UNIT-2

1. OPEN GRID SERVICE ARCHITECTURE: As we have discussed, grid computing assumes and/or
requires technologies that include:
• Support for executing programs on a variety of platforms
• A secure infrastructure
• Data movement/replication/federation
• Resource discovery
• Resource management
For each of these areas, there are a variety of technologies available that could be used to address them.
We will look at just a few of the standards (both proposed and adopted) that could be considered when
architecting a grid-based solution.
• INTRODUCTION:
Open Grid Services Architecture (OGSA) describes a service-oriented architecture for a grid computing
environment for business and scientific use. It was developed within the Open Grid Forum, which was called the
Global Grid Forum (GGF) at the time, around 2002 to 2006.
OGSA is a distributed interaction and computing architecture based around services, assuring interoperability on
heterogeneous systems so that different types of resources can communicate and share information. OGSA is based
on several other Web service technologies, such as the Web Services Description Language (WSDL) and the Simple
Object Access Protocol (SOAP), but it aims to be largely independent of transport-level handling of data. OGSA has
been described as a refinement of a Web services architecture, specifically designed to support grid requirements.
The concept of OGSA is derived from work presented in the 2002 Globus Alliance paper "The Physiology of the
Grid" by Ian Foster, Carl Kesselman, Jeffrey M. Nick, and Steven Tuecke. It was developed by GGF working
groups which resulted in a document, entitled The Open Grid Services Architecture, Version 1.5 in 2006. The GGF
published some use case scenarios.
According to the "Defining the Grid: A Roadmap for OGSA Standards v 1.0", OGSA is:
• An architectural process in which the GGF's OGSA Working Group collects requirements and maintains a set
of informational documents that describe the architecture;
• A set of normative specifications and profiles that document the precise requirements for a conforming
hardware or software component;
• Software components that adhere to the OGSA specifications and profiles, enabling deployment of grid
solutions that are interoperable even though they may be based on implementations from multiple sources.
The Open Grid Services Architecture, Version 1.5 described these capabilities:
• Infrastructure services
• Execution Management services
• Data services
• Resource Management services
• Security services
• Self-management services
• Information services
In late 2006 an updated version of OGSA and several associated documents were published, including the first of
several planned normative documents, "Open Grid Services Architecture Glossary of Terms, Version 1.5".
The Open Grid Services Infrastructure (OGSI) is related to OGSA, as it was originally intended to form the basic
“plumbing” layer for OGSA. It was superseded by Web Services Resource Framework (WSRF) and WS-
Management.
➢ OGSA
The Global Grid Forum has published the Open Grid Service Architecture (OGSA). To address the requirements of
grid computing in an open and standard way, requires a framework for distributed systems that support integration,
virtualization, and management. Such a framework requires a core set of interfaces, expected behaviors, resource
models, and bindings. OGSA defines requirements for these core capabilities and thus provides general reference
 architecture for grid computing environments. It identifies the components and functions that are useful if not
