VOMS

From Globus

Currently the VOMS authorization plugins do not have a logical home for their documentation, this page serves that purpose for the immediate future. To ask support questions please sign up for gt-user at http://dev.globus.org/wiki/Mailing_Lists

The current release is: 0.2 -- released Feb 15, 2007

The plugins are compatible with both the GT 4.0.x stable release and the GT 4.1 development release.

Instructions for download are below.

Contents

[edit]

Licenses

This plugin download includes a VOMS parsing library that is only available under the terms of this license. This library was generated from the gLite CVS.

The plugins themselves (all of the authorization logic and Globus interfaces that we distribute as the VOMS authorization modules) are licensed under the Apache 2.0 license.


[edit]

Overview

VOMS is a grid attribute system that allows a client to embed an attribute certificate in a well known certificate extension. Since the embedded attribute certificate is signed by a VOMS server, a VOMS enabled service can parse and verify this extra certificate and treat the data therein as extra information about the client to use in an authorization decision.

  • A VOMS server, typically a VO-specific service, contains information about a client (DN)
  • The VOMS server, when requested, will digitally sign an assertion stating that a particular DN has some particular attributes
  • A client may embed this in its own proxy certificate to "push" it to the service when accessing resources.
  • The service, trusting a particular set of VOMS servers for attribute information, can use the attributes to make authorization decisions
    • or even use attributes to affect application logic, for example the Dynamic Accounts service can use attributes to decide on what account pool to obtain the dynamic account for this particular client from.

Using a distributed attribute system relieves services of needing to know every detail about the connecting clients. You can even operate an entire grid without the need for access control lists (grid-mapfiles).

Another attribute system for Globus is GridShib which integrates SAML attributes, more widely used in industry and academia than VOMS attributes.

As of the 0.5.1 release, the GridShib authorization modules for GT support the simultaneous use of VOMS and SAML attributes (by optionally making a callout to the VOMS authorization modules described here).

For more information on GridShib and VOMS, see this section of the GridShib admin guide: http://gridshib.globus.org/docs/gridshib-gt-0.5.1/admin-index.html#VOMS

[edit]

Basic authorization flow

There are two modules, the PIP (policy information point) and the PDP (policy decision point).

The PIP collects and validates attributes from the client's certificate.

The PDP makes an authorization decision based on the collected attributes.

Abstracting out these two functions allows for more deployment flexibility. For example, you could use the PIP by itself to just collect the attributes and let your grid service decide by itself how to interpret them. An example from the Dynamic Accounts service's use of the VOMS modules: you can use the same PIP to collect information but protect different WSRF resources with different access policies by using a separate PDP for each resource.

[edit]

Administration needs

When you install the Globus VOMS modules to a particular Globus installation you are essentially just making Java libraries available to any service in that installation. In order to actually activate any authorization logic, the service configurations need to:

  • list the VOMS modules in the authorization section of the relevant security descriptor
  • include the VOMS module configurations, providing necessary per-module information (such as what VOMS servers to trust, full list is below)

Like all authorization modules for the Java container, they can be used to protect the container as a whole, particular services, or particular WSRF resources.

[edit]

Installation

There are two options, binary and source packages. To use the binary packages (GAR files), you need to choose the one that matches your Globus installation: GT4.0.x or GT4.1. Using the source package, the build.xml ant script will auto-sense your Globus version and install the appropriate modules.

[edit]

Binary installation

  1. Download the proper archive:
  2. Expand the tarball
  3. Make sure GLOBUS_LOCATION and ANT_HOME environment variables are set properly
  4. Run "globus-deploy-gar FILE" where "FILE" is the GAR to install
[edit]

Source installation

  1. Download the source tarball:
  2. Expand the tarball
  3. cd into the "globus_voms_interceptors_0.2" directory
  4. Make sure GLOBUS_LOCATION and ANT_HOME environment variables are set properly
  5. Run "ant deploy"


[edit]

Configuration

[edit]

Configuring the authorization chain

In this section we cover enabling the VOMS modules for a service only. Enabling the modules for the container as a whole is analagous. Enabling the modules for a particular WSRF resource requires programmatic intervention, see this GT authorization documentation and sample code such as the source code of the Dynamic Accounts service.

[edit]

GT4.0.x: Configuring the authorization chain

