On Mon, Apr 2, 2018 at 7:39 PM Kevin Fenzi <kevin(a)scrye.com>
> Sorry it took so long to write this up and send it out, but here's our
> proposed plan for authentication moving forward.
> Please do feel free to comment or suggest changes/improvements here. Any
> mistakes are mine alone. :)
> Fedora Project Auth roadmap
> The Fedora project created its own authentication/user/group
> management system at nearly the beginning of its existance. FAS (Fedora
> Account System) (version 1) and then a rewrite (FAS2). At each of these
> points other solutions were investigated and found unacceptable for
> various reasons. Over the last few years, several additional
> applications have been added next to FAS2 to provide additional
> functionality: ipisilon has been added as a identity provider, and
> FreeIPA has been added for kerberos authentication. FAS2 is still the
> authoritative source of authentication data. FAS2 is currently deployed
> on RHEL6 servers and won't run on RHEL7.
> Also during the last few years, a new FAS re-write has been slowly in
> the works. FAS3 is written in a modern framework and has a number of
> functionality and interface improvements over FAS2. Additionally it can
> run on RHEL7.
> Goals and Critera
> Maintaining authentication applications is difficult and time
> consuming work, and it has always been a goal to try and move to more
> industry standard applications as much as possible given our goals and
> critera. The last time we looked, Some of those goals/critera include:
> * User self service registration
> * User self service password reset
> * FPCA acceptance requirement
> * Basset integration (may not be needed anymore)
> * Allow Self Service groups with their own sponsors/admins
> * Allow group requirements (other group first, etc)
> On discussion with FreeIPA developers and looking at how things are
> setup now, we came up with a plan to get what we need, but reduce the
> footprint and maintance we need to do. Many of the features we were
> hoping to use in FAS3 have now been implemented upstream in
> FreeIPA (2fa, fasClient syncing better, etc).
> Basically we will:
> * A new small wrapper type project is written (Community Account
> Information API) or CAIAPI.
> This small app provides the Critera listed above, talking at first to
> FAS2 on the backend then, later switching to talking to FreeIPA on the
> backend and providing a json API to consumers.
> * Switch anything we have using the direct FAS api to use CAIAPI instead.
> * Move to FreeIPA being the canonical source for authentication data.
> This should just be a switch to CAIAPI, and no consumers should even
> * FreeIPA still provides kerberos auth.
> Note that kerberos will remain limited to use at ipsilon and koji.
> * Ipsilon provides identity auth for applications, preferably with OIDC
> (still provides others)
> * A new small website that uses the CAIAPI json to provide end user
> access / management. This thing would be in flask and needs a name still.
> Good news. we finally are getting somewhere :)
> Since https://fedoraproject.org/wiki/Infrastructure/fas_freeipa
> has matured and our understanding of the work required to make CAIAPI
> and a small web consumer has clarified.
> * IPA handles all the storing of credentials, replication and such and
> we just use it.
> * Our maint goes from needing to maintain FAS2 or FAS3 to just CAIAPI
> (a much smaller api) and a
> very small web application.
> * Easier to audit 2 small apps.
> * We can try and share the CAIAPI with other open source communities
> (Gnome? CentOS? others?)
> Open Source Communities already using FreeIPA would be easy to add
> this to.
> * We can stop using fasClient in favor of ipa-client setup (no more
> heavy syncing)
> * The heavy security aspects will be handled by upstreams we don't
> need to fully maintain
> (FreeIPA, sssd, ipsilon, etc).
> * We still need to write the CAIAPI/webapp, although Patrick may have
> CAIAPI already somewhat implemented.
> * It feels very sad to have spent so long on FAS3 and never deploy it,
> but sometimes
> thats just the way things go. ;(
Well, we have to keep up with new tech/ideas/architecure redesign. It
would have been used for the last 2 years and we would have to change it
@Partrick. what's the next step with CAIAPI?
> infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
> To unsubscribe send an email to
Any way we can schedule a meet-up to talk about this at flock?