Mapping VOMS users based on their role

This page is based on an NorduGrid bugzilla entry 1127 which discuss how to use the grid-manager authentication framework to map VOMS users to different local accounts based on the VOMS role.

John is member of the VO smscg where he belongs to the group atlas and has been assigned the roles production and test. Since groups and roles are fully decoupled, John can request proxies that can include one (or several) of the following different group-role combinations (termed "Fully Qualified Names" (FQAN)):

/smscg (notice it's the same as /smscg/Role=NULL)
/smscg/Role=production
/smscg/Role=test
/smscg/atlas
/smscg/atlas/Role=production
/smscg/atlas/Role=test

Assume we have to following local users smcsg and smscgP. We now want an assignment that performs the following VOMS to local user mapping:

/smscg -> smscg
/smscg/Role=production -> smscg
/smscg/Role=test -> smscg
/smscg/atlas -> smscgP
/smscg/atlas/Role=production -> smscgP
/smscg/atlas/Role=test -> smscgP

LRMS can then be configured to have different priorities for the two users, but this is outside the scope of this page.

We start by defining a [vo] block. This needs to be done in order to

To generate grid-mapfile needed for information system. For that purpose nordugridmap utility will have to be run periodically.
To provide coarse-grained information to authorization rules used to define authorization groups. If needed of course.

[vo]
id="smscg_vo"
vo="smscg_vo"

# Here we define path to file to which nordugridmap will write DNs of
# users matching rules below. Because we are going to use it as grid-mapfile
# for other purposes it is going reside at default location.
file="/etc/grid-security/grid-mapfile"

# Now we tell nordugridmap to pull information from VOMRS/VOMSS/or_whatever_
# it_is_called_now service and to ask for users belonging to smscg VO.
source="vomss://voms.smscg.org:8443/voms/smscg"

# Now we specify default mapping to local *NIX id. It is possible to completely
# redefine mapping in [gridftpd] block. But this one will be used by information
# system to compute and present resources available to user.
# Let's use one of lowest priority account defined in use-case.
mapped_unixid="smscg"

Next comes an authorization group. In the authorization group we are going to check if user presents
any proof that he belongs to smscg VO. We can use that information later to explicitely limit access to resources. If such access control is not needed this group can be removed.

[group]
name="smscg_auth"

# Here we use internal support of ARC for VOMS attrbutes
voms="smscg * * *"
# If we want to limit access to resources also by other VOMS
# attributes then other voms rules similar to those defined
# below in [gridftpd] section may be used.

Finally we do the fine grained configuration in the gridftpd group

[gridftpd]
debug="9"
logfile="/var/log/gridftpd.log"
logsize="100000 2"
pidfile="/var/run/gridftpd.pid"
port="2811"
pluginpath="/opt/nordugrid/lib"
encryption="no"

# By specifying 'no' here we limit users allowed to exatblish connection to this 
# server to those specified in grid-mapfile. This may be not necessary if additional
# authorization is applied as done below. But this provides additional 
# layer of protection so let it be.
allowunknown="no"

maxconnections="200"

# Here we start fine-grained user mapping. Let's first define 
# few VOMS mappings using embedded functionality of ARC.
# These lines should map Grid users to high-priority and low-priority *NIX users
# smscg and smscgP. Mind order - those with more attributes defined come first. 
# The order is also important because proxies with roles might have a second
# attribute set without the roles.
# I do not know if missing attribute is passed by VOMS as empty string or as string 
# containing NULL keyword. 
# UPDATE: it is passed as 'NULL'.
#
unixmap="smscgP voms smscg atlas test *"
unixmap="smscgP voms smscg atlas production *"
unixmap="smscgP voms smscg atlas NULL *"
# These 3 lines are not needed if grid-mapfile defines default mapping
# to smscg001 user. But we can have them for consistence and if mapping
# to nobody is defined below for safety reasons.
unixmap="smscg voms smscg NULL test *"
unixmap="smscg voms smscg NULL production *"
unixmap="smscg voms smscg NULL NULL *"

Technical-ARC VOMS2

Labels:

Mapping VOMS users based on their role