Skip to main content
skip to main content

developerWorks  >  Grid computing  >

Introducing GT4 security

Grid Security Infrastructure, the security component in Globus Toolkit 4

developerWorks
Document options

Document options requiring JavaScript are not displayed

Discuss


Rate this page

Help us improve this content


Level: Introductory

Babu Sundaram (babu@cs.uh.edu), Grid Specialist

31 May 2005

In this article, you are introduced to the Grid Security Infrastructure (GSI), the security component in Globus Toolkit 4 (GT4). Get an overview of the basic design and architecture of GSI, which enables grid entities to use authentication, authorization, and secure communication over open networks. Using a simple grid service as an example, you set up, configure, and use GSI for authentication and secure communication.

What is GSI?

In any networked environment, security is a paramount concern. You must protect yourself from outside threats. Because this requirement is especially true for a grid environment where clients can be geographically and organizationally diverse, GT4 meets this need. Basic requirements and motivations for security in any grid environment include, but are not restricted to:

  • Secure and tamper-proof communication between grid entities such as users, resources, and programs
  • The ability for grid users to use single sign-on capabilities across multiple resources
  • Privilege delegation from one entity to another for proxy-like operations
  • Interoperability with security mechanisms in place at the participating organizations

GSI is the GT4 component that addresses all these requirements and allows for privacy, integrity, and replay protection for grid communication (to eliminate sniffing and man-in-the-middle attacks), as well as single sign-on and delegation abilities for grid users. It also includes facilities for verifying the identity of a grid entity (authentication) and, based on that, determining the actions the entity is allowed to perform (authorization).



Back to top


GSI function and architecture

GSI includes both resource- and client-side tools for grid security. On the resource side, GSI tools include X.509 credentials for identifying the resource. (See Resources for more information on X.509, as well as tools to spawn processes on behalf of authenticated clients.)

On the client side, tools include facilities to create temporary credentials, called a proxy, used to perform single sign-on and delegation. The client performs mutual authentication with the target resource using the above certificates and establishes a secure, encrypted communication channel after this initial handshake, similar to the one involved in Transport Layer Security protocol (TLS) that supports secure transport HTTPS and Secure Shell (SSH). (See Resources for more information on TLS.)

Optionally, the client can choose to delegate its credentials to the resource to enable subsequent resource access without further intervention. The resource makes use of the grid map file to associate the presented credentials with a local user account. It can then spawn processes with the local user account's privileges. Optionally, it can make use of tools such as Community Authorization Service (CAS) for fine-grained authorization. Since GT4 messages are Simple Object Access Protocol (SOAP)-based, you can also turn on message-level security to provide protection for and to ensure integrity of these messages.

GSI implements standards from various standards bodies and specifications from the Web services community to provide the fundamental security needs just described. GT4 security is composed of both Web-services-based and non-Web-services-based elements that together realize grid security. GSI has been traditionally based upon public key encryption (also known as asymmetric key encryption) for all its functionalities. It uses X.509 end-entity certificates (EECs) for establishing identities of persistent entities, such as users and resources. It also introduces the notion of X.509 proxy certificates, which support delegation and the establishment of identities for temporary and often short-lived entities. GSI treats both of the certificate types equivalently. GSI makes use of Secure Sockets Layer (SSL) to achieve secure communication between grid entities.

In GT4, GSI supports both transport-level security and message-level security. Transport-level security implementation in GSI achieves authentication between grid entities using TLS and X509 certificates. Message-level security implements the support for WS-Security and WS-SecureConversation specifications. By using this, you can achieve security protection at per-message level for SOAP messages.

In GT4, transport-level security is set as the default because of its performance advantages. This setting will be deprecated as message-level security improves in performance, but that is not envisioned to happen in the immediate future.

Now that we've discussed the reasoning behind GT4, let's set up, configure, and use a GSI installation. The major steps involved in this process include the following:

  1. GSI and GT4 installation
  2. Generating certificate requests and obtain signed certificates
  3. Security configuration and privilege mapping using grid map file


Back to top


GSI and GT4 core installation

