Difference between revisions of "Site Access Control"

From PDP/Grid Wiki
Jump to navigationJump to search
m
m
Line 4: Line 4:
 
implement authorization decisions and to make (and enforce) a mapping from grid credentials to  
 
implement authorization decisions and to make (and enforce) a mapping from grid credentials to  
 
the Unix world.  
 
the Unix world.  
 +
 +
The framework is designed to work fully with the gLite middleware stack and the pre-WS part of Globus Toolkit version 4. In those environment, it can provide full authorization and credential mapping for native OS-applications.
 +
 +
The suite is not intended to be used in data management where fine-grained access control is required, nor it is intended to be used for access control to container or hosted environments (such as Java). For fine grained data access, an integrated model is preferred, such as the one implemented in [https://twiki.cern.ch/twiki/bin/view/LCG/DataManagementDocumentation#DPM DPM], or look at the way that dCache and gPlazma work. For Java, pure-Java solutions are available for authorization, and credential mapping is not relevant in a JVM.
  
 
Let's shortly review the various elements of the suite:
 
Let's shortly review the various elements of the suite:
Line 13: Line 17:
 
; [[gLExec]] : the gLexec system, used in combination with the LCAS site-local authorization system and the LCMAPS local credential mapping service, provides an integrated solution for site access control to grid resources. With the introduction of gLExec, the submission model can be extended from the traditional gatekeeper models, where authorization and credential mapping only take place at the site’s ‘edge’. Retaining consistency in access control, gLExec allows a larger variety of job submission and management scenarios that include per-VO schedulers on the site and the late binding of workload to job slots in a scenario where gLExec in invoked by pilot jobs on the worker node. But it is also the mapping ingredient of a new generation of resource access services, like CREAM.
 
; [[gLExec]] : the gLexec system, used in combination with the LCAS site-local authorization system and the LCMAPS local credential mapping service, provides an integrated solution for site access control to grid resources. With the introduction of gLExec, the submission model can be extended from the traditional gatekeeper models, where authorization and credential mapping only take place at the site’s ‘edge’. Retaining consistency in access control, gLExec allows a larger variety of job submission and management scenarios that include per-VO schedulers on the site and the late binding of workload to job slots in a scenario where gLExec in invoked by pilot jobs on the worker node. But it is also the mapping ingredient of a new generation of resource access services, like CREAM.
  
; [[SCAS]] : when maintaining consistency between the LCAS and LCMAPS on individual systems becomes burdensome, the Site Central Authorization Service (SCAS) ban be deployed as a (redundant and mostly fail-safe) central administration point for site access control and mapping.  Employing a commonly agreed, SAML2XACML2 based, communications protocol, various services can contact a SCAS service to obtain authorization and mapping decisions. Since the entire system itself leverages the LCAS and LCMAPS system, introducing a SCAS service in an exiting deployment is largely transparent. It can be used simultaneously to make mappings on worker nodes (in late binding and pilot job scenarios) as well as on Globus gatekeepers, GridFTP servers, CREAM CEs and dCache's gPlazma.  
+
; [[SCAS]] : when maintaining consistency between the LCAS and LCMAPS on individual systems becomes burdensome, the Site Central Authorization Service (SCAS) ban be deployed as a (redundant and mostly fail-safe) central administration point for site access control and mapping.  Employing a commonly agreed, SAML2XACML2 based, communications protocol, various services can contact a SCAS service to obtain authorization and mapping decisions. Since the entire system itself leverages the LCAS and LCMAPS system, introducing a SCAS service in an exiting deployment is largely transparent. It can be used simultaneously to make mappings on worker nodes (in late binding and pilot job scenarios) as well as on Globus gatekeepers, GridFTP servers, CREAM CEs and dCache's gPlazma. Connection clients are available from LCMAPS and from the Privilege Project.
Connection clients are available from LCMAPS and from the Privilege Project.
 
  
 
== Interoperability ==
 
== Interoperability ==

Revision as of 10:57, 26 March 2009

To integrate resources that use Unix-like semantics for user management and access control in a grid environment, site-local authorization and credential mapping are required. The Site Access Control suite, comprising LCAS, LCMAPS, SCAS and gLExec, provides the mechanisms to implement authorization decisions and to make (and enforce) a mapping from grid credentials to the Unix world.

The framework is designed to work fully with the gLite middleware stack and the pre-WS part of Globus Toolkit version 4. In those environment, it can provide full authorization and credential mapping for native OS-applications.

The suite is not intended to be used in data management where fine-grained access control is required, nor it is intended to be used for access control to container or hosted environments (such as Java). For fine grained data access, an integrated model is preferred, such as the one implemented in DPM, or look at the way that dCache and gPlazma work. For Java, pure-Java solutions are available for authorization, and credential mapping is not relevant in a JVM.

Let's shortly review the various elements of the suite:

LCAS
the Local Centre Authorization Service. This component makes binary ('yes' or 'no') authorization decisions at the site and resource level. In making this decision, it can use a variety of inputs: the 'grid' name of the user (the Subject Distinguished Name), any VO attributes the user has (like VOMS FQANs), the name of the executable the user intends to execute. It supports basic black and white list functionality, but also more complex VOMS-based expressions, based on the GACL language.
LCMAPS
the Local Credential Mapping Service takes care of translating grid credentials to Unix credentials local to the site. Using the pool account 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.
gLExec
the gLexec system, used in combination with the LCAS site-local authorization system and the LCMAPS local credential mapping service, provides an integrated solution for site access control to grid resources. With the introduction of gLExec, the submission model can be extended from the traditional gatekeeper models, where authorization and credential mapping only take place at the site’s ‘edge’. Retaining consistency in access control, gLExec allows a larger variety of job submission and management scenarios that include per-VO schedulers on the site and the late binding of workload to job slots in a scenario where gLExec in invoked by pilot jobs on the worker node. But it is also the mapping ingredient of a new generation of resource access services, like CREAM.
SCAS
when maintaining consistency between the LCAS and LCMAPS on individual systems becomes burdensome, the Site Central Authorization Service (SCAS) ban be deployed as a (redundant and mostly fail-safe) central administration point for site access control and mapping. Employing a commonly agreed, SAML2XACML2 based, communications protocol, various services can contact a SCAS service to obtain authorization and mapping decisions. Since the entire system itself leverages the LCAS and LCMAPS system, introducing a SCAS service in an exiting deployment is largely transparent. It can be used simultaneously to make mappings on worker nodes (in late binding and pilot job scenarios) as well as on Globus gatekeepers, GridFTP servers, CREAM CEs and dCache's gPlazma. Connection clients are available from LCMAPS and from the Privilege Project.

Interoperability

Interoperability is a key aspect introduced in the latest versions of the SAC suite. Starting with LCMAPS release 1.4.1 and LCAS 1.3.7, the SAC services can be loaded transparently into the Globus Toolkit 4 authorization call-out mechanism. With the introduction of the LCMAPS 'SCAS' client, it can communicate based on the Joint EGEE, OSG, Privilege, and Globus SAML2XAML2 profile, and with a set of standard attributes and obligations to ensure that LCMAPS, SCAS, GUMS, gPlazma and many others can inter-work.

Starting with LCMAPS release 1.4.3 and the new PEP-C communications plug-in, downloadable from the Etics repository in beta, it can work with the new gLite Authorization Framework as well.