Open Stack

I'd also be happy to sponsor this work.

Thanks,

Steve Martinelli
OpenStack Keystone Core

Marek Denis <marek.denis at cern.ch> wrote on 03/17/2015 06:28:58 PM:

> From: Marek Denis <marek.denis at cern.ch>
> To: <openstack-dev at lists.openstack.org>
> Date: 03/17/2015 06:35 PM
> Subject: [openstack-dev] [Keystone][FFE] - IdP ID (remote_id) 
> registration and validation
> 
> 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
> 
> 
__________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150317/498206de/attachment.html>