SAML statement extension for XACML

[Anne Anderson <Anne.Anderson@sun.com>]

Looks like we need to make another pass on the SAML profile schema for
XACML.  Argyn, would you be interested in tackling this, since you
suggested using xsi:type?  I'm forwarding Eve Maler's comments, where
she agrees that using xsi:type is the way to go.

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

--- Begin Message ---

• From: "Eve L. Maler" <Eve.Maler@Sun.COM>
• To: Anne.Anderson@sun.com
• Date: Mon, 26 Sep 2005 12:43:21 -0700

The commenter is right that SAML V2.0 has blocked substitutions, so 
you can't use that method anyway.  The proper way is to extend the 
StatementType to contain what you want and then either use the real 
<saml:Statement> element with an xsi:type on it naming the XACML 
custom type, or extend AssertionType to allow containment of some 
special XACML element that is mapped to your own type (and then have 
to "extend all the way up" as necessary).  The former method is 
preferred, as suggested by this text in the core spec:

http://www.oasis-open.org/committees/download.php/11898/saml-core-2.0-os.pdf
Lines 3133-3137

"Note that elements in the SAML schemas are blocked from 
substitution, which means that no SAML elements can serve as the 
head element of a substitution group. However, SAML types are not 
defined as final, so that all SAML types MAY be extended and 
restricted. As a practical matter, this means that extensions are 
typically defined only as types rather than elements, and are 
included in SAML instances by means of an xsi:type attribute."

To explain a bit more: You must have extended SAML's *types* with 
custom XACML *types*, and then bound those custom types to custom 
XACML elements.  That last step is certainly legitimate to do, but 
in order to use those elements inside SAML elements, you do have to 
extend parent types to allow them.  The alternative way is to use 
your custom *types* directly on SAML's abstract Statement element by 
referencing them with xsi:type.

	Eve

Anne Anderson wrote:
> Hi Eve,
> 
> Here are my more specific questions about this user's comment:
> 
> In the SAML 2.0 profile of XACML 2.0 schema, I defined
> XACMLAuthzDecisionStatement and XACMLPolicyStatement as extensions of
> saml:StatementAbstractType.  In the SAML assertion schema,
> saml:Statement is included as one of the choices in saml:Assertion, and
> saml:Statement is defined as "abstract".
> 
> Isn't that sufficient to be able to use an XACMLAuthzDecisionStatement
> or XACMLPolicyStatement as the payload of a SAML Assertion?  Is a
> SubstitutionGroup really necessary, as this user claims?
> 
> Regards,
> Anne
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> [xacml-users] SAML statement extension for XACML
> From:
> Frederic Deleon <frederic.deleon@crf.canon.fr>
> Date:
> Fri, 23 Sep 2005 17:42:32 +0200
> To:
> xacml-users@lists.oasis-open.org
> 
> To:
> xacml-users@lists.oasis-open.org
> CC:
> Virginie PRIE <virginie.prie@crf.canon.fr>
> 
> 
> Hello,
> 
> Specification of SAML 2.0 profile of XACML defines XACMLPolicyStatement 
> and XACMLAuthzDecisionStatement whose types are extensions of SAML 
> StatementAbstractType element.
> It says that these statements should be placed in SAML Assertion 
> elements (themselves placed inside SAML Response elements).
> As extended type from Statement I suppose.
> 
> However, XACMLPolicyStatement and XACMLAuthzDecisionStatement are not 
> defined as possible substitutions for Statement, as there is no 
> "substitutionGroup" attribute in the XML schema, and substitutions are 
> blocked anyway by blobkDefault="substitution" in both schemas (SAML and 
> XACML-SAML profile).
> 
> So, it seems that putting XACMLPolicyStatement and 
> XACMLAuthzDecisionStatement in SAML assertions is not correct according 
> to schemas.
> What is your mind about this ?
> Is schema of SAML extension for XACML profile normative ?
> 
> Thanks in advance,
> Sincerely
> 
> 
> Frédéric Deléon
> 
> 
> ---------------------------------------------------------------------
> This publicly archived list supports open discussion on using the
> XACML OASIS Standard. To minimize spam in the archives, you
> must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Alternately, using email: list-[un]subscribe@lists.oasis-open.org
> List archives: http://lists.oasis-open.org/archives/xacml-users/
> Committee homepage: http://www.oasis-open.org/committees/xacml/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Join OASIS: http://www.oasis-open.org/join/
> 

-- 
Eve Maler                                         +1 425 947 4522
Technology Director                           eve.maler @ sun.com
CTO Business Alliances group                Sun Microsystems, Inc.

--- End Message ---