Lcmaps-plugins-vo-ca-ap

Introduction

The LCMAPS-plugins-vo-ca-ap package provides the functionality for making authorization decisions based on the combination of an Authentication Profile (AP) or CA signing the End-Entity certificate and VO used by the user.

Background

Until recently a site would typically accept any signing CA, as long as it belonged to any of the supported IGTF APs. A site could only selectively decide not to support a certain AP or CA. On the other hand, with the advent of using federated logins and logins using social IdPs such as Google and Facebook, some (typically online) CAs have a lower 'Level of Assurance' (LoA). This has led to the IGTF IOTA Profile.

In itself such a lower LoA would not be sufficient for allowing a user to enter a site. On the other hand, certain VOs do a strong identity vetting before allowing users into their VO. In such cases, the combined LOA would actually be sufficient to trust a user into a site. As a temporarily solution, CERN has introduced a new CA, the CERN IOTA CA, which is an IOTA CA, but will only produce certificates for users that are member of one of the (strongly vetted) CERN VOs. Such a solution can only be employed on a temporary or one-off basis, for a proper solution it is necessary to be able to perform combined VO+AP+CA authorization decisions. This LCMAPS plugin provides the necessary logic to make that possible.

Usage

The plugin should be inserted somewhere in a LCMAPS policy, but preferable at the beginning. The plugin accepts two arguments,

-vo-ca-ap-file	File containing VO ↔ CA or AP mapping
-certdir or -capath	Directory containing the .info files, default /etc/grid-security/certificates

Each line in the vo-ca-ap file first contains the name of a VO (starting with a slash and allowing wildchars), followed by a list of DNs or .info files. Long lines can be broken using a continuation character \, and anything after a # is ignored.

Example VO-CA-AP files

For example:

# Realistic example vo-ca-ap file, to be used with lcmaps-plugins-vo-ca-ap
# CERN VOs are allowed to use any AP, including IOTA
/atlas   file:policy-igtf-classic.info, file:policy-igtf-mics.info,\
         file:policy-igtf-slcs.info,    file:policy-igtf-iota.info
/cms     file:policy-igtf-classic.info, file:policy-igtf-mics.info,\
         file:policy-igtf-slcs.info,    file:policy-igtf-iota.info
/lhcb    file:policy-igtf-classic.info, file:policy-igtf-mics.info,\
         file:policy-igtf-slcs.info,    file:policy-igtf-iota.info
/alice   file:policy-igtf-classic.info, file:policy-igtf-mics.info,\
         file:policy-igtf-slcs.info,    file:policy-igtf-iota.info

# Anything else only for classic, mics and slcs
/*       file:policy-igtf-classic.info, file:policy-igtf-mics.info,\
         file:policy-igtf-slcs.info

Or a more elaborate (and NOT realistic) example:

# Not-realistic example vo-ca-ap file
# VO A can be used only with IGTF classic
/vo_a    file:policy-igtf-classic.info

# VO B can be used with IGTF classic, or a CERN CA specified either using DN or with its info file
/vo_b    file:policy-igtf-classic.info, "/DC=ch/DC=cern/CN=CERN Grid Certification Authority",\
         file:CERN-Root-2.info

# Test VO, can only be used with two Example CAs
/testvo  "/DC=org/O=example/CN=First Example Certificate Authority", \
         "/DC=org/O=example/CN=The Other Example Certificate Authority"

# Any other VO should only allowed for Classic and MICS
/*       file:policy-igtf-classic.info, file:policy-igtf-mics.info

# Non-VOMS proxies only allowed for Classic
"-"      file:policy-igtf-classic.info

Example lcmaps.db file

The plugin would typically called in an LCMAPS db file like:

[...]
vo_ca_ap = "lcmaps_vo_ca_ap.mod"
           " -certdir /etc/grid-security/certificates"
           " -vo_ca_ap_file /etc/grid-security/vo-ca-ap-file"
[...]

# policies
mapping:
vo_ca_ap -> my-first-plugin
my-first-plugin -> ...

Software

The current version is 0.0.1-1

• release tar-balls
• Nikhef signed RPMs use epel5, epel6 or epel7 for RH5, RH6 and RH7 compatible.
• Debian packages