Globus Toolkit Mapping and Authorization Callouts to Python

Introduction

Globus Toolkit provides various callout mechanisms to enable a site to implement a local/custom policy for mapping user DNs to local user accounts and for making authorization decisions. This document describes the API for a mapping and authorization callout to Python from within specific components of Globus Toolkit 5.x that use Gridmap authorization callouts (described later). An example implementation of the callout to Python is also provided so that a system administrator can modify the Python script to implement a site-specific identity mapping and authorization policy instead of writing and compiling a new C callout shared library.

Background

Globus Toolkit provides the following identity mapping and authorization mechanisms:

1. Gridmap file-based mapping and authorization (default/standard)

2. Gridmap callouts

3. Supplemental callouts

3.1 GRAM callout

3.2 GridFTP CAS authorization callouts

The following matrix shows the various Globus Toolkit components and the mapping and authorization mechanisms they use.

Gridmap File-based Authorization (default)

As mentioned at this Globus page:

VDT uses this callout mechanism for GRAM/Gatekeeper and GridFTP (and GSI-OpenSSH?) to call out to PRIMA which then contacts a GUMS server to perform mapping and authorization functions.

More information on PRIMA and its use in VDT can be found at:

http://vdt.cs.wisc.edu/components/prima.html

http://computing.fnal.gov/docs/products/voprivilege/swarchive/privilege/documentation/architecture-v4.gif

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108.4921&rep=rep1&type=pdf

An implementation of the PRIMA called-out module (prima_authz_module-0.3) can be found in the source code tar ball mentioned on:

http://computing.fnal.gov/docs/products/voprivilege/prima/prima.html

Miscellaneous Callouts

There are certain application specific callouts made by specific individual components such as the GRAM job manager and GridFTP/CAS.

A description and an example implementation of the GRAM callout is available at:

http://www.globus.org/toolkit/security/callouts/

GridFTP CAS authorization callouts are implemented using GAA (Generic Authentication and Access Control). Community Authorization Service (CAS) is defined at: http://www.globus.org/alliance/publications/papers/CAS_2002_Revised.pdf

The CAS module is loaded into GridFTP using GridFTP's ACL plug-in mechanism. The CAS module then makes specific callouts, which in turn use the GAA mechanism for an authorization decision.

Details on setting up GridFTP with CAS can be found at:

http://www.globus.org/toolkit/docs/4.2/4.2.0/security/cas/admin/cas-howto-gridftp.html#cas-howto-gridftp-overview

A couple of implementations of these callouts are available at:

http://viewcvs.globus.org/viewcvs.cgi/gsi/authz_gaa_callout/

http://viewcvs.globus.org/viewcvs.cgi/gsi/authz_null_callout/

Gridmap callout to Python

Overview

This section describes a way for the Globus Toolkit components that use Gridmap callouts to ultimately call into Python. The idea behind calling out into Python is so that a system administrator can modify the Python script to implement a site-specific identity mapping and authorization policy without having to write and compile a C callout shared library.

The callout to Python is implemented by embedding Python in a C callout library which is typically a shared library. When the callout into the C callout library happens as depicted in the picture in the section Gridmap Callouts above, the callout function invokes functions in the Python shared library so as to embed Python into C. The Python script gridmap_authz.py is then loaded and the Python map_and_authorize function invoked, all via the C Python library. It is important to note that the callout type globus_mapping is used here to perform authorization decisions as well as identity mapping.

In the attachments section at the bottom of this page is a tar file containing an example implementation of a C callout embedding Python. The python script included in the tar ball performs the following:

• Map the user DN to a local identity and check to see if it can be the desired identity
• Enforce requirement for minimum proxy certificate lifetimes
• Enforce access control based on (LDAP/Unix) group membership (are you a member of a UNIX group?)

It is expected that a site can modify the Python script to implement a local/custom policy for identity mapping and authorization.

API

The python script gridmap_authz.py has the function map_and_authorize defined. The map_and_authorize function is invoked with the following arguments:

cert_chain - A list of certificates (DER encoded) in the certificate chain presented by the peer.

peer_dn - A string representing the peer user's Distinguished Name.

service - A string representing the name of the service such as "ssh" for GSI-OpenSSH. May be empty.

desired_identity - A string representing desired identity to map to. May be empty.

gridmap_file_identity - A string representing the identity mapping, if any, from the gridmap file.