It isn't necessary to download and install the GT4 Toolkit to follow along with this article, but in order to set up and run the example, download the GT4 Toolkit at http://www-unix.globus.org/toolkit/survey/index.php?download=gt4.0.0-all-source-installer.tar.gz. The full installer is required compared with, for example, the WS Core, because we need the GSI components.

Uncompress the .tar file and follow the instructions below to build and install the GT4 Toolkit from source. Choose an installation directory, such as /home/globus/gt-4.0.0, and set that value as the GLOBUS_LOCATION environment variable. The following steps will set up GT4:

  1. Use any nonprivileged account to follow these instructions. Optionally, you can create a separate globus account to perform administrative tasks such as performing this installation, starting and stopping the container that hosts the GT4 services, and so on.
  2. Create the GT4 installation directory, which we'll refer to as GLOBUS_LOCATION from here on.
  3. We need a working installation of Java™ and the Ant build tool to compile GT4. Set the JAVA_HOME and ANT_HOME environment variables to the Java and Ant installation's root directories respectively. Be sure to also add their binaries to the PATH. For example:
    
    >> export JAVA_HOME=/usr/local/java
    >> export ANT_HOME=/usr/local/ant
    >> export PATH=$JAVA_HOME/bin:$ANT_HOME/bin:$PATH

  4. Untar and install GT4 as follows:
    
    >> untar zxvf gt4.0.0-all-source-installer.tar.gz
    >> cd gt4.0.0-all-source-installer
    >> export GLOBUS_LOCATION=/home/globus/gt-4.0.0
    >> ./configure --prefix=$GLOBUS_LOCATION
    >> make

Be aware that this make command will take between a few minutes and a few hours to complete the GT4 installation, depending upon system performance. Once it is complete, a full installation of GT4 is created, including the GSI tools.

In a terminal window, set the value of GLOBUS_LOCATION. For example:


		 >> GLOBUS_LOCATION=/home/globus/gt-4.0.0
		 >> export GLOBUS_LOCATION=$GLOBUS_LOCATION
		 

Add $GLOBUS_LOCATION/bin to the path, as in:


		 >> PATH=$GLOBUS_LOCATION/bin:$PATH
		 >> export PATH=$PATH



Back to top


Installing certificates

To use secure certificates, we must have access to a certificate authority that can "sign" them, ensuring their authenticity, as shown below. For the work presented here, we can use the SimpleCA package, which is included in GT4, to issue certificates (EECs) for ourself and the server. We can also use an existing certificate, if one exists.

When using certificates, distinguished names (DNs) provide a standard form of naming entities in a global namespace. In any environment, a given DN uniquely identifies a specific entity. An X.509 certificate refers to this DN to identify a persistent entity such as a users, server program, piece of hardware, and so on. It provides a binding between a distinguished name (DN) of the entity and a specific public key. This assertion is normally validated, or digitally signed, by a trusted entity called the certificate authority (CA).

Firewall issues

Most corporate networks employ firewalls for network protection. Globus Toolkit addresses this and allows for setting up GSI and other Globus communication to coexist with existing firewalls. Other Globus services such as MDS and GridFTP run on known ports with other temporary/ephemeral ports required for client-server interactions. To allow Globus-related communication at a range of ports, set the GLOBUS_TCP_PORT environment variable as follows: % export GLOBUS_TCP_PORT_RANGE=45000,45100.

More information and pointers regarding this issue can be found in the Resources section.

Many companies operate commercial CAs solely for the purpose of signing such certificates to identify people within organizations. In a grid setup, once we have a certificate from the target resource's trusted CA, we can authenticate with that resource. Using GSI, we can configure entities on a grid to trust in a specific set of CAs, depending on the requirements. For instance, organizations that want to collaborate may be configured to accept each other's certificates, which can be obtained from a common trusted CA.

Let's walk through obtaining certificates and performing the certificate setup for GSI.

Obtaining certificates and performing setup

