Open Stack

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