Table of Contents
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.PDPConfig
- org.globus.wsrf.security.authorization.PDPConstants
- 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:SetResourceProperties: Sets the value for resource properties. This operation throws the following faults:QueryResourceProperties: Used for the querying of resource properties using a query expression. This operation throws the following faults:
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 server side the authorization configuration is configured using security descriptors, either programmatically or using files. Refer to Section 3.5, “Configuring authorization mechanisms” and Section 3.6, “Writing a custom authorization mechanism” for detailed documentation.
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. The next section discusses setting property directly on stub and writing custom authorization schemes, while Section 4.2, “Configuring authorization mechanism ” describes using clients side security descriptors to configure a distributed authorization schema.
The following client side authorization schemes are distributed as a part of the toolkit: no authorization, self authorization, host authorization and identity authorization.
If setting properties directly on the stub, there are two properties that maybe used, based on that authentication scheme used.
If GSI Secure Transport or GSI Secure Conversation is used, the
org.globus.axis.gsi.GSIConstants.GSI_AUTHORIZATIONproperty must be set on the stub. The value of this property must be an instance of an object that extends fromorg.globus.gsi.gssapi.auth.GSSAuthorization. All distributed authorization schemes have implementation inorg.globus.gsi.gssapi.authpackage.For all other authentication schemes, 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.Example:
// 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 Configuring Client Security Descriptor and Section 4.2, “Configuring authorization mechanism ”
Other than the distributed client authorization scheme, custom client-side authorization schemes can be written and can be set as value for appropriate property on the stub.
![[Note]](../../../../../docbook-images/note.gif) | Note |
|---|---|
Security descriptors cannot be used to configure custom authorization schemes on client side. |
If the authentication scheme to be used is GSI Secure Transport or GSI Secure Conversation, the custom authorization scheme should extend from extends from
org.globus.gsi.gssapi.auth.GSSAuthorization.public class TestAuthorization extends GSSAuthorization { // Provide some way to instantiate this class. Can use constructor // with arguments to pass in parameters. public TestAuthorization() { } public GSSName getExpectedName(GSSCredential cred, String host) throws GSSException { // Return the expected GSSName of the remote entity. } public void authorize(GSSContext context, String host) throws AuthorizationException { // Perform the authorization steps. // context.getSrcName() provides the local GSSName // context.getTargName() provides the remote GSSName // if authorization fails, throw AuthorizationException } }The following describes the steps done for client side authorization during context establishment:
Prior to initialization of context establishment the relevant handler (HTTPSSender in case of GSI Secure Transport or SecContextHandler in case of GSI Secure Conversation), invokes getExpectedName on the instance of GSSAuthorization set on the Stub.
During context establishment, if the expected target name from previous step is not null, it is compared with the remote peer's GSSName. If it is not a match, context establishment is abandoned and an error is thrown.
If the expected target name is null, then a match is not done, unless the option of delegation is used. That is, if GSI Secure Conversation with delegation is used, then the expected target name cannot be null and must match the remote peer's identity.
Once the context has been established, the authorize method is invoked.
Note Client authorization is done prior to invocation.
To configure the custom authorization scheme:
((Stub)port)._setProperty(GSIConstants.GSI_AUTHORIZATION, new TestAuthorization());Various authorization scheme implementations in package
org.globus.gsi.gssapi.authwould serve as examples. View CVS LinkFor all authentication schemes other than GSI Secure Transport, 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.public class TestAuthorization implements Authorization { // Provide some way to instantiate this class. Can use constructor // with arguments to pass in parameters. public TestAuthorization() { } public GSSName getName(MessageContext ctx) throws GSSException { // Return the expected GSSName of the remote entity. } void authorize(Subject peerSubject, MessageContext context) throws AuthorizationException { // Perform the authorization steps. // peerSubject provides the remote Subject // Use SecurityManager API to get local Subject // if authorization fails, throw AuthorizationException } }The following describes the steps done for client side authorization:
The client side handler WSSecurityClientHandler, invokes authorize method on the authorization instance.
Note Client authorization is done after the invocation.
To configure the custom authorization scheme:
((Stub)port)._setProperty(Constants.AUTHORIZATION, new TestAuthorization());Various authorization scheme implementations in package
org.globus.wsrf.impl.security.authorizationwould serve as examples. ViewCVS Link.
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 Configuring Client Security Descriptor 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.