Role Based Security
Overview
Role-based security (RBS) refers to a type of authorisation process that allows a User to access some resources and not others, and/or to perform specific tasks, based on their Role.
A Role may be the User’s job title or position in the organisation, or may refer to a group or part of the organisation to which the User belongs. A Role may simply exist to denote Users who need access to identical resources within the software.
The advantage of setting permissions against Roles is that once a Role is set up, Users can simply be added to that Role in order to gain the permissions set against the Role. And if the scope of permission required by a Role changes, this can simply be performed against the Role with all Role Users automatically inheriting the change.
RBS Permissions
Permissions in RBS can be thought of as describing a task or action. Typical examples of permissions may be Can view risks or Can edit risks. In RBS, permissions have a name and a description.
Permission Allocation
A permission becomes useful when it is allocated to a User or Role:
- Allocating a permission to a User allows that User to perform the action represented by that permission. So, for example, if a User called John is allocated the permission Can create invoice, the application would allow John to create an invoice.
- Allocating a permission to a Role allows all Users who are in that Role to perform the action represented by that permission. So, for example, if a Role called Account Managers was given the permission Can create invoice, and Users John, Margaret and Rajesh where members of that Account Managers Role, then John, Margaret and Rajesh would automatically be allowed to create invoices in the application.
RBS Roles
A Role in RBS is simply a container within which to group Users who perform that Role. The Role must be given a name, and can be given a description.
A Role can contain many Users, and a User may belong to more than one Role.
Role Permissions
A Role is allocated permissions, thus providing all Users within that Role those permissions.
If a User is a member of more than one Role, they inherit all the permissions from all the Roles to which they belong. When permissions allocated to their Roles coincide, a User may actually inherit a permission more than once.
RBS Users
A User may also be allocated permissions directly. This is useful if a particular User requires all the permissions of a particular Role, plus a few extra permissions, possibly on a temporary basis. For example, if a manager is off sick, one of his employees may be required to assume part of his Role for the day, but not get all the permissions from that Role. Rather than set up a new Role just for that day, it is possible to allocate only those additional permissions required directly to the employee only.
RBS User Interface Functionality
Select the System tab and then select the appropriate option from the Security menu. The following chapter describes the RBS pages.
After permissions or Roles have been changed for a User, the User will need to log out of OpRiskControl, and log back in before the changes take effect.