[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: Re: [security-services] Moving subjects up to assertions(disregard first reply)
--- Begin Message ---
- From: "Eve L. Maler" <Eve.Maler@Sun.COM>
- To: 'SAML' <security-services@lists.oasis-open.org>
- Date: Mon, 08 Mar 2004 17:32:10 -0500
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 To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]