RequestedAttributes in SP metada

[Cantor, Scott]

On 12/30/13, 11:22 AM, "Nick Amon" <namon at xceedium.com> wrote:

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

Yes, and that's an isolated case. Believe me or don't, I'm just telling
you the fact of the matter.

>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.

And we're saying, again, that in Shibboleth that's a filter issue.

>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.

When you say the words "what values are released", that is a filter
behavior, not a resolver one.

>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.

That's entirely expected and works fine. You seem to be under the
impression that attribute information actually changes, but tt does not,
really ever. The inertia involved in application behavior is such that
attribute requirements for an SP rarely change unless the SP is a proxy to
many discrete applications. So this is more about adding SPs than changing
them.

>   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.

Yes. That is how it's meant to work. The resolver will not do what you
want, that's all I can tell you.

-- Scott