Open Stack

In my opinion you have got into this situation because your federation
trust model is essentially misguided. As I have been arguing since the
inception of federated Keystone, you should have rules for trusted IdPs
(already done), trusted attributes (not done), and then one set of
mapping rules that apply to all IdPs and all attributes (not done). If
you had followed this model (the one Kent originally implemented) you
would not be in this situation now.

Concerning the remote user ID, we can guarantee that it is always
globally unique by concatenating the IDP name with the IdP issued user
ID, so this wont cause a problem in mapping rules.

Concerning other identity attributes, there are two types:
- globally known and assigned attributes (such email address and other
LDAP ones) that have unique IDs regardless of the IDP that issued them -
the eduPerson schema attributes are of this type, so the mapping rules
for these are IDP independent, and the trusted IDP rules ensure that you
filter out untrusted ones
- locally issued attributes that mean different things to different
IDPs. In this case you need to concatenate the name of the IDP to the
attribute to make it globally unique, and then the mapping rules will
always apply. The trusted IDP rules will again filter these out or let
them pass.

So instead of fixing the model, you are adding more layers of complexity
to the implementation in order to fix conceptual errors in your
federation model.

Sadly yours

David


On 17/03/2015 22:28, Marek Denis wrote:
> 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,
>