User:Dennisvd@nikhef.nl/lijmwijzer

De LCMAPS lijmwijzer. Nederlandse tekst is concepttekst.

The universal guide to setting up Grid security middleware at your site

This guide will help you choose and configure security middleware components to suite the local setup at your site. Warning: this advice given by this guide won't replace applying good security practices for grid sites.

The following guide applies to sites that are part of the EGEE grid infrastructure.

There are several options for centrally managing grid security policies, but the ARGUS authorization service is the framework of choice now and in the future. There are some special cases which require an alternative approach as detailed below.

Central account mapping

Managing the (pool) user and group account mappings on a site is typically done centrally. If for some reason a central authorization service is not chosen, the gridmapdir and/or groupmapdir could be shared (with NFS) among all services where mappings are performed, for consistency.

Node-local mapping

In special cases the scope of the account mappings is kept local to a node; these use-cases are typically found when users are mapped to a job slot on a worker node. Node local mapping can be mixed with centralized mapping, for instance when using secondary group ids from the central group mapping.

Special Cases

The following items should be considered before a final choice can be made.

LDAP enforcement

The LCMAPS plugin for LDAP enforcement is used for sites that have dynamic mappings to users and groups, which requires a modification of the LDAP database every time a (new) mapping is done. Zie elders. Applies to: WN, CE.

This plugin will not work together with the ARGUS framework.

YAIM configurable

no

In production

yes

supposed to work

yes

certified

yes

LDAP enforcement with SCAS

(This situation is supposed to work, but not found in production as such.)

On the WN:

get_account_on_wn:
verify_proxy -> scas_client
scas_client -> ldap_enf
ldap_enf -> posix_enf

On the CE:

get_account_on_ce:
scas_client -> ldap_enf
ldap_enf -> posix_enf

On SCAS:

get_account_on_scas:
voms_pool_group -> voms_local_group | voms_local_group
voms_local_group -> voms_pool_account

LDAP enforcement with node-local mapping

On the WN:

get_account_on_wn:
verify_proxy -> voms_pool_group | voms_local_group
voms_pool_group -> voms_local_group
voms_local_group -> voms_pool_account
voms_pool_account -> ldap_enf
ldap_enf -> posix_enf

On the CE:

get_account_on_ce:
voms_pool_group -> voms_local_group | voms_local_group
voms_local_group -> voms_pool_account
voms_pool_account -> ldap_enf
ldap_enf -> posix_enf

AFS integration

If your site makes use of AFS for file access (e.g. AFS home directories that require AFS tokens) then you need the AFS enforcement plugin. Applies to: CE, WN.

using an ARGUS backend =

On the WN:

get_account_on_wn:
verify_proxy -> pepc
pepc -> afs_enf
afs_enf -> posix_enf

On the CE:

get_account_on_ce:
pepc -> afs_enf
afs_enf -> posix_enf

using a SCAS backend

On the WN:

get_account_on_wn:
verify_proxy -> scas_client
scas_client -> afs_enf
afs_enf -> posix_enf

On the CE:

get_account_on_ce:
scas_client -> afs_enf
afs_enf -> posix_enf

On SCAS:

get_account_on_scas:
voms_local_group -> voms_pool_account

AFS enforcement with node-local mapping

This case is used when there is no centrally arranged authorization; the gridmapdir should be shared (e.g. through NFS) between services for consistent mappings.

On the WN:

get_account_on_wn:
verify_proxy -> voms_local_group
voms_local_group -> voms_pool_account
voms_pool_account -> afs_enf
afs_enf -> posix_enf

On the CE:

get_account_on_ce:
voms_local_group -> voms_pool_account
voms_pool_account -> afs_enf
afs_enf -> posix_enf

Third party plugins

Some sites use LCMAPS plugins not provided with the base LCMAPS software; the functioning and side-effects of such plugins is specific to the site and the implementation. In general, it cannot be determined a priori if a plugin will or will not work with either ARGUS or SCAS. YMMV.