Software Links
Getting Started
- Doc Structure
- A Globus Primer
- Quickstart
- Installing GT
- Platform Notes
- Migrating from GT2
- Migrating from GT3
Reference
- PDF version
- Best Practices
- Coding Guidelines
- API docs
- Public Interfaces
- Resource Properties
- Samples
- Glossary
- Index
- Performance Studies
Common Runtime
Security
Data Mgt
Information Svcs
Execution Mgt
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.1.0:
Enhanced server-side attributed-based authorization framework: The server-side authorization framework has been reworked to support attribute based authorization with delegation of rights. The framework allows for configuring a chain of Policy Information Points(PIPs) and Policy Decision Points(PDPs) and a combining alogorithm that processes the individual decisions returned by the PDPs. Some of the key changes from the previous versions are:
Authorization framework uses a set of attributes to identify entities
The authorization engine uses Java Security provider framework to allow different combining algorithms to be plugged in.
A default implementation of permit override combining algorithm, which looks for a permit decision chain, to allow for fine grained delegation of rights.
Refer Architecture and Design Overview for detailed information on the architecture.
Host or Self Authoriation: Support for a pluggable PDP that does host authorization, and if that fails, tries self authorization.
The security descriptor framework, used to configure security properties for the security framework has been enhanced. Detailed information about the framework is provided Section 1, “Introduction”
Other Supported Features
- Authorization based on
grid-mapfileand other access control lists. - Ability to implement custom authorization modules.
- A SAML callout authorization module enables outsourcing of authorization decisions to an authorization service (e.g. PERMIS).
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 4.0.2
- Addition of the SAML authorization callout
API changes since GT 4.0.2
- None
Exception changes since GT 4.0.2
- None
Schema changes since GT 4.0.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.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.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.
A draft design document can be found at GT Authorization Framework
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.
Independent authorization settings can be configured on the server and client side. The security programming model on the server side is declarative and all configuration is done by setting a security descriptor. The descriptor can be a resource, service or container descriptor, depending on the required scope for the authorization. On the other hand, on the client side the configuration is done by setting required properties on the stub used to make the method invocation. The security properties, and hence the authorization settings, can be set directly as properties on the stub, or a client security descriptor that encapsulates the individual properties may be written and in turn passed to the framework via a property on the stub object.
Stable API
- org.globus.wsrf.security.Constants
- org.globus.wsrf.security.SecureResource
- org.globus.wsrf.security.SecurityManager
- org.globus.wsrf.security.authorization.PDP
- org.globus.wsrf.security.authorization.PIP
- org.globus.wsrf.security.authorization.ChainConfig
- org.globus.wsrf.security.authorization.Constants
- org.globus.wsrf.security.authorization.Interceptor
- org.globus.wsrf.security.impl.authorization.Authorization
Less stable API
- org.globus.wsrf.impl.security.descriptor.ClientSecurityDescriptor
- org.globus.wsrf.impl.security.descriptor.ServiceSecurityDescriptor
- org.globus.wsrf.impl.security.descriptor.ResourceSecurityDescriptor
Documentation for these interfaces can be found here.
The authorization framework as such does not have a WSDL interface. On the other hand one of the authorization scheme in the toolkit, a callout to an authorization service compliant with the specification published by the OGSA Authorization Working Group (OGSA-AuthZ) requires a WSDL interface for the service. The callout makes a query on the configured authorization service, which returns an authorization decision.
The authorization service takes a query as input and returns an authorization decision. The Security Assertion Markup Language (SAML) is used for expressing the query and the decision. If any fault occurs, it is embedded as a part of the decision. The decision can be a permit, deny or indeterminate.
SAMLRequest: Used to send queries to the authorization service, which after processing returns an authorization decision. All faults are embedded as part of the decision that is returned, i.e. no fault is declared at the WSDL level.GetResourceProperty: Gets the value of a specific resource property. This operation throws the following faults:- ResourceUnknownFault
- InvalidResourcePropertyQNameFault
SetResourceProperties: Sets the value for resource properties. This operation throws the following faults:- ResourceUnknownFault
- InvalidSetResourcePropertiesRequestContentFault
- UnableToModifyResourcePropertyFault
- InvalidResourcePropertyQNameFault
- SetResourcePropertyRequestFailedFault
QueryResourceProperties: Used for the querying of resource properties using a query expression. This operation throws the following faults:- ResourceUnknownFault
- InvalidResourcePropertyQNameFault
- UnknownQueryExpressionDialectFault
- InvalidQueryExpressionFault
- QueryEvaluationErrorFault
supportedPolicies: Contains identifiers for any or all access control policies that the authorization service is capable of rendering decisions regarding.supportsIndeterminate: Indicates whether the authorization service may return an "indeterminate" authorization decision. If set to flase, only permit or deny is returned.signatureCapable: Indicates if the authorization service is capable of signing the decision returned. If not, only unsigned decisions are returned.
On the client side the authorization configuration is set on the stub instance used for method invocation. Properties can be set directly on the stub or set using a client security descriptor.
If setting properties directly on the stub, the
org.globus.wsrf.impl.security.Constants.AUTHORIZATIONproperty must be set on the stub. The value of this property must be an instance of an object that implements theorg.globus.wsrf.impl.security.authorization.Authorizationinterface.// Create endpoint reference EndpointReferenceType endpoint = new EndpointReferenceType(); // Set address of service String counterAddr = "http://localhost:8080/wsrf/services/CounterService"; // Get handle to stub object CounterPortType port = locator.getCounterPortTypePort(endpoint); // set client authorization to self ((Stub)port)._setProperty(Constants.AUTHORIZATION, SelfAuthorization.getInstance());Setting properties using the client descriptor is described in Section 2.4, “Configuring Client Security Descriptor” and Section 8.2, “Configuring authorization mechanism ”
| Note |
|---|---|
If no authorization mechanism has been specified, host authorization is performed. |
The authorization framework can be configured at the resource, service or container level. Configuration settings are specified in security descriptors. The descriptors can be read from a file or can be created programmatically. Refer to Section 2, “Configuring security descriptors ” for more details.
Authorization configuration involves setting a chain of authorization schemes (also known as Policy Decision Points (PDPs)). When an authorization decision needs to be made the PDPs in the chain are evaluated in turn to arrive at a permit or deny decision. The combining rule for results from the individual PDPs is currently "deny overrides"; that is, all PDPs have to evaluate to permit for the chain to evaluate as permit.
This section describes a list of PIPs and PDPs that are distributed with the toolokit. Each of these modules can be plugged into the authorization framework using configuration.
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.
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 in Section 7, “Debugging”. 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 in Section 11.1, “Configuring Default GridMap Files” 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: