Difference between revisions of "HowTo: Configuring gPlazma"
Jump to navigation
Jump to search
(→=) |
|||
(16 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
= 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 | ||
+ | == 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 == | == dCache Authorization by protocol == | ||
=== WebDAV === | === WebDAV === | ||
* htpasswd | * htpasswd | ||
− | + | * x509 | |
− | |||
=== NFSv3/NFSv41 === | === NFSv3/NFSv41 === | ||
− | * | + | * Authentication is not performed in the dCache system, is made through OpenLDAP server. |
− | |||
=== GridFTP === | === GridFTP === | ||
+ | * x509 | ||
+ | * voms | ||
=== DCap/GSI-DCap === | === 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 === | === XRootD === | ||
− | + | * voms | |
− | |||
− | * | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Latest revision as of 08:58, 5 October 2017
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