A Privacy, Trust and Policy based Authorization ... - CiteSeerX

INTERNATIONAL JOURNAL OF COMPUTER SCIENCE VOLUME 2 NUMBER 2 2007 ISSN 1306-4428

A Privacy, Trust and Policy based Authorization Framework for Services in Distributed Environments Sarbjeet Singh, and Seema Bawa

decomposed into a collection of network connected components/services and applications are composed dynamically from the deployed and available components in the network. Such architecture is called service oriented architecture. A large scale service oriented computing environment like grid couples thousands of computers, storage systems, networks, scientific instruments and other devices distributed over heterogeneous wide area networks [1], [2]. Such a system also presents unique security problems that are not addressed by traditional client-server/distributed computing environments. In addition to providing basic security requirements like authentication, authorization, confidentiality and integrity, the security infrastructure for grid and web must also be able to support more advanced security features like dynamic delegation of access rights, single sign-on/sign-off, dynamic establishment of trust relationships among multiple domains, privacy and policy related security issues in federated environments etc [3]-[9]. There are several factors that make security hard e.g. user population and resource pool is large and dynamic, resources have different authentication and authorization requirements, computations span over multiple domains, users have different roles/privileges in different domains etc [5], [10], [11]. All these factors make authorization a big and challenging issue. Authorization, in simple terms, deals with issues like who can access which resources/services under which conditions. There are many authorization mechanisms e.g. role based authorization, rule based authorization, and identity based authorization etc. But these authorization mechanisms alone cannot satisfy the access requirements of distributed services as the access depends on many other factors like privacy requirements of the requester, authentication requirements of the service, trust relationship with the requester, authorization and management policies among participating parties etc. Authorization in a distributed environment should be determined as a result of evaluating the request of an authenticated user against various policies like privacy policy, trust policy, authorization policy etc. Many authorization mechanisms for large scale distributed systems like grid and web ignore one of the components from privacy, trust and policy [12]-[15]. We emphasize that these are vital components and must be integrated into the access control framework of security architecture to make it more effective and useful. In this paper we propose a privacy, trust and policy based authorization framework for distributed services like grid and web services. For implementation, we are making use of existing and emerging web and grid services standards and

Abstract—Distributed Environments are touching new heights, becoming more useful, popular and more complex with the emergence of service oriented architecture and computing technologies like peer-to-peer, autonomic, pervasive and grid etc. These technologies aim to enable large scale resource sharing. Security is a big and challenging issue in these environments as it involves the federation of multiple heterogeneous, geographically distributed autonomous administrative domains. The dynamic and multi- institutional nature of service oriented environments like grid and web introduces several challenging security issues that require new technical approaches. This paper proposes a privacy, trust and policy based authorization framework for grid and web services, but, in fact can be amended for any distributed, service oriented computing environment as most of the elements defined in the framework are general and adaptable in other computing environments. The framework is intended to provide a simple, powerful, flexible and scalable authorization infrastructure for services exposed in a large scale distributed environment. The paper also discusses a prototype implementation of the proposed framework. For implementation, we are making use of web services security specifications supported by WSE 3.0. Sample implementation has shown that the architecture is capable of meeting the identified security requirements and the approach is workable.

Keywords—Authorization Framework, Grid computing, Peerto-peer, Pervasive and Autonomic computing, Privacy, Trust and Policy based authorization, Web and Grid Services. I. INTRODUCTION AND BACKGROUND

A

distributed system is a set of interconnected, autonomous computers that cooperatively solve large, single problem by facilitating parallel execution of separate but related tasks. Today, the increasingly large, complex and resource intensive applications are being developed both in research institutions and in industry. It is common observation that organizational resources alone are failing to meet the demand of these applications. Fortunately, improvements in wide area networking make it possible to aggregate resources distributed across various collaborating institutions and we are entering into next generation of distributed computing with technologies like peer-to-peer computing, pervasive computing, autonomic computing grid computing etc. These technologies support software system that can be Manuscript received January 01, 2007. Sarbjeet Singh is with Department of Computer Science and Engineering, University Institute of Engineering and Technology, Panjab University, Chandigarh 160014, India (phone: 091-09815951674; e-mail: [email protected]). Seema Bawa is with Department of Computer Science and Engineering, Thapar Institute of Engineering and Technology, Patiala, Punjab 147004, India (e-mail: [email protected]).

IJCS VOLUME 2 NUMBER 2 2007 ISSN 1306-4428

85

© 2007 WASET.ORG


