Roles and Their Uses within Web and Mobile Applications Software

What is a role? 

A role is a set of behaviours, conditions and rights that can be applied to an actor within a particular situation. Roles can be applied to many different situations in society, however this mini report will focus on how roles can been implemented within a piece of software to make it more secure.

What is the purpose of roles?

Roles are controls that are assigned to an application. When roles have been assigned, it means that there is some protected data that can only be accessed via log in (username and password). Typical roles control:

• Who can log into an application in the first place. 
• What data the user can have access to as read-only. 
• What data the user can update themselves; add, edit or delete. 

All companies want to use various user roles that allow different modes of access. I am going to use a diagram to illustrate the hierarchy (see below). Generally, the higher up the hierarchy, the more permissions and rights that user has.

• Users – These are read-only access roles that allow access to their own account log in details, give the ability to modify their own details (e.g. change their name, update their password), view their own projects and see the shares and share holder information linked to both of those projects. 

• Managers – These are the directors who are in control of their own projects. They can only view the projects that they are directly assigned to (they would have no need to view the information of other directors that are unrelated to their own work) however, they have complete access and the ability to modify any information within their own projects. They can also view the other members within their own project but do not have the permissions to make adjustments to existing user accounts. 

• Administrator (or super administrator) – These accounts are used very sparsely as they have no restricted access at all and can view all data and information from all projects. All data can be modified or deleted and new data can also be input anywhere in the system. All users and user information can be accessed too which allows, for example, if a user has forgotten their password for the password to be changed. If users are not applicable in the system anymore, they can also be removed. 

There is also the possibility of having anonymous access roles that allow complete strangers to have access to the site. Some companies would want this but some would not.

It is also possible to add permissions to buttons and controls using validation rules, which not only stop users who should not have access to them from using them, but will hide the button completely from the screen so the user that has logged on would not even know that there was a button there.

What would happen if roles did not exist?

If roles did not exist, then data would certainly leak out to the wrong people. Roles are a safety barrier that prevents confidential and private information from being accessed by people who should not have access to it. It is incredibly important to ensure that you assign the correct roles to the correct people, otherwise the objective of roles has been defeated, and they are there to protect data!

Designers and developers create Use Case diagrams in order to help decide what user roles an application will adopt and what permissions they will have. The diagram below shows a quick example on what a typical Use Case diagram looks like:

So how would I set up a user role tables within my database?

It is very easy and straight forward to set up user roles within your database to be used within your asp.net applications.

Firstly, create 2 tables called UserAccount and UserRole:

There is a reason why I stated use those names. In SQL coding, try to avoid using names such as user, role and password: 

This is because, as you can see from the screen grab above, they show up blue as they are reserved SQL keywords. Try to avoid using these as it can get SQL very confused. You could possibly use them by places square brackets around them:

But in this example I am going to use different names.

Next, you will need to decide on the relationship between users and their roles. Can 1 user have multiple roles? Possibly. Can 1 role have multiple users assigned to it? Most probably. For the purpose of this tutorial, I will suggest creating a bridge table:

And that really is it! Just remember to encrypt your passwords to keep them secure!

In your asp.net application, you will be able to configure your settings so that it follows the security in your database. However, it is also possible to use the standard asp.net membership system which can generate users and roles automatically. This method is just as good (it contains a similar table structure with a bit more), the only difference is particular code generators such as Iron Speed Designer may find it easier to interpret your own created tables when setting up security.