RequestedAttributes in SP metada

[Nick Amon]

" Unless you control the SPs, you are not going to get people to give you that information in the general case. Metadata rarely contains that information. If you control the metadata, you could of course manually maintain it, but that defeats the purpose of metadata really."

Take for example SSOing on to AWS management console.  The relevant SP metadata provided by Amazon is the following:

    <md:AssertionConsumerService index="1" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://signin.aws.amazon.com/saml">
      <ServiceName xml:lang="en">AWS Management Console Single Sign-On</ServiceName>
      <RequestedAttribute isRequired="true" name="https://aws.amazon.com/SAML/Attributes/Role" FriendlyName="RoleEntitlement"/>
      <RequestedAttribute isRequired="true" name="https://aws.amazon.com/SAML/Attributes/RoleSessionName" FriendlyName="RoleSessionName"/>
      <RequestedAttribute isRequired="false" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1" FriendlyName="eduPersonAffiliation"/>

Now, I would like our UI to show a view that allows the administrator to map for example, RoleSessioName to a user attribute in our product, let's say role.  Therefore when a user attempts to SSO into AWS from our product, our AttributeResolver will identify the user that has authenticated, map the AWS SP requested attributre RoleSessionName to the user's role and release it in the returned assertion.  

In our model, the admin has complete control of what attributes will be released about the user and does not require user consent.  We would like to support such a feature for all SPs, i.e. specify in the metadata what attributes you require and then our product will enable the admin to configure what values for these attributes are released for the user requesting the SSO.

" No, not really. Just generate the filter policy from the database."
The issue with that is that if we have many SPs, each time an existing or new SP requires a new attribute, I'd have to regenerate the filter policy file from the database.   Same for the attribute-resolver.xml, if a new attribute is required for an SP, I'd have to regenerate the complete file to add the new attribute.  This is based on my assumption that there is only one of  each attribute-resolver and attribute-filter policy files.  If I have a 100 SPs configured, to regenerate the file, I'd have to extract from the DB the required attributes for all SPs just to add or update 1 attribute.


Thanks,


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Monday, December 30, 2013 10:40 AM
To: Shib Users
Subject: Re: RequestedAttributes in SP metada

On 12/30/13, 10:30 AM, "Nick Amon" <namon at xceedium.com> wrote:
>
>Thinking it through further, this shouldn't be an issue for us.  We 
>plan to internally parse the SP's metadata so that we can determine 
>what attributes it is requesting and allowing the administrator of our 
>product in the UI to map these requested attributes to attributes 
>stored in our product.

Unless you control the SPs, you are not going to get people to give you that information in the general case. Metadata rarely contains that information. If you control the metadata, you could of course manually maintain it, but that defeats the purpose of metadata really.

>  Since the attributes that will be released by the Idp will differ 
>based on the SP and the policy configured in our UI (ultimately store 
>in DB table), defining them statically in the attribute-resolver.xml 
>file doesn't seem to be the right approach to take.

The resolver is not designed to selectively resolve data. It resolves everything by design. What you're talking about is filtering.

>  I was considering developing my own AtttriubteResolver implementation 
>that would read the attributes to be released to the SP from the 
>database and then configure the Idp policy to simply release all 
>attributes to the SP.  Is this the right approach to take?

No, not really. Just generate the filter policy from the database.

>Also, it appears from your responses and other messages in the dev 
>list, that the 3.0 version of the Idp that is being developed may 
>internally work differently from the current stable 2.4 version.  When 
>do you plan to release this?  I wonder if it makes sense for me to 
>begin my development against the 3.0 codebase or the 2.4 codebase.

That depends on your goals, but the APIs are not stable yet and won't be for some months yet. Nor is anything changing in this area. We are not explicitly supporting selective resolution except through the addition of criteria for suppressing specific data connectors.

>Also, I noticed that only the 2.5 version of the Idp supports 
>monitoring a directory for new metadata.

You are confusing the SP with the IdP. There is no 2.5 IdP nor is that feature in of the Java code.

> Would it be easy for me to port support for this back to 2.4?

Nothing to port, it would be a new plugin.

>  Or better yet, is there a recommended way for me to trigger the Idp 
>to refresh its metadata rather than monitoring file access times?  
>Since the configuration of the SP metadata is driven by our product, I 
>would ideally like to send a request to the Idp alerting it to refresh the
>metadata for the SP identified in the request.   Is there an existing or
>better way to do this now?

Not right now. There's no programmatic access to it. There will be in V3, and I think Brent ported the change to allow that on the metadata API in V2, but I could be wrong, and there's nothing exposing that API right now.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net