Dear all,
As promised during last confcall, please find below a summary of the
impact of attribute predicate assertions on XACML for the simple
solution we had in mind. All discussion is welcome, in particular
about the questions at the end of the email.
Best regards,
Greg
General Principle
- The policy is specified in terms of dedicated, only locally
meaningful, boolean attributes.
- Some component (PEP, PIP, or Context Handler -- see discussion
below) knows the mapping from local attributeIDs to predicates
over globally meaningful attributeIDs.
e.g., urn:mypolicy:underage -> urn:unitednations:birthdate
< 1992/11/09
- When a local attribute is found missing, a SAML assertion
request is generated for the corresponding predicate (either
from the requestor, or directly from the IDP/issuer).
- When a SAML assertion for the predicate comes in, the
following checks are performed:
- Does the signature support the predicate in the assertion?
- Is the predicate in the assertion "the same" as the
predicate in the request. The easiest is probably to test by
string equality after canonicalization.
About the choice of which component should do the mapping local
attributeIDs -> predicates:
- PEP: Best placed if missing attributes are reported through
status detail in an Indeterminate response, as described in
XACML 2.0 spec section 7.15.3. It can then intercept
Indeterminate responses with missing attributes, call out to the
user/IDP with an assertion request for the corresponding
predicate, verify the incoming SAML assertion, and generate a
new XACML request context with the local attribute set to true.
- PIP: Best placed if the PDP actively queries missing
attributes from the PIP. What is the format of the communication
between PDP and PIP for attribute queries and responses,
however? Is it standardized?
- Context Handler: Is well placed in the sense that both missing
attribute fetching mechanisms (via Indeterminate response or via
PIP) pass through the Context Handler, but is poorly placed in
the sense that it takes an XACML request context as input. If
the Context Handler is responsible for handling incoming SAML
assertions, then the schema of the XACML request context needs
to be changed so that it can carry SAML assertions, rather than
just attribute values.
The main advantage of this simple approach is that the impact on
XACML schema/architecture is minimal. The main disadvantage is that
it puts the burden on the policy author to define the static mapping
between local attributes and predicates over global attributes.
Example
XACML policy:
<Rule Effect="Permit" RuleId="#rule1">
<Target> ... </Target>
<Condition>
<Apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:boolean-one-and-only">
<SubjectAttributeDesignator
AttributeId="urn:mypolicy:local:isoverage" Issuer=
"http://www.trustedidp.com"
DataType=
"http://www.w3.org/2001/XMLSchema#boolean"
MustBePresent="true"/>
</Apply>
</Condition>
</Rule>
The PEP/PIP/Context Handler knows that urn:mypolicy:local:isoverage
corresponds to a predicate:
<Apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-less-than">
<Apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-one-and-only">
<SubjectAttributeDesignator AttributeId=
"http://www.w3.org/2006/vcard/ns#bday"
Issuer=
"http://www.trustedidp.com"
DataType=
"http://www.w3.org/2001/XMLSchema#date"/>
</Apply>
<AttributeValue DataType=
"http://www.w3.org/2001/XMLSchema#date">1992-01-01</AttributeValue>
</Apply>
When no value for urn:mypolicy:local:isoverage is known at the time
the rule is evaluated, then an "Indeterminate" decision is returned
with status code
"urn:oasis:names:tc:xacml:1.0:status:missing-attribute" (as per
Section 7.15.3) listing urn:mypolicy:local:isoverage in the
<MissingAttributeDetail> element. If the PEP/PIP/Context
Handler obtains an assertion by trustedidp.com that the above
predicate is true (by contacting either the requestor or the IDP
directly), then a refined request context is resubmitted specifying
that urn:mypolicy:local:isoverage is true:
<Request>
...
<Subject>
<Attribute AttributeId="urn:mypolicy:local:isoverage"
Issuer=
"http://www.trustedidp.com"
DataType=
"http://www.w3.org/2001/XMLSchema#boolean">
<AttributeValue>true</AttributeValue>
</Attribute>
...
</Subject>
</Request>
Questions
- The XACML spec seems to specify two ways in which missing
attributes can be treated, either by returning an Indeterminate
response as per XACML 2.0 spec section 7.15.3, or call out to
the PIP (via the Context Handler). Which mechanism is used when?
Is the communication format for the latter mechanism
standardized?
- How to distinguish local boolean attribute IDs that are in
fact aliases for predicates over global attribute IDs from
normal local attribute IDs? Should one standardize a URN prefix
for these type of attributes, as Hal suggested?
- The above flow assumes that, when missing attributes are
encountered, an Indeterminate response is generated and a new
request is resubmitted. I understand there is also an
interactive way of fetching missing attributes, but I must admit
that I don't understand where in the standard this mechanism is
specified.
- It would be nice if the predicate could contain environment
attributes, such as the current date. For example, the above
predicate could specify that "bday < today - 18Y" instead of
"bday < 1992/01/01":
<Apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-less-than">
<Apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-one-and-only">
<SubjectAttributeDesignator AttributeId="http://www.w3.org/2006/vcard/ns#bday"
Issuer="http://www.trustedidp.com"
DataType="http://www.w3.org/2001/XMLSchema#date"/>
</Apply>
<Apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-subtract-yearMonthDuration">
<EnvironmentAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-date"
DataType="http://www.w3.org/2001/XMLSchema#date"
/>
<AttributeValue DataType="http://www.w3.org/TR/2002/WD-xquery-operators-20020816#yearMonthDuration">P18Y</AttributeValue>
</Apply>
</Apply>
Which predicate assertion would then be requested from the
user/IDP however, the literal predicate above, or a "partially
evaluated" predicate where the
<EnvironmentAttributeDesignator> element is replaced with
an <AttributeValue> element with the correct value? If the
latter, who does the partial evaluation?