technologies [5], [16], [17]. The framework proposed is simple, powerful and scalable. In the next section we will explain different elements of the framework. In subsequent sections, we will discuss authentication (Section III), trust (Section IV), privacy (Section V) and authorization (Section VI) models and then we will talk about implementation details (Section VII) and future plans (Section VIII).

and OP refers to any Other Policy Service Policy and Domain Policy, both are subsets of Policy. i.e. SP ⊆ PO and DP ⊆ PO. Domain Set (DS): Domain Set is simply the set of Domains. i.e. DS = (DO1, DO2, …. , DOn). Domain Set Policy (DSP): Domain Set Policy refers to the Policy that applies to Domain Set. DSP ⊆ PO. Filter: The rights/privileges of a Subject are different in different Domains. Filter is a component through which rights/privileges of a Subject are filtered for a particular Domain. There are two types of filters (filter-in and filter-out). These are explained in section VII. MAP (MAP): is an operation that maps/transforms Subject of one administrative domain to Subject in another administrative domain. E.g. SUi (DOk) Æ mapÆ SUj (DOl) means that Subject SUi of Domain DOk has been mapped to Subject SUj in Domain DOl. Security Elements Set (SET): refers to the set SET(SU,SR,R,SP,DO,DP,AC,PO,DS,DSP,MAP) i.e. the set of all elements described above. Distributed Environment (DE): refers to the environment in which different Domain Sets interact. In a typical Distributed Environment, the elements described above interact in a complex manner, which we will discuss in the later sections.

II. ELEMENTS OF THE FRAMEWORK An authorization system can be defined as a system that grants specific type of access to specific requesters based on their authentication, what services/resources they are accessing, current state of the system and their conformation to established policies. It is a detailed description of all aspects of a system that relate to access of services/resources by requesters. In order to understand the architecture well, we have identified and defined the following elements: Subject (SU): Subject is an entity that wants to access services/resources. It can be a user, a service or any other entity on behalf of user/service. Service (SR): Service is a piece of software that provides some functionality and can be accessed by Subjects or other Services. Services are exposed in the environment and are found by Subjects. Resource (R): Resource is an object that is accessed by Subjects. It can be a CPU, a storage device, software, data, scientific instrument or any other peripheral. Subjects access Resources through Services. In other words, a Resource is a Service. Service Policy (SP): Service Policy refers to the set of rules/requirements associated with the Service. A Subject must conform to Service Policy in order to Access that Service. Domain (DO): Domain refers to the set of Subjects and Services under a unique Domain Policy (DP). DO = (SU, SR, DP). The Services in a Domain are provided by Service Providers and they may belong to same or different physical organizations/institutions. Domain Policy (DP): Domain Policy refers to the set of rules/regulations/requirements of a Domain to which an entity must conform to in order to be in that Domain. Access (AC): Access is an operation that a Subject performs on Service/Resource. The access is provided based on conformance to Service Policy (SP) that is associated with that Service/Resource. Access operation is represented as AC (SU, SR, SP) i.e. Subject (SU) can Access (AC) Service (SR) if it conforms to Service’s Policy (SP). Policy (PO): Policy is a set of rules/requirements that can be associated with a Subject/Service/Domain. It can be represented as PO = (AP, AuP, TP, PP, MP, OP) where AP is Authentication Policy AuP is Authorization Policy TP is Trust Policy PP is Privacy Policy MP is Management Policy


Fig. 1 Schematic showing Distributed Environment consisting of two Domains along with other elements of the Framework

Fig. 1 shows a Distributed Environment consisting of two Domains (DO1 and DO2) along with other elements of the framework. In the diagram Squares represent Subjects, Diamonds represent Resources, Triangles represent Policies, Rectangles represent Filters and Ellipses represent Domains.

86

© 2007 WASET.ORG


As shown in Fig. 1, Subject’s access request for Service SR first passes through Filter-out component at the source Domain and then through Filter-in component at the target Domain. During this passage, Subject’s access rights are filtered for the target Domain. The purpose and working of Filters is explained in Section VII. At the target Domain, the proposed Authorization Framework checks Subject’s conformance to Service Policy. If Subject conforms to Service Policy then mapping operation (MAP) is performed to provide the Subject an identity that is local to that Domain. The mapped identity is then used by the Target Domain to provide access to the requested Service/Resource. The mapping operation is optional. If the access of a Service/Resource does not require local identity then it can be omitted. If Subject does not conform to Service Policy, the access is denied. Determining whether a Subject conforms to Service Policy is a complex task and is performed by authorization engine which must take into account different types of policies like Trust Policies, Privacy Policies, Authorization Policies, Authentication Policies etc. to grant/deny access to Services/Resources. Fig. 1 also shows Policy database to store different types of policies. These Policies exist in a complex manner among Subjects and Services of different Domains. To address authorization requirements for this type of environment, the models defined in Sections III – VI are proposed. These models can be used to provide privacy, trust and policy based access to Services/Resources. The remaining discussion is concerned with addressing authorization requirements of distributed services like grid and web services. The elements described in this section are general and can be considered common with other computing technologies like peer-to-peer, pervasive and autonomic computing. The Security Element Set (SET) can be extended easily to include the unique features of these computing technologies but in this paper we have focused specifically on grid and web services.

