OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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:

should be expanded fully

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]