RequestedAttributes in SP metada

[Nick Amon]

"Specific attributes ... were not requested" means that the authentication request from the SP does not contain a list of attributes. This is normal, which is why the message is only at DEBUG level. It's not an error."

I'm confused by this statement the SSOProfileHandler.completeAuthentication eventually calls ShibbolethSAML2AttributeAuthority->getAttributes which as the following code:
        // get attributes from the message
        Set<String> queryAttributeIds = getAttributeIds(requestContext.getInboundSAMLMessage());
        requestedAttributes.addAll(queryAttributeIds);

        // get attributes from metadata
        Set<String> metadataAttributeIds = getAttribtueIds(requestContext.getPeerEntityMetadata());
        requestedAttributes.addAll(metadataAttributeIds);

My understanding of reading this is that the AttributeResolver should get the requested attributes both from the incoming request and the metadata.  I am assuming that further in the resolution process in the ShibbolethSAML2AttributeAuthority->resolveAttributes

        Collection<String> attributeIDs = resolutionContext.getAttributeRequestContext().getRequestedAttributesIds();
        Map<String, BaseAttribute> resolvedAttributes = new HashMap<String, BaseAttribute>();

        // if no attributes requested, then resolve everything
        if (attributeIDs == null || attributeIDs.isEmpty()) {
            log.debug("Specific attributes for principal {} were not requested, resolving all attributes.",
                    resolutionContext.getAttributeRequestContext().getPrincipalName());
            attributeIDs = getAttributeDefinitions().keySet();
        }

That the getRequestedAttributesIds  method returns the requested attributes retrieved from the incoming request and metadata.  Am I mistaken?   My understanding of reading the code is that it will first filter the attributes by what is requested in the incoming request and metadata and also by the filter policy configured in the IdP.

Thanks,

Nicholas

From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Ian Young
Sent: Thursday, December 26, 2013 6:48 AM
To: Shib Users
Subject: Re: RequestedAttributes in SP metada


On 24 Dec 2013, at 20:45, Nick Amon <namon at xceedium.com<mailto:namon at xceedium.com>> wrote:


After successful authentication, I noticed this in the logs:
20:20:51.810 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:275] - Specific attributes for principal XXX were not requested, resolving all attributes.

As if the AttributeResolver did not recognize that the SP's RequestedAttribute.

That's not what the message means.

"Specific attributes ... were not requested" means that the authentication request from the SP does not contain a list of attributes. This is normal, which is why the message is only at DEBUG level. It's not an error.

The consequence is that the IdP will resolve all attributes it is configured for, and then filter them according to the configured attribute release policy. Again, this is normal behaviour. You control the attributes you want the IdP to release to a given SP by changing the policy, not in general by changing the metadata.

                -- Ian


Original Message:

Hi,

The Amazon SP metadata originally contained the following:

<md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAssertionsSigned="true">
   <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"/>
</md:AssertionConsumerService>

After successful authentication, I noticed this in the logs:
20:20:51.810 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:275] - Specific attributes for principal XXX were not requested, resolving all attributes.

As if the AttributeResolver did not recognize that the SP's RequestedAttribute.  I thought that this was caused by AWS not conforming to the SAML standard since I couldn't find an example of including RequestedAttribute elements inside AssertionConsumerService elements.

I thus modified the metadata to conform to the standard as I have understood it:
  <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAssertionsSigned="true">
    <md:AttributeConsumingService index="1">
      <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"/>
    </md:AttributeConsumingService>
....
This didn't work either; I received the exact same message.  I therefore looked at the code and it appears it is looking for requested attributes in the AttributeAuthorityDescriptor element.  What am I missing?  I would like the IdP to recognize the attributes requested by the SP, ideally in the AssertionConsumerService element so I don't have to modify the provided metadata, or at the least AttributeConsumingService.

Thanks,

Nicholas


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20131230/a71a5b56/attachment.html