where they are to be stored, how they are to be retrieved according to the requirements of the Service, how they are to be delivered to the Service etc. As a solution to this problem, we propose the Domain to have a Service to store, retrieve and maintain multiple security credentials of all of their Subjects. We will call this service as Credential Manager Service (CMS). CMS is responsible for managing multiple Subjects’ credentials and is provided by the Domain to which the Subject belongs. Subjects store all of their security credentials in CMS. To access a Service, Subject first discovers the security requirements of that Service. Then Subject checks the required security credentials in CMS. If the security credentials are present in CMS, he obtains them from CMS by authenticating himself to CMS. If the required credentials are not present in CMS, then Subject may obtain them from relevant certificate authority or other third party. These credentials are then used by Subject to access the Service. After this, the credentials are stored in CMS also for future use. Another problem, related to authentication, is of single signon and delegation. Distributed jobs may take a long time (days/months) to execute and their execution may also span across multiple Domains. For these types of jobs, authentication model must provide single sign-on/off and delegation facilities. Single sign-on and delegation features depend on the credentials used for authentication. E.g. these features can not be provided if the Subject is using username/password for authentication, but, can be easily provided, if the Subjects use X.509 certificates. In the prototype implementation, we have provided these features by creating proxy certificates [19]. We are also working on using SAML to provide single sign on and delegation features. Currently we want the Subjects to have X.509 certificate to use these features. Subjects are issued certificates by certificate authorities. Certificates bind Subject’s DN (Distinguished Name) to its public and private key. Public key is written in the certificate whereas private key remains with the Subject. In order for Subjects to prove their identity they must have i) Certificate ii) Private Key. Authentication process involves presenting the certificate and proving the possession of the private key. Private key is held by Subjects and is not disclosed to anyone under any circumstances. Proxy certificates enable us to implement non repudiation also. As the Subjects are digitally signing the certificates, they cannot deny from having send the access request, as signature is possible only through their private key. Delegation is also possible through proxy certificates. The delegated rights can be expressed in a policy language like XACML [20] and can be attached to proxy certificates through PCI (Policy Certificate Information) field [19]. It is also possible to support different delegation levels (e.g. impersonation, restricted delegation etc) using proxy certificate. This will effect the decision of Authorization Framework to grant/deny access to the requested Service/Resource. To implement Credential Manager Service, we are making use of WS-Security [21] and related specifications implemented by WSE 3.0. Using these specifications we are

III. AUTHENTICATION MODEL Authentication is a complex task in a type of Distributed Environment described above. There are several reasons for that. First, authentication requirements of different Services are different [18]. E.g. In Domain A, Service-1 may require username/password, Service-2 may require Kerberos ticket and Sevice-3 may require X.509 certificate to authenticate Subjects and so on. This is because Services in a Domain are provided by different Service Providers and they are free to implement any authentication mechanism of their choice to protect their Services/Resources. It is certainly neither possible nor good idea to force different Service Providers to use same kind of security credentials to authenticate Subjects. Though it may have advantages in implementing a more robust authentication system but then the very purpose of integrating heterogeneous environments is lost. Given this scenario, Subjects end up having multiple security credentials for accessing different Services from different Domains. The main problem that comes here is the management of multiple security credentials held by Subjects i.e. how and


87

© 2007 WASET.ORG


