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 <d.w.chadw...@kent.ac.uk> 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