required for a grid environment. Though it does not go to the level of detail such as defining programmatic
interfaces or other aspects that would guarantee inter operability between implementations, it can be used to
identify the functions that should be included based on the requirements of the specific target environment.
➢ OGSI
As grid computing has evolved it has become clear that a service-oriented architecture could provide many benefits
in the implementation of a grid infrastructure. The Global Grid Forum extended the concepts defined in OGSA to
define specific interfaces to various services that would implement the functions defined by OGSA.
More specifically, the Open Grid Services Interface (OGSI) defines mechanisms for creating, managing, and
exchanging information among Grid services. A Grid service is a Web service that conforms to a set of interfaces
and behaviors that define how a client interacts with a Grid service. These interfaces and behaviors, along with other
OGSI mechanisms associated with Grid service creation and discovery, provide the basis for a robust grid
environment. OGSI provides the Web Service Definition Language (WSDL) definitions for these key interfaces.
Globus Toolkit 3 included several of its core functions as Grid services conforming to OGSI.
➢ OGSA-DAI
The OGSA-DAI (data access and integration) project is concerned with constructing middleware to assist with
access and integration of data from separate data sources via the grid. The project was conceived by the UK
Database Task Force and is working closely with the Global Grid Forum DAIS-WG and the Globus team.
➢ GridFTP
GridFTP is a secure and reliable data transfer protocol providing high performance and optimized for wide-area
networks that have high bandwidth. As one might guess from its name, it is based upon the Internet FTP protocol
and includes extensions that make it a desirable tool in a grid environment. The GridFTP protocol specification is a
proposed recommendation document in the Global Grid Forum (GFD-R-P.020). GridFTP uses basic Grid security
on both control (command) and data channels. Features include multiple data channels for parallel transfers, partial
file transfers, third-party transfers, and more. GridFTP can be used to move files (especially large files) across a
network efficiently and reliably. These files may include the executables required for an application or data to be
consumed or returned by an application. Higher level services, such as data replication services, could be built on
top of GridFTP.
➢ WSRF
WSRF is being promoted and developed through work from a variety of companies, including IBM, and has been
submitted to OASIS technical committees. Basically, WSRF defines a set of specifications for defining the
relationship between Web services (that are normally stateless) and stateful resources. WSRF is a general term that
encompasses several related proposed standards that cover:
• Resources
• Resource lifetime
• Resource properties
• Service groups (collections of resources)
• Faults
• Notifications
• Topics
As the concept of Grid services evolves, the WSRF suite of evolving standards holds great promise for the merging
of Web services standards with the stateful resource management requirements of grid computing.
➢ Web services related standards
Because Grid services are so closely related to Web services, the plethora of standards associated with Web services
also apply to Grid services. We do not describe all of these standards in this document, but rather recommend that
the reader become familiar with standards commonly associate with Web services, such as:
• XML
• WSDL
• SOAP
• UDDI
In addition, there are many evolving standards related to Web Services Interoperability (WS-I) that also can be
applied to and bring value to grid environments, standards, and proposed standards.
2. APPLICATION CONSIDERATIONS

➢ General application considerations

While a grid-based environment may offer many advantages, any given application may not necessarily benefit from
a grid. For example, some personal productivity applications are tightly coupled with a user’s interface and do not
consume a large amount of computing resources. Running them on a grid may not provide significant benefits.
However, other applications may be very suited for exploiting a grid.
If we take a parochial view of the grid as an environment that provides access to vast amounts of computing power,
one of the simplest concepts for grid utilization is to be able to run an application somewhere else when your own
machine is too busy or otherwise does not have the required resources. Almost any kind of application can be
executed in a grid environment this way. You may not see spectacular performance gains unless the machine it runs
on is much faster than the machine you usually use. Applications that can be run in a batch mode are the easiest to
execute on other resources within the grid. Applications that need interaction through graphical user interfaces are
more difficult to run on a grid, but not impossible. For instance, they can use remote graphical terminal support,
such as X Windows or other similar capabilities.
For this discussion, let us consider a grid environment to be distributed computing on virtualized resources.
Distributed computing concepts are well known and most application architects and developers understand what it
takes to enable an application to execute and take advantage of a distributed computing environment. What is new is
the utilization of virtualized resources. This implies that the application developer may not know (and optimally
should not need to know) what operating platform or other resources (network, storage, and so on) will be utilized
by the application at run time. The more an application can be written to be independent of actual physical
resources, the more likely it can take advantage of a grid environment by running on any available resources that
provide the required services and conform to any applicable policies.
Likewise, using standardized interfaces for access to storage, databases, and network communications provides the
portability required to run on virtualized resources independent of their physical makeup.
Applications specifically designed to use multiple processors or other federated resources of a grid will benefit most.

➢ CPU-intensive application considerations

To determine if existing or planned applications that are CPU intensive can take advantage of a grid environment
requires many considerations. This section describes some things to consider related to the possible applicability of a
grid to these applications. Probably the most important step in grid enabling an application is to determine whether
the calculations can be done in parallel. While High Performance
Computing (HPC) clusters are sometimes used to handle the execution of applications that can utilize parallel
processing; grids provide the ability to run these applications across a heterogeneous, geographically dispersed set of
clusters. Rather than run the application on a single homogenous cluster, the application can take advantage of the
larger set of resources in the grid. If the algorithm is such that each computation depends on the prior calculation,
then a new algorithm (if possible) may be beneficial. Not all problems can be converted into parallel calculations.

In a distributed application, partial results or data dependencies may be met by communicating among subjobs. That
is, one job may compute some intermediate result and then transmit it to another job in the grid. If possible, one
should consider whether it might be more efficient to simply recompute the intermediate result at the point where it
is needed rather than waiting for it from another job. One should also consider the transfer time from another job,
versus retrieving it from a database of prior computations.

