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

From PDP/Grid Wiki
Jump to navigationJump to search
Line 19: Line 19:
  
 
=== Example VO-CA-AP files ===
 
=== Example VO-CA-AP files ===
For example:
+
The default vo-ca-ap-file as shipped in <tt>/etc/grid-security/vo-ca-ap-file</tt>
  # Realistic example vo-ca-ap file, to be used with lcmaps-plugins-vo-ca-ap
+
  # 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
 
   
 
   
  # Anything else only for classic, mics and slcs
+
  # 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
+
  # 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 12: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 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 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.