Action from last week - what do we do with anonymous requests when there is a filter which assumes metadata
Rod Widdowson
rdw at steadingsoftware.com
Fri Nov 8 11:37:04 EST 2013
I caused some confusion in last week's dev meeting last week while I was
wondering what to do what the metadata based filters would do for anonymous
requests.
The short answer is that in the absence of metadata (because there is no
attribute requester) we (currently) return FAIL and so return the most
restrictive result.
Consider the obvious case:
<AttributeFilterPolicy id="releaseTransientIdToAnyone">
<PolicyRequirementRule xsi:type="saml:AttributeRequesterInEntityGroup"
groupID="urn:example.org" />
<AttributeRule attributeID="eppn">
<PermitValueRule xsi:type="basic:ANY" />
</AttributeRule>
</AttributeFilterPolicy>
In this case the policy requirement rule returns "FAIL" (no metadata - so we
cannot make any sense) and so the rule is not applied.
Or the non-obvious case:
<AttributeFilterPolicy id="releaseTransientIdToAnyone">
<PolicyRequirementRule xsi:type=basic:ANY"/>
<AttributeRule attributeID="eppn">
<PermitValueRule xsi:type="saml:AttributeRequesterInEntityGroup"
groupID="urn:example.org" />
</AttributeRule>
</AttributeFilterPolicy>
Again the rule fails and so no values are release.
BUT in the negated case:
<AttributeFilterPolicy id="releaseTransientIdToAnyone">
<PolicyRequirementRule xsi:type="NOT">
<Basic xsi:type=saml:AttributeRequesterInEntityGroup"
groupID="urn:example.org" />
</PolicyRequirementRule>
<AttributeRule attributeID="eppn">
<PermitValueRule xsi:type="basic:ANY" />
</AttributeRule>
</AttributeFilterPolicy>
The rule fails. Because this was failure (not returning "true" or "false")
we also release no values, if the rule has said "false" we *would* have
released values.
The same goes for the deny rules (which are a brain melter by the time you
have negation).
Scott (I think it was) made the case that a rule like
"AttributeRequesterInEntityGroup" should just return FALSE (not fail) in the
case where there is no AttributeRequester. This *only* make a difference in
the negated and deny cases. What do we think should happen?
I'll also add that I suggested that we might not be handling the third state
properly during filtering - that is to say doing it at an inappropriate
level by failing everything if one policy rule failed. This is definitely
not the case. Failure of any filter is propagated up to the right level
only.
Rod
More information about the dev
mailing list