Embedded Files
Testing the Database Works
To ensure the database is providing valid results, the test outlined in the PoC testing plan in section 4.1.1 will be carried out step-by-step.
"The test - once the reports query has been built - will be to enter one additional attribute row into the toxic table to see if this value appears in the report where it is known to be mapped to a particular user and role. If the attribute appears the reports output has been shown to be working and the test has been validated."
Inserting the Test Value and Validating the Test
The following table (Table 22) tracks through the test access attribute with the expected and actual results. The test will be successful if the expected results all match the actuals.
Table 22 - Tracking the Test Steps and Results
Test/ Step
Data
Expected Result
Actual Result
Pass / Fail
1. Insert a new user with single recognisable attribute into the Application Import table
2. New role "PoC Test Role" inserted into Business Roles for testing
This simulates a new compliance report run. Importing the actual access assignments data from the application.
This creates a new business role, to make the testing easier to follow in the output reports.
Data to appear in the Import table. This simulates a new compliance report run.
No additional data to appear in any other tables.
New role to appear in the users role table.
No additional data to appear in any other tables.
New role to be mapped to the new business role "PoC Test Role".
Mapping should now appear in the "Assigning Roles to Users" query result.
New access attribute added to the app_all_attributes table.
No additional data to appear in any other tables.
The data will appear in the Toxic table, ready for the output report.
Data inserted correctly.
Data not appearing anywhere else.
Data inserted correctly.
Data not appearing anywhere else.
Data inserted correctly.
Data appearing in the SQL query.
Pass
Pass
3. User to Role mapping made in "app_user_roles" table
4. Adding additional attribute to "app_all_attributes" and Imported Apps
5. Setting the new attribute as a toxic attribute for the role of "PoC Test Role". The final compliance "Reports Output" query.
6. Running the compliance "Reports Output" query should display the User RTEST as in breach with the access attribute of "Bad Access Attribute".
Pass
This simulates the compliance user mapping the new user to the new business role. role_id =13 "PoC Test Role".
The output should be visible in the "Assigning Roles to Users" query. This simulates the results screen on the User's Business Group page.
Data inserted correctly.
Data not appearing anywhere else.
Data inserted correctly.
Pass
The all available attributes would be updated with the new access attribute and Imported apps amended if it was a new application.
Pass
Data set as follows, using mapping values created in steps 1-4.
app_id = 1 (Endur)
Role_id = 13 (PoC Test Role)
Attribute_id = 21 (Bad Access Attribute)
This simulates the compliance user amending the Toxic table that contains the access breaches the compliance office would like to check for.
No additional data is required. Only the reports query to be activated.
Any users that have the Business role of "PoC Test Role" and the access attribute of "Bad Access Attribute" should appear on the compliance report.
Pass
Result in screenshot below this table.
Resulting Compliance Report
The report in Figure 33 shows the test access attribute appearing, indicating a successful test (highlighted in red).
Figure 33 - Compliance Output Report
Page updated
Google Sites
Report abuse