This example uses a random identifier "vomsPdp" as a way to differentiate instances (another service may be using the VOMS modules as well, and its configurations could be different).

Edit the service's security-config.xml file to look like this: 

<authz value="vomsPdp:org.globus.voms.PIP vomsPdp:org.globus.voms.PDP"/>

The configurations will go in the service's server-config.wsdd file.

[edit]

GT4.1: Configuring the authorization chain

This example also uses the random identifier "vomsPdp" (see above).

NOTE that the GT4.1 security descriptors include configurations in the security descriptor itself and not separately in the service's server-config.wsdd file. So this example will include configurations (which are explained separately below).

Edit the service's security-config.xml file to look similar to this: 

<authzChain>

  <pips>
    <interceptor name="vomsPip:org.globus.voms.PIP">
      <parameter>
        <param:nameValueParam>

          <param:parameter
                 name="vomsTrustStore"
                 value="/etc/grid-security/vomsdir/*"/>

        </param:nameValueParam>
      </parameter>
    </interceptor>
  </pips>
  
  <pdps>
    <interceptor name="vomsPdp:org.globus.voms.PDP">
      <parameter>
        <param:nameValueParam>

          <param:parameter
                 name="vomsAttrAuthzFile"
                 value="etc/globus_wsrf_core_samples_counter/voms-attr-authz"/>

          <param:parameter
                 name="vomsAttrMapFile"
                 value="etc/globus_wsrf_core_samples_counter/voms-attr-mappings"/>

        </param:nameValueParam>
      </parameter>
    </interceptor>
  </pdps>
  
</authzChain>
[edit]

Setting configuration parameters

There is no duplication of the module code for the GT4.0.x and GT4.1 versions of the interceptors. There are simply two GT-version-specific adapter classes that both point to the same code. And so the configurations for each version are exactly the same, they just reach the modules in different ways due to the authorization engine changes in GT4.1.

This table lists the configurations, the behaviors it affects, whether they are required or not, the default setting if the configuration is not specified, and a sample of a name/value pair.

Depending on which GT version you are using, this name/value pair will either be entered into the service's server.config.wsdd like so for GT4.0.x: 

<parameter name="vomsPdp-vomsTrustStore"
           value="/etc/grid-security/vomsdir/*"/>

Note that the extra "scope" tag (in the example, "vomsPdp") is included in the parameter's name with a dash between scope and parameter name.

Or when using GT 4.1, add parameters in the manner listed above in the authorization chain configuration section. Note that in GT4.1 syntax, the extra "scope" tag is NOT in the parameter name, it is listed just once in the enclosing interceptor configuration.


[edit]

PIP configuration parameters

Configuration Behavior Required? Default Sample
vomsTrustStore A directory with file glob. Tells the PIP which certificates to trust. No "/etc/grid-security/vomsdir/*.pem" name="sc1-vomsTrustStore" value="/some/vomsdir/*"
vomsValidate If true, triggers path validation on attribute certificate. No "false" name="sc1-vomsValidate" value="true"
vomsRefreshTime Time in milliseconds between scans of vomsTrustStore directory. No 0 name="sc1-vomsRefreshTime" value="30000"


[edit]

PDP configuration parameters

