You are not obliged to follow my advice: Obligations and Advice in XACML part 1

Imagine that you are designing a policy for your business, which happens to be a top-notch hospital, and bump into the following legal requirement:

A physician can access a medical record from one of her patients provided this access is reported to the patient

If you are familiar with XACML, much of this requirement would not be too difficult to structure and implement. The problem you may face starts with “provided…”.

This seems to indicate that it is ok to allow a physician to access medical records of one of her own patients, provided that a notification of some sort is sent to the patient. Who should then be the sender of such a notification? Sounds like a task for the Policy Enforcement Point (PEP); after all, it is the only part of the access control architecture that knows that an action is about to be performed. Now, access to resources other than medical records may not require this extra constraint; how would the PEP know when it is required to send a notification to a patient, and when it is not? The PEP does not know anything about the policy in place the regulate such an action. Also, if the notification is an email where should it be sent? How would the PEP know the email address of the patient?

Welcome to obligations.

Obligations

Obligations are the means by which a Policy Decision Point (PDP) can tell the PEP that a decision is dependent on extra constraints. It is the PEP’s responsibility then to abide by the decision of the PDP only if the extra constraints can be satisfied. One can also think of these extra constraints as commands from the PDP to the PEP.

Obligations are intended to allow a policy writer to express requirements as the one above. Lets take a look at how this could look in XACML.

<Rule Effect="Permit">
    <Description/>
    <Target/>
    <Condition>
        <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:boolean-one-and-only">
            <AttributeDesignator
                AttributeId="urn:careRelationExists"
                DataType="http://www.w3.org/2001/XMLSchema#boolean"
                Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
                MustBePresent="false"
            />
        </Apply>
    </Condition>
    <ObligationExpressions>
        <ObligationExpression ObligationId="urn:notifyPatient" FulfillOn="Permit">
            <AttributeAssignmentExpression
                AttributeId="urn:notification:message"
                Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
                <AttributeValue
                    DataType="http://www.w3.org/2001/XMLSchema#string">Your record was accessed</AttributeValue>
            </AttributeAssignmentExpression>
            <AttributeAssignmentExpression
                AttributeId="urn:notification:recipient"
                Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
                <AttributeDesignator
                    AttributeId="urn:patientId"
                    DataType="http://www.w3.org/2001/XMLSchema#string"
                    Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
                    MustBePresent="false"
                />
            </AttributeAssignmentExpression>
        </ObligationExpression>
    </ObligationExpressions>
</Rule>

OK, that looks a little daunting; lets write our example in the ALFA language, so we get rid of XML noise while retaining XACML goodness,

rule {
  permit
  condition booleanOneAndOnly(careRelationExists)

  on permit {
    obligation notifyPatient {
      message = "Your record was accessed"
      notificationRecipient = patientId
    }
  }
}
obligation notifyPatient = "urn:notifyPatient"
attribute message {
   id = "urn:notification:message"
   type = string
   category = subjectCat
}
attribute notificationRecipient {
   id = "urn:notification:recipient"
   type = string
   category = subjectCat
}

There are a few things to note in this example:

  • Obligations have an identifier, which is used to distinguish different types of obligations
  • Obligations can have arguments
  • Obligations apply to Permit (or Deny) decisions only

A PDP will return, as part of a Permit or Deny response, a (possibly empty) subset of the obligations that appear in the policy.

What should the PEP do about them? Well, any XACML compliant PEP should of course permit or deny the action it is processing, depending on the decision of the PDP, provided it can deal with all the obligations that came with the decision. So, going back to our example, if the PEP receives a Permit along with the obligation to notify the patient, and it has no problems in notifying the patient using the arguments in the obligation, then it should allow the action. Otherwise it should not permit it. What does it exactly mean that it should not permit it? Or more interestingly perhaps, what would it mean not to deny it, if the decision returned by the PDP was Deny?

Welcome to the PEP bias.

PEP Bias

There seems to be a characteristic of PEPs that confuses a lot of developers: the PEP “bias”*.

Consider for a moment the role of PEPs in the access control architecture: PEPs stand between an actor and its ability to access a resource; they either allow something to happen, or they don’t. What is expected from a PEP? Remember that someone else may be writing a policy, in an office far far away.

What a policy writer expects from a PEP is that:

  • Any access that has been denied by the policy should not be allowed
  • Any access that has been permitted by the policy should be allowed
  • Any decision containing obligations is conditional to those obligations being understood and fulfilled

But what happens when there is no decision? That is to say, when either the PDP returned NotApplicable, Indeterminate, or when the obligations of a Permit or Deny decision are not understood or cannot be fulfilled. The PEP still has to either let something happen, or not let it happen. Enter the PEP bias, that is to say, the prescribed behavior of the PEP when there is no decision.

There are three “flavors” of PEPs according with the XACML specification:

Permit-biased PEP

Will allow access when there is no decision.

Deny-biased PEP

Will not allow access when there is no decision.

Base PEP

Will do… whatever it pleases, when there is no decision.

The Base PEP is interesting. It allows the PEP to arbitrarily decide whether to allow access or not when there is no decision from the PDP. Of course, the behavior of the PEP should never actually be just arbitrary; but rather, a behaviour agreed upon by PEP developers and policy writers.

