I met with Anne today and confirmed my understanding of XACML's needs
wrt building on top of SAML. Comments and a proposal are below:
Anne Anderson wrote:
> XACML has two strong use cases.
>
> 1. XACML's Query and XACMLAuthorizationDecisionStatement are NOT
> tied to a Subject. An XACML request may contain no Subject
> whatsoever! The only requirement is that it contain a
> resource. Any Subject information is weighted equally with
> any Resource or Action information.
I confirmed that it would be acceptable to Anne if XACML had to derive
its special kinds of queries from our new RequestAbstractType structure.
It seems entirely appropriate and within the spirit of SAML to query
on whatever criteria one wishes.
(Incidentially, I also confirmed that she's okay with our decision to
block element substitution. It appeals to her, as it does to me, to use
<saml:XXXX xsi:type="xacml:YYYY"> to indicate the SAML "primacy" of any
XACML-extended markup.)
XACML includes both queries that don't specify subjects as a criterion,
and also queries that do specify XACML-flavored subject information.
XACML subjects are pretty much collections of attributes, which is a
structure very different from our identifier-based one.
> 2. XACML's XACMLPolicyStatement does not contain a Subject at all
> (it MAY refer to one or more Subject Attributes, but those may
> refer to many different subjects that might come in from
> different requests).
>
> This Statement has an issuer (the policy creator), but no
> Subject. Yet I think it is squarely in the scope of SAML as a
> Security Assertion.
In talking with Anne, I came to agree that this is a perfectly
reasonable thing to want to do with a "security assertion markup
language". I feel that since XACML is one of the earliest users of SAML
and since the XACML TC's intent is to profile/extend SAML V2.0 formally
rather than just being "inspired" by it this time around, we should
continue to accommodate XACML wrt subjectless assertions.
Therefore, I propose that we do the following:
- Keep <Assertion> as the main assertion element we expect
everyone to use.
- Bind it to a type called AssertionType that requires
<Subject>.
- Add an ancestor type that has no subject information in it,
just the usual common stuff like MajorVersion, so that
AssertionType gets the common stuff from this ancestor.
- Call the ancestor type *AssertionAbstractType (fill in
asterisk with "Generic" or "SAML" or "Subjectless"?).
- To make the whole extension point thing work, declare an
element *Assertion (fill in asterisk with same answer as
above) and insert it in the obvious places.
I again considered the idea of adding SubjectAbstractType (with nothing
in it) instead of using this approach, but it appears that
XACMLAuthorizationDecisionStatement really doesn't *require* a subject
in it, and I would really like to avoid making <Subject> optional on
regular SAML assertions. Also, on reflection it seemed that it would be
Tag Abuse to require XACMLPolicyStatement to have an empty <Subject>
element. In this case it's better for XACML to define its own
<xacml:Subject> element with its own semantics and optionality (rather
than a <saml:Subject xsi:type="xacml:XACMLSubjectType"> element).
Eve
--
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 354 9441
Web Products, Technologies, and Standards eve.maler @ sun.com
