The gPlazma cell can be called from GridFTP and
GSIdCap doors and the SRM server.
Depending on which authorization methods are to be used, some
configuration files must be modified. The configuration files
described here must exist on the node that should run
the gPlazma cell and must contain the correct
site-specific information for the dCache on which it is
deployed.
The gPlazma policy, located in the
/opt/d-cache/etc/dcachesrm-gplazma.policy
file, controls the authorization plugins to be used ("ON" or
"OFF" for each plugin) and the order of their execution.
Example:
# Switches xacml-vo-mapping="OFF" saml-vo-mapping="ON" kpwd="ON" grid-mapfile="OFF" gplazmalite-vorole-mapping="OFF"
The order of execution is specified by assigning a different number to each plugin, such as
# Priorities xacml-vo-mapping-priority="5" saml-vo-mapping-priority="1" kpwd-priority="3" grid-mapfile-priority="4" gplazmalite-vorole-mapping-priority="2"
In the above example, the saml-vo-mapping plugin would be tried first. If authorization was denied for that method, or if the authentication method itself failed, then the kpwd plugin would be tried. The "Priorities" numbering shows that if gplazmalite-vorole-mapping were to also be turned on, it would be tried after the saml-vo-mapping plugin and before the kpwd method.
Having more than one plugin turned on allows a plugin to be used as fallback for another plugin that may fail. It also allows for the authorization of special users who may be denied by the other methods.
The policy file also contains a section for each of the plugins, for configuration specific to that plugin. These sections are described in the documentation for each plugin, as follows.
In gPlazma, except for the dcache.kpwd plugin,
authorization mapping is a two-step process. First, a username
is obtained from a mapping of the user’s DN or DN and role, then
a mapping of username to uid, gid, rootpath is performed. The
storage-authzdb file is used for the
second mapping.
The directory /etc/grid-security is
the location of storage-authzdb. The file
must contain a line specifying the version of the
storage-authzdb format.
version 2.1
The other lines in the file each contain eight fields: the
string authorize, followed by the username, read-write
permission, uid, gid, and three paths.
authorize doegroup read-write 12345 1234 / /data/<yourDirectory> /
In the storage-authzdb file, there must
be a line for each username to be authorized. The existence of
three paths is for legacy purposes. The second path is of most
importance; it is the path under which the user is allowed to
access files. It is permissible to simply use a
“/” for
the second path.
authorize doegroup read-write 12345 1234 / / /
in which case the user will be authorized for any path (the filesystem permissions in Chimera must also allow the transfer).
The first path is nearly always left as “/”, but it may be used as
a home directory in interactive session, as a subdirectory of
the second path. Upon login, the second path is used as the
user’s root, and a “cd” is performed to the first
path. The first path is always defined as being relative to
the second path.
Multiple gids can be assigned by using comma-separated values for the GID file, as in
authorize doegroup read-write 12345 5063,5071,6843 / / /
The lines of the storage-authzdb file are
similar to the “login” lines of the
dcache.kpwd file. If you alreay have a
dcache.kwpd file, create
storage-authzdb by taking the lines from
your dcache.kpwd file that start with the
word login, for example,
login doegroup read-write 12345 50631234 / /data/<yourDirectory> /
and replacing the word login with
authorize.
In the future, dCache services may support the use of
priorites, to be assigned in
storage-authzdb. To assign priorities in
storage-authzdb, replace the stated
version number with 2.2
version 2.2
In the remainder of the file, the fourth field of each line is the priority, which is an integer. Otherwise the fields have the same definitions as in version 2.1.
authorize doegroup1 read-write 2 12345 1234 / /data/<yourDirectory>/doe1 / authorize doegroup2 read-write 0 23456 2345 / /data/<yourDirectory>/doe2 /
Using version 2.1, the default priority is “0”, therefore use this value if it is desired to have the same behavior as in 2.2. Interpretation of the priority value is dependent on the implementation of any dCache service which may use it, however, the convention is that higher numerical values of the field result in higher priority. See the documentation of the specific service in question for details.
There are currently no dCache services which make use of the priority field.
The gPlazma policy file
/opt/d-cache/etc/dcachesrm-gplazma.policy
contains two lines for this plugin.
# Built-in gPLAZMAlite grid VO role mapping gridVoRolemapPath="/etc/grid-security/grid-vorolemap" gridVoRoleStorageAuthzPath="/etc/grid-security/storage-authzdb"
The second is the storage-authzdb used in
other plugins. See the above documentation the section called “storage-authzdb” for how to create the file.
The file is similar in format to the
grid-mapfile, however there is an
additional field following the DN (Certificate Subject),
containing the FQAN (Fully Qualified Attribute Name).
Example:
"/C=DE/O=GermanGrid/OU=DESY/CN=John Doe" "/desy" doegroup "/C=DE/DC=GermanGrid/O=DESY/CN=John Doe" "/desy/Role=NULL/" doegroup "/C=DE/DC=GermanGrid/O=DESY/CN=John Doe" "/desy/Role=NULL/Capability=NULL" doegroup
Therefore each line has three fields: the user’s DN, the user’s FQAN, and the username that the DN and FQAN combination are to be mapped to.
The FQAN is sometimes semantically referred to as the “role”. The same user can be mapped to different usernames depending on what their role is. The role is determined by how the user creates their proxy, for example, using voms-proxy-init. The FQAN contains the user’s Group, Role (optional), and Capability (optional). The latter two may be set to the string “NULL”, in which case they will be ignored by the plugin.
Example:
If a user is authorized in multiple roles, for example
"/DC=org/DC=doegrids/OU=People/CN=John Doe" "/cms/uscms" uscms01 "/DC=org/DC=doegrids/OU=People/CN=John Doe" "/cms/uscms/Role=cmsuser" cms2847 "/DC=org/DC=doegrids/OU=People/CN=John Doe" "/cms/uscms/Role=cmsphedex" phedex "/DC=org/DC=doegrids/OU=People/CN=John Doe" "/cms/uscms/Role=cmsprod" cmsprod
they would be mapped to the username corresponding to the role found in the proxy that the user creates for use by the client software. If the user actually creates several roles in their proxy, authorization (and subsequent check of path and filesystem permissions) will be attempted for each role in the order that they are found in the proxy.
In a GridFTP URL, the user may also explicity request a
username.
gsiftp://doeprod@ftp-door.example.org:2811/testfile1
in which case other roles will be disregarded.
Instead of individual DNs, it is allowable to use
* or "*" as the first
field, such as
Example:
"*" "/desy/Role=production/" desyprod
In that case, any DN with the corresponding role will
match. It should be noted that a match is first attempted with
the explicit DN. Therefore if both DN and
"*" matches can be made, the DN match will
take precedence. This is true for the revocation matches as
well (see below).
Thus a user with subject
/C=DE/O=GermanGrid/OU=DESY/CN=John Doe and
role /desy/Role=production will be mapped
to username desyprod via the above
storage-authzdb line with
"*" for the DN, except if there is also a
line such as
"/C=DE/O=GermanGrid/OU=DESY/CN=John Doe" "/desy/Role=production" desyprod2
in which case the username will be desyprod2.
To create a revocation entry, add a line with a dash
(-) as the username, such as
"/C=DE/O=GermanGrid/OU=DESY/CN=John Doe" "/desy/production" -
or modify the username of the entry if it already exists. The behaviour is undefined if there are two entries which differ only by username.
Since DN is matched first, if a user would be authorized by
his VO membership through a "*" entry, but
is matched according to his DN to a revocation entry,
authorization would be denied. Likewise if a whole VO were
denied in a revocation entry, but some user in that VO could
be mapped to a username through his DN, then authorization
would be granted.
Suppose that there are users in production roles that are
expected to write into the storage system data which will be
read by other users. In that case, to protect the data the
non-production users would be given read-only access. Here in
/etc/grid-security/grid-vorolemap the
production role maps to username cmsprod,
and the role which reads the data maps to
cmsuser.
"*" "/cms/uscms/Role=cmsprod" cmsprod "*" "/cms/uscms/Role=cmsuser" cmsuser
The read-write privilege is controlled by the third field in
the lines of
/etc/grid-security/storage-authzdb
authorize cmsprod read-write 9811 5063 / /data / authorize cmsuser read-only 10001 6800 / /data /
Another use case is when users are to have their own
directories within the storage system. This can be arranged
within the gPlazma configuration files by mapping each
user’s DN to a unique username and then mapping each username
to a unique root path. As an example, lines from
/etc/grid-security/grid-vorolemap would
therefore be written
"/DC=org/DC=doegrids/OU=People/CN=Selby Booth" "/cms" cms821 "/DC=org/DC=doegrids/OU=People/CN=Kenja Kassi" "/cms" cms822 "/DC=org/DC=doegrids/OU=People/CN=Ameil Fauss" "/cms" cms823
and the corresponding lines from
/etc/grid-security/storage-authzdb would be
authorize cms821 read-write 10821 7000 / /data/cms821 / authorize cms822 read-write 10822 7000 / /data/cms822 / authorize cms823 read-write 10823 7000 / /data/cms823 /
Starting with dCache 1.8, regular expressions are supported
in the /etc/grid-security/storage-authzdb
file. Substitutions by regular expression group are also
permitted. Place a regular expression in the username field of
the storage-authzdb file. Any groups in
the regular expression (defined by enclosure in parentheses)
can be referred to in later fields of the line, and the
corresponding substitution will be made when the file is
read. For example, the above lines for granting users
individual directories can be replaced with
authorize cms(\d\d\d) read-write 10$1 7000 / /data/cms$1 /
in which case cms821 matches
cms(\d\d\d) and the group
(\d\d\d) is substituted in
10$1 to yield 10821 and
in /pnfs/fnal.gov/data/cms$1 to yield
/pnfs/fnal.gov/data/cms821, and so on.
The section in the gPlazma policy file for the kpwd plugin
specifies the location of the dcache.kpwd
file, for example
# dcache.kpwd kpwdPath="/opt/d-cache/etc/dcache.kpwd"
To maintain only one such file, make sure that this is the same
location as defined in
/opt/d-cache/share/defaults/dcache.properties.
Use /opt/d-cache/share/examples/gplazma/dcache.kpwd
to create this file.
Two file locations are defined in the policy file for this plugin:
# grid-mapfile gridMapFilePath="/etc/grid-security/grid-mapfile" storageAuthzPath="/etc/grid-security/storage-authzdb"
The grid-mapfile is the same as that used in other
applications. It can be created in various ways, either by
connecting directly to VOMS or GUMS servers, or by hand.
Each line contains two fields: a DN (Certificate Subject) in quotes, and the username it is to be mapped to.
"/C=DE/O=GermanGrid/OU=DESY/CN=John Doe" johndoe
When using the grid-mapfile plugin, the
storage-authzdb file must also be
configured. See the section called “storage-authzdb” for
details.
There are two lines in the policy file for this plugin.
# SAML-based grid VO role mapping mappingServiceUrl="https://gums.oursite.edu:8443/gums/services/GUMSAuthorizationServicePort" # Time in seconds to cache the mapping in memory saml-vo-mapping-cache-lifetime="60"
The first line containins the URL for the GUMS web service. Replace the URL with that of the site-specific GUMS. When using the "GUMSAuthorizationServicePort", the service will only provide the username mapping and it will still be necessary to have the storage-authzdb file used in other plugins. See the above documentation storage-authzdb for how to create the file. If a GUMS server providing a "StorageAuthorizationServicePort" with correct uid, gid, and rootpath information for your site is available, the storage-authzdb file is not necesary.
The second line contains the value of the caching lifetime. In
order to decrease the volume of requests to the SAML
authorization (GUMS) service, authorizations for the
saml-vo-mapping method are by default cached for a period of
time. To change the caching duration, modify the
saml-vo-mapping-cache-lifetime value in
/opt/d-cache/etc/dcachesrm-gplazma.policy
saml-vo-mapping-cache-lifetime="120"
To turn off caching, set the value to 0. The default value is 180 seconds.
gPlazma includes an authorization plugin, to support the XACML
authorization schema. Using XACML with SOAP messaging allows
gPlazma to acquire authorization mappings from any service which
supports the obligation
profile for grid interoperability. Servers presently
supporting XACML mapping are the latest releases of GUMS and
SCAS. Using the new plugin is optional, and previous
configuration files are still compatible with gPlazma. It is
normally not necessary to change this file, but if you have
customized the previous copy, transfer your changes to the new
batch file.
The configuration is very similar to that for the saml-vo-mapping plugin. There are two lines for the configuration.
# XACML-based grid VO role mapping XACMLmappingServiceUrl="https://gums.example.org:8443/gums/services/GUMSXACMLAuthorizationServicePort" # Time in seconds to cache the mapping in memory xacml-vo-mapping-cache-lifetime="180"
# XACML-based grid VO role mapping XACMLmappingServiceUrl="https://scas.europeansite.eu:8443" # Time in seconds to cache the mapping in memory xacml-vo-mapping-cache-lifetime="180"
As for the saml-vo-mapping, the first line containins the URL
for the web service.Replace the URL with that of the site-specific
GUMS or SCAS server. When using the "GUMSXACMLAuthorizationServicePort"
(notice the difference in service name from that for the saml-vo-mapping)
with a GUMS server, the service will only provide the username mapping
and it will still be necesary to have the storage-authzdb file used in
other plugins. See the above documentation
Configuring storage-authzdb for how to create the file. An SCAS server
will return a UID, a primary GID, and secondary GIDS, but not a rootpath. A
storage-authzdb file will be necesary to assign the rootpath. Since SCAS
does not return a username, the convention in gPlazma is to use "uid:gid"
for the username, where uid is the string representation of the uid returned by
SCAS, and gid is the string representation of the primary GID returned by SCAS.
Thus a line such as
authorize 13160:9767 read-write 13160 9767 / /data /
in /etc/grid-security/storage-authzdb will
serve to assign the user mapped by SCAS to uid=13160 and primary
gid=9767 the rootpath /data. It is best for
consistency’s sake to fill in the UID and GID fields with the
same values as in the "uid:gid" field. Additional secondary
gids can be assigned by using comma-separated values in the GID
field. Any gids there not already returned as secondary gids by
SCAS will be added to the secondary gids list.
The second line contains the value of the caching lifetime. In
order to decrease the volume of requests to the XACML
authorization (GUMS or SCAS) service, authorizations for the
saml-vo-mapping method are by default cached for a period of
time. To change the caching duration, modify the
xacml-vo-mapping-cache-lifetime value in
/opt/d-cache/etc/dcachesrm-gplazma.policy
saml-vo-mapping-cache-lifetime="120"
To turn off cach caching, set the value to 0. For xacml-vo-mapping, the default value is 180 seconds.
Here is an example of how a policy file might be set up.
Example:
# Switches xacml-vo-mapping="OFF" saml-vo-mapping="ON" kpwd="ON" grid-mapfile="OFF" gplazmalite-vorole-mapping="OFF" # Priorities xacml-vo-mapping-priority="5" saml-vo-mapping-priority="1" kpwd-priority="3" grid-mapfile-priority="4" gplazmalite-vorole-mapping-priority="2" # dcache.kpwd kpwdPath="/opt/d-cache/etc/dcache.kpwd" # grid-mapfile gridMapFilePath="/etc/grid-security/grid-mapfile" storageAuthzPath="/etc/grid-security/storage-authzdb" # SAML-based grid VO role mapping mappingServiceUrl="https://fledgling09.fnal.gov:8443/gums/services/GUMSAuthorizationServicePort" saml-vo-mapping-cache-lifetime="60" # Built-in gPLAZMAlite grid VO role mapping gridVoRolemapPath="/etc/grid-security/grid-vorolemap" gridVoRoleStorageAuthzPath="/etc/grid-security/storage-authzdb"
In this case, gPlazma will attempt to authorize first
through a GUMS server, and fall back to using
dcache.kpwd. The mappingServiceUrl would
have to be changed to a GUMS server appropriate for the site.