MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: XACML SAML extension notes and questions
SSTC SAML 2.0 is moving in some directions that are very good for
XACML:
1) SSTC has discovered that AttributeNamespace was being used
inconsistently for various purposes: datatype, Attribute
source, Attribute domain of interpretation, etc. They also
discovered they need to determine the datatype of an attribute
independently of having an AttributeValue. (XACML to SSTC: We
told you so!)
The current SSTC proposal for SAML Attribute has the
equivalent of our AttributeId (Name) and DataType (Format) as
the only two required XML attributes on an
AttributeDesignator.
2) NEW ISSUE: The current SSTC proposal would let users insert
arbitrary other xml attributes, such as Domain="xxx",
Source="xxx", in addition to the two required Name and Format
attributes. These additional xml attributes must be of
"anyURI" type.
Do we want to support such arbitrary additional xml attributes
on an XACML Attribute? We could allow matching on such
attributes just like we now allow matching on Issuer. Note
that we require string-equal match semantics on XML
attributes, even if the attributes are of anyURI type - this
means the checker does not have to understand the syntax
matching rules for each URI scheme (e.g. does "xxx:ABC" match
"xxx:abc"; XACML says no, without having to know whether
scheme "xxx" says they are equal or not).
Example:
<ResourceAttributeDesignator AttributeId="xxx"
DataType="yyy"
Issuer="zzz"/>
This designator returns a bag containing only those
Resource Attributes from the Request that match on all of
AttributeId, DataType, and Issuer.
<ResourceAttributeDesignator AttributeId="xxx"
DataType="yyy"
Issuer="zzz"
Domain="ddd"
Source="sss"/>
This designator would return a bag containing only those
Resource Attributes from a Request that match on all of
AttributeId, DataType, Issuer, Domain, and Source.
Deciding on this is a bit pre-mature, since SSTC has not yet
accepted the above proposal, but we might want to think about
it. If we see big problems, we might want to feed those back
to the SSTC now.
3) Up until the most recent proposed changes, we would have to
pretty much redefine SAML in order to get XACML extensions to
SAML. For example, we would have had to extend
saml:Request->XACMLRequest as well as extending
saml:Query->XACMLAuthorizationDecisionQuery, because there was
no way for saml:Request to include any kind of extended Query
element.
With the most recent proposed changes, we will be able to use
a saml:Request that contains an
xacml:XACMLAuthorizationDecisionQuery.
4) QUESTION: we are defining extensions to both the SAML
Assertion Schema (XACMLAuthorizationDecisionStatement,
XACMLPolicyStatement) and to the SAML Protocol Schema
(XACMLAuthorizationDecisionQuery, XACMLPolicyQuery).
Should we define two XACML extension schemas, or just one?
Anne
--
Anne H. Anderson Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]