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 <em...@daviey.com> wrote on 10/16/2014 02:15:07 PM:

> From: Dave Walker <em...@daviey.com>

> To: OpenStack Development Mailing List <openstack-dev@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@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

Reply via email to