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. 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)
2. Alternatives and requirements list
Here are the current alternatives that are on the short list:
FAS - Fedora Account System : https://fedorahosted.org/fas/
Requirement (short explained) |
IPA |
FAS |
packages available natively in the distro |
yes |
no |
packages available for a rebuild |
yes |
yes |
multi-master replication |
yes |
tbc |
Kerberos support |
yes |
tbc |
LDAP support |
yes |
no |
SSL cert generation/signing |
yes |
yes |
User self-enrollment |
no * but POC available, production under development |
yes |
OAuth plugin available |
no * but can be added with FedOAuth |
yes with FedOAuth |
3. FAQ and Remarks
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.
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.