➢ Data considerations
When considering applications that may be split into multiple parts for execution on a grid, it is important to
consider the amounts of data that are needed to be sent to the node performing a calculation and the time required to
send it. If the application can be split into small work units requiring little input data and producing small amounts
of output data, that would be most ideal. The data in this kind of case is said to be staged to the node doing the work.
Sending this data along with the executable file to the grid node doing the work is part of the function of most grid
systems. However, in many applications, larger amounts of input and/or output data are involved, and this can cause
complications and inefficiencies.
When the grid application is split into subjobs, often the input data is a large fixed set of data. This offers the
opportunity to share this data rather than staging the entire set with each subjob. However, one must consider that
even with a shared mountable file system, the data is being sent over the network. The goal is to locate the shared
 data closer to the jobs that need the data. If the data is going to be used more than once, it could be replicated to the
degree that space permits. If more than one copy of the data is stored in the grid, it is important to arrange for the
subjobs to access the nearest copy per the configuration of the network.
This highlights the need for an information service within the grid to track this form of data awareness. Furthermore,
one must be careful that the network does not become the bottleneck for such a grid application. If each subjob
processes the data very quickly and is always waiting for more data to arrive, then sharing may not be the best
model if the network data transfer speed to each subjob does not at least match disk speeds. Shared data may be
fixed or changing.
In some applications, various database records may need to be updated atomically or in concert with others. Locking
or synchronization primitives are used to lock all of the related database entries, whether they are in the same
database or not, and then are updated while the synchronization primitives keep other subjobs waiting until the
update is finished. One should look for ways to minimize the number of records being updated simultaneously to
reduce the contention created by the synchronization mechanism. One should exercise caution not to create
situations that might cause a synchronization deadlock with two subjobs waiting for each other to unlock a resource
the other needs. There are three ways that are usually used to prevent this problem:
• The first is the easiest, but can be the most wasteful. This is to have all waits for resources to include time-
outs. If the time-out is reached, then the operation must be undone and started over in an attempt to have
better luck at completing the transaction.
• The second is to lock all of the resources in a predefined order ahead of the operation. If all of the locks
cannot be obtained, then any locks acquired should be released, and then, after an optional time period,
another attempt should be made.
• The third is to use deadlock detection software. A transitive closure of all of the waiters is computed before
placing the requesting task into a wait for the resource. If it would cause a deadlock, the task is not put into
a wait. The task should release its locks and try again later. If it would not cause a deadlock, the task is set
to automatically wait for the desired resource.
It may be necessary to run an application redundantly for reliability reasons, for example. The application may be
run simultaneously on geographically distinct parts of the grid to reduce the chances that a failure would prevent the
application from completing its work or prevent it from providing a reliable service. If the application updates
databases or has other data communications, it would need to be designed to tolerate redundant data activity caused
by running multiple copies of the application. Otherwise, computed results may be in error.

