USING MICROSOFT OFFICE INFOPATH TO GENERATE XACML

POLICIES

Manuel Sánchez, Gabriel López, Antonio F. Gómez-Skarmeta

Department of Information Engineering and Communications

University of Murcia, Spain

Óscar Cánovas

Department of Computer Engineering

University of Murcia, Spain

Keywords:

Policy editor, XACML, XSLT, access control.

Abstract:

Today, when organizations perform access control over their resources they are not only interested in the

user’s identity, but in other data such as user’s attributes or contextual information. These requirements can

be found, for example, in a network access control scenario where end users pay for a speciﬁc access level

and depending on it, they can get different network quality of service. The network provider has to check, not

only the user identity, but the user’s attributes to make sure that he can access to the speciﬁed resource. These

systems are based on the use of policy languages to deﬁne the authorization process. However, due to the

increasing complexity of current systems, policies are becoming more and more complex to be managed by

system administrators. Therefore, in this paper we present an user friendly approach to policy speciﬁcation,

based on the use of high level templates and common desktop applications. These templates are easily built

from XML schemas, and once they have been ﬁlled, a XACML policy is automatically generated using a XML

transformation.

1 INTRODUCTION

Access control management is a main concern

for domain administrators since target resources

have to be protected against unauthorized accesses

from malicious attackers. One of the main sce-

narios is the network access control and several

mechanisms have been proposed recently for that,

such as 802.1X (IEEE Computer Society, 2001) or

PANA (Forsberg et al., 2005). Initially, these mecha-

nisms were only based on user authentication, mainly

using shared secrets or public key cryptography.

However, they are evolving to more sophisticated pro-

posals performing user authorization based on user

attributes, such as NAS-SAML (López et al., 2006).

Usually, the authorization process is guided by a set

of rules, that is, the access control policy, which has

been usually described by means of speciﬁc, and tech-

nology dependent, policy languages, such as PER-

MIS (Chadwick et al., 2003) or Akenti (Thompson

et al., 2003).

Due to the existence of different proprietary and

application speciﬁc access control policy languages,

policies can not be easily shared between different or-

ganizational domains, as described in (Cánovas et al.,

2004), which involves a serious interoperability draw-

back. Besides, it makes difﬁcult the development of

good editing tools for access control policies. This sit-

uation has motivated the creation of a standard access

control policy language, named XACML (Anderson

et al., 2003), by the OASIS consortium. XACML,

which was proposed to become a common framework

for deﬁning access control policies, addresses all the

requirements of an access control environment and is

currently used to represent and evaluate policies in a

wide range of authorization scenarios, such as NAS-

SAML (López et al., 2005) or systems described in

(Lorch et al., 2002) (Cardea and PRIMA). However,

this versatility implies a high level of complexity in

the policy language deﬁnition. Therefore, adminis-

trators should have a depth knowledge of XACML in

order to deﬁne an accurate medium-sized access con-

trol policy. For example, in a medium or large orga-

nization which needs to protect a high number of re-

sources, policy management may become a very com-

plex task.

Therefore, it would be desirable the existence of

software tools to facilitate the development of access

control policies from the point of view of the domain

administrator, especially when they cannot be consid-

379

Sánchez M., López G., F. Gómez-Skarmeta A. and Cánovas Ó. (2006).

USING MICROSOFT OFFICE INFOPATH TO GENERATE XACML POLICIES.

In Proceedings of the International Conference on Security and Cryptography, pages 379-386

DOI: 10.5220/0002096803790386

 SciTePress

ered XACML or security experts. At the moment

there are several alternatives to deal with XACML

policies, such as general XML editors or even spe-

ciﬁc XACML editors, but as explained below, all of

them present any deﬁciency. This paper presents a

framework to generate XACML policies from user

friendly templates that can be ﬁlled in by a domain

administrator in the same way they write a document

in natural language, using the Microsoft

Ofﬁce

InfoPath

utility (Hoffman, 2003). Finally, the re-

sulting high level policy ﬁles are transformed into the

ﬁnal low level XACML policies by means of XSL

transformations (Clark, 1999).

In this way, as Figure 1 shows, to obtain a new

XACML policy, the administrator writes the initial

document. Then, the security expert of the organiza-

tion applies the XML transformation to generate the

policy. Finally, this policy is added to the XACML

repository containing the rest of policies.

Figure 1: Policy life cycle.

The rest of this paper is structured as follows. Sec-

tion 2 introduces the XACML standard. Section 3

explains the features of the tool used to design user

friendly forms for administrators. The policy life cy-

cle is shown in Section 4. To clarify the policy gener-

ation process, Section 5 presents a speciﬁc example.

Related work is shown in Section 6. Finally, conclu-

sions and future work are presented in Section 7.

2 XACML POLICY LANGUAGE

XACML (eXtensible Access Control Markup Lan-

guage) (Anderson et al., 2003), the OASIS proposal

for a standard access control language, was deﬁned to

represent access control policies in a standard way.

XACML is XML-based and includes two different

speciﬁcations: the ﬁrst one is an access control policy

language, which deﬁnes the set of subjects that can

perform particular actions on a subset of resources;

the second one is a representation format to encode

access control requests and responses, that is, a way

to express queries about whether a particular access

should be allowed and the related answers.

As Figure 2 shows, the main element of all

XACML policies is a Policy or PolicySet element. A

PolicySet is a container that can hold other Policies

or PolicySets, as well as references to other policies

(PolicyIDReference). A Policy represents a single ac-

cess control policy, expressed by a set of Rules. A

Policy or PolicySet may contain multiple policies or

Rules, each of which may evaluate to different access

control decisions. XACML needs some way of rec-

onciling the decisions each makes, and this is done

through a collection of Combining Algorithms. An

example of those is the Permit Overrides Algorithm,

which says that if at least an evaluation returns Permit,

then the ﬁnal result is also Permit. A Policy or Pol-

icySet element may also specify a set of Obligation

Attributes, that is, a set of actions to be performed if

the request has been approved.

Figure 2: XACML policy structure.

XACML provides another feature called Target. It

is a set of simpliﬁed conditions for the Subject, Re-

source and Action that must be met for a PolicySet,

Policy or Rule to apply to a given request. If all

the conditions of a Target are met, then its associated

PolicySet, Policy, or Rule are applied to the request.

Once a Policy is found, the included rules are evalu-

ated. The main element of a rule is the Condition. If

the evaluation of the Condition results true, then the

Rule’s Effect (Permit or Deny) is returned.

The main object that XACML deals with is at-

tributes. Attributes are named values of known types.

Speciﬁcally, attributes are characteristics of the Sub-

ject, Resource, Action or Environment in which the

access request is made.

SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY

380

3 MICROSOFT OFFICE

INFOPATH

InfoPath (Hoffman, 2003) is a desktop application

which allows organizations to efﬁciently gather the

needed information using dynamic forms. This ar-

chitecture includes design characteristics which make

easy the structured creation and ﬂexible viewing of

XML documents. This tool has the following archi-

tectural features and design objectives:

• Build an hybrid tool which combines document

editing experience with the data capture ability of

forms. Users can view and modify abstract data

structures using a traditional word-processing en-

vironment.

• The use of XML documents belonging to user de-

ﬁned schemas for the input and output. InfoPath

uses and produces XML schemas and XSL trans-

formations, and it is integrated with XML Web

services standards. When editing an XML docu-

ment, InfoPath enables adding and deleting valid

attributes and XML elements which belong to a

XML schema deﬁned by the user. Then, when the

XML document is saved or submitted, it remains

valid following the XML schema.

• Provide structural editing. InfoPath enables gath-

ering structured and validated XML information

which can be reused. Structural editing in InfoPath

provides an easy and natural user’s interface which

allows to normal users add and delete valid XML

attributes and elements.

• Provide ﬂexible views to present XML documents

in a coherent way to the user. InfoPath uses XSLT

to enable the content of the editing views to be or-

ganized in a different way that the XML data struc-

ture.

Three different validation levels exist in InfoPath:

schema based validation, XPath validation rules and

script based validation. The ﬁrst validation level helps

users to create structured XML documents which are

ready to be reused by XML based systems. The sec-

ond level allows to check conditions, e.g. the value of

some ﬁeld must be greater than a particular minimum.

And the third level may deﬁne additional validations

in the XML document or deﬁne other business logic.

Form templates can be designed in several ways,

ranging from an existing XML schema or document

to deﬁning an XML schema from scratch.

4 USING TEMPLATES TO

GENERATE POLICIES

Complexity in policy deﬁnition languages makes dif-

ﬁcult the speciﬁcation of the policies governing the

access control system. Therefore, a methodology to

simplify this task is proposed in this document. The

main idea, shown in Figure 3, is that the administra-

tor writes a document in natural language expressing

what the system must enforce, that is, the set of ac-

cess control rules. Later, by means of XSL transfor-

mations, this document is translated into an XACML

policy. Speciﬁcally, a set of templates are available

to the system administrator, each one for every spe-

ciﬁc policy existing in the system. These templates

deﬁne documents that can be used to describe a spe-

ciﬁc feature of the access control system, such as the

roles assigned to each user or the set of roles enabled

to access to a speciﬁc resource.

Figure 3: Policy generation.

Microsoft Word might be used as text editor to de-

sign the required templates, but InfoPath has been

selected since this tool was speciﬁcally designed to

work with templates. The design of a policy template

is based on a XML schema deﬁning the information

elements which can be speciﬁed by the administrator.

This schema should be designed by an XACML ex-

pert, since it has to contain the more relevant elements

of the XACML policy.

Once the initial document is written, a XSL trans-

formation must be applied to transform it into the ﬁ-

nal XACML policy. This can be done either using a

XSLT compiler, such as XALAN (Apache Software

Foundation, 2006), or some XML editor implement-

ing the XSLT standard, such as XMLSpy (Altova,

2006). The XSL transform generates the XACML

policy completing the required sections using the in-

formation from the initial document. As the initial

XML schema, the design of the XSLT implies a deep

knowledge about the XACML standard, because it is

necessary to know how to generate a complete policy

fulﬁlling the XACML speciﬁcations.

Consequently, the "security expert" is responsible

for developing the XML schemas, the policy tem-

plates and the XSL transformations for each policy in

the organization. On the other hand, speciﬁc system

administrator, for example administrators who are in

USING MICROSOFT OFFICE INFOPATH TO GENERATE XACML POLICIES

381

charge of the role assignment to users, are able to

specify the security policy without any knowledge of

XACML. All they have to do is to complete the policy

template, expressed in natural language, and this will

be automatically transformed into the target XACML

policy by means of the XSL transformations. Finally,

policies are stored in the XACML repository to make

them available to the system.

This kind of policies doesn’t have real time require-

ments, therefore it is not necessary for administra-

tors to apply the XSLT transformation and to store

the XACML policy in the repository directly. In this

way, administrators only have to ﬁll in the template

due to the security expert can perform all the related

technical tasks.

The conversion of the XML document into the

XACML policy depends mostly on the speciﬁc pol-

icy being generated, therefore transformation details

are given next using some examples.

4.1 Translating Policy Elements

Deﬁnition of the XML schema containing the ele-

ments managed by the administrator can be made us-

ing the string data type, for attributes, subjects, etc.

However, there are special cases needing special at-

tention. For example, obligations commonly express

the assignment of a value to an attribute, so they need

to be represented as a pair of strings.

A more complicated example is related to condi-

tions, because they can be expressed in a variety of

ways. For example, ((: current − time ≥ 9h)and(:

current − time ≤ 21h))and((: dayOfW eek ≥

Monday)and(: dayOf W eek ≤ F riday)) needs to

be represented in a recursive way, but InfoPath does

not allow recursive schemas.

Therefore an iterative approach must be taken,

where simple relational checks are joined using

boolean operators, and new checks are joined to

the previous relation as a whole. For example, the

condition stated before could be expressed as (((:

current − time ≥ 9h)and(: current − time ≤

21h))and(: dayOf W eek ≥ M onday))and(:

dayOf W eek ≤ F riday). Moreover, since the most

common condition in policies implies two relational

comparison in the form of (x > A)and(x < B), this

structure can be introduced in the schema to make

easy the design of the Condition element. Figure 4

shows a simpliﬁed view of the Condition element

schema.

Finally, the basic XML document must be trans-

formed into the complete XACML policy by means

of a XSL transformation. Therefore, elements from

the basic XML document must be translated into

XACML elements, obeying the speciﬁc structure,

formats and namespaces. The XSL transforma-

tion generates the speciﬁc policy structure using the

xsl:element and xsl:attribute operators in a ﬁxed way,

and then it uses the input XML document generated

before to ﬁll in the speciﬁc gaps in the ﬁnal XACML

policy. Once the transformation is designed, it has

only to be applied to every InfoPath-generated docu-

ment.

5 POLICY GENERATION FOR A

NETWORK ACCESS CONTROL

AUTHORIZATION SCENARIO

This section depicts how to generate one of the re-

quired policies for the NAS-SAML system, where the

main resource to be protected is the communication

network.

5.1 Nas-saml. A Network Access

Control Approach Based on

Saml and XACML

NAS-SAML (López et al., 2006) is a network access

control approach based on X.509 identity certiﬁcates

and authorization attributes. This proposal is based

on the SAML and the XACML standards, which will

be used for expressing access control policies based

on attributes, authorization statements and authoriza-

tion protocols. Authorization is mainly based on the

deﬁnition of access control policies including the sets

of users pertaining to different subject domains which

will be able to be assigned to different roles in order to

gain access to the network of a service provider, un-

der speciﬁc circumstances. The starting point is a net-

work scenario based on the 802.1X standard and the

AAA (Authentication, Authorization and Account-

ing) architecture, where processes related to authenti-

cation, authorization, and accounting are centralized.

The system operates as follows. Every end user be-

longs to a home domain, where he was given a set

of attributes stating the roles he plays. When the end

user requests a network connection in a particular do-

main by means of a 802.1X connection, the request is

obtained by the AAA server, and it makes a query to

obtain the attributes linked to the user from an author-

ity responsible for managing them, based on a Role

Assignment Policy. In case the user’s home domain

is based on a different authorization system, the AAA

server uses a credential conversion service, as deﬁned

in (Cánovas et al., 2004), to translate the user’s autho-

rization credentials into internal format, based on a

Conversion Policy. Finally, the AAA server sends an

authorization query to a policy decision point (PDP),

which consults a Resource Access Policy. The PDP

ﬁrsty recognizes if the user belongs to well known

SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY

382

Figure 4: Simpliﬁed Condition Element XML Schema.

source domain, by means of the Role Allocation Pol-

icy sub-policy. Then, it checks if the user is allowed

or not to use the target resource, by means of the Tar-

get Access Policy sub-policy. Furthermore, it also es-

tablishes the set of obligations derived from the given

decision, for example some QoS properties, security

options, etc. This general scheme works both in sin-

gle and inter-domain scenarios, and using both push

an pull based communications.

5.2 Editing the Target Access Policy

This section shows an example of how one of the poli-

cies introduced in NAS-SAML (Target Access Pol-

icy), can be deﬁned by means of the proposed policy

editor. First, the Target Access Policy is described,

and next the policy template is generated step by step.

5.2.1 Target XACML Policy

As described in (López et al., 2005), the Target Ac-

cess Policy comprises a set of target access elements.

Each of them grants a user playing a speciﬁed set of

roles the permission to carry out the speciﬁed actions

on the speciﬁed list of targets, but only if the are sat-

isﬁed conditions. Every target access element has the

following elements:

• Attributes: Set of allowed attributes or enabled

roles to execute the actions on the resource.

• Resources: Set of controlled resources.

• Actions: Set of allowed actions over the resource.

• Conditions: Users holding some of the attributes

have permission to execute some actions on the

speciﬁed resources only if the conditions are ful-

ﬁlled. Otherwise, the permission will be denied.

These conditions can establish time constraints or

other constraints related to contextual information.

• Obligations: Once the action has been granted,

some obligations deﬁning network properties

might be applied. Obligations can specify options

related to network addressing, security or QoS

properties that must be enforced.

Figure 6 shows an example of the Target Access

Policy. In this ﬁgure we can see a PolicySet ele-

ment, where Target deﬁnes the role type and value,

in this case role-id and Student. Besides, it con-

tains a Policy to deﬁne that the wireless-network re-

source, can be used by the users playing that role.

This example also shows the set of obligations de-

rived from this decision. That is, if a user holding

the Student role, requests wireless-network connec-

tion, it should obtain an IPv6 address from the range

2001:720:1710:100::/64 and the network must guar-

antee a quality of service established by Class1.

5.2.2 Deﬁnition of the XML Schema

To deﬁne the initial XML schema, we have to iden-

tify ﬁrst the policy elements the administrator needs to

complete in order to create a new policy instance. In

this example, as described above, these elements are

the attributes, the rights which are going to be granted,

