LCAS

The Local Centre Authorization Service. This component makes binary ('yes' or 'no') authorization decisions at the site and resource level. In making this decision, it can use a variety of inputs: the 'grid' name of the user (the Subject Distinguished Name), any VO attributes the user has (like VOMS (https://twiki.cnaf.infn.it/cgi-bin/twiki/view/VOMS) FQANs), the name of the executable the user intends to execute. It supports basic black and white list functionality, but also more complex VOMS-based expressions, based on the GACL (http://www.gridpp.ac.uk/authz/gacl/) language.

High level description

the set of Attributes associates therewith, and on the incoming service request. It is implemented as a program library that provides a modular pluggable framework wherein policy modules implemented as shared objects can be used to evaluate incoming assertions and return a boolean access decision. LCAS combines these individual decisions using a boolean AND to reach an overall access decision. The LCAS library invocation returns this decision to the invoking program for enforcement. The native interface to the LCAS system takes as input the target user’s credential chain and a string containing the Resource Specification Language (RSL) for the job. The authorization decision is returned to the application via the return code of the library call. Since in practice there is no standard way to represent the requested action, passing RSL is only used in a limited number of cases. In the case of gLExec, an RSL string is explicitly constructed based on the executable name to allow decisions to be made thereon. A basic set of policy modules is provided with the LCAS system that implement the following decision policies:

• White and black listing based on grid identity
• Grant or deny access based on both grid identity and VOMS attributes, as expressed in

the GACL policy language. This requires that the incoming assertions are appropriately signed by the VOMS attribute authority, whose trust anchor is available to the policy module.

• Access based on current local calender time
• Access based on the target executable to be executed. The LCAS interface specifies that

a resource specification language (RSL) string be used to express the executable, and gLExec will construct the appropriate RSL equivalent string for the command to be executed. These modules can be combined selectively and in any order. Evaluation will stop once all policy modules have been evaluated or a negative access decision has been reached. The LCAS system uses a configuration file that contains the module definitions and order in which to execute the modules.This configuration file has to be accessible by a standard open(2) call, i.e., on a POSIX-style file system.

User Guide

The configuration file, /opt/glite/etc/lcas/lcas.db by default, contains the list of plugins to be executed. A positive 'allow' decision is only reached if all modules allow the user (it's a simple logical AND). An example configuration file might be

# LCAS database/plugin list
#
# Format of each line:
# pluginname="<name/path of plugin>", pluginargs="<arguments>"
#
pluginname=lcas_userban.mod,pluginargs=ban_users.db
pluginname=lcas_voms.mod,pluginargs="-vomsdir /etc/grid-security/vomsdir/ -certdir /etc/grid-security/certificates/ -authfile /etc/grid-security/grid-mapfile -authformat simple -use_user_dn"

When used with a service that can provide arguments to LCAS, the location of the file can be changes. Otherwise, the build-in default must be used (for example in the GT4 callout). Others, like gLExec, can make the configuration for LCAS explicit:

lcas_db_file                 = /opt/glite/etc/lcas/lcas-glexec.db
lcas_log_file                = /var/log/glexec/lcas_lcmaps.log
lcas_debug_level             = 0
lcas_log_level               = 1

If you want to use LCAS with GT4, use the AuthZ call out, configured in /etc/grid-security/gsi-authz.conf:

globus_mapping /opt/glite/lib/liblcas_lcmaps_gt4_mapping_gcc32.so lcmaps_callout

Plug in modules

userallow.mod

userban.mod

voms.mod

timeslots.mod

the most useless plugin ever

check_executable.mod

restrict the user in the programs that can be invoked

Installation

LCAS is usually (dynamically) linked to your service or application. It is shipped by default with all gLite versions, but can also be installed from the etics repository. On a, say, GT4 gatekeeper node, or a GT GridFTP server, you might find:

glite-security-lcas-1.3.7-2.slc4
glite-security-lcas-interface-1.3.6-3.slc4
glite-security-lcas-lcmaps-gt4-interface-0.0.14-2.slc4
glite-security-lcas-plugins-basic-1.3.2-3.slc4
glite-security-lcas-plugins-check-executable-1.2.1-3.slc4
glite-security-lcas-plugins-voms-1.3.4-5.slc4

Developer Guide

The details of most modules (except check-executable) are available here.