Service/Resource will behave in an expected manner despite the lack of ability to monitor or control the environment in which Service/Resource operate [24]. The trust status of a Service/Resource from a different Domain is hard to determine. Subjects generally have no idea whether the Service is compromised or is malicious [24], [25]. While enabling delegation also, determining trust relationship is essential [26]. Trust can take a complex form in Distributed Environment. E.g. Subjects of Domain A may trust Domain B and not Domain C, or, Subjects may trust Domain B for Service 1 but not for Service 2, etc. The main problem is how to establish and determine trust relationships of Subjects/Services of one domain with Subjects/Services of other domains. Domains need a trust enabled security infrastructure to handle trust related requirements and to provide trust based access to Services/ Resources. The trust of an entity with other entity is not a fixed value but can change dynamically depending on the behavior of the entity and context in the environment. Trust should be established from the viewpoint of both the parties. Requester’s trust with the service provider may be different from the service provider’s trust with the requester. There are two important types of trust: code trust and execution trust [24]. Execution trust exist from subject’s side to service provider’s side that service provider will correctly and faithfully allocate resources for the efficient execution of job with respect to established policies. Code trust exist from service provider’s side to subject’s side that subject will generate a legitimate request consisting of virus free code and will not produce malicious results and does not temper other results/information/code present at service provider’s end. There may be other types of trust also, e.g.: Direct Trust: is the trust that a subject holds on other service provider without any intermediate service provider or entity. Indirect Trust: is the trust that a subject has on a service provider through some other service provider or entity. Full Trust: A Subject is said to have full trust on a service provider/Domain if it trust on all the services provided by that service provider/Domain. Partial Trust: A Subject is said to have partial trust on a service provider/Domain if it trust on some of the services provided by that service provider/Domain. Recommended Trust: is the trust of one entity on second entity that is recommended by other entities. Authentication Trust: is the trust of an entity on the authenticity of an identity certificate signed by a certificate authority. Privacy Trust: is the trust of an entity on the privacy features provided by other entity. Trust Model is a system that can be represented as TS = (EN, TR, OP). Where EN refers to different entities in a grid environment among which trust relationships exist. These entities can be Subjects, Services, Service Providers or Domains etc. TR is the set of trust relationships according to the types of trust discussed above. OP is the set of operators used to handle trust relationships. Trust Relationship can be represented as: TR = (SU1, DO1,

also guarantying the confidentiality and integrity of the messages exchanged. Credential Manager is a feature rich and flexible service for storing, retrieving, updating and managing multiple user credentials. Users can store their multiple security credentials (username/password, X.509 certificates, Kerberos Tickets etc) in CMS. Access to Credential Manager Service is either through X.509 Certificates or Username/password.

Fig. 2 Credential Manager Service

As shown in Fig. 2, if a Subject accesses CMS through username: password, then CMS will return either X.509 Certificate/Kerberos Ticket/Proxy credentials, as demanded by the Subject. Subjects then provide these credentials to Services to access them. Proxy credentials enable Subjects to use single sign-on and delegation features. Option will be given by the user whether he wants to store his long term permanent security credentials (e.g. private key) or just the proxy certificates / credentials. If Private key is not stored then access to Credential Manager Service is provided through username/password. If Private Key is stored in Credential Manage Service then access is through X.509 certificate. The second option is preferred if the user has many security credentials (with many private keys). The CMS can send the required proxy credentials to the Subject as well as to the service to which Subject wants them to send so that the service can act on behalf of the Subject. But this feature can be dangerous also if CMS is compromised. So Subjects are generally advised to disable this feature. Only when the consequences of CMS being compromised are not very dangerous, this feature can be enabled. The protection of CMS itself is also very important for the success of proposed authentication model. CMS make use of WS-Trust [22] and WS-SecureConversation [23] specifications supported by WSE 3.0 to provide these features. Credentials obtained from CMS are used by Subjects to authenticate themselves to Domains. If the Resources/Services of a Domain require local identity then Domain may map (if Subject conforms to Service Policy SP) the authenticated identity to a local account using MAP operation. Access to Resources/Services is then provided using this local account. IV. TRUST MODEL Trust is generally defined as having confidence that a


88

© 2007 WASET.ORG


TR, SR1, DO2, t, tv) i.e. Subject SU1 belonging to Domain DO1 trust Service SR1 belonging to Domain DO2 with trust value tv with respect to trust type TR for time duration t. In order to establish and evaluate trust, we want every Domain to implement a Trust Model integrated with the Authorization Framework. The Trust Model can be used to provide trust based access to Services/Resources. The Trust model that we propose is able to capture various types of trust and also provide mechanism for trust evaluation, recommendations and updation of trust. Fig. 3 shows a high level view of the trust model used in the proposed Authorization Framework. The Trust Model has been implemented as a Trust Manager Service.

