What Does NotApplicable Mean?

Axiomatics   ·   Thursday, July 28th, 2016

The Policy Enforcement Point (PEP) sends the PDP an authorization request. The PDP inspects the request and must return a decision. There are four possible decisions:

• Permit
• Deny
• NotApplicable
• Indeterminate

If operating correctly, the PDP must always return one of these 4 decisions. Permit and Deny are the decisions returned under normal conditions: a policy has concluded that access should either be granted or denied. Indeterminate implies that, during the policy evaluation, an error occurred. The root cause could be that there is an incorrect amount of information (for instance a user has two dates of birth) or that an underlying component – typically a policy information point (PIP) – is malfunctioning.

What About NotApplicable?

NotApplicable means that the PDP does not have any policy that matches the incoming request. If, for instance, the PDP has policies about viewing and approving banking transactions, and if the authorization request is about a doctor trying to view a medical record, the PDP won’t be able to reach a conclusion: there is a mismatch between the request and the response.

When developing and testing policies, NotApplicable can occur if the values sent have typos in them or the wrong capitalization.

For instance if the policy states that access is permitted if the user’s role is manager and if the request says Alice is a Manager (with a capital M), then the policy will fail and the decision returned will be NotApplicable.

This also means that in XACML, the opposite of a desired effect e.g. Permit is not Deny. Conversely the opposite of Deny is not Permit. If a Permit policy does not apply, the default result will be NotApplicable.

Let’s imagine the following scenario: we want to write a policy that control who can drink. There are 2 rules: under-age users cannot drink. Drivers cannot drink. Everyone else can.

If we have a policy that states: deny if age < 21, it does not mean that all adults are still allowed to drink. The PDP will not conclude Permit. Rather the PDP will continue to process the following rules. The following rule could be deny if role == ‘driver’. A 23-year old driver would therefore get access denied.

Often times, NotApplicable will be triggered because of a missing attribute value.

The Impact of Missing Attribute Values on Policy Evaluation

In ALFA, the policy for the drinking scenario could be implemented as:

   policy drinkAlcohol{
          target clause action == "drink" and resource == "alcohol"
          apply firstApplicable
          rule denyUnderAge{
                 target clause age < 21
                 deny
          }
          rule denyDriver{
                 target clause role == "driver"
                 deny
          }
          rule allow{
                 permit
          }
   }

Let’s have a look at the following scenarios:

• Scenario #1
  • Request: Can Alice drink alcohol?
  • Response: Yes, Permit.
• Scenario #2
  • Request: Can Bob who is 27 and is not the designated driver drink alcohol?
  • Response: Yes, Permit.
• Scenario #3
  • Request: Can Carol who is 15 and is not the designated driver drink alcohol?
  • Response: No, Deny.
• Scenario #4
  • Request: Can Dan who is 27 and is the designated driver drink alcohol?
  • Response: No, Deny.

Scenarios 2, 3, and 4 make sense. The request has all the information to reach a conclusion. Scenario 1, however, does not provide Alice’s age or role. Yet, because of the way the policy was written, access is granted. This means that it may be best to rewrite the policy as:

   policy drinkAlcohol{
          target clause action == "drink" and resource == "alcohol"
          apply firstApplicable
          rule allowNonDriversOver21{
               target clause age ≥ 21
               permit
               condition not(role=="driver")
          }
   } 

If we revisit our scenarios, we get the following results:

• Scenario #1 → NotApplicable

• Scenario #2 → Permit

• Scenario #3 → NotApplicable

• Scenario #4 → NotApplicable

Hiding NotApplicable

Sometimes, we do not want to have any NotApplicable decisions returned from the PDP to the PEP. We want the policy evaluation to be binary: either it is Yes, Permit, or No, Deny. In that case, we can use two approaches:

1. Include a “catch-all” policy that will default to Permit or more commonly Deny if no other policy has kicked in.
2. Use a special combining algorithm that will guarantee the resulting decision to be Permit or Deny:
   1. deny-unless-permit
   2. permit-unless-deny

Using a Catch-all Policy

In the first scenario, the policy structure looks like the following (using ALFA notation). The top-level policy which contains the application policies and the catch-all policy must use a first-applicable combining algorithm. The catch-all policy must come last.

namespace example{
          policyset global{
               apply firstApplicable
               applicationPolicies
               /**
               * This policy always returns deny
               */
               policy catchAll{
                    apply firstApplicable
                    /**
                    * This rule always returns deny
                    */
                    rule catchAll{
                         deny
               }
          }
   }
   policyset applicationPolicies{
          apply firstApplicable
          /**
          * Implement your authorization scenarios here.
          */
   }
}

Using a Special Combining Algorithm

As of XACML 3.0, there are two new combining algorithms that can help us achieve a default decision with having to use an extra catch-all policy. These combining algorithms are:

• deny-unless-permit and
• permit-unless-deny.

These are both specified in the XACML 3.0 standard.

This means that if the overall result were to be NotApplicable (or Indeterminate), then these 2 decisions will be masked with Deny in the former case and Permit in the latter.

We can now rewrite our example as follows:

namespace example{
   policyset global{
          apply denyUnlessPermit
          applicationPolicies
   }
   policyset applicationPolicies{
          apply firstApplicable
          /**
          * Implement your authorization scenarios here.
          */
   }
}

Processing NotApplicable in the Policy Enforcement Point

If the PDP does return NotApplicable to the PDP, the PEP must decide what to do: will it grant access or will it deny access?

To resolve this conundrum, the PEP uses a bias. The bias is a property of the PEP. A bias can be a Permit-bias or a Deny-bias. The PEP acts as follows:

• Permit-biased PEP: deny if the PDP says Deny; otherwise permit access.
• Deny-biased PEP: permit if the PDP says Permit; otherwise deny access.

Deny-biased PEPs are more common.

Conclusion

When implementing your policies and your PEP, think about your NotApplicable cases – do you want to hide them? Do you want to process them in a special way? Do you want to report on them?

One common pattern is to write a policy as follows:

1. Use the first-applicable combining algorithm
2. First define the negative cases e.g. blacklisted users
3. Then define the positive cases: managers can view records
4. Finally add a catch-all policy that will default to deny