3. SECURITY
Computer Security and Access Control Models
Computer security is about protection of assets. The protection measures include prevention (taking measures to
prevent assets from being damaged), detection (taking measures that allow one to detect when an asset has been
damaged) and reaction (taking measures that allow one to recover assets from damage). The notion of computer
security revolves around three core aspects namely confidentiality, integrity and availability. Confidentiality is
prevention of unauthorized disclosure of information. Integrity is about preventing unauthorized modification of
information where as availability deals with prevention of unauthorized withholding of information or resources.
The three other aspects which are equally important for computer security are accountability, non-repudiation and
reliability. Accountability refers to the audit information that must be maintained and protected so that actions
affecting security can be traced to the responsible party. Non-repudiation services provide unforgeable evidence that
a specific action has occurred. Reliability relates to accidental failures and safety relates to impact of system failures
on their environment. Dependability can be stated as a concept unifying security, reliability, integrity and
availability. It is the property of a computer system such that reliance can justifiably be placed on the service it
delivers. We can say that dependability summarizes all the aspects of computer security.
1 Security Models
Implementing security for an organization needs well-framed security policies. A security policy is a statement of
intent to protect an identified resource from unauthorized use. Organizational security policy is a set of laws, rules
and practices that regulate how an organization manages, protects and distributes resources to achieve specified
security policy objectives. There are also automated security policies which address issues like the definition of
access control lists or firewall settings, decisions on the services that may run on devices and the security protocols
used to protect network traffic. To formulate a security policy, we have to describe the entities governed by the
policy and we have to state the rules that constitute our policy. Security models play an important role in the design
and evaluation of high assurance security systems. The design process of such systems starts from a formal
specification of the policy which the system should enforce (security model) and a high level specification of the
system itself. By adding more details to this high level specification, we can arrive at a series of low level
specifications. We need to show that the high level specification implements the desired policy. For high assurance,
a proof is required. A security model is a mathematical or logical expression of a set of security policies. A system
can be secure only if its security model is based on logically sound premises as the security features are built into
such components of a computer system like the operating systems, database systems, applications, etc on the basis
of their security models. Security models are also used in security evaluation, sometimes as proofs of security. There
are several well-known security models, such as the Bell-LaPadula (BLP) model and the Biba model which
represent the concepts for controlling accessibility, integrity, etc. of information systems. All information security
models use the terminologies ’subject’ and ’object’. A ’subject’ is an entity, such as a person, process, or device
which accesses or uses information from the system. An ’object’ is the information, or a piece of a larger body of
information, which is accessed by a ’subject’. An ’object’ may be a ’subject’ in another situation or context and vice
versa.
The important types of information security models are
• Access Control models
• Integrity models
• State machine models
• Information flow models
• Non-interference models
Different types of information security models use different philosophies for looking at subjects and objects, for
grouping and classifying them and for controlling their interactions. A specific model, which may be a well-known
model or a model designed for a particular organizational environment, usually has features from different types of
information models. Among the earlier models, BLP is a state machine model which represents the confidentiality
aspect of computer security. Biba model and Clark-Wilson model were designed to represent the integrity aspect of
security.
The Chinese Wall model represents dynamically changing access rights. The Harrison-Ruzzo-Ulman (HRU)
model defines authorization systems that represent policies for changing access rights or for the creation and
deletion of subjects and objects. Information flow models consider any kind of information flow, not only the
direct information flow through access operations but also the indirect flow through covert channels. The following
subsection describes some of the security models perceived as access control models.
Access means entry, approach, or privilege to a resource. Access control is a mechanism to secure resources from
unauthorized use. It constrains what a user can do directly as well as what the programs executing on the user’s
behalf are allowed to do. Access control models use sets of rules, which permit or deny access for a subject to an
object. This ensures that information does not fall into wrong hands. The process involves a subject requesting for
an object. The permission or denial of access to the object depends upon the ’right’ that the subject possesses. The
early years (1975 - 1985) saw the evolution of three major categories of access control models namely
• DAC (Discretionary Access Control ) Model
• MAC (Mandatory Access Control) Model
• HRU (Harrison Ruzzo and Ullman) Model
The DAC Model consists of a set of Objects (O) , a set of Subjects (S) and an Access Matrix (A). Any element
A[i,j] specifies the access which the subject i has to the object j . When the matrix is stored by columns it is called
an Access Control List (ACL). When the matrix is stored by rows it is called a Capability List (CL). The DAC
model had its own drawbacks. It does not provide real assurance on the flow of information in a system. Also it does
not impose any restriction on the usage of information by a user once the user has received it. Objects depend on
their owners to permit access to them for other users. Information can be copied from one object to another, so
access to a copy is possible even if the owner of the original does not provide access to it.
As per the MAC Model, subjects and objects in a system have a certain classification. The read-up operation means
a subject’s integrity level must be dominated by the object being read whereas in write-down operation, a subject’s
integrity level must dominate the integrity level of the object being written. The MAC Model has its own
drawbacks. The information flow can pass through covert channels in prohibited ways. There is no solution to the
inference problem where the high level information is deduced by assembling and intelligently combining the
low level information.
In the HRU Model, the protection system consists of a finite set of generic rights (R) and a finite set of commands
(C). This model uses the DAC access matrix and has six primitive commands namely, enter R into (S,O), delete R
from (S,O) , create subject S’, create object O’, delete subject S’ delete object O’.
Originator Controlled Access Control (ORCON) is advancement over Mandatory and Discretionary Access Controls
models, as both these models cannot handle environments in which the originators of documents retain control over
them even after those documents are disseminated. In ORCON, a subject can give another subject rights to an object
only with the approval of the creator of that object. Organizations that use categories grant access to individuals on
a” need to know” basis. There is a formal, written policy determining who needs the access based on common
characteristics and restrictions. The main features of ORCON are as follows.
• The owner of an object cannot change the access controls of the object
• When an object is copied, the access control restrictions of that source are copied and bound to the target of
the copy
• The creator (originator) can alter the access control restrictions on a per-subject and per-object basis.
In ORCON, the access control associated with the object is under the control of the originator and not the owner of
the object. Possession equates to only some control. The owner of the object may determine to whom he or she gives
access, but only if the originator allows the access. The owner may not override the originator.
Alternative Models
The decade 1985 - 1995 is called the period of alternative models which are categorized as
• ChineseWall Model (CW)
• Task Based Authorization (TBA)
• Role Based Access Control Model (RBAC)
The Chinese Wall Model
Deriving its name from the Great Wall of China, this model deals with devising a set of rules such that no person
(subject) can ever access data (objects) on the wrong side of the wall. The basis of the ChineseWall policy is that
people are only allowed access to information which is not held to conflict with any other information that they
already possess.

