HowTo: Configuring gPlazma

Configuring gPlazma

gPlazma configuration file example

################################################################################
# Login Phases:
#   [auth]
#       - auth-plugins are used to read the users public and private
#         credentials and ask some authority, if those are valid for accessing 
#         the system. 
#   [map]
#       - map-plugins map the user information obtained in the auth step to UID
#         and GIDs. 
#       - This may also be done in several steps (e.g., the vorolemap plugin 
#         maps the users DN+FQAN to a username which is then mapped to UID/GIDs
#         by the authzdb plugin)
#   [account]
#       - account-plugins verify the validity of a possibly mapped of the user 
#         and may reject the login depending on information gathered within the 
#         map step.
#   [session]
#       - session plugins usually enrich the session with additional attributes
#         like the user’s home directory.
#   [identity]
#       - identity plugins are responsible for mapping UID and GID to user
#         names and vice versa during the work with dCache. 
################################################################################

################################################################################
# Modifiers:
#   [optional]
#       - The success or failure of this plugin is only important if it is the 
#         only plugin in the stack associated with this type. 
#   [sufficient]
#       - Success of such a plugin is enough to satisfy the authentication 
#         requirements of the stack of plugins (if a prior required plugin has
#         failed the success of this one is ignored). 
#       - A failure of this plugin isn't deemed as fatal for the login attempt.
#       - If the plugin succeeds gPlazma2 immediately proceeds with the next 
#         plugin type or returns control to the door if this was the last stack. 
#   [required]
#       - Failure of such a plugin will ultimately lead to gPlazma2 returning 
#         failure but only after the remaining plugins for this type have been 
#         invoked. 
#   [requisite]
#       - Like required, however, in the case that such a plugin returns a
#         failure, control is directly returned to the d
################################################################################
auth     sufficient  htpasswd
auth     optional    x509
auth     sufficient  voms
# send username and password to LDAP server
auth     optional    jaas       gplazma.jaas.name=LdapGplazma
map      optional    vorolemap
map      sufficient  authzdb
map      optional    gridmap
# convert LDAP specific result to dCache internal principals
map      optional    mutator gplazma.mutator.accept=com.sun.security.auth.UserPrincipal gplazma.mutator.produce=username
# use ldap to map user name to uid
# map      optional    ldap
map      requisite   nsswitch
identity requisite   nsswitch
session  sufficient  nsswitch
session  sufficient  authzdb

dCache Authorization by protocol

WebDAV

• htpasswd

Authentication

jaas

• JAAS, custom /etc/dcache/jgss.conf

htpasswd

• Configuration file can be found here: /etc/dcache/htpasswd

Mapping

• glazma Mutator (to convert LDAP specific result to dCache internal principals) + NSSwitch (to map user name to uid)

NFSv3/NFSv41

Authentication

• Authentication is not performed in the dCache system, is made through OpenLDAP server.

Mapping

• Username/Password already authenticated through OpenLDAP, NSSwitch for mapping.

GridFTP

Authentication

x509

• Users defined in /etc/grid-security/grid-mapfile.

• /etc/grid-security/grid-mapfile is generated with a grid-mapfile cron (crontab -l) which executes the edg-mkgridmap application.

# Puppet Name: grid-mapfile
0 */6 * * * [ ! -f /var/lock/subsys/edg-mkgridmap ] && /usr/sbin/edg-mkgridmap --output=- > /etc/grid-security/grid-mapfile.new && sleep 3 && cat /etc/grid-security/grid-mapfile.new > /etc/grid-security/grid-mapfile

• edg-mkgridmap application can be configured with the /etc/edg-mkgridmap.conf file where:

• You can map VO members by specifying a VOMS service and the affected VO. In example:

group vomss://voms2.cern.ch:8443/voms/lhcb?/lhcb lhcb001

• /etc/grid-mapfile-local is a file to bootstrap the actual grid-mapfile and can be used to allow extra DNs or override some mappings

voms

• User defined in /etc/grid-security/grid-vorolemap.

Mapping

• gridmap must is map the incoming DN to a local user

DCap/GSI-DCap

Authentication

Plain DCap

• No authentication required, but needs world readable and/or writable files and directories.
• Only recommended its use for prestages.

HTPasswd

• This is intended only for the WebDAV protocol.

x509 Certificates

• This is mostly intented for the WebDAV protocol.

VOMS Certificates

• This is intented for GRID Users, mostly using GridFTP, GSI-DCap & SRM protocols.

JAAS

• This is intended for PIC LDAP users accessing to WebDAV.

multimap

• Useful for OIDC authentication (i.e. through Google or INDIGO Accounts)