Default deny policy in attribute-policy.xml does not work
Description
Environment
CentOS 5.5 / Shibboleth 2.3.1 from openSUSE repos
Activity
Scott Cantor December 17, 2010 at 2:38 PM
Closing after release.
Scott Cantor October 20, 2010 at 12:24 PM
http://svn.middleware.georgetown.edu/view/cpp-sp?view=rev&revision=3348
Sorry for being obtuse, I understand what you meant now. Thanks for debugging this for me.
Takeshi Nishimura October 4, 2010 at 9:39 PMEdited
Thanks for your reply. OK, I'll try.
Attached files are my attribute-map.xml and attribute-policy.xml (more simplified than I used before).
Input data from IdP:
entitlement: urn:mace:dir:entitlement:common-lib-terms
ou: Test Unit1
displayName: test_displayname
Expected result (passed to web application):
entitlement: NULL
ou: Test Unit1
displayName: NULL
Actual result:
entitlement: NULL
ou: NULL
displayName: test_displayname
shibd.log:
2010-10-05 11:29:44 DEBUG Shibboleth.AttributeFilter [2]: filtering 3 attribute(s) from (https://...)
2010-10-05 11:29:44 DEBUG Shibboleth.AttributeFilter [2]: applying filtering rule(s) for attribute (entitlement) from (https://...)
2010-10-05 11:29:44 WARN Shibboleth.AttributeFilter [2]: removed value at position (0) of attribute (entitlement) from (https://...)
2010-10-05 11:29:44 WARN Shibboleth.AttributeFilter [2]: no rule found, removing attribute (displayName) from (https://...)
2010-10-05 11:29:44 DEBUG Shibboleth.AttributeFilter [2]: applying filtering rule(s) for attribute (ou) from (https://...)
2010-10-05 11:29:44 WARN Shibboleth.AttributeFilter [2]: no values left, removing attribute (entitlement) from (https://...)
Please inform me if you need more information.
Scott Cantor October 4, 2010 at 9:05 AM
I'm afraid I don't understand the complaint, so please provide a sample of what the input data is, what the expected result is, and what the actual result is. Use explicit attributes and values in your example, and attach or include the entire policy in use.
If you don't have attributeID="*" rule and have DenyValueRule, you may see wrong attributes permitted/denied to be passed to the web application.
My patch for 2.3.1 is attached.
The following is an example attribute-policy.xml. Obviously it permits none, but the web application receives exact two attributes other than "o" and "entitlement". The exact name of 2 attributes depend on the environment.
<afp:AttributeFilterPolicyGroup
xmlns="urn:mace:shibboleth:2.0:afp:mf:basic"
xmlns:basic="urn:mace:shibboleth:2.0:afp:mf:basic"
xmlns:afp="urn:mace:shibboleth:2.0:afp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<afp:AttributeFilterPolicy>
<afp:PolicyRequirementRule xsi:type="ANY"/>
<afp:AttributeRule attributeID="o">
<afp:DenyValueRule xsi:type="ANY"/>
</afp:AttributeRule>
<afp:AttributeRule attributeID="entitlement">
<afp:PermitValueRule xsi:type="AttributeValueString"
value="urn:example:dir:entitlement:test01"/>
</afp:AttributeRule>
</afp:AttributeFilterPolicy>
</afp:AttributeFilterPolicyGroup>
Furthermore, in the worst case, if you add PermitValueRule for two arbitrary attributes the SP receives, you'll find they are mistakenly NULL.