Site Access Control

To integrate resources that use Unix-like semantics for user management and access control in a grid environment, authentication, 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. It can also provide authentication and credential validation capability for those systems that don't have built-in TLS handshakes.

If you have any trouble in using this Site Access Control suite, please contact the product team by email at grid-mw-security, at the domain nikhef.nl.

The previous information pages on LCAS and LCMAPS are still available.

For whom was the SAC suite built?

The framework is designed to work fully with the gLite middleware stack and the pre-WS part of Globus Toolkit version 4, including the gatekeeper, GridFTP service and GSI-SSH. In those environments, it can provide full authorization and credential mapping for native OS-applications. With special patches ('edg-gatekeeper' and 'edg-gridftp'), it can also be integrated in the Globus Toolkit 2.x series. Elements from LCMAPS and LCAS are also deployed in NAREGI and the GeoGrid, and are part of a few other products. Through the gLExec utility, it can be directly integrated into late-binding job submission frameworks, so that such frameworks can honour site access policies and restrictions.

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: the gLite TrustManager, soon the gLite Authorization Framework (Java Components), and the GT4 Authorization Framework. Credential mapping is not relevant in a JVM, and when needed should be done through gLExec.

Overview and Architecture

A (still limited) number of presentations and papers describe the various components of the SAC system. Whilst these are not intended to serve as documentation as such, they provide elements of the architectural overview. Please read the papers and presentations for more information ...

Components of the SAC suite

LCAS

LCAS is 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

LCMAPS is 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 VO Services (Privilege) Project.

Other components and elements

There is a set of associated products and components available:

• JobRepository utilities to query and mine the audit database of interactions generated by the LCMAPS JR plugin
• the EDG gatekeeper and edg-gridftp daemons that provide LCAS and LCMAPS capabilities for the GT2.x series
• integration with the WorkSpaceService in GT4.x
• the batch system validation tool sutest to verify interoperability of your own batch system with gLExec

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. See the AuthZ-Interop page for more links and the documents.

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.

Examples of how to configure a system with a GT4 Authorization Call out (or gLExec only) to use LCAS and LCMAPS is in the LCAS and LCMAPS installation for gLExec and (GT4) gatekeepers guide.

Programmatic interfaces

Developers that want to integrate LCAS and LCMAPS capabilities directly into their code can use the programmatic interface. Both LCAS and LCMAPS can either be linked to your application at compile-time, or they can be discovered at run-time and dynamically loaded into your application. Over the years, both LCAS and LCMAPS have grown a large variety of public interface, to cater for various usage scenarios. This may impair your abilty to quickly glance the interface which is most appropriate for your business case. We're working on improving this aspect of the documentation, but we're happy to provide help any time. Look at the LCAS LCMAPS API documentation for further details.

Adding your own plug-ins

If you need specific credential mapping functionality, or authorization capability, in your site, you can easily extend the LCAS and LCMAPS systems by writing a plug-in module. The modules are like mini-libraries that can be added to the system without ever having to change the main application. Just add a reference to your new module in the LCAS and LCMAPS configuration files, re-configure the workflow, and you're in business. Example modules are provided to kickstart your development.

Contact

For any questions and comments, please send mail to the Nikhef Grid Middleware Security product team, by email to grid-mw-security at the domain of this web site: nikhef.nl.

The LCAS/LCMAPS Site Access Control suite is developed by Nikhef, the Dutch national institute for sub-atomic physics, PDP group, under contract of EU DataGrid and EGEE, and is co-funded by the European Commission and the Foundation FOM.