authorization service for web services and its implementation

90 International Journal of Web Services Research, 2(4), 90-114, October-December 2005

Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without writtenpermission of Idea Group Inc. is prohibited.

Authorization Service forWeb Services and Its Application

in a Health Care DomainSarath Indrakanti, Macquarie University, Australia

Vijay Varadharajan, Macquarie University, Australia

Michael Hitchens, Macquarie University, Australia

ABSTRACT

In this paper, we discuss the design issues for an authorization framework for Web Services. Inparticular, we describe the features required for an authorization policy language for WebServices. We briefly introduce the authorization service provided by Microsoft .NET MyServicesand describe our extended authorization model that proposes extensions to the .NET MyServicesauthorization service to support a range of authorization policies required in commercialsystems. We discuss the application of the extended authorization model to a health care systembuilt using Web Services. We use the XML Access Control Language (XACL) in ourimplementation to demonstrate our extended authorization model. This also enables us toevaluate the range of authorization policies that XACL supports.

Keywords: access control; authorization; policy language; security; Web Services

INTRODUCTION

Security plays a vital role in the designand practical deployment of distributed appli-cations, as greater availability and access toinformation, in turn, imply that systems are moreprone to attacks. In a networked computingsystem, when one principal requests a servicefrom another, the receiving principal needs toaddress at least two fundamental questions: Isthe requesting principal the one it claims to be?Does the requesting principal have appropri-

ate privileges for the requested service? Thesetwo questions relate to the issues of authenti-cation and authorization. The authorization re-quirements in networked applications are muchricher than authentication both in terms of thetypes of privileges required and the nature anddegree of interactions. There also are other se-curity concerns, such as auditing, secure com-munication (confidentiality and integrity), avail-ability, and accountability. All of these securityissues apply in general to the Web Servicesarchitecture.


International Journal of Web Services Research, 2(4), 90-114, October-December 2005 91

In general, security for Web Services is abroad and complex area covering a range oftechnologies. At present, there are several ef-forts underway that are striving for the provi-sion of security services, such as authentica-tion between participating entities, confidenti-ality, and integrity of communications. A vari-ety of existing technologies can contribute tothis area, such as TLS/SSL (Rescorla, 2001) andIPSec (Kent & Atkinson, 1998). We also havesecurity functionality based on XML Signa-ture (Bartel et al., 2002) and XML Encryption(Imamura et al., 2002) standards. There also arenatural extensions of these to integrate secu-rity features in technologies such as SOAP(Gudgin et al., 2003) and WSDL (Christensen etal., 2001). WS-Security (Atkinson et al., 2002)specification describes enhancements to SOAPmessaging to provide message integrity, confi-dentiality, and authentication. There also is workon XKMS (Ash et al., 2004) defining interfacesto key management and trust services basedon SOAP and WSDL. There is a draft proposalon Web Services security policy language(Della-Libera et al., 2002) that describes the ca-pabilities and constraints of the security poli-cies on intermediary Web Services and endpoints. Web Services trust draft specification(Anderson et al., 2005) considers secureinteroperation of Web Services by outlining aframework of trust models. There also is somework on Web Services privacy issues (O’Keefe& Greenfield, 2003). However, while there is alarge amount of work on general access controland more recently on distributed authorization(Herzberg et al., 2000; Jajodia et al., 1997;Varadharajan et al., 1998), research in the areaof authorization for Web Services is still at anearly stage (Kraft, 2002; Yagüe & Troya, 2002).There is not yet a specification or a standardfor Web Services authorization. Currently, mostWeb-service-based applications, having gonethrough the authentication process, make au-thorization decisions using application-specificaccess control functions, which result in thepractice of frequently reinventing the wheel.This motivates us to have a closer look at theissues involved in designing an authorizationframework for Web Services.

DESIGN CHOICESFOR AUTHORIZATION

In some sense, there is a lot of similaritiesin the design of authorization services andframeworks for distributed applications andWeb Services. Perhaps one aspect that makesit somewhat different in the case of Web Ser-vices is the need to take into account multipledomains and jurisdictions in a federated struc-ture as a default. Although this is true in thecase of distributed systems, as well, in the pastthe approach has been one of developing theservice on a per-domain basis and then extrapo-lating it to multiple domains.

In designing a distributed authorizationservice for Web Services, there are some fun-damental design issues that we need to ad-dress. First, we need to consider the types ofauthorization information to be used in thedecision-making process. These range fromstatic and generic information (e.g., identities)to specific information (e.g., roles) to dynamicand specific information, which are dependenton system state. Then, we need to addressthe class of authorization policies that need tobe supported in the Web Services architec-ture. These can range from identity-based torole-based to delegation to joint actions todynamic separation of duty. Associated withthe different types of information, there canbe different places at which checks need to beperformed by different authorities. This, inturn, will lead to what authorization informa-tion (e.g., privileges or credentials) can bepushed to the decision-making authority andwhat information needs to be pulled, or a com-bination of both. Related to these is the repli-cation strategy and who updates and man-ages what information and policies. Differentdesign choices to these questions lead to dif-ferent authorization frameworks that, in turn,need to be positioned within the distributedWeb Services architecture. A detailed discus-sion of these issues can be found inVaradharajan (2002). In this paper, we addressthe class of authorization policies that needsto be supported by an authorization policy lan-guage used by the Web Services architecture.



In this paper, we discuss the features re-quired for an authorization policy languagedesigned for the Web Services architecture. Wedescribe our authorization model (Indrakanti etal., 2003), which extends the authorization ser-vice used by .NET MyServices. Note that .NETMyServices is used as an example system forillustration purposes. The authorization tech-niques proposed in this paper apply in generalto Web Services environments. In particular,we extend the authorization policy language tosupport a range of access control policies re-quired in a commercial environment. We thendiscuss the demonstration of our extended au-thorization model to an application in the healthcare domain. We made use of the XML AccessControl Language (XACL) (Kudo & Hada,2000) policy language in our implementation inorder to demonstrate our extended authoriza-tion model. We describe our system architec-ture, explaining our design, the policy specifi-cations and associations, and their practicalevaluation. We then discuss our experience withXACL. In particular, we evaluate the range ofaccess control policies supported by XACL.We propose extensions to XACL to support arange of access control policies required in com-mercial systems. We discuss some related workin the area of authorization policy languagesbased on XML before concluding the paperwith some final remarks.

AUTHORIZATION POLICYLANGUAGE FEATURES

Languages long have been recognized incomputing as ideal vehicles for dealing with ex-pression and structuring of complex and dynamicrelationships. Over recent years, a language-based approach to specifying access controlpolicies has (rightly) gained prominence, whichis helpful not only for supporting a range of ac-cess control policies but also for separating policyrepresentation from policy enforcement.

A standard access control policy lan-guage can replace several application-specificlanguages and is useful for interoperability be-tween different systems and applications. Ad-ministrators save time and money, because theyare not required to rewrite their policies in many