expressed in XACML [20]. Trust Model and its integration with Authorization Framework are explained in Section VI. V. PRIVACY MODEL Privacy issues are generally ignored in many security architectures because they make the design more complicated. But, to gain wide acceptance, it is necessary to address these issues by establishing a privacy model and incorporating that model into the Authorization Framework [27]-[29]. Trust of a Domain with other Domains plays an important role in addressing privacy issues of Subjects with Subjects/Services of other Domains. The main problem is how a Subject can be sure that other Domain is providing privacy based access to his private information that he has sent to that Domain. If a Service is exposing Subject’s personal/private information then access to that Service should be in accordance with privacy policies established with that Subject. To implement privacy based access, a variable, say, PI (Privacy Index) can be attached to the information (that is being sent by Subjects to Service providers) to indicate the privacy level of information. Following values of PI can be considered: PI=0: No Privacy (information can be used anyway) PI=1: Partial Privacy (information can be used with permission only) PI=2: Time Limited Privacy (information can be used with permission but for a limited time period) PI=3: Full Privacy (can not be used under any circumstances) The trust of the Subject with the Domain and Service Provider plays an important role while marking the information with PI. In case of full trust, information can be marked with lower values of PI but in case of partial or unknown trust, higher PI values can be considered. We have identified the following privacy policy elements to implement the privacy model: Subjects: They provide their private/personal information which is necessary to access Services/Resources. This information is marked by Privacy Index Information: can be either private information or public information. This information is marked by PI according to its sensitivity. Purpose: tells why the private/public information is required by Service/Resource provider. It also tells how the collected information will be used. Actions: tells what operations can be performed on the collected information. Conditions: These are privacy statements/policies that describe conditions to be satisfied before access in granted. Obligations: are simply activities that must be performed by Service Providers, after access, according to privacy policies established. A privacy relationship can be represented as PR = (SU, IN, PU, ACT, CO, OB) i.e. Subject SU’s information IN can be used for purpose PU only if conditions CO are satisfied and only those actions as described by ACT can be performed. After access, obligations OB will also be performed.

Fig. 3 Trust Model Architecture for Trust based Access

As shown in Fig. 3, access request coming from Subject, through Authorization Engine (explained in Section VI), is first intercepted by Trust Evaluator component. Trust Evaluator is responsible for evaluating trust based on established trust relationships and providing trust evaluation result to Authorization Engine. To evaluate trust, Trust Evaluator makes use of Trust Inference Engine. As an example, Suppose Subject SU-1 from Domain A wants to access Service SR-1 from Domain B. Let s and f denote the success and failure evidences experienced by SU-1 about SR1. Then tv can be calculated as: tv = s / ( s + f ) We are making use of this equation to manage trust relationships between different entities. This equation plays an important role in evaluating trust. In case of full trust, f can be set to 0, in case of partial trust, s and f take different values depending on the level of trust. In case of no trust, s can be set to 0. A history of these values is maintained by every Domain. Trust Inference Engine calculates tv values for different types of trust. These results are passed to trust evaluator to prepare final result. Trust Evaluator is also responsible for updation of Trust among entities. Trust is updated with every interaction that takes place between a Subject and a Service. Trust Policy base fetches established trust relationships and trust management rules from policy database and provide these to trust evaluator to evaluate trust. Trust policies have been


89

© 2007 WASET.ORG


and he can change them dynamically. These policies can be authentication policies, trust policies, privacy policies or any other security policy based upon which access to Resource/Service is to be provided. In short, the authorization model must be able to support multiple security policies and need to have the flexibility to support dynamic changes in security policies [30]-[33]. In order to provide trust, privacy and policy based authorization; we have implemented the Authorization Framework shown in Fig. 5. The Authorization Framework makes use of trust and privacy models discussed in Sections IV and V. The proposed framework implements SAML and is based on XACML authorization model [20]. Fig. 5 shows various components of the model and also shows how the privacy and trust models fit into the framework.

Fig. 4 shows an interaction illustrating how information can be protected and full privacy (PI=3) is maintained. Consider that a Subject SU wants to access Service SR-1 provided by Domain A, but, for this, SR-1 requires accessing Service SR-2 from Domain B on SU’s behalf with SU’s private information. Now Subject SU may not want to disclose his private information to SR-1 (say, SU does not trust SR-1 for this information), but only to SR-2. So Subject may choose to use full privacy (PI=3) and will send the information with encryption and signature that can be decrypted and verified only by SR-2 of Domain B. This interaction is shown in Fig. 4.

Fig. 4 Interaction between a Subject and a Service showing how information is protected and full privacy (PI=3) is maintained

