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 <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
