Authentication and authorization

./bin/gums-host runs using the host credentials, not the user credentials. This means that the user running gums-host will need to be able to read the host credentials. A host will be able to only access the maps relative to the host. That is, the hostname included in the host certificate will need to match to the maps within GUMS.

./bin/gums-host commands

The script provides many commands, which you can list just by running the script with no arguments:

[root@mygk bin]$ ./gums-host
usage: gums-host command [command-options]
Commands:
  generateGrid3UserVoMap - Generate grid3-user-vo-map.txt for this host.
  generateGridMapfile - Generate grid-mapfile for this host.
  mapUser - Local credential used for a particular user.
  version - Retrieve GUMS client version.
For help on any command:
  gums-host command --help

You can then retrieve the full syntax of each command by calling it with the --help options. For example:

[root@mygk bin]# ./gums-host mapUser --help
usage: gums mapUser [-s SERVICEDN] [-n TIMES] [-t NREQUESTS] [-b] [-f
            FQAN] [-i FQANISSUER] USERDN1 [USERDN2] ...
Maps the grid identity to the local user.
Options:
 -s,--service <arg>   DN of the service. When using gums-host, it defaults
                      to the host credential DN.
 -f,--fqan <arg>      Fully Qualified Attribute Name, as it would be
                      selected using voms-proxy-init; no extended information by default
 -t,--timing <arg>    enables timing, grouping the requests. For example,
                      "-t 100" will give you timing information on 100 requests at a time
 -b,--bypassCallout   connects directly to GUMS instead of using the
                      callout
 -i,--issuer <arg>    Fully Qualified Attribute Name Issuer, that is the
                      DN of the VOMS service that issued the attribute certificate
 -n,--ntimes <arg>    number of times the request will be repeated
    --help            print this message

Please, refer to the help on the command line for the full syntax of the commands.

Service mapping generation commands

The only set of commands available for a host are the ones to retrieve mapping information. One can retrieve the maps generated by GUMS, and check to which local user any Grid identity is mapped. These are the same as the ./bin/gums commands, but, since they run with host credential, they can access only that particular host mapping.\

gums-host mapUser

With this command an admin can check the mapping of a specific identity, including the VOMS extended proxy FQAN. This allows to check if the user is mapped to the correct account when using different VO roles. It issues a mapping request as the callout to the gatekeeper does, which is very helpful to diagnose problems. Remember that the service name has to match the name used in the credentials.

Here are a couple of examples:

[root@mygk bin]# ./gums-host mapUser \
  -s  "/DC=org/DC=doegrids/OU=Service/CN=mygk.mysite.com" \
  "/DC=org/DC=doegrids/OU=People/CN=Gabriele Carcassi 12345"
LocalId[userName: grid12345]

This examples asks the GUMS server what account would the certificate be mapped on the mygk.mysite.com gatekeeper.

One can also ask what account would be used if the user would come in with a particular role.

[root@mygk bin]# ./gums-host mapUser \
  -s  "/DC=org/DC=doegrids/OU=Service/CN=mygk.mysite.com" \
  -f  "/myvo/Role=role1" \
  -i  "/DC=org/DC=doegrids/OU=Service/CN=voms.mysite.com" \
  "/DC=org/DC=doegrids/OU=People/CN=Gabriele Carcassi 12345"
LocalId[userName: special1]

Here we see the same user being assigned a different account.

gums generateGridMapfile

This commands allows to retrieve a grid-mapfile for the host. Be careful: generating a map will force all the policy to be explored, and it might have undesired side effects. For example, when using the account mapping, this will force assigning an account to each user, even if they are never going to come on site. For example:

[root@mygk bin]# ./gums-host generateGridMapfile
#---- members of vo: usatlas ----#
"/C=CH/O=CERN/OU=GRID/CN=Frederik Orellana 5894" usatlas1
"/C=CH/O=CERN/OU=GRID/CN=Michela Biglietti 4798" usatlas1
"/C=CH/O=CERN/OU=GRID/CN=Miguel De Oliveira Branco 2423" usatlas1
"/C=CH/O=CERN/OU=GRID/CN=Shulamit Moed 9840" usatlas1
"/DC=org/DC=doegrids/OU=People/CN=Alden Stradling 409738" usatlas1
"/DC=org/DC=doegrids/OU=People/CN=Aldo Saavedra 942457" usatlas1
"/DC=org/DC=doegrids/OU=People/CN=Alexandre V Vaniachine 778117" usatlas1
...

It will generate the map for the DN associated with the host certificate. To modify the host credential to be used (i.e. if your host/service certificate is not in /etc/grid-security/hostcert.pem), modify the variable defined in the gums-host script.

gums generateGrid3UserVoMap

This command allows to retrieve the inverse map used by Grid3/OSG accounting. Be careful: generating a map will force all the policy to be explored, and it might have undesired side effects. For example, when using the account mapping, this will force assigning an account to each user, even if they are never going to come on site. For example:

[root@mygk bin]# ./gums-host generateGrid3UserVoMap 
#User-VO map
# #comment line, format of each regular line line: account VO
# Next 2 lines with VO names, same order, all lowercase, with case (lines starting wi
th #voi, #VOc)
#voi usatlas ivdgl ligo btev uscms sdss gridex grase
#VOc ATLAS iVDgL LIGO BTeV CMS SDSS GRIDEX GRASE
#---- accounts for vo: usatlas ----#
usatlas1 usatlas
#---- accounts for vo: ivdgl ----#
ivdgl ivdgl
...

It will generate the map for the DN associated with the host certificate. To modify the host credential to be used (i.e. if your host/service certificate is not in /etc/grid-security/hostcert.pem), modify the variable defined in the gums-host script.