<font size=2 face="sans-serif">I think it depends on what you mean by
'</font><tt><font size=2>external identity provider</font></tt><font size=2 face="sans-serif">'
- 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. <br>
</font>
<br><font size=2 face="sans-serif">Steve</font>
<br>
<br><tt><font size=2>Dave Walker <email@daviey.com> wrote on 10/16/2014
02:15:07 PM:<br>
<br>
> From: Dave Walker <email@daviey.com></font></tt>
<br><tt><font size=2>> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>,
</font></tt>
<br><tt><font size=2>> Date: 10/16/2014 02:20 PM</font></tt>
<br><tt><font size=2>> Subject: [openstack-dev] [Keystone] external
AuthN Identity Backend</font></tt>
<br><tt><font size=2>> <br>
> Hi,<br>
> <br>
> Currently we have two ways of doing Identity Auth backends, these
are<br>
> sql and ldap.<br>
> <br>
> The SQL backend is the default and is for situations where Keyston
is<br>
> the canonical Identity provider with username / password being<br>
> directly compared to the Keystone database.<br>
> <br>
> LDAP is the current option if Keystone isn't the canonical Identity<br>
> provider and passes the username and password to an LDAP server for<br>
> comparison and retrieves the groups.<br>
> <br>
> For a few releases we have supported External auth (or Kerberos),<br>
> where we authenticate the user at the edge and trust the REMOTE_USER<br>
> is valid.  In these situations Keystone doesn't require the Username<br>
> or Password to be valid.<br>
> <br>
> Particularly in Kerberos situations, no password is used to<br>
> successfully authenticate at the edge.  This works well, but
LDAP<br>
> cannot be used as no password is passed through.  The other option
is<br>
> SQL, but that then requires a user to be created in Keystone first.<br>
> <br>
> We do not seem to cover the situation where Identity is provided by
an<br>
> external mechanism.  The only system currently available is Federation<br>
> via SAML, which isn't always the best fit.<br>
> <br>
> Therefore, I'd like to suggest the introduction of a third backend.<br>
> This would be the external identity provider.  This would seem
to be<br>
> pretty simple, as the current checks would simply return success (as<br>
> we trust auth at the edge), and not store user_id in the database,
but<br>
> generate it at runtime.<br>
> <br>
> The issue I have, is that this doesn't cover Group membership.<br>
> <br>
> So, am I a:<br>
>  - Barking totally up the wrong tree<br>
>  - Add support to the current LDAP plugin to support external
auth<br>
> (but still use LDAP for groups)<br>
>  - Write a standalone external plugin, but then do what for Groups?
 I<br>
> would be reasonably happy to just have 1:1 mapping of users to groups.<br>
> <br>
> Does this make sense?<br>
> <br>
> Thanks<br>
> <br>
> --<br>
> Kind Regards,<br>
> Daviey Walker<br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> <br>
</font></tt>