GT 4.1.0 WS AA Public Interfaces

1. Semantics and syntax of APIs

1.1. Programming Model Overview

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.

1.2. Component API

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

2. Semantics and syntax of the WSDL

2.1. SAML Authorization Callout

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.

2.2. Protocol overview

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.

2.3. Operations

  • 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

2.4. Resource properties

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

2.6. WSDL and Schema Definition

3. Semantics and syntax of non-WSDL protocols

[describe non-WSDL protocols. if none, state so.]

4. Command-line tools

There is no support for this type of interface.

5. Overview of Graphical User Interfaces

This component has no graphical user interfaces.

6. Semantics and syntax of domain-specific interface

6.1. Interface introduction

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.

6.2. Syntax of the interface

  • If setting properties directly on the stub, the org.globus.wsrf.impl.security.Constants.AUTHORIZATION property must be set on the stub. The value of this property must be an instance of an object that implements the org.globus.wsrf.impl.security.authorization.Authorization interface.

    // 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]Note

If no authorization mechanism has been specified, host authorization is performed.

7. Configuration interface

7.1. Configuration overview

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.

7.2. Syntax of the interface

Refer to Section 8.2, “Configuring authorization mechanism ”.

8. Environment variable interface

There is no support for this type of interface.

9. PIPs and PDPs

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.