· The Sun XACML is a Java implementation of the XACML specification. It is used to test evaluate the XACML policies based on the request files given to it.

· Eclipse Development Environment –

· Eclipse provides an excellent Java Development Environment. Opening the Sun XACML project and working with the sample applications is easier through the Eclipse Environment as compared to a traditional command line interface.

· XACML Documents

· http://www.oasis-open.org/committees/xacml/

· These documents are the actual specification of the XACML standards. This is the absolute documentation available on XACML.

· Sun XACML Programmer’s Guide

· http://sunxacml.sourceforge.net/guide.html

· A guide which introduces XACML and also gives instructions on how to program using the Sun XACML api.

· XACML Java Based Policy Editor

· http://xacml.dif.um.es

· This is a Java based Editor that was used to create the XACML policies. It eases the work of policy writing by providing an interface specifically meant for XACML policies.

· Xpath Tutorials

· http://www.w3schools.com/xpath/default.asp

· Xpath must be understood to use certain features provided by the XACML specification.

· XML editor

· For editing of the policies and requests. I used VS 2005 IDE for opening XML files. There are many tools available, Google on it and use the tool you are most comfortable with.

· XML Security: Control information access with XACML

· http://www.ibm.com/developerworks/xml/library/x-xacml/

· Introduction To XACML

· http://dev2dev.bea.com/pub/a/2004/02/xacml.html

Introduction

Welcome and thanks for viewing this tutorial. This tutorial is targeted to all those people who wish to start using XACML for access control and privacy policy enforcement in their systems. Before proceeding I would like to advice the reader to gain some background information about Access Control, Privacy Policies, and the basic idea behind XACML. Although I have tried to keep the usage of the technical terms to the minimum, there may have been places where there usage becomes unavoidable.

By the end of this tutorial the reader will have a good idea about the following aspects:

1. Learn about XACML semantics and its tags.

2. Learn how to systematically create XACML policies and requests.

3. Learn how to use the Sample PDP application provided by Sun XACML implementation for testing the policies and requests that have been constructed.

The tutorial proceeds by introducing a Use Case Scenario in which XACML can be useful. A small system analysis is presented after this. This will help the reader to understand what we are really trying to achieve by using XACML. A small XML Database is then created for the system. The tutorial then explains how one can proceed systematically to create their XACML policies and test them against XACML request files. Each policy that is created will introduce certain aspects of XACML that will make the reader clearer about the XACML tags and semantics.

In development of an XACML privacy aware access control system, writing of XACML policies will probably be the first step in the system development stage. The next step in the development stage would be automation of the process of generating XACML requests. In this tutorial we will put more emphasis on how to create XACML policies for requests that we have manually created. The programmer docs are an excellent guide for all those who wish to develop software using the Sun XACML Classes.

This guide is meant to supplement many XACML documentations available by providing a scenario in which XACML can be used. It is a small attempt to share whatever knowledge I have gained while working XACML. Others are invited to expand on this tutorial and add their ideas and improve it.

I would like to request you to bring to my notice any errors that might have crept into the document.

Before proceeding ahead I would advise the reader to go through the Introduction to XACML section in Sun XACML Programmer’s Guide. That would be very beneficial.

With that done let us proceed :-)

XACML Basics

XACML is an OASIS ratified general purpose access control language. It is used to model policies in XML format. The request to access resources and their corresponding response is also specified using XML. In a general situation there is an authorization system for different organizations or services (web or otherwise) which is responsible for granting or denying access to certain resource. These decisions are taken based upon various policies. Till now access control and privacy policy enforcement has been done in an ad-hoc manner. By this I mean there has been no standard method across different organizations for access control. A common standardized method of access control and policy enforcement sounds like a great idea! Think how madness would ensue if two organizations were to merge? How would their separate access policies be merged? Now if both organizations used the same standard procedure then there would be no such hassles. Cool isn’t it?

In this tutorial I’ll discuss the basics and not delve into the nitty gritties of XACML components, as that has already been done in the Official Document and in other documents. I will present information that should be enough to get you going and understanding this tutorial.

Let us think of a simple application which is responsible for enforcing the policies we have. Broadly we will have two components for it [in actuality there are many more, check out the official documents, but for the sake of brevity we will skip them]:

1. A Policy Enforcement point or PEP

2. A Policy Development Point or PDP

PEP & PDP

The PEP is the component of the software which the user sees. It is the PEP which is responsible for taking the user requests. It forwards this request to the PDP which uses the XACML system. The PDP will take the request and based on the XACML policies defined return a response to the PEP. The PEP will have a way to parse the XML response and take action based on the response. The responses can either Permit/Deny/Say Not Applicable if no policies exist or say Indeterminate if any other situation exists for eg: multiple policies become applicable.

The various components of an XACML policy are:

PolicySets [Policy Combining Algorithm]

1. Policy [Rule Combining Algorithm]

a. Target

i. Subject Attributes

ii. Resource Attributes

iii. Action Attributes

iv. Environment Attributes

b. Rule [Effect]

i. Subject Attributes

ii. Resource Attributes

iii. Action Attributes

iv. Environment Attributes

v. Conditions

c. Obligations

Basic Terms

I am loosely explaining some basic terms here, so that the tutorial is readable.

· Policy Set – A policy set is an aggregation of various Policies or Policysets. The result from evaluation of different policies must be intelligently combined to yield a well defined result. That is done using Policy Combining Algorithms.

· Policy – A policy can be defined as a level of defining access to particular resources.

· Rule – Rules are used to identify various conditions or cases under which a policy may become applicable. Based on the result of these rules different policies can become applicable.

· Target – A target is used to specify information which helps the XACML system uniquely identify a PolicySet/Policy/Rule. Based on certain information contained as Attributes the XACML system is able to decide which PolicySet/Policy/Rule can be applicable.

· Attribute – Attribute is nothing but a way to describe certain aspects of a Subject/Resource/Action or Environment.

· Subject – Attributes that describe of the user who has made an access request.

· Resource – Attributes that describe the object to which access is requested, or other variables about which we must maintain some information.

· Action – Attributes that describe what action the subject wants to take on the requested resource.

· Environment – Attributes of this type hold information about the environment in which the request was made like the time of day etc.

· Attribute Designators – Attribute Designators are a way to reference to Attributes specified in the request from within the XACML policy. Imagine each Attribute to have some ID in the request. Using Attribute Designators in the policies we can access the values of these Attributes very easily.

· Attribute Selectors – Attribute Selectors work in a manner very similar to Attribute Designators. However they are normally used to reference to attributes which cannot be directly specified as Attributes within the request, but as raw XML data. Attribute Selectors use Xpath expressions to resolve the information contained within those XML structures.

System Definition

Use Case:

Consider a scenario in which an academic institution maintains the marks of students in three different subjects. It wishes to have an automatic access control enforcement system, which also respects the privacy concerns of its students. The policies are defined in the subsequent sections.

There are four different roles namely:

1. Dean

2. Head

3. Teacher

4. Student

There are two branches namely:

1. Information Technology [IT]

2. Computer Engineering [CS]

The Student marks are stored in an XML database. It can be represented as a relational table as shown below:

	Sub1[IT]	Sub2[CS]	Sub3[CS]
Student1	76	96	84
Student2	86	79	85
Student3	45	89	100

We wish to achieve fine grained access control for each Role to the three resources namely:

1. Sub1 [of branch IT]

2. Sub2 [of branch CS]

3. Sub3 [of branch CS]

By fine grained access control I mean that access to each cell of the relational table described above will be defined using XACML policies.

The three students are in the IT branch, but study subjects from other disciplines [CS] as well.

Access policies and their privacy requirements

Different policies must be constructed for each role. The steps taken to define these policies in a systematic manner are shown below. For each role and each resource we explicitly mention the access control decision in form of a table as shown below:

	Resources				Privacy Policy Parameters
