Difference between revisions of "HowTo: Configuring gPlazma"

From Public PIC Wiki
Jump to navigation Jump to search
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
 
== dCache Authorization by protocol ==
 
== dCache Authorization by protocol ==
 
=== WebDAV ===
 
=== WebDAV ===

Revision as of 13:02, 6 September 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

dCache Authorization by protocol

WebDAV

  • htpasswd

Authentication

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

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 with no authentication, but requires world readable and/or writable. GSI-DCap
Mapping: glazma Mutator (to convert LDAP specific result to dCache internal principals) + NSSwitch (to map user name to uid)

XRootD

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)