XACML SAML extension notes and questions

[Anne Anderson <Anne.Anderson@Sun.COM>]

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