[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]