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 | cxbayrak@ualr.edu] 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 1 November 2005 Volume 30 Number 6

2

(OGSA) and is principled around web services framework. Globus Toolkit version 3 is the first grid implementation complying with the OGSA.

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.

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.

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].

Site B

Data

Site C-Kerberos

Data Data

Site A

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:

Finvoimp

Figusite Siteto bsimuempbrokorgaexpeand fromeachdisti

1.2.

ACM SIGSOFT Software Engineering Notes Page 2 November 2005 Volume 30 Number 6

User

Site D- SSL

Data

Site G

Initiate Task

Connect to Resource Broker

Request Data Analysis

Site F

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)

igure lving lemen

re 1 dA, wh C hase prolationirical er prnizatirimenG. R site othenct at The The

pro

Access Parameter Values

Site E

Data

achieves the aim of expressing security role of an entity.

Globus Approach to Grid Security Model

1: A fictitious distributed computing scenario heterogeneous platforms and security

tations

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.

epicts a Virtual Organization having a researcher at o initiates an analysis program at a remote site C. the necessary data storage capability supplying data cessed. The analysis program leads to running a program for testing the predictions against outputs. Therefore it communicates with a resource ogram at site D to identify resources among ons which can be used to run simulation ts. The resource broker starts simulation at sites E equired parameters for the simulations are fetched F by these sites. They may also communicate with r and with the broker program. Thus, a few most tributes of the above described VO are:

• 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.

user population is large and changing. • An object is an element in grid system which can be used as some form of resource and hence needs to be protected.

quantity and location of resources vary with equal portion.

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 request-response 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

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 3 November 2005 Volume 30 Number 6

4

n R GT – G

Figure 2:Protocols are defin

Figure 2. Protocol 1 on to grid system. Uand create another prus understand how a local mapping functiThese protocols are techniques instead services application pGlobus toolkit.

Protocol for CreatioUser proxy is a speciexecutes on a machinthe user. Main concecredentials given to credentials.

A user could provwhich proxy can thenresources and to creaan inherent risk in thaequivalent to comprocontrol over time periof the user. So Globcompletely new cresigned by user credencredentials control aduration as well. It evproxy process can staallowed to start proce

Once a user proxy

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.

Domain 1

Resource Proxy

Local Policy, Mechanisms

P1Cp. PnCp

GT

Domain 2

User

Protocol 2: Allocation Of remote resource

Protocol 1: Proxy Creation User Proxy

Cp GT

Host Machine

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

ACM SIGSOFT Software Engineering Notes Page 4 November 2005 Volume 30 Number 6

Protocol 3: Resource Allocation From process

Protocol 4: Global to Local Mapping

lobal to Local Mapping Table Globus Security Architecture ed by Globus security model shown in

allows user proxy creation with user log-ser proxy process can allocate resources ocess using protocol 2. Protocol 3 helps process can allocate resources. Global to on is achieved by following protocol 4. based on authentication and signature

of encryption. Also generic security rogramming interface is implemented by

n of User Proxy fic process created by user in grid which e which is in the same domain as that of rn regarding a proxy process is type of it and how the proxy receives these

ide its proxy process its own credentials use for utilizing dynamically allocated te other processes. This condition poses t the compromise of proxy credentials is

mise of user credentials. Also there is no od for which the proxy can act on behalf us introduces the concept of creation of dentials for proxy process which are tials (e.g. user’s private key). This new

ctivity scope of proxy process and the en specifies the host names (where from rt), target hosts (where in grid proxy is

sses and/or use resources). process creation is finished, it needs to

-1

-n

GT

Local Policy,Mechanism

P1-Cp1. . Pn-Cpn

Resource Proxy

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.

5

3. User logs on to the resource using resource’s identity verification method to start a map registration process.

• A security breach at remote machine can result in malicious allocation of resource on behalf credulous user.

4. Map registration process issues MAP-SUBJECT-P request to resource proxy with global subject name and resource subject name as parameters.

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:

5. Resource proxy waits for MAP-SUBJECT-UP and MAP-SUBJECT-P with same parameters.

6. Resource proxy ensures that map registration process belongs to the resource subject specified in the map request.

7. If a match is found, resource proxy sets up a mapping and sends acknowledgements to map registration process and user proxy.

1. The process and its user proxy authenticate each other.

8. If a match is not found with timeout period, resource proxy removes the pending request with an acknowledgement to waiting entity.

2. The process issues a signed request to its user proxy, of the form sig(“allocate”, allocation request parameters)

9. If acknowledgment is not received within map timeout period, request considered to have failed [3].

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 Globus Implementation of Grid Security Architecture Proxy and returned to the requesting process. Globus security architecture provides support for user proxies, resource proxies (the Globus resource allocation manager, GRAM), certification authorities, and implementation of protocols described above.

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:

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.

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 RESOURCE-

CREDENTIAL to user proxy in a secure manner. 6. The user proxy checks the RESOURCE-

CREDENTIAL 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].

Protocol 1 Protocol 1

GSS-API

Protocol 1Protocol 1

Global to Local Mapping Protocol

GlServiAPI impleis tracommgeneany and tprocedoes

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

