Nimbus

DEPRECATED: The most recent version is Nimbus TP2.1

Plugins

The Workspace Factory Service create operation, can be configured with any authorization plugin written for GT4 and one such plugin is distributed here, the VOMS authorization modules (see the downloads section). The Python based plugin mentioned below is compatible with both VOMS and GridShib attribute based authorization if either is enabled to protect the factory service create operation.

The service itself can be configured with plugins, currently one for scheduling/resource management and one for deployment authorization. We distribute a Python based authorization plugin (see the downloads section) that allows an administrator to provide only a simple Python script to express complicated policies. A non-useful example Java authorization plugin is also available. The default scheduling/resource management plugin (Immediate) is distributed with and used by the service itself.

Authorization Overview

The default installation is configured with gridmap authorization, a DN access control list, that allows only clients in the gridmap file to call the factory create operation. The request is then validated and default values are filled in if not supplied by the client. If the request is invalid, it will be denied and a WorkspaceMetadataFault will be returned. If valid, the request is compared against the master policies configured in the factory and a violation will cause a WorkspaceResourceRequestDeniedFault to be returned.

Note: Once deployed, a workspace can be managed and inspected via Workspace Service operations. No matter what authorization scheme is in use, once a workspace is deployed it is protected by a DN access control list consisting of one DN that allows only the deployer to manage or inspect the workspace.

The VOMS and GridShib modules run before the Workspace Factory Service is ever invoked, just like the gridmap authorization:

As mentioned above there is a plugin interface for creation time authorization. All relevant information about the request is passed to the plugin including client identity and attributes (if available) as well as the workspace description and resource request. The callout to this plugin occurs after the validation process:

The supplied Python based plugin allows an administrator to configure a much richer policy than the factory policies allow for. For example, any arbitrary combination of resource allocation request (such as RAM), network settings, deployment duration, client DN, and client attributes can be taken into account.

This implementation of the authorization callout can present both VOMS credentials and SAML attributes (via GridShib) to the policy evaluation. But before they can be consulted, the "PIP" (Policy Information Point) portion of those modules must be configured. The PIP is what collects the attributes, the PDP (Policy Decision Point) is what enforces policy. This distinction is being mentioned because the PIP can be configured without the PDP in the VOMS and GridShib packages. Bear in mind that this might be an option if you are using the workspace authorization callout and want to handle all attribute policy there instead of before the factory service which is when the VOMS and GridShib modules are run. Thus, the PIP modules can collect the attributes about the client and then the detailed policy about those attributes can be expressed in the workspace creation time authorization callout.