The Java security code currently does not enforce secure permissions and, implicitly, file ownership requirements on any of the security related files, e.g. configuration and credential files. It is thus important that administrators ensure that the relevant files have correct permissions and ownership. Permissions should generally be as restrictive as possible, i.e. private keys should be readable only by the file owner and other files should be writable by owner only, and the files should generally be owned by the globus user (the requirements that the C code enforces are documented in Section 8, “Configuration interface”).

Also refer to Section 5, “Known Problems” for details on any other open issues.

On the server side transport security is enabled by simply switching a non-secure socket implementation with the GSISocket implementation. In addition to this change some code was added to propagate authentication information and message protection settings to the relevant security handlers, in particular the authorization and security policy handlers.

On the client side transport security is similarly enabled by switching a non-secure socket implementation with the GSISocket implementation and registering a protocol handler for HTTPS that uses the secure socket implementation. In practice this means that any messages targeted at a HTTPS endpoint will, irregardless of any stub properties, be authenticated and protected. It also means that any messages sent to a HTTP endpoint will not be secured, again irregardless of any stub properties. Stub properties are only used to communicate the desired message protection level, i.e. either integrity only or integrity and privacy.

This section aims to describe the message flow and processing that occurs for a security-enabled service. The figure below shows the JAX-RPC handlers that are involved in security related message processing on a server.

Figure 1. The new certificate is signed by the owner, rather than a CA.

GT4 provides two mechanisms, GSI Secure Conversation and GSI Secure Message security, for authentication and secure communication.

In the GSI Secure Conversation approach the client establishes a context with the server before sending any data. This context serves to authenticate the client identity to the server and to establish a shared secret using a collocated GSI Secure Conversation Service. Once the context establishment is complete the client can securely invoke an operation on the service by signing or encrypting outgoing messages using the shared secret captured in the context.

The GSI Secure Message approach differs in that no context is established before invoking an operation. The client simply uses existing keying material, such as an X509 End Entity Certificate, to secure messages and authenticate itself to the service.

Securing of messages in the GSI Secure Conversation approach, i.e. using a shared secret, requires less computational effort than using existing keying material in the GSI Secure Message approach. This allows the client to trade off the extra step of establishing a context to enable more computationally efficient messages protection once that context has been established.

When a message arrives from the client the SOAP engine invokes several security related handlers.

The first of these handlers, the WS-Security handler, searches the message for any WS-Security headers. From these headers it extracts any keying material, which can be either in the form of an X509 certificate and associated certificate chain or a reference to a previously established secure conversation session. It also checks any signatures and/or decrypts elements in the SOAP body. The handler then populates a peer JAAS subject object with principals and any associated keying material whose veracity was ascertained during the signature checking or decryption step.

The next handler that gets invoked, the security policy handler, checks that incoming messages fulfill any security requirements the service may have. These requirements are specified, on a per-operation basis, as part of a security descriptor during service deployment. The security policy handler will also identify the correct JAAS subject to associate with the current thread of execution. Generally this means choosing between the peer subject populated by the WS-Security handler, the subject associated with the hosting environment and the subject associated with the service itself. The actual association is done by the pivot handler, a non-security handler not shown in the figure that handles the details of delivering the message to the service.

The security policy handler is followed by an authorization handler. This handler verifies that the principal established by the WS-Security handler is authorized to invoke the service. The type of authorization that is performed is specified as part of a deployment descriptor. More information can be found in there authorization framework documentation.

Once the message has passed the authorization handler it is finally handed off to the actual service for processing (discounting any non security related handlers, which are outside the scope of this document). Replies from the service back to the client are processed by two outbound handlers: the GSI Secure Conversation message handler and the GSI Secure Message handler. The GSI Secure Conversation message handler deals with encrypting and signing messages using a previously established security context, whereas the GSI Secure Message handler deals with messages by signing or encrypting the messages using X509 certificates. The operations that are actually performed depend on the message properties associated with the message by the inbound handlers, i.e. outbound messages will have the same security attributes as inbound messages. That being said, a service has the option of modifying the message properties if so desired. These handlers are identical to the client side handlers described in the following section.

This section describes the security related message processing for Java-based GT4 clients. In contrast to the server side, where security is specified via deployment descriptors, client side security configuration is handled by the application. This means that a client side application has to explicitly pass information to the client side handlers on what type of security to use. This is also true for the case of services acting as clients. The below figure shows the JAX-RPC handlers that are involved in security related message processing on a server.

Figure 2. JAX-RPC handlers involved in security related message processing on a server.

The client side application can specify the use of either the GSI Secure Conversation security approach or the GSI Secure Message security approach. It does this by setting a per message property that is processed by the client side security handlers.

There are three outbound client side security handlers:

The secure conversation service handler is only operational if GSI Secure Conversation mode is in use. It establishes a security session with a secure conversation service collocated with the service with which the client aims to communicate. When the client sends the initial message to the service with a property indicating that session based security is required, this handler intercepts the message and establishes a security session. It will also authorize the service by comparing the service's principal/subject obtained during session establishment with a value provided by the client application. Once the session has been established the handler passes on the original message for further processing.

The next handler in the chain, the secure message handler, is only operational if GSI Secure Message mode is in use. It signs and/or encrypts messages using X.509 credentials.

The third outbound handler is operational only if GSI Secure Conversation mode is in use. It handles signing and/or encryption of messages using a security session established by the first handler.

The client side inbound handler (the WS-Security client handler) deals with verifying and decrypting any signed and/or encrypted incoming messages. In the case of GSI Secure Message operation it will also authorize the remote side in a similar fashion to the outbound secure conversation service handler.

The security programming model differs between the client and server side. The client side model is programmatic in nature, i.e. security related code is driven by making actual function calls, whereas the server side model is declarative, i.e. security related settings are declared in a security descriptor. For more information on the available client side calls see Section 7, “Semantics and syntax of domain-specific interface”. More information about the security descriptor can be found in Java WS Security Descriptor Framework .

Documentation for these interfaces can be found here.

The framework implements the Web Services Security: SOAP Message Security, Web Services Security: Username Token Profile and Web Services Security: X.509 Token Profile specifications.

The transport security solution used by the framework consists of HTTP over SSL/TLS (HTTPS) using X.509 certificates. The path validation step has been augmented to support the Proxy Certificate Profile (RFC3820).

The framework implements the Web Services Security: SOAP Message Security, Web Services Security: Username Token Profile and Web Services Security: X.509 Token Profile specifications.

The transport security solution used by the framework consists of HTTP over SSL/TLS (HTTPS) using X.509 certificates. The path validation step has been augmented to support the Proxy Certificate Profile (RFC3820).

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 for the two approaches:

The descriptor file is described in detail in Section 1, “Security Descriptors Introduction”.

	Note
	If the client needs to use transport security, the following API must be used to register the Axis transport handler for "https": import org.globus.axis.util.Util; static { Util.registerTransport(); }

Configuration of service-side security settings can be achieved in two ways. The preferred way is to provide these settings in a security descriptor, although it is also possible to manipulate security settings via CoG properties.

Information on the syntax of security descriptors can be found in Java WS Security Descriptor Framework .

Information on available CoG security properties can be found Section 3.1, “Trusted Certificates Location”

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

Solutions:

This error occurs if the file path to the container certificate and key configured are invalid.

Solutions:

This error occurs if container proxy file configured is invalid.

Solutions:

This error occurs if the container security descriptor configured is invalid.

Solutions:

This error occurs if the CA certificate for the credentials being used is not installed correctly.

Solutions: