Table of Contents
The authorization framework enforces the configured authorization policy on the service and client side. The framework allows developers to configure a chain of authorization mechanisms either programmatically or declaratively using security descriptors. It also allows for plugging in new authorization schemes (in addition to using those that are provided with the framework). Moreover, the framework allows for this configuration to be done at resource, service or container level, each taking precedence in the order specified and scoped as the name suggests.
Features new in GT 4.0
- A SAML callout authorization module enables outsourcing of authorization decisions to an authorization service (e.g. PERMIS).
Other Supported Features
- Authorization based on
grid-mapfileand other access control lists. - Ability to implement custom authorization modules.
Deprecated Features
- None
Tested Platforms for WS Authorization Framework:
- Linux (Red Hat 7.3)
- Windows 2000
- Solaris 9
Protocol changes in the Authorization Framework since GT 3.2
- Addition of the SAML authorization callout
API changes since GT 3.2
- None
Exception changes since GT 3.2
- None
Schema changes since GT 3.2
- None
The WS Authentication and Authorization component depends on the following GT components:
- WS Authentication and Authorization Message-Level Security
The WS Authentication and Authorization component depends on the following 3rd party software:
- OpenSAML
Client authorization of the server is done after the completion of the operation when GSI Secure Message authentication is used. If you require client authorization to be done prior, use GSI Secure Conversation or GSI Transport security.
During host authorization, the toolkit treats DNs "hostname-*.edu" as equivalent to "hostname.edu". This means that if a service was setup to do host authorization and hence accept the certificate "hostname.edu", it would also accept certificates with DNs "hostname-*.edu".
The feature is in place to allow a multi-homed host folowing a "hostname-interface" naming convention, to have a single host certificate. For example, host "grid.test.edu" would also accept likes of "grid-1.test.edu" or "grid-foo.test.edu".
![[Note]](../../../../../docbook-images/note.gif) | Note |
|---|---|
The wildcard character "*" matches only name of the hostand not domain components. This means that "hostname.edu" will not match "hostname-foo.sub.edu", but will match "host-foo.edu". |
| Note |
|---|---|
If a host was set up to accept "hostname-1.edu", it will not accept any of "hostname-*.edu". |
A bug has been opened to see if this feature needs to be modfiied.
The authorization framework on the server side 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 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 toolkit contains a set of PDPs that implement some authorization schemes or callout to some authorization services. Custom PDPs and PIPs can be written and plugged in as a part of the chain.
Any PDP has to implement the interface org.globus.wsrf.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.wsrf.security.authorization.PDPConfig 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.wsrf.security.authorization.PIP with the functionality to collect attributes from the invocation context that are relevant to making the authorization decision.
A chain of PDPs and PIPs, with relevant configuration information, can be configured at resource, service or container level. If no chain is specified at resource level, service level is used; if nothing is specified at service level, the container level configuration is used. The engine evaluates each PDP and PIP in the order specified and a deny-override mechanism is used to render a decision. If one PDP returns a deny, the decision rendered is deny.
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. The other two authentication schemes supported, GSI Secure Conversation and GSI Transport, authorize the server prior to the operation. 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.
The semantics and syntax of the APIs and WSDL for the component, along with descriptions of domain-specific structured interface data, can be found in the public interface guide.
Configuring authorization information can be done using a programmatic interface and is described in detail in these two sections of the Security Descriptor document: Programmatic altering of descriptors and Resource Security Descriptor.
If the authorization framework is set on either the service or container level and is using one of the schemes that are distributed with the toolkit, it is recommended that declarative configuration using security descriptor files be used.
- Article titled "Authorization processing for Globus Toolkit Java Web services" published at IBM Developer Works provides an overview of the GT4 Web Services Authorization options, architecture and custom authorization approaches.
Log output from the authorization framework is a useful tool for debugging issues. Logging in the code is based on the Jakarta Commons Logging API and is described in more detail here. As described in the above section, configuration files need to be edited to enable logging at different levels. For example, to see all logging for server side authorization, the following lines need to be added to container logging configuration file. To see client-side authorization framework logging, the same line needs to be added to $GLOBUS_LOCATION/log4j.properties.
log4j.category.org.globus.wsrf.impl.security.authorization=DEBUG
The authorization module uses Java CoG Kit for some of the functionality. To turn on logging for that functionality, the following can be added to the relevant logging file, depending on whether it is the client or the server side logging.
log4j.category.org.globus.gsi.jaas=DEBUG log4j.category.org.globus.gsi.gssapi=DEBUG log4j.category.org.globus.security.gridmap=DEBUG
Check to ensure that a grid map file name is configured as shown here and that the security descriptor with grid map file information is configured correctly.
If an anonymous client is used, only some authorization schemes can authorize them. Self authorization, identity authorization, gridmap authorization and host authorization will fail if anonymous clients are used. Ensure that an appropriate authorization scheme is used if anonymous clients are allowed.
This error can occur on the client side if the authorization instance set on the stub does not implement interface org.globus.ogsa.impl.security.authorization.Authorization. A common error is importing authorization classes from org.globus.gsi.gssapi.auth rather than from org.globus.ogsa.impl.security.authorization. It is recommended that client security descriptors be used to set these properties, so the right classes and properties are setup by the framework.
Associated standards for WS Authentication and Authorization Framework: