Roles and permissions

Once a user has been authenticated, the user is granted or denied the right to access each protected object in the system using a permissions map (a category-based matrix), which is defined by the role assigned to the user. Permissions define the rights a user has within each category of station objects.

Roles ease the management of permissions for a large number of users. The permissions for a group of users who are assigned to the same role can be updated by changing the role. This saves having to update each user’s permissions individually.

For example, if 40 operators need access to a new component in the station, you may need to update only their shared operator role, and then only if a category has been added or permissions need to be changed. The initial configuration of a station’s security, which involves object permission levels, object categories, roles (permissions) and users may take time to design and set up in some configurations, but the trade off is worth the future time saved when updating the permissions of more than one user at a time.

 CAUTION: There are risks involved in giving any user broad permissions on the Role Service. For example, giving a user admin write permissions on the Role Service allows that user to create, edit, rename or delete any role. Best practices recommend that such permissions on the Role Service be limited only to appropriately authorized users.