Difference between revisions of "EMI Argus-EES test plan"

From PDP/Grid Wiki
Jump to navigationJump to search
 
Line 83: Line 83:
 
==== EES preparation ====
 
==== EES preparation ====
  
The installation default of the '''/etc/glexec.conf''' file will work fine, but you'll need to whitelist yourself to authorize your account to use gLExec.
+
The default '''/etc/ees.conf''' configuration file will contain the EES transformer plugin which is able to decode obligations from incoming XACML requests. Here is a '''ees.conf''' snippet which loads the transformer plug-in:
  
Whitelist yourself in the /etc/glexec.conf:
+
  # plug-ins
user_white_list              = okoeroo
+
    transformer        = "ees_plugin_transformer.mod"
 +
    good              = "ees_dummy_good.mod"
 +
  # policies
 +
  transformer:
 +
    transformer -> good
 +
 
 +
To test integration in the Argus PEPd, configure the EES OH in the pepd.ini configuration file.
  
 
==== PEPd preparation ====
 
==== PEPd preparation ====
 
+
Install the OH plug-in .jar file by copying it to /opt/argus/pepd/lib/ or equivalent PEPd library directory.
Configure gLExec to use LCAS and to use the specified '''lcas.db'''. Here is a '''glexec.conf''' snippet:
+
Configure the PEPd to use the EES OH and specify the url of a running EES instance. Here is a '''pepd.ini''' snippet:
use_lcas                    = yes
+
  [EES_OH]
lcas_db_file                = /etc/lcas/lcas-testing.db
+
  ENDPOINT = http://ees_instance:6217/
lcas_log_file                = /var/log/glexec/lcas_lcmaps.log
+
  parserClass = org.glite.authz.pep.obligation.eesmap.EESObligationHandlerConfigurationParser
lcas_debug_level            = 5
 
 
The '''/etc/lcas/lcas-testing.db''' would then look like:
 
# LCAS policy file/plugin definition
 
pluginname=/usr/lib64/modules/lcas_userban.mod,pluginargs=/etc/lcas/userban.db
 
 
 
Touch the file '''/etc/lcas/userban.db''', otherwise the LCAS UserBan module will fail on the inability to read the userban.db file.
 
 
 
==== LCMAPS preparation ====
 
 
 
lcmaps_db_file              = /etc/lcmaps/lcmaps-testing.db
 
lcmaps_get_account_policy    = test_policy
 
lcmaps_log_file              = /var/log/glexec/lcas_lcmaps.log
 
lcmaps_debug_level          = 5
 
 
The '''/etc/lcmaps/lcmaps-testing.db''' would then look like:
 
# LCMAPS policy file/plugin definition
 
 
 
# default path for the modules
 
path = /usr/lib64/modules/
 
 
 
# Plugin definitions:
 
good            = "lcmaps_dummy_good.mod"
 
                    " --dummy-username nobody"
 
                    " --dummy-group nobody"
 
                    " --dummy-sec-group nobody"
 
 
 
posix_enf        = "lcmaps_posix_enf.mod"
 
                    " -maxuid 1"
 
                    " -maxpgid 1"
 
                    " -maxsgid 32"
 
 
 
verifyproxy = "lcmaps_verify_proxy.mod"
 
              " -certdir /etc/grid-security/certificates"
 
 
 
# Policies:
 
test_policy:
 
verifyproxy -> good
 
good -> posix_enf
 
  
 
=== Basic functionality tests (manual) ===
 
=== Basic functionality tests (manual) ===
 +
Configure [[glExec]] to use the '''lcmaps-plugins-c-pep''' plug-in and the  '''lcmaps-plugins-basic''' plug-in.
 +
Configure the C-PEP plug-in to connect to your running PEPd instance and configure the '''LCMAPS good''' plug-in to map to the 'nobody:nobody' account. The expected result is a account mapping by glExec to the user 'nobody:nobody' account.
 +
This can be verified by running the following command.
 +
  glexec /usr/bin/id -a
 +
And,
 +
verifying activity by the PEPd and the EES by tailing their log files, '''/opt/argus/bla'''
  
Have proxy certificate on the test system, here located at $HOME/mkproxy-x509-voms. Using the following gLExec script to activate gLExec with your own user certificate:
+
=== Performance tests ===
#!/bin/sh
 
 
GLEXEC_BIN="/usr/sbin/glexec"
 
