[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] AI 00077 - Auth Decision (Section A) FW: [xacml] XACML/OGSA SAML 2.0 Requirements, v1.8
> From: Hal Lockhart [mailto:hlockhar@bea.com] (forwarding for) > -----Original Message----- > From: Anne Anderson [mailto:Anne.Anderson@Sun.com] > > Colleagues, > > Attached are the joint XACML/OGSA SAML 2.0 requirements presented > at the SAML Face-to-Face 10 Sept. This final version of the > requirements was agreed on during a working session between XACML > TC and OGSA representatives held at the SAML Face-to-Face Tuesday > afternoon 9 Sept. This has been stewing in my inbox for quite a while. Now it's late and I'm wedged into an airplane seat, so forgive me (or thank your stars, or whatever) if I'm less philosophical than usual... I'm going to give away the ending first this time, unlike my previous message. Your proposed changes make the SAML protocol schema depend on the XACML schema. I will vote against this. Either plug XACML into existing "any" extension points in the samlp schema, add new extension points, or devise an entirely new XACML protocol. If we really can't solve your problem without injecting XACML elements into the samlp schema, it's a clear indication that either we got the extension points wrong in the samlp schema, or that XACML should not be trying to use samlp as a transport. > Proposed SAML 2.0 Changes from XACML TC and OGSA > Editor: Anne Anderson <Anne.Anderson@sun.com> > Version: 1.8, 03/09/10 (yy/mm/dd) ... > 4. Where XACML Obligations go when carried in a SAML Response; > specific semantics of SAML Condition vs. XACML Obligation If we honestly need both Conditions and Obligations, we're going to have to figure out a way to make the semantics distinct enough that users can understand them. The fact that *we're* not quite sure what the distinction is doesn't bode well. ... > ===================================================================== > A. Abstract Requirements for SAML AuthorizationDecisionQuery/Response > ===================================================================== > > 1. A way to pass an XACML Input in the SAML Query, and an XACML > Output in the SAML Decision. [W-28C] > > These new SAML Query and Decision types should not extend SAML > SubjectQueryAbstractType and SubjectStatementAbstractType because > the SAML Subject element is redundant and inconsistent with XACML > Subject information in the XACML Input and Output. > > The requirements are: > a) Make the SAML Query and Decision more compatible with the XACML > Input and Output. Or the converse. > b) Allow a SAML Decision to include the validated Attribute > Identifiers and values that were used by the PDP in making the > authorization decision. Can these be included inside XACML elements nested inside a SAML extension point? If not, see the above rant about fixing extensibility or using a different protocol. > 2. A way to return an XACML Input as part of the SAML Decision, and > a flag in the SAML Query to indicate whether an XACML Input is to > be returned as part of the SAML Decision. [W-28C] Ditto. ... > =================================== > B. Other Abstract SAML Requirements > =================================== > > 1. Associate a DataType with an Issuer name, such that the name > can be determined to be a string, an X.500 Distinguished Name, > etc. [W-28D] My response to Rebekah Lepro's message goes after this one. > 2. Better correspondence between SAML Attribute format and XACML > Input Attribute format. [W-28A] > > The requirement is to allow SAML Attributes to be translated > into XACML Input Attributes mechanically and easily. Current > differences include: > > a) One SAML Attribute can have multiple AttributeValue elements, > whereas an XACML Attribute has a single AttributeValue element > with "any" type (allowing the single AttributeValue to be a > sequence of values if appropriate). > > b) SAML Attribute has a "name qualifier" XML attribute, whereas the > XACML Attribute does not. > > Additional problematic differences are to be submitted by Rebekah > Lepro, who has been writing code to do such translations. If I'm not mistaken, the SAML spec was reasonably stable about attribute naming and structure before XACML was too far under way. Why did the XACML TC choose to make their format different? > 3. A new SAML Policy Statement syntax. [W-28B] > > The requirement is to allow a policy issuer (Policy Administration > Point) to state and sign an XACML Policy.. The XACML TC may be > responsible for defining such a syntax. SAML doesn't have or want a Policy Statement syntax. That's XACML's job. If XACML wants to derive from saml:Assertion to define the syntax, dive right in. > 4. A new SAML Policy Query syntax. [W-28B] > > The requirement is to allow a PDP to request an XACML Policy by its > Policy[Set]Id from an on-line Policy Administration Point (PAP). Again, this should be an XACML Policy Query, and I refer back to my opening rant. > ============================================================= > C. Requirements to be satisfied by [changes to ]XACML schemas > ============================================================= Somebody Else's Problem (tm) > ======================================================= > D. Suggested SAML Assertion Schema Changes [incomplete] > ======================================================= > > Note: This is an early draft that has not been completely reviewed > against the current list of requirements. It is included here merely > as an example that may help clarify what XACML and OGSA have in mind. This entire section falls under my opening "SAML schema MUST NOT refer to XACML schema" opinion. If you need us to insert an "any", or make a particular SAML element a little more extensible so that XACML can derive a subtype from it, I'll be happy to help you get that change into SAML 2.0. > ====================================================== > E. Suggested SAML Protocol Schema Changes [incomplete] > ====================================================== Ditto. > =============================================== > F. Suggested Specification Changes [incomplete] > =============================================== > > Changes to "Assertions and Protocol for the OASIS Security > Assertion Markup Language (SAML)" (OASIS Standard, 5 November > 2002) to utilize the XACML Request and Response Context formats > for authorization decisions. These are associated with the > schema changes listed in sections C and D. This one I have a slightly different opinion on. The SAML AuthorizationDecisionQuery and ADResponse were never really "baked"; when SAML 1.0 came to the crunch I think we pretty well agreed that this part of the spec wasn't really finished, and we let it slide. I'd like to remove ADQuery and ADResponse from SAML. XACML can then use whatever SAML extension methods are appropriate to define the semantics you need. As always, subject to the requirement that the saml and samlp schemas contain no direct references to any XACML elements. Well, there we are. Under different conditions I might have been less blunt, and please don't take this as implying that I feel that XACML is in any way below or less valuable than SAML. On the contrary, I see the requirement for two-way dependencies as an indication that something is wrong with SAML, since our original goal was to make an extensible framework that could be used to derive things like XACML _without_ needing to build in the reverse dependencies. - irving -
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]