Abstract-- In the era of distributed computing and multi-user environment, federated organizations need to collaborate and access each other’s resources. In order to access resources user must be authenticated seamlessly and authorized to perform access request. Existing centralized solution such as Single Sign On suffers with single point of failure. In our research, we propose a distributed solution by making access control models, existing in different organizations, interoperable. We show how decentralized and distributed yet federated organizations with heterogeneous access control models can share valuable resources/services in secure, reliable and efficient manner with no or minimal changes to their existing infrastructure. Our solution converts the existing policies of collaborating organization into ABAC model by a model transformation utility. Any cross organization transactions are handled by our plug-in based system without requiring any changes in the current authentication and authorization workflow of both collaborating parties.

Keywords: Interoperability, Access Control, Attribute Bases Access Control, Collaborating Organization.

I. INTRODUCTION In order to protect valuable resources every organization needs some access control mechanism that meets their requirements of managing their resources, efficiently and effectively. Each access control model accomplishes this goal in a different way. An access control deployment usually includes its three logical components; an access control model, policies and mechanism to enforce them. Some very well-known access control model includes Mandatory Access Control / Discretionary Access Control (employed in most military organizations), Role-based Access control (employed in commercial organizations such as banks that have large number of users and resources) and purpose based access control [2]. These access control models are configured to organization’s security framework [3] [4]. Federated organizations merge or collaborate to provide services to their common users who want successful completion of their tasks in secure way with minimal effort.Each collaborating organization

needs to access its partner organization resources and vice versa. Therefore, users of remote organization should be authenticated and authorized to access the resources of partner organization. One possibility is to manage multiple identities for a user in both organizations, which is not only difficult to manage but is also troublesome for user to remember its multiple credentials. In order to make seamless authentication certain centralized authentication systems such as Single Sign On [1] exist, which have their own limitations including single point of failure. Federated organizations also want their existing infrastructure to be unchanged or minimal acceptable changes that does not affect their internal flows. In order to provide access to each other’s resources, we propose distributed solution based on model transformation for collaborating organizations. Both organizations might have used heterogeneous model for implementing their access control requirements. Heterogeneity can be removed by using the same model at both sides which is not feasible for any organization to rewrite all its policies that might be in thousand in number. Our objective is to provide solution that requires no or minimal changes to existing infrastructure. Our proposed plugin based solution include Model Transformation Utility which transform existing model into Attribute Based Access Control Model using XACML These policies are applied to remote request to obtain access over local resources whereas legacy policies are applied to local requests. Rest of the paper is organized as follows: Section II describes background technologies, Section III discusses related work in the specified field. Proposed system design and architecture is presented in Section IV. Section V describes implementation details and evaluation and in the last section we conclude our research work.

II. BACKGROUND

A. XACML: Extensible Access Control Markup Language (XACML), [5] a policy language, is an OASIS [6]

Interoperability among Access Control Models

Khalid Hafeez, Qasim Rajpoot, Awais Shibli School of Electrical Engineering and Computer Science

National University of Sciences & Technology Islamabad, Pakistan

{09msitkhafeez, qasim.rajpoot, awais.shibli}@seecs.edu.pk

978-1-4673-2252-2/12/$31.00 ©2012 IEEE

standard. The policy and the decisions that are made on requests by applying policies and the end response are encoded in XML. General access control requirements are met using policy language and it can be further enhanced to define new data types, function and policy/rule combining algorithms. XACML engine can be queried by sending request and corresponding response can be one of the four values: Permit, Deny, Intermediate (decision can’t be made due to some error and misinformation) and Not Applicable (said service can’t answer the request). The main components of XACML engine include policy, policy set, Targets and Rule combining algorithms. XACML typical implementation includes Policy enforcement Point (PEP), to which request is made. It prepares the request in the context of resource, action need to be taken on that resource, attributes of request and other information (such as environment attributes) related to requester and resource in question, and forwards the prepared request to Policy Decision Point (PDP). PDP finds applicable policies, applies them and returns the appropriate response back to PEP. We choose XACML because it is standard, generic, allows distributed policies and really powerful (can be enhanced to be used with other standards like SAML & LDAP).