Configuration Behavior Required? Default Sample
vomsAttrAuthzFile Access control file listing attributes to accept. Can be a simple list of quoted attributes (one per line) or can be in grid-map syntax (user account mappings are ignored, see the vomsAttrMapFile configuration for user account mappings functionality). Path can be absolute or can be relative to (searched for in this order) 1. current working directory of container, 2. /etc/grid-security Yes (*) None name="sc2-vomsAttrAuthzFile" value="etc/aService/voms-authz"
vomsAttrMapFile File listing attributes and user account mappings. Must be in grid-map syntax (quoted attributes on left, user accounts on right with commas between multiple accounts). If this is not enabled, no mappings will be performed. Mappings of an attribute are only performed if the attribute is accepted via the authorization file. Note that since the vomsAttrAuthzFile can handle grid-map syntax (but ignore the mappings), you either use the same file for each (IF it is in grid-map syntax) or different ones. Attributes can be in the authorization file (vomsAttrAuthzFile) without having a mapping in this file (vomsAttrMapFile). Path can be absolute or can be relative to (searched for in this order) 1. current working directory of container, 2. /etc/grid-security No None name="sc2-vomsAttrMapFile" value="etc/aService/voms-attrMap"
vomsConsultGridmap If true, the container's default grid-mapfile is consulted before looking at attributes. If there is a PERMIT from the grid-mapfile, the attributes are not consulted. Note that in GT4.1 you can simply configure a gridmap PDP to run before the VOMS PDP to get the same behavior. This functionality is present here because in GT4.0.x running a gridmap PDP before the VOMS PDP would not work in the same way. They would be combined in an AND fashion not an OR fashion. i.e., a DENY from the gridmap PDP would always result in an overall DENY. (Also, see the vomsPDPAndLogic configuration, you can optionally choose to use AND logic internally in the VOMS PDP, this was a requested feature) No "false" name="sc2-vomsConsultGridmap" value="true"
vomsPDPAndLogic If true, the DN and attribute access control policies are taken together in an "AND" fashion (see the vomsConsultDefaultGridmap configuration above for more discussion on this). That is, the client's DN needs to be in the grid-mapfile and its attribute needs to be in the attribute access control list (attrAuthzConfigFile). No "false" name="sc2-vomsPDPAndLogic" value="true"
vomsPDPPolicy Programmatic use only. This configuration points to an instantiated VomsPDPPolicy object (that has already been loaded with a policy). This lets you programmatically decide on attribute policies, for example to protect particular WSRF resources with particular attribute policies. No null (Not applicable)

(*) - unless you want to disable attribute based authorization entirely or you are instantiating PDP programmatically with an in-memory policy

[edit]

vomsAttrAuthzFile example 

"/SOMEVO/SomeAttribute/Role=Manager/Capability=NULL"
"/SOMEVO/Role=NULL/Capability=NULL"
"/SOMEVO/SomeOtherAttribute/Role=Developer/Capability=NULL"
[edit]

vomsAttrAuthzFile example 2 

"/SOMEVO/SomeAttribute/Role=Manager/Capability=NULL" frank, bob
"/SOMEVO/Role=NULL/Capability=NULL" joe
"/SOMEVO/SomeOtherAttribute/Role=Developer/Capability=NULL"
[edit]

vomsAttrMapFile example

(mappings required here) 

"/SOMEVO/SomeAttribute/Role=Manager/Capability=NULL" frank, bob
"/SOMEVO/Role=NULL/Capability=NULL" joe
"/SOMEVO/SomeOtherAttribute/Role=Developer/Capability=NULL" billy


Multiple account mappings are supported, this can be used with GRAM for example. GRAM provides a localUserId element to pick the account mapping from the list of authorized accounts. See this section of the GRAM documentation for more information.

[edit]

Using mappings with GRAM

If using VOMS username mappings with GRAM without a gridmap PDP in its authorization chain, you must make sure the sudoers policy is correct. The typical GRAM entry in the sudoers policy looks like so: 

globus ALL=(billy) NOPASSWD: /globuslocation/libexec/globus-gridmap-and-execute -g \
/etc/grid-security/grid-mapfile /globuslocation/libexec/globus-job-manager-script.pl *

The call to "globus-gridmap-and-execute -g /path/to/grid-mapfile" should be removed from the line (or a separate copy of the line added that excludes this). When GRAM detects that gridmap authorization is not being used it omits these arguments. Thus, the original sudo policy would fail unless the arguments were removed. This is a working entry: 

globus ALL=(billy) NOPASSWD: /globuslocation/libexec/globus-job-manager-script.pl *

For more information about GRAM and sudo, see the Configuring Sudo section of the GRAM documentation.

[edit]

Troubleshooting

1. Error parsing file: "...security-config.xml" [Caused by: The prefix "param" for element "param:nameValueParam" is not bound.

  • This error is encountered when using GT4.1. It means you have not added the proper namespaces to the security-config.xml file.
  • Solution: make sure the beginning of security-config.xml looks like so: 
<serviceSecurityConfig
        xmlns="http://www.globus.org/security/descriptor/service"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.globus.org/security/descriptor name_value_type.xsd"
        xmlns:param="http://www.globus.org/security/descriptor">
Retrieved from "http://dev.globus.org/wiki/VOMS"
Personal tools
Execution Projects
Information projects
Distribution Projects
Documentation Projects
Deprecated