Identity
Goals - support authentication against external LDAP - provide authentication mechanism across aeolus components
Conversation Topics
* LDAP Support:
* Conductor auth against LDAP with local DB Fallback
* conductor first tries authenticate user against external LDAP server. If user is found there, user account in local db is created (except credentials) if it doesn't exist yet. If user is not found in LDAP, local db is searched.
* Keep Consistent With Katello
* This means Using DB as initial resource and falling back to LDAP
* if admin deletes a LDAP user in admin section, user is deleted only from local db, but this user can login again (as she will be authenticated against LDAP)
* user listing in conductor - shoud we list only local users or all including LDAP?
* do we need UI for LDAP config (it's probably only IP + port, maybe LDAP domain), if so we will need some table for saving configuration (we don't have this yet)
* should be LDAP server setup part of aeolus-configure script? I don't think so.
* but we should probably have something in aeolus-configure to make conductor/etc aware of the ldap store
* IWHD Auth against:
* Conductor?
* warehouse should know about same set of users as conductor? No
* warehouse is going to support GSSAPI. So if someone is authenticating to warehouse, identity check should be done against conductor?
* LDAP?
* Should IWHD and imagefactory users be independent
* should IWHD authenticate always against conductor or against LDAP or other resource? if not against conductor local db users won't have access to iwhd
* Should ImageFactory Authenticate users?Yes
* Authentication across components
* Use OAuth?
* Already Support By Katello
* supports OAuth (two-legged), so it's not a problem for conductor to be a 'consumer' of Katello service and use two-legged OAuth too (in case conductor will use Katello as a service)
* OAuth Providers:
* Conductor
* IWHD?
* Will IWHD Support OAuth as well as GSSAPI?
* OAuth Clients
* aeolus-image
* imagefactory
* IWHD?
* if iwhd supports only GSSAPI (and should authenticate against conductor) then conductor should act as GSSAPI server. Also user creds in image build process will have to be passed through aeolus-image->imagefactory->iwhd
* any other alternative to OAuth?
Task List
* Add LDAP support in conductor
* Update authentication model to auth againsts LDAP id available
* Create non existing users to local db
* Add OAuth Provider Support to
* Conductor
* IWHD?
* Add OAuth Client Support to
* Imagefactory
* aoelus-image
* IWHD?
* Add Deps to componets and fedora
* gem used in conductor for ldap auth, could be part of some more sophisticated gem (devise, omniauth)
* oauth, gssapi libs
On 07/29/2011 11:58 AM, Martyn Taylor wrote:
Identity
Goals
- support authentication against external LDAP
- provide authentication mechanism across aeolus components
Conversation Topics
* LDAP Support: * Conductor auth against LDAP with local DB Fallback * conductor first tries authenticate user against external LDAPserver. If user is found there, user account in local db is created (except credentials) if it doesn't exist yet. If user is not found in LDAP, local db is searched.
I wonder why reinvent the wheel. Can you use local pam stack for authentication and configure SSSD. It already provides all the functionality you are talking about. * Local storage * External LDAP auth * Identity cache
We will be providing a special interface down the road but for now simple wrappers around pam and nss calls would allow you to save you a lot of time.
Do you want to explore it more?
* Keep Consistent With Katello * This means Using DB as initial resource and falling back to LDAP
SSSD handles this.
* if admin deletes a LDAP user in admin section, user is deletedonly from local db, but this user can login again (as she will be authenticated against LDAP)
And this.
* user listing in conductor - shoud we list only local users or allincluding LDAP?
SSSD can create unified lists across local and LDAP domains if you really need the list. It can also return you groups and group membership for your access control checks.
* do we need UI for LDAP config (it's probably only IP + port,maybe LDAP domain), if so we will need some table for saving configuration (we don't have this yet)
If you go with SSSD it is not needed. Everything goes to sssd.conf
* should be LDAP server setup part of aeolus-configure script? Idon't think so.
This is a big question but if you set SSSD your test scripts then can add local users to it do a dry run and test even withouth the external LDAP server.
* but we should probably have something in aeolus-configure to makeconductor/etc aware of the ldap store
* IWHD Auth against: * Conductor?
IWHD authenticating against Conductor does not make sense. It should be against some identity source. Conductor is not a source. If we are talking about IWHD connecting to Conductor then it depends how it connects but I am not sure if this connection exsts. This is something still not clear from other discussions on the list.
* warehouse should know about same set of users as conductor? No
IMO there is a big overlap between those so I would say yes. The store should be in general the same. Just different groups within same organization or community.
* warehouse is going to support GSSAPI. So if someone isauthenticating to warehouse, identity check should be done against conductor?
Against IPA. GSSAPI gives you Kerberos SSO. User authenticates against IPA and gets ticket to access IWHD. Same should be generally with any component. It is all covered on the diagrams that I sent a month ago however there was not discussion or agreement about hose so I do not know if everybody on the same page about it. It looks like it is not the case so far.
* LDAP?
It can be done using LDAP but then you would have to provide you password on every command.
* Should IWHD and imagefactory users be independent
No. In context of the combined solution users come from one identity source (at least for v1)
* should IWHD authenticate always against conductor or against LDAPor other resource? if not against conductor local db users won't have access to iwhd
It looks like there is a lot of confusion. Can we have a meeting about it?
* Should ImageFactory Authenticate users?Yes
It depends. If IF does not expose CLI/UI directly then may be no. We need to agree on the diagrams I sen a month ago before we can answer these questions. John, Hugh, should we have a formal review meeting?
* Authentication across components
Diagrams are about it...
* Use OAuth?
It depends.
* Already Support By Katello * supports OAuth (two-legged), so it's not a problem for conductorto be a 'consumer' of Katello service and use two-legged OAuth too (in case conductor will use Katello as a service)
* OAuth Providers: * Conductor * IWHD? * Will IWHD Support OAuth as well as GSSAPI? * OAuth Clients * aeolus-image * imagefactory * IWHD? * if iwhd supports only GSSAPI (and should authenticate againstconductor) then conductor should act as GSSAPI server. Also user creds in image build process will have to be passed through aeolus-image->imagefactory->iwhd
Oh... Let us have a review... please!
* any other alternative to OAuth?
Before we move to the actions and tasks we should agree on the architecture.
Task List
* Add LDAP support in conductor * Update authentication model to auth againsts LDAP id available * Create non existing users to local db * Add OAuth Provider Support to * Conductor * IWHD? * Add OAuth Client Support to * Imagefactory * aoelus-image * IWHD? * Add Deps to componets and fedora * gem used in conductor for ldap auth, could be part of some moresophisticated gem (devise, omniauth)
* oauth, gssapi libs
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
Hi Dmitri,
On Fri, 2011-07-29 at 12:31 -0400, Dmitri Pal wrote:
On 07/29/2011 11:58 AM, Martyn Taylor wrote:
Identity
Goals
- support authentication against external LDAP
- provide authentication mechanism across aeolus components
Conversation Topics
* LDAP Support: * Conductor auth against LDAP with local DB Fallback * conductor first tries authenticate user against external LDAPserver. If user is found there, user account in local db is created (except credentials) if it doesn't exist yet. If user is not found in LDAP, local db is searched.
I wonder why reinvent the wheel. Can you use local pam stack for authentication
Using PAM is an interesting idea. It does make the app more complicated to install and configure, though. And makes it less portable. Also, I don't see much talk of Rails apps using PAM.
All that being said, though, it might be a good option for LDAP support assuming we retain the option of using Conductor's DB as an identity store.
and configure SSSD.
SSD is what would give us the identity cache, right?
The motivation there was for laptop use cases, right? i.e. where you want to be able to authenticate a user even when you can't reach the LDAP server?
It already provides all the functionality you are talking about.
- Local storage
i.e. authenticate against /etc/shadow ?
- External LDAP auth
And lots of other auth options
- Identity cache
That's from SSD?
[..]
* do we need UI for LDAP config (it's probably only IP + port,maybe LDAP domain), if so we will need some table for saving configuration (we don't have this yet)
If you go with SSSD it is not needed. Everything goes to sssd.conf
All LDAP configuration is in sssd.conf? No extra PAM, nsswitch or OpenLDAP config?
Cheers, Mark.
On Wed, 2011-08-03 at 15:40 +0100, Mark McLoughlin wrote:
Hi Dmitri,
On Fri, 2011-07-29 at 12:31 -0400, Dmitri Pal wrote:
On 07/29/2011 11:58 AM, Martyn Taylor wrote:
Identity
Goals
- support authentication against external LDAP
- provide authentication mechanism across aeolus components
Conversation Topics
* LDAP Support: * Conductor auth against LDAP with local DB Fallback * conductor first tries authenticate user against external LDAPserver. If user is found there, user account in local db is created (except credentials) if it doesn't exist yet. If user is not found in LDAP, local db is searched.
I wonder why reinvent the wheel. Can you use local pam stack for authentication
Using PAM is an interesting idea. It does make the app more complicated to install and configure, though. And makes it less portable. Also, I don't see much talk of Rails apps using PAM.
All that being said, though, it might be a good option for LDAP support assuming we retain the option of using Conductor's DB as an identity store.
Oh yes, as Simo pointed out, the other thing about PAM is that it doesn't get us kerberos support - it's not a magic bullet on that front.
Cheers, Mark.
On 08/03/2011 10:58 AM, Mark McLoughlin wrote:
On Wed, 2011-08-03 at 15:40 +0100, Mark McLoughlin wrote:
Hi Dmitri,
On Fri, 2011-07-29 at 12:31 -0400, Dmitri Pal wrote:
On 07/29/2011 11:58 AM, Martyn Taylor wrote:
Identity
Goals
- support authentication against external LDAP
- provide authentication mechanism across aeolus components
Conversation Topics
* LDAP Support: * Conductor auth against LDAP with local DB Fallback * conductor first tries authenticate user against external LDAPserver. If user is found there, user account in local db is created (except credentials) if it doesn't exist yet. If user is not found in LDAP, local db is searched.
I wonder why reinvent the wheel. Can you use local pam stack for authentication
Using PAM is an interesting idea. It does make the app more complicated to install and configure, though. And makes it less portable. Also, I don't see much talk of Rails apps using PAM.
All that being said, though, it might be a good option for LDAP support assuming we retain the option of using Conductor's DB as an identity store.
Oh yes, as Simo pointed out, the other thing about PAM is that it doesn't get us kerberos support - it's not a magic bullet on that front.
I am not sure we are talking about same scenario here. PAM gives you kerberos support if you plan to authenticate users by prompting them for their user credentials. In this case yes you can use user's Kerberos password to authenticate him as pma can have pam_krb5 or sssd configured.
If you are talk about the case when user already authenticated using his kerberos password and has TGT and tries to access Conductor using browser the GSSAPI negotiation should kick in even before the application decides to prompt user for credentials. In Apache mod_krb5 is in charge of this. So if negotiation is successful user is redirected to the protected pages otherwise it can be an error or user can be pointed to an unprotected page. These would be the pages where user is asked for password and the whole PAM related sequence starts.
For GSSAPI negotiation to work now user and service (conductor) should be members of the the same kerberos domain. In 80/20- use case user will be using his windows machine to start the browser so either conductor should be made a windows service or the conductor should be a part of IPA domain (while user is a part of the AD domain) and there should be a trust between IPA and AD. This is the functionality we are working on now. Until it is there I do not see any value to be concerned with GSSAPI negotiation and this PAM suits fine your needs.
Hope this clarifies things.
Cheers, Mark.
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
On Wed, 2011-08-03 at 19:56 -0400, Dmitri Pal wrote:
Oh yes, as Simo pointed out, the other thing about PAM is that it doesn't get us kerberos support - it's not a magic bullet on that front.
I am not sure we are talking about same scenario here.
It was simply a warning to others that PAM isn't sufficient for ticket based kerberos authentication.
It's easy to forget that PAM doesn't do this.
Cheers, Mark.
On 08/03/2011 10:40 AM, Mark McLoughlin wrote:
Hi Dmitri,
On Fri, 2011-07-29 at 12:31 -0400, Dmitri Pal wrote:
On 07/29/2011 11:58 AM, Martyn Taylor wrote:
Identity
Goals
- support authentication against external LDAP
- provide authentication mechanism across aeolus components
Conversation Topics
* LDAP Support: * Conductor auth against LDAP with local DB Fallback * conductor first tries authenticate user against external LDAPserver. If user is found there, user account in local db is created (except credentials) if it doesn't exist yet. If user is not found in LDAP, local db is searched.
I wonder why reinvent the wheel. Can you use local pam stack for authentication
Using PAM is an interesting idea. It does make the app more complicated to install and configure, though. And makes it less portable. Also, I don't see much talk of Rails apps using PAM.
All that being said, though, it might be a good option for LDAP support assuming we retain the option of using Conductor's DB as an identity store.
and configure SSSD.
SSD is what would give us the identity cache, right?
Yes but not only.
The motivation there was for laptop use cases, right? i.e. where you want to be able to authenticate a user even when you can't reach the LDAP server?
The motivation is mostly to abstract from different identity sources and authentication sources: You can configure LDAP, AD, IPA, local files, or SSSD itself (it has local indentity domain you are welcome to use). The point is that your application does not need to know what is the source. The source is configured outside the app.
It already provides all the functionality you are talking about.
- Local storage
i.e. authenticate against /etc/shadow ?
Not only. It has its own local user domain that you can use. It is not local files.
- External LDAP auth
And lots of other auth options
Yep.
- Identity cache
That's from SSD?
SSSD, you missing one S which might be confusing as there is another project called SSD. SSSD caches identities from remote identity sources in the local DB so for the applications on the system is does not really matter whether the system is connected or not and where the identities come from. It can cache credentials too and do local authentication when disconnect from central source.
I understand that to take advantage of SSSD one now would have to implement PAM calls and NSS libc calls. This is limiting and not convenient. Next year we plan to provide a D-BUS interface that will have all sorts of bindings for different languages. I hope that switch from PAM/NSS to this interface would be really simple and straightforward. One of the benefits of it will be the capability to decouple the application identity space from the OS identity space. We see that this would be a highly desirable feature. Think about SSSD in this case as a local instance of SiteMinder. This is the path we are going. We are not there yet but I want to layout the direction for you so that you have all the information to make your implementation decision and not do the work that can be avoided.
[..]
* do we need UI for LDAP config (it's probably only IP + port,maybe LDAP domain), if so we will need some table for saving configuration (we don't have this yet)
If you go with SSSD it is not needed. Everything goes to sssd.conf
All LDAP configuration is in sssd.conf? No extra PAM, nsswitch or OpenLDAP config?
Cheers, Mark.
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
The motivation there was for laptop use cases, right? i.e. where you want to be able to authenticate a user even when you can't reach the LDAP server?
The motivation is mostly to abstract from different identity sources and authentication sources: You can configure LDAP, AD, IPA, local files, or SSSD itself (it has local indentity domain you are welcome to use). The point is that your application does not need to know what is the source. The source is configured outside the app.
I do like this idea. Instead of supporting both LDAP / DB based authentications and having to keep users in sync), perhaps in configure we can have the admin select an authentication mechanism, configure it (whether a new local install or an existing remote solution), and then access it via PAM (or GSSAPI or whatever abstract authentication mechanism)
That way Aeolus could support whatever custom authentication scheme whether or not it already deployed in an existing infrastructure (I'm sure this will make alot of sysadmins happy :-) )
-Mo
SSD is what would give us the identity cache, right?
The motivation there was for laptop use cases, right? i.e. where you want to be able to authenticate a user even when you can't reach the LDAP server?
Well conductor, iwhd, etc themselves would be the only ones authenticating against LDAP correct? We would the end user communicate w/ ldap directly?
-Mo
* conductor first tries authenticate user against external LDAPserver. If user is found there, user account in local db is created (except credentials) if it doesn't exist yet. If user is not found in LDAP, local db is searched.
* This means Using DB as initial resource and falling back to LDAP
These two bullets seem to contrast one another, the first you're saying use LDAP first and in the 2nd your saying use the DB first.
* if admin deletes a LDAP user in admin section, user is deletedonly from local db, but this user can login again (as she will be authenticated against LDAP)
I'm not a fan of this, if an admin deletes a user, it is expected that user is deleted and is not able to login again. An alternate approach would be to introduce the notion of 'disabling' a user account
* do we need UI for LDAP config (it's probably only IP + port,maybe LDAP domain), if so we will need some table for saving configuration (we don't have this yet)
I image a WUI to control LDAP has been implemented, perhaps this is just finding the right one?
In any case, LDAP config is more suited for a yaml file written by configure, not in a db in the database.
* should be LDAP server setup part of aeolus-configure script? Idon't think so.
I disagree, I think this should be an optional feature able to be setup by configure. The configure script should also support being able to specify an external location for an existing LDAP install (falling back to setting it up locally if it doesn't exist).
All in all, IMO the user shouldn't be required to do anything to setup aeolus other than install the rpms and run aeolus-configure.
-Mo
aeolus-devel@lists.fedorahosted.org
-
Dmitri Pal -
Mark McLoughlin -
Martyn Taylor -
Mo Morsi