Summing up, your application will function as a compliant PEP if you ensure that:

  • For every access attempt, it will ask the PDP for an authorization decision
  • It will deny access when
    • the PDP decision is Deny with no obligations, or
    • the PDP decision is Deny with obligations, and the obligations are understood, can be fulfilled and will be fulfilled
  • It will permit access when
    • the PDP decision is Permit with no obligations, or
    • the PDP decision is Permit with obligations, and the obligations are understood, can be fulfilled and will be fulfilled

Your application functions as a Base PEP (§7.2.1) only if these requirements are met.

If you application meets the requirements of a Base PEP, and it also meets the requirement:

  • It will deny access in any other case

That is to say, you will ensure that:

  • For every access attempt, it will ask the PDP for an authorization decision.
  • It will permit access when
    • the PDP decision is Permit with no obligations, or
    • the PDP decision is Permit with obligations, and the obligations are understood, can be fulfilled and will be fulfilled.
  • It will deny access in any other case.

Your application functions as a Deny-biased PEP (§7.2.2).

Alternatively, if your application meets the requirements of a Base PEP, and it also meets the requirement:

  • It will permit access in any other case

That is to say, you will ensure that:

  • For every access attempt, it will ask the PDP for an authorization decision
  • It will deny access when
    • the PDP decision is Deny with no obligations, or
    • the PDP decision is Deny with obligations, and the obligations are understood, can be fulfilled and will be fulfilled
  • It will permit access in any other case

Your application functions as a Permit-biased PEP (§7.2.3)**.

Advice

Finally, XACML 3.0 introduces the concept of Advice. Advice is similar to obligations and it shares much of its syntax. The difference is contractual: the PEP can disregard any advice it receives.

Let’s go back to our original example. We used an XACML obligation to implement the requirement that whenever a doctor is given access to one of her patient’s records a notification is sent to the patient. The doctor may not know about this policy, so the management thinks it is fair to inform the doctor that the patient has been notified, even though this is not a legal requirement.

We could use an obligation, similar to the one we used before, to instruct the PEP to also send a notification to the doctor. However, there is a catch: remember that if there is any problem with the notification, the doctor will not be permitted to access the record. This may be too restrictive. What we would want is a way of telling the PEP “try to notify the doctor, but never mind if you cannot”; and this is precisely what XACML advice is intended for. Our extended example could then look like:

rule {
  permit
  condition booleanOneAndOnly(careRelationExists)

  on permit {
    obligation notifyPatient {
      message = "Your record was accessed"
      notificationRecipient = patientId
    }
    advice notifyDoctor {
      message = "The patient has been notified of this access."
      notificationRecipient = doctorId
    }
  }
}
obligation notifyPatient = "urn:notifyPatient"
advice notifyDoctor = "urn:notifyDoctor"
attribute message {
   id = "urn:notification:message"
   type = string
   category = subjectCat
}
attribute notificationRecipient {
   id = "urn:notification:recipient"
   type = string
   category = subjectCat
}

As I mentioned before, the XACML specification says (§7.2) that any advice returned with a decision can be safely ignored by compliant PEPs. This means that PEPs should work as described in the previous section, regardless of what the PEP does with the advice it may receive. For example, a PEP must allow access if it receives a Permit decision with no obligations, regardless of any advice in the decision. In the context of our hospital policy, whether the PEP will allow the doctor to access the record or not will never depend on whether the doctor can be notified.

An interesting use of advice is as a means to tell the PEP the reasons why a request has been denied; but to show you how this is done I would need to introduce you to the way the PDP calculates the advice for a decision. Maybe in a follow-up post? Looking forward to it!

 

* “Bias” appears in the XACML specification in sections §5.1, §5.14, §5.48, §7.2.2 and §7.2.3. Section 5 “Syntax” is normative, but I understand that it is normative about syntax, not about semantics. It is there where a lot a confusion about the bias is introduced. Section 7 “Functional requirements” defines requirements for conformant implementations.

** The specification uses the expressions “understand”, “can fulfill” (or “can discharge”) and “will discharge”. To “understand” an obligation means that the PEP knows what to do with it (e.g: our hospital PEP knows what to do with an obligation called “urn:notifyPatient” but not with one called “urn:discombobulate”). “Can fulfill” means it has all it needs to fulfill the obligation (e.g: it has all the arguments to send the notification). “Will fulfill” means it will actually attempt to fulfill the obligation (e.g: sending the notification).

 

Other Blogs

3 keys to re-evaluate your authorization management
Business
On May 27, I had the pleasure to join the KuppingerCole KCLive event with several industry peers in a panel discussion about  “Enabling the Future...
How OAuth is related to Attribute Based Access Control
Tech
What is Authorization? Authorization, also referred to as Access Control, is the process that follows authentication (which checks your identity and ensures that you are...
Modern Enterprise Authorization Management System
Business
Gartner has an interesting article titled “Modernize Your Runtime Authorization” that highlights some aspects you need from a modern enterprise authorization systems. Over the years...