On Mon, Apr 2, 2018 at 7:39 PM Kevin Fenzi <ke...@scrye.com> wrote:

> Greetings.
>
> 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
>
> Background/History
>
>   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)
>
> Plan:
>
>   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
> notice.
> * 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 FreeIPA
> has matured and our understanding of the work required to make CAIAPI
> and a small web consumer has clarified.
>
> Pros:
>
>   * 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).
>
> Cons:
>   * 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 today
so...

@Partrick. what's the next step with CAIAPI?

>
>
> _______________________________________________
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
>
-- 

-

Xavier
_______________________________________________
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Reply via email to