Difference: VOMSAdminTestPlan (1 vs. 2)

Revision 22012-04-27 - AndreaCeccanti

Line: 1 to 1
 

VOMS Admin test plan

Added:
>
>

1 Version information

Server version: 2.7.0

Client version: 2.0.17

 

1 Unit tests

2 Deployment tests

2.1 MySQL Backend

yum install emi-voms-mysql

installs cleanly on an SL5 x86_64 and SL x86_64 machine configured as described in the EMI 1 and EMI2 Generic Installation and Configuration guide.

2.2 Oracle Backend

yum install emi-voms-oracle

installs cleanly on an SL5 x86_64 and SL x86_64 machine configured as described in the EMI 1 and EMI2 Generic Installation and Configuration guide.

2.3 System tests

Added:
>
>
 

0.0.1 Basic functionality tests

Added:
>
>
N.B.: All these tests are performed automatically by the VOMS Admin test suite.
 

0.0.0.1 Administrative registration of a VO member

0.0.0.1.1 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)

0.0.0.1.2 Pass/Fail Criteria

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

0.0.0.1.3 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

0.0.0.1.4 Pass/Fail Criteria

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

0.0.0.2 Groups and role creation

0.0.0.2.1 Normal workflow

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

0.0.0.2.2 Pass/Fail Criteria

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

0.0.0.2.3 Erroneous workflow

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

0.0.0.2.4 Pass/Fail Criteria

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

0.0.0.3 Attribute class registration

0.0.0.3.1 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.

0.0.0.3.2 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.

0.0.0.4 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.

0.0.0.5 Group membership operations

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

0.0.0.5.1 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.

0.0.0.5.2 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

0.0.0.6 Role assignments/dismissals

0.0.0.6.1 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.

0.0.0.6.2 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.

0.0.0.7 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.

0.0.0.7.1 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

0.0.0.8 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.

0.0.0.9 Managing VOMS-ADMIN default access control lists

0.0.0.9.1 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.

0.0.1 Web interface

0.0.1.1 VO registration service

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

0.0.1.1.1 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.

0.0.2 Regression tests