ACM SIGSOFT Software Engineering Notes Page 5 November 2005 Volume 30 Number 6

Plaintext

Figuobus securitces applica

provides mentation cnsport indepunication

rates a sequecommunicathe Nexus cossors. The not mandat

PKI

re 2: GSS-APy infrastructution programm

its calleran be done uendent meanmethod or nce of tokension method. mmunicationAPI is meche use of any

Kerberos

I in Globus [re is based oing interfac

s generic sing any tec

ing it is not alibrary. An

which can bGlobus emp

library to moanism indepespecific proto

XYZ

3] n Generic Security e (GSS-API). This

services whose hnology. GSS-API ffected by specific y GSS-API call e transported using loys TCP sockets ve tokens between ndent indicating it col like Kerberos,

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

simulate following grid scenario.

ClientApplic ation

Phy sicsServ ice

GlobusContainer

Server-Config.ws ddServer-

Config.ws dd

IndexServ er

MathServ ice

GlobusContainer

Server-config.wsddServer-

config.wsdd

Organization 1 Organization 2

CommonCA

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 6 November 2005 Volume 30 Number 6

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.MathProvider=console,info Client side output message is: TCwpathis TAprdoMcace Thexco TGfesefildese

coTh

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/progtutorial/MathService}add" operation.

d for

ERROR: GSI Secure Conversation (signature only) authentication require"{http://www.globus.org/namespaces/2004/02/progtutorial/MathService}subtract" operation.Current value: 4

ACM SIGSOFT Software Engineering Notes Page 7 November 2005 Volume 30 Number 6

Added 5 Subtracted 1 Current value: 4

PMonitor consists of a GUI (Graphical User Interface) hich displays both the client request and server response ckets in two different scrollable windows. As described in e previous paragraph, it is observed that only message data encrypted and the message format is kept intact.

est Scenario II ccording to Globus model, each client must have a valid oxy certificate associated while invoking a grid service. If it es not have one, Globus container rejects the request. athService is invoked with the same client program as above se from user account nitin, but without a valid proxy rtificate. This throws following error message:

is is a scenario when a user’s proxy certificate may have pired or may have been deleted or may have been rrupted. This presents a loop hole in Globus security model.

est Scenario III lobus incorporates a good control over type of security atures built into client server communication for each rvice by means of a service specific security configuration e. Each grid service is configured in the web services ployment descriptor in Globus installation directory. A curity configuration file is specified as shown below: <parameter name="securityConfig" value=<location of nfiguration file>> rough this security configuration file, container specifies

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/progtutorial/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.

ERROR: Defective credential detected [Root errormessage: Proxy file (/tmp/x509up_u500) not found.]

ERROR: Defective credential detected [Root errormessage: Proxy file (/tmp/x509up_u500) not found.]

ERROR: Defective credential detected [Root errormessage: Proxy file (/tmp/x509up_u500) not found.]

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

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:

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.

<parameter name="authorization" value="gridmap"/> Test Scenario V <parameter name="gridmap" value=<location of grid map file>/>

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.

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.

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.

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:

E.g. – <method name="math:add"> <run-as> <caller-identity/> </run-as>

"/O=Grid/OU=GlobusTest/OU=simpleCA-localhost.localdomain/OU=localdomain/CN=testuser" testuser

</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 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:

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.

If asubentrrece

For better understanding Credential delegation process flow, following pictorial representation is drawn:

ACM SIGSOFT Software Engineering Notes Page 8 November 2005 Volume 30 Number 6

Added 5 Subtracted 1 Current value: 4

n attempt is made to invoke the service with a global ject whose entry is not present in the grid map file, or if the y is present but it is corrupt, below given error message is ived:

ClientApplic ation

Phy sicsServ ice

GlobusContainer

Server-Config.ws ddServer-

Config.ws dd

Dynamic Identity=Caller’s Identity

IndexServ er

MathService Hand le

MathServ ice

GlobusContainer

Server-config.wsddServer-

config.wsdd

Invocation with Delegated Credentia ls

Grid-mapfileGrid-

mapfile

Global to Loc al Subject mapping

Organization 1 Organization 2

CommonCA

CA DB

Security-Config.xmlSecurity-

Config.xml

Figure 4: Credential Delegation Scenario

ERROR: org.globus.ogsa.impl.security.authorization.AuthorizationException: Gridmap authorization failed: peer "/O=Grid/OU=GlobusTest/OU=simpleCA-localhost.localdomain/OU=localdomain/CN=globus" not in gridmap file. ERROR: org.globus.ogsa.impl.security.authorization.AuthorizationException: Gridmap authorization failed: peer "/O=Grid/OU=GlobusTest/OU=simpleCA-localhost.localdomain/OU=localdomain/CN=globus" not in gridmap file. ERROR: org.globus.ogsa.impl.security.authorization.AuthorizationException: Gridmap authorization failed: peer "/O=Grid/OU=GlobusTest/OU=simpleCA-localhost.localdomain/OU=localdomain/CN=globus" not in gridmap file.

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: 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

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/anatomy.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

Answer: 42

[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_iccs02.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-sec-wg/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

ACM SIGSOFT Software Engineering Notes Page 9 November 2005 Volume 30 Number 6