The map_and_authorize function first determines the local identity the peer user's DN (peer_dn) should map to. The script may be modified to contact an LDAP server and such to determine this mapping. Or it could simply accept and use the mapping from the gridmap file passed to it via the gridmap_file_identity parameter. If desired_identity is non-empty, then either the user's DN must map to desired_identity if allowed by local policy or the script should return a failure code as described later. It then checks to see if the certificates in the given list meet a locally defined minimum lifetime. The certificates passed in thru the cert_chain argument are DER encoded and the example script uses the PyOpenSSL Python module to handle the certificates. Other modules, such as M2Crypto could be used to handle these certificates instead of the PyOpenSSL module. The function also checks to see if the account has a certain group membership. The function returns one of the following tuples:

- A status code (-1 for error, 0 for failed to map identity or failed to pass authorization, and 1 for success)

- A string containing any error messages. Must be empty when the status code is 1.

or the tuple:

- A status code (-1 for error, 0 for failed to map identity or failed to pass authorization, and 1 for success)

- A string containing any error messages. Must be empty when the status code is 1.

- A string representing the local account name the user DN has been mapped to.

In the former case where only a status code and an error string are returned, the C shared library the python callout is invoked from will fall back to the default gridmap file for mapping the user DN to a local account identity. If desired_identity is non-empty, then the script should return an status code of 0 if the desired_identity is not allowed for that peer according to the local/custom policy being enforced.

Building Callout Dynamic Library

Prerequisites

Make sure you have Globus Toolkit already installed on your system. Also make sure the globus_gridmap_callout_error library is available on your system. If it's not available, run the following from within the Globus Toolkit directory:

$ make globus_gridmap_callout_error install

Also make sure Python version 2.5 or greater (including development libraries) is installed on the system. Also needed is the PyOpenSSL or the M2Crypto module to enable handling of certificates.

Building and Installing Callout

Download the tar file attached at the bottom of this page and extract all the files.

$ cd globus_gridmap_callout2python-0.1

$ ./configure --prefix=$GLOBUS_LOCATION --with-flavor=gcc32dbg

$ python-config --includes

-I/usr/include/python2.5 -I/usr/include/python2.5

$ python-config --libs

-lpthread -ldl -lutil -lm -lpython2.5

$ python-config --cflags

-I/usr/include/python2.5 -I/usr/include/python2.5 -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes

$ python-config --ldflags

-L/usr/lib/python2.5/config -lpthread -ldl -lutil -lm -lpython2.5

$

Add to the CFLAGS, CPPFLAGS and LDFLAGS variables in Makefile as suggested by the python-config output above.

Modify the LIBPYTHON macro in globus_gridmap_callout.c to reflect the current python version you are using. This is because, the python library currently needs to be explicitly dlopened by the callout library due to the absence of appropriate module dependency definitions.

$ make install

Now customize gridmap_authz.py for the local/custom policy (allowed groups, the minimum certificate lifetime, etc.) as appropriate and copy it into the appropriate location.

$ mkdir $GLOBUS_LOCATION/var/lib/python

$ cp gridmap_authz.py $GLOBUS_LOCATION/var/lib/python

Create the file $GLOBUS_LOCATION/etc/authz.conf with the following contents:

globus_mapping libglobus_gridmap_callout2python globus_gridmap_callout

Testing with GSI-OpenSSH

1. On the server and the client, configure GSI-OpenSSH per the documentation and your specific setup requirements including the port (example: 2222) the test server should use.

2. On the server as root:

# export GSI_AUTHZ_CONF=$GLOBUS_LOCATION/etc/authz.conf

# export PYTHONPATH=$GLOBUS_LOCATION/var/lib/python

# $GLOBUS_LOCATION/sbin/sshd -dD

3. On the client:

$ gsissh -p 2222 -vvv -o PreferredAuthentications="gssapi-keyex" <server>

Testing with GridFTP

1. On the server and the client, configure GridFTP per the documentation and your specific setup requirements including the port (example: 5000) the test server should use.

2. On the server as root:

# export GSI_AUTHZ_CONF=$GLOBUS_LOCATION/etc/authz.conf

# export PYTHONPATH=$GLOBUS_LOCATION/var/lib/python

# globus-gridftp-server -debug

3. On the client:

$ globus-url-copy gsiftp://<server>:5000//home/testuser/log11 file:///Users/testuser/log11