The SQA2 Blog: BBT - Implemented
What is Security Authorization Testing?
In a general sense, Security Authorization Testing tests typical security requirements that can include elements from confidentiality, integrity, authentication, availability, authorization and non-repudiation.
This article will be discussing how to use BBT to test user authorization.
User Authorization
There has always been a need to test how users with certain access rights can only access designated areas of the system. These access rights are defined by certain sets of rules usually tied to a user type or role.
A simple example would be to compare the Administrator role and the Guest role in Microsoft Windows.
Administrator Rights | Guest Rights |
|
|
|
|
|
Windows Guest accounts are severely limited in what they are able to do. These limitations were designed and predefined by Microsoft.
When a system environment is created, control over what can be accessed is highly critical to the overall security of the system. In most cases, the system designers will want to predefine these user rights. For example, users in the finance department should only be able to interact with the financial database and other related systems. Users in the purchasing department should only be able to interact with the purchasing database and their related systems. Creating a “finance” user role and a “purchasing” user role would be required.
User Authorization Testing
Complete testing of what each user role can do most likely would involve many test cases, and that is only for the “happy path” of testing. In other words, testing to see if only a finance user can access finance systems as well as testing to see if only if a purchasing user can access purchasing systems.
Imagine if there are many more user accounts in this environment. The “happy path” test cases would encompass each one of those user roles and their designated systems. Often times, we overlook the negative test cases. If there are many other user roles in the system, there is a need to test if a user role cannot access the other systems in the environment.
BBT Implemented
By using BBT to identify contexts and outcomes based on the user role requirements, one can easily identify all possible “happy path” test cases.
Using the exact same contexts and outcomes, BBT will also identify all possible negative test cases as well. BBT will automatically see that a finance user role cannot access the purchasing systems and create negative test cases for that. As long as we identify all the “happy path” contexts and outcomes it does not matter how many types of user roles exist.
BBT Implemented: Example
In the slide below, we depict multiple tiers of users for each finance and purchasing role. This kind of granularity can be quite common when there is a need to further restrict users within departments. It is easy to see that certain tiers of users can do only certain actions.
In the slide below, we depict the inverse of the previous slide. We map all the negative test cases generated from the “happy path” contexts and outcomes.
In this particular example, we created 14 contexts and outcomes. These 14 contexts and outcomes will generate 20 “happy path” test cases and 44 negative test cases. In other words, BBT reduced the effort to generate all possible test cases down to just 14 contexts and outcomes.
BBT has the power to transform and revolutionize your security authorization testing with perhaps the biggest win of them all – identifying all possible negative test cases.
To see more examples go more in depth on how the BBT Tool works, reference the blog on BBT optimization.