Re: [xacml] Groups - xacml-3.0-obligation-v1-wd-03.zip uploaded

[Bill Parducci <bill@parducci.net>]

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