Role Playing With Access Permissions

Websites, applications, games – the information resources managed by the users. To split allowed and forbidden actions for a particular actor, access permissions are used. Scope of authorization rights defines the roles. For a clear example, let’s look at the basic site with the registration option.

This website is "inhabited" with 3 separate roles with particular rights and responsibilities:

1. Unauthorized User

All website guests act in this role by default. If we’ll grant them the right to "Add comments", then anonymous users will be able to reply to your posts. If not, then in order to comment content visitors will need to register first.

2. Authorized User

After the authentication and authorization, anonyms get a new role. Only authorized users can control the member account, add and edit the personal data, view information about the other website guests. Unregistered users are not eligible for these operations.

3. Administrator

This role gives the actor the full access to the site by default. Administrator adds and deletes new blocks, gives or takes away other users’ rights to access the particular functionality.

Testing Tips

First, try not to delete the "Super administrator" while playing with the settings.

• Create a Safe Character

An additional user with similar authority to the administrator will be a real deal to get closer to the actual activity on the project. Use this character to test the resource and change the access permissions of others.

• Check in Multiple Browsers

At the same time we modify the access permissions in one browser, and check the accuracy of changes application in other, thus separating the user session

• Click the Direct Link

Test blocks’ limitations, clicking the direct URL address. Some of the resource data should be unavailable for unauthorized users. If access is restricted, then everything is ok: instead of private information anonymous will receive a warning message in the form of a special page, often with the 403 code.

• Test the Concurrency Control

For resources such as ticket and travel booking services, it is important to block elements, which might be accessed by multiple users. There are two ways to isolate them:

+ Optimistic concurrency checks the database for a newer version of the data left by another user. If it exists, then the current actor reloads the entity.

+ Pessimistic concurrency (locking) is used when the optimistic one produces too many collisions. In this case, only one visitor at the current time interacts with entity given.

You can test this point on one computer through multiple browsers or accounts.

• Use the Test Matrix

It simplifies the tester’s work, clearly shows permitted and prohibited activities, and just helps not to miss anything. Fill it with roles, user variations and limits of actors’ capabilities.

Here is a simple example of a test matrix:

Authorization rightscontrol is one of the main inspections in the framework of software security testing . Even checking the website of the local library with, like, three roles might be challenging for the specialist. So popular resources with dozens of roles, thousands of users and millions of permissions require a whole army of administrators! It is difficult to imagine the extent of the damage if an amateur carries out the testing. Engage qualified specialists only and avoid gaps in the security of your products!