Open Stack

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