Difference between revisions of "EGI Quality Criteria Testing"
Line 168: | Line 168: | ||
|- | |- | ||
|} | |} | ||
If you don't belong to those VOs or want to test other banning policies (e.g. on your user DN), you need to contact the verification team for adding new rules into the ARGUS instance. | |||
[[Category:Technology]] [[Category:Quality_Assurance]] | [[Category:Technology]] [[Category:Quality_Assurance]] |
Revision as of 13:16, 20 March 2013
Quality Criteria Testing
Verifiers should adjust the level of testing for each release (major, minor, revision) as described in the Verifiers guideline. They must also consider that some of the QC included in the documents are also checked during Stage-Rollout. This list include the mandatory criteria that must be checked for all verifications:
QC | Description |
---|---|
GENERIC_DIST_3 | Valid binary packages must be available for the tested platform |
GENERIC_SEC_1 | No world-writable files are used in the product |
INFO_MODEL_SCHEMA_1 | Glue1.3 & Glue2 support |
INFO_MODEL_SCHEMA_2 | Version of middleware published |
AUTHN_CRED_2 | Use of SHA-2 certificates/proxies |
AUTHN_CRED_3 | Use of RFC proxies |
AUTHZ_PEP_3 | Argus integration (only if the service requires some form of authz) |
How to test criteria
Generic
GENERIC_DIST_3
The product must be installable from the UMD repository (+ epel if using RH based distros) with no extra packages coming from other sources. All packages must be signed.
Ideally a meta-package fetches all dependencies. Installing should be done with the regular package management tools of the distro (rh based):
yum install <meta-package>
or (debian based):
apt-get install <meta-package>
The packages should not create any files outside the regular OS locations: use of /opt is discouraged, if files are created there, the QC passes, but a note should be included in the report (except for yaim packages)
GENERIC_SEC_1
An easy way to find world-writable files is using the find command:
find / -type f -perm -002 -exec ls -l {} \;
For finding world-writable files in the packages contents:
rpm -qalv | egrep "^[-d]([-r][-w][-xs]){2}[-r]w"
Information Model Capability
INFO_MODEL_SCHEMA_1
Use GlueValidator for testing the validity of both Glue1.3 and Glue2.
Some exceptions may be allowed:
- AssertionError: The field GLUE2EndpointCapability with value 'information.publication' does not follow the type Capability_t
INFO_MODEL_SCHEMA_2
The basic query would be something like:
ldapsearch -x -h <hostname> -p 2170 -b GLUE2GroupID=resource,o=glue objectclass=GLUE2Endpoint
That should return one or more Endpoint objects, containing attributes like
GLUE2EndpointImplementationVersion: 2.7.0 GLUE2EntityOtherInfo: MiddlewareVersion=2.5.1-1
Authentication Capability
AUTHN_CRED_2
If you do not have valid SHA-2 certificates, you can get one using a provider like CILogon, using their (unaccredited) OpenID provider like Google
(instructions from D. Groep)
- Go to https://cilogon.org/
- Select "Google" from the list of IdPs.
- After signing in to Google and typing in a password, you can download a pkcs#12 file with your new certificate and private key.
- To get the conventional usercert.pem and userkey.pem, use openssl:
openssl pkcs12 -in myfile.p12 -info -out usercert.pem -nokeys openssl pkcs12 -in myfile.p12 -info -out userkey.pem -nocerts chmod 0600 userkey.pem
Services to test need to have the OpenID CA just like the other IGTF CAs, which is available from the experimental repository. A RPM package is also provided.
SA2 VM images also include SHA-2 certificates into /etc/grid-security directory (hostcert-SHA2.pem and hostkey-SHA2.pem). These certificates could replace /etc/grid-security/hostcert.pem and /etc/grid-security/hostkey.pem to check SHA-2 service support. First of all backup the old certificates:
cp /etc/grid-security/hostcert.pem /etc/grid-security/hostcert.pem.orig cp /etc/grid-security/hostkey.pem /etc/grid-security/hostkey.pem.orig
And replace them by the new SHA2 certificates:
cp /etc/grid-security/hostcert-SHA2.pem /etc/grid-security/hostcert.pem cp /etc/grid-security/hostkey-SHA2.pem /etc/grid-security/hostkey.pem
An then reconfigure/restart the service.
AUTHN_CRED_3
RFC proxies can be created by using the -rfc option in voms-proxy-init:
$ voms-proxy-init -rfc --voms dteam Your identity: /DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo Creating temporary proxy .......................................... Done Contacting voms.hellasgrid.gr:15004 [/C=GR/O=HellasGrid/OU=hellasgrid.gr/CN=voms.hellasgrid.gr] "dteam" Done Creating proxy ...................................... Done Your proxy is valid until Thu Aug 2 01:01:26 2012
You can check if the proxy has RFC format with voms-proxy-info:
$ voms-proxy-info --all subject : /DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo/CN=3300543 issuer : /DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo identity : /DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo type : RFC compliant proxy strength : 1024 bits path : /nfs4/home/local/enol/.x509up_u7056 timeleft : 11:59:52 === VO dteam extension information === VO : dteam subject : /DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo issuer : /C=GR/O=HellasGrid/OU=hellasgrid.gr/CN=voms.hellasgrid.gr attribute : /dteam/Role=NULL/Capability=NULL timeleft : 11:59:51 uri : voms.hellasgrid.gr:15004
AUTHZ_PEP_3
This criterion needs to be checked for every product that requires some sort of authorization. You will need a working ARGUS instance where the policies are defined. The verification testbed includes one ARGUS instance at test10.egi.cesga.es that can be used for this test.
There are two different resources for testing the test10.egi.cesga.es ARGUS service, one lets any user from ops, dteam or ops.vo.ibergrid.eu VOs to perform any action (".*") and is configured using these values:
Argus endpoint | https://test30.egi.cesga.es:8154/authz |
---|---|
Resource | http://test30.egi.cesga.es/policy |
For testing banning policies, there is another resource that lets users from ops.vo.ibergrid.eu but bans dteam users. This resource can be configured with:
Argus endpoint | https://test30.egi.cesga.es:8154/authz |
---|---|
Resource | http://test30.egi.cesga.es/deny |
If you don't belong to those VOs or want to test other banning policies (e.g. on your user DN), you need to contact the verification team for adding new rules into the ARGUS instance.