GT4 provides command-line tools to generate certificate requests that can be mailed out to the CA for verification and signing. Once signed, the CA returns the signed document that we can now use to identify the entity for which the request was generated. Assuming we have an installation of GSI (or the complete GT4 installation), we can use tools such as grid-cert-request to generate these requests. This script generates a public-private key pair and an associated certificate request. The process of generating the certificate is straightforward. At the command line, type: grid-cert-request.

This generates the following output:


A certificate request and private key is being created. You will be asked to enter 
a PEM pass phrase. This pass phrase is similar to your account password
and protects your key file. If you forget your pass phrase, you will need to obtain
a new certificate. Generating a 1024-bit RSA private key
....................++++++
................................................++++++
writing new private key to /home/globus/.globus/userkey.pem

When prompted to Enter PEM pass phrase:, enter a password that will be used to protect the private key.

Running this command creates an empty usercert.pem (replaced later with the signed certificate), userkey.pem (readable only by you), and usercert_request.pem (request file to be sent to CA) in .globus directory under $HOME.

As directed, send the request to the CA, which sends back a signed version. Save this file as usercert.pem in the .globus directory under $HOME. In general, repeat this process to obtain certificate-key pairs for your own services and other resources such as servers or containers (host certificates).

To follow the examples in this article, obtain a host certificate or certificate-key pair for the container in which the grid service will run, because mutual authentication in GSI requires both you and the container that hosts the services to have EECs. To get a host certificate, use the same grid-cert-request command as before, but for systemwide services such as the container, a super user is required to generate a certificate request. Typically, host/service certificates are not passphrase protected. Generate the certificate request by typing:


grid-cert-request -host <<Full qualified Domain name of the host>>

as in:

 
grid-cert-request -host myhost.myorg.com

The container credentials are called hostcert.pem and hostkey.pem, and they need to be placed in the /etc/grid-security directory. With the certificate and key for the host, perform the following steps as root:


root# cd /etc/grid-security
root# cp hostkey.pem containerkey.pem
root# cp hostcert.pem containercert.pem
root# chown globus.globus containerkey.pem containercert.pem

Note that we're using the globus user to start and stop the container. When using a different user, adjust the command accordingly.

Grid map file management

We now have the certificates for you and the host placed at the appropriate locations. Next, we need a way to tell the GT4 service container how to associate certificate DNs to local user accounts. Grid map files serve this purpose and Globus tools perform the mapping of DNs to user accounts by using the grid map file, which is placed in the GSI-specific directory, normally /etc/grid-security/. Root access is required to edit this file, but any text editor is fine. Edit this file and add an entry such as:


"/O=TestOrg/OU=TestOrgUnit/CN=Babu Sundaram" bsundaram

This entry indicates that the entity that successfully authenticates with the above DN by using the associated certificate and proving the possession of corresponding private key will be given the privileges of the local account. In this case, the a certificate that identifies the user as /O=TestOrg/OU=TestOrgUnit/CN=Babu Sundaram indicates the user should be given the privileges of the bsundaram account. This process enables a user to present a single certificate to multiple resources and be mapped to different local accounts.

But where do we get the DN? Issue the following command to find out what the DN in the certificate is:


grid-proxy-init
Your identity: /O=TestOrg/OU=TestOrgUnit/CN=Babu Sundaram 
Enter GRID pass phrase for this identity:

Press <Ctrl+c> to stop the command as we will do the actual proxy creation later in the article.

Enter this DN and your local account in the grid map file in the format as shown above. You can also obtain the certificate DN using the command grid-cert-info -subject.



Back to top


Deploying the example

To see this in action, we can add authentication and authorization abilities to the existing grid service, such as the Auction service example detailed in the "Understanding WSRF, Part 4" tutorial. (See Resources for a link.) Download the code from the Resources section. We'll use the Ant build tool to both compile and deploy the application.

We will refer to the directory where the example classes are installed as AUCTION_HOME. Once the example files are extracted, the following directory structure will exist:


<AUCTION_HOME>/etc
<AUCTION_HOME>/schema
<AUCTION_HOME>/schema/tutorial
<AUCTION_HOME>/src

The Java SDK and Ant should be installed, and JAVA_HOME and ANT_HOME should have been set earlier, but if not, do it now:


>>> JAVA_HOME=/home/globus/jdk1.5.0_01
>>> export JAVA_HOME=$JAVA_HOME

>>> ANT_HOME=/home/globus/apache-ant-1.6.2
>>> export ANT_HOME=$ANT_HOME

Also, make sure JAVA_HOME/bin, ANT_HOME/bin, and GLOBUS_HOME/bin are on included in the PATH environment variable.

Security descriptor setting

Now we need to add a security descriptor to the deploy-server.wsdd file in the AUCTION_HOME directory so that the server knows where to obtain the configuration details for service-level security.

Add the following to deploy-server.wsdd:


<deployment name="defaultServerConfig"
    xmlns="http://xml.apache.org/axis/wsdd/"
    xmlns:aggr="http://mds.globus.org/aggregator/types"
    xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <service name="AuctionService" provider="Handler"
        use="literal" style="document">

     <parameter name="providers" value="GetRPProvider QueryRPProvider DestroyProvider
		   SetTerminationTimeProvider SubscribeProvider"/>

<!-- Additions to add Service-level Security  -->
        <parameter name="securityDescriptor" value="@config.dir@/security-config.xml"/>
        <parameter name="handlerClass" value="org.globus.axis.providers.RPCProvider"/>
        <parameter name="scope" value="Application"/>
        <parameter name="allowedMethods" value="*"/>
        <parameter name="activateOnStartup" value="true"/>
        <parameter name="className"
            value="org.globus.tutorial.auction.AuctionService"/>
        <wsdlFile>share/schema/tutorial/Auction_service.wsdl</wsdlFile>
    </service>

</deployment>

Grid map file setting

At this point, we will have successfully obtained a certificate. Let's add the DN in the certificate and the user account to the grid map file for the service, located in the AUCTION_HOME/etc directory.

As before, add the DN and username to the grid map file so that it looks something like this:


"/O=TestOrg/OU=TestOrgn/CN=Babu Sundaram" bsundaram

Use your own information, of course.

Now we need to deploy the edited grid service. From the command line, change to the AUCTION_HOME directory and type: ant deploy to deploy the application into the container. If all goes well, a BUILD SUCCESSFUL message displays. If not, review the output to find the problem, correct it, and then run the ant script again.

Proxy creation

In order for the system to work, a temporary credential must be created for the purpose of single sign-on and delegation. The operation goes as indicated here:


% grid-proxy-init
Your identity: <YOUR_DN_WILL_BE_SHOWN_HERE>
Enter GRID pass phrase for this identity:
Creating proxy
....................................................................... Done
Your proxy is valid until: <THE_PROXY_LIFETIME_WILL_BE_SHOWN_HERE>
%

When requested, enter the pass phrase used when requesting the certificate. Verify this process by ensuring a file with a name like x509_up_u<your_uid> is generated in the /tmp directory. This is the default location for the proxy unless specified otherwise.

Starting a secure container

We now need to start a secure container that checks for authentication before accepting service access requests.

Once we've deployed the service, we need to start the container. From the command line, type:


% globus-start-container 

.......
<other_services>
.......
https://localhost:8443/wsrf/services/AuctionService
.......
<other_services>
.......

This command starts the secure container. Also, note that each services is listening on port 8443 (as opposed to 8080) and uses secure HTTP (HTTPS) as the communication protocol. You should see a list of installed services (including the AuctionService), and the window should not return control. To stop the container, press <ctrl>-C in this window.

Performing authentication

Part of the auction service's deployment process generates client tools to interact with the AuctionService instance. We can now use them to perform secure operations with our service implementation. Create a new instance of AuctionService and interact with it, as shown in the following section. The create client tool takes in an extra option (-z) to indicate what level of authorization we want with the newly created instance. (Optionally, we can set the option to none to indicate no authorization.)


% $GLOBUS_LOCATION/bin/create-auction 
-s https://localhost:8443/wsrf/services/AuctionService -z self 
New Auction Created...
EPR written to file:  bid-581376501.epr