if [ ! -f ${GLEXEC_BIN} ]; then
 
    GLEXEC_BIN="${GLEXEC_LOCATION}/sbin/glexec"
 
    if [ ! -f ${GLEXEC_BIN} ]; then
 
        echo "No glexec found"
 
        exit 1
 
    fi
 
fi
 
 
if [ "${X509_USER_PROXY}" = "" ]; then
 
    export X509_USER_PROXY=$HOME/mkproxy-x509-voms
 
fi
 
 
export GLEXEC_CLIENT_CERT=${X509_USER_PROXY}
 
export GLEXEC_SOURCE_PROXY=${X509_USER_PROXY}
 
 
#echo "------------"
 
cmd="${GLEXEC_BIN} /usr/bin/id -a"
 
 
$cmd
 
echo $?
 
exit 0
 
  
Run the test script and the following result is expected:
 
[okoeroo@localhost ~]$ ./test-glexec.sh
 
uid=99(nobody) gid=99(nobody) groups=99(nobody)
 
0
 
 
=== Test setup (automated) ===
 
 
Download the [https://ndpfsvn.nikhef.nl/cgi-bin/viewvc.cgi/mwsec/trunk/glexec/test/glexec-lcas-lcmaps-compound-test.sh?view=markup gLExec (and LCAS/LCMAPS) compound test script]. The [https://ndpfsvn.nikhef.nl/cgi-bin/viewvc.cgi/mwsec/trunk/glexec/test/glexec-lcas-lcmaps-compound-test.sh?revision=15284&view=markup SVN revision number 15284 of the compound test script] was used.
 
 
 
WARNING: The script will rewrite the '''glexec.conf''' file multiple times to test all possible permutations of the configuration file. Also the LCAS and LCMAPS configuration files will be rewritten (in '''lcas-testing.db''' and '''lcmaps-testing.db''' files) to work.
 
 
 
Edit the script to configure it. Here is what was used for this certification:
 
#################
 
# Setup options #
 
#################
 
CONTINUEONERROR=no
 
 
TEST_ACCOUNT="okoeroo"
 
 
GLEXEC_EXEC="/usr/sbin/glexec"
 
GLEXEC_OWNERSHIP_SETUID="root.root"
 
GLEXEC_FILE_PERM_SETUID="6555"
 
GLEXEC_OWNERSHIP_NON_SETUID="root.root"
 
GLEXEC_FILE_PERM_NON_SETUID="0555"
 
 
CONF_OWNERSHIP_SETUID="glexec.glexec"
 
CONF_FILE_PERM_SETUID="0440"
 
CONF_OWNERSHIP_NON_SETUID="root.root"
 
CONF_FILE_PERM_NON_SETUID="0444"
 
 
test_glexec_conf="/etc/glexec.conf"
 
test_lcas_db="/etc/lcas/lcas-testing.db"
 
test_lcas_db_path="/usr/lib64/modules/"
 
test_lcas_log_file="/var/log/glexec/lcas_lcmaps.log"
 
test_lcas_userban_file="/etc/lcas/userban.db"
 
test_lcas_debug_level="0"
 
 
test_lcmaps_db="/etc/lcmaps/lcmaps-testing.db"
 
test_lcmaps_db_path="/usr/lib64/modules/"
 
test_lcmaps_log_file="/var/log/glexec/lcas_lcmaps.log"
 
test_lcmaps_debug_level="0"
 
 
priv_sep_file="/tmp/glexec_priv_sep_test.sh"
 
CAPATH="/etc/grid-security/certificates"
 
SCAS_ENDPOINT="https://eir.nikhef.nl:8443"
 
PEPD_ENDPOINT="https://argus.testbed:8154/authz"
 
GLEXEC_TEST_GRID_MAPFILE="/tmp/glexec-test-grid-mapfile"
 
 
LOCALACCOUNT_TEST_MAP_USER="$TEST_ACCOUNT"
 
#LOCALACCOUNT_TEST_MAP_USER="pool001"
 
POOLACCOUNT_TEST_MAP_USER=".pool"
 
 
### Test selection ###
 
USE_SCAS="yes"
 
USE_SCAS=""
 
 
#################
 
# Setup proxies #
 
#################
 
CLIENT_CERT="/home/okoeroo/mkproxy-x509-voms"
 
USER_PROXY="$CLIENT_CERT"
 
SOURCE_PROXY="$CLIENT_CERT"
 
TARGET_PROXY="/tmp/target_proxy"
 
 
=== Basic functionality tests (automated) ===
 
 
Execute the script as '''root''' after properly configuring the script. See previous section for details:
 
sh glexec-lcas-lcmaps-compound-test.sh
 
 
Output:
 
http://www.nikhef.nl/grid/ndpf/files/EMI_1_SAC_documentation/certification_output/glexec-lcas-lcmaps-compound-test.28-april-2011.out
 
  
 
=== Regression tests ===
 
=== Regression tests ===
 
+
Not applicable
Savannah bug [https://savannah.cern.ch/bugs/?53192 53192]: '''scas-client: segfaults with malformed lcmaps-glexec.db''' (implemented):
 
 
 
The SCAS-client plugin will not trigger a segmentation fault and pull gLExec with it when the SCAS host is not a FQDN.
 
 
 
Savannah bug [https://savannah.cern.ch/bugs/?77130 77130 ]: '''[lcmaps-plugins-scas] crashes on invalid -capath''' (implemented):
 
 
 
Verified by moving the CA path and reconfiguring the SCAS plugin to use an non-existing directory as -capath value.
 
 
 
Savannah bug [https://savannah.cern.ch/bugs/?80927 80927]: '''bug #80927: [LCMAPS] Mapping fails if VOMS AC contains a generic attribute''' (implemented):
 
 
 
Added VOMS generic attributes to the VO registration in the VOMS service.
 
 
 
Savannah bug [https://savannah.cern.ch/bugs/?80822 80882]: '''LCMAPS-plugins-c-pep cannot read proxy from NFS partition''' (not implemented):
 
 
 
Tested but turns out that the tests were not done properly with a false-positive as a result. The package version 1.1.4 fixes this problem. The 1.1.3 works as advertised on all other use cases.
 
 
 
Savannah bug [https://savannah.cern.ch/bugs/?80815 80815]: '''GLExec support for tracking group ids''' (implemented):
 
 
 
The gLExec and LCMAPS suite now has a plugin called the [[LCMAPS_Tracking_GroupID_plugin]] and supports the tracking groupid feature of Condor, Sun Grid Engine and other batch systems.
 
 
 
Savannah bug [https://savannah.cern.ch/bugs/?80548 80548]: '''GLExec possible segfault when reading proxy''' (implemented):
 
 
 
When reading a proxy file, the '\0' is added at the end, before we're sure if we didn't have an I/O error.
 
 
 
Savannah bug [https://savannah.cern.ch/bugs/?80547 80547]: ''GLExec segfaults if argc == 0'''' (implemented):
 
 
 
When gLExec is called using e.g. execve with NULL as argument list (i.e. resulting internally in argc==0) it segfaults.
 
 
 
Savannah bug [https://savannah.cern.ch/bugs/?79988 79988]: '''gLExec crashes when no explicit linger option is set in the glexec.conf''' (implemented):
 
 
 
When the glexec.conf does not contain either linger=yes or linger=no, gLExec crashes. Since the default is equivalent to specifying linger=yes, it's easy to work around.
 
 
 
Savannah bug [https://savannah.cern.ch/bugs/?57746 57746]: '''Error "could not get X509 cred from gss credential!" when using gridftp but normal job submission works''' (implemented):
 
 
 
The proxy handling from the lcas-lcmaps-gt4-interface to the LCAS and LCMAPS interface has been fixed to cope with this.
 
 
 
Savannah bug [https://savannah.cern.ch/bugs/?60825 60825]: '''Strange characters in LCAS plugin string''' (implemented):
 
 
 
A fix was made in the LCAS framework and the problem doesn't occur anymore.
 
 
 
Savannah bug [https://savannah.cern.ch/bugs/?64535 64535]: '''no lcmaps/lcas logs for gridftp''' (implemented):
 
 
 
The logs appear in both the log files, when the proper LCAS_LOG_FILE or LCMAPS_LOG_FILE are exported. Also Syslog will be used by default and works.
 
 
 
Savannah bug [https://savannah.cern.ch/bugs/?80647 80647]: '''LCAS authorizes me but reports that I am not''' (implemented):
 
 
 
This is fixed. The LCAS framework authorization decision isn't ignored anymore for the lcas-lcmaps-gt4-interface.
 
 
 
Savannah bug [https://savannah.cern.ch/bugs/?80900 80900]: '''LCAS fails to find the VOMS credentials on a GridFTPd''' (implemented):
 
 
 
The proxy handling from the lcas-lcmaps-gt4-interface to LCAS is now fixed to the older (and faster) method and grabs the right credentials for a decision and passing to the VOMS api.
 

Revision as of 09:50, 29 April 2011

This test plan is following the EMI SA2 template.

EES Test Plan

Service Description

The EES is a daemon that acts as an obligation transformer for requests to the PEPd. The EES takes SAML2-XACML2 authorization request messages as input. The EES takes the local site policy into account to transform the incoming request. The EES will start a new execution thread and apply the defined policy to the incoming request.

More information on the EES.

Yum Installation

To install the EES configure the YUM-based EPEL repository and the YUM repository which hold our the EMI packages. The IGTF distribution can also be done through a YUM-based repository, including the FetchCRL3 utility to refresh the CA CRLs.

The EES depends directly on:

  • SAML2-XACML2-C-LIB
  • (g)libc

EES configurations specify plugins which operate on the incoming request. The EES ships with a transformer plug-in, which is used to unpack XACML obligations from an XACML request from the PDP.

Install the EES service by performing: yum install ees This will install the package ees which will pull in the following packages:

  • ees
  • saml2-xacml2-c-lib

Install the EES obligation handler by performing: yum install ees-pepd-oh This will install the package ees-pepd-oh which will pull in the following packages:

  • argus-pep-server
  • java

This is the first release of the EES service and the EES obligation handler in EMI. There is nothing to upgrade from.

System tests

Test setup EES

First we install and setup the system for testing. This means to prepare the system taking a clean CentOS 5 or Scientific Linux 5 machine as a baseline.

yum install ees

The basic installation is now done. We can now test the basic functionality of the EES by using the following script.

#!/bin/bash

# Configuration
host=0.0.0.0
port=6217

MSG='<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:XACMLcontext="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:XACMLassertion="urn:oasis:names:tc:xacml:2.0:profile:saml2.0:v2:schema:assertion" xmlns:XACMLpolicy="urn:oasis:names:tc:xacml:2.0:policy:schema:os" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:XACMLService="http://www.globus.org/security/XACMLAuthorization/bindings" xmlns:XACMLsamlp="urn:oasis:names:tc:xacml:2.0:profile:saml2.0:v2:schema:protocol" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<SOAP-ENV:Body>
<XACMLsamlp:XACMLAuthzDecisionQuery CombinePolicies="true" ReturnContext="true" InputContextOnly="false" IssueInstant="2010-03-25T14:55:01Z" Version="2.0" ID="ID-1804289383">
<saml:Issuer xsi:type="saml:NameIDType" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">NetCat</saml:Issuer>
<XACMLcontext:Request xsi:type="XACMLcontext:RequestType">
<XACMLcontext:Action xsi:type="XACMLcontext:ActionType">
</XACMLcontext:Action>
</XACMLcontext:Request>
</XACMLsamlp:XACMLAuthzDecisionQuery>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
'

# Takes three args, a test string and a pattern to match to
test_main() {
  output=`echo -n "$1" | nc -n -i1 $host $port | grep -w "$2"`
  if [ -z "$output" ]
  then
    echo "ERR"
  else
    echo "OK"
  fi  
}

echo -n "Basic sanity test\t"
test_main "$MSG" "200 OK"
echo -n "Basic failure test\t"
test_main "<TEST>" "500 Internal"

Test setup EES Obligation handler

EES preparation

The default /etc/ees.conf configuration file will contain the EES transformer plugin which is able to decode obligations from incoming XACML requests. Here is a ees.conf snippet which loads the transformer plug-in:

 # plug-ins
   transformer        = "ees_plugin_transformer.mod"
   good               = "ees_dummy_good.mod"
 # policies
 transformer:
   transformer -> good

To test integration in the Argus PEPd, configure the EES OH in the pepd.ini configuration file.

PEPd preparation

Install the OH plug-in .jar file by copying it to /opt/argus/pepd/lib/ or equivalent PEPd library directory. Configure the PEPd to use the EES OH and specify the url of a running EES instance. Here is a pepd.ini snippet:

 [EES_OH]
 ENDPOINT = http://ees_instance:6217/
 parserClass = org.glite.authz.pep.obligation.eesmap.EESObligationHandlerConfigurationParser

Basic functionality tests (manual)

Configure glExec to use the lcmaps-plugins-c-pep plug-in and the lcmaps-plugins-basic plug-in. Configure the C-PEP plug-in to connect to your running PEPd instance and configure the LCMAPS good plug-in to map to the 'nobody:nobody' account. The expected result is a account mapping by glExec to the user 'nobody:nobody' account. This can be verified by running the following command.

 glexec /usr/bin/id -a

And, verifying activity by the PEPd and the EES by tailing their log files, /opt/argus/bla

Performance tests

Regression tests

Not applicable