B. SAML Security Assertion Markup Language (SAML) is also an OASIS standard XML based framework used to communicate user’s attribute information for authentication purpose. SAML assertions are made for attributes, identity and user entitlement in federated organization. SAML is flexible enough to extend and customize as needed. We use it in our proposed system, to authenticate partner organization’s user accessing service at service provider’s end.

C. ABAC Attribute Based Access Control (ABAC) uses attribute information associated with subject and resources in question. A typical implementation of ABAC includes subject which demands access, resource on which access is required, action and the environment (the context in which request is made). In our research we use ABAC as intermediate model among the access control models of the organizations that are to be made interoperable. ABAC is best suitable in our case because almost every model can be transformed into ABAC.

III. RELATED WORK Jian et al [7] compare different access control models and the Active Security Management and Distributed Security Management in terms of scalability, flexibility, granularity, ease of use and ease of management. They consider distributed environment as secure group communication and discuss two basic architectures; a layered architecture and integrated architecture. Layered architectures are more robust while integrated architectures are more complex however both are not enough. A distributed attribute based access control model introduced assigning permission on the basis of privacy preservation scheme and level of trust. Markus et al [8] presented XACML as a distributed framework and also discussed how authorization can be deployed in decentralized systems, They discuss how XACML can effectively solve problem in existing authentication and authorization system such as Shiboleth[9] , Cardea and privilege and policy management in PRIMA system. Secondly, authors suggested certain points that need to be considered while implementing XACML for addressing challenges of distributed authorization. The points include: creation and management of access control policies, encoding of privilege management policies in XACML, locating the correct PDP, XACML request preparation and request context management. In the end authors conclude that XACML is an excellent choice for distributed authorization because of its ability to work with decentralized polices. Team Based Access Control (TMAC) is introduced in [10] where team itself refer to a group of collaborating users acting in various roles and provides a way to assign permissions to the team. Task Based Access Control (TBAC) [11] was introduced to synchronize access permissions with ongoing tasks and workflow instances spanning across organizations. Alex et al [12] proposed a scheme called XEngine which efficiently evaluates XACML policies as compared to Sun PDP. In order to improve processing efficiency they uses tree structure policies and claim that XEngine performance is quite good whether number of rules in polices is small or large.

IV. SYSTEM DESIGN AND ARCHITECTURE

Our proposed system works as a plug-in to existing system. Figure-1 shows the high level view of the system with multiple modules Identity Management System (IDMS), Model Transformation Utility

(MTU) and transformed policies in ABAC model working together to provide a workable solution that makes heterogeneous access control models of collaborating organizations, interoperable.

Figure 1. System Overview

In order to understand the entire working of each module let us consider two different entities say a software company and a university department works in collaboration for certain research projects.

Figure 2. IDMS to IDMS Interaction

Software company experts may offer courses for university students and also may send their trainees

to enroll in university offered courses to enhance their knowledge in new research areas. They need to access each other resources to perform certain operations. Both have implemented an access control model that best suits their interest. Suppose university follows RBAC model and Software Company uses ACL. Each one shares their organizational hierarchy and agrees upon some membership level mapping between roles and ACL groups as shown in table below:

TABLE I. ROLE VS GROUP MAPPING

Software Company University Department Trainee Student Associate SE Teaching Assistant (TA) Software Engineer (SE) Lecturer Senior SE Assistant Professor Advisory SE Associate Professor Senior Advisory SE Professor When a Software Company (Identity provider) user wants to access a resource at university (Service provider), it sends request to IDMS.

A. IDMS IDMS uses SAML assertion for authenticating a remote user from its identity provider. When a request from remote user (Software Company) is received, university IDMS forward this request (SAML authentication request) to IDMS of Software Company which evaluates it and sends response in the form of SAML assertion. Figure-2 shows how SAML authentication request is validated and the response is conveyed back that includes other required attributes such as membership level. We assume SAML communication is secure and the encrypted keys are already shared hence the data is encrypted before being transferred. IDMS on successful authentication stores user attributes in repository and forward access request to PEP for authorization.

B. Policy evaluation PEP using context handler prepares request in native format (XACML request) and forwards to PDP for evaluation. PDP, by looking at request attributes coming from remote end, consults mapping entries for membership level and applies policies obtained from ABAC policies store. ABAC policy store contains the policies which were previously converted by Model Transformation Utility from legacy model (RBAC) to ABAC.

Figure 3. ABAC Plugin Architecture

C. Model Transformation Utility MTU reads the policies form legacy repository and transforms it to ABAC model, using XACML and stores in ABAC policy store. These policies are applied to remote request to obtain access over local resources. When our proposed system is plugged-in to existing system it will read its entire legacy policy repository and generate ABAC policies implemented in XACML and store it into new repository. PDP while applying policy verify whether the given policy is up-to-date by matching its version with corresponding policy in legacy repository. If the given policy is out-dated it will first ask MTU to update it before applying it to given request.

V. IMPLEMENTATION In order to understand the functionality of MTU we take university RBAC Model and show how our MTU converts RBAC model into ABAC by first extracting attributes to build system vocabulary and extracting rules later. In the last step MTU generates policies in XACML based on ABAC rules and attributes vocabulary.

A. Attribute Extraction ABAC model is based on attributes. Figures below show some resources (object) and operations in our existing RBAC in a typical university setup. RBAC

operations and resources are mapped into ABAC actions and resources respectively. While RBAC users and their assigned roles are mapped into ABAC subject attribute.

TABLE II. OPERATIONS

Id Name 1 Add 2 Edit 3 Delete 4 View 5 Mark 6 Publish 7 Submit 8 Download

urn:lms:plugin:names:action:id http://www.w3.org/2001/XMLSchema#string urn:lms:plugin:names:action:id:Add urn:lms:plugin:names:action:id:Edit urn:lms:plugin:names:action:id:Delete urn:lms:plugin:names:action:id:View urn:lms:plugin:names:action:id:Mark urn:lms:plugin:names:action:id:Publish urn:lms:plugin:names:action:id:Submit urn:lms:plugin:names:action:id:Download

Figure 4. Operations

urn:lms:plugin:names:resource:id: http://www.w3.org/2001/XMLSchema#string urn:lms:plugin:names:resource:id:FrontScreen urn:lms:plugin:names:resource:id:LectureNotes urn:lms:plugin:names:resource:id:Assignment urn:lms:plugin:names:resource:id:Course

Figure 5. Resources

urn:lms:plugin:names:subject:roles: http://www.w3.org/2001/XMLSchema#string urn:--,:plugin:names:subject:roles:role:id:Teacher urn:--.:plugin:names:subject:roles:role:id:Student urn:.----:subject:roles:role:id:TeachingAssistant

Figure 6. Roles

B. Rules Extraction After successful generation of system vocabulary (ABAC attributes), MTU extract rules for ABAC policies. Permissions (privileges) of performing actions on a certain resource and which role has what permissions are shown in tables:

TABLE III. PERMISSIONS

Id Resource Id Operation Id 1 1 4 2,…,6 2 1,2,3,4,8 7,…,14 3 1,2,3,4,5,6,7,8 15,…,18 4 1,2,3,4

TABLE IV. ROLES & ASSOCIATED PERMISSIONS

Id Role Id Permission Id 1,…17 1 1,…17 18,…22 2 1,5,6,13,14 23,…26 3 2,3,11,12 ABAC Rules: User having teacher role have all permissions User having student role can view front screen. User having student role can view lecture notes.

Figure 7. Policy (Student Role)

<Policy PolicyId="Permission:for:Student" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule- combining-algorithm:ordered-permit-overrides"> <Target> <Subjects><Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Student </AttributeValue> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject- id" DataType="http://www.w3.org/2001/XMLSchema#string"/> </SubjectMatch> </Subject></Subjects> <Resources><AnyResource/></Resources> <Actions><AnyAction/></Actions> </Target> <Rule RuleId="Permission:to:Download:Assignment" Effect="Permit"> <Target> <Subjects> <AnySubject/> </Subjects> <Resources><Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">LectureNotes </AttributeValue> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource- id" DataType="http://www.w3.org/2001/XMLSchema#string"/> </ResourceMatch> </Resource></Resources> <Actions><Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"> View </AttributeValue> <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/> </ActionMatch> </Action></Actions> </Target> </Rule> <Rule RuleId="FinalRule" Effect="Deny"/> </Policy>

User having student role can submit assignment. User having student role can download assignment. User having teaching assistant role can add lecture notes. User having teaching assistant role can publish assignment. User having teaching assistant role can mark assignment. User having teaching assistant role can edit lecture notes

C. Policy Generation The last and the most important task MTU does, is to generate ABAC policies in XACML. A permission policy is generated for every role defined in RBAC

model. Each permission policy contains a set of rules, where each rule corresponds to ABAC rule generated by rule generation module. Role policy with set of rules, including default deny rule, is given above:

D. Authorization Cycle In the previous section we transformed RBAC model into ABAC model, generated ABAC policies in XACML and stored them in repositories. In this section we will show how request from remote user (Software Company) will be processed and access granted or denied. Khalid (Trainee), user from Software Company wishes to view lecture notes, sends request to university learning management system. Request in XACML received at university IDMS system as shown below:

Figure 8. User request

a. Authentication Request/Response IDMS upon looking at the request coming from remote user, prepares SAML authentication request and forwards it to identity provider’s (software company) IDMS. User is authenticated in its identity

provider’s IDMS and requested attributes are returned back to service provider (University). SAML authentication request for user (Khalid) and response with requested attribute (group) as shown below:

Figure 9. SAML Authentication Query

<Request> <Subject>

<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"> <AttributeValue>khalid</AttributeValue> </Attribute>

</Subject> <Resource>

<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"> <AttributeValue> Lecture Notes </AttributeValue> </Attribute>

</Resource> <Action>

- <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"> <AttributeValue>View</AttributeValue> </Attribute

</Action> </Request>

<samlp:AuthnQuery xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="AuthnQuery1"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> http://rbac.com/IdmsJavaRelyingParty</saml:Issuer> <saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> <saml:NameID>khalid</saml:NameID> </saml:Subject> <samlp:RequestedAuthnContext> <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </samlp:RequestedAuthnContext> </samlp:AuthnQuery>

Figure 10. SAML Authentication Query Response

Figure 11. SAML Attribute Query

Figure 12. SAML Attribute Query Response

b. Request (to PEP) After successful authentication IDMS consults with mapping entries, prepares request by replacing Trainee with Student and forwards it to PEP.PEP

prepares request in native format and forwards to PDP that process request on ABAC policies written in XACML. Request to PEP is shown below:

Figure 13. Request to PEP

<Request > <Subject>

<Attribute AttributeId="&subject:subject-role"DataType="&xml;string"> <AttributeValue>Student</AttributeValue>

</Attribute> </Subject> <Resource>

<Attribute AttributeId="&resource:resource-name" DataType="&xml;string"> <AttributeValue>Lecture Note</AttributeValue>

</Attribute> </Resource> <Action>

<Attribute AttributeId="&action:action-name" DataType="&xml;string "> <AttributeValue>view</AttributeValue>

</Attribute> </Action>

</Request>

<samlp:AttributeQuery xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="AttrQuery2" > <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> http://rbac.com/IdmsJavaRelyingParty</saml:Issuer> <saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> <saml:NameID>khalid</saml:NameID> </saml:Subject> <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="group"/> </samlp:AttributeQuery>

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" InResponseTo="AuthnQuery1"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

http://acl.com/IdmsJavaRelyingParty</saml:Issuer> <samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </samlp:Status> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="Assertion12345789" > <saml:Issuer>http://acl.com/MyJavaAuthnService</saml:Issuer> <saml:Subject> <saml:NameID>khalid</saml:NameID></saml:Subject> <saml:AuthnStatement> <saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc: SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef> </saml:AuthnContext></saml:AuthnStatement> </saml:Assertion> </samlp:Response>

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" InResponseTo="AttrQuery2"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> http://acl.com/IdmsJavaRelyingParty</saml:Issuer> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="Assertion12345789"> <saml:Issuer>http://acl.com/MyJavaAttributeService</saml:Issuer> <saml:Subject><saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">

khalid</saml:NameID> </saml:Subject> <saml:AttributeStatement>

<saml:Attribute Name="group"><saml:AttributeValue> Trainee </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion> </samlp:Response>

c. Results

TABLE V. RESULTS

Sr. Request Expected Result Actual Result 1. User with teacher role wants to view Front Screen Permit Permit 2. User with student role wants to view Front Screen Permit Permit 3. User with student role wants to view Lecture Notes Permit Permit 4. User with student role wants to edit Lecture Notes Denied Denied 5. User with student role wants to download Lecture Notes Permit Permit 6. User with student role wants to submit Assignment Permit Permit 7. User with student role wants to Publish Assignment Denied Denied 8. User with teaching assistant role wants to add Lecture Notes Permit Permit 9. User with teaching assistant role wants to publish assignment Permit Permit 10. User with teaching assistant role wants to mark assignment Permit Permit 11. User with teaching assistant role wants to edit lecture notes Permit Permit

VI. CONCLUSION In our research we proposed a distributed solution for collaborating organization, to control access of their resources, by making access control model interoperable. MTU transforms the policies written in native access control model into ABAC policies implemented in XACML. We give a proof of concept by transforming RBAC policies to ABAC policies showing that how interoperability can be achieved. Our plug-in approach does not interfere with the internal workflow of both collaborating organizations. We are currently working on providing support to transform other access control model including ACL. The advantage of this solution is that we need to write MTU as a part of plugin for each new access control model without requiring any changes in the internal workflows of collaborating organizations.

VII. REFERENCES [1] “Single Sign On”, URL: http://www.authentication

world.com/Single-Sign-On-Authentication/,” [Last accessed 11-05-2012]

[2] N. Yang, H. Barringer, N. Zhang, “A Purpose-Based Access Control Model," The Third International Symposium on Information Assurance and Security, 2007.

[3] V.Hu, D. Ferraiolo, D.Kuhn, “Assessment of access control systems — NIST interagency report. Technical report,” National Institute of Standards and Technology, 2006.

[4] “A Survey of Access Control Models,” URL:http://csrc.nist.gov/news_events/privilege-management-workshop/PvM-Model-Survey-Aug26-2009.pdf, [Last accessed 11-05-2012].

[5] “Sun's XACML Implementation Programmer's Guide,” URL:http://sunxacml.sourceforge.net/guide.html, [Last accessed 11-05-2012].

[6] “OASIS- Advancing open standards for the information security”, URL: http://www.oasis-open.org/standards. [Last accessed 11-05-2012]

[7] J. Zhu, W.Smari, "Attribute Based Access Control and Security for Collaboration Environments," Aerospace and Electronics Conference, 2008.

[8] M. Lorch, S. Proctor, R. Lepro, D. Kafura, S. Shah, “First Experiences Using XACML for Access Control in Distributed Systems,” XMLSEC 03 Proceeding of ACM workshop on XML Security,2003.

[9] “Shibboleth- A project of the Internet2 Middleware Initiative,” URL:http://shibboleth.internet2.edu, [Last accessed 11-05-2012].

[10] R. K. Thomas. Team-based access control (TMAC): a primitive for applying role-based access controls in collaborative environments. RBAC ’97: Proceedings of the second ACM workshop on Role-based access control.

[11] R. K. Thomas and R. S. Sandhu, “Task-based authorization controls (TBAC): A family of models for active and enterprise-oriented authorization management.,” Proceeding of the IFIP TC11 WG11.3 Eleventh International Conference on Database Security,1997.

[12] A. Liu, F. Chen, J. Hwang,T. Xie,” Xengine: a fast and scalable XACML policy evaluation engine,” SIGMETRICS '08 Proceedings ACM SIGMETRICS international conference on Measurement and modeling of computer systems, 2008.