Re: [openstack-dev] [Keystone] external AuthN Identity Backend
On 10/16/2014 02:58 PM, David Chadwick wrote: Dave when federation is used, the user's group is stored in a mapping rule. So we do have a mechanism for storing group memberships without using LDAP or creating an entry for the user in the SQL backend. (The only time this is kinda not true is if we have a specific rule for each federated user, so that then each mapping rule is equivalent to an entry for each user). But usually we might expect many users to use the same mapping rule. Mapping rules should be usable for Kerberos logins. I dont know if the current code does have this ability or not, but if it doesn't, then it should be re-engineered to. (it was always in my design that all remote logins should have a mapping capability) I most certainly does, and can be extended to get additional env vars from mod_lookup_identity as well. regards David On 16/10/2014 19:15, Dave Walker wrote: Hi, Currently we have two ways of doing Identity Auth backends, these are sql and ldap. The SQL backend is the default and is for situations where Keyston is the canonical Identity provider with username / password being directly compared to the Keystone database. LDAP is the current option if Keystone isn't the canonical Identity provider and passes the username and password to an LDAP server for comparison and retrieves the groups. For a few releases we have supported External auth (or Kerberos), where we authenticate the user at the edge and trust the REMOTE_USER is valid. In these situations Keystone doesn't require the Username or Password to be valid. Particularly in Kerberos situations, no password is used to successfully authenticate at the edge. This works well, but LDAP cannot be used as no password is passed through. The other option is SQL, but that then requires a user to be created in Keystone first. We do not seem to cover the situation where Identity is provided by an external mechanism. The only system currently available is Federation via SAML, which isn't always the best fit. Therefore, I'd like to suggest the introduction of a third backend. This would be the external identity provider. This would seem to be pretty simple, as the current checks would simply return success (as we trust auth at the edge), and not store user_id in the database, but generate it at runtime. The issue I have, is that this doesn't cover Group membership. So, am I a: - Barking totally up the wrong tree - Add support to the current LDAP plugin to support external auth (but still use LDAP for groups) - Write a standalone external plugin, but then do what for Groups? I would be reasonably happy to just have 1:1 mapping of users to groups. Does this make sense? Thanks -- Kind Regards, Daviey Walker ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] external AuthN Identity Backend
On 10/16/2014 03:18 PM, Dave Walker wrote: On 16 October 2014 20:07, David Stanek wrote: I may be missing something, but can you use the external auth method with the LDAP backend? No, as the purpose of the LDAP backend is to validate user/pass combination are valid. With the external auth plugin, these are not provided to keystone (and may not even exist). If they did exist, we would be doing auth at the edge and at the backend - which seems needlessly expensive. -- Kind Regards, Daviey Walker ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev The short of it is that what you are describing is handled by Federation. I think that there is some confusing in the processing of an authN/authZ request which we call "create a token" Here's how I would expect it to work in a Kerberos case (the archetype for external) before the use of Federation 1. mod_auth_kerb authenticates the user and sets REMOTE_USER before calling the Keystone WSGI app 2. Keystone accepts REMOTE_USER and looks up the user in LDAP to get groups 3. Userid and Groups are used to fetch roles to populate the token We can also use the OSand mod_lookup_identity to get us Groups: see this write up for how to use Federation with SSSD http://adam.younglogic.com/2014/05/keystone-federation-via-mod_lookup_identity/ That is old and needs to be updated, but the concepts are the same. With Federation, you provide a mapping and a bunch of env vars to the Keystone server, and there is no need to persist the user in the user table. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] external AuthN Identity Backend
On 10/16/2014 12:30 PM, Dave Walker wrote: > Hi, > > I think I considered the Federated plugin as a mismatch as it dealt > with 'remote' auth rather than 'external' auth. I thought it was for > purely handling SSO / SAML2, and not being subordinate to auth with > the webserver. > > I'll dig into the federation plugin more, thanks. There are some plans to be able to frontend the user/group lookup in httpd like you ca do with external auth. This is similar to the federation approach. I've written up some details here: https://blog-nkinder.rhcloud.com/?p=130 There is still work to do to tie in the mapping code from the OS-FEDERATION extension, but I think the approach shows a lot of promise. Choose your auth module (mod_auth_kerb, mod_ssl, etc.) to set REMOTE_USER, then use mod_lookup_identity to supply the user/group info from LDAP. This is an approach that should get some discussion time at the Summit. Thanks, -NGK > > -- > Kind Regards, > Dave Walker > > On 16 October 2014 19:58, David Chadwick wrote: >> Dave >> >> when federation is used, the user's group is stored in a mapping rule. >> So we do have a mechanism for storing group memberships without using >> LDAP or creating an entry for the user in the SQL backend. (The only >> time this is kinda not true is if we have a specific rule for each >> federated user, so that then each mapping rule is equivalent to an entry >> for each user). But usually we might expect many users to use the same >> mapping rule. >> >> Mapping rules should be usable for Kerberos logins. I dont know if the >> current code does have this ability or not, but if it doesn't, then it >> should be re-engineered to. (it was always in my design that all remote >> logins should have a mapping capability) >> >> regards >> >> David >> >> On 16/10/2014 19:15, Dave Walker wrote: >>> Hi, >>> >>> Currently we have two ways of doing Identity Auth backends, these are >>> sql and ldap. >>> >>> The SQL backend is the default and is for situations where Keyston is >>> the canonical Identity provider with username / password being >>> directly compared to the Keystone database. >>> >>> LDAP is the current option if Keystone isn't the canonical Identity >>> provider and passes the username and password to an LDAP server for >>> comparison and retrieves the groups. >>> >>> For a few releases we have supported External auth (or Kerberos), >>> where we authenticate the user at the edge and trust the REMOTE_USER >>> is valid. In these situations Keystone doesn't require the Username >>> or Password to be valid. >>> >>> Particularly in Kerberos situations, no password is used to >>> successfully authenticate at the edge. This works well, but LDAP >>> cannot be used as no password is passed through. The other option is >>> SQL, but that then requires a user to be created in Keystone first. >>> >>> We do not seem to cover the situation where Identity is provided by an >>> external mechanism. The only system currently available is Federation >>> via SAML, which isn't always the best fit. >>> >>> Therefore, I'd like to suggest the introduction of a third backend. >>> This would be the external identity provider. This would seem to be >>> pretty simple, as the current checks would simply return success (as >>> we trust auth at the edge), and not store user_id in the database, but >>> generate it at runtime. >>> >>> The issue I have, is that this doesn't cover Group membership. >>> >>> So, am I a: >>> - Barking totally up the wrong tree >>> - Add support to the current LDAP plugin to support external auth >>> (but still use LDAP for groups) >>> - Write a standalone external plugin, but then do what for Groups? I >>> would be reasonably happy to just have 1:1 mapping of users to groups. >>> >>> Does this make sense? >>> >>> Thanks >>> >>> -- >>> Kind Regards, >>> Daviey Walker >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] external AuthN Identity Backend
Hi, I think I considered the Federated plugin as a mismatch as it dealt with 'remote' auth rather than 'external' auth. I thought it was for purely handling SSO / SAML2, and not being subordinate to auth with the webserver. I'll dig into the federation plugin more, thanks. -- Kind Regards, Dave Walker On 16 October 2014 19:58, David Chadwick wrote: > Dave > > when federation is used, the user's group is stored in a mapping rule. > So we do have a mechanism for storing group memberships without using > LDAP or creating an entry for the user in the SQL backend. (The only > time this is kinda not true is if we have a specific rule for each > federated user, so that then each mapping rule is equivalent to an entry > for each user). But usually we might expect many users to use the same > mapping rule. > > Mapping rules should be usable for Kerberos logins. I dont know if the > current code does have this ability or not, but if it doesn't, then it > should be re-engineered to. (it was always in my design that all remote > logins should have a mapping capability) > > regards > > David > > On 16/10/2014 19:15, Dave Walker wrote: >> Hi, >> >> Currently we have two ways of doing Identity Auth backends, these are >> sql and ldap. >> >> The SQL backend is the default and is for situations where Keyston is >> the canonical Identity provider with username / password being >> directly compared to the Keystone database. >> >> LDAP is the current option if Keystone isn't the canonical Identity >> provider and passes the username and password to an LDAP server for >> comparison and retrieves the groups. >> >> For a few releases we have supported External auth (or Kerberos), >> where we authenticate the user at the edge and trust the REMOTE_USER >> is valid. In these situations Keystone doesn't require the Username >> or Password to be valid. >> >> Particularly in Kerberos situations, no password is used to >> successfully authenticate at the edge. This works well, but LDAP >> cannot be used as no password is passed through. The other option is >> SQL, but that then requires a user to be created in Keystone first. >> >> We do not seem to cover the situation where Identity is provided by an >> external mechanism. The only system currently available is Federation >> via SAML, which isn't always the best fit. >> >> Therefore, I'd like to suggest the introduction of a third backend. >> This would be the external identity provider. This would seem to be >> pretty simple, as the current checks would simply return success (as >> we trust auth at the edge), and not store user_id in the database, but >> generate it at runtime. >> >> The issue I have, is that this doesn't cover Group membership. >> >> So, am I a: >> - Barking totally up the wrong tree >> - Add support to the current LDAP plugin to support external auth >> (but still use LDAP for groups) >> - Write a standalone external plugin, but then do what for Groups? I >> would be reasonably happy to just have 1:1 mapping of users to groups. >> >> Does this make sense? >> >> Thanks >> >> -- >> Kind Regards, >> Daviey Walker >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] external AuthN Identity Backend
On 16 October 2014 20:07, David Stanek wrote: > I may be missing something, but can you use the external auth method with > the LDAP backend? > No, as the purpose of the LDAP backend is to validate user/pass combination are valid. With the external auth plugin, these are not provided to keystone (and may not even exist). If they did exist, we would be doing auth at the edge and at the backend - which seems needlessly expensive. -- Kind Regards, Daviey Walker ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] external AuthN Identity Backend
On Thu, Oct 16, 2014 at 2:54 PM, Dave Walker wrote: > Hi Steve, > > Thanks for your response. I am talking generally about the external > auth support. One use case is Kerberos, but for the sake of argument > this could quite easily be Apache Basic auth. The point is, we have > current support for entrusting AuthN outside of Keystone. > > What I was trying to outline is that it seems that the current design > of external auth is that keystone is not in the auth pipeline as we > trust auth at the edge. However, we then do additional auth within > keystone. > > With external auth and SQL, we drop the user provided username and > password on the floor and use what was provided in REMOTE_USER (set by > the webserver). > > Therefore the check as it currently stands in SQL is basically 'is > this username in the database'. The LDAP plugin does Authentication > via username and password, which is clearly not sufficient for > external auth. The LDAP plugin could be made to check in a similar > manner to SQL 'is this a valid user' - but this would seem to be a > duplicate check, as we already did this at the edge. > > If the webserver granted access to keystone, the user has already been > checked to see if they are a valid user. However, your response seems > to suggest that current external auth should be formally deprecated? I may be missing something, but can you use the external auth method with the LDAP backend? -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek www: http://dstanek.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] external AuthN Identity Backend
Dave when federation is used, the user's group is stored in a mapping rule. So we do have a mechanism for storing group memberships without using LDAP or creating an entry for the user in the SQL backend. (The only time this is kinda not true is if we have a specific rule for each federated user, so that then each mapping rule is equivalent to an entry for each user). But usually we might expect many users to use the same mapping rule. Mapping rules should be usable for Kerberos logins. I dont know if the current code does have this ability or not, but if it doesn't, then it should be re-engineered to. (it was always in my design that all remote logins should have a mapping capability) regards David On 16/10/2014 19:15, Dave Walker wrote: > Hi, > > Currently we have two ways of doing Identity Auth backends, these are > sql and ldap. > > The SQL backend is the default and is for situations where Keyston is > the canonical Identity provider with username / password being > directly compared to the Keystone database. > > LDAP is the current option if Keystone isn't the canonical Identity > provider and passes the username and password to an LDAP server for > comparison and retrieves the groups. > > For a few releases we have supported External auth (or Kerberos), > where we authenticate the user at the edge and trust the REMOTE_USER > is valid. In these situations Keystone doesn't require the Username > or Password to be valid. > > Particularly in Kerberos situations, no password is used to > successfully authenticate at the edge. This works well, but LDAP > cannot be used as no password is passed through. The other option is > SQL, but that then requires a user to be created in Keystone first. > > We do not seem to cover the situation where Identity is provided by an > external mechanism. The only system currently available is Federation > via SAML, which isn't always the best fit. > > Therefore, I'd like to suggest the introduction of a third backend. > This would be the external identity provider. This would seem to be > pretty simple, as the current checks would simply return success (as > we trust auth at the edge), and not store user_id in the database, but > generate it at runtime. > > The issue I have, is that this doesn't cover Group membership. > > So, am I a: > - Barking totally up the wrong tree > - Add support to the current LDAP plugin to support external auth > (but still use LDAP for groups) > - Write a standalone external plugin, but then do what for Groups? I > would be reasonably happy to just have 1:1 mapping of users to groups. > > Does this make sense? > > Thanks > > -- > Kind Regards, > Daviey Walker > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] external AuthN Identity Backend
Hi Steve, Thanks for your response. I am talking generally about the external auth support. One use case is Kerberos, but for the sake of argument this could quite easily be Apache Basic auth. The point is, we have current support for entrusting AuthN outside of Keystone. What I was trying to outline is that it seems that the current design of external auth is that keystone is not in the auth pipeline as we trust auth at the edge. However, we then do additional auth within keystone. With external auth and SQL, we drop the user provided username and password on the floor and use what was provided in REMOTE_USER (set by the webserver). Therefore the check as it currently stands in SQL is basically 'is this username in the database'. The LDAP plugin does Authentication via username and password, which is clearly not sufficient for external auth. The LDAP plugin could be made to check in a similar manner to SQL 'is this a valid user' - but this would seem to be a duplicate check, as we already did this at the edge. If the webserver granted access to keystone, the user has already been checked to see if they are a valid user. However, your response seems to suggest that current external auth should be formally deprecated? -- Kind Regards, Daviey Walker On 16 October 2014 19:28, Steve Martinelli wrote: > I think it depends on what you mean by 'external identity provider' - I > assume it's capable of speaking some sort of federation protocol. So I'd > rather explore adding more support for additional federation > protocols/standards, rather than making our own third backend. > > Steve > > Dave Walker wrote on 10/16/2014 02:15:07 PM: > >> From: Dave Walker >> To: OpenStack Development Mailing List >> , >> Date: 10/16/2014 02:20 PM >> Subject: [openstack-dev] [Keystone] external AuthN Identity Backend >> >> Hi, >> >> Currently we have two ways of doing Identity Auth backends, these are >> sql and ldap. >> >> The SQL backend is the default and is for situations where Keyston is >> the canonical Identity provider with username / password being >> directly compared to the Keystone database. >> >> LDAP is the current option if Keystone isn't the canonical Identity >> provider and passes the username and password to an LDAP server for >> comparison and retrieves the groups. >> >> For a few releases we have supported External auth (or Kerberos), >> where we authenticate the user at the edge and trust the REMOTE_USER >> is valid. In these situations Keystone doesn't require the Username >> or Password to be valid. >> >> Particularly in Kerberos situations, no password is used to >> successfully authenticate at the edge. This works well, but LDAP >> cannot be used as no password is passed through. The other option is >> SQL, but that then requires a user to be created in Keystone first. >> >> We do not seem to cover the situation where Identity is provided by an >> external mechanism. The only system currently available is Federation >> via SAML, which isn't always the best fit. >> >> Therefore, I'd like to suggest the introduction of a third backend. >> This would be the external identity provider. This would seem to be >> pretty simple, as the current checks would simply return success (as >> we trust auth at the edge), and not store user_id in the database, but >> generate it at runtime. >> >> The issue I have, is that this doesn't cover Group membership. >> >> So, am I a: >> - Barking totally up the wrong tree >> - Add support to the current LDAP plugin to support external auth >> (but still use LDAP for groups) >> - Write a standalone external plugin, but then do what for Groups? I >> would be reasonably happy to just have 1:1 mapping of users to groups. >> >> Does this make sense? >> >> Thanks >> >> -- >> Kind Regards, >> Daviey Walker >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] external AuthN Identity Backend
I think it depends on what you mean by 'external identity provider' - I assume it's capable of speaking some sort of federation protocol. So I'd rather explore adding more support for additional federation protocols/standards, rather than making our own third backend. Steve Dave Walker wrote on 10/16/2014 02:15:07 PM: > From: Dave Walker > To: OpenStack Development Mailing List , > Date: 10/16/2014 02:20 PM > Subject: [openstack-dev] [Keystone] external AuthN Identity Backend > > Hi, > > Currently we have two ways of doing Identity Auth backends, these are > sql and ldap. > > The SQL backend is the default and is for situations where Keyston is > the canonical Identity provider with username / password being > directly compared to the Keystone database. > > LDAP is the current option if Keystone isn't the canonical Identity > provider and passes the username and password to an LDAP server for > comparison and retrieves the groups. > > For a few releases we have supported External auth (or Kerberos), > where we authenticate the user at the edge and trust the REMOTE_USER > is valid. In these situations Keystone doesn't require the Username > or Password to be valid. > > Particularly in Kerberos situations, no password is used to > successfully authenticate at the edge. This works well, but LDAP > cannot be used as no password is passed through. The other option is > SQL, but that then requires a user to be created in Keystone first. > > We do not seem to cover the situation where Identity is provided by an > external mechanism. The only system currently available is Federation > via SAML, which isn't always the best fit. > > Therefore, I'd like to suggest the introduction of a third backend. > This would be the external identity provider. This would seem to be > pretty simple, as the current checks would simply return success (as > we trust auth at the edge), and not store user_id in the database, but > generate it at runtime. > > The issue I have, is that this doesn't cover Group membership. > > So, am I a: > - Barking totally up the wrong tree > - Add support to the current LDAP plugin to support external auth > (but still use LDAP for groups) > - Write a standalone external plugin, but then do what for Groups? I > would be reasonably happy to just have 1:1 mapping of users to groups. > > Does this make sense? > > Thanks > > -- > Kind Regards, > Daviey Walker > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] external AuthN Identity Backend
Hi, Currently we have two ways of doing Identity Auth backends, these are sql and ldap. The SQL backend is the default and is for situations where Keyston is the canonical Identity provider with username / password being directly compared to the Keystone database. LDAP is the current option if Keystone isn't the canonical Identity provider and passes the username and password to an LDAP server for comparison and retrieves the groups. For a few releases we have supported External auth (or Kerberos), where we authenticate the user at the edge and trust the REMOTE_USER is valid. In these situations Keystone doesn't require the Username or Password to be valid. Particularly in Kerberos situations, no password is used to successfully authenticate at the edge. This works well, but LDAP cannot be used as no password is passed through. The other option is SQL, but that then requires a user to be created in Keystone first. We do not seem to cover the situation where Identity is provided by an external mechanism. The only system currently available is Federation via SAML, which isn't always the best fit. Therefore, I'd like to suggest the introduction of a third backend. This would be the external identity provider. This would seem to be pretty simple, as the current checks would simply return success (as we trust auth at the edge), and not store user_id in the database, but generate it at runtime. The issue I have, is that this doesn't cover Group membership. So, am I a: - Barking totally up the wrong tree - Add support to the current LDAP plugin to support external auth (but still use LDAP for groups) - Write a standalone external plugin, but then do what for Groups? I would be reasonably happy to just have 1:1 mapping of users to groups. Does this make sense? Thanks -- Kind Regards, Daviey Walker ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