The access rule states that a subject s can access an object o only if o is in the same company data set as some object
previously read by s. o belongs to a COI (Conflict of Interest) class within which s has not read any object. The
information flow which causes COI should be prevented. The conflict of interest classes are A,B and C where as the
company data sets are f,g,h.
Task Based Authorization
The Task Based Authorization deals with authorization of tasks rather than subject and objects. These tasks may
involve other tasks. The authorization is transient and it models the organizational structure.
Role Based Access Control
The standard discretionary access control and mandatory access control approaches cannot cater to an enterprise’s
access control requirements as the former is a user discretion mechanism and the later an approach more suitable for
Operating System security. The needs to evolve a new model for enterprise-wide security lead to the development of
Role Based Access Control Model or the RBAC.
The Role Based Access Control Model is a technical means for controlling access to computer resources. With role-
based access control, access decisions are based on the roles that individual users have as part of an organization. A
role is the standard unit of access control in RBAC and reflects the responsibilities of a user in an organization.
Users take on assigned roles (such as doctor, nurse, teller, manager). The process of defining roles should be based
on a thorough analysis of how an organization operates and should include input from a wide spectrum of users in
an organization. Access rights are grouped by role name, and the use of resources is restricted to individuals
authorized to assume the associated role.

• INTRODUCTION TO GRID SECURITY

Security requirements are fundamental to the grid design. The basic security components are comprised of
mechanisms for authentication, authorization, and confidentiality of communication between grid computers.
Without this functionality, the integrity and confidentiality of the data processed within the grid would be at risk. To
properly secure your grid environment, there are many different tools and technologies available. This chapter
examines some of those technologies.
In order to better understand grid security, it is best to start with some basic grid security requirements and security
fundamentals. Grid security builds on well-known security standards. We discuss general security requirements
followed by security fundamentals.
1- GRID SECURITY REQUIREMENTS
A virtual organization is one of the fundamental concepts in a grid environment today. A virtual organization (VO)
is defined as a dynamic group of individuals, groups, or organizations who define the conditions and rules (business
objectives and policies) for sharing resources. A grid environment is required to coordinate resource management
and sharing within a VO that potentially spans multiple organizations. This implies that a grid application may span
multiple administrative domains. Each of these domains would have its own business requirements and policies to
adhere to. A grid security infrastructure is required to comply with local domain-level security policies and VO-
defined policies. To achieve this requirement the grid security infrastructure requires interoperability amongst
various domains while maintaining a clear separation of the security policies and mechanisms deployed by both
virtual and real organizations.
The Security Architecture for Open Grid summarizes the following security challenges in a grid environment:
• Integration
The grid security infrastructure is required to integrate with existing security infrastructures across platforms and
hosting environments. The overall grid security architecture is required to be implementation agnostic and be
extensible to incorporate new security services as they become available.
• Interoperability
The Grid services that traverse multiple domains and hosting environments need to be able to interact with each
other to allow domains to exchange messages (for example, via SOAP/HTTP), allow each party to specify security
policy applied to a secure conversation, and provide mechanisms to identify a user from one domain in another
domain.
• Trust Relationship
A Grid service request can span multiple security domains. The security domains involved to meet a Grid service
request require establishing trust with each other. Due to the dynamic nature of a grid environment, it is unfeasible
to establish end-to-end trust prior to execution of an application. The issue of trust establishment becomes
complicated with transient Grid services.
At a high level the grid security requirements can be defined as follows:
Authentication Providing interfaces to plug-in different authentication mechanisms and means to convey the
mechanism used.
Delegation Providing mechanisms to allow delegation of access rights from requesters to services while ensuring
that the access rights delegated are restricted to the tasks intended to be performed within policy restrictions.
Single logon This refers to relieving an authenticated entity from re-authentication for a certain period of time when
subsequent access to grid resources are requested while taking multiple security domains and identity mappings into
account.
Credential life span and renewal Ability to refresh requester credentials if a grid application operation takes longer
to complete than the life-span of a delegated credential.
Authorization Ability to control access to grid components based on authorization policies.
Privacy Allowing both a service requester and a service provider to define and enforce privacy policies.
Confidentiality Protect confidentiality of underlying transport and message content and between OGSA-compliant
components in either point-to-point or store and forward mechanisms.
Message integrity Ensuring unauthorized changes made to message content or data can be detected at the recipient
end.
Policy exchange Allows security context negotiation mechanism between service requesters and service providers
based on security policy information.
Secure logging Provides a foundation for non-repudiation and auditing that enables all services to time-stamp and
log various types of information without interruption or information alteration by adverse agents.
Assurance Provides means to qualify the security assurance level that can be expected of a hosting environment.
The security assurance level indicates the types of security services provided by an environment. This information is
useful in deciding whether to deploy a service in the environment.
Manageability This requirement mainly deals with various security service management issues such as identity
management, policy management, and so on.
Firewall traversal Ability to traverse firewalls without compromising local control of firewall policy to enable
cross-domain grid computing environment.
Securing the OGSA infrastructure This refers to securing core OGSA components.

