Java CoG Kit GSI
From Java CoG Kit
Java CoG Kit Guide to GSI Security Editor: Gregor von Laszewski
Software Version: TBD
Last update: 2001
This document is totally outdated and needs a complete walk through. IT also should be having a focus about the new WS security in GT4. I propose to remove the compatibility guide for transition between iaik and the new way. We do this so long that this may not serve any benefit for the users anymore.
About this Document
This document includes basic information about the different Java CoG Kit Guides in order to help you find documentation about the Java CoG Kit.
Introduction to Grid Security
Security is of paramount importance in the Grid computing paradigm. The Globus Toolkit uses the Grid Security Infrastructure (GSI) \cite{Foster1998GSI} for secure access to Grid resources. Users of the Java CoG Kit thus need to interact with the GSI in order to access the Grid resources.
This chapter starts with a brief discussion about the security issues involved in the Grid paradigm and how GSI addresses these issues. It then introduces various GSI concepts such as certificates, certifying authorities, proxies, and gridmap authorization. The subsequent section explains the procedures to acquire the necessary credentials. A Web-based credential management software called MyProxy \cite{MyProxy-2001} is then discussed. We describe how a user can use the various tools that the Java CoG Kit provides for managing (creating, destroying, examining, etc.) certificates and proxies. A discussion of the security API provided by the Java CoG Kit follows. The next section describes the issues that need to be faced when using GSI across network boundaries guarded by firewalls. We conclude with a discussion of feature differences between the Java CoG Kit and the C implementations of the Globus Toolkit.
Introduction
This section assumes some knowledge of the fundamentals of information security and public key cryptography. If you are not familiar with these concepts please refer to a book, such as \cite{menezes96cryptography}. Working knowledge of Secure Sockets Layer (SSL) \cite{ssl-handshake} is also assumed.
Grid Security Infrastructure
The Grid infrastructure allows users to access computational and data resources that may span organizational, and perhaps national, boundaries. Thus it is very important to ensure that this access is secure. The basic security requirements are user authentication, confidentiality, and communication integrity. Additionally, single sign-on is desired in order to allow the user to authenticate only once, regardless of the number of resources he needs to access. This lets the user access resources with the least amount of manual intervention. In addition to satisfying these requirements, the security infrastructure needs to inter-operate with the various security paradigms being used today in different organizations. This is necessary because it is not convenient for those organizations to abandon the existing infrastructure and switch to a new one. The Grid Security Infrastructure (GSI) \cite{Foster1998GSI,www-gsi} satisfies all these requirements mentioned above.
GSI uses the Public Key Infrastructure (PKI), X.509 certificates, and Secure Sockets Layer (SSL) as its basis. It extends these standards for single sign-on. Thus, users do not have usernames/passwords in GSI. Instead they have public/private key pairs and identity certificates.
Certificates and Certifying Authorities
Every user and service on the Grid has a public and private key. These keys are used during the SSL handshake \cite{ssl-handshake} for mutual authentication for establishing a secure channel. This method is not secure unless a public key can be reliably mapped to an entity (a user or a service). GSI uses a third party called the Certifying Authority (CA) to certify this mapping.
Users and services generate public and private key pairs and send the public keys to the CA for certification. The CA verifies using some non-cryptographic means that the public key belongs to that entity. Upon successful verification, it generates a document that contains the identity of the entity (called subject name), its public key, and the identity of the CA. This document is called a ``certificate. This certificate is digitally signed by the CA, so that it cannot be tampered with.
During mutual authentication, both parties present their certificates to each other. For the authentication handshake to take place, the parties need to trust the Certifying Authorities of each other.
Proxies and delegation
In GSI, the private key of a user is stored on the user's machine. In order to protect it, it is never stored in its original form but is encrypted by using a passphrase provided by the user. Before it can be used, it needs to be decrypted. Thus, whenever a user wants to authenticate to a resource, he has to provide the passphrase in order to decrypt the private key. This can be very inconvenient, since a Grid computation typically involves obtaining access to many different computational and data resources. The need to enter the passphrase repeatedly can be avoided by creating what is called a ``security proxy, hereafter referred to as ``proxy.
A proxy contains a public and private key pair different from the key pair that belongs to the user. The proxy key pair is used during any authentication dialogs. A proxy has a limited lifetime, after which the keys are not valid. Thus, even if the private key gets compromised, the damage is limited. This approach allows storing the private key of the proxy without encrypting it with a passphrase. Thus, there is no passphrase for the proxy.
A new certificate is generated for the proxy. It contains a mapping between the user's identity (slightly modified to denote that it is a proxy) and the new public key. This certificate is signed by the user, rather than a CA. The certificates thus form a trust chain, with the user's certificate signed by the trusted CA and the proxy certificate signed by the user.
In GSI, the long-term private key of the user cannot be used for authentication. It can be used only to sign the proxy, and that is the only time the user needs to enter his passphrase.
Occasionally a service needs to acquire resources on the behalf of the user. The user's proxy cannot be used, since it resides on the user's machine and not on the service machine. GSI uses a technique called ``delegation in such cases. When a user authenticates to a service and establishes an SSL connection, the user creates another proxy that is passed to the service. This proxy is signed by the private key of the user proxy, adding another link to the trust chain. The service can use this proxy to authenticate to other resources, on behalf of the user.
Security Prerequisites
Most of the software provided by the Java CoG Kit uses the GSI security. To be able to start using GSI, you need to perform certain steps. This section describes these steps in detail.
Acquiring a user certificate
As mentioned in the introduction, getting a certificate for yourself is a matter of generating a public/private key pair, and sending it to the CA for identity verification and signing. The latter is site-specific. Each Grid should either have its own CA or use an established commercial CA that is trusted by the users and services in that Grid. Depending on the CA, the procedure for getting your certificate signed will vary.
Using Globus Toolkit tools to acquire a User Certificate
To use this method, you need to have an account on a machine where Globus Toolkit is installed, and permission to run its tools. This method is described in detail on the following Web page: \LINK{Acquiring GSI certificates}{http://www.globus.org/security/v1.1/certs.html} Follow the hyperlink ``User certificates on this page. Please note that the method specified on this page for sending your public key to the CA for signing is relevant only when using the Globus Toolkit CA, and should be replaced by a procedure specific to your site. Please contact the Grid administrator at your site for details.
After you receive the certificate from the CA, please store the certificate and the private key file with appropriate file permissions in the .globus directory inside your home directory, as instructed on the above Web page.
Acquiring a host certificate (optional)
You need to acquire a host certificate if you are going to run a Globus Toolkit service on your host. Examples of such services are Globus Toolkit GRAM server (Section \ref{C:Jobs:Introduction}) and GridFTP server (Section \ref{C:File I/O and Transfer:Introduction:GridFTP}). A host certificate is a binding between the identity of the host and its public key. Just as with user certificates, acquiring a host certificate is a matter of generating a public/private key pair and sending it to the CA for identity verification and signing. Thus, it is site-specific, as explained in the preceding subsection. Please note that for acquiring a host certificate you need to have administrative privileges on the host.
Using Globus Toolkit tools to acquire a host certificate
Please refer to the following Web page: \LINK{Acquiring GSI certificates}{http://www.globus.org/security/v1.1/certs.html} Follow the hyperlink ``Host certificates for instructions about acquiring a host certificate. As in the previous subsection, please replace the Globus Toolkit specific procedures with those specific to your site.
After you receive the certificate from the CA, please store the certificate and private key with appropriate file permissions in the host certificate directory, as mentioned on the above Web page.
Renewing a Certificate
You will get a notification from the CA when your user or host certificate is about to expire. Renewing a new certificate involves generating a new public/private key pair, creating a renewal request, and getting it signed from the CA. Thus, it is partly site-specific, as explained before. Globus Toolkit provides a tool called globus-cert-renew for this. Please refer to the following Web page for a documentation of this tool.
\LINK{Renewing a GSI Certificate}{http://www.globus.org/details/programs/globus-cert-renew.html}
Obtaining the Certificates of the Trusted CAs
You should use a service only if you trust the CA that signed the certificate. This essentially depends on whether you trust the administrators of the domain that hosts the service. If you decide to trust a particular CA, you need to obtain the certificate of that CA from its administrators. For example, administrators of the Globus Toolkit CA make the certificate available for download at \newline \LINK{Globus Toolkit CA Certificate}{ftp://ftp.globus.org/pub/gsi/globus\_ca/42864e48.0}.
Once you obtain the CA certificate, you need to let the Java CoG Kit know that you trust that CA. You can do this either by manually editing the <user-home>/.globus/cog.properties file or using the Java CoG Kit configuration wizard explained in Section \ref{C:Install:Configuration:Configuration}.
Gridmap files
Successful authentication alone is not sufficient for a user to use a service. Authentication only convinces the service that the user is indeed who he claims to be. In addition, the service has a right to check whether the user is authorized to use the service. It checks this on the basis of the user's Grid identity (i.e., his Distinguished Name), as found in the user's certificate.
Currently, Globus Toolkit services perform authorization using a file called grid-mapfile that has to be present on every machine hosting a Globus Toolkit service. This file is prepared by the GSI administrator of that site, depending on local policies. The file maps Grid identities to local usernames on that machine. A user is authorized to use a service only if the user's Grid identity can be mapped to his local username using the grid-mapfile.
Thus, before you can use any Globus Toolkit service, you have to request the Grid administrator to add you to the grid-mapfile. The procedure is site-specific. Please contact the Grid administrator for details.
Protecting Credentials
Please follow the steps given below in order to protect your security credentials:
- Make sure that the only permission on your long-term private key file
userkey.pem is the read permission for yourself. This should be the case by default, and you should never change that.
- Make sure that the only permissions on your proxy file are read and
write permissions for yourself. This should be the case by default, and you should never change that.
- If you are running a Globus Toolkit service, make sure that the only permission
on the long-term private key of the host hostkey.pem is the read permission for the superuser (root/administrator). This should be the case by default, and you should never change that.
- In the process of acquiring user credentials, you are prompted to
enter a passphrase. This passphrase is used to encrypt your long-term private key. Please make sure to select a passphrase that is easy to remember for you, but still very difficult to guess for others. If, by mistake, you have chosen a weak passphrase during this process, please change the passphrase using the tools described in Section \ref{C:Security:Managing certificates and proxies:Unix shell scripts} or \ref{C:Security:Managing certificates and proxies:Windows batch files}.
- Please don't store the private key and proxy files mentioned above
on removable media like floppy disks or zip disks, which may get stolen.
- If you want to copy the private key and proxy files mentioned above
to some other host, please don't use insecure methods such as FTP or rcp.
MyProxy
Users may use different computers to access services on the Grid. These may include computers at work, computers at home, and public access terminals. All of these machines may not be very secure and trustworthy. On each of these machines, the user needs to have his security credentials in order to authenticate to the Grid services. But it is not secure to copy the long-term credentials (user's private key and certificate) to every machine, as they may be compromised. Instead, it is desirable to have a central secure server trusted by the user where the user can store his credentials and later retrieve a proxy whenever needed for authentication. Since proxies have a limited lifetime that can be controlled, the compromise of a proxy does not cause much damage. MyProxy \cite{MyProxy-2001} serves this purpose. A securely managed MyProxy server that is trusted by the user can provide an effective way of credential management. MyProxy is available from the following Web site: \LINK{MyProxy Home Page}{http://www.ncsa.uiuc.edu/Divisions/ACES/MyProxy/}
First, the user has to store a credential to the MyProxy server. This is done from a machine that has the user's long-term credentials. From these credentials, a proxy is created and sent to the MyProxy server. The lifetime of the proxy on the MyProxy server can be controlled by the user. The proxy can be secured using a username and a password. Also, the user can restrict the hosts that can later retrieve and/or renew the proxy.
At a later time, a proxy can be retrieved by supplying the username and password that the user has set. The lifetime of the retrieved proxy can be controlled. The proxy can also be renewed, if needed.
Grid administrators may refer to the Administrator's Guide on the MyProxy home page, mentioned above, for instructions on how to maintain a MyProxy server. For users, MyProxy software comes with tools to store and retrieve credentials. The Java CoG Kit also provides command line tools for this purpose. Please refer to Sections \ref{C:Security:Managing certificates and proxies:Unix shell scripts} and \ref{C:Security:Managing certificates and proxies:Windows batch files} for information about using these tools.
Managing Certificates and Proxies
Some of the tools described in this section need that the environment variable COG_INSTALL_PATH is set to <cog-install-path>, as discussed in Section \ref{C:Install:Configuration:Environment}.
GUI
Currently, the Java CoG Kit provides the following GUI-based tools for credential management:
Visual-grid-proxy-init
This tool allows creation of a proxy. Lifetime and cryptographic strength of the proxy can be specified. Also, the locations of user's long-term credentials and the location of the resulting proxy file can be specified.
\FIGURE{htb}{images/VisualProxyInit.png} {0.5} {Visual-grid-proxy-init.} {F:Visual-grid-proxy-init}
To run this tool, run the shell script visual-grid-proxy-init or the Windows batch file visual-grid-proxy-init.bat in the <cog-install-path>/bin directory.
Java CoG Kit Configuration Wizard
This tool lets the user configure the Java CoG Kit by specifying various security related parameters, such as the locations of the user's long-term and proxy credentials and the locations of the files containing trusted CA certificates. The tool then creates a configuration file called cog.properties, which is used by the Java CoG Kit software. This tool is described in detail, along with screenshots, in Section \ref{C:Install:Configuration:Configuration}.
To run this tool, run the shell script ogce-setup or the Windows batch file ogce-setup.bat in the <cog-install-path>/bin directory.
Unix Shell Scripts
The Java CoG Kit provides a number of Unix command line tools. All of these tools can be found in the <cog-install-path>/bin directory. Each of these tools supports a -help command line option that prints a detailed usage message describing various options. These usage messages have also been included in the Appendix \ref{C:commands} of this manual.
grid-proxy-init
This tool allows creation of a proxy. By default, this tool generates a GSI-3 style proxy. The GSI-3 style proxies are not compatible with older servers (such as Globus Toolkit 2.2, 2.0). Thus, they will not work for the majority of the examples in this manual. \color{red}To generate a proxy that is compatible with Globus Toolkit 2.2 and 2.0 servers, either use the visual-grid-proxy-init tool described in the preceding section, or use the -old option for this tool. \color{black}Other options supported by this tool are lifetime, strength, policy file and so forth. This tool prompts you for your passphrase. The usage syntax is
grid-proxy-init [options]
For example, to create a proxy that will work with Globus Toolkit
2.2 and 2.0 servers, has a validity period of 12 hours, and contains
1024 bit keys,
grid-proxy-init -old -hours 12 -bits 1024
\color{red} Warning: The grid-proxy-init tool echoes your passphrase to the screen.
\color{black} The reason for this is currently Java does not have a portable way of reading the
passphrase securely from the console (without echoing it to the
screen first) Any solution would sacrifice the portability
of the code. If you want to avoid this behavior, please use the visual-grid-proxy-init tool described in the preceding section.
grid-proxy-info
This tool displays information regarding a proxy such as the issuer, Distinguished Name (DN) of the identity and time left on the proxy. The usage syntax is
grid-proxy-info [options]
For example, to observe the identity and validity period of a proxy,
use
grid-proxy-info -identity -timeleft
grid-proxy-destroy
This tool destroys a user proxy, if present. The files containing proxies can be specified. The dryrun option prints the names of files that would be destroyed, without actually destroying them. The usage syntax is
grid-proxy-destroy [-dryrun] [file1, file2, ...]
grid-cert-info
This tool displays information regarding the long-term user certificate. It can display the identity that the certificate represents, the CA that signed the certificate, the validity period, and so on. The usage syntax is
grid-cert-info [options]
grid-change-pass-phrase
This tool allows changing of the passphrase used to encrypt the long-term private key of the user. You need to enter your old passphrase. The usage syntax is:
grid-change-pass-phrase [options]
\color{red} Warning: The grid-change-pass-phrase tool echoes your old and new passphrases to the screen. \color{black} The reason for this is currently Java does not have a portable way of reading a passphrase securely from the console (without echoing it to the screen first). Any solution would sacrifice the portability of the code. The only way to avoid this problem is to provide a graphical front-end to grid-change-pass-phrase. Though this is not currently available, we plan to develop this in future.
myproxy
This tool allows storing and retrieval of credentials using a MyProxy server. Supports various options such as the hostname and port number of the server and the lifetime of the delegated proxy. The usage syntax is
myproxy [options] command
where command is one of put, get, anonget, destroy, and info. anonget is
used for anonymous retrievals.
For example, to store a proxy to host myproxy.mcs.anl.gov, with a validity period of 12 hours, use
myproxy -h myproxy.mcs.anl.gov -c 12 put
In case of the put command, you will be prompted first
for your Grid passphrase and then for the password to be used to
protect the credential stored on the MyProxy server. When you later
try to retrieve the credential using get or anonget
or any other method, \emphyou will be asked to enter this password.
\color{red} Warning: The myproxy program echoes both your Grid passphrase and the credential password to the screen.
\color{black} The reason is same as the one mentioned above regarding grid-change-pass-phrase. This problem will go away when we provide a graphical front-end to this tool.
Windows Batch Files
Each of the tools described in the preceding section has a Windows batch file counterpart. These batch files can be found in the <cog-install-path>/bin directory. Just like the Unix shell scripts, each of them supports a -help option that prints a usage message. The usage details have also been included in the Appendix \ref{C:commands} for this manual.
Java CoG Kit Shell
The Java CoG Kit shell is a convenience application that allows you to use several Java CoG Kit features from a platform-independent command line interface.
To start the shell, execute the following from the <cog-install-path>/bin directory:
cog-shell
proxy-init
Currently, the Java CoG Kit shell provides a single command called proxy-init, that presents a GUI to create a user proxy. This GUI is the same as the one explained in Section \ref{C:Security:Managing certificates and proxies:GUI}.
API
In this section we describe selected security APIs provided by the Java CoG Kit. Please note that these APIs are different from (and not backwards-compatible with) the APIs in the previous versions of the Java CoG Kit. For the convenience of developers used to the old APIs, we also provide a comparison of the old and new library APIs in this section.
Reasons for Changing the Security Library API
- The old security library was based on a commercial SSL library (IAIK),
which had licensing restrictions not suitable for many of the Java CoG Kit users.
- The old security library was socket-oriented (it was difficult to
write non-socket-based security modules e.g., for FTP, MDS.).
- The old security library API was not designed to work with multiple
security protocols, represent different types of credentials and the likes.
Functionality Provided by the New Library
The new security library is based on GSS-API and is implemented entirely with open-source SSL and certificate processing libraries. With the GSS-API abstractions it is possible to provide transport and security protocol independence. Also, the new library supports a few new features such as the new proxy certificate format and delegation-at-any-time API. For a detailed list of GSS-API implementation features and limitations, please see the following Web page: \LINK{Java GSI GSS-API Implementation} {http://www.globus.org/cog/distribution/1.1/api/org/globus/gsi/gssapi/Java_GSI_GSSAPI.html}
Key differences between old and new library
- GSS abstractions are used throughout the code instead of the old security
API (e.g., previously, setCredential(org.globus.security.GlobusProxy) and now setCredential(org.ietf.jgss.GSSCredential))
- All the security classes in the org.globus.security package and all
subpackages (except the org.globus.security.gridmap package) are now deprecated.
- The functionality of the org.globus.security.GlobusProxy class is
mostly replaced by the org.globus.gsi.GlobusCredential class. However, it is strongly recommended not to use (if possible) the org.globus.gsi.GlobusCredential class as it is a security-protocol-specific representation of (PKI) credentials. Instead, it is recommended to use the GSS abstractions as much as possible, as shown in the sample code in this section.
Getting Default (User Proxy) Credentials
Java CoG Kit 1.1a
ExtendedGSSManager manager = (ExtendedGSSManager)
ExtendedGSSManager.getInstance();
GSSCredential cred = manager.createCredential(
GSSCredential.INITIATE_AND_ACCEPT);
Saving Credentials in a File
Java CoG Kit 1.1a
ExtendedGSSCredential cred = ...
byte[] data = cred.export(ExtendedGSSCredential.IMPEXP_OPAQUE);
FileOutputStream out = new FileOutputStream("file");
out.write(data);
out.close();
Loading Credentials from a File
Java CoG Kit 1.1a
byte [] data = new buffer[1024];
FileInputStream in = new FileInputStream("file");
// read in the credential data
in.read(data);
in.close();
ExtendedGSSManager manager = (ExtendedGSSManager)
ExtendedGSSManager.getInstance();
GSSCredential cred = manager.createCredential(data,
ExtendedGSSCredential.IMPEXP_OPAQUE,
GSSCredential.DEFAULT_LIFETIME,
null, // use default mechanism - GSI
GSSCredential.ACCEPT_ONLY);
Getting the Remaining Lifetime of a Credential
Java CoG Kit 1.1a
GSSCredential cred = ... int time = cred.getRemainingLifetime();
Getting the Identity of the Credential
Java CoG Kit 1.1a
GSSCredential cred = ... String identity = cred.getName().toString();
GlobusCredential/GSSCredential Conversion
As mentioned before, it is not recommended to use the GlobusCredential class directly. To convert a GlobusCredential instance to a GSSCredential instance, you must first wrap it in org.globus.gsi.gssapi.GlobusGSSCredentialImpl class, as shown below:
GlobusCredential cred = ...
GSSCredential cred = new GlobusGSSCredentialImpl(cred,
GSSCredential.ACCEPT_ONLY);
It is also possible to retrieve the org.globus.gsi.GlobusCredential object from the GSSCredential instance if it is of the right type:
GSSCredential cred = ...
if (GSSCredential instanceof GlobusGSSCredentialImpl) {
GlobusCredential globusCred =
((GlobusGSSCredentialImpl)cred).getGlobusCredential();
}
Firewall Issues
Grids usually involve multiple organizations, or at least multiple departments in the same organization. Thus, the interactions between Grid clients and servers span network boundaries. Some of these networks may have firewalls. Since the network communication in Globus Toolkit is based on TCP sockets, firewalls may block it. You may face the following issues because of network firewalls, while using the Java CoG Kit to communicate with Globus Toolkit servers.
- Connecting to Globus Toolkit servers: If the port a Globus Toolkit server is listening
on is blocked by the firewall, the connection will fail. This applies to all servers such as GridFTP servers and Globus Toolkit Gatekeepers. This problem can be solved if the person maintaining the server requests the administrators of the server network to configure the firewall such that it allows traffic destined for Globus Toolkit servers. Since most of these servers listen on fixed, well-known ports, this is possible. Please refer to the following Web page for a list of common Globus Toolkit servers and the ports they listen on. \LINK{Globus Toolkit Firewall Requirements}{http://www.globus.org/security/v1.1/firewalls.html}
- GridFTP data channels: While transferring data using GridFTP (introduced
in Section \ref{C:File I/O and Transfer:Introduction:GridFTP}), if the client (your computer) is set in Passive mode, it starts listening on an available port and conveys this port number to the server. The server will then try connecting to that port. Since this port is neither fixed nor well known, a firewall on the client's network will probably block it. Thus, the server will not be able to connect to the port. The solution is to force the client to listen on a port number that lies in a specific range of ports, and then request the network personnel to allow these ports through the firewall. The methods used to restrict the client to a specific port range are described later in this section.
- GASS servers setup for file staging and output/error retrieval: As
explained in Section \ref{C:Jobs:Submission:API}, a GASS server needs to be run on a client machine (your machine) for staging executables and data files to, and retrieving output/errors from, jobs running on a remote GRAM server. The GRAM Job Manager will try to establish a connection with the GASS server on the client machine. Since the ports used by GASS servers are neither fixed nor well known, a firewall in the client's network will probably block the connection. The solution is the same as the one mentioned above for GridFTP data channels: restricting the port range.
- Connecting to Globus Toolkit servers behind a NAT firewall: Some networks
employ a firewall that performs Network Address Translations for the hosts in those networks. Please refer to the following Web page for a discussion of problems posed by NAT firewalls and possible solutions to these problems. \LINK{Globus Toolkit Firewall Requirements}{http://www.globus.org/security/v1.1/firewalls.html}
Restricting the Port Range Used by GridFTP Data Channels and GASS Servers
The port range can be set either in the Java CoG Kit configuration file, \newline i.e., <user-home>/.globus/cog.properties, or through the Java system properties (e.g., set from the command line). To set the port range in the configuration file just add the following line to the file:
tcp.port.range=<min>,<max>
For example,
tcp.port.range=6000,6060
To set the port range using the system properties, set the org.globus.tcp.port.range property.
For example,
java -Dorg.globus.tcp.port.range="6000,6060" -classpath ...
Random Number Generation Issues
For security-related tasks, the Java CoG Kit tools and APIs must initialize a secure seed for the random number generator. On some platforms this may be a very computationally expensive process. However, the seed for the random number generator needs to be initialized only once per Java Virtual Machine instance. The Java CoG Kit can be configured to use an arbitrary SecureRandom implementation (which can be optimized for particular platform(s)) by adding the following properties into the <user-home>/.globus/cog.properties file:
random.provider=<Provider class> random.algorithm=<algorithm name>
For example, if you are using the ISNetworks implementation of SecureRandom, add the following into the <user-home>/.globus/cog.properties file:
random.provider=com.isnetworks.provider.random.InfiniteMonkeyProvider \newline random.algorithm=InfiniteMonkey
\LINK{SecureRandom Implementation by ISNetworks}{http://www.isnetworks.com/infinitemonkey/}
Of course, you must first install the provider correctly.
The next time you use a Java CoG Kit tool or library, the startup time should be faster on the platforms supported by the provider. For platforms not supported by the provider, the default seed generator will be used.
