gPlazma configuration as in use

This page contains the results of a survey asking some of the larger dCache sites how they're using gPlazma (and, by extension, dCache) and whether they are using Kerberos doors.

Here are the results:

Fermilab

Fermilab has three dCache instances: CMS, CDF and the "public dCache".

CMS

The following is information from Catalin Dumitrescu about the CMS instance

>  I believe the CMS instance uses some Kerberos access protocols.  Is  that 
>  right?  Do any other instances use Kerberos?

   CMS instance does not use kerberos. I know the CDF one uses some 
kind of kerberos for their dcap doors. CMS has only read-only doors for 
users and SRM. It also uses the telnet plugin for production only.

Here is the gPlazma configuration. For brevity, the options that affect disabled authn/authz methods have been removed.

# Switches
saml-vo-mapping="ON"
kpwd="ON"
xacml-vo-mapping="OFF"
grid-mapfile="OFF"
gplazmalite-vorole-mapping="OFF"
saz-client="OFF"

# Priorities
saml-vo-mapping-priority="1"
kpwd-priority="3"

# dcache.kpwd
kpwdPath="/opt/d-cache/etc/dcache.kpwd"

# SAML-based grid VO role mapping
mappingServiceUrl="https://gums.fnal.gov:8443/gums/services/GUMSAuthorizationServicePort"
# Time in seconds to cache the mapping in memory
saml-vo-mapping-cache-lifetime="180"

Here's an example of the kind of mapping they have inside their kpwd file

version 2.1
mapping "/DC=org/DC=doegrids/OU=People/CN=Catalin L. Dumitrescu 42349" XXX1
mapping "catalind" XXX1


login XXX1 read-write xxx yyy / /pnfs/fnal.gov/usr/cms /pnfs/fnal.gov/usr/cms
   /DC=org/DC=doegrids/OU=People/CN=Catalin L. Dumitrescu 42349 catalind

Catalin also mentioned that use the telnet plugin with gPlazma:

> Am I right in thinking that the telnet plugin allows a door to  
> authenticate the user without GSI and without talking to gPlazma?

   Actually the latest version we have installed talks to gPlazma.
Prior version (1 or 2 years ago did not).

Here is the configuration of a "production" door:

create dmg.cells.services.login.LoginManager DCap4r-${thisHostname} 
             "${dCapPort4r} 
              -export 
              diskCacheV111.doors.DCapDoor 
              -keepAlive=300 
              -poolRetry=2700 
              -prot=telnet -pswdfile=${ourHomeDir}/etc/passwd 
              -authorization=required 
              -use-gplazma-authorization-module=true 
              -gplazma-authorization-module-policy=${ourHomeDir}/etc/dcachesrm-gplazma.policy 
              -permission-handler=diskCacheV111.services.acl.UnixPermissionHandler 
              -truncate=${truncate} 
              -maxLogin=${dcapMaxLogin} 
              -brokerUpdateTime=30 
              -protocolFamily=dcap 
              -protocolVersion=1.3.0 
              -poolProxy=PoolManager 
              -io-queue=${dcapIoQueue} 
              -permission-handler=${permissionHandler} 
              -aclTable=${aclTable} 
              -aclConnDriver=${aclConnDriver} 
              -aclConnUrl=${aclConnUrl} 
              -aclConnUser=${aclConnUser} 
              -aclConnPswd=${aclConnPswd} 
              -stageConfigurationFilePath=${stageConfigurationFilePath} 
              -io-queue-overwrite=${dcapIoQueueOverwrite} 
              -loginBroker=LoginBroker  

CDF

The CDF dCache instance serves the physicists of the CDF experiment, one of the experiments using the Tevatron facility.

FNL public dCache

BNL

From Ofer Rind

I have attached our ATLAS dcachsrm-gplazma.policy file.  I don't believe we use any Kerberos access protocol.
Let me know if you need any more information and thanks for thinking of us!

Here's the edited gPlazma file. To keep things reasonably short I've removed the options about disabled authn/authz options (like kpwd and grid-mapfile).

gplazmalite-vorole-mapping="ON"
saml-vo-mapping="ON"
xacml-vo-mapping="OFF"
kpwd="OFF"
grid-mapfile="OFF"
saz-client="OFF"

# Priorities
gplazmalite-vorole-mapping-priority="1"
saml-vo-mapping-priority="2"

# SAML-based grid VO role mapping 
mappingServiceUrl="https://gums.racf.bnl.gov:8443/gums/services/GUMSAuthorizationServicePort"
# Time in seconds to cache the mapping in memory
saml-vo-mapping-cache-lifetime="30"

# Built-in gPLAZMAlite grid VO role mapping
gridVoRolemapPath="/etc/grid-security/grid-vorolemap"
gridVoRoleStorageAuthzPath="/etc/grid-security/storage-authzdb"
vomsValidation="false"

University of Michigan

Here is the gPlazma file supplied by Shawn McKee. He confirmed that the SAML/XACML duplication is due to the OSG switch-over from SAML to XACML. He may disable the SAML part in the future. He also confirmed that they're not using Kerberos right now (nor telnet).

# Switches
xacml-vo-mapping="ON"
saml-vo-mapping="ON"
kpwd="OFF"
grid-mapfile="OFF"
gplazmalite-vorole-mapping="ON"
saz-client="OFF"

# Priorities
gplazmalite-vorole-mapping-priority="1"
xacml-vo-mapping-priority="2"
saml-vo-mapping-priority="3"

# XACML-based grid VO role mapping
XACMLmappingServiceUrl="https://linat02.grid.umich.edu:8443/gums/services/GUMSXACMLAuthorizationServicePort"
# Time in seconds to cache the mapping in memory
xacml-vo-mapping-cache-lifetime="180"

# SAML-based grid VO role mapping
mappingServiceUrl="https://linat02.grid.umich.edu:8443/gums/services/GUMSAuthorizationServicePort"
# Time in seconds to cache the mapping in memory
saml-vo-mapping-cache-lifetime="180"

# Built-in gPLAZMAlite grid VO role mapping
gridVoRolemapPath="/etc/grid-security/grid-vorolemap"
gridVoRoleStorageAuthzPath="/etc/grid-security/storage-authzdb"
vomsValidation="true"

OSG in general

Here is some information from Tanya Levshina about how OSG are using gPlazma in general.

Yes, gplazma is deployed everywhere in OSG and a lot of sites are using GUMS for authorization. We
are in the process of switching  from SAML to XACML call outs to GUMS.  Some sites are still
using gplazma/dcache.kwpd.