Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "EGI Quality Criteria Testing"

From EGIWiki
Jump to navigation Jump to search
m
 
(22 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Category: Technology ]]
<br>
[[Category: Quality Assurance]]


== Quality Criteria Level of Testing ==
== 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:
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:  


<br>


{| cellspacing="0" cellpadding="3" border="1" style="border: 1px solid black;" class="wikitable sortable"
{| cellspacing="0" cellpadding="3" border="1" style="border: 1px solid black;" class="wikitable sortable"
Line 12: Line 12:
! Description
! Description
|-
|-
| GENERIC_DIST_3
| GENERIC_DIST_3  
| Valid binary packages must be available for the tested platform
| Valid binary packages must be available for the tested platform
|-
|-
| GENERIC_SEC_1
| GENERIC_SEC_1  
| No world-writable files are used in the product
| No world-writable files are used in the product
|-
|-
| INFO_MODEL_SCHEMA_1
| INFO_MODEL_SCHEMA_1  
| Glue1.3 & Glue2 support
| Glue1.3
|-
|-
| INFO_MODEL_SCHEMA_2  
| INFO_MODEL_SCHEMA_2  
| Version of middleware published
| Version of middleware published
|-
| INFO_MODEL_SCHEMA_3
| Glue 2
|-
| 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  ====


== How to test criteria ==
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'''.


=== Generic ===
Ideally a meta-package fetches all dependencies. Installing should be done with the regular package management tools of the distro (rh based):


==== GENERIC_DIST_3 ====
yum install &lt;meta-package&gt;


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'''.
or (debian based):


Ideally a meta-package fetches all dependencies. Installing should be done with the regular package management tools of the distro (rh based):
  apt-get install &lt;meta-package&gt;
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)
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 ====
==== GENERIC_SEC_1 ====


An easy way to find world-writable files is using the find command:
An easy way to find world-writable files is using the find command:  


  find / -type f -perm -002 -exec ls -l {} \;
  find / -type f -perm -002 -exec ls -l {} \;


For finding world-writable files in the packages contents:
For finding world-writable files in the packages contents:  


  rpm -qalv | egrep "^[-d]([-r][-w][-xs]){2}[-r]w"
  rpm -qalv | egrep "^[-d]([-r][-w][-xs]){2}[-r]w"


=== Information Model Capability ===
=== Information Model Capability ===
 
==== INFO_MODEL_SCHEMA_1  ====


==== INFO_MODEL_SCHEMA_1 ====
Use [https://tomtools.cern.ch/confluence/display/IS/GLUEValidator GlueValidator] for testing the validity of both Glue1.3 and Glue2. More info about GLUEValidator is available [http://gridinfo.web.cern.ch/glue/glue-validator-guide here]


Use [https://tomtools.cern.ch/confluence/display/IS/GLUEValidator GlueValidator] for testing the validity of both Glue1.3 and Glue2.
Some exceptions may be allowed:  


Some exceptions may be allowed:
*AssertionError: The field GLUE2EndpointCapability with value 'information.publication' does not follow the type Capability_t  
* AssertionError: The field GLUE2EndpointCapability with value 'information.publication' does not follow the type Capability_t
*
*


==== INFO_MODEL_SCHEMA_2 ====
==== INFO_MODEL_SCHEMA_2 ====


The basic query would be something like:
The basic query would be something like:  


  ldapsearch -x -h <hostname> -p 2170 -b GLUE2GroupID=resource,o=glue objectclass=GLUE2Endpoint
  ldapsearch -x -h &lt;hostname&gt; -p 2170 -b GLUE2GroupID=resource,o=glue objectclass=GLUE2Endpoint


That should return one or more Endpoint objects, containing attributes like
That should return one or more Endpoint objects, containing attributes like  


  GLUE2EndpointImplementationVersion: 2.7.0
  GLUE2EndpointImplementationVersion: 2.7.0
  GLUE2EntityOtherInfo: MiddlewareVersion=2.5.1-1
  GLUE2EntityOtherInfo: MiddlewareVersion=2.5.1-1


=== Authentication Capability ===  
GLUEValidator UMD3 installation:
 
yum install glue-validator
 
GLUEValidator usage:
 
glue-validator -g egi-glue2 -H localhost -p 2170 -b o=glue -s egi-profile -n -v 3 --exclude-known-issues
 
A complete list of glue-validator Error Codes is available [https://twiki.cern.ch/twiki/bin/view/EGEE/GLUEValidatorErrorCodes here].
 
=== Authentication Capability ===


==== AUTHN_CRED_2 ====
==== 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
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)
(instructions from D. Groep)  


# Go to https://cilogon.org/
#Go to https://cilogon.org/  
# Select "Google" from the list of IdPs.  
#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.  
#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:
#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 usercert.pem -nokeys
Line 90: Line 114:
  chmod 0600 userkey.pem
  chmod 0600 userkey.pem


Services to test need to have the OpenID CA just like the other IGTF CAs, which is available from the [https://dist.eugridpma.info/distribution/current/experimental/ experimental repository]. A [https://dist.eugridpma.info/distribution/current/experimental/RPMS/ca_cilogon-openid-1.48-1.noarch.rpm RPM package] is also provided.
Services to test need to have the OpenID CA just like the other IGTF CAs, which is available from the [https://dist.eugridpma.info/distribution/current/experimental/ experimental repository]. A [https://dist.eugridpma.info/distribution/current/experimental/RPMS/ca_cilogon-openid-1.48-1.noarch.rpm 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


==== AUTHN_CRED_3 ====
An then reconfigure/restart the service.


RFC proxies can be created by using the <tt>-rfc</tt> option in voms-proxy-init:
==== AUTHN_CRED_3  ====


<pre>
RFC proxies can be created by using the <tt>-rfc</tt> option in voms-proxy-init:
$ voms-proxy-init -rfc --voms dteam
<pre>$ voms-proxy-init -rfc --voms dteam
Your identity: /DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo
Your identity: /DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo
Creating temporary proxy .......................................... Done
Creating temporary proxy .......................................... Done
Line 103: Line 137:
Creating proxy ...................................... Done
Creating proxy ...................................... Done
Your proxy is valid until Thu Aug  2 01:01:26 2012
Your proxy is valid until Thu Aug  2 01:01:26 2012
</pre>
</pre>  
You can check if the proxy has RFC format with voms-proxy-info:
<pre>$ voms-proxy-info --all
subject  &nbsp;: /DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo/CN=3300543
issuer  &nbsp;: /DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo
identity &nbsp;: /DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo
type    &nbsp;: RFC compliant proxy
strength &nbsp;: 1024 bits
path    &nbsp;: /nfs4/home/local/enol/.x509up_u7056
timeleft &nbsp;: 11:59:52
=== VO dteam extension information ===
VO      &nbsp;: dteam
subject  &nbsp;: /DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo
issuer  &nbsp;: /C=GR/O=HellasGrid/OU=hellasgrid.gr/CN=voms.hellasgrid.gr
attribute&nbsp;: /dteam/Role=NULL/Capability=NULL
timeleft &nbsp;: 11:59:51
uri      &nbsp;: voms.hellasgrid.gr:15004
</pre>
==== 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 <tt>test30.egi.cesga.es</tt> that can be used for this test.
 
Configure the service with the following values for testing a policy where any user from <tt>ops</tt>, <tt>dteam</tt> or <tt>ops.vo.ibergrid.eu</tt> VOs is allowed to perform any action (<tt>".*"</tt>):
 
{| cellspacing="0" cellpadding="5" style="border:1px solid black;" class="wikitable"
|-
! Argus endpoint
| <tt><nowiki>https://test30.egi.cesga.es:8154/authz</nowiki></tt>
|-
! Resource
| <tt><nowiki>http://test30.egi.cesga.es/policy</nowiki></tt>
|}
 
For testing banning policies, there is another resource that lets users from <tt>ops.vo.ibergrid.eu</tt> and <tt>ops</tt>, but bans <tt>dteam</tt> users. This resource can be configured with:
 
{| cellspacing="0" cellpadding="5" style="border:1px solid black;" class="wikitable"
|-
! Argus endpoint
| <tt><nowiki>https://test30.egi.cesga.es:8154/authz</nowiki></tt>
|-
! Resource
| <tt><nowiki>http://test30.egi.cesga.es/deny</nowiki></tt>
|}
 
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.


You can check if the proxy has RFC format with voms-proxy-info:
[[Category:Technology]] [[Category:Quality_Assurance]]
<pre>
$ 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
</pre>

Latest revision as of 08:21, 14 August 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
INFO_MODEL_SCHEMA_2 Version of middleware published
INFO_MODEL_SCHEMA_3 Glue 2
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. More info about GLUEValidator is available here

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

GLUEValidator UMD3 installation:

yum install glue-validator

GLUEValidator usage:

glue-validator -g egi-glue2 -H localhost -p 2170 -b o=glue -s egi-profile -n -v 3 --exclude-known-issues

A complete list of glue-validator Error Codes is available here.

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)

  1. Go to https://cilogon.org/
  2. Select "Google" from the list of IdPs.
  3. After signing in to Google and typing in a password, you can download a pkcs#12 file with your new certificate and private key.
  4. 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 test30.egi.cesga.es that can be used for this test.

Configure the service with the following values for testing a policy where any user from ops, dteam or ops.vo.ibergrid.eu VOs is allowed to perform any action (".*"):

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 and ops, 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.