Role	Sub1[IT]	Sub2[CS]	Sub3[CS]	Action	Purpose	Obligations
Dean	Permit	Permit	Permit	View	GradeSheetEvaluation	Email Student
Head[IT]	Permit	Deny	Deny	View	Moderation	Email Student
Head[CS]	Deny	Permit	Permit	View	Moderation	Email Student
Teacher1 [Sub1]	Permit	Deny	Deny	Edit	Marking	NA
Teacher2 [Sub2]	Deny	Permit	Deny	Edit	Marking	NA
Teacher3 [Sub3]	Deny	Deny	Permit	Edit	Marking	NA

The Access Control policies for Students are as follows:

Action: View

Obligations: NA

Role		Resources			Privacy Policy Parameters
Subject	Target	Sub1[IT]	Sub2[CS]	Sub3[CS]	Purpose
Student1	Student1	Permit	Permit	Permit	NA
Student1	Other Student	Conditional*	Conditional*	Conditional*	Analysis
Student2	Student2	Permit	Deny	Deny	NA
Student2	Other Student	Conditional*	Conditional*	Conditional*	Analysis
Student3	Student3	Permit	Deny	Deny	NA
Student3	Other Student	Conditional*	Conditional*	Conditional*	Analysis

*Conditional means that the Subject Student must be permitted by the target student to view his marks for the purpose of analysis. We will discuss this in the sections to come.

XML Database

In reality this database would be built using XML DBs like eXist. For the sake of simplicity we have simply maintained it as a simple file.

<db_acad>

<users>

<user>

<username>admin1</username>

<password>xacml</password>

<role>admin</role>

</user>

<user>

<password>xacml</password>

</user>

<user>

<password>xacml</password>

</user>

<user>

<password>xacml</password>

</user>

<user>

<username>teacher1</username>

<password>xacml</password>

<role>teacher</role>

</user>

<user>

<username>teacher2</username>

<password>xacml</password>

<role>teacher</role>

</user>

<user>

<username>teacher3</username>

<password>xacml</password>

<role>teacher</role>

</user>

<user>

<username>student1</username>

<password>xacml</password>

<role>student</role>

<dean_view_once>false</dean_view_once >

<email>student1@acad.com</email>

<marks>

</marks>

</user>

<user>

<username>student2</username>

<password>xacml</password>

<role>student</role>

<permit>student1</permit>

<permit>student3</permit>

<dean_view_once>false</dean_view_once>

<email>student2@acad.com</email>

<marks>

</marks>

</user>

<user>

<username>student3</username>

<password>xacml</password>

<role>student</role>

<dean_view_once>false</dean_view_once>

<email>student3@acad.com</email>

<marks>

</marks>

</user>

</users>

</subject>

</subject>

</subject>

</subjects>

</db_acad>

File Structure

The policy and request files can be downloaded from these links:

Policies

1. Student.xml

2. Head.xml

3. Dean.xml

4. Teacher.xml

Requests

1. Student_request.xml

2. Head_request.xml

3. Dean_request.xml

4. Teacher_request.xml

Namespaces chosen

The namespaces must be chosen very carefully, as they are required by the Sun XACML implementation for accessing various kinds of information of Subjects, Resources, Environments, and Actions from the request file. For our purpose we will stick with some standard namespaces as given in many standard XACML examples.

For Policies

xmlns="urn:oasis:names:tc:xacml:1.0:policy"

xmlns:context="urn:oasis:names:tc:xacml:1.0:context"

xmlns:db="db_acad"

xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

For Requests

xmlns="urn:oasis:names:tc:xacml:1.0:context"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:db="db_acad"

Attribute Information

Attributes are nothing but “variables” whose values are required for different reasons. Attribute ID for each attribute must be chosen with care. We must keep in mind, the logical structure of our database. These attribute IDs are used much like “variable names” to extract information from different sources within the XACML request document and from external databases. The following table shows the different attributes which will be used within the context of the XACML policies, and requests. To maintain a uniformity and prevent errors from cropping up, we will construct a table of all attributes used for easy referencing while construction of the XACML policies.

Attribute value	Attribute – ID	Data Type
username	db_acad_users_user_username	http://www.w3.org/2001/XMLSchema#string
branch	db_acad_users_user_branch	http://www.w3.org/2001/XMLSchema#string
role	db_acad_users_user_role	http://www.w3.org/2001/XMLSchema#string
name	db_acad_subjects_subject_name	http://www.w3.org/2001/XMLSchema#string
branch	db_acad_subjects_subject_branch	http://www.w3.org/2001/XMLSchema#string
sub1	urn:oasis:names:tc:xacml:1.0:resource:resource-id	http://www.w3.org/2001/XMLSchema#double
sub2	urn:oasis:names:tc:xacml:1.0:resource:resource-id	http://www.w3.org/2001/XMLSchema#double
sub3	urn:oasis:names:tc:xacml:1.0:resource:resource-id	http://www.w3.org/2001/XMLSchema#double
Purpose	policy_purpose	http://www.w3.org/2001/XMLSchema#string

The Road Ahead

After fixing some basic information for the system, this is how we will proceed now:

1. Learn how to write a basic XACML request for a specific role.

2. Learn how to construct an XACML policy for a specific role.

For each role, we will first construct a request XACML file, and then proceed to making the policy file. I personally feel that it becomes easier to write an XACML policy file once we have its request file ready. I think in due time you will also realize the same thing.

XACML Requests

If you imagine XACML PDP as a black box the input to it is the XACML request file. The output is an XACML response to the request.

Based on these request files, an XACML policy is checked to see if the requested access to a certain resource is allowed or not. By evaluating certain policies within the black box the XACML PDP is able to generate a response to the request made.

Here is a sample request to get things started:

<?xml version="1.0" encoding="UTF-8"?>

<Request xmlns="urn:oasis:names:tc:xacml:1.0:context"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:db="db_acad">

<Attribute AttributeId="db_acad_users_user_username"

DataType="http://www.w3.org/2001/XMLSchema#string">

<AttributeValue>student2</AttributeValue>

</Attribute>

<Attribute AttributeId="db_acad_users_user_role"

DataType="http://www.w3.org/2001/XMLSchema#string" >

<AttributeValue>student</AttributeValue>

</Attribute>

<Attribute AttributeId="db_acad_users_user_branch"

DataType="http://www.w3.org/2001/XMLSchema#string" >

</Attribute>

</Subject>

<db:user type=”target”>

<db:username>student2</db:username>

<db:password>xacml</db:password>

<db:role>student</db:role>

<db:branch>IT</db:branch>

<db:permit>student3</db:permit>

<db:permit>student1</db:permit>

<db:marks>

<db:sub1>86</db:sub1>

<db:sub2>79</db:sub2>

<db:sub3>85</db:sub3>

</db:marks>

</db:user>

</ResourceContent>

<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"

DataType="http://www.w3.org/2001/XMLSchema#string">

</Attribute>

</Resource>

<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"

DataType="http://www.w3.org/2001/XMLSchema#string">

</Attribute>

</Action>

</Request>

When analyzed the request file is broadly divided into three sections.

1. <Subject>

2. <Resource>

3. <Action>

<Subject>

The <Subject> section describes the attributes of the user who has made an access request to some resource. The three attributes that are used to describe the requesting subject in this case are:

1. Username

2. Role

3. Branch

The value of each <Attribute AttributeId=”foo”> is stored within <AttributeValue> tags.

This information can be accessed through an XACML policy by the use of <AttributeDesignator> tags. They have been described in the subsequent sections.

<Action>

The <Action> section is used to describe what action the subject or reqeusting user wishes to take on the requested resource.

The action that student2 wishes to take is view the resource sub2.

<Resource>

The <Resource> section describes the resources in the request file. The two resources described in the Resources section are:

· <ResourceContent>

· Resource Requested – sub2 – ID - urn:oasis:names:tc:xacml:1.0:resource:resource-id

