Describe ProposalForObligations here.

Definitions

==== ObligationCategories ==== as originally provide by Michiharu

Atomic Obligation must be performed with action just as the Obligation and the action are the atomic operation. So if the action is roll-backed, then the Obligation must be roll-backed as well.

Sequential - action and obligation must be performed in sequential way. First action is performed, then the first obligation is performed, etc. e.g. after the read action is performed, then the warning message must be sent to the manager.

Asynchronous action and obligation can be performed in asynchronous way. e.g. the read action is performed and in 90 days, the record will be deleted from the DB.

Supplemental obligation obligation supplements the action (as a parameter). e.g. service invocation is allowed and the routing should use this option.

Data-processing obligation obligation annotates action operation. e.g. data can be read but it should be encrypted using DES.

Category Behaviors

Name

Exclusive?

Timing

Sequence?

atomic

(./)

{1}

sequential

{2}

(./)

asynchronous

{3}

supplemental

{2}

data-processing

(./)

{2}

Where {1} implies execution during Permit/Deny Action and {3} Obligation carried out at some future date.

Anil introduced an interesting concept: non-mandatory obligations. It seems that this could an interesting line of thought as a way to deal with Obligation mismatch at PEP. "Alternative" is another area for exploration : e.g. "do A, else do B"

Additional Comments by Anil Saldhana

I know that the issue of "non-mandatory" obligations has been controversial, because it skews the semantic meaning of an obligation. I am referring to low priority obligations that can probably be ignored by the PEP (A use case is when there is an obligation to log every authorization request, the PEP may choose not to do any logging for system performance reasons).

End Comments by Anil Saldhana

Additional Comments by Anne Anderson

"Non-mandatory" Obligations can be handled by the definition of the semantics of the Obligation itself: a particular Obligation definition could state 'Log this access if possible, but grant access whether logged or not.' The drawback is that the PEP must understand the semantics of the Obligation in order to know this. If there were a generic, extra-Obligation attribute for "non-mandatory" Obligations then a PEP could be written to understand the generic attribute without having to understand the semantics of each specific non-mandatory Obligation.

End Comments by Anne Anderson

Category Examples

 Revisit once definitions and Behaviors are clarified - my guess is that this will be non-normative...? `-bill`

Atomic Examples: log(???), create File, etc.

Supplemental Examples: route, QoS behavior, filter, etc.,

Asynchronous Examples: Purge

Sequential Examples: email, warning, etc.

Data-processing Examples: encrypt, decrypt

A Different Approach: Non-Rigid Classification

So I think the way to deal with Obligations is to have ObligationFamilies (we can think of a better name later ;-) that are dynamically defined in Obligation Schema (vs. having a set group of Obligations). My guess is that the Obligation schema instances would be defined by Implementers rather than Policy writers but that is not a requirement. Each 1ObligationFamily would be composed of Obligations. The Family is not predefined, rather it is container for a set of combining attributes and the sequence of Obligations (precedence/order).

For simplicity I suggest we have ObligationFamilies contain Obligations in sequential order. The sequence may be ignored based upon the Sequential attribute, but I think it is easier if they are stored in that fashion regardless to keep the schema simple.

Here are the ObligationFamily Attributes I have gathered up so far:

Exclusive - boolean (maybe "n-of"? I prefer not to but I'll throw it out there for discussion), True | False. If True only one of the Obligations is applied. The sequence of Obligations in ObligationFamily determines precedence (first = highest). If False, all applicable Obligations are presented to the PEP.

Sequential - boolean, True | False. If True, all applicable Obligations are presented to the PEP in order; The PEP is to apply these Obligations in this order. If False, all applicable Obligations are presented to the PEP without reference to order. This requires a change to the way decisions are passed to the PEP.

Fallback - boolean, True | False. If True the PEP will attempt to perform the Obligations in order until it reaches one (or n if we decide to employ "n of" instead of Exclusivity--which is one reason why I prefer Exclusive to n-of) that it can complete. If it is unable to do so, the PEP will generate an Error condition and act accordingly. If False, the PEP will only attempt to fulfill the first Obligation presented and will generate an Error condition if it is unable to fulfill. This only makes sense if this is used with Exclusive. If Sequential is True then the PEP will attempt to fulfill the Obligations in the order given, otherwise it will attempt to fulfill any Obligation. This requires a change to the way decisions are passed to the PEP.

Repetitive - boolean, True | False. If True the PDP will present ALL Obligations from the family to the PEP (effectively a union of gathered Obligations with this ObligationFamily Attribute). The PEP will reapply each Obligation. If False the PDP will combine Obligations as defined by other Attributes. If this Attribute is True, Exclusive must be False. Not sure if this scenario makes sense but I can kind of thin of a Use Case (e.g. log -> a, log -> b if implementer wants to capture all applicable obligations). Erik & I think this seems that this should be handled in the ID. -bill

Optional - boolean. True | False. If True the PEP will attempt to fulfill the Obligation(s) presented (multiple if of type Fallback), however it will NOT generate an Error condition if it fails to fulfill the Obligations. If False the PEP will generate an Error condition if it is unable to execute an Obligation within the parameters given. Erik feels this should be handled in the ID.

Timing - Sync | AsyncValue. If Sync the PEP must execute the Obligation as part of an "Atomic" transaction with the access control decision; if Async the PEP must execute the Obligation within the value of AsyncValue. This is a required Attribute. If the PEP is unable to meet this requirement is generates an Error condition and acts appropriately. Another orthogonal attribute, but it's a brainstorm... ;-) Dud. -bill

Comments by Anil Saldhana

We need to define default values for these attributes (Eg: Timing is "Sync", Optional is "false", Sequential is "true" etc)

End Comments by Anil Saldhana

Note: This model assume exclusivity MUST ONLY be applicable within an ObligationFamily.

Comments by Erik

I think that is good, but I don't like the combinatorial explosion in semantics which your new approach leads to. If all these attributes are available, it is possible to define families with confusing semantics by setting many of the attributes to "true". Some combinations of attributes are not valid, while others may be valid, but there may be multiple possible interpretations. This means that we need to define very carefully what the semantics of all possible combinations of attributes are, which gets complex as the number of attributes grows. Especially when we add more attributes over time.

But I like the flexibility of this idea, and it can be used in a more limited fashion. It complements "hard coded" combining algorithms. So I have taken this idea of yours and included in what I wrote here, mostly based on what I have had in my mind for a fairly long time. obligations-combining.xsd is the schema for the "meta policy" for obligation combining. I am not sure whether it should be a separate meta policy, or if it could be included in the regular XACML policy or request schemas. For now I don't care. We can figure that out later. (I have dropped the explicit ObligationCombining element which Ja'far used from the policy schema for now, and think of this mostly as a meta policy.)

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:obl="urn:FIXME:obligations"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        targetNamespace="urn:FIXME:obligations" elementFormDefault="qualified"
        attributeFormDefault="unqualified">
        <xs:element name="ObligationFamilies" type="obl:ObligationFamiliesType"/>
    <xs:complexType name="ObligationFamiliesType">
                <xs:annotation>
                        <xs:documentation>
                                This is the top level element of the obligation combining
                                policy. It is used to declare which families are in effect.
                        </xs:documentation>
                </xs:annotation>
        <xs:sequence maxOccurs="unbounded">
                <xs:element ref="obl:ObligationFamily"/>
        </xs:sequence>
        </xs:complexType>
    <xs:element name="ObligationFamily" type="obl:ObligationFamilyType"/>
    <xs:complexType name="ObligationFamilyType" abstract="true">
                <xs:annotation>
                        <xs:documentation>
                                This is an abstract type representing obligation families.
                                Any specific obligation family has to define a concrete type
                                representing its parameters.
                                The XACML standard will define number of families in this
                                schema. These families are mandatory to implement, so
                                policy writers can rely on them being available.
                                Implementations may specify more families, but this requires
                                new code in the implementing PDPs, so it is not interoperable
                                without profiling and coordination between implementations
                                and users.
                        </xs:documentation>
                </xs:annotation>
                <xs:sequence>
                        <xs:element name="Description" type="xs:string"/>
                </xs:sequence>
        </xs:complexType>
        <xs:element name="ObligationId" type="xs:anyURI"/>
        <xs:complexType name="ObligationFamilyExclusive">
                <xs:annotation>
                        <xs:documentation>
                                This is a particular obligation family.
                                The parameters of this family are an ordered list of obligation
                                identifiers. The semantics for this family are that
                                of the obligations listed, only one occurence
                                is kept, with priority to the earliest identifiers in the list.
                        </xs:documentation>
                </xs:annotation>
                <xs:complexContent>
                        <xs:extension base="obl:ObligationFamilyType">
                                <xs:sequence maxOccurs="unbounded">
                                        <xs:element ref="obl:ObligationId"/>
                                </xs:sequence>
                        </xs:extension>
                </xs:complexContent>
        </xs:complexType>
        <xs:complexType name="ObligationFamilySequential">
                <xs:annotation>
                        <xs:documentation>
                                This is a particular obligation family.
                                The parameters of this family are an ordered list of obligation
                                identifiers and two xml attributes.
                                If the Ordered attribute is true, it means the PDP must return
                                the obligations in the listed order and the PEP must enforce
                                the obligations in the listed order.
                                If the Repetitive attribute is true, it means the PDP must
                                keep multiple instances of the same obligation id. If it is
                                false, the PDP must keep only one instance of each obligation
                                identifier.
                        </xs:documentation>
                </xs:annotation>
                <xs:complexContent>
                        <xs:extension base="obl:ObligationFamilyType">
                                <xs:sequence maxOccurs="unbounded">
                                        <xs:element ref="obl:ObligationId"/>
                                </xs:sequence>
                                <xs:attribute name="Ordered" type="xs:boolean"/>
                                <xs:attribute name="Repetitive" type="xs:boolean"/>
                        </xs:extension>
                </xs:complexContent>
        </xs:complexType>
</xs:schema>

The schema also defines a number of standard family types. In this case there are two, but you can imagine more of them. Each concrete family type takes a number of parameters. These parameters are defined by the schema. Each new family type needs its parameters to be defined in a schema and to be implemented in code in the PDP.

Among the parameters I have used lists of obligation ids, which defines which obligations belong to which family. I have also included some of the parameters which you wrote about in your email. In those cases where they do not conflict, they can be put in the same family type, leading to dynamic flexibility. Also, by not allowing conflicting attributes in the same family type, we avoid the semantic complexity. In my samples here, I though that the exclusive and sequential attributes are mutually exlusive, so I put them in different family types. The repetitive attribute does not conflict with the sequential, so I put them in the same family types. When this is used, you write an obligation combining policy. In this you instantiate the family types into family instances. A family instance is a declaration defining the parameters of a family type. In my example I have defined two family instances.

Declaring them like this and making the policy available (however that is done), makes the PDP to combine those obligations according to the defined semantics of the family types and the particular parameters on the instances defined. (Note also that each obligation id may appear only in one family instance to avoid ambiguities.)

I have also included a sample XACML policy which makes use of the obligations in the emergency override family.

<?xml version="1.0" encoding="UTF-8"?>
<PolicySet xmlns="urn:oasis:names:tc:xacml:3.0:schema:wd-01"
        PolicySetId="http://example.com/policyset1"
        PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides">
        <Target />
        <Policy PolicyId="http://example.com/policy1"
                RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides">
                <Target />
                <Rule RuleId="http://example.com/rule1" Effect="Permit">
                        <!-- This rule matches if the access subject is a doctor
                                and the resource is a medical record of one of his patients.
                                This represents a normal access permission which a doctor
                                whould use in daily routine work. -->
                </Rule>
                <Obligations>
                        <Obligation ObligationId="http://example.com/normalAudit"
                                FulfillOn="Permit">
                        </Obligation>
                </Obligations>
        </Policy>
        <Policy PolicyId="http://example.com/policy2"
                RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides">
                <Target />
                <Rule RuleId="http://example.com/rule2" Effect="Permit">
                        <!-- This rule matches if the access subject is any doctor
                                and the resource is any medical record.
                                This represents the right to perform an emergency override
                                on any patient's medical record, and that especially careful
                                audit must be done in case of override use. -->
                </Rule>
                <Obligations>
                        <Obligation ObligationId="http://example.com/heavyAudit"
                                FulfillOn="Permit">
                        </Obligation>
                </Obligations>
        </Policy>
</PolicySet>

There are a number of open questions still remaining. Two that come to mind now are:

1. How are families in turn related to each other?

2. I didn't use URI for identifying the family types. The type is clear from the xsi:type xml attribute, but using names for identifiers is not used much in XACML, so I am not sure if people like that. :)

And, as I wrote earlier, the use cases get more complex with delegation.

ProposalForObligations (last edited 2009-08-12 18:06:41 by localhost)