In Fig. 4, we have assumed that SU has already established a trust relationship with SR-2. Furthermore SU and SR-1 has also established a privacy relationship PR. SR-1 uses the information sent by SU according to this relationship. Before forwarding information to SR-2, SR-1 makes sure that this interaction occurs according to established privacy policy that describes for what purpose and under which condition the information can be used. In case of full trust with SR-1, SU may also decide to send this information to SR-2 via SR-1 without encryption. Implementation of Partial Privacy and Time Limited Privacy require alternative procedures and depend on the trust relationships present between participating entities. Thus the model enables us to specify privacy relationships between different entities beforehand i.e. what information can be disclosed to which party, for what purpose, for which actions, and under which conditions, along with obligations, if any. Privacy information is stored in the policy database using XACML. The integration of the Privacy Model with Authorization Framework is explained in the next section.

Fig. 5 Trust, Privacy and Policy based Authorization Framework

As shown in Fig. 5, authorization request from Subject SU is first intercepted by PEP (Policy Enforcement Point). PEP constructs an authorization decision query and passes it to authorization handler. The result of this query determines whether the access to Service/Resource is granted. The authorization decision query has details about the identity of the Subjects and the Service requested. Authorization Engine passes this information to PDP (Policy Decision Point). The Policy is retrieved by PDP from PRP (Policy Retrieval Point). If the policy information is not available at PRP, it may be retrieved from Policy Store. The Policies are written by administrator using PAP (Policy Administration Point). The Policy Store is capable of importing/exporting XACML. In XACML, Policy is constructed as a set of rules against the target defined as a triod (Subject, Resource, Action). PIP (Policy Information Point) is used by Authorization Engine to retrieve Resource, Subject and Environment related attributes. Trust Manager and Privacy Handler provide trust and privacy based access information to Authorization Engine. After getting this information, Authorization Engine prepares a final result and passes it to PEP. Based on the result, PEP then grants/denies access to the Service/Resource. Obligation Service, if any, is also executed by PEP.

VI. AUTHORIZATION MODEL Authorization in a Distributed Environment needs to be flexible and scalable to support multiple security policies [30]. Every Service Provider within a Domain has its own policies


90

© 2007 WASET.ORG


VII. CURRENT IMPLEMENTATION DETAILS

privacy policies established among Subjects and Services of different Domains. While accessing data services, Subjects mark their data with Privacy Index according to the sensitivity of information being sent. After agreement with Subjects the purposes, conditions, actions and obligations (as defined by Privacy Model) are stored in the database. Other access rules and management policies are also stored in the database using XACML. To access a Service, Subjects retrieve credentials from CMS and send these along with request and necessary parameters at the target Domain. Access to Service is provided based on conformance to these established privacy, trust and other policies. We have performed prototype implementation in .NET environment with WSE 3.0 support. Fig. 6 shows a high level view of the implementation. As shown in the figure, the Subject requiring access to Service first discovers the Service using discovery service (shown as step 1). The discovery service is implemented using UDDI specification. While discovering the Service, the Subject also finds the security requirements of the Service e.g. what type of security tokens the Service accepts, what are the encryption and signature requirements of the Service etc. After obtaining these requirements, the Subject contacts CMS (Credential Manager Service) to acquire the security tokens necessary to access the Service. This is done in step 2. After obtaining the security tokens, Subject accesses the Service with required parameters (step 3). But before the Subjects can access the Service, their rights/privileges are filtered for the Domain to which the Service belongs, because the access rights of a Subject are different in different Domains. A Subject can access Services/ Resources from any of the Domain present in the Environment but for this the Domain (to which the Subject belongs) has to register itself with the Domain who’s Services/Resources the Subject wants to access. With this condition the Services/ Resources of a Domain can be accessed by the Subjects/Services of registered Domains only. In this scenario, it becomes difficult for Service Providers to keep information of access rights of all of the Subjects of registered Domains. To address this problem, we require Service Providers to store information about access rights of registered Domains as a whole and not of individual Subjects of registered Domains. The Domains themselves will keep track of access rights of their Subjects. This enables us to implement more fine grained access control in the environment. To achieve this functionality, we have used Filter component. It filters the rights/privileges of a Subject for a particular Domain. There are two types of Filters: Filter-in and Filter-out. With Filterout component, the Subject leaves the Domain with access rights that his parent Domain grants to him. With Filter-in component, the Subject enters the organization with access rights that the target Domain grants to the parent Domain. In other words, the Subject gets the intersection of the rights that his parent Domain grants to him and the rights that target Domain grants to parent Domain. All the related information is exchanged as SOAP messages. In the prototype implementation we have used WSE 3.0 to construct SOAP messages. While constructing these

