Difference between revisions of "LCMAPS"
m |
m |
||
| Line 1: | Line 1: | ||
LCMAPS is the Local Credential Mapping Service takes care of translating grid credentials to Unix credentials local to the site. Using the pool account (http://www.gridsite.org/gridmapdir/) mechanism, extended to dynamic groups when needed, takes case of ensuring that different individuals on the grid remain distinct unix accounts. Using goup mappings based on the user's VO attributes, isolation and scheduling priority decisions can be made. It can also verify the validity and authenticity of the incoming grid credentials, just like when you would have established a TLS connection over a network. This 'verify_proxy' plugin can also enforce life time constraints on the proxy. | LCMAPS is the Local Credential Mapping Service takes care of translating grid credentials to Unix credentials local to the site. Using the pool account (http://www.gridsite.org/gridmapdir/) mechanism, extended to dynamic groups when needed, takes case of ensuring that different individuals on the grid remain distinct unix accounts. Using goup mappings based on the user's VO attributes, isolation and scheduling priority decisions can be made. It can also verify the validity and authenticity of the incoming grid credentials, just like when you would have established a TLS connection over a network. This 'verify_proxy' plugin can also enforce life time constraints on the proxy. | ||
| + | |||
| + | = High Level Description = | ||
| + | |||
| + | The Local Credential Mapping System (LCMAPS) is a pluggable framework, implemented as | ||
| + | a library, that can be used by applications to map incoming grid identities to local Unix-style | ||
| + | identities, in particular a uid and a set of gids, based on a site-local policy. The native interface to the LCMAPS system needs as inputs the target user’s credential chain. The framework then | ||
| + | either returns successfully after enforcing the appropriate credentials, or returns an error that | ||
| + | must be interpreted as a failure on which the invoking application must exit. | ||
| + | |||
| + | The pre-web services Globus gatekeeper, into which LCMAPS was initially integrated, | ||
| + | requires the Unix uid to be returned, as it will itself re-enforce mapping of this uid using the | ||
| + | setuid(2) call. Therefore, the legacy-gatekeeper interface to LCMAPS returns the Unix uid, | ||
| + | since re-enforcing the current Unix uid is allowed by the setuid(2) call. | ||
| + | |||
| + | Additional interfaces to LCMAPS were developed for incorporation in other frameworks. | ||
| + | This includes interfaces that direct LCMAPS and the underlying VOMS libraries do not validate | ||
| + | the incoming credential chain, for those deployment models where only the literal value of the | ||
| + | attributes is needed, and no trust anchors are available to LCMAPS and the VOMS library to | ||
| + | perform credential chain validation (i.e. for the GUMS module). | ||
| + | |||
| + | == Acquisition and Enforcement == | ||
| + | |||
| + | The execution of the LCMAPS credential mapping framework consists or two parts or phases: | ||
| + | acquisition – where the list of local credentials is derived from the incoming credential chain | ||
| + | and the environment, and enforcement, where the acquired local credentials are enforced within | ||
| + | the running process and in any operating-system-level account databases. The two phases are | ||
| + | separated since the acquisition modules have a need to access protected data (passwords, PKI | ||
| + | key pairs, databases or state directories on the file system) in order to translate grid credentials | ||
| + | to a local user identity. Enforcement modules also may need to be invoked in a specific order, | ||
| + | with the POSIX-in-process Unix uid and gid changes (setuid, initgroups) last – this allows | ||
| + | other enforcement modules to read in private data they need (e.g. credential needed to update | ||
| + | an LDAP server). The business logic diagram of the LCMAPS framework is depicted in the figure. | ||
| + | |||
| + | The LCMAPS system uses a configuration file that contains the module definitions and the | ||
| + | policy definition in the form of a finite-state machine. This configuration file has to be accessible | ||
| + | by a standard open(2) call, i.e., on a POSIX-style filesystem. | ||
| + | |||
| + | |||
= User Guide = | = User Guide = | ||
| − | |||
Revision as of 14:33, 26 March 2009
LCMAPS is the Local Credential Mapping Service takes care of translating grid credentials to Unix credentials local to the site. Using the pool account (http://www.gridsite.org/gridmapdir/) mechanism, extended to dynamic groups when needed, takes case of ensuring that different individuals on the grid remain distinct unix accounts. Using goup mappings based on the user's VO attributes, isolation and scheduling priority decisions can be made. It can also verify the validity and authenticity of the incoming grid credentials, just like when you would have established a TLS connection over a network. This 'verify_proxy' plugin can also enforce life time constraints on the proxy.
High Level Description
The Local Credential Mapping System (LCMAPS) is a pluggable framework, implemented as a library, that can be used by applications to map incoming grid identities to local Unix-style identities, in particular a uid and a set of gids, based on a site-local policy. The native interface to the LCMAPS system needs as inputs the target user’s credential chain. The framework then either returns successfully after enforcing the appropriate credentials, or returns an error that must be interpreted as a failure on which the invoking application must exit.
The pre-web services Globus gatekeeper, into which LCMAPS was initially integrated, requires the Unix uid to be returned, as it will itself re-enforce mapping of this uid using the setuid(2) call. Therefore, the legacy-gatekeeper interface to LCMAPS returns the Unix uid, since re-enforcing the current Unix uid is allowed by the setuid(2) call.
Additional interfaces to LCMAPS were developed for incorporation in other frameworks. This includes interfaces that direct LCMAPS and the underlying VOMS libraries do not validate the incoming credential chain, for those deployment models where only the literal value of the attributes is needed, and no trust anchors are available to LCMAPS and the VOMS library to perform credential chain validation (i.e. for the GUMS module).
Acquisition and Enforcement
The execution of the LCMAPS credential mapping framework consists or two parts or phases: acquisition – where the list of local credentials is derived from the incoming credential chain and the environment, and enforcement, where the acquired local credentials are enforced within the running process and in any operating-system-level account databases. The two phases are separated since the acquisition modules have a need to access protected data (passwords, PKI key pairs, databases or state directories on the file system) in order to translate grid credentials to a local user identity. Enforcement modules also may need to be invoked in a specific order, with the POSIX-in-process Unix uid and gid changes (setuid, initgroups) last – this allows other enforcement modules to read in private data they need (e.g. credential needed to update an LDAP server). The business logic diagram of the LCMAPS framework is depicted in the figure.
The LCMAPS system uses a configuration file that contains the module definitions and the policy definition in the form of a finite-state machine. This configuration file has to be accessible by a standard open(2) call, i.e., on a POSIX-style filesystem.
