Globus security model for grid environment

ACM SIGSOFT Software Engineering Notes Page 1 November 2005 Volume 30 Number 6 1 Globus Security Model for Grid environment Nitin V. Kanaskar1, Umit Topaloglu1, Coskun Bayrak2 Applied Science Department Department of Computer Science University of Arkansas at Little Rock Little Rock, AR [nvkanaskar | umtopaloglu | [email protected]] Abstract Grid technology is increasingly being looked upon as a natural extension of the internet for engaging in complex data processing tasks over resources which are distributed across the world. Architects and developers employing grid systems must take into consideration security implications. Dynamic generation of virtual organizations leads to a synergistic picture which has to address security requirements never encountered before. Globus toolkit has devised a framework for making secure use of grid resource components which has been proved to be a feasible solution by a number of academic and scientific organizations. This paper is an attempt to identify and discern mechanisms proposed by Globus security model with certain test scenarios [1] [2]. Introduction Distributed computing has been used for quite some time with technology specific security implementation catering to the requirements of secure data and services. Technologies like RMI, CORBA, DCOM have been adopted in enterprise environments with composition of these environments in terms of users, resources and services being static. Grids propose to complement and extend these frameworks by forming a dynamic collection of resources – users, machines, applications – spread across multiple enterprises, continents supported by a software backbone called middleware. This middleware transforms heterogeneous resources into a single, coherent, virtual machine [3] [4]. Any distributed computing platform (including grid) needs to satisfy scalability and performance demands. Among what clearly distinguishes grid from these platforms is its features resulting in security requirements which cannot be addressed by existing security technologies for distributed platforms. Elements of grid are decided in dynamic manner such that the trust relationship among these elements needs to be established during application execution time. There may not at all exist any direct security protocol among resources and processes which form this dynamic environment. Each resource belongs to a fixed administrative domain governed by security standards, policies and implementation within the domain. Security functions needed to be adopted in such picture are quite dynamic. Importance of data and application security issues assume critical proportions as more and more industry and academic interests channelize their resources towards implementing cross organizational computing infrastructure. Security Problem For Grid A particular term of interest with regards to grid is Virtual Organization (VO) which consists of computers and other resources federated by different organizations. The structure of this VO is decided by factors like availability and nature of problem to be solved. Some of the very common attributes of grid environment – also called VO - recognized universally are: 1. Coordinated resource sharing in dynamic, multi institutional virtual organizations. 2. Users and resources may be large, unpredictable and dynamic at any point 3. Each resource and user will have local policies and technologies that cannot be replaced by VO 4. Users and resources located in different organizations which do not have trust agreements 5. These organizations have different security protocols and implementations 6. Grid interactions are basically interactions between services and services acting on behalf of users More precisely, these are the security challenges posed by the dynamic and disparate composition of grids. How in a Virtual Organization access to resources and assets is controlled is the crux of the security problem as VO resources and users can be part of multiple different VOs simultaneously [5]. Attempts were made to make grid phenomenon a reality in the form of different projects like united devices, SETI@Home and distributed.net. These grid systems accomplished the task of tapping wasted processor cycles for doing compute intensive calculations. The major issue identified with all these systems was a lack of interoperability with other grid systems. All these grid projects require specific software to be installed which do not adhere to any universal standard encompassing the vastly dynamic security equation pertaining to grids. Quite a number of security technologies have been used for ensuring secure data and applications over enterprise networks. If grid needs to capitalize on the unused computing power of PCs in these enterprises, integration of different existing security implementations in these proves to be indispensable. Over the years, past grid systems have stimulated a clear need for the existence of a well defined standard for possible protocols of secure communication between entities in a multi-enterprise grid system. Global Grid Forum (GGF) is the community involved actively in developing these standards and specifications for grid computing [5]. GGF has come up with a service oriented architecture which defines a set of basic capabilities and functionalities that address prime questions in grid systems. It is known as Open Grid Services Architecture ACM SIGSOFT Software Engineering Notes Page 2 (OGSA) and is principled around web services framework. Globus Toolkit version 3 is the first grid implementation complying with the OGSA. Problem Elaboration Before delving into the specifics of the conceptual model of Globus security infrastructure, a fictitious scenario as explained in Figure 1 would help grasp the challenge in a heterogeneous distributed computing environment. Site B Site A Site CKerberos Data Data Data User Request Data Analysis Connect to Resource Broker Initiate Task Site G Site D- SSL Access Parameter Values Data Data Site F Site E Figure 1: A fictitious distributed computing scenario involving heterogeneous platforms and security implementations Figure 1 depicts a Virtual Organization having a researcher at site A, who initiates an analysis program at a remote site C. Site C has the necessary data storage capability supplying data to be processed. The analysis program leads to running a simulation program for testing the predictions against empirical outputs. Therefore it communicates with a resource broker program at site D to identify resources among organizations which can be used to run simulation experiments. The resource broker starts simulation at sites E and G. Required parameters for the simulations are fetched from site F by these sites. They may also communicate with each other and with the broker program. Thus, a few most distinct attributes of the above described VO are: 1. The user population is large and changing. 2. The quantity and location of resources vary with equal proportion. November 2005 Volume 30 Number 6 2 3. A computation involves dynamic creation of processes on resources from different sites. 4. Resources may be accesses using different authentication and authorization mechanisms. E.g. – Kerberos, plain text passwords, Secure Sockets Layer, and secure shell. Such a diverse combination of resources and users across different organizations demand security solution which assimilates access control needs of all the concerned entities [3]. Globus approach to defining grid security model covers basic security functions of authentication, access control, integrity, privacy and non-repudiation. It also encapsulates following grid specific characteristics: 1. Single sign-on which enables a user to authenticate once and start computations, acquire resources and start other processes without any more authentication process. 2. Interoperability with local security solutions by means of some entities in a domain which act as translators of security functions. 3. Grid application code developed should be exportable to other grid platforms based on OGSA. So security policy must not use anywhere bulk message encryption. 4. A standard credential framework (X.509v3) achieves the aim of expressing security role of an entity. Globus Approach to Grid Security Model Globus security policy consists of security goals, individual entities and the associated set of assumptions designed to support security mechanisms mentioned in the previous section. More specifically, it defines the individual elements viz. security subjects, security objects and a set of rules governing their interactions in the context of grid scenario. The Globus security policy is designed keeping in view all the above requirements of security infrastructure in a grid. Following are the terms defined by Globus security policy: • An entity which is actively involved in an operation in a grid requiring security measures is a subject. A user requesting a service and a process spawned by such a request in a computer on which such process executes are some examples of subjects. • A subject needs to have a credential which makes it a legal element of the system. Subject can establish its identity by means of passwords, digital signatures. • Subject authentication is first operation required to be completed before any further interaction takes place between two subjects in grid. The subjects, action initiator and the respondent adopt verify each other using credentials. • An object is an element in grid system which can be used as some form of resource and hence needs to be protected. ACM SIGSOFT Software Engineering Notes • Page 3 Whenever a subject needs to utilize an object in grid, it needs to be authorized before doing that. • Many different types of subjects and objects come together to form a larger entity called as Trust Domain. A trust domain is run by a central administration control pursuing some specific security goals. Globus security model identifies set of rules governing the relationships of the above mentioned elements as policy goals. Following points are considered in this regard: 1. A grid is composed of many trust domains. A trust domain made up of many subjects and objects is administered using a consistent technology solution and policy. Many such heterogeneous domains are required to be integrated in grid environment. Each domain has its own independent security implementation which cannot and should not be in any way affected by grid security protocol. Rather these domains should be provided with ways to easily communicate with each other and transforming global operations to operations controlled by local security policy. 2. When an operation is limited to single domain, it is controlled by that domain specific security policy. Complying with the principle of no change in the local security policy, grid security design seeks no enhancements when an operation is restricted unto a single domain. Only that domain policy will dictate the operation. 3. A global domain maintains its own global subjects and different sub-domains already have their own subjects. Global domain connects to all sub-domains with a global subject mapping to local subject. Thus, a grid will have users with possibly two identities – global identity and local identity. Each domain based on some local policy employs a global user to local user mapping function where a global user may be mapped to a dynamically determined local account, or a specific group account or a static local user account. Global log-on feature is the basis for providing the single sign-on functionality. 4. A global subject once authenticated and mapped to some local subject becomes a replica of the local subject. It virtually means that any local domain security goals are achieved only after satisfying the prerequisite of grid authentication and a valid mapping from grid identity to a local identity. 5. A local domain exhibits ultimate control on the access capabilities of an authenticated grid subject. Globus security model has ultimate design goal of ensuring no modification of local policy of a trust domain on access to objects. 6. For single sign-on to work, a process can act as a representative of a user with controlled execution of user rights. A user initiated service request may dynamically spawn processes, depending upon availability of different resources which decides the inclusion of objects in the whole requestresponse flow. This model goal seeks to achieve no user interaction after initial sign-on. A user initiated process must have sufficient authority level to start another process or even to communicate with another process. 7. All these processes working on behalf of a subject will have the same credentials. In response to a subject’s sign-on November 2005 Volume 30 Number 6 3 and a service request, there may be created a group of processes in a domain or even on a single machine to complete the service request. By allocating same credentials to these processes, boost in performance matrix is intended. Performance requirements become stringent while applying this model to large scale parallel architectures [3]. Globus Security Architecture Globus model for grid security defines grid subjects, objects, and security design goals under whose jurisdiction these subjects and objects will interact with one another following certain security protocols. Figure 1 shows a pictorial representation of this security architecture. Following elements are depicted: entities, credentials, and protocols. Globus security model is aimed to apply to large scale distributed computing environments where computations involve many processes interacting with one other and utilizing local and remote resources. Each process performs some action for a user. Thus, processes and users who initiate these processes are termed as security subjects. Computers, database systems, networks, display devices, sensors and many other types of elements which are used by subjects are known as objects [3]. Computations in grid environment are characterized by high degree of unpredictability. Number of processes started in response to a specific service request may vary depending upon the resources available at service time. So accordingly the time duration required to service a particular user request has inherent flexibility associated with it. In order to make this unpredictable process flow transparent to user, grid security infrastructure should isolate him from direct communication with each single process involved in the computation. Here comes into action the concept of user proxy. A user proxy process performs task of maintaining session of user for a limited amount of time. User proxy process acts as a user delegate. It carries its own credentials which circumvents the necessity of user credentials for each and every intermediate transactions being done on user’s behalf. The validity period of user proxy is under the control of user who can restrict it till the time duration for that particular computation. A compromise of the user proxy credentials portends less serious consequences as user can also control what its proxy can do with these credentials [3]. A related element defined by Globus security model is resource proxy which does the job of translating inter-domain security operations into intra-domain methods. Pictorial representation in Figure 1 depicts the range of interactions between entities of a grid environment. With existing definitions of grid framework, following types of operations are assumed to be supported by Globus security model. • Allocation of a resource by a user • Allocation of a resource by a process • Communication between processes in different trust domains ACM SIGSOFT Software Engineering Notes Page 4 Host Machine User Protocol 1: Proxy Creation User Proxy Cp GT Protocol 4: Global to Local Mapping Protocol 3: Resource Allocation From process Domain 1 Resource Proxy P1Cp1 . PnCpn n R Protocol 2: Allocation Of remote resource Domain 2 P1Cp1. . PnCpn Resource Proxy GT Local Policy, Mechanisms GT Local Policy, Mechanism GT – Global to Local Mapping Table Figure 2: Globus Security Architecture Protocols are defined by Globus security model shown in Figure 2. Protocol 1 allows user proxy creation with user logon to grid system. User proxy process can allocate resources and create another process using protocol 2. Protocol 3 helps us understand how a process can allocate resources. Global to local mapping function is achieved by following protocol 4. These protocols are based on authentication and signature techniques instead of encryption. Also generic security services application programming interface is implemented by Globus toolkit. Protocol for Creation of User Proxy User proxy is a specific process created by user in grid which executes on a machine which is in the same domain as that of the user. Main concern regarding a proxy process is type of credentials given to it and how the proxy receives these credentials. A user could provide its proxy process its own credentials which proxy can then use for utilizing dynamically allocated resources and to create other processes. This condition poses an inherent risk in that the compromise of proxy credentials is equivalent to compromise of user credentials. Also there is no control over time period for which the proxy can act on behalf of the user. So Globus introduces the concept of creation of completely new credentials for proxy process which are signed by user credentials (e.g. user’s private key). This new credentials control activity scope of proxy process and the duration as well. It even specifies the host names (where from proxy process can start), target hosts (where in grid proxy is allowed to start processes and/or use resources). Once a user proxy process creation is finished, it needs to November 2005 Volume 30 Number 6 4 communicate with a resource proxy. Resource proxy manages the access to a resource for doing any task which contributes toward grid computation. User proxy needing a resource access gets the authentication of resource proxy and subsequently issues the request for resource. If the request is successful, the resource is allocated with a possible process creation on it. The request can fail because the requested resource is not available (allocation failure), because the user is not a recognized user of the resource (authentication failure), or because the user is not entitled to use the resource in the requested mode (authorization failure). As discussed above, it is up to the resource proxy to enforce any local authorization requirements. Depending on the nature of the resource and local policy, authorization may be checked at resource allocation time or process creation time, or it may be implicit in authentication and not be checked at all. Protocol 2 defines mechanism used to issue a request to a resource proxy from a user proxy. It may be required to map the user’s credential into a local user I.D. or account name if the policy of the resource proxy is to check for authorization at resource allocation time. Alternatively, authorization checks can be delayed until process creation time. The ability to have a resource proxy create credentials on behalf of the process it creates relies on a process and its resource proxy executing in the same trust domain. Essential steps for user proxy generation are as below: 1. The user gains access to the computer on which the user proxy needs to be created using respective authentication method. 2. The user produces user proxy credential, by using his own credential to sign a record containing user’s I.D., the name of the local host, validity information of proxy credential 3. A user proxy process is generated with proxy Credential. Protection of the proxy credential depends upon computer policy on which user proxy is located. New process receives independent credentials by use of this protocol. That gives the ability to the process to identify itself and the identity on behalf of which it is acting (i.e. the user). Each new generated process with credential makes it possible to employ additional protocol which allows the process to control access to incoming communication activity on a per subject basis [3]. Resource Allocation Protocol Resource allocation activity is more frequently done task of resource proxy process which is created by a previous resource allocation request. This protocol exhibits simplicity and finer control. This protocol can be compared with another option where processes can allocate resources and create processes independently of user proxies which has got following two drawbacks: • A user must be able to encode and incorporate arbitrary policy into process so that it supports separate resource specific allocation criteria. ACM SIGSOFT Software Engineering Notes Page 5 • A security breach at remote machine can result in malicious allocation of resource on behalf credulous user. Each process which runs on behalf of user gets separate credentials from user along with assignment of some of the rights of user. Optional protocol described just before requires that there be established an inter-resource trust relationship for distributed authentication. Globus security model always relies on authentication between user proxy and resource proxy which expedites the existing trust relationship between the user and the resource. Given below is sequence of actions required to be taken for this protocol: 1. The process and its user proxy authenticate each other. 2. The process issues a signed request to its user proxy, of the form sig(“allocate”, allocation request parameters) 3. If the user proxy decides to service the request, it starts a resource allocation request to resource proxy. 4. The resulting process handle is signed by the user Proxy and returned to the requesting process. Above protocol comes into action when a user intends to allocate remote resource for a computation. But the procedure used while allocating a resource to start another process is different from above sequence as follows: 1. The user proxy and resource proxy establish each other’s identity. 2. The user proxy sends resource proxy signed request in the form – sig(allocationspecification) 3. The resource proxy verifies if the user who signed the proxy has the required authority according to local policy to make allocation request. 4. If the request is accepted, resource proxy creates a RESOURCE-CREDENTIAL record specifying name of the user for whom resource is allocated, resource name. 5. The resource proxy returns the RESOURCECREDENTIAL to user proxy in a secure manner. 6. The user proxy checks the RESOURCECREDENTIAL request, signs it to create credential for the requesting resource. 7. The resource proxy allocates the resource and assigns the new process(es) created signed resource credential from user proxy [3]. Global to Local Mapping Protocol This is a significant protocol in Globus security architecture which defines how correct mapping from a global subject to a local subject can be achieved. This is effectively done by resource proxy process which maintains a mapping table of global names and corresponding local names. Following are the steps taken in adopting the above protocol: 1. User proxy authenticates with resource proxy. 2. User proxy issues a signed MAP-SUBJECT-UP to the resource proxy, with global and subject name and resource subject names as parameters November 2005 3. 4. 5. 6. 7. 8. 9. Volume 30 Number 6 5 User logs on to the resource using resource’s identity verification method to start a map registration process. Map registration process issues MAP-SUBJECT-P request to resource proxy with global subject name and resource subject name as parameters. Resource proxy waits for MAP-SUBJECT-UP and MAP-SUBJECT-P with same parameters. Resource proxy ensures that map registration process belongs to the resource subject specified in the map request. If a match is found, resource proxy sets up a mapping and sends acknowledgements to map registration process and user proxy. If a match is not found with timeout period, resource proxy removes the pending request with an acknowledgement to waiting entity. If acknowledgment is not received within map timeout period, request considered to have failed [3]. Globus Implementation of Grid Security Architecture Globus security architecture provides support for user proxies, resource proxies (the Globus resource allocation manager, GRAM), certification authorities, and implementation of protocols described above. All the protocols defined in previous sections are based on high level concepts like signature, authentication and authorization without any dependence on some specific technology. So an implementation of grid security infrastructure can possibly leverage a technology which is suitable for the respective environment. This has drastic positive effect on the portability and flexibility of resulting system. Protocol 1 Protocol 1 Protocol 1 Protocol 1 GSS-API Plaintext PKI Kerberos XYZ Figure 2: GSS-API in Globus [3] Globus security infrastructure is based on Generic Security Services application programming interface (GSS-API). This API provides its callers generic services whose implementation can be done using any technology. GSS-API is transport independent meaning it is not affected by specific communication method or library. Any GSS-API call generates a sequence of tokens which can be transported using any communication method. Globus employs TCP sockets and the Nexus communication library to move tokens between processors. The API is mechanism independent indicating it does not mandate use of any specific protocol like Kerberos, ACM SIGSOFT Software Engineering Notes Page 6 SESAME, DES, or RSA public key cryptography. Currently Globus security infrastructure (GSI) uses authentication as defined by the Secure Sockets Layer protocol. There are a few reasons for the selection of SSL. SSL has been implemented in public domain (SSLeay) with proven quality service which has been developed outside the United States eliminating export related issues. SSLeay is known to have an architecture which allows easy extraction of token stream. Also, SSL is a popular protocol chosen for authentication and secure message transfer for different types of distributed computing platforms like HTTP web servers, web browsers, index services. As a result, a combination of GSI with SSL can enable a grid user to utilize not only pure Globus services but also common web services. Globus Toolkit for Grid Security Simulation Globus toolkit components have been used to simulate some scenarios in grid environment. After running these test conditions, a good understanding of how Globus Security Infrastructure helps to achieve secure communication over grid platform can be attained by leveraging the analysis of its pros and cons. Before carrying out any test experiment, the grid environment has to be set up by installing Globus toolkit. The prerequisite steps to be taken for doing so are: 1. A system with Fedora Linux 3.0 for running simulations is used. For the purpose of test case scenarios, two users in addition to root are created – user globus which is used to run the Globus container and all grid services deployed by the container by default. User account to run all the grid service clients is created. 2. Globus 3.2.1(stable release) is installed on the system. 3. Installation procedure is followed from web site [8]. 4. Globus toolkit is configured [9]. GSI uses public key cryptography (asymmetric cryptography) as the basis of its security support. This system employs a pair of digital keys – private key and public key for establishing three pillars of secure communication – privacy, integrity, and authentication. One can enforce encryption on a message using private key and receiver can decrypt the message using its public key to achieve privacy of data. Digital signature can ensure message integrity which is created with the help of private key. Authentication of a valid subject is obtained by the use of digital certificate which is signed by a certification authority. Globus provides a simple certification authority tool. Configuration of Globus involves setting up a simple CA (certification authority). For users globus and testuser (for invoking clients), certificates are created following the instructions as given in configuration procedure. Also, Globus simple CA provides scripts to create proxy certificates for these users. Complete Grid Scenario Once the necessary software is set up to run our simulation cases, software programs are written which are needed to November 2005 Volume 30 Number 6 6 simulate following grid scenario. Organization 2 Organization 1 Clie nt Applic ation Phy sicsServ ice Globus Container ServerServerConfig.ws dd Config.ws dd MathServ ice Index Serv er Common CA Globus Container ServerServer-d config.wsd config.wsd d CA DB Figure 3: Simplistic Grid picture Complete grid scenario consists of two enterprise organizations with their networks set up so that a grid computing environment provides different types of services in addition to PhysicsService and MathService, as shown in Figure 3. Software programs are written in Java programming language to provide simple services: • PhysicsService – implementing a method calcSpHeat • Math Service – providing simple addition of two numbers The tools provided with Globus are used to build respective grid services whose architecture is mainly derived from web services framework. MathService is described briefly below which is deployed on grid container running from the domain of organization 2. MathService has following 3 simple interface methods which can be invoked by an authorized grid subject: 1. add 2. subtract 3. getValue MathService is a stateful grid service whose add method keeps on summing integer parameter passed by clients invoking the service. Subtract method subtracts 1 from the current value of the counter and getValue method returns the latest value of the counter to the client. Client programs are written which invoke these services in different test scenarios. Test Scenario I This scenario assumes that a secure client program is invoking MathService where the client is run from a valid user account from the same domain. The MathService in this case is configured to run with default security features provided by Globus tollkit (i.e. message level encryption). That means that, only message data is encrypted and the message format is kept intact. Motivation for this kind of security feature is to make the data interpretation and processing portable across different grid containers which comply with OGSA specification. OGSA specification is primarily based on web ACM SIGSOFT Software Engineering Notes Page 7 services standard. So the message format, in which client and server communicate with each other, has been decided using SOAP protocol which is a standard in web services architecture. In our case, the client program is run from user account testuser. Another program needs to be run – TCPMonitor - which acts as listener for TCP packets on port 8081 and redirects all traffic which comes on this port to port 8080 where Globus container is listening for client requests. The logging feature provided with the Globus toolkit is enabled to see appropriate messages on server side. An entry in the ogsilogging.properties file which is present in the Globus installation directory as follows enables this: org.globus.progtutorial.services.security.first.impl.MathProvi der=console,info Client side output message is: Added 5 Subtracted 1 Current value: 4 TCPMonitor consists of a GUI (Graphical User Interface) which displays both the client request and server response packets in two different scrollable windows. As described in the previous paragraph, it is observed that only message data is encrypted and the message format is kept intact. Test Scenario II According to Globus model, each client must have a valid proxy certificate associated while invoking a grid service. If it does not have one, Globus container rejects the request. MathService is invoked with the same client program as above case from user account nitin, but without a valid proxy certificate. This throws following error message: ERROR: Defective credential detected [Root error message: Proxy file (/tmp/x509up_u500) not found.] ERROR: Defective credential detected [Root error message: Proxy file (/tmp/x509up_u500) not found.] ERROR: Defective credential detected [Root error message: Proxy file (/tmp/x509up_u500) not found.] This is a scenario when a user’s proxy certificate may have expired or may have been deleted or may have been corrupted. This presents a loop hole in Globus security model. Test Scenario III Globus incorporates a good control over type of security features built into client server communication for each service by means of a service specific security configuration file. Each grid service is configured in the web services deployment descriptor in Globus installation directory. A security configuration file is specified as shown below: <parameter name="securityConfig" value=<location of configuration file>> Through this security configuration file, container specifies November 2005 Volume 30 Number 6 7 what type of authentication mechanism must be adopted by client program for each method provided by the service. Three different types are possible options to be set on client side according to what is specified in the configuration file: a. Message encryption b. Digital signature c. No security In this test scenario, client program which invokes the MathService using no authentication mechanism when run, gives the following error message: ERROR: GSI Secure Conversation authentication required for "{http://www.globus.org/namespaces/2004/02/pro gtutorial/MathService}add" operation. ERROR: GSI Secure Conversation (signature only) authentication required for "{http://www.globus.org/namespaces/2004/02/pro gtutorial/MathService}subtract" operation. Current value: 4 Another client is programmed to invoke all the methods with message encryption. Server side security configuration file allows encryption for the method ‘add’ only. Subtract method is configured for signature. Thus, an invocation of this service with such client gives us following output: Added 5 ERROR: GSI Secure Conversation (signature only) authentication required for "{http://www.globus.org/namespaces/2004/02/progtutori al/MathService}subtract" operation. Current value: 5 This shows how the container rejects a call to method ‘subtract’ with encryption which is configured such that it must be called using digital signature only. Another client program is written which calls all the methods with digital signature enabled. The security configuration file specifies <integrity/> - signifying digital signature – as one of the authentication methods for methods ‘add’ and ‘subtract’. For method ‘getValue’, no authentication is specified. Thus this client runs successfully. Client output as follows is observed: Added 5 Subtracted 1 Current value: 9 Test scenario IV Grid service can be invoked by a user who does not belong to the domain which hosts the service. This is made possible by facility where a global grid subject to local domain mapping is specified in a grid map file which is maintained by local network administrator. User must be having a valid certificate ACM SIGSOFT Software Engineering Notes Page 8 from a common CA which provides certificates to both the user domain and the service domain. This grid map file is mentioned as one of the parameters in the web service deployment descriptor for the particular service in the following manner: <parameter name="authorization" value="gridmap"/> <parameter name="gridmap" value=<location of grid map file>/> A situation is considered where client program is invoked from a subject which is not a part of the domain which hosts the service. Here, the client subject has a valid certificate and a proxy certificate issued from a common CA (Certification Authority). From the proxy credentials which are used with client request, container in the target domain determines the original credentials of the client. This subject which is retrieved finally is used to check if the subject is mapped to some local subject belonging to the domain. If such a mapping exists, client request is allowed to be serviced. The MathService is invoked using client program which is run by account ‘testuser’ which may be considered as a user not belonging to the domain hosting the MathService. For account ‘testuser’ an entry in the grid map file is made in following manner: "/O=Grid/OU=GlobusTest/OU=simpleCAlocalhost.localdomain/OU=localdomain/CN=testuser" testuser In the above line, quoted string signifies the global subject i.e. a valid grid entity – user/process - which is mapped to local subject i.e. legal entity under the jurisdiction of local domain. That means MathService published on this grid environment can be invoked by any user or process which assumes the credentials of the above specified global subject. A client program is written and deployed with the same MathService with grid map file added into security features. When the above client program is run with user account ‘nitin’, the success message is seen: Added 5 Subtracted 1 Current value: 4 If an attempt is made to invoke the service with a global subject whose entry is not present in the grid map file, or if the entry is present but it is corrupt, below given error message is received: ERROR: org.globus.ogsa.impl.security.authorization.Authorizatio nException: Gridmap authorization failed: peer "/O=Grid/OU=GlobusTest/OU=simpleCAlocalhost.localdomain/OU=localdomain/CN=globus" not in gridmap file. ERROR: org.globus.ogsa.impl.security.authorization.Authorizatio nException: Gridmap authorization failed: peer "/O=Grid/OU=GlobusTest/OU=simpleCAlocalhost.localdomain/OU=localdomain/CN=globus" not in gridmap file. ERROR: org.globus.ogsa.impl.security.authorization.Authorizatio nException: Gridmap authorization failed: peer "/O=Grid/OU=GlobusTest/OU=simpleCAlocalhost.localdomain/OU=localdomain/CN=globus" not in gridmap file. November 2005 Volume 30 Number 6 8 Above is the output message when MathService is invoked with ‘globus’ user account on the system whose mapping entry is not made in the grid map file. Test Scenario V Last scenario describes how Globus handles the issue of credential delegation. In simple terms it can be put as – proxy credential which are generated from client credential are assigned to grid service which in turn invokes another service(s) with the proxy identity. An additional grid service is written – PhysicsService. PhysicsService is invoked by a client application which delegates credentials of the global subject. This is achieved by defining the runtime identity of the method invoked to be equal to the caller’s identity. Globus model allows us to add this feature to a method by means of a tag <run-as> in the service specific security configuration file. E.g. – <method name="math:add"> <run-as> <caller-identity/> </run-as> </method> The above example sets the run time identity of method ‘add’ to be equal to the invoker’s identity. Through the method ‘add’, the service can further call other services deployed on the grid with credentials which were delegated to it by the client. This is how Globus achieves single sign on by a client. Client provides his credential only once for interacting (indirectly) with many services. In our example situation, client is run from user account ‘testuser’ to invoke PhysicsService which subsequently calls MathService with the delegated proxy credentials of the client. PhysicService method is configured to run with client’s proxy credentials. This proxy credential is used in establishing identity of the caller subject by MathService. For better understanding Credential delegation process flow, following pictorial representation is drawn: Organization 2 Organization 1 Clie nt Applic ation SecuritySecurityConfig.xml Config.xml Dynamic Ide ntity= Call er’s Identity Invocation w ith Del egate d Cred entia ls Phy sicsServ ice MathServ ice MathService Hand le Globus Container Index Serv er Globus Container GridGridmapfile mapfile Global to Loc al Subject map pin g ServerServerConfig.ws dd Config.ws dd Common CA ServerServer-d config.wsd config.wsd d CA DB Figure 4: Credential Delegation Scenario ACM SIGSOFT Software Engineering Notes Page 9 MathService is configured to validate client authentications based on grid map file as global to local mapping is performed according to entries made in this file. Figure 4 shows the relation between MathService and grid map file. Client first invokes PhysicsService with proxy credential which are delegated to the service because of security configuration file. PhysicsService assumes caller’s identity at run time and with this credential it invokes MathService from another domain. It communicates with index service which is an important component in Globus toolkit package. MathService receives secure request with a credential which is signed by clients original certificate and is valid for limited time period. MathService retrieves identity of the main client as both the domains share a common Certification Authority. The global subject which is obtained from the CA database for the client is checked if it is mapped to any local user account from grid map file. If such an entry exists, the resource proxy process validates the request and allows access to MathService. Otherwise the request is invalidated and removed from the request cache. Client first calls PhysicsService which in turn invokes ‘add’ method from MathService 7 times in a loop and then calls ‘getValue’ method from MathService to display result of addition. Following output is seen: Answer: 42 Functional Analysis Globus Security Architecture is the first grid implementation which is designed with a view to support and complement different security solutions so as to federate as many disparate components as possible. No previous grid software contained this feature. It also is the first standard set of tools implementing grid entities communication protocol adhering to OGSA (Open Grid Services Architecture) which is the universal standard for charting grid specifications and protocols. In other words, Globus has set the trend of developing grid solutions based on universal standards so that different grid implementations from different vendors will be more inclined to follow its suit. Needless to say, this will go a long way in discerning grids better and utilizing them in more and more business and research areas. Future Developments There appear a few areas in Globus security design where it can be revamped to a more reliable, robust framework. It needs to overcome some of the drawbacks related to certificates management. Proxy certificates and even the original certificates are stored in files on local machines which stand susceptible to accidental corruption or deletion. Proxy Certificates need to be renewed manually at fixed time intervals. There is a scope for further improvement with novel methods being devised for storing the certificates in an online database and users requesting proxy certificates on demand [7]. MyProxy can be considered as an example of such a system [6]. Proxy certificates hold good chances of being used November 2005 Volume 30 Number 6 9 in unison with mobile agent technology in dynamic field like mobile network. Conclusion Globus security model for high performance grid computing has its pros and cons. It has come up with an implementation which strives to resolve the main security concerns like privacy, integrity and authentication in grid computing environment. It is characterized by security features which are controllable through application programs as well as configuration files so that a good compromise of security and performance for a grid application is achieved. Client delegation is a noticeable feature which empowers users with single sign-on capability. References [1] Ian Foster, Carl Kesselman, Steven Tuecke, “The Anatomy of Grid Enabling Scalable Virtual Organizations”, online at http://www.globus.org/alliance/publications/papers/anato my.pdf [2] Ian Foster, Carl Kesselman, Jeffrey M. Nick, Steven Tuecke, “The Physiology of the Grid, An Open Grid Services Architecture for Distributed Systems Integration”, online at http://www.globus.org/alliance/publications/papers/ogsa. pdf [3] Ian Foster, Carl Kesselman, Gene Tsudik, Steven Tsuecke, “A Security Architecture for Computational Grids,” Proceedings of the 5th ACM Conference on Computer and Communications Security, 1998, pp 83-92. [4] Zsolt Nemeth, Vaidy Sunderam, “A comparison of Conventional Distributed Computing Environments and Computational Grids,” online at http://www.mathcs.emory.edu/dcl/h2o/papers/grids_iccs0 2.pdf [5] Nataraj Nagaratnam, Philippe Janson, John Dayka, Anthony Nadalin, Frank Siebenlist, Von Welch, Ian Foster, Steve Tuecke, “The Security Architecture for Open Grid Services”, online at http://www.cs.virginia.edu/~humphrey/ogsa-secwg/OGSA-SecArch-v1-07192002.pdf [6] Jim Basney, “Using the MyProxy Online Credential Repository”, online at http://www.globusworld.org/2005Slides/Session%204b(2 ).pdf [7] Olivier Chevassut, “Secure (one -time-)Password Authentication for the Globus Toolkit”, online at http://www.globusworld.org/2005Slides/Session%207b(3 ).pdf [8] http://www.globus.org/toolkit/docs/3.2/installation/index. html [9] http://www.globus.org/toolkit/docs/3.2/installation/install _config.html