Open Stack

Hi Steve,

Thanks for your response.  I am talking generally about the external
auth support.  One use case is Kerberos, but for the sake of argument
this could quite easily be Apache Basic auth.  The point is, we have
current support for entrusting AuthN outside of Keystone.

What I was trying to outline is that it seems that the current design
of external auth is that keystone is not in the auth pipeline as we
trust auth at the edge.  However, we then do additional auth within
keystone.

With external auth and SQL, we drop the user provided username and
password on the floor and use what was provided in REMOTE_USER (set by
the webserver).

Therefore the check as it currently stands in SQL is basically 'is
this username in the database'.  The LDAP plugin does Authentication
via username and password, which is clearly not sufficient for
external auth.  The LDAP plugin could be made to check in a similar
manner to SQL 'is this a valid user' - but this would seem to be a
duplicate check, as we already did this at the edge.

If the webserver granted access to keystone, the user has already been
checked to see if they are a valid user.  However, your response seems
to suggest that current external auth should be formally deprecated?

--
Kind Regards,
Daviey Walker

On 16 October 2014 19:28, Steve Martinelli <stevemar at ca.ibm.com> wrote:
> I think it depends on what you mean by 'external identity provider' - I
> assume it's capable of speaking some sort of federation protocol. So I'd
> rather explore adding more support for additional federation
> protocols/standards, rather than making our own third backend.
>
> Steve
>
> Dave Walker <email at daviey.com> wrote on 10/16/2014 02:15:07 PM:
>
>> From: Dave Walker <email at daviey.com>
>> To: OpenStack Development Mailing List
>> <openstack-dev at lists.openstack.org>,
>> Date: 10/16/2014 02:20 PM
>> Subject: [openstack-dev] [Keystone] external AuthN Identity Backend
>>
>> 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
>>