Simple Attribute aggregation testing and improvement suggestions
Description
Environment
Activity
Scott Cantor December 17, 2010 at 2:39 PM
Closing after release.
Former user January 21, 2010 at 4:39 AM(edited)
Thanks Scott!
I've tested rev 3220 and confirm this is fixed.
2010-01-21 10:35:48 DEBUG Shibboleth.AttributeResolver.Query [1] resolveAttributes: found AttributeStatement in input to new session, skipping query
2010-01-21 10:35:48 DEBUG Shibboleth.AttributeResolver.SimpleAggregation [1] resolveAttributes: using input attribute (Shib-SwissEP-UniqueID) as identifier for queries
2010-01-21 10:35:48 DEBUG Shibboleth.AttributeResolver.SimpleAggregation [1] resolveAttributes: skipping previously queried attribute source (https://kiwi.unil.ch/idp/shibboleth)
Scott Cantor January 20, 2010 at 3:16 PM
Former user January 19, 2010 at 9:47 AM(edited)
The SimpleAggregation resolver still queries a statically configured entityID even if this entityID is the one that issued the authentication+attribute assertion. Given the following config:
<AttributeResolver type="Chaining">
<AttributeResolver type="Query"/>
<AttributeResolver type="SimpleAggregation" attributeId="Shib-SwissEP-UniqueID" format="urn:oid:2.16.756.1.2.5.1.1.1">
<Entity>https://kiwi.unil.ch/idp/shibboleth</Entity>
</AttributeResolver>
</AttributeResolver>
I see in the log:
2010-01-18 15:23:35 DEBUG Shibboleth.SSO.SAML2 [34]: extracting pushed attributes...
[...]
2010-01-18 15:23:35 DEBUG Shibboleth.AttributeFilter [34]: filtering 17 attribute(s) from (https://kiwi.unil.ch/idp/shibboleth)
[...]
2010-01-18 15:23:35 DEBUG Shibboleth.SSO.SAML2 [34]: resolving attributes...
2010-01-18 15:23:35 DEBUG Shibboleth.AttributeResolver.Query [34] resolveAttributes: found AttributeStatement in input to new session, skipping query
2010-01-18 15:23:35 DEBUG Shibboleth.AttributeResolver.SimpleAggregation [34] resolveAttributes: using input attribute (Shib-SwissEP-UniqueID) as identifier for queries
2010-01-18 15:23:35 DEBUG Shibboleth.AttributeResolver.SimpleAggregation [34] resolveAttributes: issuing SAML query to (https://kiwi.unil.ch/idp/shibboleth)
Scott Cantor June 23, 2009 at 12:47 PM
Closing after releases.
I did some testing work regarding the newly implemented attribute aggregation for 2.2. The main conclusion is that everything seems to work fine 🙂
I was testing with an SP compiled from SVN sources and two 2.1 IdPs and a 1.3 IdP the following cases:
Statically configured entityId in shibboleth2.xml to fetch more attributes from another IdP (with correct or non existing entityID)
Case where the attribute that is used as nameId is filtered out
Two entityIDs configured for aggregation (with correct or non existing entityId)
One statically configured entityId and one entityId coming via a refrenced attribute (with correct or non existing entityId)
Two IdPs contained in referenced attribute (with correct or non existing entityId)
Statically configured the same entityID twice
Statically configured entityID which is also contained in referenced attribute
In all cases things seem to work as expected and as it makes sense in my opinion. So, good job and thank you for that very promising new feature 🙂
I nevertheless have two minor suggestions for improvements:
Attribute deduplication:
I'm not sure how relevant this actually would be in a real use case but having multiple attribute sources queried can result in duplicate attribute values that are provided to applications by the SP and are also used SP internally. I don't see a reason why it could make sense to have multiple duplicate values but maybe I haven't thought hard enough about this 🙂 Having the same values for an attribute multiple times may be confusing and cause unnecessary computation work within the SP as well as potential applications using the attributes.
Prevent multiple queries to same IdP:
It can happen that the same IdP is queried multiple times because of attribute aggregation. This can happen if a (dumb) SP admin statically configures the same entityID multiple times in shibboleth2.xml or if one entityID is configured there and the same entityID comes via a referenced attribute. In both cases the SP will query this IdP twice altough this makes (in my opinion) little sense. So, this probably could be optimized.