different languages. Developers save time andmoney, because they do not have to inventnew policy languages and write code to sup-port them. They may reuse existing code. Goodtools for writing and managing policies for apolicy language are likely to emerge, if the policylanguage is standardized. We believe policylanguages in which one can specify policiesusing XML have an advantage over otherpolicy languages such as Ponder (Damianou etal., 2001) and Tower (Hitchens & Varadharajan,2000). Web-services-based applications usingan XML-based language can leverage on thebenefits of XML like interoperability over mul-tiple platforms in a heterogeneous environment.A policy based on XML technology with itsown namespaces and schemas is necessary ina heterogeneous environment of Web Services.Standard specifications, such as XML Encryp-tion and XML Signature, then can be used tosecure and sign those policies, where needed.Such a policy language’s policies can be speci-fied and associated with any service-basedapplication, whether it is running on a Java-based platform or the .NET platform.

We also need to consider the range ofauthorization policies that likely are to be re-quired for Web Services deployed in a commer-cial environment. Support for a range of poli-cies, including dynamic separation of duty poli-cies (Simon & Zurko, 1997), Role Based AccessControl (RBAC) (Sandhu et al., 1996) policies,conditional authorization policies (discussedin this paper), joint-action based policies(Varadharajan & Allen, 1996), and Chinese-wallpolicies (Brewer & Nash, 1989), must be pro-vided by the policy language.

EXTENDEDAUTHORIZATION MODEL

In this section, we briefly introduce .NETMyServices, its authorization model, and ourevaluation of the model, along with our pro-posed extensions.

Motivation for Evaluation. We evaluatedthe policy language used by the authorizationservice for .NET MyServices for the followingreasons:



1. It is an XML-based language;2. It supports Role Based Access Control

(RBAC) model for access control. The privi-leges of an organization can be modeled ef-fectively using RBAC. Advantages of theRBAC model are widely understood; and

3. Unlike other policy languages (Damianou etal., 2001) designed for distributed systems,the policy language used by .NETMyServices was designed specifically forWeb Services.

Microsoft .NET MyServicesMicrosoft .NET MyServices (Microsoft

Corporation, 2001b) is the name for a set ofXML message interfaces implemented as a setof Web Services. It is a platform for buildinguser-centric Internet applications, where userscan place their private personal data. .NET Cal-endar, .NET Inbox, and .NET Contacts are ex-amples of .NET MyServices. They serve as asingle central location, where users can store,update, and control all of their personal data..NET MyServices aims to provide a fine granu-larity of control to the user (owner of the data).Users may choose to share that informationwith friends, family, groups with which theyhave an association, and businesses. Addition-ally, users can sign up to receive alerts on bothdesktop and mobile devices.

Authorization Servicein .NET My Services

The authorization service used by .NETMyServices uses a policy language comprisedof the following items. The definition of a rolein terms of the permissions that it has on differ-ent objects (a set of elements in an XML docu-ment) is specified using a role-template. A role-template defines the set of methods allowed bythe role-template and the scope visible to eachmethod. A role-template has a name (e.g., rt1). Ascope is nothing but a group of elements andattributes within an XML document. The map-ping between a role-template and a user is de-fined by role. Then, users have a list of rolesthat are authorized to access the resources(XML documents) associated with those us-ers. This is defined in role-list, which describeswhat information to share, who to share it with,and how to share it. A role-map describes whatinformation is to be shared and how that shar-ing is to occur. It defines for each role (from therole-list) what the allowable Web Service meth-ods are and what scope of data is visible whileusing this method. The role-map is the same forall instances of a particular service and isauthored by the implementer of the service.

An example of role-map is shown in Fig-ure 1. The role-map is defined for all elementsof an XML document or, in other words, for anentire XML document. The role-template rt0gives query, insert, replace, delete, and up-

Figure 1. Example of role-map



date privileges on all elements of the XMLdocument.

An example of role-list is given in Figure2. The role-list defines the privileges for differ-ent roles to Bob’s medical record. The rolesinclude Bob, Alice, and Joe. All the three rolesin this case have privileges given by role-tem-plate rt0 on Bob’s medical record (stored as anXML document). We refer the reader toMicrosoft Corporation (2001a) for XMLschemas and detailed descriptions of role-map,role-list, role, and role-template.

Proposed ExtensionsA key architectural aspect of any autho-

rization policy language is its ability to sup-port a range of access control policies. Afterevaluating the authorization model used by.NET MyServices, we discovered that the policylanguage used does not support the range ofaccess control policies required in a commer-cial environment. We proposed extensions tothe policy language to be able to capture policyrequirements, such as identity-based discretion-ary access control, role-based access control,static and dynamic separation of duty, Chinese-wall policy, delegation, and joint and collabo-rative action-based access control.

In this paper, we briefly discuss our pro-posed extensions to the policy language alongwith examples to specify conditional authoriza-tion policies, delegation policies, joint-actionpolicies, and dynamic separation of duty poli-cies. We give some examples of the kinds ofpolicies one can specify using the extendedauthorization model in a health care applicationscenario. In each case, we first will describe theaccess policy requirements to be supported bythe Web Service, discuss the existing limita-tions, and propose extensions to the policyspecification mechanism provided by the au-thorization service. In particular, we provideextensions to the XML schemas of role-mapand role-list.

In describing our extensions to the au-thorization service, we will use the term pro-vider to denote an entity that owns the contentdocument (or Web Service data) and the termuser to denote an entity that accesses theprovider’s document. For a more comprehen-sive discussion on this work, we refer the readerto Indrakanti et al. (2003).

Throughout this paper, when we use theelement role in extended role-list schema, wemean that it is either a normal role, a delegatedrole, or a dynamic role. Delegated-role and dy-

Figure 2. Example of role-list



namic-role are defined in the sections to follow.For simplicity, we only show the schema skel-eton for role element.

Every .Net MyServices provider has acontent document that actually stores its dataand an access control list (ACL) document thatstores authorization information. We suggestthat every provider provisioned for a .NET MyService also should be provisioned a log docu-ment along with the content document and ACL(role-list) for auditing purposes. We will not bediscussing the auditing aspects in this paper.

To begin with, we propose a small modi-fication to the role-map schema that helps touniquely identify a method-scope pair in therole-template. This is achieved by including anID attribute. This new attribute is introducedso that this pair can be referred to in a roleelement in a provider’s role-list document. Anexample with this minor extension given in boldis shown in Figure 3.

Conditional AuthorizationThe existing authorization service in .NET

MyServices does not have the ability to specifyconditions to methods when performing accesscontrol checks. Each role-template providesaccess to a number of methods on variousscopes to a user. To further restrict access oneach of those methods based on arbitrary con-ditions, we introduce a new element:methodRef. This construct enables us to asso-ciate conditions and actions with a method. Amethod can have a condition and one or moreactions associated with it. The modified schemaskeleton for a role-list document is shown inFigure 4. The elements and attributes introduced

to role-list to support conditions and actionsbased policies are described.

/roleList/role/methodRef element refers tothe ID of the method for this role in its role-template. Multiple method IDs can be referencedhere (e.g., methodRef = “1,2”). In this case, theconditions and actions are performed for themethods with IDs 1 and 2. /methodRef/@idRefattribute gives the reference to the method ID inthe role template referred to by this role.

