HowTo: Configuring gPlazma
Jump to navigation
Jump to search
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
Authetincation types
jaas
- This is intended for PIC LDAP users accessing to WebDAV.
- JAAS, custom /etc/dcache/jgss.conf
htpasswd
- This is intended only for the WebDAV protocol.
- Configuration file can be found here: /etc/dcache/htpasswd
- To generate a new entry in the htpasswd file proceed as follows: dCache gPlazma: htpasswd management
x509
- This is mostly intented for the WebDAV protocol.
- 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
- This is intented for GRID Users, mostly using GridFTP, GSI-DCap & SRM protocols.
- User defined in /etc/grid-security/grid-vorolemap.
multimap
- Useful for OIDC authentication (i.e. through Google or INDIGO Accounts)
dCache Authorization by protocol
WebDAV
- htpasswd
- x509
NFSv3/NFSv41
- Authentication is not performed in the dCache system, is made through OpenLDAP server.
GridFTP
- x509
- voms
DCap/GSI-DCap
Plain DCap
- No authentication required, but needs world readable and/or writable files and directories.
- Only recommended its use for prestages.
GSI-DCap
- voms
XRootD
- voms