I'd also be happy to sponsor this work. Thanks,
Steve Martinelli OpenStack Keystone Core Marek Denis <[email protected]> wrote on 03/17/2015 06:28:58 PM: > From: Marek Denis <[email protected]> > To: <[email protected]> > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
