release notes | Book: 1.9.5, 1.9.12 (opt, FHS), 2.11 (FHS), 2.12 (FHS), 2.13 (FHS), 2.14 (FHS), | Wiki | Q&A black_bg
Web: Multi-page, Single page | PDF: A4-size, Letter-size | eBook: epub black_bg
SRM Space Manager Virtual Organization based access control configuration
Prev Chapter 14. dCache Storage Resource Manager  Next
The dCache Book > Configuration of dCache > dCache Storage Resource Manager > SRM Space Manager Virtual Organization based access control configuration

SRM Space Manager Virtual Organization based access control configuration

[return to top]

VO based Authorization Prerequisites

In order to be able to take advantage of the Virtual Organization (VO) infrastructure and VO based authorization and VO Based Access Control to the Space in dCache, certain things need to be in place:

  • User needs to be registered with the VO.

  • User needs to use voms-proxy-init to create a vo proxy.

  • dCache needs to use gPlazma and not gPlazma with dcache.kpwd plugin, but other modules that know how to extract VO attributes from the proxy. (see Chapter 12, gPlazma authorization in dCache, have a look at gplazmalite-vorole-mapping plugin.

Only if these 3 conditions are satisfied the VO based authorization of the Space Manager can work.

If a client uses a regular grid proxy, created with grid-proxy-init, and not a Virtual Organization (VO) proxy, which is created with the voms-proxy-init, when he is communicating with SRM server in dCache, then the VO attributes can not be extracted its credential. voms-proxy-init adds a Fully Qualified Attribute Name (FQAN) section(s) to the grid proxy, which contain informaton about user’s VO membership, in particular it contain VO Group name and VO Role that the client intends to play at this time. In this case the name of the user is extracted on basis of the direct Distinguished Name (DN) to use name mapping. For the purposes of the space reservation the name of the user is used as its VO Group name, and the VO Role is left empty.

[return to top]

VO based Access Control configuration

dCache Space Reservation Functionality Access Control is currently performed at the level of the LinkGroups. The access to making reservations in each LinkGroup is controlled by the SpaceManagerLinkGroupAuthorizationFile property.

[return to top]

SpaceManagerLinkGroupAuthorizationFile syntax

The file described by SpaceManagerLinkGroupAuthorizationFile has following syntax:

LinkGroup Name followed by the list of the Fully Qualified Attribute Names (FQANs), each FQAN on separate line, followed by an empty line, which is used as a record separator, or by the end of file. FQAN is usually a string of the form <VO>/Role=<VORole>. Both <VO> and <VORole> could be set to *, in this case all VOs or VO Roles will be allowed to make reservations in this LinkGroup. Any line that starts with # is a comment and may appear anywhere.

File location is specified by defining 

SpaceManagerLinkGroupAuthorizationFileName=<FILENAME>

in the dCacheSetup

[return to top]

Example of the SpaceManagerLinkGroupAuthorizationFile 

# this is comment and is ignored

LinkGroup LFSOnly-LinkGroup
/atlas/Role=/atlas/role1

LinkGroup CMS-LinkGroup
/cms/Role=*
#/dteam/Role=/tester

LinkGroup default-LinkGroup
#allow anyone :-)
*/Role=*
#/dteam/Role=/tester

Successful VO and Experiment specific examples of dCache SRM Space Manager configurations are or will be published at dCache WIKI documentation pages .

Prev Up Next
SRM Space Manager configuration Home SRMWatch, SRM Monitoring Tool