| ||||||||||||
Workspace Management ServiceGT4The 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. DownloadThe 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`
Deploy the Workspace ServiceGiven 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
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 BackendA 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. InstallationAuthorization SchemeWorkspace 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 ConfigurationsOperations 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.
Authorizing Workspace ManagementCurrently 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 systemAt 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.
|