Copied from InfraWiki/CentralizedAuth

1. Centralized Authentication for CentOS.org Restructuring

There are some issues with the way we do the mirrors at the moment, so we are rethinking on how we should do that. All thoughts about this can be found on this page.

1.1. Short introduction

• local accounts for Infra team (puppet manages that)
• doesn't scale anymore (need to plug other systems, like Koji and other solutions to come)

1.2. Alternatives and requirements list

Here are the current alternatives that are on the short list:

• IPA : http://www.freeipa.org/page/Main_Page

• FAS - Fedora Account System : https://fedorahosted.org/fas/

1.3. FAQ and Remarks

1.3.1. IPA

• IPA is normally used to provide Kerberos/access/SSL certifcations, all integrated into one solution. It normally uses heavily DNS for the SRV location, but if we use that, we'll have to probably use our cfgmgmt system to modify clients krb config, instead of exposing all that on the Internet (and so "firewalling" also access to KDC)
• Kerberos isn't really the target, but nice to have (see above)
• We'll mainly use the embedded dogtag ssl solution from IPA to take care of the x509/pki.
• Has an active upstream and user community.

1.3.2. FAS

• FAS isn't a centralized auth system following standard protocols. It's more or less a "Users CMDB" and cron jobs/scripts are creating/removing/modifying users/groups locally on each managed system.

• Mainly written to discuss with the fedmsg bus, and so targetting all Fedora Applications
• Written for one project but has good integration with Fedora web services.

Continued March 2015 - BrianStinson

1. Other Requirements

2. Work needed to get up and running

3. Other Comments

4. Editorializing

Personally, if I had to choose right now, I would be -0 on IPA and +0 on FAS. It seems that both solutions will require some sort of modification or support from us, the difference being where that support is required.

4.1. IPA

IPA's advantages come from being included in the distro by default, by having a stable upstream, and by being a robust full-fledged IdM tool with a fully configured CA which we could leverage with our own tools if-and-until the developers include client cert management tools upstream (Perhaps in v4.2?) http://permalink.gmane.org/gmane.linux.redhat.freeipa.user/14646. In most cases the developers seem amenable to accepting changes, although we would be deploying IPA in a workflow that doesn't match the "usual" use-case. IPA speaks to most of the "problems" we are facing now: we need a list of users and groups for git, koji and the lookaside and provides an interface for managing group membership by SIG admins. Handling Self-Service user registration and user cert generation and delivery would be left up to us.

Since our requirements do not yet include connecting the CentOS infra machines to the domain for machine accounts, we may not be able to take advantage of all of the features of an IdM. In the future, we may find ourselves using more applications from Fedora which are not widely tested against IPA. IPA would also require us to support a separate tool for self-service user registration separate from the built-in interface to manage group membership and permissions.

4.2. FAS

FAS's advantages come from being developed with Fedora's applications in mind. The established workflow: "Request Account, Generate Cert, Request Group Membership, Auth with user cert" is well tested with this tool in production. The modifications needed would largely be packaging related. The developers seem willing to accept patches, and even to hear about features we would like to see. FAS speaks directly to the "problems" we are facing now: we need a list of users and groups for git, koji, and the lookaside that allows for Self-Service account creation, group membership management by SIG admins, and automatic user cert generation. We would need to handle delivering the cert to the user (likely through modifying fedora-cert).

FAS is _extensively_ tied to Fedora's infrastructure and is quite opinionated as such. It would require a few more moving parts (TurboGears instance, Postgres DB, caches, data storage etc.) and replicas would require a little more sysadmin work on the backend. Being developed with a single project in mind comes with quite a bit of branding scattered around the sources, we would need to go through and be sure everything points to the correct places. FAS (as it exists now) does not provide a clean way to manage machine accounts on our infra, but this problem seems to be stable around our config management setup.