Are there any plans for enabling single-sign-on between the different centos.org subdomains? Perhaps at least between accounts and bugs, if not also cbs or others?
I remember seeing how SSO can work seamlessly in a big company - the Windows login and a client cert enabled access to pretty much everything, from web apps like HR, to different servers, even unlocking the LAN port you were connected to. This is highly practical when it works. Then again, I was in R&D (not in IT, which had to configure the whole thing). :)
Regards, Laurențiu
On 16/08/16 11:20, Laurentiu Pancescu wrote:
Are there any plans for enabling single-sign-on between the different centos.org subdomains? Perhaps at least between accounts and bugs, if not also cbs or others?
I remember seeing how SSO can work seamlessly in a big company - the Windows login and a client cert enabled access to pretty much everything, from web apps like HR, to different servers, even unlocking the LAN port you were connected to. This is highly practical when it works. Then again, I was in R&D (not in IT, which had to configure the whole thing). :)
Regards, Laurențiu
I guess you mean using ACO (https://accounts.centos.org) as the central users DB ? Actually CBS is using certificates issued from ACO directly, so it's already integrated (and people are granted/removed rights automatically at the cbs/koji level depending on their group membership in ACO)
For existing resources within centos.org that we deployed before ACO was available, those were configured to use their built-in users DB. So we can invest time to see which are the possibilities to be tied to ACO but it needs at least some glue, like for example token/oauth. Actually, ACO on its own can't do that (nor is "ldap" compatible) so we need to setup something in between (like what's done for the Fedora project) to do that, like either ipsilon (https://ipsilon-project.org/) or keycloak (http://www.keycloak.org/)
But the remaining issue would then be to have *everybody* signing through ACO to get an account that will match with each deployed applications (like MantisBT for bugs.centos.org and so on). So you can imagine the impact
On 16/08/16 10:30, Fabian Arrotin wrote:
For existing resources within centos.org that we deployed before ACO was available, those were configured to use their built-in users DB. So we can invest time to see which are the possibilities to be tied to ACO but it needs at least some glue, like for example token/oauth. Actually, ACO on its own can't do that (nor is "ldap" compatible) so we need to setup something in between (like what's done for the Fedora project) to do that, like either ipsilon (https://ipsilon-project.org/) or keycloak (http://www.keycloak.org/)
prolly worth looking at keycloak once
But the remaining issue would then be to have *everybody* signing through ACO to get an account that will match with each deployed applications (like MantisBT for bugs.centos.org and so on). So you can imagine the impact
Would we not be able to rehash the user accounts from bugs.centos.org over to a.c.o ? and send them all a reminder to set a new password ?
On 16/08/16 11:49, Karanbir Singh wrote:
On 16/08/16 10:30, Fabian Arrotin wrote:
For existing resources within centos.org that we deployed before ACO was available, those were configured to use their built-in users DB. So we can invest time to see which are the possibilities to be tied to ACO but it needs at least some glue, like for example token/oauth. Actually, ACO on its own can't do that (nor is "ldap" compatible) so we need to setup something in between (like what's done for the Fedora project) to do that, like either ipsilon (https://ipsilon-project.org/) or keycloak (http://www.keycloak.org/)
prolly worth looking at keycloak once
don't mind doing it, but last time I checked, it was targeting existing backends like LDAP or Active Directory so not FAS (which is our backend for ACO)
But the remaining issue would then be to have *everybody* signing through ACO to get an account that will match with each deployed applications (like MantisBT for bugs.centos.org and so on). So you can imagine the impact
Would we not be able to rehash the user accounts from bugs.centos.org over to a.c.o ? and send them all a reminder to set a new password ?
Once existing users have signed to ACO , we'll probably be able to do a matching table and see how MantisBT allow external authentication. But the real problem is that all existing users will have to then signup manually on ACO (we can't "bulk register" users because also of email validation step that is mandatory)
On Tue, Aug 16, 2016 at 9:49 AM, Karanbir Singh mail-lists@karan.org wrote:
On 16/08/16 10:30, Fabian Arrotin wrote:
For existing resources within centos.org that we deployed before ACO was available, those were configured to use their built-in users DB. So we can invest time to see which are the possibilities to be tied to ACO but it needs at least some glue, like for example token/oauth. Actually, ACO on its own can't do that (nor is "ldap" compatible) so we need to setup something in between (like what's done for the Fedora project) to do that, like either ipsilon (https://ipsilon-project.org/) or keycloak (http://www.keycloak.org/)
prolly worth looking at keycloak once
Is there any reason why you're only mentioning Keycloak here? Are there any features Ipsilon is missing that would rule it out for you, or is there some other reason?
Ipsilon would probably be a better choice for now given your account backend, as Fabian already pointed out.
But the remaining issue would then be to have *everybody* signing through ACO to get an account that will match with each deployed applications (like MantisBT for bugs.centos.org and so on). So you can imagine the impact
Would we not be able to rehash the user accounts from bugs.centos.org over to a.c.o ? and send them all a reminder to set a new password ?
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 16/08/16 11:33, Patrick Uiterwijk wrote:
On Tue, Aug 16, 2016 at 9:49 AM, Karanbir Singh mail-lists@karan.org wrote:
On 16/08/16 10:30, Fabian Arrotin wrote:
For existing resources within centos.org that we deployed before ACO was available, those were configured to use their built-in users DB. So we can invest time to see which are the possibilities to be tied to ACO but it needs at least some glue, like for example token/oauth. Actually, ACO on its own can't do that (nor is "ldap" compatible) so we need to setup something in between (like what's done for the Fedora project) to do that, like either ipsilon (https://ipsilon-project.org/) or keycloak (http://www.keycloak.org/)
prolly worth looking at keycloak once
Is there any reason why you're only mentioning Keycloak here? Are there any features Ipsilon is missing that would rule it out for you, or is there some other reason?
mostly since its something I haveto work with in a different scope - but the fact that it does not work with the accounts backend we have at the moment is a bit of a blocker :)
Ipsilon would probably be a better choice for now given your account backend, as Fabian already pointed out.
sounds good, can we get some sort of a scope done here ?
On 16/08/2016 11:33, Patrick Uiterwijk wrote:
prolly worth looking at keycloak once
Is there any reason why you're only mentioning Keycloak here? Are there any features Ipsilon is missing that would rule it out for you, or is there some other reason?
Speaking with my Ipsilon developer hat on, I (and I imagine Patrick too) would be interested what features people feel are missing from Ipsilon. We've got plenty of new features coming up, but it's always good to know what else people would like to see :)
On 16/08/16 11:30, Fabian Arrotin wrote:
I guess you mean using ACO (https://accounts.centos.org) as the central users DB ?
Yes, exactly. I think even on Fedora, the bug tracker is not tied to the FAS.
But the remaining issue would then be to have *everybody* signing through ACO to get an account that will match with each deployed applications (like MantisBT for bugs.centos.org and so on). So you can imagine the impact
In that case, sure. I initially thought about recognizing visitors already logged in to accounts.c.o, not removing all other accounts. But you and Karanbir probably know the infrastructure best, and what's doable with reasonable effort. Thanks!
Regards, Laurențiu
-
Fabian Arrotin -
Howard Johnson -
Karanbir Singh -
Laurentiu Pancescu -
Patrick Uiterwijk