Beginning with dCache version 1.9.2, gPlazma includes a new 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. If the installation is an upgrade it will change /opt/d-cache/config/gPlazma.batch. 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://fledgling09.fnal.gov: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 / /pnfs/fnal.gov/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
/pnfs/fnal.gov/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
saml-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 0; caching is turned off by default.