/roleList/role/methodRef/condition ele-ment is a Boolean formula. If the formula evalu-ates to true, then the access is granted. In gen-eral, the condition expression can involve sev-eral predicates involving standard logic opera-tors, such as and, or, and not. Defining a condi-tion element within another condition elementcan specify recursion. That is, a condition alsocan be a predicate. Recursion is useful to specifypolicies such as (A OR B) AND (C OR D), whereA, B, C, and D are different conditions to beevaluated before authorizing access to a method.Each predicate may have one or more parameters.

/roleList/role/methodRef/action speci-fies actions that need to be performed when anaccess request is made to the method(s)through methodRef. Each action has an optionalID attribute. The type attribute is used to definewhether the action only is performed when theaccess is granted (on_access) or always is per-formed whether or not access is granted (always).The predicates in action expressions are similarto those defined in conditions, except that thereshould be at least one predicate element.

An example conditional authorizationpolicy is shown in Figure 5. In the example, apatient (Bob) can access only his own patient

Figure 3. Role-map example with minor extension



record, if he is located within the hospital. Wedo this by using a predicate checkUserID thatmatches Bob’s identity (ID) (after authentica-tion) with the ID in his record. The predicatecheckUserLocation is used to find the currentlocation of Bob. Both the predicates used donot take any parameters as input. In the ex-ample policy, the condition is evaluated, andthe action is always performed, whether accessis granted or not. That is, each time an accessto a patient record is requested, the action islogged for auditing purposes.

Role HierarchyOne of the advantages of the role-based

approach is that it can model the privileges inan organization more effectively. A simplisticview of an organization structure is a hierarchi-cal ordering of responsibilities, with the seniorpositions encompassing all the privileges of thejunior positions with some extra privileges. Sucha role hierarchy can be achieved by providinghierarchy in role-template definition. At present,most of the services in .NET MyServices only

Figure 4. Modified schema skeleton for role-list to support conditional authorization

Figure 5. Example of conditional authorization policy



use about three to five role templates. Custom-ized roles and role hierarchy policies cannot bespecified using the authorization policy lan-guage. We propose the following extensionsto .NET MyServices authorization policy lan-guage in order to enable role-based access con-trol and role hierarchy. Each service should beable to associate itself with a dynamic role-mapat the user level. The role-map must be static atthe Web Service level, but the provider shouldbe able to change it, when needed. Therefore,every provider will now have his or her role-map along with the Web Service role-map. Wename the provider’s role-map as the provider-role-map (XML document name = providerRoleMap).New scopes now can be defined in this pro-vider-role-map instead of in the provider’s role-list. We also remove all scope definitions fromthe role-list for a provider and move them to theprovider-role-map for consistency. The role-template names in provider-role-map must beanything other than rT0, rT1, rT2, rT3, or rT99,as these are the default role-template names.Every method in the default Web Service role-map and provider role-map now must have anID number attribute to uniquely identify themethod.

When a provider is provisioned to a ser-vice, the provider has his or her own providerrole-map document along with the content,system, log, and acl (role-list) documents. Our

definition of XML schema skeleton forproviderRoleMap is shown in Figure 6.

The schemas for scope, role-template,and their child elements and attributes are thesame as those defined for the Web Service role-map. Other elements and attributes introducedto specify role hierarchy policies are describedas follows.

providerRoleMap/ro leTemplate /includeRT element is introduced to specify hi-erarchy. A role-template can inherit another role-template’s privileges with this element. /includeRT/@name attribute is introduced tospecify the name of the parent role-template.

providerRoleMap/roleTemplate/over-ride element is provided to override either ascope or method name for a role-template’smethod. /override/@rtName attribute refers tothe role-template (inherited) in which the over-riding is to be done. If the mentioned role-tem-plate is not inherited with an includeRT ele-ment, override element is ignored. /override/@idRef attribute is provided to refer to themethod element (using its ID) from the inher-ited role-template that is to be overridden. /over-ride/@methodName is an optional attribute. Itshould be used only when the method in theinherited role-template is to be overridden. /override/@scopeRef is an optional attribute. Itshould be used only when the scope in theinherited role-template is to be overridden.

Figure 6. Schema skeleton for provider-role-map



Note that the role-templates inherited ei-ther can be the default role-templates from theWeb Service role-map or from the provider-role-map. To achieve role hierarchy, a suitablenew role-template (with appropriate hierarchydefinition) in the provider role-map can be cre-ated. Then, the role-template can be associ-ated with suitable role element(s) in theprovider’s role-list.

For illustration purposes, a few scenariosare shown in Figure 7. Role-templates rt10, rt20,and rt30 are defined in the example. Role-tem-plate rt30 inherits privileges from both rt10 andrt20. Method with ID “4” from rt10 is overrid-den in rt30 to create. Scope for method with ID2 (insert) from rt20 is overridden to 2 in rt30.

Dynamic Separation of DutyIn the case of dynamic separation of duty,

a user having chosen a specific action or role atruntime is not authorized to perform another ac-tion or assume another role. To begin with, theuser is allowed to choose either of the actions orassume either of the roles. A user may have twoprivileges (p1 and p2) but cannot have both onthe same object. Compliance with these require-ments only can be determined at runtime. Weintroduce a new element called dynamicRole tothe role-list’s schema to support specification ofdynamic separation of duty policies. The modi-

fied schema skeleton for role-list document isshown in Figure 8. Extensions to the role-listschema are described in subsequent paragraphs.

/roleList/dynamicRole element is intro-duced to support dynamic separation of dutypolicies. Most of the child elements and at-tributes for this element are exactly the same asdefined for the role element. Only the new ele-ments and attributes are described here. /dynamicRole/RT — a minimum of two (or more)RT elements — must be used in each dynamic-role. RT encapsulates both role-template andthe scope on which it is used, along with theconditions and actions on the methods. Theuser with a dynamic-role has access to any ofthe role-templates and on any of the scopesassociated with a dynamic-role. The role-tem-plate scope pairs are mutually exclusive. Oncethe user accesses a method in a role-templateon a scope (privilege provided by RT), he orshe is not allowed to access any other privi-leges provided by his or her other RT elements./dynamicRole/RT/scopeRef stores the scope towhich the user has access. /dynamicRole/RT/roleTemplateRef stores reference to the role-templates IDs to which the user has access.

/roleList/dynamicRole/usedRT/ is intro-duced to store information to enable dynamicseparation of duty. /usedRT/idRef is defined tostore the reference (ID) to one of the RT ele-

Figure 7. Example role hierarchy policy



ments (in this dynamic-role). Until the first timea user accesses any of the privileges in his orher set of RT elements, usedRT is null. Oncethe user accesses privileges provided by anyof the RT elements, the ID of that RT element iswritten here by the authorization service. Ev-ery method in an RT element uses thecheckAccess predicate. This predicate imple-ments the logic to enforce the dynamic separa-tion of duty policy using information in usedRT.

In the example of dynamic separation ofduty policy shown in Figure 9, a doctor (Alice)both can write a medical report after a medicalprocedure and certify it but cannot write andcertify the same medical report. In our example,scope 1 denotes the part (scope) of the patientrecord document used to write the medical re-port, and scope 2 denotes the part of the docu-ment to certify the medical report. For a patient(Bob), if Alice chooses to write a medical re-port, the idRef value in usedRT element for Alicein that patient’s role-list document is set to 1. Ina subsequent access to Bob’s record, Alice can-not certify the medical report, as thecheckAccess predicate uses the usedRT valuepassed as a parameter and enforces the dy-namic separation of duty at runtime.

