Open Stack

This is more in line with my argument that we should not have 100
different end points and mapping rules for a federation of 100 IdPs, but
rather one end point and one mapping for all trusted IdPs. But I still
think that in order to make this design waterproof we need a trusted
attributes policy as well, to ensure that:
i) all untrusted and unthought off attributes are discarded before the
mapping takes place, so that mistakes are not inadvertently made in the
mapping rules
ii) all attribute types are checked to make sure that they are all
globally unique before mapping takes place

regards

David

On 18/03/2015 17:54, Yee, Guang wrote:
> I think we can create a mapping which restricts which IdP it is
> applicable. When playing around with K2K, I've experimented with
> multiple IdPs. I basically chained the IdPs in shibboleth2.xml like
> this
> 
> <MetadataProvider type="Chaining"> <MetadataProvider type="XML"
> file="/etc/keystone/acme_idp_metadata.xml"/> <MetadataProvider
> type="XML" file="/etc/keystone/beta_idp_metadata.xml"/> 
> </MetadataProvider>
> 
> And with a mapping intended for Acme IdP, we can ensure that only
> Acme users can map to group '1234567890'.
> 
> { "mapping": { "rules": [ { "local": [ { "user": { "name": "{0}" } 
> }, { "group": { "id": "1234567890" } } ], "remote": [ { "type":
> "openstack_user" }, { "type": "Shib-Identity-Provider", "any_one_of":
> [ "https://acme.com/v3/OS-FEDERATION/saml2/idp" ] } ] } ] } }
> 
> Shibboleth do convey the "Shib-Identity-Provider" attribute in the
> request environment. With this mechanism we should be able to create
> a rule for multiple IdPs as well.
> 
> 
> Guang
> 
> 
> -----Original Message----- From: David Chadwick
> [mailto:d.w.chadwick at kent.ac.uk] Sent: Wednesday, March 18, 2015 2:41
> AM To: openstack-dev at lists.openstack.org Subject: Re: [openstack-dev]
> [Keystone][FFE] - IdP ID (remote_id) registration and validation
> 
> 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,
>> 
> 
> __________________________________________________________________________
>
> 
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
> 
> __________________________________________________________________________
>
> 
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
>