Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The legacy LCAS framework is designed to take an authorization decision based on various credentials as input, e.g. a certificate and/or VOMS credentials, and provide a yes/no decision. LCAS is a framework that can load and run one or more authorization plugins. Most of the plugin functionality has been reproduced by corresponding LCMAPS plugins. LCAS is no longer actively supported except for existing use cases.

The LCMAPS framework is designed to take various credentials as input, e.g. a certificate and/or VOMS credentials, and map them to Unix credentials as output. Unix credentials are the basic POSIX credentials, i.e. User ID, Group ID and Secondary Group IDs. Just like LCAS, LCMAPS is a pluggable framework, but it provides a much more advanced and flexible plugin engine and a wide variety of plugins exist, including plugins to interface with Argus and GUMS.

LCAS/LCMAPS are currently used in many HTC and storage services deployed in the EGI infrastructure, as well as in cloud services federated in EGI. They are also deployed in OSG and are critical components for the WLCG community.

The two frameworks were developed by Nikhef during the EDG, EGEE I-II-III and EMI projects, and are now maintained by Nikhef. They are open source tools, available – among other sources – in the Fedora community repository EPEL, in Debian, Ubuntu and in the EGI UMD distribution.

Via the lcas-lcmaps-gt4-interface library, LCAS and LCMAPS can be used in e.g. gsissh and GridFTP via the gsi-callout mechanism.

gLExec uses LCMAPS for its mapping decision, providing the sudo-like functionality based on X.509 and VOMS credentials.

Table of Contents


Features

  • Support for VOMS credentials
  • Support for groups and roles within the VOs
  • Support for X.509 proxies extensions to support robot certificates
  • Client for Argus and SCAS.
  • Support for Globus GSI-callout mechanism. 
  • VOMS VO membership allows to group users and hierarchically delegate group membership within the VO


Support for community-based authorisation: through the VOMS extensions, authorization can be based on community attributes (stored on the VOMS server). Using the lcmaps-plugins-vo-ca-ap plugin, it allows for mappings and authorization, which takes into account different levels of assurance.

Supported standards

X.509 (RFC5280, RFC3820), VOMS, SAML2-XACML2 (via plugin).

User Interfaces and APIs

Configuration policies and rules are stored in configuration files, to be edited by the system administrators. The tool, being used as a component of a service, does not directly expose interfaces to the user.

LCAS/LCMAPS provides proprietary but stable and open APIs to push credentials and retrieve authorization and mapping decision results.

Support for Virtual Organisations

LCAS and LCMAPS enable sites to regulate authorization and user separation based on VO membership and specific roles within these VOs. When a VO is supported by a service, a user which is member can be authorized to access this service, e.g. to submit computational tasks to a cluster or retrieve or store data. All the tasks - where relevant - can be mapped to a pool of local users connected to the VO.

Dependencies on other technologies

OpenSSL and Globus libraries.

VOMS C API for the VO credentials.

Operational overview

LCAS and LCMAPS are deployed with the services that use the framework for authorization.

Expected level of support

Nikhef supports LCMAPS, its standard plugins and the lcas-lcmaps-gt-interface for bug fixes and relevant new features. LCAS is only supported for security bug fixes.