TGIF XACML – What’s a XACML condition?

It’s that time of the week when the creative juices go south and the urge to relax hits all-time records. And I know you are all craving for some XACML goodness before you head out for the weekend. After all, just a spoonful of XACML makes the… Uh who am I kidding? Let’s get on with this new episode of TGIF XACML. Today, let’s focus on a XACML condition.

Definition

A condition is an element of the XACML policy language. Unlike targets, it can only occur in rules. The condition is used to further define the scope of XACML rules. The scope defines when the rule will trigger. Both the target and the condition therefore help define the scope of policy sets, policies, and rules.

Here’s the OASIS XACML standard’s definition for conditions.

Condition represents a Boolean expression that refines the applicability of the rule beyond the predicates implied by its target. Therefore, it may be absent.

Where can I use a condition?

Conditions can only be used in:

  • rules

Use conditions to define a stricter scope on rules such that they only apply to specific scenarios. Bear in mind that conditions will only be triggered once all parent targets (in the containing rule and parent policy (set)) have been processed.

If we have targets, why use conditions?

Good question! I’m glad you asked. Targets are bit like the simple version of a condition. Targets can only be used to compare an attribute to a value e.g. role==manager. As a result, it’s impossible to express relationships using targets e.g. Permit if user.id==document.owner.id.Enter the condition, bright and bold. Conditions, by contrast to the simpler target, can use any of the functions available in the XACML standard and can compare any number of attributes one to another.

In other words, any time you have to implement relation-based access control, use a condition. Some examples include:

  • Users cannot approve a purchase order they created themselves (Deny if userId==purchaseOrder.creator)
  • Doctors can view the medical records of patients to whom they are assigned (Permit if userId==patient.assignedDoctor)

Other instances where you want to use XACML Conditions is when the attribute values need some kind of manipulation or combiniation. For instance if you want to compare the sum of two numbers to a given limit, then you will need to resort to a condition such as:

sum(integerOneAndOnly(a),integerOneAndOnly(b))<100

Example

The following uses the ALFA syntax. You can download the plugin for free from the Axiomatics website. Check out YouTube for a video example.

/**
 * A manager in purchasing can approve a transaction in the same region
 */
 policy readDocument{
    target clause actionId==&quot;approve&quot; and resourceType==&quot;transaction&quot;
    apply firstApplicable
    rule denyDifferentRegion{
        condition not(userLocation==transactionRegion)
        deny
    }
    rule allow{
    	target clause userRole==&quot;manager&quot; and department==&quot;purchasing&quot;
    	permit
    }
}

The above code implements the example used in a previous post on combining algorithms.

In the above example, note the use of:

Tagged , ,

TGIF XACML – what’s a XACML combining algorithm?

Today’s Friday, the weather is definitely telling us winter is right around the corner. Morning temperatures have been heading south and are flirting with the freezing point. Skies are still clear and a bright blue.

Gamla Stan Rooftops

Bright skies over Gamla Stan as we head towards the darker days of winter


Before the weekend comes knocking, it’s this time of the week when I share a bit of XACML know-how to chew on over the next couple of days. In the training sessions we regularly give at Axiomatics, attendees sometimes struggle with the notion of combining algorithms.

Combining Algorithm

Definition

Combining algorithms are used to resolve conflicts between multiple policies and rules that apply at the same time. Imagine the following use case:

  • Managers in purchasing can approve transactions.
  • A user cannot approve a transaction outside their region.

What happens if Alice, the purchasing manager from Vermont, is trying to approve transaction #123 based in Alabama? If we look at the first rule, then Alice should be able to approve transaction #123. But if we consider the second rule, then should Alice still be allowed to approve the transaction?

We all understand of course that in this example, the overall result should be to deny Alice the right to approve the transaction. The English language has an implicit notion that the restriction applies first. But of course, computers don’t do ‘implicit’. This means we have to declare explicitly what the behavior should be. And in this case, we want the deny case to supersede the permit case. In XACML, that’s achieved by choosing the deny-overrides combining algorithm.

Here’s the OASIS XACML standard’s definition for combining algorithms.

XACML defines a number of combining algorithms that can be identified by a RuleCombiningAlgId or PolicyCombiningAlgId attribute of the <Policy> or <PolicySet> elements, respectively. The rule-combining algorithm defines a procedure for arriving at an authorization decision given the individual results of evaluation of a set of rules. Similarly, the policy-combining algorithm defines a procedure for arriving at an authorization decision given the individual results of evaluation of a set of policies.

Where can I use a combining algorithm?

Combining algorithms must be used in:

  • PolicySet elements
  • Policy elements

Use them in policies to combine the effect of multiple rules. Use them in policy sets to combine the effect of multiple policies, policy sets, policy references, and policy set references.

Example

The following uses the ALFA syntax. You can download the plugin for free from the Axiomatics website. Check out YouTube for a video example.

/**
 * A manager in purchasing can approve a transaction in the same region
 */
 policy readDocument{
    target clause actionId=="approve" and resourceType=="transaction"
    apply firstApplicable
    rule denyDifferentRegion{
        condition not(userLocation==transactionRegion)
        deny
    }
    rule allow{
    	target clause userRole=="manager" and department=="purchasing"
    	permit
    }
}

The above code implements the example used in the first paragraph. The combining algorithm used is firstApplicable which means that if the user is not in the same region as the transaction, then access will be systematically denied.

References

ALFA Reference

  • denyOverrides: urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides
  • permitOverrides: urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:permit-overrides
  • firstApplicable: urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable
  • orderedDenyOverrides: urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:ordered-deny-overrides
  • orderedPermitOverrides: urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:ordered-permit-overrides
  • denyUnlessPermit: urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-unless-permit
  • permitUnlessDeny: urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:permit-unless-deny
  • denyOverrides: urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides
  • permitOverrides: urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-overrides
  • firstApplicable: urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:first-applicable
  • onlyOneApplicable: urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:only-one-applicable
  • orderedDenyOverrides: urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:ordered-deny-overrides
  • orderedPermitOverrides: urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:ordered-permit-overrides
  • denyUnlessPermit: urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-unless-permit
  • permitUnlessDeny: urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-unless-deny
  • onPermitApplySecond: urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:on-permit-apply-second

Other references

Conclusion

I hope this simple example helps to understand the XACML policy language. Stay tuned for more TGIF XACML tidbits.

Previously in TGIF XACML…

Previous tidbits can be found here:

Authorization, it’s not just about who you are – feedback from JavaZone 2013

I was fortunate enough to be one the speakers at JavaZone 2013 in Oslo, a stone’s throw from the Axiomatics headquarters in Stockholm. One of the organizers, Ole-Alex had asked me to give an overview of XACML to a crowd of Java developers and architects.
I decided to focus on the consolidation and flexibility aspects of XACML. For a developer, the natural reflex when it comes to implementing authorization is to “do-it yourself” or at best to use a framework, e.g. Spring Security or JAAS. While these frameworks are great and the right step towards externalized authorization, they fall short of implementing truly dynamic authorization.
The first part of the presentation therefore covers the current state of the art before introducing Attribute-based access control (ABAC) and then diving into XACML, the eXtensible Access Control Markup Language.
The latter part of the presentation focused on hands-on examples of policy enforcement points for Java: servlet filters, JAX-WS handlers, and annotations-based enforcement courtesy of my colleague Andreas Sjoholm. We also looked into authoring policies using the ALFA plugin for Eclipse – a free tool to author XACML policies that uses an abstraction language called ALFA.
The slides are available on SlideShare as usual and are also embedded hereafter:
.
The video of the presentation will be made available shortly on JavaZone’s Vimeo album.
The presentation was well received and sparked some interesting questions around performance (yes, it’s possible to embed a PDP inside an application), attribute retrieval (yes, you can cache attribute retrieval), and database access control. Axiomatics whom I work for does provide an extension to XACML to be able to convert authorization policies into SQL statements.
Lastly, as mentioned before, this piece of work wouldn’t be possible without the XACML Technical Committee. So if you want to give back, feel free to join the conversation at OASIS.

EDIT September 16th
The video has now been put up online here.

TGIF XACML – What’s a XACML target?

Today’s Friday, the weather has been amazingly nice these past few weeks in Stockholm which is all the more surprising since September is on the slope down to darker, wetter, and colder days. The weekend ahead looks promising. I’ll be heading out to fellow colleague, Andreas’ summer house out in the archipelago.

The view from the Axiomatics offices towards Skeppsholmen and AF Chapman

The view from the Axiomatics offices towards Skeppsholmen and AF Chapman


But before I walk out the door, I thought I’d share a bit of XACML know-how to chew on over the next couple of days. In the training sessions we regularly give at Axiomatics, attendees often ask what a target is.

XACML Target

Definition

A target is an element of the XACML policy language. It can occur in policy sets, policies, and rules. The target is used to define their scope. The scope defines when the policy (set) / rule will trigger. For instance, for a rule to trigger and yield a Permit decision for managers in Greece, the target would have to contain two attribute matches:

  • role==manager, and
  • userLocation==Greece

There can be any number of matches. A match is always between an attribute (role, department, location, classification…) and a value. Matches can then be assembled together using logical operands (AND, OR).

Where can I use the target?

Targets can be used in:

  • Policy Set elements
  • Policy elements
  • Rule elements

Example

The following uses the ALFA syntax. You can download the plugin for free from the Axiomatics website. Check out YouTube for a video example.

/**
 * A user in Greece can read a document in the Greece region
 */
 policy readDocument{
 	target clause actionId=="read" and resourceType=="document"
 	apply firstApplicable
 	rule allowReadIfCorrectRegion{
 		target clause userLocation=="Greece" and documentRegion=="Greece"
 		permit
 	}
 }

The above example will yield a Permit if and only if the user trying to read a document based in Greece is also based in Greece.

Conclusion

I hope this simple example helps to understand the XACML policy language. Stay tuned for more TGIF XACML tidbits.

Previously in TGIF XACML…

Previous tidbits can be found here:

Tagged , , , , , ,

XACML for Developers – Updates, New Tools, & Patterns for the Eager #IAM Developer

At the Cloud Identity Summit 2013, CIS Napa, last week, I had the privilege to be part of one of the sessions Hans Zandbelt was leading on advanced identity concepts. I chose to dive deeper into XACML and to provide updates for the developer specifically.
My slides are available from slideshare and below.