Open Stack

On 10/16/2014 12:30 PM, Dave Walker wrote:
> Hi,
> 
> I think I considered the Federated plugin as a mismatch as it dealt
> with 'remote' auth rather than 'external' auth.  I thought it was for
> purely handling SSO / SAML2, and not being subordinate to auth with
> the webserver.
> 
> I'll dig into the federation plugin more, thanks.

There are some plans to be able to frontend the user/group lookup in
httpd like you ca do with external auth.  This is similar to the
federation approach.  I've written up some details here:

  https://blog-nkinder.rhcloud.com/?p=130

There is still work to do to tie in the mapping code from the
OS-FEDERATION extension, but I think the approach shows a lot of
promise.  Choose your auth module (mod_auth_kerb, mod_ssl, etc.) to set
REMOTE_USER, then use mod_lookup_identity to supply the user/group info
from LDAP.  This is an approach that should get some discussion time at
the Summit.

Thanks,
-NGK

> 
> --
> Kind Regards,
> Dave Walker
> 
> On 16 October 2014 19:58, David Chadwick <d.w.chadwick at kent.ac.uk> 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)
>>
>> 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
>>
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>