[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Groups - xacml-3.0-obligation-v1-wd-03.zip uploaded
Minor suggestions from my end: name="ObligationFamiliesDecl" should be expanded fully name="ObligationFamiliesDeclaration" erik@axiomatics.com wrote: > This is a major rewrite of the obligation families profile. > > Summary of changes: > > - Use <xs:any> for extension rather than xsi:type > - Define a response formet for each family. Insertion in the core response > remains to be done. > - Include the "Chronicle" attribute proposed by David Chadwick back in May > 2007. Though I am calling it "Timing" > - Due to the Timing attribute include some text defining properties about > obligation enforcement under failure. > > Detailed discussion of changes follows. > > I changed the way the schema was set up. I used to defined an abstract > ObligationFamily type which the concrete obligation family types extended. > I dropped this inheritance of schema types because it leads to the use of > the xsi:type attribute which as Hal pointed out during the next to the > previous TC call, is annoying in XML signatures since you have to define an > inclusive namespace in the signature to make sure the xmlns:xsi is not > dropped during exclusive c14n. > > Instead I made it like this: > > <xs:element name="ObligationFamiliesDecl" > type="obl:ObligationFamiliesDeclType"/> > <xs:complexType name="ObligationFamiliesDeclType"> > <xs:choice minOccurs="0" maxOccurs="unbounded"> > <xs:element ref="obl:ExclusiveDecl"/> > <xs:element ref="obl:SequentialDecl"/> > <xs:any namespace="##other" processContents="lax"/> > </xs:choice> > </xs:complexType> > > The xs:any allows for extension of families by us or by users. I chose this > approach by imitation of the WS-Policy schema. (I hope I got it right.) > This approach means that a family is identified by its element name > (including the namespace of the element). This is not problematic in > signatures. This also means that there is no need for a URI for identifying > the families since the element name is enough. > > I have defined a response format for the two families which are defined, > but I have not defined yet how these XML fragments are inserted in the > request context since this change may affect the core schema. > > There are two ways I can think of. One is to change the 3.0 core schema so > it allows obligation families in the response. This is my preference. It > would like this: > > <Response> > <Result Decision="Permit"> > <Status>...</> > <Obligations>...</> > <ObligationFamilies> > <Exclusive> > ... > </Exclusive> > <Sequential> > ... > </Sequential> > </ObligationFamilies> > </Result> > </Response> > > Another option is that the PDP creates a special obligation, which contains > the families. The second option is a bit more verbose, but does not require > a special construct in the core schema. > > <Response> > <Result Decision="Permit"> > <Status>...</> > <Obligations> > <Obligation ObligationId="urn:oasis:...:obligation-families"> > <AttributeAssignment> > <AttributeValue> > <ObligationFamilies> > <Exclusive> > ... > </Exclusive> > <Sequential> > ... > </Sequential> > </ObligationFamilies> > </AttributeValue> > </AttributeAssignment> > </Obligation> > ... Other obligations here ... > </Obligations> > </Result> > </Response> > > > I have added the "Chronicle" attribute proposed by David Chadwich back in > May 2007. This attribute tells whether the PEP should enforce the > obligation before, during or after access control enforcement. As we have > discussed previously, I put it in the obligation families profile rather > than the core schema. However, this way it is less granular than the > original proposal by David, in which individual obligation instances in > policies could be marked with the Chronicle attribute. > > I think this is better since I would like to have the obligation families > as the method of defining obligation metadata because the obligation family > concept is used to isolate mutually inconsistent meta data types from each > other. Also, the families concept contains an extension point so additional > meta data can be defined in the future. > > If we put the Chronicle attribute in the core schema obligation we get two > problems: > > 1. If we want to add some other meta data attribute in the future, we have > to change the core schema again. > > 2. As we keep adding more and more meta data attributes to the core, the > meta data types will eventually start to conflict with each other and > various combinations of metadata explode and defininig the semantics will > be difficult and prone to inconsistensies and security issues. > > We already have an example of such a conflict: the chronicle metadata would > conflict with the Sequantial obligation family. The sequential obligation > family is used to say in what order obligations are enforced. Here is a > simple example of how this can conflict with the Chronicle attribute: > > Two obligations: A and B > > Chronicle says on A: before access control enforcement > Chronicle says on B: after access control enforcement > > Sequential family says: B has to be enforced before A > > So, in order to avoid issues like these, I propose that all obligation > metadata is put in the families where applicable. The metadata available > within each family is limited in scope and can be kept consistent so it is > not possible to define conflicting metadata, or at least the scope of > conflicts can be kept to a minimum so the conflict resolution can be > comprehended. > > BTW, If someone wants to do what David proposes, it can be done already by > making the Chronicle an <AttributeAssignment> within the obligation like > this: > > <Obligation OligationId="http://foo/bar";> > <AttributeAssignement AttributeId="http://foo/Chronicle";> > <AttributeValue DataType="...#string">Before</AttributeAssignment> > </AttributeAssignment> > ... Any other AttributeAssignments ... > <Obligation> > > The PEP can extract the Chronicle value from there before obligation > enforcement. This of course could lead to conflicts with other metadata, > but there isn't much we can do about this. At least the "official" metadata > schemes from the TC will be consistent. > > Finally, I changed the name of the attribute to "Timing" rather than > Chronicle and I made the values "BeforeAccess", "WithAccess", > "AfterAccess". I though these names are more easily understood. Let me know > if you disagree. > > > Because I have added the timing attribute to the obligation families, I was > concerned about whether it is possible to implement such guarantees. I > wrote up a simple analysis of it. Please review that so I didn't make a > mistake. And we might consider moving that to the core spec instead of this > profile since some of it applies to obligations in general. > > I added another piece of metadata to the sequential family which I thought > would be useful: a mode of failure for enforcement of the sequence > obligations. Previously it was undefined what should happen if some of the > obligations fail. There are noew three modes: Atomic, FailFast and > ContinueOnFailure. > > I have not written the examples yet. I would like to reach consensus on > these new major changes in the TC before I put effort into detailed > writeups of examples. > > Personally I feel like this is pretty much the obligation family profile > completed from a technical point of view. It just needs the examples and > some editorial work to make it look good. Oh, and of course fixing any > errors. :-) > > > -- Erik Rissanen > > The document named xacml-3.0-obligation-v1-wd-03.zip has been submitted by > Erik Rissanen to the OASIS eXtensible Access Control Markup Language > (XACML) TC document repository. > > Document Description: > > > View Document Details: > http://www.oasis-open.org/apps/org/workgroup/xacml/document.php?document_id=27230 > > Download Document: > http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/27230/xacml-3.0-obligation-v1-wd-03.zip > > > PLEASE NOTE: If the above links do not work for you, your email application > may be breaking the link into two pieces. You may be able to copy and paste > the entire link address into the address field of your web browser. > > -OASIS Open Administration -- Anil Saldhana Project/Technical Lead, JBoss Security & Identity Management JBoss, A division of Red Hat Inc. http://labs.jboss.com/portal/jbosssecurity/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]