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.

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.

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.

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