xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xacml] PrimeLife attribute predicates: the simple case
- From: Franz-Stefan Preiss <FRP@zurich.ibm.com>
- To: xacml <xacml@lists.oasis-open.org>
- Date: Mon, 29 Nov 2010 15:34:51 +0100
Dear Paul, All,
>> 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.
Considering Paul's proposal [1] on using
'extended' <AttributeValue> elements in the request context, this
would allow for choosing the ContextHandler as mapping instance without
an actual change of the request schema.
However, a mapping from the incoming
SAML assertion to the 'extended' <AttributeValue> elements would
be needed. In my understanding, the 'SAML 2.0 profile of XACML' would be
the place to to this. As you may already know, there are currently discussions
going on with the SAML committee on whether it makes sense to introduce
'attribute predicates' in SAML. Under the assumption that those are indeed
introduced, then the SAML profile of XACML would have to be extended for
incorporating a translation from the new attribute predicates to the 'extended'
<AttributeValue> elements.
In case it is not the Context Handler
that does the mapping but, e.g., the PEP, then, if I understand correctly,
neither the 'extended' <AttributeValue> elements nor an extension
of the SAML profile for XACML are necessary.
[1] http://lists.oasis-open.org/archives/xacml/201011/msg00033.html
Best Regards,
Franz-Stefan Preiss
------------------------------------------------
Franz-Stefan Preiss
IBM Research Zurich
Säumerstrasse 4, CH-8803 Rüschlikon,
Switzerland
+41 44 724 8401
frp@zurich.ibm.com
------------------------------------------------
From:
| Gregory Neven <nev@zurich.ibm.com>
|
To:
| xacml <xacml@lists.oasis-open.org>
|
Date:
| 11/25/2010 10:28 AM
|
Subject:
| [xacml] PrimeLife attribute predicates:
the simple case |
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
1. 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?
2. 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?
3. 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.
4. 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?
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]