about research toolkit development

Workspace Management Service

GT4

The Workspace Management Grid Services require the Globus Toolkit 4 (GT4) hosting environment. The GT4 hosting environment can be embedded in applications, deployed in Tomcat (Java only), or run in a standalone container.

Note: all subsequent Globus related directions assume that you are using the standalone container on Linux.

Recommended Installation:

The recommended installation procedure can be found for each version here. The Workspace Management Service is only compatible with GT4 releases 3.9.3 and later, these documents reflect version 3.9.4. Currently, the service is provided in Java and there are only system account implementations available for Unix/Linux systems.

Alternative Installation:

We provide a very brief guide for the Java core only meant for those already familiar with Globus Toolkit concepts and installation (but not necessarily GT4). This guide assumes you have your security infrastructure in place and assumes you have access to grid-proxy-init tools.

Download

The service code, three back-end implementations, and the VOMS parsing libraries (from the gLite cvs) can all be downloaded at once here:

$ wget http://www-unix.mcs.anl.gov/workspace/workspaceService_tech_preview_1.tgz
$ tar xvzf workspaceService_tech_preview_1.tgz
$ cd workspaceService
$ export WORKSPACE_HOME=`pwd`
$WORKSPACE_HOME has five subdirectories:
  • client - Java source code for the example client command line program.
  • common - WSDL files, Java stubs are generated directly from these.
  • docs - These HTML files.
  • local - Three separate programs for implementing dynamic Unix accounts.
  • service - Java source code for the Grid Services. Also, user editable files for deploy-time configurations.
dirs

Deploy the Workspace Service

Given a working GT4 installation, deploying the service to the container is just a matter of configuring the deployment information and running the ant build process.

1. Set GLOBUS_LOCATION:

$ export GLOBUS_LOCATION=/path/to/GL

2. Edit $WORKSPACE_HOME/service/java/source/deploy-jndi-config.xml

Parameter Description
DynamicAccountsFactoryService:host   Hostname advertised as factory resource property
DynamicAccountsFactoryService:defaultTtl   Default account time-to-live (in minutes)
DynamicAccountsService:resourceClass   Configures accounts implementation to use:
  - org.globus.dynamicAccounts.impl.service.LCMAPSResource
  - org.globus.dynamicAccounts.impl.service.PoolAccountsResource
  - org.globus.dynamicAccounts.impl.service.UnixAccountsResource

3. Stop service container

4. Deploy services

$ source $GLOBUS_LOCATION/etc/globus-devel-env.sh   (or .csh)
$ cd $WORKSPACE_HOME
$ ant deploy

5. Install appropriate system program to $GLOBUS_LOCATION/bin (see next section)

6. Add logging declaration to $GLOBUS_LOCATION/container-log4j.properties:

log4j.category.org.globus.dynamicAccounts=INFO

7. Start service container. The EPRs to use will be advertised:

Starting SOAP server at: http://host.org:8443/wsrf/services/ 
With the following services:

[1]: http://host.org:8443/wsrf/services/DynamicAccountsFactoryService
[2]: http://host.org:8443/wsrf/services/DynamicAccountsService

For interface description and usage examples, see the User's Guide.


Install the System Backend

A system administrator may want to configure accounts according to different policies. In order to support a range of possibilities offering different trade-offs in terms of control, flexibility and maintenance we currently provide three back-end implementations.

The "adduser" method calls directly a Unix command creating an account via a setuid process. After termination the account is destroyed such that no other user ever maps to this account. The advantage of this method is flexibility (a new account gets created on the fly) and also the fact that the same account is never "recycled" for another Grid identity which simplifies audit.

Although in principle such accounts could hit the naming limit, in practice this is very unlikely to happen. Also, this method ensures that there are only as many accounts at a given time as necessary. On the other hand, this method is likely to interfere with local account management systems and makes it hard for local administrators to exercise tight control over the account creation, configuration and termination.

For this reason, many site administrators prefer to use a pre-generated pool of accounts. Such accounts are created directly and configured by the site administrator in a site-specific way. The workspace service then creates a binding between a specific Grid entity and a new account taken from the pool. Account termination means that such binding (and all the access policies that it implies) is destroyed. While account termination may mean "clean up" (file deletion, etc.) it does not necessarily mean that an account is deleted. It may be quarantined and then restored to the pool in site-specific way to be used with a different Grid entity.

While this method allows the site administrator to closely control the process of account creation and termination, it has some limitations. The pre-generated account pool is finite. Statically allocating resources to these pre-generated accounts may mean that those resources will get allocated even if they are not immediately needed. And the possibility of mapping multiple identities to the same account complicates audit.

Installation


Authorization Scheme

Workspace creation and management is subject to authorization policies. This section explains how those policies are configured.

We support both push mode and pull mode authorization. The push mode assumes information carried in the credentials and is currently supported via the VOMS credentials (the support is extensible, see the developer's guide). Ordinary X509 credentials are naturallly accepted. The pull mode is configured via policy decision points (PDPs) calling out to access control lists (ACLs) as explained below. 

Creating workspaces: Factory Service Authorization Configurations

Operations on workspace factory are authorized via the  ACL mechanism. Entities can be authorized by DN or by attribute (in which case any DN with a specified attribute gets authorized). Two ACLs are used: one for DNs (consulted first) and one for attributes.

  1. Before service deployment (before you run "ant deploy") the DN ACL file can be found here:

    $WORKSPACE_HOME/service/java/source/etc/dn-authz

    After service deployment the file is deployed to:

    $GLOBUS_LOCATION/etc/dynamic_accounts_service/dn-authz

    The policy in this file can be modified after the service is deployed.

    Example of a DN ACL, one DN per line, no quotes:

    /DC=org/DC=doegrids/OU=People/CN=Timothy Freeman 964650
    /O=Grid/OU=GlobusTest/OU=simpleCA-prnb3/CN=TimF

  2. Before service deployment (before you run "ant deploy") the attribute ACL file can be found here:

    $WORKSPACE_HOME/service/java/source/etc/attr-authz

    After service deployment the file is deployed to:

    $GLOBUS_LOCATION/etc/dynamic_accounts_service/attr-authz

    As before, policy in this file can be modified after the service is deployed.

    Example, one attribute per line, no quotes:

    /EGEE/egee/manager
    /egtest/mytemp/Role=NULL/Capability=NULL

Authorizing Workspace Management

Currently the factory caller creating the account ("account owner")  is the only entity allowed to call the DynamicAccountsService operations on the account resource (i.e., manage the created account). This is DN only, certificate attributes are not considered part of the caller's identity.

Access policy to the accounts on system

At account creation time the client has the option to specify "access policies" for the created account. This policy is specified as a list of DNs.  In the future, this option is intended to enable the account owner to configure policy controlled access to the account. Since at this point we cannot effectively control access policy specifications, for now the use of this option is deprecated.

The enforcement of this access policy depends wholly on infrastructure using the workspace management service. These policies are exposed in the file configured under the "authzInfoFilename" option in deploy-jndi-config.xml. In addition, some of the backends (e.g., the adduser implmementation) attempt to configure things like a grid-mapfile or gridmapdir, but this is implementation specific.

We assume that for the time being the implied access policy is "account owner has access". The "account owner" DN is accessible via the DN property.