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.2-1 and can be found in the Official EGI UMD-3 and UMD-4 repos.
- release tar-balls
- Nikhef signed RPMs use epel5, epel6 or epel7 for RH5, RH6 and RH7 compatible.
- Debian packages