Page 1
Standard

Use JAXB and Ant to generate Java POJOs for XACML 1.1, XACML 2.0, and XACML 3.0 policies

In a previous blog post, I mentioned that I was working on a conversion script for a client to migrate XACML 1.1 policies to XACML 3.0.

There are several ways this could be achieved. Here are the ways I have thought of:

  • Use XSLT to convert from the XACML 1.1 schema to the XACML 3.0 schema. This is possibly a purist’s way of approaching this. However support for XSLT has not always been great and it requires a lot of XML, XPath, and XSLT know-how.
  • Use the Java DOM model to parse XACML 1.1 XML and create XACML 3.0 XML.
  • Use JAXB to generate POJOs (plain old Java objects) that represent XACML 1.1 and XACML 3.0. I chose the latter approach. For a Java developer, this is perhaps the easiest way.

The first step of the conversion was of course to generate the POJOs that would let me manipulate the XACML policies. To do so, use the xjc utility that is now part of the Oracle JDK. Hereafter is a sample code snippet from my ant build script. You will need to have downloaded the XACML 1.1, 2.0, and 3.0 schemas first. Note that the XACML 1.1 and 2.0 schemas only include the policy definitions whereas the XACML 3.0 schema also includes the request / response schema.

	<target name="generate">
		<delete dir="generated" failonerror="false" />
		<mkdir dir="generated" />
		<taskdef name="xjc" classname="com.sun.tools.xjc.XJCTask">
			<classpath refid="master-classpath" />
		</taskdef>
		<xjc schema="etc/schemas/cs-xacml-schema-policy-01.xsd" destdir="${src.gen.dir}" />
		<xjc schema="etc/schemas/access_control-xacml-2.0-policy-schema-os.xsd" destdir="${src.gen.dir}" />
		<xjc schema="etc/schemas/xacml-core-v3-schema-wd-17.xsd" destdir="${src.gen.dir}" catalog="catalog.cat"/>
	</target>

And there we go, I ended up with a series of Java classes that I could use to marshall / unmarshall XML into/from Java objects. From there on, it was child’s play to write the conversion script. I’ll post a couple of interesting findings on the conversion. To test the conversion, I used the XACML 1.1 conformance tests which can be found here.

Standard

TGIF XACML – What’s a XACML Obligation?

Definition

The XACML standard defines the concept of obligations which are elements which can be returned along with a XACML decision (either of Permit or Deny) in order to enrich that decision. Obligations are triggered on either Permit or Deny. The Policy Enforcement Point must implement and enforce obligations. If it fails to do so, it must deny access to the requested resource (in the case of a Permit).

The XACML 3.0 standard defines obligations as follows:

An operation specified in a rule, policy or policy set that should be performed by the PEP in conjunction with the enforcement of an authorization decision

Where can I use an Obligation?

Obligations can be defined in PolicySet, Policy, and Rule elements. This is illustrated in the XACML class diagram below.

XACML 3.0 Class Diagram - taken from the eXtensible Access Control Markup Language (XACML) Version 3.0

XACML 3.0 Class Diagram – taken from the eXtensible Access Control Markup Language (XACML) Version 3.0

Use cases

Obligations are extremely useful to enrich the otherwise simple (and binary) authorization flow. Here are some examples where obligations help take XACML the extra mile:

  • Break-the-glass scenarios: one common scenario in healthcare is to control access to medical records. By default, only those physicians a patient has a relationship to should have access to that patient’s medical. Well, what happens then if the patient is critically ill in an unfamiliar setting e.g. while on a vacation to a different city or country altogether? Should we still deny access to the information? Of course not: the medical staff should have the ability to override the default Deny. This is achievable through a break-the-glass scenario. The first time the medical staff request the information, they will get a Deny + obligation to set an emergency flag in the case that the situation is indeed an emergency flag. Once the flag is set, the medical staff can request access again in which case they will be granted access.
  • Accountability: another great example of obligations is a follow-up to the previous case. What’s to prevent a doctor from waving the emergency flag needlessly for the sole purpose of getting illicit access to medical records? Another obligation of course. This obligation, this time, is to log the fact that a doctor was granted access to a medical record that would have otherwise been off limits because that given doctor used the break-the-glass scenario. The PEP will be responsible for logging the access in a special central log which will be later used to hold the doctor accountable.
  • Notifications: Let’s switch scenarios and move to banking. Let’s imagine a user is repeatedly trying to transfer $1,000. The first time, he/she is denied access, the second time as well. The third time though, not only is the user denied access but on top of that an email alert is triggered through an obligation. The alert can be sent to an administrator, a manager or another user for immediate action. This type of approach leads to more proactive security systems and therefore more secure systems.
  • Strong authentication: another interesting scenario hauls from the banking sector. Imagine the use case where a user logs into their bank account using weak authentication (username / password). That may be enough to get them into their account overview to check their balance. It won’t be enough however to get users to transfer money from one account to another. Yet, as a friendly bank, we want to let our customers get the most out of online banking. In this case, when the user tries to transfer money, they will be denied access plus they will get an obligation which will reroute them to a page where they can enter a one-time password to augment and strengthen their authentication after which they will be able to transfer money. This enables a much more positive user experience than simply denying the user access.

Example in ALFA

First of all, it’s necessary to define the obligation identifiers. This is done as follows:

namespace com.axiomatics.examples{
	import Attributes.*
	
	obligation logExceptionalAccess = "com.axiomatics.examples.obligations.logExceptionalAccess"
	obligation breakTheGlass = "com.axiomatics.examples.obligations.breakTheGlass"
}	

We can now use the newly defined obligations inside a policy ensemble:

namespace com.axiomatics.examples{
	import Attributes.*
	
	obligation logExceptionalAccess = "com.axiomatics.examples.obligations.logExceptionalAccess"
	obligation breakTheGlass = "com.axiomatics.examples.obligations.breakTheGlass"
	
	/**
	 * Control access to medical records
	 */
	policyset allowAccessMedicalRecords{
		target clause resourceType=="medical record"
		apply denyOverrides  
		/**
		 * Doctors - control access to medical records
		 */
		policy doctorsView{
			target clause userRole=="doctor" and actionId=="view"
			apply firstApplicable
			/**
			 * The assigned doctor can view the medical record
			 */			
			rule regularAccess{
				permit
				condition subjectId==assignedDoctorId	
			}			
			/**
			 * Any doctor can view the medical record if the emergency flag is on
			 */
			rule emergencyAccess{
				condition emergency==true
				permit
				on permit{
					obligation logExceptionalAccess{
						message = "The following doctor has requested access to a medical record"
						recordId = resourceId
						doctorId = subjectId
					}
				}
			}		
			/**
			 * Deny
			 */
			rule breakTheGlass{
				deny
				on deny{
					obligation breakTheGlass{
						message = "You do not have access to this record. Please set the emergency flag to true to gain access."
					}
				}
			}	
		}

	}
}

The example consists of one policy set with a nested policy inside which in turn contains 3 rules. The policy set scopes the access to medical records. The policy scopes it to doctors and the action view. The three rules work as follows:

  • Rule #1: this rule applies to doctors who have a care relationship with the patient. The access is then granted.
  • Rule #2: this rule applies when a doctor has enabled the emergency flag. Access is then granted and an obligation kicks in to log the special access for accountability.
  • Rule #3: this rule applies when a doctor tries to access a record they do not normally have access to. Access is denied and an obligation is returned to let the doctor they can gain access by waving the emergency flag.

Differences from previous versions of XACML

It’s worth noting that previous versions of XACML (XACML 2.0 and older) do have obligations but these do not allow for variables inside. One of the compelling points of obligations in XACMCL 3.0 is that you can have dynamic variables. For instance, in the example above, the logExceptionalAccess obligation contains three variables: message, recordId, and doctorId. The first one, message, is static. The 2 other ones contain the values resolved at runtime, when access is being granted or denied.

Conclusion

The obligations feature of XACML make the authorization language even more powerful by enabling advanced scenarios such as trust elevation, notifications, and break-the-glass. For more information, head on over to Axiomatics’ website. We provide training courses on-demand.

Previously in TGIF XACML…

Previous tidbits can be found here:

Standard

XACML 1.1 Class Diagram

I’ve been recently working on an interesting little project: converting XACML 1.1 policy (sets) to XACML 3.0 policies in order to help migrate a customer from a legacy environment to Axiomatics.

In order to proceed with the conversion, I decided to use stock tools available off-the-shelf and custom code as little as possible. Since I write in Java, I chose to go for JAX-B especially since the support for JAXB has become better and better over the years. XJC itself is part of the JDK and it makes generating Java classes from XML schemas a breeze.

I’ll talk some more about that in a separate post. In the meantime though, I wanted to share with you an old picture, the class diagram for XACML 1.1. I extracted it from the core specification documentation which can be found here.

XACML 1.1 Policy Language UML Class Diagram

This UML class diagram shows the elements of the XACML 1.1 policy language

In this class diagram, the structural elements of XACML are clearly shown:

  • PolicySet
  • Policy
  • Rule

I’ll keep you updated on the conversion progress.

Standard

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:

  • a target: target clause userRole=="manager" and department=="purchasing"
  • a condition: condition not(userLocation==transactionRegion)

References

Conclusion

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

Previously in TGIF XACML...

Previous tidbits can be found here:

Standard

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: