Introduction
Authorization. Users who run clients can programmatically set up the authorization scheme to be enforced on a per invocation basis. The properties and configuration information required depends on the configured authorization scheme.
Authentication & message-level security. Typical user configuration deals with configuring authentication mechanisms and credentials for the clients. These could be client applications, including command line clients or client configuration within services that contact other services. There are multiple mechanisms for doing this:
- Command line options (these are application-specific)
- Client security descriptors
- CoG properties
- Environment variables
- Relying on default behavior. The only default behaviors available concern the proxy file and trusted certificates locations.
More information on these mechanisms can be found in the public interface guide.
Table of Contents
The client side authorization can be configured for each invocation.
Security descriptors using files. Refer to Section 1, “Configuring Client Security Descriptor”, specifically Section 3, “Authorization policy”.
Security descriptors programmatically. Refer to Section 1, “Configuring Client Security Descriptor”
Properties on the Stub. Refer to Section 2.1, “Configuring client-side authorization on the stub”
To write and configure custom authorization mechanism refer to Section 2.2, “Writing custom client-side authorization scheme”.
If no authorization mechanism has been specified, HostOrSelf authorization is used. In this scheme host authorization is tried first, if it fails, self authorization is attempted
Table of Contents
Client-side security is set up by either setting individual
properties on the javax.xml.rpc.Stub
object used for the web service method invocation or by setting properties
on a client-side security descriptor object, which in turn is propagated
to client-side security handlers by making it available as a stub object
property. Here are examples of the two approaches:
Setting a property on the stub:
// Create endpoint reference EndpointReferenceType endpoint = new EndpointReferenceType(); // Set address of service String counterAddr = "http://localhost:8080/wsrf/services/CounterService"; // Get handle to port CounterPortType port = locator.getCounterPortTypePort(endpoint); // set client authorization to self ((Stub)port)._setProperty(Constants.AUTHORIZATION, SelfAuthorization.getInstance());Setting properties using a client descriptor:
// Client security descriptor file String CLIENT_DESC = "org/globus/wsrf/samples/counter/client/client-security-config.xml"; // Create endpoint reference EndpointReferenceType endpoint = new EndpointReferenceType(); // Set address of service String counterAddr = "http://localhost:8080/wsrf/services/CounterService"; // Get handle to port CounterPortType port = locator.getCounterPortTypePort(endpoint); //Set descriptor on Stub ((Stub)port)._setProperty(Constants.CLIENT_DESCRIPTOR_FILE, CLIENT_DESC);
The descriptor file is described in detail in Chapter 1, Introduction.
![[Note]](/docbook-images/note.gif) | Note |
|---|---|
If the client needs to use transport security, the following API
must be used to register the Axis transport handler for
import org.globus.axis.util.Util;
static {
Util.registerTransport();
}
|
Table 2.1. Client side security properties
| Number | Task | Stub Configuration | Descriptor Configuration |
| 1. | Allows for configuration of credentials for authentication. | Property: org.globus.axis.gsi.GSIConstants.GSI_CREDENTIALS Value equals the Instance of
| |
| 2. | Allows for configuring client-side authorization. | Property: org.globus.wsrf.security.Constants.AUTHORIZATION Value equals the Instance of
If GSI Secure Transport or GSI Secure Conversation is
used, the value should be an instance of
| Refer to Section 3, “Authorization policy” |
| 3. | Enable GSI Secure Conversation with specified message protection level. | 1. Property: org.globus.wsrf.security.Constants.GSI_SEC_CONV Values equal one of the following:
2. Property: org.globus.wsrf.security.Constants.GSI_SEC_CONV_SECREPLY_UNNECESSARY
If the value is set to Boolean.TRUE, the GSI Secure conversation protection is not required in the reply message. By default, if the request was secured with GSI Secure Conversation, the response is also required to have the same protection. 3. Property: You can set
the SOAP Actor of the GSI signed/encrypted SOAP message by using
the | |
| 4. | Sets the GSI delegation mode. Used for GSI
Secure Conversation only. If limited or full
delegation is chosen, then some form of client-side
authorization needs to be done (i.e client-side authorization
cannot be set to none). | Property: org.globus.axis.gsi.GSIConstants.GSI_MODE Value equals one of following:
| |
| 5. | Enables GSI Secure Transport with some protection level. | Property: org.globus.gsi.GSIConstants.GSI_TRANSPORT Values equal one of the following:
| |
| 6. | Enables anonymous authentication. This option only applies to GSI Secure Conversation and GSI Transport. | Property: org.globus.wsrf.security.Constants.GSI_ANONYMOUS Value equals one of following:
| Refer Section 4, “GSI Secure Conversation” and Section 6, “GSI Secure Transport” |
| 7. | Enable GSI Secure Message with specified message protection level. | 1. Property: org.globus.wsrf.security.Constants.GSI_SEC_MSG Values equal one of the following:
2. Property: org.globus.wsrf.security.Constants.GSI_SEC_MSG_SECREPLY_UNNECESSARY
If the value is set to Boolean.TRUE, the GSI Secure Message protection is not required in the reply message. By default, if the request was secured with GSI Secure Message, the response is also required to have the same protection. 3. Property: org.globus.wsrf.security.Constants.GSI_SEC_MSG_SINGLECERT
If the value is set to Boolean.TRUE, only a single certificate is used for the GSI Secure Message request. By default, the whole certificate chain is sent. 4. Property: You can set the SOAP Actor of the signed
message using the | |
| 8. | Enable WS-Security username/password authentication. | Properties: org.globus.wsrf.security.Constants.USERNAME Value equals the username. org.globus.wsrf.security.Constants.PASSWORD Value equals the password. | |
| 9. | Sets the credential that is used to encrypt the message (typically, the recipient's public key). Used for GSI Secure Message only. | Property: org.globus.wsrf.impl.security.authentication
.Constants.PEER_SUBJECT Value
equals the instance of
The credential object needs to be wrapped in
For example,
if Subject subject = new Subject();
X509Certificate serverCert =
CertUtil.loadCertificate(publicKeyFilename);
EncryptionCredentials encryptionCreds =
new EncryptionCredentials(
new X509Certificate[] { serverCert });
subject.getPublicCredentials().add(encryptionCreds);
stub._setProperty(Constants.PEER_SUBJECT, subject);
| |
| 10. | Sets the trusted certificates location. | Property: org.globus.wsrf.security.TRUSTED_CERTIFICATES Value should be a comma-separated list of directories and file names. | Refer Section 8, “Trusted credentials” |
| 11. | Sets the SAML Authorization Assertion to embed in SOAP Header. | Property: org.globus.wsrf.impl.security.authentication.Constants.SAML_AUTHZ_ASSERTION Value should be an instance of org.opensaml.SAMLAssertion. | Cannot be configured using descriptors. |
Table of Contents
The following information applies to Java WS Core and all services built on Java WS Core.
Java WS Core server side has two types of loggers. One logger is used for development logging and by default writes to standard out. The other logger includes system administration information and is CEDPs best practices compliant.
On client side, only developer logging is available and is configured using log4j.properties.
The following information applies to Java WS Core and those services built on it.
Logging in the Java WS Core is based on the Jakarta Commons Logging API. Commons Logging provides a consistent interface for instrumenting source code while at the same time allowing the user to plug-in a different logging implementation. Currently we use Log4j as a logging implementation. Log4j uses a separate configuration file to configure itself. Please see Log4j documentation for details on the configuration file format.
Server side logging can be configured in $GLOBUS_LOCATION/container-log4j.properties, when the container is stand alone container. For tomcat level logging, refer to Logging for Tomcat, . The logger log4j.appender.A1 is used for developer logging and by default writes output to the system output. By default it is set for all warnings in the Globus Toolkit package to be displayed.
Additional logging can be enabled for a package by adding a new line to the configuration file. Example:
#for debug level logging from org.globus.package.FooClass log4j.category.org.globus.package.name.FooClass=DEBUG #for warnings from org.some.warn.package log4j.category.org.some.warn.package=WARN
Client side logging can be configured in $GLOBUS_LOCATION/log4j.properties. The logger log4j.appender.A1 is used for developer logging and by default writes output to the system output. By default it is set for all warnings in the Globus Toolkit package to be displayed.
The specific logger to edit will be
log4j.logger.sysadmin in
$GLOBUS_LOCATION/container-log4j.properties. There
you can configure the following properties:
log4j.appender.infoCategory=org.apache.log4j.RollingFileAppender log4j.appender.infoCategory.Threshold=INFO log4j.appender.infoCategory.File=var/containerLog log4j.appender.infoCategory.MaxFileSize=10MB log4j.appender.infoCategory.MaxBackupIndex=2
Above implies the logging file is rolling with each file size
limited to 10MB and the logging information is stored in
$GLOBUS_LOCATION/var/containerLog.
The sample log file contains many log entries for various scenarios in the Java WS container.
Table of Contents
For a list of common errors in GT, see Error Codes.
For information about system administrator logs, see Chapter 7, Troubleshooting.
The following are some common problems that may cause clients or servers to report that credentials are invalid:
For a list of common errors in GT, see Error Codes.
Table 4.1. Credential Errors
| Error Code | Definition | Possible Solutions |
|---|---|---|
Your proxy credential may have expired | Your proxy credential may have expired. | Use grid-proxy-info to check whether the proxy credential has actually expired. If it has, generate a new proxy with grid-proxy-init. |
The system clock on either the local or remote system
is wrong. | This may cause the server or client to conclude that a credential has expired. | Check the system clocks on the local and remote system. |
Your end-user certificate may have
expired | Your end-user certificate may have expired | Use grid-cert-info to check your certificate's expiration date. If it has expired, follow your CA's procedures to get a new one. |
The permissions may be wrong on your proxy
file | If the permissions on your proxy file are too lax (for example, if others can read your proxy file), Globus Toolkit clients will not use that file to authenticate. | You can "fix" this problem by changing the permissions on
the file or by destroying it (with grid-proxy-destroy) and
creating a new one (with grid-proxy-init).
Important: However, it is still possible that someone else has made a copy of that file during the time that the permissions were wrong. In that case, they will be able to impersonate you until the proxy file expires or your permissions or end-user certificate are revoked, whichever happens first. |
The permissions may be wrong on your private key
file | If the permissions on your end user certificate private key file are too lax (for example, if others can read the file), grid-proxy-init will refuse to create a proxy certificate. | You can "fix" this by changing the permissions on the
private key file. Important: However, you will still have a much more serious problem: it is possible that someone has made a copy of your private key file. Although this file is encrypted, it is possible that someone will be able to decrypt the private key, at which point they will be able to impersonate you as long as your end user certificate is valid. You should contact your CA to have your end-user certificate revoked and get a new one. |
The remote system may not trust your
CA | The remote system may not trust your CA | Verify that the remote system is configured to trust the CA that issued your end-entity certificate. See Installing GT 4.2.1 for details. |
You may not trust the remote system's
CA | You may not trust the remote system's CA | Verify that your system is configured to trust the remote CA (or that your environment is set up to trust the remote CA). See Installing GT 4.2.1 for details. |
There may be something wrong with the remote
service's credentials | There may be something wrong with the remote service's credentials | It is sometimes difficult to distinguish between errors reported by the remote service regarding your credentials and errors reported by the client interface regarding the remote service's credentials. If you cannot find anything wrong with your credentials, check for the same conditions on the remote system (or ask a remote administrator to do so) . |
The grid-cert-diagnostics program checks prints diagnostics about the user's certificates, and host security environment.
%grid-cert-diagnostics-p
openssl verify -CApath /etc/grid-security/certificates -purpose sslclient ~/.globus/usercert.pem
openssl s_client -ssl3 -cert ~/.globus/usercert.pem -key
~/.globus/userkey.pem -CApath /etc/grid-security/certificates
-connect <host:port>Here <host:port> denotes the
server and port you connect to.
If it prints an error and puts you back at the command prompt, then it typically means that the server has closed the connection, i.e. that the server was not happy with the client's certificate and verification. Check the SSL log on the server.
If the command "hangs" then it has actually opened a telnet style (but secure) socket, and you can "talk" to the server.
You should be able to scroll up and see the subject names of the server's verification chain:
depth=2 /DC=net/DC=ES/O=ESnet/OU=Certificate Authorities/CN=ESnet Root CA 1
verify return:1
depth=1 /DC=org/DC=DOEGrids/OU=Certificate Authorities/CN=DOEGrids CA 1
verify return:1
depth=0 /DC=org/DC=doegrids/OU=Services/CN=wiggum.mcs.anl.gov
verify return:1
In this case, there were no errors. Errors would give you an extra line next to the subject name of the certificate that caused the error.
Table 4.2. Java WS A&A Errors
| Error Code | Definition | Possible Solutions |
|---|---|---|
[JWSSEC-248] Secure container requires valid
credentials | This error occurs when globus-start-container is run without any valid credentials. Either a proxy certificate or service/host certificate needs to be configured for the container to start up. |
|
Failed to start container: Container failed to
initialize [Caused by: [JWSSEC-250] Failed to load certificate/key
file] | This error occurs if the file path to the container certificate and key configured are invalid. |
|
Failed to start container: Container failed to
initialize [Caused by: [JWSSEC-249] Failed to load proxy
file] | This error occurs if container proxy file configured is invalid. |
|
Failed to start container: Container failed to
initialize [Caused by: [JWSSEC-245] Error parsing file:
"etc/globus_wsrf_core/ global_security_descriptor.xml" [Caused by:
...] | This error occurs if the container security descriptor configured is invalid. |
|
[JGLOBUS-77] Unknown CA | This error occurs if the CA certificate for the credentials being used is not installed correctly. |
|
P
S
- scheduler
Term used to describe a job scheduler mechanism to which GRAM interfaces. It is a networked system for submitting, controlling, and monitoring the workload of batch jobs in one or more computers. The jobs or tasks are scheduled for execution at a time chosen by the subsystem according to an available policy and availability of resources. Popular job schedulers include Portable Batch System (PBS), Platform LSF, and IBM LoadLeveler.