<font size=2 face="sans-serif">I'd also be happy to sponsor this work.</font>
<br><font size=2 face="sans-serif"><br>
Thanks,<br>
<br>
Steve Martinelli<br>
OpenStack Keystone Core</font>
<br>
<br><tt><font size=2>Marek Denis <marek.denis@cern.ch> wrote on 03/17/2015
06:28:58 PM:<br>
<br>
> From: Marek Denis <marek.denis@cern.ch></font></tt>
<br><tt><font size=2>> To: <openstack-dev@lists.openstack.org></font></tt>
<br><tt><font size=2>> Date: 03/17/2015 06:35 PM</font></tt>
<br><tt><font size=2>> Subject: [openstack-dev] [Keystone][FFE] - IdP
ID (remote_id) <br>
> registration and validation</font></tt>
<br><tt><font size=2>> <br>
> Hello,<br>
> <br>
> One very important feature that we have been working on in the Kilo
<br>
> development cycle is management of remote_id attributes tied to Identity
<br>
> Providers in keystone.<br>
> <br>
> This work is crucial for:<br>
> <br>
> -  Secure OpenStack identity federation configuration. User is
required <br>
> to specify what Identity Provider (IdP) issues an assertion as well
as <br>
> what protocol (s)he wishes to use (typically it would be SAML2 or
OpenId <br>
> Connect). Based on that knowledge (arbitrarily specified by a user),
<br>
> keystone fetches mapping rules configured for {IdP, protocol} pair
and <br>
> applies it on the assertion. As an effect a set of groups is returned,
<br>
> and by membership of those dynamically assigned groups (and later
<br>
> roles), an ephemeral user is being granted access to certain OpenStack
<br>
> resources. Without remote_id attributes, a user, can arbitrarily choose
<br>
> pair {Identity Provider, protocol} without respect of issuing Identity
<br>
> Provider. This may lead to a situation where Identity Provider X issues
<br>
> an assertion, but user chooses mapping ruleset dedicated for Identity
<br>
> Provider Y, effectively being granted improper groups (roles). As
part <br>
> of various federation protocols, every Identity Provider issues an
<br>
> identifier allowing trusting peers (Keystone  servers in this
case) to <br>
> reliably identify issuer of the assertion. That said, remote_id <br>
> attributes allow cloud administrators to match assertions with Identity
<br>
> Providers objects configured in keystone (i.e. situation depicted
above <br>
> would not happen, as keystone object Identity Provider Y would accept
<br>
> assertions issued by Identity Provider Y only).<br>
> <br>
> - WebSSO implementation - a highly requested feature that allows to
use <br>
> federation in OpenStack via web browsers, especially Horizon. Without
<br>
> remote_ids server (keystone) is not able to distinguish what maping
rule <br>
> set should be used for transforming assertion into set of local <br>
> attributes (groups, users etc).<br>
> <br>
> <br>
> Status of the work:<br>
> <br>
> So far we have implemented and merged feature where each Identity
<br>
> Provider object can have one remote_id specified. However, there have
<br>
> been few request for stakeholders for ability to configure multiple
<br>
> remote_id attributes per Identity Provider objects. This is extremely
<br>
> useful in configuring federations where 10s or 100s of Identity Provider
<br>
> work within one federation and where one mapping ruleset is used among
<br>
> them.<br>
> This has been discussed and widely accepted during Keystone mid cycle
<br>
> meetup in January 2015. The first version of the implementation was
<br>
> proposed on Febrary 2nd. During the implementation process we discovered
<br>
> the bug (</font></tt><a href="https://bugs.launchpad.net/keystone/+bug/1426334"><tt><font size=2>https://bugs.launchpad.net/keystone/+bug/1426334</font></tt></a><tt><font size=2>)
that was <br>
> blocking further work. Fixing it took reasonably big manpower and
<br>
> significantly delayed delivery process of the main feature. Eventually,
<br>
> the bug was fixed and now we are ready to get final reviews (mind,
the <br>
> patch was already reviewed and all the comments and issues were <br>
> constantly being addressed) and hopefully get landed in the Kilo release.<br>
> <br>
> Specification link: <br>
> </font></tt><a href="https://github.com/openstack/keystone-specs/blob/master/specs/kilo/"><tt><font size=2>https://github.com/openstack/keystone-specs/blob/master/specs/kilo/</font></tt></a><tt><font size=2><br>
> idp-id-registration.rst<br>
> Implementation link: </font></tt><a href=https://review.openstack.org/#/c/152156/><tt><font size=2>https://review.openstack.org/#/c/152156/</font></tt></a><tt><font size=2><br>
> <br>
> I hereby ask for exceptional accepting the provided work in the Kilo
<br>
> release cycle.<br>
> <br>
> With kind regards,<br>
> <br>
> -- <br>
> Marek Denis<br>
> Keystone Core member<br>
> <br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<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>