On Wed, Apr 4, 2018 at 5:58 PM SmootherFrOgZ <[email protected]> wrote:

> On Mon, Apr 2, 2018 at 7:39 PM Kevin Fenzi <[email protected]> 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 -- [email protected]
>> To unsubscribe send an email to
>> [email protected]
>>
> --
>
>
Hi folks,

Any way we can schedule a meet-up to talk about this at flock?

-- 

-

Xavier
_______________________________________________
infrastructure mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]/message/3BO2FTJSEN4JPB4HOQLGAHTU5ITDCFM2/

Reply via email to