On 10/16/2014 02:58 PM, David Chadwick 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)
I most certainly does, and can be extended to get additional env vars
from mod_lookup_identity as well.
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