DelegationOur extended authorization model sup-

ports two forms of delegation policies:Forwardable and Proxiable. Forwardable delega-tion is used when privileges are being delegatedto a client application that acts on behalf of theuser. Proxiable delegation is used where del-egation is between real-world users. A detailedanalysis of delegation in distributed systems ismade in Varadharajan, et al. (1991).

Our delegation scheme only allows trans-fer of privileges less than or equal to privilegesowned by the user delegating his or her privi-leges. If more privileges are delegated, thenaccess to the delegate will be denied at runtime.Whenever delegation of privileges is made, theaccess details must be logged in to theprovider’s log document, clearly mentioningwho delegated what privileges to whom. Wesuggest that such dynamic delegation be speci-fied by extending the authentication tickets andprotocols in order to carry privileges and au-thorization information. As such, this needs tobe achieved in the Passport (Microsoft Corpo-ration, 1999) protocol used by .NET MyServices.

In the case of static delegation, such as amanager delegating part of his or her privilegesto a personal assistant, one can create a del-

Figure 8. Modified schema skeleton for role-list to support dynamic separation of duty policy



egated-role (delegatedRole element) in theprovider’s role-list document using our exten-sions to the policy language. This saves pro-cessing overhead, as each time the personalassistant accesses his or her manager’s privi-leges, his or her privileges need not be com-puted from the authorization data field in theauthentication ticket. Hence, a user requestinghis or her privileges to be delegated must sendthe type of delegation information — eithertemporary or permanent — along with the re-quest. If it is temporary (i.e., one-time delega-tion), then at runtime, the privileges are verifiedwith the user’s role-template, and access is de-nied or granted according to the authorizationalgorithm. If it is permanent, then a delegated-role is created in the provider’s role-list docu-ment for the delegate. The schema for thedelegatedRole element is defined next. Note thatfor a permanent delegation type request, if thegranted privileges are a subset of the sender’s

privileges, then a new role-template element iscreated for those privileges in the provider role-map, and the delegated-role refers to it. Modi-fied XML schema skeleton for role-list documentto enable static delegation is shown in Figure10. Schema modifications for a role-list docu-ment are described in subsequent paragraphs.

/roleList/delegatedRole element repre-sents a user with delegated privileges. This el-ement is created dynamically when a delega-tion request comes in. The role-template andscope for this delegated-role are set per therequest. Once this is set up, the user with thesedelegated privileges has similar access privi-leges to those of a normal user. Other child ele-ments and attributes for this element are similarto a normal role element. They are not rede-fined here. In /delegatedRole/expiresAt, unlikein the normal role element, the expiresAt ele-ment is mandatory here. If the user delegatinghis or her privileges does not mention when

Figure 9. Example of dynamic separation of duty policy



the delegated-role should expire in the request,then the Web Service default is stored herewhen the delegated-role is created. Every ser-vice must define a default expiry time for a del-egated-role. Once this delegated-role expires,then the user with these privileges no longerhas access. To regain this access, an explicitdelegate request should be made again.

An illustration of the delegation policy isgiven in Figure 11. In the example, the doctorAlice delegates (proxiable form of delegation)permanently certain privileges (roleTemplatert10 from Figure 7) that she gives to Jane, herpersonal assistant. In particular, Alice delegatesprivilege to query on scope 1. Our extendedauthorization service automatically generatesa delegated-role for Jane, once the delegationrequest is approved. Also, a new role-template(e.g., rt11) is created in the provider-role-map

to reflect the privileges given to Jane. rt11 isshown in Figure 11. The delegated-role for Janeis associated with rt11.

Joint Action-Based PoliciesJoint action-based policies (Varadharajan

et al., 1996) are used in situations where trust inindividuals needs to be dispersed. Often this arisesbecause individuals are trusted according to theirexpertise, which, in turn, maps the concept of trustto a specific set of actions. In delegation, there isa partial or complete granting of privileges;whereas, in joint actions, users may acquire privi-leges by working together in tandem, which nonepossesses in isolation. We provide an example ofa joint action-based policy after describing XMLschema extensions. A modified XML schema skel-eton for provider-role-map is shown in Figure 12and for role-list in Figure 13.

Figure 10. Modified schema skeleton for role-list document to support delegation policy

Figure 11. An example of delegated-role



A description of schema extensions toprovider-role-map document follows.

providerRoleMap/ro leTemplate /jointMethod element is added to a role-tem-plate. It defines a joint method and its quorumnumber. A joint-method’s name, scopeRef, andID attribute schemas are the same as the schemafor a normal method. They are not redefinedhere. /jointMethod/quorum element gives theauthorization service the quorum number forthis joint method. Quorum is the minimum num-ber of times users (who have access) must in-voke the joint-method in order for it actually to

be committed. A temporary Boolean flag is usedto store the invocation information until thequorum is reached.

A description of schema extensions torole-list document follows.

/roleList/role/jointMethodRef: There areas many jointMethodRef elements in a role, asthere are joint-methods in the role-template withwhich it is associating itself. It is similar to amethodRef element, except that it has a Bool-ean flag element. All other elements injointMethodRef schema are exactly the sameas those defined for methodRef schema. /

Figure 12. Modified schema for provider role-map to support joint actions

Figure 13. Modified schema for role-list to support joint actions



jointMethodRef/@idRef attribute refers to thejoint method’s ID. It is used to uniquely refer toa joint-method.

/roleList/role/jointMethodRef/condi-tion/flag element is a Boolean value that en-capsulates information about invocation of ajoint-method. /condition/flag/reducedScope isan optional element. It may so happen that auser should gain authorization only to performa joint action on a further reduced scope thanthat permitted by his or her role-template. Thisscope element solves such a purpose. Shapeelement schema is the same as the one definedfor scope element in role-map. /condition/flag/value by default is set to false. When the re-quest for the joint-method comes in from theuser represented by a role, the flag value in thatuser’s role element is set to true. Until the quo-rum is reached, only this flag in the participat-ing users’ role elements is set to true. Once thequorum is reached, the actual action is commit-ted on the content document of the provider.

A new predicate called “checkQuorum”is defined for all services that need to imple-ment joint action based policy. EveryjointMethodRef element in a role element mustcall this predicate in its condition. checkQuorumpredicate does the following:

• When a call to a joint-method is made, thepredicate checks the number of flags thatare set to true in the roles that have accessto this joint-method.

• If the number of flags set to true is morethan or equal to the quorum defined in thejoint-method, then the actual action is com-mitted or else the flag in the caller’sjointMethodRef element is set to true.

An illustration of joint action-based policyis given in Figure 14. In the example, the policystates that two or more doctors are required tojointly certify a patient’s medical report after amedical procedure. Role-template rt20 definesjoint-methods for write, update, and delete meth-ods. This means that two or more doctors mustinvoke write method (i.e., certify the medicalreport) on the medical report in order for it to becommitted. The same applies for update and

delete methods. However, the doctors can readthe medical report at any time, as query is de-fined as a normal method.

