The toolkit by default is deployed with our implementation of transport security, which is based on HTTP over SSL, also known as HTTPS, with modifications to path validation to enable X.509 Proxy Certificate support. In contrast to the GT3 version of the toolkit, the default transport security enabled in the toolkit does not support delegation of proxy certificates as part of the security handshake.

However, the underlying security libraries and handlers required for secure transport with delegation, also known as HTTPG, is still supported and shipped as part of the CoG library. The GT4 Java WS code base and configuration can be modified to use the HTTPG protocol as required.

Transport security is implemented by layering on top of the GSISocket class provided in JGlobus. This class deals with the security-related aspects of connection establishment as well as message protection. The socket interface serves as an abstraction layer that allows the HTTP protocol handling code to be unaware of the underlying security properties of the connection.

Container-level credentials are required and, irrespective of security settings on the service being accessed, these credentials are used for the handshake.

1.1.1. Server-Side Security

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.

1.1.2. Client-Side Security

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 an HTTPS endpoint will, irregardless of any stub properties, be authenticated and protected. It also means that any messages sent to an 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.

1.2. Message Level Security

1.2.1. Server Side Security

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.

1.2.2. Message Processing

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 the 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.

1.2.3. Client Side Security

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 must 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.

1.2.4. Message Processing

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 [fixme - is there a name?] 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 the GSI Secure Message operation, it will also authorize the remote side in a similar fashion to the outbound secure conversation service handler.

2. Authorization architecture

2.1. Server-side authorization

The Java WS Authorization framework leverages the generic GT Java Authorization Framework. The framework consists of an engine that evaluates a chain of configured authorization schemes, also known as Policy Decision Points (PDPs), to determine if the client making the invocation can access the resource/service. The chain can also be configured with Policy Information Points (PIPs), which can be used to glean information that would be useful in the decision making process.

A subset of PIPs that collect information only about the request i.e. the peer subject, requested action and resource, are called Bootstrap PIP. Typically these PIPs are run first in the authorization evaluation process, to build the request context.

The framework enables attribute-based authorization. PIPs can be used to collect attributes about resource/operations/subjects and used in the decision making process. While the toolkit provides some implementations of PIPs/PDPs, the framework is pluggable and custom mechanisms can be written and configured.

An authorization engine consists of PIPs, PDPs and a combining algorithm. The configured authorization engine is invoked as part of a handler chain, immediately after authentication of the invocation (java:org.globus.wsrf.impl.security.authorization.AuthorizationHandler). If no security mechanism is used for an operation, authorization is not done for that operation.

The architecture of Generic Java Authorization Engine is described in detail in this document. It also describes interfaces and writing custom PDPs/PIPs.

Any PDP has to implement the interface org.globus.security.authorization.PDP and contain the logic to return a permit or deny based on information such as the subject DN, the service being accessed and the operation being performed. To manage configuration information, each PDP can be bootstrapped with an object implementing the org.globus.security.authorization.ChainConfig interface. The interface has get and set methods which can be used to retrieve and set scoped parameters for the PDP.

PIPs have to implement the interface org.globus.security.authorization.PIP with the functionality to collect attributes from the invocation context that are relevant to making the authorization decision.

2.1.1. Authorization Policy Configuration

A chain of PDPs and PIPs, with relevant configuration information, can be configured at resource, service or container level. These chain use Permit Override with Delegation as default combining algorithm. Additionally an administrative policy can be configured at the container level. The administrative chain uses First Applicable combining algorithm by default. Note that comining algorithms can be configured to over-ride the deafult. The following describes the precedence in which configured policy is used:

If container level administrative policy is specified, it is evaluated.
1. If (1) returns a deny, the request is denied.
2. If (1) returns a permit, step (2) is done.
If resource level policy is specified, it is evaluated.
1. If (2) returns a deny, the request is denied.
2. If (2) returns a permit, the request is permitted.
If (2) is not specified and service level policy is specified, it is evaluated.
1. If (3) returns a deny, the request is denied.
2. If (3) returns a permit, the request is permitted.
If (3) is not specified and container level policy configuration is specified, it is evalauted.
1. If (4) returns a deny, the request is denied.
2. If (4) returns a permit, the request is permitted.

2.1.2. Authorization Handler Steps

Invoke Container PIP to collect attributes inherent to the framework. The PIP creates an instance of RequestEntities class to use as parameter with PIPs. It also creates an instance of ResourceChainConfig class to push the current message context as a parameter to ContianerPIP.
Evaluate the administrator authorization engine, if one is configured
1. If bootstrap overwrite is configured, then only BootstrapPIPs in administrator engine is invoked. Else the X509 Bootstrap PIP is invoked prior to any other Bootstrap PIPs configured.
2. The authorization engine is run and if a deny decision is returned, the operation is denied. If a permit decision is returned, the operation is permitted. If a not applicable or indeterminate is returned, further authorization engines are evaluated.
Evaluate the authorization engine configured in the resource, service, container, in that order depending on which is configured
1. If bootstrap overwrite is configured, then only BootstrapPIPs in administrator engine is invoked. Else the X509 Bootstrap PIP is invoked prior to any other Bootstrap PIPs configured.
2. If any decision other than a Permit is returned, the operation is denied. If a permit is returned the operation is allowed.
If no authorization engine was configured, then default authorization engine is created, which checks whether the caller has same credentials as service (self authorization)

2.2. Client-side authorization

Client side authorization is done as a part of the authentication handler. GSI Secure Message authentication does client-side authorization only after the operation is completed. This is done as a part of the web services client handler. The other two authentication schemes supported, GSI Secure Conversation and GSI Transport, authorize the server during the handshake, prior to the operation invocation.

The Transport Level Security protocol allows for authorization (an expected DN comparison) during the handshake. This is disabled by default in the toolkit, unless delegation of credential is requested. If no delegation is requested, the configured authorization mechanism is invoked afer the handshake is complete, prior to the operation invocation. If delegation is requested, authorization (expected DN comparison) is done during key exchange as a part of the protocol.

The toolkit supports self, gridmap, host and identity authorization on the client side. The authorization to be used is set programmatically on the Stub and the handler enforces it.

Prev		Next
Tutorials	Home	APIs