the resource/access pair, the conditions which have to

be fulﬁlled to apply the policy decision and the oblig-

ations which may be derived. In this way, we can de-

ﬁne an XML schema where an Attribute and several

Resource/Action pairs are speciﬁed. Besides, Condi-

USING MICROSOFT OFFICE INFOPATH TO GENERATE XACML POLICIES

383

Figure 5: XML schema representation.

Figure 7: Target access policy form template.

tion and Obligation need to be stated as optional ele-

ments. Figure 5 clariﬁes this structure.

5.2.3 Deﬁnition of the XSL Transformation

The next step in the policy template generation

process is the deﬁnition of the XSL transformation,

which has to translate the document in natural lan-

guage written by the system administrator into the

ﬁnal XACML policy. The resulting XACML pol-

icy is structured using a PolicySet to specify the At-

tribute. Then, for each resource/action pair, a new

Policy is added with the Resource, Action, Condition

and Obligation elements. The XSL transformation

creates the XACML policy in a ﬁxed way and then

ﬁlls in some speciﬁc gaps using the information con-

tained in the initial document.

Figure 8 shows a fragment of the XSL transforma-

tion used to generate the target access policy in this

example. It is interesting to see how the XACML po-

lice structure is generated in a ﬁxed way using the

xsl:element and xsl:attribute operators, while the suit-

able gaps are completed using the sentence xsl:value-

of select="text()" to extract the information from the

initial XML document.

5.2.4 Design of the InfoPath Form Template

The ﬁnal step in this process lies in the design of the

InfoPath template to enable the system administrator

an easy way to create new policies without XACML

knowledge. This is done with the InfoPath editor,

which allows to import the XML schema deﬁning the

template. Figure 7 shows an example of template de-

signed using this editor.

6 RELATED WORK

This section analyzes two main tools which are

currently used to manage XACML policies, XML-

Spy(Altova, 2006) and UMU-XACML-Editor (Uni-

versity of Murcia, 2006). The ﬁrst one is a powerful

and commercial generic XML editor, the second one

is a speciﬁc XACML editor developed by the Univer-

sity of Murcia.

XMLSpy is an IDE designed to work with XML

documents in general, which allows users to enter

data into XML documents as they would into a word

processor-type application. It allows the deﬁnition of

XML documents in multiple editing formats, well-

formedness checking and built-in validator, intelli-

gent editing, deﬁnition of XSLT documents, code

generation, etc. These characteristics enable users

to specify the XACML schema in the IDE and thus

generate XACML policies from scratch in a fast way.

The user builds the policy adding each element step

by step and checking that it is well formed.

UMU-XACML-Editor is a XACML policy deﬁ-

nition open source software, developed using Java,

which fulﬁlls the XACML 2.0 standard. This editor

is speciﬁcally designed to create and modify XACML

policies, providing facilities to manage these policies.

It is free and can be downloaded from the OASIS’s

XACML Home Page (OASIS, 2006).

Although both solutions deals with XACML in a

proper way, the main problem is that they work di-

rectly with XACML policies. In this way, the system

administrator has to known the XACML standard to

create a new policy. But also, he has to decide how

to organize the elements in the XACML structure to

express correctly the meaning of the policy. With our

proposal, this work is made only once for each kind of

policy. Besides, only one person, the security expert,

has to deal with the XACML related work.

Furthermore, each XACML editor has its own edit-

ing interface and its own characteristics, so the sys-

tem administrator has to learn how to use these pro-

grams before start editing policies. However, we pro-

vide standard templates to create the XACML poli-

cies. Therefore, the system administrator opens the

template and completes it as he was writing a natural

SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY

384

Figure 6: Target Access Policy example.

Figure 8: XSL transformation fragment.

language speciﬁcation. He does not need any previ-

ous knowledge to start editing the policies of the or-

ganization. He only has to know which policy wants

to deﬁne and then writes the appropriate document.

Later, the security expert will deal with the automatic

translation from the natural language document to the

XACML policy.

Finally, related to modiﬁcations in policy format,

when using a generic XML editor we have to specify

the new XACML schema to generate new policies.

On the other hand, with the speciﬁc UMU-XACML

editor, the source code has to be modiﬁed to add the

new elements and relations.

USING MICROSOFT OFFICE INFOPATH TO GENERATE XACML POLICIES

385

7 CONCLUSIONS AND FUTURE

WORK

XACML has appeared to cover the need of the cur-

rent authorization systems to represent in a standard

language the access control policies used to control

critical resources. Most of those current systems are

migrating their speciﬁc policies to XACML in order

to offer a more scalable and extensible solution.

The fact that XACML is a very helpful tool for se-

cure domain administrator does not imply that it is

easy to use. In a typical access control scenario, dur-

ing a routine policy creation or update, the domain ad-

ministrator does not have to deal with complex XML

schemes and documents but only with the fulﬁllment

of the set of permissions assigned to users under spe-

ciﬁc circumstances. In fact, the domain administrator

could not even understand the XACML language.

It shows the need of tools able to help domain ad-

ministrators to deal with complex XML documents in

a natural language. Moreover, this paper shows that

current generic XML or speciﬁc XACML editors do

not fulﬁll these requirements.

We have deﬁned a way to manage those XML doc-

uments in a transparent way for the domain adminis-

trator, making use of a word-processing style editor

such as Microsoft InfoPath. In this way, once the nec-

essary XML templates and transformations are cre-

ated by a XACML expert, the domain administrator

can deﬁne low level XACML policies using human

readable forms.

The sample scenario we have used to test the pro-

posed solution is the NAS-SAML infrastructure. This

paper shows how the Target Access Policy template

and its associated XSL transformation can be gener-

ated by a security expert to make easy the adminis-

tration tasks to the network administrator. The rest

of policies used in this scenario can be deﬁned in a

similar way.

Finally, the solution proposed in this work can be

also used to deﬁne other kind of documents based on

other XML speciﬁcation, such as (Thompson et al.,

2003; Chadwick et al., 2003).

REFERENCES

Altova (2006). XMLSpy

. http://www.altova.

com/xmlspy.

Anderson, A., Parducci, B., Adams, C., Flinn, D., Brose,

G., Lockhart, H., Beznosov, K., Kudo, M., Humenn,

P., Godik, S., Andersen, S., Crocker, S., and Moses, T.

(2003). EXtensible Access Control Markup Language

(XACML) Version 1.0. OASIS Standard.

Apache Software Foundation (2006). The apache xalan

project. http://xalan.apache.org.

Chadwick, D., Otenko, O., and Ball, E. (2003). Implement-

ing role based access controls using x.509 attribute

certiﬁcates. IEEE Internet Computing, pages 62 – 69.

Clark, J. (1999). XSL Transformation (XSLT). W3C Rec-

ommendation.

Cánovas, O., Lopez, G., and Gómez-Skarmeta, A. (2004).

A credential conversion service for saml-based sce-

narios. In Proceedings First European PKI Workshop,

volume 3093 of Lecture Notes in Computer Science,

pages 297–305. Springer.

Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and Yegin,

A. (2005). Protocol for Carrying Authentication for

Network Access (PANA). Internet Draft.

Hoffman, M. (2003). Architecture of Microsoft Ofﬁce In-

foPath 2003. Microsoft Technical Report.

IEEE Computer Society (2001). P802.1x/d11: Standard for

port based network access control. IEEE Draft.

Lorch, M., Proctor, S., Lepro, R., Kafura, D., and Shah, S.

(2002). First Experiences Using XACML for Access

Control in Distributed Systems. ACM Workshop on

XML Security.

López, G., Cánovas, O., and Gómez, A. F. (2005). Use of

xacml policies for a network access control service. In

Proceedings 4th International Workshop for Applied

PKI, IWAP 05, pages 111–122. IOS Press.

López, G., Cánovas, O., Gómez, A. F., Jimenez, J. D.,

and Marín, R. (2006). A network access control ap-

proach based on the aaa architecture and authorzation

attributes. Journal of Network and Computer Appli-

cations JNCA. To be published.

OASIS (2006). OASIS eXtensible Access Control

Markup Language (XACML) TC. http:

//www.oasis-open.org/committees/

tc_home.php?wg_abbrev=xacml.

Thompson, M., Essiari, A., and Mudumbai, S. (2003).

Certiﬁcate-based authorization policy in a PKI envi-

ronment. ACM Transactions on Information and Sys-

tem Security (TISSEC), 6:566 – 588.

University of Murcia (2006). UMU XACML editor. http:

//xacml.dif.um.es.

SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY

386