In addition to information provided in the request context, an XACML policy might require extra information to make decisions. This extra information is retrieved from an external database and put in the XACML request file. The information required by the XACML policy for this request is the information of the target student whose marks are sought. This information is wrapped within the <ResourceContent> tag.

External Resource Information in XACML request files

Each XACML policy requires certain amount of information (from external sources) to make decisions to Permit/Deny access to resources. This information is provided in the form of <ResourceContent> within the XACML request file. However all policies might not require the same type of information.

Example: A policy might require information of both the Requesting Subject and the Target Student for making decisions. Another policy in addition might require information about a particular subject that is taught in the institution. You will see numerous examples of this in the coming request and policy files.

So we must clearly decide what all external information has to be included within a request file. This concept of deciding on what information to include and what not, requires planning and certain amount of foresight and experience. Some algorithms must be developed which will automatically figure out what information must be fetched from the external data store and put in the request file, based on the request made by the user. This is a step in the automation of XACML request generation, which we will not discuss here. It is sufficient to assume that whatever information the XACML policy requires will be available to it in the <ResourceContent> section of an XACML request file.

Now that we have understood the semantics of an XACML request we can describe the above request in plain english:

The user whose username is “student2” of branch “IT” having role “student” wishes to access the resource “sub2” of the target student whose username is “student2”. The information of the target student is picked from the XML Database which was mentioned above, and wrapped within the <ResourceContent> tag. This information can be accessed from within an XACML policy using an Xpath Expression. The user wishes to perform the action “view” on the requested resource.

With the understanding of an XACML request we are ready to proceed to the next step of making XACML Policies.

Role Based Access Control Policies

In the subsequent sections we will develop the policies for different roles. While we move along the way we will encounter many XACML tags which we will discuss one by one.

Role: Student

Description: A student can view their own marks or view the marks of another student for analysis purpose if they are permitted to do so.

PolicyID: Student

File Name: student.xml

Uniquely Identifying a Policy: The <target> element

There are many policies for an XACML implementation to consider. How can, then the implementation automatically find out which policy/PolicySet can be applicable to a particular XACML request?

In XACML each policy has a <target> element associated with a <PolicySet>, <Policy> or <Rule> tag. A PolicySet is nothing but a combination of several policies aggregated together. A specification of these target values help XACML implementation in identification of a policy that can be applicable in the current request context.

We want the current policy to be applicable to all users who satisfy the following conditions:

· role is of type student [SubjectAttribute]

· resource requested is either sub1,sub2, or sub3 [ResourceAttribute]

· action performed on the resource is view [ActionAttribute]

Here is a snippet from the Student.xml file showing how the <target> must be configured.

<!--

#Policy is meant for the role student

#Policy Applicable only when subject wants to view Information

#Policy is applicable when resources to be accessed are sub1, sub2, sub3.

-->

Student

</AttributeValue>

</SubjectMatch>

</Subject>

</Subjects>

</ActionMatch>

</Action>

</Actions>

</ResourceMatch>

</Resource>

</ResourceMatch>

</Resource>

</ResourceMatch>

</Resource>

</Resources>

</Target>

Let us see each portion of the <target> in a little detail now:

· Subjects - Information about a subject i.e. the user who makes the request is wrapped within a <Subjects> tag. The <SubjectMatch> tag is used to match information of the subject with the requirements of the policy by applying different matching and comparison functions that XACML specification provides. In the above case we match the role of the subject to student. This ascertains that this policy is targeted to all users having a role student.

· Actions - Similarly information about the Action to be performed is wrapped within the <Actions>tag. The action is matched to view by using the <ActionMatch> tag as done in the policy.

· Resources - As mentioned above the policy is applicable to the request of three resources namely sub1, sub2, and sub3. If a request for any other resource apart from these is made; then the policy will not be applicable. The resource information and matching is done within the <Resources> tag by using the <ResourceMatch> tag.

· Attribute Matching Logic - The match logic used in all the cases above is: MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal”. It compares two string values and returns a boolean value stating wheter the strings match or not. The full list of all available functions can be seen in the XACML Core Documentation.

Attribute Matching

