12:38 p.m.
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.
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. ;(
9:32 p.m.
On 04/02/2018 01:38 PM, Kevin Fenzi 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
Thanks for the history and writeup! Very insightful.
Dusty
2:37 a.m.
On Mon, Apr 2, 2018, at 7:38 PM, Kevin Fenzi 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.
Where does this leave us with the development on those features of FAS2 that aren't
auth related? Do we have open work to do on the new group enablements, etc.?
regards,
bex
> * 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.
>
> 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. ;(
>
>
> _______________________________________________
> infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave(a)lists.fedoraproject.org
> Email had 1 attachment:
> + signature.asc
> 1k (application/pgp-signature)
10:41 a.m.
On 04/04/2018 12:37 AM, Brian Exelbierd wrote:
Where does this leave us with the development on those features of
FAS2
that aren't auth related? Do we have open work to do on the new group
enablements, etc.?
This will be handled by the new small flask app. So, yes, it still needs
to be written. It should basically just be calling the CAIAPI part tho,
so it shouldn't need much logic.
regards,
bex
kevin
6:33 a.m.
Currently, in COPR we talk to id.fedoraproject.org to authenticate users.
Will there be some change in the name or API for this service?
Will it be possible to do user registration and group creation remotely
through CAIAPI?
Thank you
clime
On Mon, Apr 2, 2018 at 7:38 PM, Kevin Fenzi <kevin(a)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.
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. ;(
_______________________________________________
infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
To unsubscribe send an email to infrastructure-leave@lists.
fedoraproject.org
7:44 a.m.
On Wed, Apr 04, 2018 at 01:33:50PM +0200, Michal Novotny wrote:
Currently, in COPR we talk to id.fedoraproject.org to authenticate
users.
Will there be some change in the name or API for this service?
No this will remain as it is, ipsilon is running there and there is no plan on
changing this :)
Will it be possible to do user registration and group creation
remotely
through CAIAPI?
That is the idea, assuming you have sufficient credentials of course.
Pierre
10:58 a.m.
On Mon, Apr 2, 2018 at 7:39 PM Kevin Fenzi <kevin(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to
infrastructure-leave(a)lists.fedoraproject.org
--
-
Xavier
12:14 p.m.
On Wed, Apr 4, 2018 at 5:58 PM SmootherFrOgZ <lxtnow(a)gmail.com> wrote:
On Mon, Apr 2, 2018 at 7:39 PM Kevin Fenzi <kevin(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-leave(a)lists.fedoraproject.org
>
--
Hi folks,
Any way we can schedule a meet-up to talk about this at flock?
--
-
Xavier
2122
days inactive
2210
days old
infrastructure@lists.fedoraproject.org
7 comments
6 participants
participants (6)
-
Brian Exelbierd -
Dusty Mabe -
Kevin Fenzi -
Michal Novotny -
Pierre-Yves Chibon -
SmootherFrOgZ