[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
All, I think this is a good use case which we should support. After some off list clarifications from Bill, I would like to explain how this fits in the current obligation families working draft. I think the document could be improved with respect to this, and I will try to do so for the next version. The current draft defines "After", "Before" and "With" options for obligations after the proposal from David Chadwick. What is currently a bit unclear perhaps is that when I thought about David's proposal, I made two distinct interpretations from the metadata "After", "Before" and "With". The first interpretation is what I would call the "Causality" interpretation. According to this interpretation the metadata is intended to guarantee that, for instance, if the obligation is "After", then any side effects from the access enforcement will be visible to the obligation enforcement. The second interpretation is what I would call the "Atomicity" interpretation. According to this the metadata is intended to guarantee that, for instance, if the obligation is "After", then it is guaranteed that if the obligation is successful, then the access has also been successful. I tried to think what David intended and I thought that he was mostly interested in the atomicity guarantees, so that is what I wrote in the draft. What Bill is proposing is the causality interpretation. I think we should support both. I haven't really thought through yet how these two can interact and be perhaps combined. My gut feeling is that the atomicity guarantees should be supersets of the causality guarantees, that is, if you ask for the atomicity guarantee, you get the causality as well. Regards, Erik Bill Parducci wrote: > I would like to propose that we introduce a "TTL" attribute to > ObligationFamiles, specifically for those that are to occur after the > decision has been rendered. The use for post decision Obligations > would be along the lines of: > > make request (PEP) > compute decision (PDP) > generate response (PDP) > execute decision (PEP) > execute obligation; ERROR state if not complete by TTL (PEP) > > The thinking here is that if you specify that you wish something to > happen after the decision is made/enforced then it seems logical that > you would want it to be time bound. In other words, I am suggesting is > that there are two reasons why an Obligation may not be met, one > quantitative (Obligation simply failed), the other qualitative (the > Obligation is taking longer to fulfill than is considered reasonable > by the Policy writer). > > What is "reasonable"? I don't know, but my opinion is that it is > defined by the Policy writer not the system administrator because the > former has the context of what the Policy is supposed to achieve. I > also suspect that the specification of the TTL value is best suited at > the ObligationFamily level since it defines the expected behavior for > that class of Obligation. > > How the ERROR behaves and how that information is dealt with is > implementational. > > b > > On Feb 17, 2008, at 3:13 AM, 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 > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]