Let us now understand the basic idea behind matching of different attributes. Attributes can describe Subjects, Actions, Resources, or Environment information (e.g.: time of day).

At the core, they are all nothing but Attributes which have been classified as different types.

Let us for a moment assume that there is no classification of the attributes.

<<AttributeType>Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

foo

</AttributeValue>

<<AttributeType>AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType=”http://www.w3.org/2001/XMLSchema#string”>

</<AttributeType>Match>

· In the above code snippet <AttributeType> can be replaced by Subject, Action, Resource or Environment to achieve matching of different types of attributes.

· The <<AttributeType>AttributeDesignator> tag is used as a reference to an attribute value in the XACML request document. The AttributeId is used to map to values mentioned in the request context.

· The <AttributeValue> tag is used to specify an attribute value against which another value can be compared.

Role Matching

· Role is an attribute that describes the Subject.

· So we replace <AttributeType> by Subject.

· The AttributeId for role has already been fixed to db_acad:users:user:role as discussed before. This was precisely the reason for fixing the AttributeIds beforehand.

So the XML template that we had above transforms to:

Student

</AttributeValue>

</SubjectMatch>

The two strings that are compared by the string-equal function are the strings:

1. Student

2. The value of role of the subject present in the request context.

Similarly we can build match logic for other types of attributes.

At this point you should have understood:

1. the <target> tag and its need

2. usage of AttributeDesignators and how they reference to values specified in the request context.

3. matching strings and other attributes using AttributeMatch.

Incase you still have a doubt be sure to read up more about these tags in more details from the XACML Core Documentation.You should proceed from this point once these concepts are clear. Also refer to the policy and their corresponding example request file to see how AttributeDesignators work.

Now that we have fixed the scope of our policy what is the next step?

Rule Creation

For our policy for the student we have three cases to consider:

1. The student is trying to view his own marks.

2. The student is trying to view marks of another fellow student for analysis purpose.

3. The student is trying to do something not defined in points 1 or 2 so the access request must be denied.

For our policy we will create three rules which will cater to the three cases that were just described. Out of the three cases only one case can happen at any point of time. If either case 1 or case 2 don’t happen we must Deny access to the student according to Case 3.

Each rule has the following sections:

1. <Target> - This section describes for which attributes (subject, resource, action and environment) is the rule applicable.

2. <Condition> - Different conditions that must be true for the rule to become applicable and give the desired result are wrapped in the <Condition> tag.

Rule Combining Algorithms

As discussed we will have three rules for the three different cases of access for the student. How will XACML decide the result for an access request when so many rules will be evaluated? Each rule that is evaluated will return a result. These results will be combined using the many Combining Algorithms defined for such a purpose. The RuleCombAlgId attribute property is used to mention how the rules in a policy must be combined.

<Policy PolicyId="student"

xmlns="urn:oasis:names:tc:xacml:1.0:policy"

xmlns:context="urn:oasis:names:tc:xacml:1.0:context"

xmlns:db="db_acad"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable">

In our case we have a fall through mechanism i.e. if Case 1 does not happen then Case 2 may happen. If Case 2 does not happen then it is an illegitimate access which must be denied. The Rule Combining Algorithm used in this case states this very concept. Apply the first rule that becomes applicable and return a permit.

You can refer to the other Rule Combining Algorithms in the Core XACML Documents.

So how will XACML know which rule to apply?

Well its quite simple, we again use the <target> tag for each rule. This tag will help identify which rule is applicable, just like it was used in the case of a policy. We will encounter <target> in the rule we construct for Case 2.

Rule for Case 1

<!--A user can only see

his own information. So the

username of the target whose

info must be edited must match

with the username of the user

who wants to edit.

-->

</Apply>

</Condition>

</Rule>

There are a couple of new things here. Let us analyse each tag one by one.

The Effect Attribute Property states that if the rule is applicable(target and conditions are applicable) then it should permit the access.

