VOMS Test Plan

YAIM-VOMS Configuration testing

Both glite-VOMS_oracle an glite-VOMS_mysql should be configured with site-info.def containing at least 2 VOs (DNS-named and simple-named one).

Important use cases that should be covered

• VO that operates in short FQAN mode
• VO that has web registration disabled
• VO that has custom value for membership requests timeout configured
• VO that uses a database user with read only access to the VOMS database

Upon successful configuration, each VO should be tested by using

• voms-admin CLI - simple VO management operation (create user, etc) to prove the voms-admin server is working as expected.
• voms-core cli - requesting a simple proxy to verify FQAN format, proxy lifetime enforcement

Information system

Verify that the voms-core and voms-admin entries are present, the voms-core service ports and voms-admin endpoints for the configured VOs are correct.

If VOMS_ADMIN_INSTALL=false, the VOMS-ADMIN related entries should not be published.

Note: yaim-voms does not remove VOs when they are excluded from the list in the VOS variable. Such VOs will be present in BDII as well unless removed with

/opt/glite/sbin/voms-admin-configure remove --vo=vo_name

VOMS-ADMIN testing

VOMS-ADMIN CLI and VO management

Administrative registration of a VO member

Normal workflow

Use "create-user" to register a new VO member by

• using a certificate file (PEM format)
• specifying the user DN, issuer DN, email and name on the command line (--nousercert option)

Pass/Fail Criteria

voms-admin create-user exits with code 0 and list-users returns its DN as a registered member.

Erroneous workflow

• Wrong location of the certificate file or not a valid PEM file.
• Missing parameter when --nousercert is used ( userDN/issuerDN/email/name ).
• Issuer not trusted by the VOMS server
• User already registered

Pass/Fail Criteria

Test succeeds if an appropriate error message is printed and the exit code is 1.

Groups and role creation

Normal workflow

Use create-group and create-role to register new VO groups/roles.

Pass/Fail Criteria

voms-admin should exit with code 0. list-groups/list-subgroups and list-roles should display the newly created entities.

Erroneous workflow

Try to create a role/group that already exists or subgroup that full name does not start with "/vo_name/".

Pass/Fail Criteria

An error should be displayed to the user and voms-admin should exit with code 1.

Attribute class registration

Normal workflow and Pass/Fail Criteria

use create-attribute-class to register a new one. Verify both the creation of classes with UNIQUE enforcement and without. The test succeeds if voms-admin exits with code 0 and list-attribute-classes contains the new ones.

Erroneous workflow and Pass/Fail Criteria

If the class already exists or the name contains illegal characters, voms-admin should print an error and exit with code 1.

Users/groups/roles/classes deletion.

Use delete-user, delete-group, delete-role, delete-attribute-class to test deletion of VOMS entities. The test succeeds if voms-admin exits with code 0 and subsequent calls to the list command does not show the erased objects.

Group membership operations

Tests for adding/removing/listing of group members using add-member, remove-member, list-members

Normal workflow and Pass/Fail Criteria

• the add operations exits with code 0, and list-members shows the newly added member for the context in question. The user should become a member of all of the group's predecessors as well (if not already). This has to be verified with list-members as well.
• the delete operation exits with code 0 and the user is no longer member of the context in question. Group membership removal is not propagated back to the predecessors.

Erroneous workflow and Pass/Fail Criteria

voms-admin should print an error message and exit with code 1 if any of the following events occur:

• the location of the user certificate file is not valid or the file is not in PEM format
• adding a member that already exists
• removing a non-existent member

Role assignments/dismissals

Normal workflow and Pass/Fail Criteria

Use the assign-role and dismiss-role commands to verify the role management operations. assign-role should be tested with multiple roles for a single context.

Erroneous workflow and Pass/Fail Criteria

• assigning a role which is already granted
• dismissing a non-assigned role
• assigning a role for a context the user is not member of

In these cases voms-admin should exit with code 1 and print an error message.

Setting/Deleting attribute class values for users, groups, role/group

Test of the voms-admin commands

• set-user-attribute, delete-user-attribute
• set-group-attribute, delete-group-attribute
• set-role-attribute, delete-role-attribute

After the execution of the action, the corresponding list command should be used to verify that the value was actually stored in/removed from the database in which case the test is considered successful.

Erroneous workflow and Pass/Fail Criteria

voms-admin should exit with code 1 and print an error message if the commands are

• called with wrong number of arguments
• the user is not a VO member
• group/role does not exist
• a duplicate value for an attribute with unique constraint enabled
• the attribute is not set for the specified entity

Managing VOMS-ADMIN access control lists

The commands add-ACL-entry and remove-ACL-entry should be tested to modify the ACL for the top VO group and group hierarchy. The test passes if subsequent call to get-ACL for that contexts lists the new ACE.

Access control entries for the following subjects should be checked:

• registered vo user
• user which is not a VO member
• user possessing a role in a context
• all members of a group
• any authenticated user (anyone who has a valid certificate issued by the authorities the VOMS-ADMIN server trusts)

The propagation functionality should be checked for adding an ACE down the group hierarchy.

Managing VOMS-ADMIN default access control lists

Normal workflow and Pass/Fail Criteria

Access control entries are added in the default ACL for a context. Then a subgroup is created and the contents of its ACL is inspected with the get-ACL command. It should correspond to the contents of the default ACL of the parent. In this case the test is considered successful.

Web interface

VO registration service

Testing the VOMS-ADMIN web interface as a regular user.

Normal workflow and Pass/Fail Criteria

• VO registration request
• Confirmation email verification
• Request timeout
• VO information page

The test passes if the VOMS server accepts the registration requests, sends the confirmation email containing the valid activation link and subsequent approval of the user make it a regular VO member.

Activation should be tested also after the request expiration time. The VOMS server should display a proper error message.

VOMS-CORE server and voms-core cli testing

This testing covers the functionality of the voms-core server with the help of the following commands:

• voms-proxy-init
• voms-proxy-destroy
• voms-proxy-info
• voms-proxy-list

Proxy creation for a member of a VO (no special FQANs)

Use voms-proxy-init -voms vo_name to request a simple VOMS proxy.

Normal workflow

A temporary grid-proxy is created on the client side and used to establish a secure connection with the VOMS server. The server returns to the client a VOMS proxy containing the FQAN

/vo_name/Role=NULL/Capability=NULL

at position 1 if the server is operating in long FQAN mode or

/vo_name

if the server is in short FQAN mode.

Pass/Fail Criteria

Upon successful completion, voms-proxy-init prints the time until the proxy is valid and exits with status 0.

Erroneous workflow

• The name of the VO can not be found in the vomses file and the client does not know the VOMS server it is supposed to contact.
• The user's certificate and private key are not found in the default location.
• The private key is password protected and the user does not enter the correct password string.
• An authenticated connection with the VOMS server cannot be established because the issuer of the user's certificate is not trusted by the server.
• The issuer is known to the server but the user's DN is not registered as a member of the VO.

Pass/Fail Criteria

The test passes when the CLI reports a proper error message and exits with a non zero code.

Generate proxy with different private key sizes

Normal workflow

Generate proxies with size of the private key of 512, 1024, 2048 and 4096 bits. Simple request as in the previous test could be used.

Pass/Fail Criteria

voms-proxy-init completes its execution without errors, prints the lifetime of the VOMS proxy returned by the server and the strength of the key reported by voms-proxy-info is the requested one.

Erroneous workflow

• Wrong size is requested

Pass/Fail Criteria

The test passes when the CLI reports "Error: number of bits in key must be one of 512, 1024, 2048, 4096." and exits with code 1.

Request a proxy using non-standard location of the user certificate and private key files

Normal workflow

voms-proxy-init successfully generates the temporary grid proxy and then obtains the VOMS proxy from the server.

Pass/Fail Criteria

voms-proxy-init return 0 and voms-proxy-info reports a valid VOMS proxy.

Erroneous workflow

• Wrong location of the certificate or private key file.

Pass/Fail Criteria

voms-proxy-init exits with status 1 and prints an appropriate error message.

Use voms-proxy-init with custom vomses location

Normal workflow

Custom vomses file is specified on the command line of voms-proxy-init which defines a VOMS server for this VO different from the one in the standard vomses files (/opt/glite/etc/vomses). voms-proxy-init contacts the correct VOMS server for the VO requested by the user.

Pass/Fail Criteria

voms-proxy-init prints the expected VOMS server hostname and the lifetime of the proxy and exits with code 0. The test should fail if instead of the server specified in the custom vomses file, the one from the standard vomses location is used.

Erroneous workflow

voms-proxy-init cannot find the vomses file

Pass/Fail Criteria

Error message describing the problem and exit code 1 are expected.

Using proxies with generic attributes

Define generic attributes at user level, group level, role/group level and verify the returned VOMS proxied by the server for different user requests.

Example scenario:

User: "/C=CH/O=CERN/CN=Test user"
Member of: "/org.glite.voms-test/CERN/Bitface"
User role: "production"

Attributes defines:

Role=production, Group=/org.glite.voms-test, attribute_class_1=value_1
Role=production, Group=/org.glite.voms-test/CERN, attribute_class_2=value_2
Role=production, Group=/org.glite.voms-test/CERN/Bitface, attribute_class_3=value_3

Group=/org.glite.voms-test, attribute_class_4=value_4
Group=/org.glite.voms-test/CERN, attribute_class_5=value_5
Group=/org.glite.voms-test/CERN/Bitface, attribute_class_6=value_6
Group=/org.glite.voms-test/DESY, attribute_class_7=value_7

User: "/C=CH/O=CERN/CN=Test user", attribute_class_8=value_8

Scenario 1: The user requests a VOMS proxy without specifying a role:

voms-proxy-init -voms org.glite.voms-test

The attributes returned should be:

attribute : /org.glite.voms-test/Role=NULL/Capability=NULL
attribute : /org.glite.voms-test/CERN/Role=NULL/Capability=NULL
attribute : /org.glite.voms-test/CERN/Bitface/Role=NULL/Capability=NULL
attribute : attribute_class_6 = value_6 (/org.glite.voms-test/CERN/Bitface)
attribute : attribute_class_5 = value_5 (/org.glite.voms-test/CERN)
attribute : attribute_class_4 = value_4 (/org.glite.voms-test)
attribute : attribute_class_8 = value_8 (org.glite.voms-test)

I.e. the returned attributes should be

• standard group membership attributes, no attribute classes there
• the user level attributes (attribute_class_8)
• the group level attributes of the groups the user is member of (attribute_class_4, attribute_class_5, attribute_class_6)

The attribute for /org.glite.voms-test/DESY should not be returned because the user is not a member of this group.

The role/group attributes should not exist in the proxy as well, because the user did not request a role when calling voms-proxy-init

Scenario 2: The user requests a VOMS role to be included in the proxy

voms-proxy-init -voms org.glite.voms-test:/org.glite.voms-test/CERN/Bitface/Role=production

Attributes expected:

attribute : /org.glite.voms-test/CERN/Bitface/Role=production/Capability=NULL
attribute : /org.glite.voms-test/CERN/Role=NULL/Capability=NULL
attribute : /org.glite.voms-test/CERN/Bitface/Role=NULL/Capability=NULL
attribute : /org.glite.voms-test/Role=NULL/Capability=NULL
attribute : attribute_class_3 = value_3 (/org.glite.voms-test/CERN/Bitface/Role=production)
attribute : attribute_class_6 = value_6 (/org.glite.voms-test/CERN/Bitface)
attribute : attribute_class_5 = value_5 (/org.glite.voms-test/CERN)
attribute : attribute_class_4 = value_4 (/org.glite.voms-test)
attribute : attribute_class_8 = value_8 (org.glite.voms-test)

I.e. the returned attributes should be

• standard group membership attributes, no attribute classes there
• standard attributes concerning role assignments, no attribute classes there
• the user level attributes (attribute_class_8)
• the group level attributes of the groups the user is member of (attribute_class_4, attribute_class_5, attribute_class_6)
• the role/group level attributes for the requested roles (attribute_class_3)

Pass/Fail Criteria

If the list of returned attributes does not match the list above, the test should fail.

voms-proxy-init debug option

Test the -debug option of voms-proxy-init by requesting a simple VOMS proxy.

Normal workflow and Pass/Fail Criteria

voms-proxy-init prints all configuration files used, number of bits, Globus version, CA directory used, files for user proxy, certificate and private key. The test passes if the proxy is created successfully and the debug information is available.

voms-proxy-init help option

Normal workflow and Pass/Fail Criteria

Invoked with --help, voms-proxy should print the options summary help page and exit with code 0. If so, the test passes.

Creating proxies with custom lifetime

Normal workflow and Pass/Fail Criteria

Use the -valid option of voms-proxy-init to request a VOMS proxy with a specific lifetime.

* Scenario 1: The lifetime requested is smaller than the maximum lifetime configured for the VO on the server (VO__VOMS_CORE_TIMEOUT YAIM parameter).*

voms-proxy-init should obtain the proxy from the VOMS server and the value of timeleft for both the grid-proxy and the VOMS extension should correspond to the requested validity time by the user. Exit code should be 0.

* Scenario 2: The lifetime requested is larger than the maximum lifetime configured for the VO on the server*

voms-proxy-init should obtain a valid proxy from the VOMS server, identify the shortened lifetime and print a warning to the user. Exit code should be 0. The lifetime of the grid proxy should be as requested by the user and the lifetime of the VOMS extension should reflect the maximum lifetime configured on the server.

Erroneous workflow and Pass/Fail Criteria

If format of the value of -valid parameter is not followed, voms-proxy-init should print an error message and exit with code 1.

Check voms-proxy-init ignorewarn option

Normal workflow and Pass/Fail Criteria

Request a proxy with lifetime larger than the maximum allowed on the server side and add -ignorewarn. The test passes if voms-proxy-init does not print the warning about the shortened proxy lifetime.

Limited proxy creation

Use -limited to request a limited proxy. The limited grid proxy should be working with the VOMS server to obtain the VOMS extensions.

Pass/Fail Criteria

voms-proxy-init should exit with code 0 and voms-proxy-info should display "limited proxy" in the type field. The appended suffix in the subject of the limited grid proxy should be "CN=limited proxy"

Check voms-proxy-init "-list" option

Normal workflow and Pass/Fail Criteria

Should be invoked with exactly one -voms option denoting a VO name. voms-proxy-init contacts the VOMS server and should print a list of all FQANs representing group memberships and role assignments of the user.

Erroneous workflow and Pass/Fail Criteria

If the user is not a member of the VO, voms-proxy-init should print an error message and exit with code 1.

RFC-compliant proxy creation

Generate a RFC-compliant VOMS proxy by using the -rfc option of voms-proxy-init. voms-proxy-init should exit with code 0 and voms-proxy-info should report "RFC compliant proxy" in the type field.

FQAN order check

The VOMS-CORE server should honor the natural command line order of FQANs requested by the user (even when the -order option is not used). The test should create a VOMS proxy for a VO member that has multiple group memberships and role assignments in them. Multiple FQAN values should be permuted using the -voms option to request a proxy and then the same order should be reported by voms-proxy-info. Otherwise the test should fail.

VOMS proxy creation from an existing grid or voms proxy (regeneration)

Use the -regen option to request a VOMS proxy using an existing one. voms-proxy-init should not create a new grid-proxy, just contact the VOMS server and renew the VOMS extension. If as a result the lifetime of the VOMS proxy is shortened (due to a shorter lifetime of the grid proxy), voms-proxy-init should print a warning and exit with code 1.

VOMS API compatibility testing on gLite nodes

glite-UI

The UI has both the VOMS-CORE API, VOMS-CORE CLI and VOMS-ADMIN CLI installed. It should be used to run the VOMS testsuites against the VOMS_oracle and VOMS_mysql servers first with the production CLI and then with the patched one.

In addition to that, when the testing of the nodes below is performed from the UI, these tests should be done with

• production VOMS API, proxy from patched VOMS server
• patched VOMS API, proxy from production VOMS server
• patched VOMS API, proxy from patched VOMS server

glite-WMS and glite-LB

glite-WMS and glite-LB could be installed on the same machine and checked together against the new VOMS API.

The following scenarios should be covered:

• VOMS proxy with NULL enabled FQANs
• VOMS proxy with short FQANs
• Classic VOMS proxy
• Newformat proxies
• VOMS proxy for a simple named VO
• VOMS proxy for a DNS named VO
• RFC Proxy
• Proxy with VOMS extensions lifetime larger than the job running time
• Proxy with VOMS extensions lifetime smaller than the job running time and simple (non-voms) proxy uploaded to a MyProxy server (needed to verify the proxy renewal daemon functionality)
• VOMS proxy with role

These tests should be performed against

• a WMS node with the old VOMS API installed and a proxy issued by a VOMS server running the new version of the server
• a WMS node with the new VOMS API installed and a proxy issued by a VOMS server running the new version of the server

from a UI

• running with the old VOMS API
• running with the new VOMS API from the patch under certification

Both the lcg-CE and Cream should be checked as a computing element selected by the WMS

Use glite-wms-job-submit on the UI to submit a job to the WMS server. The job should perform regularly an operation that requires a valid VOMS proxy to assure there is always a valid voms proxy at jobs' disposal on the worker node.

For the proxy renewal tests, review the log files on the WMS node, MyProxy node and VOMS server node to assure that the renewals go fluently. The renewal daemon on the WMS node should contact the VOMS server to renew the VOMS extensions on user's behalf.

Check /var/log/glite/wmproxy.log to assure mod_gridsite is parsing correctly the contents of the VOMS extension and setting the environment variables.

glite-DPM_mysql

DPNS, DPM copy, SRM use the VOMS API and should be checked against the new version, both with proxies from production and patched VOMS server (using NULL-enabled FQANs, short-FQANs, RFC proxies, proxies for a DNS-named VO).

DPM-HTTP uses mod_gridsite to process proxies and is not affected by the VOMS libraries update so only proxies issued from an updated VOMS server should be tested.

DPNS

Use dpns-entergrpmap to define a simple group and a group with role. Use dpns-setacl to grant these entities rights to a subtree in the DPNS catalog hierarchy.

Request a user proxies on the UI with the configured FQANs in the VOMS extensions. Use the dpns-* commands to verify the DPNS server understands the client proxy and performs as expected (access is granted when the FQANs are in the proxy).

DPM

Use dpm-modifypool to grant access to specific FQANs access to a pool. Using the corresponding proxy on the UI, verify that the user which is member of the group used and assigned the role specified can access the pool.

Use dpm-reservespace to reserve DPM space and grant access to FQANs containing both group and role. Verify that the a user possessing a proxy with that FQAN in the VOMS extensions can use the space.

SRM

Use the lcg-utils to transfer files with srmv2 in order to verify the compatibility of the new libraries with the srm server.

DPM-HTTP

Use dpm-httpd-cp to transfer a file to a DPM server using a proxy issued by patched VOMS server and containing the needed FQAN in order to get pool access.

glite-LFC_mysql and glite-LFC_oracle

Use lfc-entergrpmap to create LFC groups based on FQANs. Grant access to these group for subtrees in the catalog hierarchy and use the appropriate user proxies from the UI node to check that the access is granted / denied as expected.

Check production voms proxes against the LFC server with the new API installed and also new VOMS proxies against the production and new VOMS API on the LFC server.

glite-FTS_oracle and glite-FTA_oracle

Deploy both services on a single node and define at least two channels of type urlcopy and srmcopy.

Submit transfer jobs using both old and new VOMS proxy and preform the test with the new VOMS API installed on the FTS/FTA node.

glite-CREAM

Test direct job submission to the CREAM computing element using glite-ce-job-submit CLI.

CREAM uses the VOMS-CORE Java API in order to extract the information from the VOMS proxy before the checking of the authorization rules by the policy engine. Submission with different VOMS proxies containing specific roles/groups/attributes should be performed against a CREAM CE that is configured to allow/reject access based on them.

glite-WN

Deploy the WN and check whether the voms client (proxy request) works. Note that the VOMS testsuite is not usable here because the VOMS-ADMIN client is not part of the glite-WN metapackage.

Verify that the lcg-DM clients work with the new VOMS API.

glite-VOBOX

Deploy the WN and check whether the voms client (proxy request) works. Note that the VOMS testsuite is not usable here because the VOMS-ADMIN client is not part of the glite-WN metapackage.