Open Stack

Hello,

One very important feature that we have been working on in the Kilo 
development cycle is management of remote_id attributes tied to Identity 
Providers in keystone.

This work is crucial for:

-  Secure OpenStack identity federation configuration. User is required 
to specify what Identity Provider (IdP) issues an assertion as well as 
what protocol (s)he wishes to use (typically it would be SAML2 or OpenId 
Connect). Based on that knowledge (arbitrarily specified by a user), 
keystone fetches mapping rules configured for {IdP, protocol} pair and 
applies it on the assertion. As an effect a set of groups is returned, 
and by membership of those dynamically assigned groups (and later 
roles), an ephemeral user is being granted access to certain OpenStack 
resources. Without remote_id attributes, a user, can arbitrarily choose 
pair {Identity Provider, protocol} without respect of issuing Identity 
Provider. This may lead to a situation where Identity Provider X issues 
an assertion, but user chooses mapping ruleset dedicated for Identity 
Provider Y, effectively being granted improper groups (roles). As part 
of various federation protocols, every Identity Provider issues an 
identifier allowing trusting peers (Keystone  servers in this case) to 
reliably identify issuer of the assertion. That said, remote_id 
attributes allow cloud administrators to match assertions with Identity 
Providers objects configured in keystone (i.e. situation depicted above 
would not happen, as keystone object Identity Provider Y would accept 
assertions issued by Identity Provider Y only).

- WebSSO implementation - a highly requested feature that allows to use 
federation in OpenStack via web browsers, especially Horizon. Without 
remote_ids server (keystone) is not able to distinguish what maping rule 
set should be used for transforming assertion into set of local 
attributes (groups, users etc).


Status of the work:

So far we have implemented and merged feature where each Identity 
Provider object can have one remote_id specified. However, there have 
been few request for stakeholders for ability to configure multiple 
remote_id attributes per Identity Provider objects. This is extremely 
useful in configuring federations where 10s or 100s of Identity Provider 
work within one federation and where one mapping ruleset is used among 
them.
This has been discussed and widely accepted during Keystone mid cycle 
meetup in January 2015. The first version of the implementation was 
proposed on Febrary 2nd. During the implementation process we discovered 
the bug (https://bugs.launchpad.net/keystone/+bug/1426334) that was 
blocking further work. Fixing it took reasonably big manpower and 
significantly delayed delivery process of the main feature. Eventually, 
the bug was fixed and now we are ready to get final reviews (mind, the 
patch was already reviewed and all the comments and issues were 
constantly being addressed) and hopefully get landed in the Kilo release.

Specification link: 
https://github.com/openstack/keystone-specs/blob/master/specs/kilo/idp-id-registration.rst
Implementation link: https://review.openstack.org/#/c/152156/

I hereby ask for exceptional accepting the provided work in the Kilo 
release cycle.

With kind regards,

-- 
Marek Denis
Keystone Core member