Open Stack

This is a good workaround to allow the authentication on the IdP but with the new websso is problematic because
you do not know which mapping to use but you have the "Shib-Identity-Provider". With the new information
the entityIDs are associated with the keystone IdP so it is easy to find the right one. With this approach
you have to analyse all the mapping and select the first that can apply.

Marco


On Wed, Mar 18, 2015 at 05:54:36PM +0000, 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5483 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150319/376b30aa/attachment.bin>