In the example, Alice and Bob are doc-tors, and both of them certified the medical re-port. This is indicated by the current status ofthe flag values. The flag values are currentlytrue. This means that the status of the joint-action, certifying a medical report, is commit-ted. This demonstrates how different users canwork together in tandem and perform an actionor acquire a privilege, which none possesses inisolation.

Other Policies Supportedby the Extended Model

We cannot specify only conditional au-thorization policies, separation of duty policies,role hierarchy policies, delegation policies, andjoint action-based policies, but also other poli-cies, such as the Chinese-wall policy and userand session constraints using our extendedauthorization policy language. We can specifyvarious constraints on subjects such as mu-tual exclusion set on roles, cardinality con-straints on roles, and users using the extendedauthorization policy language. For example, asubject cannot be assigned to both Doctor andPatient roles at the same time (in this case, Doc-tor and Patient roles are mutually exclusive).Another example of a constraint is that the to-tal number of users that are authorized as nursescan be limited to five. Session constraints suchas “a role or user only can activate two ses-sions at any one time” also can be specified.Role activation constraints such as “a subjectassigned to both Doctor and Doctor-in-chargeroles cannot activate both the roles in a ses-sion at any one time” can be specified. We willgive an illustration of the Chinese-wall policyin the system implementation section.

Authorization AlgorithmThe .NET MyServices authorization al-

gorithm is redefined here to take into accountthe extensions proposed to the authorizationmodel. We refer the reader to Microsoft Corpo-ration (2001a) for original authorization algo-rithm for .NET MyServices.



1. The user, application, and platform identi-ties as well as the credential type are deter-mined from a user request.

2. The matching role from the Web Serviceprovider’s role-list document then is located.If a matching role, delegated-role, or dy-namic-role is not found, then the user re-quest is not authorized.

3. If a matching role or delegated-role is found,then:

• If the matching role contains expiry infor-mation (in expiresAt element), it is checkedto see if the role has expired. If so, theuser request is not authorized (expiresAtelement use is mandatory for delegated-roles).

• The role-template (referenced by the role)is located in the respective role-map or pro-vider-role-map. This template is checkedto see if the method or joint-method re-quested is allowed by it. If it is not allowed,then the user request is not authorized.

• Using the scope from the role-map or pro-vider-role-map (referenced by role-tem-plate), combined with the optional scopereferenced by the role, the node set thatis visible to this message is determined.

4. If a matching dynamic-role is found, then:

• If the matching dynamic-role contains ex-piry information, it is checked to see if ithas expired.

Figure 14. An example for joint-action policy



• If the dynamic-role has not expired,usedRT’s idRef value in the dynamic-roleelement is verified. If the value is null,then:

• The role-template and scope refer-enced by first RT element are locatedfrom the role-map or provider-role-map. This template is then used todetermine whether the method orjoint-method requested is allowed.The scope is used to determine ifthe operation requested is withinthat scope. If either the method can-not be invoked or the operation isnot within the scope, then the role-template and scope referenced bythe next RT element are located. Itthen is determined if the access tothe method or joint-method re-quested is allowed. Similarly allother RT elements in the dynamic-role are verified to determine if theoperation requested is within thespecified scope. If none of the RTelements provide the requestedprivileges, then the user request isnot authorized.

• The usedRT’s idRef is set to thevalue of the ID attribute of the RTelement that gives the requestedprivileges.

• If idRef value in usedRT element refers toan RT’s ID, and if either the method is notallowed by the role-template in that RT orif the operation requested is not withinthe scope specified, then the user requestis not authorized.

• Using the scope from the role-map or pro-vider role-map referenced by the role-tem-plate, combined with the optional scopereferenced by the RT in the dynamic-role,the XML node set visible to the user iscomputed.

5. If the method requested is a normal method,then:

• All conditions are evaluated, and if anyone returns false, then the user request isnot authorized.

• All the actions with type set to alwaysare performed.

• All the actions with type set to on-accessonly are performed, if condition is true.

6. If the method requested is a joint-method,then there exists at least one predicate(checkQuorum) in the condition element. Inthis case:

• The condition is evaluated. If it returnsfalse, the user request is not authorized.

• Otherwise, all the actions with type set toalways are performed.

• All the actions with type set to on-accessonly are performed, if condition is true.

The requested operation is then autho-rized, ensuring that the user has no access toinformation outside the scope computed instep 3.

IMPLEMENTATIONOF EXTENDEDAUTHORIZATION MODEL

In this section, we first introduce XACLand then describe the system architecture.

Introduction to XACLOur choice to use XACL access control

language in our demonstration to specify au-thorization policies and its policy evaluationengine to enforce them is based on the follow-ing reasons.

1. XACL is an XML-based access controlpolicy language.

2. It provides for an implementation of a pro-cessor that provides for provisional autho-rization (Kudo et al., 2000). This closelymatches our requirement for conditional au-thorization policies.

3. XACL supports RBAC policies, which is animportant requirement, as discussed earlier



in the authorization policy language featuressection.

4. XACML (Godik & Moses, 2003) specificationfor the expression of authorization policies isbased strongly on the XACL language and inthe future could become a standard for speci-fying authorization policies for Web Services.

XACL provides fine-grained provisionalaccess control to XML documents. It is imple-mented using the Java language. XACL is anaccess control policy specification language andis oriented around triples of subject, object, andaction. Every subject has a user ID and eithercan be part of a role or a group. An object can bea single XML element or attribute in an XMLdocument or the entire document. The actionscan be read, written, created, or deleted. XACLprovides the notion of provisional actions thatare attached to the access decision. For example,if a provisional action log is specified in the ac-cess control rule of “Alice is allowed to read theHIV status field of a patient,” it means that “Aliceis allowed to read the HIV status field of a pa-tient, provided the access is logged.”

Health Care Application:System Architecture

We used the access control requirementsfor medical practice given by the specification

in Sim (2002) to implement the health care appli-cation. We created the health care applicationas a .NET Web application. Per the specifica-tion, the roles required for the medical practiceare Patient, Receptionist, Pathology Collector,Nurse, Doctor, Doctor-in-charge, and PracticeManager. Each of these roles has a specific setof privileges. We mapped those privileges intospecific XACL policies. We specified role, ses-sion, and user constraints and also a range ofaccess control policies such as those discussedin the extended authorization model sectionusing XACL in our demonstration. In this sec-tion, we outline the high-level, three-tier archi-tecture overview (shown in Figure 15) of ourimplementation.

Presentation Tier. The health care appli-cation is exposed to clients such as doctors,patients, and nurses using Web pages built withASP.NET Web Forms technology.

Incoming HTTP requests are filtered us-ing the Authorization Filter, and access is con-trolled appropriately. The Authorization Filteris a .NET component. All the Web Service re-quests pass through the Authorization Filterand are sent to the XACL processor for accesscontrol evaluation. XACL processor is an au-thorization policy evaluation engine that givesout a decision after evaluating the request us-

Figure 15. System architecture: Overview



ing the policies specified. It generates a deci-sion list with permit or deny permission to eachelement and attribute in the set of XML nodespassed in the request. The Authorization Filterreceives these decisions as output and givesappropriate read, write, or modify permissionsto each of the XML elements and attributes inthe patient record. The text boxes in the Webinterface, for instance, are disabled for writing ifthere is no write access for a nurse on a field inthe medical record. However, when there is readaccess, the data is visible to the nurse. If bothread and write operations are not allowed, thetext box is grayed out, and no data are visible.