2- SECURITY FUNDAMENTALS
Security requires three fundamental services: Authentication, authorization, and encryption. A grid resource must be
authenticated before any checks can be done as to whether any requested access or operation is allowed within the
grid. Once the user has been authenticated within the grid, the grid user can be granted certain rights to access a grid
resource. This, however, does not prevent data in transit between grid resources from being captured, spoofed, or
altered.
The security service to insure that this does not happen is encryption. The world of security has its own set of
terminology. The International Organization for Standardization (ISO) has defined the common security services
found in modern IT systems.
To have a better understanding of security systems and services, some security terms with explanations are listed
below:
Authentication Authentication is the process of verifying the validity of a claimed individual and identifying who
he or she is. Authentication is not limited to human beings; services, applications, and other entities may be required
to authenticate also.
Access control Assurance that each user or computer that uses the service is permitted to do what he or she asks for.
The process of authorization is often used as a synonym for access control, but it also includes granting the access or
rights to perform some actions based on access rights.
Data integrity Data integrity assures that the data is not altered or destroyed in an unauthorized manner.
Data confidentiality Sensitive information must not be revealed to parties that it was not meant for. Data
confidentiality is often also referred to as privacy.
Key management Key management deals with the secure generation, distribution, authentication, and storage of
keys used in cryptography.
The Grid Security Infrastructure (GSI) provided as part of the Globus Toolkit and a Public Key Infrastructure (PKI)
provide the technical framework (including protocols, services, and standards) to support grid computing with five
security capabilities: User authentication, data confidentiality, data integrity, non-repudiation, and key management.

3- IMPORTANT GRID SECURITY TERMS

There are some important concepts that should be highlighted. This is due to the fact that some areas within grid
security require a precise understanding of the security concepts. Also, some security components may work slightly
differently within a grid environment as opposed to a standard network.
Symmetric encryption: Using the same secret key to provide encryption and decryption of data.
_ Asymmetric encryption: Using two different keys for encryption and decryption. The public key encryption
technique is the primary example of this using a public key and a private key pair.
_ Secure Socket Layer/Transport Layer Security (SSL/TLS): These are essentially the same protocol. TLS has
been renamed by the IETF, but they are based on the same RFC.
_ Public Key Infrastructure (PKI): The different components, technologies, and protocols that make up a popular
asymmetric encryption solution.
_ Mutual Authentication: Instead of using an LDAP repository to hold the public key (PKI), two parties who want
to communicate with one another use their public key stored in their digital certificate to authenticate with one
another.

Getting access to the grid

In order to build a grid environment using the GSI components, you have to create a set of keys for public key
cryptography and request your certificate from the Certificate Authority and a copy of the public key of the CA. The
following procedure describes the steps to establish the GSI communication:
1. Copy the Certificate Authority’s public key to your grid host with which you set up GSI.
2. Create your private key and a certificate request.
3. Send your certificate request to CA by e-mail or another more secure way if you are running a production system
and need to positively identify the sender.
4. CA signs your request to make your certificate and sends it back to you.

