Difference between revisions of "Lcmaps-plugins-vo-ca-ap"
Line 19: | Line 19: | ||
=== Example VO-CA-AP files === | === Example VO-CA-AP files === | ||
− | + | The default vo-ca-ap-file as shipped in <tt>/etc/grid-security/vo-ca-ap-file</tt> | |
− | # Realistic example 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 | # CERN VOs are allowed to use any AP, including IOTA | ||
/atlas file:policy-igtf-classic.info, file:policy-igtf-mics.info,\ | /atlas file:policy-igtf-classic.info, file:policy-igtf-mics.info,\ | ||
Line 31: | Line 31: | ||
file:policy-igtf-slcs.info, file:policy-igtf-iota.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-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 | file:policy-igtf-slcs.info | ||
Or a more elaborate (and '''''NOT''''' realistic) example: | Or 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 can be used only with IGTF classic | ||
/vo_a file:policy-igtf-classic.info | /vo_a file:policy-igtf-classic.info |
Revision as of 10:06, 16 February 2017
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
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
Or 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
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