The Authorization filter makes use of .NETRemoting technology (Microsoft Corporation,2001c) and JNBridgePro (JNBridge Corporation,2002) proxy tool to send the authorization re-quests to XACL (running) on a Java platformfrom the .NET platform and receive the accesscontrol decisions back on the .NET platform.

Business Logic Tier. The application’slogic is implemented as Web Services.EssentialDetailsWS, ClinicDetailsWS, andHealthDetailsWS are the Web Services used toread, write, create, or delete the essential, non-essential, clinic, and health details of a patient

in his or her record. The fourth Web Services,E-ConsentWS, is used to set the consent ofthe patient on his or her record.

The XACL processor is a Java class thatimplements the authorization logic for policyevaluation on the lines of our extended autho-rization algorithm. It takes the target, request,policy, status, role hierarchy, and group hierar-chy files as input parameters in the form of XMLdocuments. It gives the access decision on eachXML element and attribute as output.

Data Tier. We use an SQL Server to storeboth the medical records and the authorizationpolicies. The medical records in the system arestored in XML format using the SQLXML(Microsoft Corporation, 2004) technology in aMicrosoft SQL Server. The security policies areassociated with them, as shown in Figure 16.

Each patient has an ID, and the name ofthe XML file is ID.xml. For example, if a patient’sID is 1234, then the patient’s correspondingrecord is 1234.xml. The patient records consistof four main XML sections holding the patient’sessential details, non-essential details, clinicdetails, and health details.

The system also maintains a users.xmlfile that consists of each user’s user ID and

Figure 16. Data and policy view



password along with the roles to which he orshe is provisioned and other role-session con-straints details. The security administrator main-tains this XML file. When a user logs in (using.NET passport authentication), he or she is pro-vided the choice of choosing which roles he orshe wants to activate in the current session.

The global security policy file gpolicy.xmlcontains the XACL access control policies ap-plicable to all patient records (resources) and toall users (subjects) in the system. The globalsecurity attribute file gatt.xml contains the glo-bal attributes details required to enforce accesscontrol policies. For example, an access policycould state that a doctor only can access patientrecords from a location in Sydney. As this policyis generic (i.e., applies to all patient records), theattribute — location — for a doctor is stored inthis file when he or she is authenticated.

The e-consent file pid-policy.xml is usedto record the individual patient’s consent whenhe or she creates a record with the medical prac-tice. E-consent policies also can be seen as pro-tecting a client’s privacy. When a receptionistcreates the record for the first time, the patientconsent is asked and recorded in his or her file.The consent given at the record creation timeis not static and can be changed at any time bythe patient.

We allow for four types of e-consent:

1. General Consent. Global policy applies tothis patient’s record.

2. General Consent With Specific Denial. Glo-bal policy applies to this patient’s record.However, the patient is allowed to explicitlydeny access to any subject.

3. General Denial. Global policy does not ap-ply here. Patient explicitly creates the policyfor himself or herself, which is stored in pid-policy.xml.

4. General Denial With Specific Consent. Pa-tients are allowed to explicitly give specificconsent to subjects. This consent informa-tion either can be stored in the global policyand/or the personal policy in pid-policy.xml.

The patient record security attribute filepid-att.xml stores the security attributes relevant

only to this patient’s record. For example, if apatient (Bob) with patient ID = 9876 wishes tolimit the number of accesses to his file to fivetimes to a nurse (Alice), the current number ofaccesses by Alice to his record will be stored inthe file 9876-att.xml.

EXTENSIONS TO XACLAs mentioned earlier, we used the XACL

processor to demonstrate our extended autho-rization model. In our model, authorization poli-cies used in commercial environments such asconditional authorization, role-hierarchy, dy-namic separation of duty, delegation, Chinese-wall policy, joint-action-based policies, and lim-ited number of accesses policy can be speci-fied. Using the concept of provisional authori-zation (Kudo et al., 2000), XACL can be used tospecify conditional access control policies,which we can specify in our model. Similarly,role-based access control policies can be speci-fied using XACL. However, dynamic separa-tion of duty, delegation, Chinese-wall policy,joint-action based policies, and limited numberof accesses policies cannot be specified usingXACL. We extended XACL to be able to specifyand enforce such policies. We were able to dothis by implementing the genericProvisionalActionInterface interface providedby the XACL Application Programming Inter-face (API). We implemented the provisionalaction checkDynamicAccess to enforce dy-namic separation of duty policies,checkDelegation to enforce delegation policies,checkCWPSet to enforce Chinese-wall policy,checkJointAction to enforce joint action-basedpolicies, and checkLimit to enforce a limitednumber of access policies. In the next section,we discuss how we are able to specify Chi-nese-wall policy (Brewer et al., 1989) using ex-tended XACL.

Chinese-Wall PolicyIn Chinese-wall policy (Brewer et al.,

1989), objects are grouped together into differ-ent conflict of interest sets. Let us assume thatevery patient record belongs to a hospital andto only one department within the hospital. So,the patient records are grouped into:



Set A. Departments (Cancer Research, Cardiol-ogy, Neurology)

Set B. Hospitals (ABC Hospital, PQR Hospital,XYZ Hospital)

The global policy may wish to implementChinese-wall policy on interns when they ac-cess the patient records. The interns may beallowed to do research by accessing patientrecords from only one department in set A and

from only one hospital in set B. According to theChinese-wall policy, an intern (Bob) initially mayaccess any of the documents from Set A and SetB. Once Bob chooses a medical record from acategory (Cardiology) from Set A, he is not al-lowed to access any other category from thatset. Similarly, if the record chosen is from XYZHospital, Bob is not allowed to access patientrecords from any other hospital in Set B.

In Figure 17, we show how to specify therequired Chinese-wall policy in XACL. We also

Figure 17. Global attribute and XACL policy files



show the attributes required for Bob in the glo-bal attribute file. The global attribute file con-tains the definition for the Chinese-wall policysets. The CWPSet attribute records the ac-cessed categories information needed to en-force the Chinese-wall policy. ThecheckCWPSet provisional action implementsthe logic necessary to enforce the Chinese-wallpolicy on interns. It does the following:

• It takes two parameters — the global at-tribute file and the user ID. It searches forthe user’s CWPSet attribute in the attributefile and gives suitable access as per Chi-nese-wall policy.

• It writes to the CWPSet of the user the firsttime the user accesses a category in a set.

RELATED WORKWS-Policy (IBM et al., 2004) specifica-

tion is used to specify policy assertions asso-ciated with a Web Service. The WS-Trust(Anderson et al., 2005) language uses the se-cure messaging mechanisms of WS-Security(Atkinson et al., 2002) specification to defineadditional primitives and extensions for the is-suance, exchange, and validation of securitytokens. WS-Trust also enables the issuanceand dissemination of credentials within differ-ent trust domains. However, because WS-Se-curity was published prior to WS-Policy, WS-SecurityPolicy (Della-Libera et al., 2002) lan-guage was created to specify security-relatedassertions required for a Web Service.

A security policy specified using WS-SecurityPolicy language is a set of domain-spe-cific policy statements. A policy statement is agroup of policy assertions. A policy assertionrepresents an individual preference, require-ment, capability, or other property. SecurityToken assertion informs a Web Service’s clientwhat kind of security token it needs to sendbefore invoking a Web Service. A security to-ken assertion either can be a X.509 or a Kerberoscertificate, a SAML (OASIS, 2005) assertion oran XrML (OASIS, 2003) assertion. Similarly, in-tegrity and confidentiality assertions specifiedin a WS-SecurityPolicy statement inform a cli-ent what integrity and confidentiality mecha-

nisms a client needs to use. If our extendedXACL authorization policy language or anyother XML-based authorization policy lan-guage is standardized for Web Services, thereis a requirement to extend WS-SecurityPolicylanguage’s XML schema to add a new authori-zation assertion token. A Web Service will usethis assertion to inform its clients about whatprivilege attributes are required to get autho-rized to the Web Service.

XACML (Godik et al., 2003) defines a coreschema and corresponding namespace for theexpression of authorization policies in XMLagainst objects that are identified in XML. Thislanguage in the future could become a stan-dard to specify authorization policies for WebService. XACL, on which XACML specifica-tion is based, has a Java implementation. Asmentioned earlier, this is another reason for usto use XACL to implement our extended autho-rization model.

Damiani, et al (2002) propose a model forfine-grained access control policies for XMLdocuments. Gabillon, et al (2002) define a secu-rity model for regulating access to XML docu-ments. However, these models are designedonly to control access to XML documents andnot to any generic resource. They also do notsupport features such as provisional authori-zation supported by XACL.

Damiani, et al (2002) also propose an ap-proach that relies on the XML structure ofSOAP requests and supports fine-grained au-thorizations at the level of individual XML ele-ments and attributes that comprise a SOAP call.This work complements our work, as it looksinto fine-grained authorization on XML ele-ments and attributes when they are transportedwithin SOAP requests and responses over thenetwork.

SAML (OASIS, 2005) is an XML-basedsecurity specification for exchanging authenti-cation and authorization information about auser or subject. It defines XML schema anddefinition for security assertions. The asser-tions are of three types—authentication, anysecurity related attributes for the subject, andfinally, the authorization decisions given basedon the security/privilege attributes. SAML also



can be extended to send any arbitrary securityassertions. This shows that SAML is used pri-marily to carry security/privilege attributes re-lated to a subject from one entity to another ina network. The only requirement is that bothentities comply with the SAML standard. Thisspecification complements our work, as we needa standard mechanism to carry authenticationand authorization-related attributes on behalfof a subject to the entity evaluating the autho-rization policies.

XrML (OASIS, 2003) is another specifi-cation for XML-based policy language for con-trolling access to digital resources. However, itis designed in specifics for specifying and man-aging rights and conditions for digital resources,such as audio and video. For instance, if a digitalmedia player has an XrML-compliant rights en-forcer, the media played on it can have XrML-based policies associated with it to restrict theusage of the media only to licensed users. XrMLtries to solve the problem of digital rights man-agement and is not designed to specify autho-rization policies streamlined for stand-aloneapplication systems or Web Service.

CONCLUDING REMARKSAt present, there are several efforts un-

derway that are striving for the provision ofsecurity services, such as authentication be-tween participating entities, confidentiality, andintegrity of communications. Currently, how-ever, most applications, having gone throughthe authentication process, make authorizationdecisions using application-specific accesscontrol functions that are inflexible and inad-equate. There remains a significant amount ofresearch that needs to be done in the area ofauthorization in large-scale deployment of WebServices in heterogeneous environments. Thereare a lot of similarities in the design of authori-zation service and architecture between distrib-uted applications and Web Services. One as-pect that makes it somewhat different is theneed to take into account multiple domains andjurisdictions in a federated structure as a de-fault. We discussed the fundamental designissues that need to be taken into considerationwhen building an authorization framework for

Web Services. In this paper, we specificallyaddressed the features that an authorizationpolicy language designed for Web Servicesmust have.

We introduced the authorization modelused by .NET MyServices. We then discussedour proposed modifications and extensions tothe authorization model. In particular, we ex-tended the authorization policy language tosupport a range of access control policies, in-cluding conditional access control policies,dynamic separation of duty policies, Role BasedAccess Control (RBAC) policies, delegationpolicies, joint-action-based policies, and Chi-nese-wall policies required in commercial envi-ronments. We redefined the .NET MyServicesauthorization algorithm to reflect the extensionsthat we proposed to the authorization model.We then discussed the application of the ex-tended authorization model to a health careapplication. We gave an overview of the high-level three-tier system architecture of our imple-mentation. We used the XML Access ControlLanguage (XACL) in our implementation todemonstrate our extended authorization model.This is because XACL is an XML policy lan-guage that supports RBAC policies and provi-sional authorization. This enabled us to evalu-ate the range of access control policies sup-ported by XACL and propose extensions tothe XACL policy language to be able to specifya range of access control policies, includingrole-hierarchy, dynamic separation of duty, del-egation, the Chinese-wall policy, joint-action-based policies, and limited number of accesses.For illustration purposes, we provided an ex-ample that shows the specification of the Chi-nese-wall policy using the extended XACLpolicy language.

ACKNOWLEDGMENTSThe authors would like to thank the Aus-

tralian Research Council and Microsoft Pty.Australia for their support.

REFERENCESAnderson, S. et al. (2005). Web Services trust

language (WS-Trust). Retrieved from http://www-106.ibm.com/developerworks/li-



brary/specification/ws-trust/Ash, D. et al. (2004, April 5). XML key manage-

ment specification (XKMS 2.0). Retrievedfrom http://www.w3.org/TR/xkms2/

Atkinson, B. et al. (2002). Web Services security(WS-Security) specification. Retrieved fromhttp://www-106.ibm.com/developerworks/webservices/library/ws-secure/

Bartel, M., Boyer, J., Fox, B., LaMacchia, B., &Simon, E. (2002, February 12). XML-signa-ture syntax and processing. Retrieved fromhttp://www.w3.org/TR/xmldsig-core/

Brewer, D.F.C., & Nash, M.J. (1989). The Chi-nese wall security policy. In Paper Presentedat the IEEE Symposium on Security andPrivacy.

Christensen, E., Curbera, F., Meredith, G., &Weerawarana, S. (2001). Web Services de-scription language (WSDL) version 1.1. Re-trieved from http://www.w3.org/TR/wsdl

Damiani, E., De Capitani di Vimercati, S.,Paraboschi, S., & Samarati, P. (2002). Secur-ing SOAP e-services. International Jour-nal of Information Security, 100-115.

Damiani, E., Vimercati, S.D.C.D., Paraboschi, S.,& Samarati, P. (2002). A fine-grained accesscontrol system for XML documents. ACMTransactions on Information and SystemSecurity, 5(2), 169-202.

Damianou, N., Dulay, N., Lupu, E., & Sloman,M. (2001). The ponder policy specificationlanguage. In Proceedings of the Interna-tional Workshop on Policies for DistributedSystems and Networks, (pp. 18-38). Springer-Verlag.

Della-Libera, G. et al. (2002). Web Services se-curity policy language (WS-SecurityPolicy).Retrieved from http://www-106.ibm.com/developerworks/library/ws-secpol/

Gabillon, A., & Bruno, E. (2002). Regulating ac-cess to XML documents. In Proceedings ofthe 15th Annual Working Conference onDatabase and Application Security.

Godik, S., & Moses, T. (2003, August 7). eXtensibleaccess control markup language version 1.1.Retrieved from http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

Gudgin, M., Hadley, M., Mendelsohn, N.,Moreau, J.-J., & Nielsen, H.F. (2003, June

24). SOAP version 1.2. Retrieved from http://www.w3.org/TR/soap12-part1/

Herzberg, A., Mass, Y., Michaeli, J., Ravid, Y., &Naor, D. (2000). Access control meets publickey infrastructure, or: Assigning roles tostrangers. In Proceedings of the 2000 IEEESymposium on Security and Privacy.

Hitchens, M., & Varadharajan, V. (2000). De-sign and specification of role based accesscontrol policies. IEE proceedings, Software.

IBM, BEA, Microsoft, SAP, Sonic Software, &VeriSign. (2004). Web Services policy frame-work (WS-Policy). Retrieved from http://www-128.ibm.com/developerworks/li-brary/specification/ws-polfram/

Imamura, T., Dillaway, B., & Simon, E. (2002,December 10). XML encryption syntax andprocessing. Retrieved from http://www.w3.org/TR/xmlenc-core

Indrakanti, S., Varadharajan, V., Hitchens, M.,& Kumar, R. (2003, August 4-6). Secure au-thorization for Web Services. In Paper Pre-sented at the 17th IFIP Conference on Dataand Applications Security, Estes Park, Colo-rado.

Jajodia, S., Samarati, P., Subrahmanian, V.S., &Bertino, E. (1997). A unified framework forenforcing multiple access control policies.In Proceedings of the 1997 ACM SIGMODInternational Conference on Managementof Data (pp. 474-485). ACM Press.

JNBridge Corporation. (2002). JNBridgepro us-ers’ guide version 1.2. Retrieved from http://www.jnbridge.com/docs.htm

Kent, S., & Atkinson, R. (1998, November). Se-curity architecture for the Internet protocol,RFC 2401. Retrieved from http://www.ietf.org/rfc/rfc2401.txt

Kraft, R. (2002, November 22). Designing a dis-tributed access control processor for net-work services on the Web. In Paper Pre-sented at the ACM Workshop on XML Se-curity, Fairfax, Virginia.

Kudo, M., & Hada, S. (2000). XML documentsecurity based on provisional authorization.In Proceedings of the ACM Conference onComputer and Communications Security(CCS), Greece.

Microsoft Corporation. (1999). .NET passport Web



site. Retrieved from http://www.passport.netMicrosoft Corporation. (2001a). .NET

MyServices Specification. Microsoft Press.Microsoft Corporation. (2001b). Microsoft .NET

MyServices specification. Microsoft Press.Microsoft Corporation. (2001c). Microsoft .NET

remoting: A technical overview. Retrievedfrom http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/hawkremoting.asp

Microsoft Corporation. (2004). SQLXML. Re-trieved from http://msdn.microsoft.com/li-brary/default.asp?url=/library/en-us/dnanchor/html/anch_SQLXML.asp

OASIS. (2003). Extensible rights markup lan-guage (XrML) version 2.0. Retrieved fromhttp://xml.coverpages.org/xrml.html

OASIS. (2005, January 17). Security assertionmarkup language version 2.0. Retrieved fromhttp://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

O’Keefe, C.M., & Greenfield, P. (2003). Role andexpression of consent in Web Services. InPaper Presented at the International Con-ference on Web Services, Las Vegas, Nevada.

Rescorla, E. (2001). SSL and TLS: Designingand building secure systems. AddisonWesley.

Sandhu, R., Coyne, E.J., Feinstein, H.L., &Youman, C.E. (1996). Role-based access con-trol models. IEEE Computer, 29(2), 38-47.

Sim, P. (2002). Access control requirements for a

medical practice and hospital environmentand a secure access control architecture.Sydney, Australia: Macquarie University.

Simon, R., & Zurko, M.E. (1997). Separation ofduty in role-based environments. In Pro-ceedings of the 10th Computer SecurityFoundations Workshop (CSFW ’97), (pp.183). IEEE Computer Society.

Varadharajan, V. (2002). Distributed authoriza-tion: Principles and practice. In Codingtheory and cryptology, lecture notes series,Institute for Mathematical Sciences, Na-tional University of Singapore. SingaporeUniversity Press.

Varadharajan, V., & Allen, P. (1996). Joint actionbased authorization schemes. ACM Oper-ating Systems Review Journal.

Varadharajan, V., Allen, P., & Black, S. (1991).An analysis of the proxy problem in distrib-uted systems. In Paper Presented at theIEEE Symposium on Security and Privacy,Oakland, California, May 20-22.

Varadharajan, V., Crall, C., & Pato, J. (1998).Authorization in enterprise-wide distributedsystem: A practical design and application.In Proceedings of the 14th Annual Com-puter Security Applications Conference.

Yagüe, M.I., & Troya, J.M. (2002). A semanticapproach for access control in Web Services.In Paper Presented at the Euroweb 2002Conference: The Web and the GRID: FromE-Science to E-Business, Oxford, UK.

Sarath Indrakanti received his bachelor’s of applied science (major in computing) from theUniversity of Western Sydney, Australia in 2001. He is currently a doctoral candidate in theDepartment of Computing at Macquarie University, Australia. His area of research is in thecontext of security for Web Services. In particular, his work focuses on providing an authorizationframework for Web Services. His research work is sponsored by the Australian Research Counciland Microsoft Pty. Australia.

Vijay Varadharajan received his BS in electronic engineering from Sussex University, UK, in1981 and his PhD in computer and communication security in the UK in 1984, which wassponsored by BT Research Labs. He is the Microsoft chair and professor of computing at theMacquarie University and the director of information and networked systems security research.He is also the technical board director of computer science, Australian Computer Society. Hehas been a member of the board of advisors in the Trusted Computing Platform Association(TCPA) and is on the Microsoft Trustworthy Computing Academic Advisory Board (TCAAB).He was responsible for worldwide security research at corporate Hewlett-Packard Labs based



in Europe at HP Labs, UK. Prior to HP, he was a research manager at British Telecom ResearchLabs, UK. He is on the editorial boards of several international journals, including the ACMTransactions on Information Systems Security and the International Journal of Information Security,Springer Verlag. His current areas of research interest include security in high speed networks,security for large distributed systems, security policies and management in distributedapplications, Internet security, secure electronic commerce and payment models, secure mobileagents, wireless security, security models and architectures, and security protocols.

Michael Hitchens received his bachelor’s of math. from Newcastle University, Australia, in1986 and his PhD in computer science from the same university in 1991. He is a senior lecturerin the Department of Computing at Macquarie University, Australia. He has also worked at theuniversities of Sydney and Western Sydney. His current areas of research interest include securityfor large distributed systems, models and languages for access control, security for wirelessnetworks, security for distributed file systems, authorization management, and security protocols.

authorization service for web services and its implementation

Documents