When that procedure has been completed and you have received your signed digital certificate, you will have three
important files on your grid host. They are:
• The CA’s public key
• The grid host’s private key
• The grid host’s digital certificate
In order to provide secure authentication and communication for your grid computer, you should not let others have
access to your private key. An extra layer of security was added to the private key, which includes a secret
passphrase that must be used when using your private key along with your digital certificate. This is to prevent
someone from stealing your digital certificate and private key and being able to automatically use them to access
grid resources. The host key is protected by the local operating system privileges within the grid server.
Authentication and authorization
Imagine a scenario where you need to communicate with another grid computer’s application and you want to
ensure that the data from the host is really from the host. Besides making sure that you can trust the grid host, you
want to make sure the grid host that you want to communicate with trusts your grid computer. In these cases, you
can use the authentication function of GSI. After you have authenticated with the remote grid resource, you then
have the option of having the grid resource give you access to resources on your behalf. In this case, you can use the
authorization function of GSI. Through the steps described below, grid host A (or a user on grid host A) is
authenticated and authorized by grid host B. Almost all steps are for authentication, except the last authorization
step:
1. A user or application on A sends its certificate to the host B.
2. Host B will get the public key for A and will use it to extract the subject from the certificate.
3. Host B creates a random number and sends it to host A.
4. Host A receives the number, encrypts it with its private key, and sends the encrypted number to host B.
5. Host B will decrypt the number and check that the decrypted number is really the one that it sent before. Then
host B authenticates that the certificate is really that from the user on host A, because only that user on host A can
encrypt the number with its private key.
6. The certificate is authenticated by host B, and the subject in the certificate is mapped to a local user name. The
subject is in the form of Distinguished Name (DN) like “O=Grid/O=Globus/OU=itso.grid.com/CN=your name“, and
it is the name that is used by LDAP to distinguish the entries in the directory service. The subject is used to specify
the user identity in a grid environment. The user defined by the Distinguished Name is authorized by host B to act as
a local user on host B.

In grid environments, your host will become a client in some cases, and in other cases, a server. Therefore, your host
might be required to authenticate another host and be authenticated by the host at the same time. In this case, you
can use the mutual authentication function of GSI. This function is almost the same as explained above, and it
proceeds with the authentication steps, and changes the direction of hosts and redoes the procedure. Briefly
speaking, authentication is the process of sharing public keys securely with each other, and authorization is the
process that maps your DN to a local user/group of a remote host.

4. GRID INFRASTRUCTURE SECURITY