For implementation purpose, we are making use of web services security specifications supported by WSE 3.0. Today the world is witnessing the convergence of grid and web services. The two (grid and web) started far apart in specifications, technology and applications but now they are converging into a common set of standards and technologies. The security requirements of grid services overlap deeply with the security requirements of web services because grid services are stateful web services. Web services security specifications consisting of WS-Security, WS-Policy, WSTrust etc. have been submitted to OASIS by IBM, Microsoft and other leading organizations [17]. These specifications addresses security issues like how to associate security tokens with messages (WS-Security), how to express constraints and requirements of a web service (WS-Policy), how to request and issue security tokens to establish trust (WS-Trust and WSFederation), how to establish and share security contexts (WSSecureConversation) etc. We are making use of these specifications, supported by WSE 3.0, to implement Trust, Privacy and Authorization Models proposed in Sections IV, V and VI.

Fig. 6 Schematic showing high level view of the implementation

In the prototype implementation we have created 50 Domains with Subjects ranging from 10 to 30 in each Domain. All Domains have more than 5 service providers that provide different Services to other Domains. Different Subjects have been given different number and type of security credentials (X.509, Kerberos, username: password, Custom Security Token etc. which we have created using WSE 3.0 tools). These credentials are stored and managed by Subjects using CMS. Subject’s trust value and trust type with Services of different Domains is stored in the database. Trust relationship among different Domains is also stored in the database. These relationships are used by Authorization Engine while granting access to the Services/Resources. Database also contains


91

© 2007 WASET.ORG


[11] V. Welch, F. Siebenlist, I. Foster, J. Bresnahan, K. Czajkowski, J. Gawor, C. Kesselman, S. Meder, L. Pearlman, S. Tuecke, “Security for Grid Services”, 12th International Symposium on High Performance Distributed Computing, 2003. [12] Quan Zhou, Geng Yang, Jiangang Shen, Chunming Rong, “A Scalable Security Architecture for Grid”, Sixth International Conference on Parallel and Distributed Computing, Applications and Technologies, 2005. [13] Yuri Demchenko, L. Gommas, C. de laat, B. Oudenaarde, A. Tokmakoff, “Security Architecture for Open Collaborative Environment” at www.collaboratoty.nl/ [14] Debasish Jana, Amritava Chaudhuri, A. Datta, B. B. Bhaumik, “Framework for Handling Security Issues in Interoperable Grid Services”, IEEE Indicon Conference, 2005. [15] Sarbjeet Singh, Seema Bawa, “A Framework for Handling Security Problems in Grid Environment using Web Services Security Specifications”, Second International Conference on Semantics, Knowledge and Grid, SKG2006. [16] N. Nagaratnam, P. Janson, I. Foster, et.al., “Security Architecture for Open Grid Services”, GGF OGSA Security Workgroup, 2003. [17] F. Siebenlist, V. Welch, et al., “OGSA Security Roadmap”, Global Grid Forum Specification Roadmap towards a secure OGSA, 2002. [18] David Del Vecchio, J. Basney, N. Nagaratnam, “CredEx: User Centric Credential Management for Grid and Web Services”, IEEE International Conference on Web Services, 2005. [19] Von Welch, Ian Foster et al., “X.509 Proxy Certificates for Dynamic Delegation” at www.globus.org. [20] XACML Version 2.0, http://docs.oasisopen.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf. [21] Bob Atkinson, Giovanni Della-Libera et al., “Web Services Security (WS-Security)” available at www.verisign.com/wss/wss.pdf [22] Steve Anderson, Jeff Bohren et al., “Web Services Trust Language(WSTrust)” available at specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf [23] Steve Anderson, Jeff Bohren et al., “Web Services Secure Conversation Language(WS-SecureConversation)” available at specs.xmlsoap.org/ws/2005/02/sc/WS-SecureConversation.pdf [24] Chin Lin, Vijay Varadharajan, Y. Wang, V. Pruthi, “Enhancing Grid Security with Trust Management”, Proceedings of the IEEE International Conference on Service Computing, 2004. [25] Thomas Weishaupl, C. Witzany, E. Schikuta, “gSET: Trust Management and Secure Accounting for Business in the Grid”, Sixth IEEE International Symposium on Cluster Computing and the Grid, 2006. [26] Mary R. Thompson, Doug Olson, Robert Cowles, Shawn Mullen and Mike Helm, “CA-based Trust Model for Grid Authentication and Identity Delegation”, Grid Certificate Policy WG, http://www.gridcp.es.net/Documents/GGF6/TrustModel-final.pdf, 2002. [27] Gunter Karjoth, Matthias Schunter, “A Privacy Policy Model for Enterprises”, 15th IEEE Computer Security Foundations Workshop, June 24-26, 2002. [28] Simone Fischer-Hubner, Amon Ott, “From a Formal Privacy Model to its Implementation”. [29] Ajay Brar and Judy Kay,“Privacy and Security in Ubiquitous Personalized Applications. [30] Bo Lang, Ian Foster, F. Siebenlist, R. Ananthakrishnan, T. Freeman, “A Multipolicy Authorization Framework for Grid Security” at www.globus.org. [31] Christian Schlager, Thomas Nowey, Jose A. Montenegro, “A Reference Model for Authentication and Authorization Infrastructures Respecting Privacy and Flexibility in b2c eCommerce”, Proceedings on the First International Conference on Availability, Reliability and Security (ARES’06), 2006. [32] Ludwig Seitz, Erik Rissanen, Thomas Sandholm, Babak Sadighi Firozabadi and Olle Mulmo, “”Policy Administration Control and Delegation using XACML and Delegent”, Grid Computing Workshop, 2005. [33] Jin Wu, Chokchai Box Leangsuksum, Vishal Rampure and Hong Ong, “Policy-based Access Control Framework for Grid Computing”, Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID’06), 2006.