Now we can have many conditions that arise during access control. Like in this case a user can access information only if, username of the target (the subject whose information is sought) matches with his own. We can precisely model such conditions using the <Condition> tag. It applies different functions upon data/or attributes and returns a boolean value. Functions can work on single arguments or they can work on two(or more) arguments.

Nesting of Functions : <Apply> tag

Functions can be used to operate upon the attribute values using the <Apply> tag. In the above case two functions are nested.

Function 1: urn:oasis:names:tc:xacml:1.0:function:string-is-in

Function2: urn:oasis:names:tc:xacml:1.0:function:string-one-and-only

The function name might apply complex at first sight however they are not really so complex. XACML has provided many standard functions in its specifications. If however, the function is not available within the specification, then you can also create your own custom functions. You should refer to Sun XACML programmer documents to learn how you can do that.

The order of calling of function is from inside out. That is the function in the deepest node will be applied before the one applied on the outside.

So first the XACML implementation will check if there are no multiple values for the username attribute in the request context then it will proceed to compare the subject’s username with target student’s username. Continue to read on even if you feel you are confused.

Xpath and <AttributeSelector>

Note: It will be a good idea to learn about Xpath if you have already not done so. Read and understand Xpath and then come back to this point.

Just like <AttributeDesignator> are used to reference to certain values in the Request File, there are times when we need to refer to some XML data to make a decision. This XML data is provided within the XACML request file. The data can be referenced by using Xpath expressions and Attribute Selectors.

Let us again refer to a specific portion of the request file student_request.xml we saw before:

<db:user type=”target”>

<db:username>student2</db:username>

<db:password>xacml</db:password>

<db:role>student</db:role>

<db:branch>IT</db:branch>

<db:permit>student1</db:permit>

<db:marks>

<db:sub1>86</db:sub1>

<db:sub2>79</db:sub2>

<db:sub3>85</db:sub3>

</db:marks>

</db:user>

</ResourceContent>

<AttributeSelector RequestContextPath="//context:ResourceContent/db:user[@type=’target’]/db:username/text()" DataType="http://www.w3.org/2001/XMLSchema#string"/> will return the value student2 from the information that was supplied in the request file.

So now that we know what value the <AttributeSelector> will return, we can proceed. Once XACML implementation ensures that only one username has been mentioned in the Subject Context(through Function1) it proceeds to compare the value returned by the <AttributeSelector> with the value returned by the <SubjectAttributeDesignator>. If the two strings match, the function returns a “true” value. This in turn makes the <Condition> true, which ultimately leads to the Rule becoming applicable and a “Permit” being returned.

Rule for Case 2

<!--

#Rule : Student wants to view another student's marks

#Purpose : analysis

#Condition: Student must be permitted to view the marks by the target student

-->

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">analysis</AttributeValue>

</ResourceMatch>

</Resource>

</Resources>

</Target>

<!--A user can only see

his own information. So the

username of the target whose

info must be edited must match

with the username of the user

who wants to edit.

-->

</Apply>

</Condition>

</Rule>

The presence of a <Target> helps in making the rule applicable when a purpose is specified along with the access request. The requester does not need to provide a purpose when he is accessing his own data (according to Case1). However, when a student wishes to view the marks of another student they must provide a purpose.

Along with the specification of a purpose the requesting student must be permitted by the student whose marks are sought. This is ascertained by comparing the username of the requester with a list of student usernames who are permitted to view the marks of the target student. Referring to the data for username student2 we notice that he has permitted student1 to view his marks. So when student1 requests to view the marks of student2 for analysis purpose his username will match with the permitted student usernames specified by student2.

Rule for Case 3

Now if neither of the first two rules is applicable, we would like to Deny Access as a final rule.

This is achieved in this way:

<!--

The policy should return a deny in all other cases

-->

So after this point I hope the reader should have become clear about the following concepts:

1. Rule Combining Algorithms

2. <Rule>, <Apply>, <Condition> tags

3. Usage of <target> w.r.t rules.

It would be a good idea to go through the XACML Core Documentation to grasp the finer details of these concepts.

We know how to do the following:

1. Make simple XACML Request files [check student_reques