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