messages, WS-Security information is embedded to handle encryption and signature requirements. SOAP messages make use of WS-Security and related specifications for security token exchange and to address security requirements like confidentiality and integrity. At the target Domain, the SOAP message is analyzed and Subjects credentials and other attributes are checked against Service Policy. At this point the Authorization Framework (as discussed in Section VI) evaluates the request. Depending on the result of the request, access to the Service/Resource is provided (step 4). Here MAP operation is also performed, if required, to provide the Subject an identity that is local to that organization. During all these steps, the relevant information is stored in log tables to address auditing and accounting requirements. The prototype implementation is able to meet identified security requirements. This suggests that the approach is workable and the proposed models can be used to provide privacy, trust and policy based access to grid and web services. VIII. CONCLUSION, SUMMARY AND FUTURE PLANS The proposed framework provides privacy, trust and policy based access to distributed services like grid and web services. For implementation we are making use of web services standards and specifications. Currently we have prototype implementation. In future we are planning to use this framework in some real environment. We are also in the process of giving a more formal treatment to authorization framework based on the proposed authentication, trust and privacy models. REFERENCES [1]

I. Foster, C. Kesselman, S. Tuecke, “The Anatomy of Grid: Enabling Scalable Virtual Organizations”, International Journal of Supercomputer Applications, 2001. [2] I. Foster, C. Kesselman, J.M. Nick, S. Tuecke, “The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration”, Open Grid Service Infrastructure WG, Global Grid Forum, 2002. [3] P. J. Broadfoot, A. P. Martin, “A Critical Survey of Grid Security Requirements and Technologies”, Programming Research Group, PRGRR-03-15, Oxford University Computing Laboratory. [4] H. Casanova, “Distributed Computing Research Issues in Grid Computing”, ACM SIGACT News Distributed Computing Column 8, July 2002. [5] “Security in a Web Services World: A Proposed Architecture and Roadmap”, Joint Security whitepaper from IBM Corporation and Microsoft Corporation 2002. [6] Marty Humphrey, Mary R. Thompson, Keith R. Jackson, “Security for Grids”, Invited Paper, Proceedings of the IEEE, 93(3):644-652, March 2005. [7] L. Ramakrishnan, “Securing Next Generation Grids”, IT Pro, IEEE Computer Society, 2004. [8] Sarbjeet Singh, Seema Bawa, “Security Policies: Key Factor for Success of Grid Services” at International Conference on Challenges and Opportunities in IT Industry (ICCII) Nov. 2005. [9] R. Buyya, “Economic-based Distributed Resource Management and Scheduling for Grid Computing”, PhD Thesis, Monash University Australia, 2002. [10] I. Foster, C. Kesselman, G. Tsudik, S. Tuecke, “A Security Architecture for Computational Grids”, 5th ACM Conference on Computer and Communications Security, 1998.


92

© 2007 WASET.ORG

A Privacy, Trust and Policy based Authorization ... - CiteSeerX

A Privacy, Trust and Policy based Authorization ... - CiteSeerX

Suggest Documents