The self parameter means that modifying the properties of this instantiation is possible only for those in the grid map file. Hence, in this case, only those entities in the grid map file can change the bid values.


% $GLOBUS_LOCATION/bin/offer-bid -e bid-581376501.epr -z none 1234
Current Bid = Welcome to the Auction Service (No Bid made yet!)
Your Bid = 1234
Bid Accepted.

% $GLOBUS_LOCATION/bin/show-bid -e bid-581376501.epr -z none 
<ns1:AuctionResourceProperties xmlns:ns1="http://tutorial.globus.org/auction">
 <ns1:message>1234</ns1:message>
 <ns1:lastModified>2005-04-05T21:28:31.129Z</ns1:lastModified>
</ns1:AuctionResourceProperties>

To be sure that security is in use, remove the proxy using the grid-proxy-destroy command. Next, try to instantiate an auction or offer a bid to an existing auction. Both the actions will fail, because there is no valid proxy, so the requesting entity cannot prove the association with the DN in the grid map file. Consider this example:


% grid-proxy-destroy
% create-bid -s https://localhost:8443/wsrf/services/AuctionService -z self
Error: ; nested exception is:
   GSSException: Defective credential detected [Root error message: Proxy file
   (/tmp/x509up_u<uid>) not found.] [Root exception is
   org.globus.gsi.GlobusCredentialException: Proxy file (/tmp/x509up_u<uid>)
   not found.]

% $GLOBUS_LOCATION/bin/offer-bid -e bid-581376501.epr -z none 123456
Error: ; nested exception is:
    GSSException: Defective credential detected [Root error message: Proxy file
    (/tmp/x509up_u<uid>) not found.] [Root exception is org.globus.gsi.
    GlobusCredentialException: Proxy file (/tmp/x509up_u<uid>) not found.]

If we refresh the proxy using the grid-proxy-init command, these operations will once again be successful.

Anonymous actions

To say that we have an anonymous user means that no authentication will be performed when handling the user's requests. Because of this, users that are not included in the grid map file can interact with a services by including the anonymous option. Any user, including an anonymous user, can query the value of auction by using the -a option, as long as they know the end point reference (EPR) of the resource instance. (Although anonymous users can query the value of the current bid, they cannot create a new instance and do not know the EPRs of specific instances, so in this case, they would have to be given the EPR to allow anonymous actions.)

For example:


% $GLOBUS_LOCATION/bin/show-bid -e bid-581376501.epr -z none -a
<ns1:AuctionResourceProperties xmlns:ns1=
"http://tutorial.globus.org/auction">
 <ns1:message>1234</ns1:message>
 <ns1:lastModified>2005-04-05T21:28:31.129Z</ns1:lastModified>
</ns1:AuctionResourceProperties>



Back to top


Summary

In this article, you get an introduction to working with the GSI component provided by The Globus Alliance as part of Globus Toolkit 4. It cites the motivations behind GSI, explains the various technologies it uses, and how they all fit together, its architecture and how to set it up using an example Web Services Resource Framework (WSRF) service.

It covered the following aspects of working with GSI, including how to

  • Obtain a working installation of GSI
  • Obtain grid credentials
  • Set up the system and the grid map file
  • Install various configuration files
  • Create and destroy proxies
  • Secure and authenticate containers
  • Secure create service instances


Back to top


Resources



Back to top


About the author

Author photo

Babu Sundaram has been actively involved with grid computing research since the early days of Globus Toolkit. He was part of the Globus implementation team during his internship at Argonne National Labs. He holds a bachelor's degree in mechanical engineering and a master's degree in computer science. He is currently pursuing his doctoral-level research in computer science at the University of Houston. He has published many papers in various conferences and grid-related workshops, and also co-authored sections of a few books on grid computing. He loves teaching and, at times, works as lecturer teaching courses on Web services and aspects of grid computing. He welcomes feedback and can be reached at: babu@cs.uh.edu.




Back to top


Rate this page


Please take a moment to complete this form to help us better serve you.



YesNoDon't know
 


 


12345
 


Back to top



    About IBMPrivacyContact