Open Stack

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>