CS 411W Lab III
Prototype Test Plan/Procedure
For
CertAnon
Prepared by: David Mirra, Red Group
Date: 11/29/2007
Mirra 11/04/2007
Table of Contents
1
2
3
Objectives ................................................................................................................... 1
References ................................................................................................................... 2
Test Plan...................................................................................................................... 3
3.1
Testing Approach ................................................................................................ 3
3.2
Identification of Tests ......................................................................................... 5
3.3
Test Schedule ...................................................................................................... 6
3.4
Fault Reporting and Data Recording .................................................................. 6
3.5
Resource Requirements ...................................................................................... 7
3.6
Test Environment ................................................................................................ 8
3.7
Test Responsibilities ........................................................................................... 9
4 Test Procedures ......................................................................................................... 10
4.1
Test Case Names and Identifiers....................................................................... 10
5 Traceability to Requirements .................................................................................... 23
List of Figures
Figure 1. Phase 1 prototype major functional component diagram................................... 3
Figure 2. Teletechnet classroom layout ............................................................................. 8
List of Tables
Table 1. CertAnon prototype test cases by category.......................................................... 5
Table 2. CertAnon prototype test schedule ........................................................................ 6
Table 3. Traceability matrix for the CertAnon prototype ................................................ 24
ii
Mirra 11/04/2007
1 Objectives
CertAnon is an anonymous Wide-Area Network (WAN) authentication service conceived
by the Old Dominion University (ODU) CS410 Red Group. It is designed to replace the
password, the weak link in online account authentication, with an enterprise-grade two-factor
authentication solution that is available to the everyday Internet user. It can be integrated with
any account-based web portal to provide an instant security boost for a site's customers. It
utilizes available, affordable, and proven technology within an innovative and scalable
framework. CertAnon targets the large and growing markets of individual Internet users and
security-conscious businesses, and it offers clear benefits to both.
The prototype of the CertAnon service is intended to demonstrate the feasibility of using
a centralized two-factor authentication system with multiple independent users and multiple
independent partner websites. The first functional objective is to successfully demonstrate the
use of a middle tier, the CertAnon website, to extend the functionality of a two-factor
authentication solution across multiple independent partner sites. Two-factor authentication
credentials entered by an end user on a partner site must be linked to a particular token. These
credentials will be sent to the CertAnon website and cross-referenced against configured
accounts to identify the associated token. The token serial number and the passcode are then
sent to the authentication server for validation. The authentication response is passed back
through the CertAnon site and on to the partner site. It is this middle-tier innovation that allows
CertAnon to offer a solution that permits a customer to securely access all participating online
accounts using a single access method.
The second objective is to demonstrate the CertAnon service using a simulated hardware
token that does not require any client software. In order to highlight the ease of use and cross-
1
Mirra 11/04/2007
platform availability of this solution, it will be shown that the service is not limited to specific
client hardware or operating systems and that it needs no special software installed by the user.
Third, user registration and account maintenance will be handled in an anonymous
fashion while still providing strong account authentication. Account access must be limited to a
specific token holder without collecting or using personal information such as a real name, a
street address, or a credit card number. This feature will allay consumer fears of information
misuse or theft and attract additional customers who value the privacy that this provides.
The final objective is to show the ease of integration of this third party system with a
potential partner website. The aim is to illustrate the relative simplicity of incorporating a prebuilt PHP module into an existing site in order to offer the CertAnon service. A short and
straightforward integration process is an important aspect of the service and will be a valuable
selling point for commercial partners.
The purpose of this test plan and procedure is to establish the overall approach, testing
sequence, and specific tests to be conducted in order to show that the operational prototype has
achieved these objectives.
2 References
Mirra, David. (2007). Lab I – CertAnon Product Description. Reston, VA: Author.
Mirra, David. (2007). Lab II – Prototype Product Specification for CertAnon. Reston, VA:
Author.
RSA. (2007). RSA SecurID. Retrieved September 17, 2007, from
http://www.rsa.com/node.aspx?id=1156.
2
Mirra 11/04/2007
3 Test Plan
The following sections of the test plan will discuss the types of tests to be performed, the
testing schedule, reporting procedures, resource requirements, the testing environment, and team
member responsibilities.
3.1 Testing Approach
Performance of the CertAnon prototype will be verified through a combination of
component and system tests. The major functional components of the prototype are shown in
Figure 1.
Figure 1. Phase 1 prototype major functional component diagram
3
Mirra 11/04/2007
The system tests will exercise multiple components concurrently, obviating the need to
perform separate tests on every component independently. The four test categories therefore do
not correspond directly to the major components. The first category will cover the functionality
of the CertAnon website. These tests will demonstrate that the system allows a user to create a
new CertAnon account, to access that account using two-factor authentication, and to
subsequently modify the information stored in that account. The second testing category will
measure the system capacity and performance. These automated tests will ensure that the system
meets the performance requirements related to volume and speed. The third category will
examine the exception handling abilities of the prototype. Component requirements for one-time
token use, account locking due to multiple bad login attempts, and time-out handling will all be
examined by these tests. The final category covers legacy password support. CertAnon must
support partner site users who choose not to use CertAnon for authentication. These tests will
verify that such users can still use legacy single-factor password authentication to access partner
site accounts if they opt out of the CertAnon service.
All tests will be conducted in a controlled classroom environment using the ODU
network and hardware. Verification of user interface tests will be completed through observation
and by monitoring back-end logs to demonstrate the proper transfer of information through the
system. Performance tests will produce reports which summarize the actual results and compare
them to the requirement benchmarks.
4
Mirra 11/04/2007
3.2 Identification of Tests
Table 1 shows the test cases that will be performed, grouped by category. Specific
details for each test will be discussed in section 4.1.
Category ID
Description
Test Case
1
CertAnon basic functionality
1.1
1.2
1.3
1.4
2
Prototype capacity and
performance
1.5
Exception handling
1.6
1.7
1.8
1.9
3
1.10
4
Legacy password support
1.11
Table 1. CertAnon prototype test cases by category
5
Description
Create new CertAnon account
CertAnon website authentication
Modify CertAnon account information
Partner site authentication
Verify prototype capacity and
performance
One time token use
Authentication module request time-out
Mid-tier account lockout
Mid-tier request time-out
Support for legacy password
authentication
Authentication module legacy
request/response
Mirra 11/04/2007
3.3 Test Schedule
The CertAnon team has been allotted 45 minutes for the setup and demonstration of the
prototype. The first five minutes will be used for setup, followed by a 10 minute introduction to
the concept of the CertAnon service. From that point forward, the test cases will be executed
according to the schedule shown in Table 2.
Start Time
Duration
(hours:min) (Minutes)
0:15
10
0:25
5
0:30
10
0:40
5
Test Objective
Test Event
Dependencies
Comments
CertAnon
basic
functionality
Prototype
capacity and
performance
Exception
handling
Legacy
password
support
1.1, 1.2,
1.3, 1.4
None
None
1.5
None
None
1.6, 1.7,
1.8, 1.9
1.10, 1.11
None
None
None
None
Table 2. CertAnon prototype test schedule
3.4 Fault Reporting and Data Recording
One team member will be tasked with recording the results of each test on a printed
checklist. Functional test results will be recorded as passing or failing. Verification of user
interface tests will be completed by observing the response of the system. Time-stamped logs
produced by the authentication module, the mid-tier, and the authentication manager will be
displayed in order to demonstrate the proper transfer of information through the system and to
confirm the visual results of certain tests. Database table contents will also be reviewed in order
to confirm that some tests have been fully passed. Performance tests will automatically produce
reports which document the actual results and compare them to the requirement benchmarks.
6
Mirra 11/04/2007
If a fault does occur or if a test fails, the fault condition or error message will be noted on
the checklist. Relevant entries in the log files will be located and added to the post-mortem
document.
3.5 Resource Requirements
The CertAnon prototype demonstration will require that the CertAnon website, two
partner websites, and the authentication manager Perl script are all running on an ODU server. A
database table must be preloaded with at least 20 token serial numbers and at least 25 related
token codes for each token. At least 20 pre-loaded accounts should also exist in the CertAnon
account table and each of the partner site account tables.
A test user, with a list of the pre-loaded token serial numbers and token codes and the
testing checklist, will be seated at the desktop PC in the presentation room. The user should
have a copy of the CertAnon prototype slideshow on a USB key. The desktop PC must have a
USB port, a network connection, an installed web browser, and the Microsoft PowerPoint
program. A laptop computer with a network connection must be set up with MySQL
QueryBrowser software to graphically display the contents of the CertAnon database databases.
The laptop must also have a terminal emulator installed in order to access and view the server
logs.
7
Mirra 11/04/2007
3.6 Test Environment
The prototype demonstration will take place in the Teletechnet classroom on the ODU
campus. Figure 2 shows the layout of this room.
Figure 2. Teletechnet classroom layout
The team member tasked with acting as the test user will be seated at the front of the
room at the instructor's PC. The team member operating the laptop will likely be positioned next
to the first individual on the same desk, but this is subject to change based upon feedback from
the video operator. The laptop must be in a position where it can be viewed by one of the room
cameras. Both team members will verify the network connectivity on their machines and launch
8
Mirra 11/04/2007
their web browsers. The PC user will launch the presentation slide show. The laptop operator
will launch the database viewing software and a terminal emulator. One other team member will
be seated in one of the student seats in the back of the room as an observer, ready to assist if
necessary. The presenter will be participating remotely from the ODU Northern Virginia Center
via satellite connection. The backup presenter and the individual recording the test results will
also be participating remotely via satellite connections. These connections must be verified
during the setup period.
3.7 Test Responsibilities
David Mirra will be the primary speaker and will handle the initial presentation on the
CertAnon service as well as the introduction and narrative for each test case. Mark Polansky
will be the backup presenter and will monitor the server logs for faults during the demonstration.
David Leonard will be the test recorder, noting the results of each test and ensuring that all test
cases have been completed successfully. Rusty Udan will act as the test user and execute all of
the test cases that involve user interfaces. Ben Blowe will be the laptop operator. He is
responsible for presenting database query results and log contents to the viewers during the
course of the test cases. Ben will also launch the automated performance tests and display the
results. Sean Alcos will be in charge of disaster recovery operations. In the event that the preloaded data or application files become corrupted or otherwise unavailable, he will take steps to
reload or restore the needed resources using prepared backups. Sean will also act as a backup for
the two computer operators in case one is unable to attend the presentation.
9
Mirra 11/04/2007
4 Test Procedures
Detailed test procedures have been prepared to ensure that the test cases can be
performed in an effective and efficient manner.
4.1 Test Case Names and Identifiers
Each test case has been assigned a unique name and reference number. The requirements
being tested by each case are identified along with the necessary initialization steps, inputs,
procedures, and expected results.
Test Case 1.1 - Create new CertAnon account
Specification References:
3.1.1.1 Accept and store a token serial number entered by a user
3.1.1.2 Store a CertAnon username and PIN chosen by a user
3.1.1.3 Store security questions and answers input by a user for later use in emergency
identity verification
Test Description: This test will ensure that a newly registered user can input and store
all pertinent data to allow for user interaction with the CertAnon system.
Test Level: Component
Test Type: Functional
Initialization:
1. Database table containing valid token serial numbers and related token codes must be
preloaded
2. Verify that the CertAnon user table does not contain the CertAnon username to be
entered during the test
3. Verify web access to CertAnon web interface
Test Inputs:
1. CertAnon username (minimum 8 alphanumeric characters)
2. PIN (minimum 4 alphanumeric characters)
3. Token serial number (8 numeric digits)
4. Security questions with answers
10
Mirra 11/04/2007
Test Procedure:
1. Access the registration web page from the CertAnon site
2. Input the required fields for registration
3. Submit values to web server for processing
4. Verify that all data is inserted correctly into the database by running SQL SELECT
commands to view database contents
Expected Test Results:
1. All submitted data is input, processed, and placed correctly into the CertAnon
database
Special Instructions:
None
Test Case 1.2 - CertAnon website authentication
Specification References:
3.1.2.1 Allow a user to log in using a CertAnon username and passcode
3.1.3.1.1 Accept a token serial number and passcode in the contents of an authentication
request
3.1.3.1.2 Compare a given passcode to the list of valid PIN/token code combinations for a
given serial number. The software should respond with an acceptance message if valid or
a rejection message otherwise.
3.1.3.1.3 Operate persistently in the background so that it is always available to accept
incoming authentication requests
3.1.3.2.3 Transmit a domain name, a partner site user name, and a passcode for a
CertAnon user to the CertAnon mid-tier process
3.1.3.2.4 Accept return messages from the mid-tier and display appropriate messages to
the user
3.1.3.3.2 Compare the domain name and partner site username provided in a request with
CertAnon user records to determine the corresponding token
3.1.3.3.3 Transmit token serial numbers and passcodes to the authentication manager
process
3.1.4.5 Display a user-specific home page upon successful authentication
Test Description: This test will ensure that a user can correctly log into the CertAnon
website using a CertAnon token. This is a system test that involves the CertAnon
website, the mid-tier, and the authentication manager.
Test Level: System
Test Type: Functional
11
Mirra 11/04/2007
Initialization:
1. Database table containing valid token serial numbers and related token codes must be
preloaded
2. CertAnon account for the test username and token serial number must be created
3. Verify web access to CertAnon web interface
4. User must have a list of valid token codes for the serial number being tested
Test Inputs:
1. CertAnon username (minimum 8 alphanumeric characters)
2. PIN (minimum 4 alphanumeric characters)
3. Token code (6 numeric digits)
Test Procedure:
1. Access the CertAnon login web page from the CertAnon site
2. Select a valid and registered CertAnon username, and then select a valid token code
from the list of preloaded values for that user's token serial number
3. Input the username into the "Username" field, and enter the PIN immediately
followed by the valid token code in the "Password" field
4. Submit values to web server
5. Verify that access to the CertAnon account information page is granted due to
successful authentication
6. Log out of the CertAnon website
7. Repeat steps 1-4, this time entering an invalid token code
8. Verify that an error is received denying the user access to the CertAnon account
9. Show mid-tier and authentication manager logs to verify that the user credentials
were correctly handled by each component
Expected Test Results:
1. Valid username and PIN + token code are verified and accepted allowing access to
the CertAnon system
2. Invalid token code cannot be verified and access to the CertAnon system is not
granted; the user is presented with an error and allowed to reenter login information
Special Instructions:
None
Test Case 1.3 - Modify CertAnon account information
Specification References:
3.1.2.2 Allow a user to add, modify, and delete partner site domain names and
corresponding partner site usernames associated with the CertAnon account
3.1.2.3 Allow a user to change and save the PIN associated with the CertAnon account
3.1.2.4 Allow a user to change and save the security questions and answers associated
with the CertAnon account
12
Mirra 11/04/2007
Test Description: This test will ensure that all user data changes are inputted and stored
correctly into the CertAnon system.
Test Level: Component
Test Type: Functional
Initialization:
1. Database table containing valid token serial numbers and related token codes must be
preloaded
2. CertAnon account for the test username and token serial number must be created
3. Verify web access to CertAnon web interface
4. User must have a list of valid token codes for the serial number being tested
Test Inputs:
1.
2.
3.
4.
5.
6.
7.
CertAnon username (minimum 8 alphanumeric characters)
PIN (minimum 4 alphanumeric characters)
Token code (6 numeric digits)
New PIN (minimum 4 alphanumeric characters)
New security question with answer
Partner site domain name
Partner site username (minimum 8 alphanumeric characters)
Test Procedure:
1. Log into the CertAnon website using a valid username, PIN, and token code
2. Click on the "My Account" link on the CertAnon site
3. Enter a new PIN in the "New PIN" field
4. Enter a new security question in the "Security Question" field
5. Enter the answer to the new security question in the "Answer" field
6. Click the "Submit" button to save the values
7. Under the section entitled "Maintain Partner Site Accounts," enter a new partner site
name and partner site username in the "Partner Site Domain Name" and "Partner Site
Username" fields
8. Click the "Submit" button to save the new entry
9. Edit an existing partner site username in the list labeled Existing Accounts
10. Click the "Delete" box next to an existing partner site name (different from the
account edited in step 9)
11. Click the "Submit" button
12. Verify that the updated information now appears on the screen
13. Verify that all data is inserted correctly into the database by running SQL SELECT
commands to view database contents
Expected Test Results:
1. All submitted data is inputted, processed, and placed correctly into the CertAnon
database
13
Mirra 11/04/2007
2.
3.
4.
5.
The PIN and security question should reflect the updated values
The new partner site account should be registered
The updated partner site account should show an updated username
The deleted partner site account should no longer be in the database
Special Instructions:
None
Test Case 1.4 - Partner site authentication
Specification References:
3.1.3.1.1 Accept a token serial number and passcode in the contents of an authentication
request
3.1.3.1.2 Compare a given passcode to the list of valid PIN/token code combinations for a
given serial number. The software should respond with an acceptance message if valid or
a rejection message otherwise.
3.1.3.1.3 Operate persistently in the background so that it is always available to accept
incoming authentication requests
3.1.3.2.3 Transmit a domain name, a partner site user name, and a passcode for a
CertAnon user to the CertAnon mid-tier process
3.1.3.2.4 Accept return messages from the mid-tier and display appropriate messages to
the user
3.1.3.3.1 Accept authentication requests sent by the authentication modules running on
partner sites
3.1.3.3.2 Compare the domain name and partner site username provided in a request with
CertAnon user records to determine the corresponding token
3.1.3.3.3 Transmit token serial numbers and passcodes to the authentication manager
process
3.1.3.3.4 Accept return messages from the authentication manager process and forward
them to the requesting partner sites
3.1.4.4 Integrate the CertAnon authentication module
3.1.4.5 Display a user-specific home page upon successful authentication
Test Description: This test will ensure that a user can correctly log into a partner site
using a CertAnon token. This is a system test that involves the partner site, the mid-tier,
and the authentication manager.
Test Level: System
Test Type: Functional
Initialization:
1. Database table containing valid token serial numbers and related token codes must be
preloaded
2. CertAnon account for the test username and token serial number must be created
14
Mirra 11/04/2007
3.
4.
5.
Verify web access to partner site
User must have a list of valid token codes for the token serial number being tested
The partner site username must be registered with CertAnon under the token serial
number being tested
Test Inputs:
1. Partner site username (minimum 8 alphanumeric characters)
2. PIN (minimum 4 alphanumeric characters)
3. Token code (6 numeric digits)
Test Procedure:
1. Access the Partner site home page
2. Enter the pre-registered partner site username, and then select a valid token code
from the list of preloaded values for that user's token serial number
3. Input the username into the "Username" field, and enter the PIN immediately
followed by the valid token code in the "Password" field
4. Submit values to web server
5. Verify that access to the partner site account information page is granted due to
successful authentication
6. Log out of the partner site
7. Repeat steps 1-4, this time entering an invalid token code
8. Verify that an error is received denying the user access to the partner site account
9. Show mid-tier and authentication manager logs to verify that the user credentials
were correctly handled by each component
Expected Test Results:
1. Valid username and PIN + token code are verified and accepted allowing access to
the partner site
2. Invalid token code cannot be verified and access to the partner site is not granted; the
user is presented with an error and allowed to reenter login information
Special Instructions:
None
Test Case 1.5 - Capacity
Specification References:
3.1.3.1.4 Handle multiple simultaneous requests
3.2.1.1 Respond to any authentication request within a maximum time of eight seconds
3.2.1.2 Respond to authentication requests within an average time of three seconds
3.2.1.3 Accept and process at least 20 concurrent authentication requests with no drops
or denials
3.2.2.1 Handle up to 20 simultaneous authentication requests
3.2.3.1 Handle up to 20 simultaneous authentication requests
15
Mirra 11/04/2007
Test Level: System
Test Type: Capacity
Test Description: This test will verify that the CertAnon system can handle up to 20
simultaneous authentication requests
Initialization:
1. Database table containing valid token serial numbers and related token codes must be
loaded
2. Authentication manager Perl script must be initiated as a background process
3. At least 20 partner site user accounts must be created and configured to use CertAnon
4. At least 20 CertAnon user accounts must be created and associated with one of the
partner site user accounts
5. A file containing all valid partner site usernames and related token codes must exist in
the testing directory as a source file for the testing script
Test Inputs:
1. File containing all valid partner site usernames and related token codes
Test Procedure:
1. Run the test driver script, which will randomly select usernames and token codes
from the saved file and submit at least 20 partner site authentication attempts in rapid
succession
2. Review the test driver log to confirm that the requests were submitted and received
responses
3. Verify that the maximum and average authentication times were under eight and three
seconds, respectively
Expected Test Results:
1. Submission of a valid serial number/token code combination should return a
successful authentication message (Pass/Fail)
2. The maximum time taken to respond to any authentication request shall be less than
or equal to eight seconds (Pass/Fail)
3. The average time taken to respond to all authentication requests shall be less than or
equal to three seconds (Pass/Fail)
4. All authentication requests shall have received appropriate authentication response
messages (Pass/Fail)
Special Instructions:
None
16
Mirra 11/04/2007
Test Case 1.6 - One-time token use
Specification References:
3.1.3.1.5 Enforce one-time usage of all token codes by throwing a rejection message for
any authentication request that contains a previously used token code
Test Level: Component
Test Type: Functional
Test Description: This test will verify that the authentication manager will only accept a
valid token code one time.
Initialization:
1. Database table containing valid token serial numbers and related token codes must be
preloaded
2. CertAnon account for the test username and token serial number must be created
3. Verify web access to partner site
4. User must have a list of valid token codes for the token serial number being tested
5. The partner site username must be registered with CertAnon under the token serial
number being tested
Test Inputs:
1. Partner site username (minimum 8 alphanumeric characters)
2. PIN (minimum 4 alphanumeric characters)
3. Token code (6 numeric digits)
Test Procedure:
1. Access the Partner site home page
2. Enter the pre-registered partner site username, and then select a valid token code
from the list of preloaded values for that user's token serial number
3. Input the username into the "Username" field, and enter the PIN immediately
followed by the valid token code in the "Password" field
4. Submit values to web server
5. Verify that access to the partner site account information page is granted due to
successful authentication
6. Log out of the partner site
7. Repeat steps 1-4 using the same token code used in step 3
8. Verify that an error is received, denying the user access to the partner site account
9. Show mid-tier and authentication manager logs to verify that the user credentials
were correctly handled by each component
10. Show that the "Used" flag of the token code has been set in the database
Expected Test Results:
1. Submission of a valid serial number/token code combination should return a
successful authentication message (Pass/Fail)
17
Mirra 11/04/2007
2.
Second submission of the same serial number and token code should return an
unsuccessful authentication message (Pass/Fail)
Special Instructions:
None
Test Case 1.7 - Authentication module request time-out
Specification References:
3.1.3.2.5 Handle authentication request time-outs due to an unresponsive mid-tier
Test Level: Component
Test Type: Functional
Test Description: This test will verify that the authentication module will time-out after
10 seconds due to a non-responsive mid-tier.
Initialization:
1. Legacy/CertAnon flag for the user account to be tested must be set to CertAnon in the
partner site database table
2. Authentication module must be installed on the partner site
3. Mid-tier component must be made unavailable
Test Inputs:
1. Partner site username
2. PIN
3. Token code
Test Procedure:
1. Access the partner site web page
2. Select a valid and registered partner site username, and then select a valid token code
from the list of preloaded values for that user's token serial number
3. Input the username into the "Username" field, and enter the PIN immediately
followed by the valid token code in the "Password" field
4. Submit values to web server
5. Verify that authentication module sends CertAnon authentication request to mid-tier
by checking authentication module log
6. Verify that mid-tier does not respond to authentication module after 10 seconds by
checking authentication module log
7. Verify that the user receives a "Request has timed out" error
Expected Test Results:
1. Submission of a valid username and passcode will return a time-out message from the
authentication module log (Pass/Fail)
18
Mirra 11/04/2007
Special Instructions:
It is not actually necessary to enter a valid passcode since the time-out will occur
regardless.
Test Case 1.8 - Mid-tier account lockout
Specification References:
3.1.3.3.5 Record multiple failures and lock an account if three consecutive incorrect
passcodes are processed
Test Level: Component
Test Type: Functional
Test Description: This test will verify that the mid-tier will count invalid login attempts
from a specific username and lockout username after three failures.
Initialization:
1. Partner site database table with legacy/CertAnon flag set to CertAnon
2. Authentication module PHP script(s) must be initiated as a background process
3. Mid-tier PHP script must be initiated as a background process
4. Database table containing valid token serial numbers, related token codes, and PIN
numbers must be loaded
5. Authentication manager Perl script must be initiated as a background process
Test Inputs:
1. Partner site username
2. PIN
3. Invalid token code
Test Procedure:
1. Access the partner site web page
2. Select a valid and registered partner site username, and then select an invalid token
code
3. Input the username into the "Username" field, and enter the PIN immediately
followed by the invalid token code in the "Password" field
4. Submit values to web server
5. Verify that an error is received denying the user access to the CertAnon account
6. Repeat steps 3-5 two more times in succession
7. Select a valid and registered partner site username, and then select a valid token code
from the list of preloaded values for that user's token serial number
8. Input the username into the "Username" field, and enter the PIN immediately
followed by the valid token code in the "Password" field
9. Submit values to web server
19
Mirra 11/04/2007
10. Verify that an error is received denying the user access to the CertAnon account
11. Verify that the mid-tier has locked out username after three consecutive invalid
passcode attempts by checking mid-tier log
Expected Test Results:
1. Multiple failure messages will be returned to authentication module and username
will be locked out after three failures (Pass/Fail)
Special Instructions:
None
Test Case 1.9 - Mid-tier request timeout
Specification References:
3.1.3.3.6 Handle authentication request time-outs due to an unresponsive authentication
manager
Test Level: Component
Test Type: Functional
Test Description: This test will verify that the mid-tier will handle an unresponsive
authentication manager.
Initialization:
1. "Use CertAnon" flag for the user account to be tested must be set to "Yes" in the
partner site database table
2. Authentication module must be installed on the partner site
3. Authentication manager process must be terminated
Test Inputs:
1. Partner site username
2. PIN
3. Token code
Test Procedure:
1. Access the partner site web page
2. Select a valid and registered partner site username, and then select a valid token code
from the list of preloaded values for that user's token serial number
3. Input the username into the "Username" field, and enter the PIN immediately
followed by the valid token code in the "Password" field
4. Submit values to web server
5. Verify that authentication module sends CertAnon authentication request to mid-tier
by checking authentication module log
20
Mirra 11/04/2007
6.
7.
Verify that authentication manager does not respond to the mid-tier request after 10
seconds by checking mid-tier log
Verify that the user receives a "Request has timed out" error
Expected Test Results:
1. Mid-tier shall send an authentication manager communication time-out message to
authentication module on Partner sites (Pass/Fail)
Special Instructions:
None
Test Case 1.10 - Support for legacy password authentication
Specification References:
3.1.4.2 Allow a user to select or deselect an option to use CertAnon for authentication
and save this preference
3.1.4.3 Accept and store a password entered by a user if CertAnon is not used for
authentication
Test Level: Component
Test Type: Functional
Test Description: This test will verify that partner sites integrating the CertAnon
authentication module retain support for one-factor password authentication.
Initialization:
1. "Use CertAnon" flag for the user account to be tested must be set to "Yes" in the
partner site database table
2. CertAnon account configured with the test partner site username must be created
3. Authentication module must be installed on the partner site
Test Inputs:
1. Partner site username
2. PIN
3. Token code
4. New password
Test Procedure:
1. Log into a partner site using a valid partner site username, PIN, and token code
2. Click on the "My Account" link on the partner site
3. Select "No" in the "Use CertAnon" field
4. Verify that "New Password" and "Verify New Password" fields appear
5. Enter the same new password in both fields
6. Click the "Submit" button to save the change
21
Mirra 11/04/2007
7.
8.
Verify that the updated setting now appears on the screen
Verify that the field contents have now changed in the database by running a SQL
SELECT command to view database contents
Expected Test Results:
1. All submitted data is inputted, processed, and placed correctly into the CertAnon
database
2. The updated "Use CertAnon" value should be observed in the database
3. The user should be able to enter a regular password, and that password should be
saved by the partner site
Special Instructions:
None
Test Case 1.11 - Authentication module legacy request/response
Specification References:
3.1.3.2.1 Accept a username and password from the login page of a partner site
3.1.3.2.2 Route authentication requests for non-CertAnon users to the internal legacy
authentication process
3.1.4.1 Provide data entry fields for username and password
Test Level: Component
Test Type: Functional
Test Description: This test will verify that the authentication module accepts and
responds to partner site legacy authentication.
Initialization:
1. Partner site database table with legacy/CertAnon flag set to legacy
2. Partner site database table contains valid legacy username and password
Test Inputs:
1. Partner site username
2. Partner site legacy password
Test Procedure:
1. Log into partner site using valid legacy username and password
2. Verify that authentication module routes non-CertAnon authentication request to
partner site internal legacy authentication process, and that the message returned by
the internal legacy authentication process shows successful authentication
3. Log into partner site using invalid legacy username and/or password
22
Mirra 11/04/2007
4. Verify that authentication module routes non-CertAnon authentication request to
partner site internal legacy authentication process, and that the message returned by
the internal legacy authentication process shows unsuccessful authentication
Expected Test Results:
1. Submission of a valid legacy username and password combination will return a
successful authentication message (Pass/Fail)
2. Submission of an invalid legacy username and/or password will return an
unsuccessful authentication message (Pass/Fail)
Special Instructions:
None
5 Traceability to Requirements
Each test case has been designed to confirm that one or more functional or performance
requirements have been met by the prototype. The traceability matrix shown in Table 3
illustrates these relationships between the requirements and test cases. Requirement identifiers
are shown in the row headers, and test case identifiers appear in the column headers. If a
requirement is addressed by a particular test case, then a yellow "X" will appear in the cell where
the requirement row and test case column intersect.
23
Mirra 11/04/2007
Requirements
Component
Initial account setup
Test Cases
Requirement ID
3.1.1.1
1.1
X
3.1.1.2
X
3.1.1.3
X
3.1.2.1
Account maintenance
interface
1.2
1.4
1.5
3.1.2.2
X
3.1.2.3
X
3.1.3.1.1
X
3.1.3.1.2
X
X
3.1.3.1.3
X
X
1.8
1.9
1.10
X
3.1.3.2.1
X
3.1.3.2.2
X
3.1.3.2.3
X
X
3.1.3.2.4
X
X
X
3.1.3.2.5
X
3.1.3.3.1
3.1.3.3.2
X
X
3.1.3.3.3
X
X
X
3.1.3.3.4
X
3.1.3.3.5
X
3.1.3.3.6
X
3.1.4.1
X
3.1.4.2
Partner sites
X
3.1.4.3
X
3.1.4.4
3.1.4.5
Authentication manager
performance
1.11
X
3.1.3.1.5
Mid-tier
1.7
X
X
3.1.3.1.4
Authentication module
1.6
X
3.1.2.4
Authentication manager
1.3
X
X
3.2.1.1
X
3.2.1.2
X
3.2.1.3
X
Authentication module
performance
3.2.2.1
Mid-tier performance
3.2.3.1
X
X
Table 3. Traceability matrix for the CertAnon prototype
24