0.0.2.1 [VOMS Admin] VOMS Admin CA update functionality fails with EGI-trustanchors CA 1.38 (https://savannah.cern.ch/bugs/?78349)

Check that VOMS Admin installation and configuration works as expected with EGI trust anchors >= 1.38.

0.0.2.2 [VOMS Admin] VOMS-admin AUP signing request behaviour broken for user with no AUP acceptance record (https://savannah.cern.ch/bugs/?78350)

Create two users without AUP record, have one user sign the AUP and check that the other still receive a Sign AUP email

0.0.2.3 [VOMS Admin] "Add to group" dialog broken (https://savannah.cern.ch/bugs/?78881)

Create 2 groups in the VO. Create a user. Check the add to group dialog in the user page allows the administrator to select any of the newly created groups

0.0.2.4 [VOMS Admin] "more info" link in group search users tab broken (https://savannah.cern.ch/bugs/?79087)

Create a user in the VO. Search the VO root group and check that the "more info" referring to the cretead user is not broken.

0.0.2.5 [YAIM VOMS] Adaptive setting of MaxPermSize according to the number of configured VOs (https://savannah.cern.ch/bugs/?80172)

Configure a large number of VOs with YAIM (> 10) and check that the MaxPermSize Java VM parameter is set in a way that is proportional to the number of VOs

0.0.2.6 [VOMS Admin] Database upgrade fails when usr table contains duplicated entry (https://savannah.cern.ch/bugs/?80308)

Starting from a VOMS Admin 2.0.x database, insert a duplicated entry in the usr table and try the upgrade of the database. The upgrade script should warn of the presence of a duplicated entry and succed.

0.0.2.7 [VOMS Admin] Confirmed pending VO membership requests are incorrectly deleted from database (https://savannah.cern.ch/bugs/?80685)

Configure the expired request purger thread to excecute every 10 sec. Request membership to the VO. As a VO admin accept the membership request. Check that the expired request purger does not delete the just confirmed request from the database.

0.0.2.8 [VOMS Admin] Uncaught exception shown in group membership search pane (https://savannah.cern.ch/bugs/?80892)

Using the voms-admin CLI create two users with the same ceritificate subject and different CAs. Check that the root VO group membership search pane shows the two users as expected and no exception is thrown.

0.0.2.9 [VOMS Admin] VOMS Admin does not resolve correctly email addresses for role an group administrators (https://savannah.cern.ch/bugs/?80945)

Create a user, assign him the VO-Admin role. Check that the user receives VOMS Admin notifications for incoming user requests.
Changed:
<
<

0.0.0.1 [VOMS Admin] VOMS Admin SIGN AUP default grace period is too short (

>
>

0.0.0.1 [VOMS Admin] VOMS Admin SIGN AUP default grace period is too short (https://savannah.cern.ch/bugs/?93370)

  1. Create a user in the VO (via voms-admin cli or the web interface).
  2. Trigger AUP reacceptance for the user from web interface.
  3. Ensure the web interface shows that 14 days (the current default) are given to the user to sign the AUP.

0.0.0.2 [VOMS Admin] VOMS Admin does not send warning message before suspending users due to membership expiration (https://savannah.cern.ch/bugs/?93255)

  1. Create 10 users in a test V0 (via voms-admin cli or the web interface).
  2. Change the expiration date for 5 of these users to be in the next 10 days.
  3. Check that administrator receives a mail that informs of the 5 expiring users.

0.0.0.3 [VOMS Admin] voms-admin-configure ignores dbhost and dbport parameters for voms core configuration (https://savannah.cern.ch/bugs/?91182)

  1. Create a test vo using voms-admin-configure specifying the --dbhost and --dbport options
  2. Ensure that the value provided appear in /etc/voms//voms.conf

0.0.0.4 [VOMS Admin] Trim spaces from DN when entered in the web interface (https://savannah.cern.ch/bugs/?88019)

  1. Add a certificate for an existing user in the VO from the web interface and enter a fake DN surrounded by spaces.
  2. Check that spaces are trimmed in the certificate listed in the user certificate list panel.

0.0.0.5 [VOMS Admin] Use single separator in the output of voms-admin list-users command (https://savannah.cern.ch/bugs/?86771)

  1. Populate the VO with at least one user
  2. Run voms-admin --vo list-users and check that a single separator is used for dn, ca and email.

0.0.0.6 [VOMS Admin] Small improvements to VOMS Admin WEB UI (https://savannah.cern.ch/bugs/?86327)

  1. Check that the add certificate page shows the "Certificate subject (DN)" label instead of "Subject".
  2. Check that the registration page displays the "Given name", "Family name" labels insted of "Name", "Surname".

0.0.0.7 [VOMS Admin] voms-admin-ping looking in wrong place to determine list of VOs. (https://savannah.cern.ch/bugs/?85657)

  1. Configure three different VOs with YAIM
  2. After YAIM configuration is over, stop two of them with service voms-admin stop vo1 vo2
  3. Run voms-admin-ping (as root) and check that one VO is shown as active, while the other two are reported as stopped.

0.0.0.8 [VOMS Admin] AUP URL for active AUP should be editable from the Web interface (https://savannah.cern.ch/bugs/?83161)

  1. Check that the VOMS Admin web interface provides the ability for administrators to edit the URL of AUPs

0.0.0.9 [VOMS Admin] Provide access to membership statistics (https://savannah.cern.ch/bugs/?93968)

  1. Check that the voms-admin list-user-stats show correct information about membership in a VO

0.0.0.10 [VOMS Admin] The voms-admin-configure --read-access-to-authenticated-clients options produces no effect (https://savannah.cern.ch/bugs/?93978)

  1. Configure a VO using the --read-access-to-authenticated-clients.
  2. Check that groups are shown in the VO group list page.
 

0.0.1 Performance and scalability tests

N/A

0.0.2 Standard compliance and conformance tests

N/A

0.0.3 Inter-component tests

0.0.3.1 MkGridmap

Check that mkgridmap script work as expected against VOMS Admin service

-- AndreaCeccanti - 2012-04-27

 
TWIKI.NET
This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback