User:Dennisvd@nikhef.nl/lijmwijzer
De LCMAPS lijmwijzer. Nederlandse tekst is concepttekst.
The universal guide to setting up Grid user authorization at your site
This guide will help you choose and configure security middleware components to suite the local setup at your site. Warning: this guide will not explain how to set up site security in general.
The following text applies to sites that are part of the EGEE grid infrastructure. For other Grids, a separate guide will be provided.
We need to distinguish current practice from upcoming methods; we project the direction taken by new developments, but as some features are not yet supported, or never will be, the old style alternatives must be discussed alongside.
The old is perhaps best represented by the LCAS/LCMAPS family of software, accompanied by SCAS an gLExec. This collection of system tools and libraries is developed in C, and has deep roots in the earliest grid systems. While the software proved to be stable grounds, some of the more recent wishes were hard to express in configuration and setup, and over time the authorization system was rethought and rewrought as the Argus service.
The new service complements the older codes, not replaces them; except for SCAS which was always supposed to be only a steward until the arrival of its master.
Step 1: central authorization
Het standaard advies moet zijn: Argus. Tenzij er een uitzondering is:
- er ontstaan problemen
- LDAP enforcement is nodig (kan via SCAS)
- 3rd party plugins gooien roet in het eten (moet uit de praktijk blijken, hoeft geen bezwaar te zijn)
- Er is een bewuste keuze om node-local mappings te doen. Dit is een erg technische verhandeling die uitleg behoeft.
Step 2: Resource configuration
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. 
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.
Service types
Worker Node
Compute Element
CREAM CE
There are two services that independently use LCMAPS on a CREAM CE: gLExec and gridftpd. It is vital that mappings for both are consistent, otherwise e.g. proxies and sandboxes cannot be read. Differences between the configuration for gLExec and the gridftpd are allowed only if the flow of the plugin execution and the initialization parameters of the plugins result in a consistent mapping.
Examples:
gridftpd:
withvoms: vomslocalgroup -> vomslocalaccount vomslocalaccount -> posix_enf | vomspoolaccount vomspoolaccount -> posix_enf standard: localaccount -> posix_enf | poolaccount poolaccount -> posix_enf
gLExec:
withvoms: verify_proxy -> vomslocalgroup vomslocalgroup -> vomslocalaccount vomslocalaccount -> posix_enf | vomspoolaccount vomspoolaccount -> posix_enf standard: verify_proxy -> localaccount localaccount -> posix_enf | poolaccount poolaccount -> posix_enf
