[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: relevant SAML F2F items from the minutes
I just wanted to make the WGs aware of the two items that were discussed at the recent SAML F2F and that seemed relevant to XACML and the ogsa-authz's authorization decision query requirements. FYI. Regards, Frank. ---------------------------------------------------------------------------------- W-28b: Deprecating AuthorizationDecisionQuery and AuthorizationDecisionStatement, Prateek Mishra Goals: Make a decision! Document: TAS Prateek: Told XACML to not wait for SAML before proceding Prateek: Asked who is using it - Rebekah said NASA is - and XACML closed issue list for XACML 2.0 Hal: not sure that's true Prateek: so won't drop these in SAML Scott: can we import from 1.1 schema? Hal: XACML will do XACML specific one, would prefer not to see additional features added. Steve: they do not want to add too muc to their scope Bob: no one here is going to write the text to complete the item John: is the perception that it is broke? Rob: just not powerfull enough Hal: at the time it came XACML was not very mature and needed something simple Scott: freezing will mean some work - copy into the schema - not the amount of work - conceptually bringing it in requires work Rob: still need to do that if deprecating rather than removing Scott: can we reuse existing schema rather than pull it into ours in 2.0? Eve: to implement entire XACML to do simple auth may be too much Hal: any PEP can only provide info that it has Hal: deprecation could be non-specific about which version will not have it Hal: this additional functionality could be CD in XACML before SAML 2.0 MOTION: Steve moved to freeze this functionality as is for SAML 2.0, no further functional enhancements, with suggestion that anyone needing more functionality look at XACML, Hal seconds Discussion Rebekah: isf it is not deprecated I am comfortable with the motion as is No objections, passed. ---------------------------------------------------------------------------------- W-28a*: Attribute Usage ======================= Goal: accept solution proposal Latest document (from Feb 4) is at: http://www.oasis-open.org/apps/org/workgroup/security/download.php/5312/draft-sstc-attribute-03.pdf Section 4 has the proposed modifications. A recent XACML telecon generated a lot of discussion on this document and on the differences between SAML and XACML attribute usage. Reviewing the proposals: 4.1: AttributeNamespace: Change this attribute explicitly to a URI that indicates how to interpret the attributes. Could cover a lot of common schemes. 4.2: AttributeDesignatorType and AttributeDesignator: No changes needed, but some text has to come out because later proposals have AttributeType no longer being derived from AttributeDesignatorType. This goes with 4.3: TypedAttributeDesignatorType. Scott: Not sure we need to go to such lengths in the schema; we can just throw some optional attributes on existing types. Rebekah: A good example is LDAP attributes, which don't carry datatypes, whereas XACML-style attributes do. Attempting to provide ability for someone to use AttributeNamespace and Attribute and have that be enough. Scott: But optional XML attributes on SAML elements could be enough; if values are present, great. There's no (XSD) schematic connection between the XML representation and the LDAP- (or whatever-)type attribute. So you have to make this connection in prose anyway. Thus, keeping the schema simple makes sense. Rebekah: Would the XML attribute holding the datatype go on AttributeDesignatorType, then? Scott: Either that or AttributeType. [Note: Proposal 4.3 suggests that it would need to be on the designator, not just the value-holding response.] Scott: the attribute currently doesn't tell the consumer what type its value is. Hal: XACML has an evaluation engine with type-checking, and it doesn't want to build in knowledge of specific attributes. It should handle arbitrary ones. RLBob: So you need schema definitions that plug in to the engine. Scott: XACML uses built-in types plus XPath in order to achieve the goal Hal mentioned. All attributes have become self- describing. RLBob: Does the XACML model require that attributes be annotated with type information? (All: Not sure.) Eve: The current proposals set up two types/elements, one with required type information and one without. Instead we could have one element with an optional datatype field. Scott: If we're comfortable with not providing a guarantee about being able to map to XACML attributes without additional run-time logic, that mapping could deal with both situations. 4.4: AttributeType and Attribute: Here, an <Attribute> element is proposed to contain <AttributeDesignator> rather than derive from it. Eve: It seems a bit weird to put the typing information on an older sibling of the value, compared to the value itself or the value's parent. Scott: The important thing is that this is type information on the attribute (regardless of choice of XML expression) that can be used to validate that all values for the attribute are the same. Currently, SAML allows a different value for each type. Eve: So the goals are to specify the type-as-a-URI for both attribute designators alone and for whole attributes and enforcing (when desired) that all the values in an attribute have the same type? All: Questions about the complexity of requiring that a returned attribute has the specified type. There are many weak-matching scenarios. ACTION: Eve: Propose a set of options for achieving the above (and below!) goals. Scott: The overarching SAML<->XACML goal here is to be able to profile the SAML attribute functionality in such a way as to make it compatible with what XACML expects. Is that right? SAML can make new optional functionality available, but to use it successfully with XACML, it would have to be "profiled" to make some of the optional parts required for that purpose. If XACML can then explicitly acknowledge the lack of suitability for some kinds of SAML statement that were created without regard for XACML needs. Rob: But I thought the goal was (stronger) alignment, not (weaker) profiling. Scott: Pure alignment would mean always requiring the type information on attributes, though not necessarily on queries. RLBob: But if you want to query for all attributes of a certain type, you'd need to supply type information in the query. Eve: Note that we have a work item W-12, currently in Reassess mode, about querying attributes by type. So we're not taking on this second use case. Eve: We can finesse this by defining a type URI that means "the type is application-specific" and making it the default. Then, the SAML syntax will be fully aligned, while not imposing extra burdens on SAML users who are not interested in XACML compatibility. RLBob: Are there uses for the type information beyond XACML? Rob: Can this be spec'd to allow for such uses? Scott: No. The process of defining profiles of attributes should include defining whatever other details are needed to work with XACML. 4.6: ScopedAttributeValueType: This proposes a new field for holding scoping information (e.g., department name) that people are currently (ab)using AttributeNamespace for. It's proposed to go on a special version of the value element as a required field. RLBob: Scope, for Shibboleth, means -- for example -- that a faculty member's name is in the value and the department is the scope. Scott: There are many different meanings of "scope"! If we separate out what AttributeNamespace is being used for sometimes now, let's consider that the attribute name's format. Then we can work on all the other things that might be called "scope". This nets out to accepting proposal 4.1 but changing the XML attribute's name to NameFormat. Eve: +1 Irving: This feels like piling mechanisms on top of mechanisms. Rob: In my heterogeneous environments, I might need to set up lots of different formats. Irving: But everyone will have to support all the possible attribute name formats. Eve: No, this will be a piece of configuration data just like all the others that we have for name identifiers etc. And it codifies, in a more useful way than SAML V1.x did, attribute names. Scott: So AttributeNamespace could disappear and be replaced by one or more fields that are more precise about the purpose they serve. Scott: In Shibboleth, they have a ScopedAffiliation structure so that you can provide important information along with your attribute value (faculty...of what? the law school?) in order to give context. This seems to be a common enough need that SAML should have it. Eve: To preserve clean separation between SAML's semantics and application-specific attribute value semantics, SAML shouldn't have this; it should be up to people putting their own stuff inside/on <AttributeValue>. Should we improve our schema extensibility features for this element? Scott: We probably can't do better than xs:anyType, though maybe we need some prose with a "health warning" that warns against using xsi:type, which requires that the extension schema be available. ACTION: Eve: Add an issue to the issues list about adding prose as described above. Eve: What about a field for the "source" of the attribute, in the sense that Rob and Prateek have reported using AttributeNamespace in the past? All: Seem to generally like this idea. John H.: This seems to work for DCE. John H.: What if you want to supply a "friendly name" along with the GUID, the way DCE does? Eve: Maybe we should put <xs:anyAttribute> on AttributeType. This would allow you to slap any global attribute onto <Attribute> without needing a schema for them. Several: Yes. ---------------------------------------------------------------------------------- -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]