Apart from the different GSI components and technologies, there are many other infrastructure security components
that are needed to secure the grid. As in other areas of grid design, the grid infrastructure security builds on other
security principles. While these security components are optional, they are considered standard within many
production networks. We explore some of these basic security concepts and see how they fit into a grid
infrastructure.
1 Physical security
Once again, the security of grid infrastructure is based on other common security fundamentals. The basics involve
solid physical security practices for all grid computers. The physical environment of a system is also considered a
part of the infrastructure. If the servers are kept in an open room, no matter how secure the applications are designed
or how complex the cryptographic algorithms are, the server services can easily be interrupted, such as being
powered off, or otherwise tampered with. Therefore, physical access should be controlled and is part of the security
policies that need to be defined. The CA server should be located in a robust, dedicated, and locked room. All
accesses should be logged and controlled. The power supply to the servers should never be interrupted. This means
an uninterruptable power supply (UPS) must be used. However, a UPS may still run out of electricity after a
prolonged period. In such a case, the servers should be able to automatically back up the data and properly shut
down. For maximum security, the network segment where the PKI-sensitive server machines are installed should be
physically and logically separated from the rest of the network. Ideally, the separation is done through a firewall that
is transparent only for PKI-related traffic. Normally, PKI traffic is reduced to using only a few TCP/IP ports.
2 Operating system security
A review of the configuration files for each operating system and middleware component within the scope of the
project determines how each effectively allows authorized users access based on your security policy and prevents
and detects unauthorized access attempts at all times. You should:
• Remove any unnecessary processes from the servers. If the grid server does not need send mail or an FTP
server running, these processes should be disabled.
• Remove any unnecessary users or groups.
• Use strong passwords for all users on the grid server.
• Update your server with the latest updates and security FixPacks. This includes all software the has been
installed as well.
• Restrict access to directories that contain security-related information, such as the /.globus directory (in a
Globus Toolkit) environment.
• Consider using host IDS to monitor important directories on the server.
• Enable logging and auditing for the server.
• Use a uniform operating system build whenever possible.
• Enable file-level restrictions on important files within the server.
• Make periodic reviews of the operating system every other month to ensure that nothing major has
changed.
• Enable anti-virus protection.
3 Grid and firewalls
Firewalls can be used within a networked environment to logically separate different sets of computers that require
additional security. In a grid environment, this is no different. The use of firewalls within a grid design helps restrict
network access to computers. The firewall is an important piece of the security infrastructure, so it needs to be
carefully analyzed and understood before it is implemented.
4 Host intrusion detection
A recommended option for further securing your grid computers is to invest in a host intrusion detection (IDS)
product. As with any software application that stores important files within the local workstation, host intrusion
detection can add a greater defense for anyone manipulating files on the workstation that should not be doing so. If
the host IDS product detects a changed file on the server, it can send an alert to a central monitoring workstation to
log and alert the necessary people. An intrusion detection system gathers and analyzes information from various
areas within a computer or a network to identify possible security breaches, which include both intrusions (attacks
from outside the organization) and misuse (attacks from within the organization). An intrusion detection system uses
vulnerability assessment (sometimes referred to as scanning), which is a technology developed to assess the security
of a computer system or network. Intrusion detection functions include:
• Monitoring and analyzing both user and system activities
• Analyzing system configurations and vulnerabilities
• Assessing system and file integrity
• Ability to recognize typical patterns of attacks
• Analysis of abnormal activity patterns
• Tracking user policy violations
5 Network intrusion detection
There can be a point made for network IDS within a grid environment, but some of that benefit would be lost due to
the encryption between grid servers. While a network IDS would be able to use special signatures for standardized
network traffic, the introduction of a network-based IDS system would be lost because of the SSL/TLS encryption.
While a network IDS system could not see the data payload portion of the packet that is encrypted, the network IDS
could respond to events based on the packet header that is unencrypted. Network IDS is best suited for placement
where it can analyze unencrypted traffic.
 ➢ OGSA GRID SERVICE REQUIREMENTS
From the OGSA perspective, a grid environment consists of typically few persistent and potentially many transient
Grid services. All Grid services must comply with the OGSA-required interface specifications to enable reliable and
secure management of a distributed state of virtual resources.
The following are some of the key capabilities that the OGSA Service Model requires a compliant Grid service to
provide:
• Creation: This refers to creating new instances of resources associated with a Grid service via an operation.
An instance can be newly created or be initialized from a persistent state of a resource.
• Global naming and references: Once we have an instance of a resource, a grid environment requires a
unique network-aware reference to a resource instance with information about how to interact with the
instance via the Grid service.
• Lifetime management: The lifetime management operation defines the life-span of a resource, mainly
dependent on whether a resource expires after a certain time period or immediately.
• Registration and discovery: This set of operations refers to the ability to find Grid service instances and
their associated deploy-time and run-time meta data.
• Notification: The notifications are asynchronous messaging mechanisms to notify subscribing clients of
certain events such as resource life-time events, property changes, and so on.
The OGSA Grid services also address authorization, concurrency control, and manageability aspects. There are two
standards currently available to implement OGSA-compliant Grid services:
• Open Grid Services Interface (OGSI) Grid services
• Web Services Resource Framework (WSRF) Grid services
Both frameworks provide mechanisms to implement OGSA-compliant Grid services in different ways.

➢ OVERVIEW OF GLOBUS TOOLKIT 4

Globus Toolkit 4 is a collection of open-source components. Many of these are based on existsing standards, while
others are based on (and in some cases driving) evolving standards. Version 4 of the toolkit is the first version to
support Web service based implementations of many of its components. (Version 3 had included an OGSI
implementation of some components, and Version 2 was not service based at all.) Though many components have
Web service based implementations, some do not, and for compatibility and migration reasons, some have both
implementations. Globus Toolkit 4 provides components in the following five categories:
• Common runtime components
• Security
• Data management
• Information services
• Execution management
Table 10-1 shows a list of components in Globus Toolkit 4, and identifies those that are Web service based and
those that are not.