Difference between revisions of "Lcmaps-plugins-vo-ca-ap"

From PDP/Grid Wiki
Jump to navigationJump to search
 
Line 33: Line 33:
 
== vo-ca-ap-file ==
 
== vo-ca-ap-file ==
 
=== Format ===
 
=== Format ===
Each line in the vo-ca-ap-file consists of a VO name starting with a leading slash (/) separated by '''white space''' from a '''comma'''-separated list of entries. For VOMS-less proxies, instead of the slash plus VO-name a minus (?) is used. The VO name is matched using a match, allowing for e.g. * wildchars to match any VO.
+
Each line in the vo-ca-ap-file consists of a VO name starting with a leading slash (/) separated by '''white space''' from a '''comma'''-separated list of entries. For VOMS-less proxies, instead of the slash plus VO-name a minus (?) is used. The VO name is matched using a �filename� match, allowing for e.g. * wildchars to match any VO.
  
 
Entries can either be an issuer DN (in OpenSSL notation) or the name of a <tt>.info</tt> file which contains the issuer DNs in the value of the ''subjectdn'' key. An issuer DN can optionally be prefixed with ''issuer:'' while a file must be prefixed with ''file:''
 
Entries can either be an issuer DN (in OpenSSL notation) or the name of a <tt>.info</tt> file which contains the issuer DNs in the value of the ''subjectdn'' key. An issuer DN can optionally be prefixed with ''issuer:'' while a file must be prefixed with ''file:''

Latest revision as of 18:55, 17 November 2022

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 VOCA 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 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 -> ...

vo-ca-ap-file

Format

Each line in the vo-ca-ap-file consists of a VO name starting with a leading slash (/) separated by white space from a comma-separated list of entries. For VOMS-less proxies, instead of the slash plus VO-name a minus (?) is used. The VO name is matched using a �filename� match, allowing for e.g. * wildchars to match any VO.

Entries can either be an issuer DN (in OpenSSL notation) or the name of a .info file which contains the issuer DNs in the value of the subjectdn key. An issuer DN can optionally be prefixed with issuer: while a file must be prefixed with file:

When an issuer DN or filename contains spaces, the entry (excluding the issuer: or file: prefix) should be enclosed in double quotes. A relative filename is taken with respect to the defined certificate directory or its default (/etc/grid-security/certificate).

Reference WLCG / IGTF VO-CA-AP file

The default vo-ca-ap-file as shipped in /etc/grid-security/vo-ca-ap-file

# Realistic example vo-ca-ap file, can 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

# Any other VO only for classic, mics and slcs
/*       file:policy-igtf-classic.info, file:policy-igtf-mics.info,\
         file:policy-igtf-slcs.info

# Any non-VOMS proxy also only for classic, mics and slcs
"-"      file:policy-igtf-classic.info, file:policy-igtf-mics.info,\
         file:policy-igtf-slcs.info

Reference ca-policy-egi-cam.vo-ca-ap as shipped with the ca-policy-egi-cam package

The following file is part of the ca-policy-egi-cam package, in /usr/share/doc/ca-policy-egi/ca-policy-egi-cam.vo-ca-ap, and applicable to those site that install the EGI-repackaged trust anchor distribution (and who thus may not have the IGTF default files used above). It implements the EGI policy on acceptable authentication assurance and the set of VOs as endorsed by virtue of EGI SPG and OMB decisions.

# EGI Combined Adequacy Assurance Model (CAM) reference configuration
# for LCMAPS-plugins-vo-ca-ap. For instructions, see 
#   https://wiki.nikhef.nl/grid/Lcmaps-plugins-vo-ca-ap
# Reference configuation follows https://documents.egi.eu/document/2930
# and associated implementation guidance as for the EGI SPG processes
#
/atlas   file:policy-egi-core.info, file:policy-egi-cam.info
/cms     file:policy-egi-core.info, file:policy-egi-cam.info
/lhcb    file:policy-egi-core.info, file:policy-egi-cam.info
/alice   file:policy-egi-core.info, file:policy-egi-cam.info
/*       file:policy-egi-core.info
#
# for non-VOMS enabled credentials, supports only core policy trust anchors:
"-"      file:policy-egi-core.info

Other example vo-ca-ap-file

A more elaborate (and NOT realistic) example:

# NOT-realistic example vo-ca-ap file, DO NOT USE IN PRODUCTION
# 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

Software

The current version is 0.0.2-1 and can be found in the Official EGI UMD-3 and UMD-4 repos.