Maintaining Security Roles

Overview

A security role is a collection of rights. Users are assigned a security role so that they can be given the associated rights to resources.

From time to time, a specific security role is created so that specific rights can be adjusted in terms of their availability within the role.

Given that a security role is a collection of rights, and a right is a collection of resources and the level of access to those resources, when a security role is applied to a user, the rights associated with the security role determines the level of access to those resources for that user.

A user can be assigned a security role for a particular laboratory, or all laboratories. Where a user has multiple security roles and more than one security role contains the same right, the permissions to use the resource are amalgamated to provide the best level of access to that resource.

Process

Users are created using the MSESEC—Security application and exist at instance-level, that is, above organisations and laboratories.

Maintaining Security Roles

Maintain security roles

Upon maintaining security roles:

The event is audited.

Default security roles are provided with CCLAS 6, however, there may be occasions when you want to create you own custom security roles. Security roles can be created from scratch or from an existing securit role, such that, an existing security role is copied and adjusted to add or remove specific rights. When a security role is saved as another security role, the source security role's rights and users are copied to the destination security role.

Selected security roles can be exported to a json file for distribution. From time to time, it is useful to be able to distribute the definitions within a custom security role to other CCLAS 6 environments, for example, when validating some definitions in a development, training or testing environment before applying them to a production environment. This file can either be distributed (for example, by email) to other users in remote sites, or moved from the Download Folder for backup purposes.

Note: This file is not intended to be edited by the user, so its format is not described here.

Security Roles can be imported from a json file. During this process:

If the custom security role does not exist, then the custom security role and its members are inserted.
If the custom security role already exists, then the Role Description is NOT replaced.
If the custom security role already exists, then rights are appended from the source.
If the custom security role already exists, then its existing rights are not removed.

Maintaining Rights for a Security Role

Each security role comprises a set of rights.

Maintain rights for a security role

Note: You need to restart an application for these security changes to have an effect.

Security Requirements for Sub-service Calls from a Called Service

Where a user has permission to call a service and that service calls an underlying service to which the user may or may not have permission to access if they were calling that service directly, when the user calls the service, then the system grants them permission to call the underlying services. For example:

If the user has the permission to delete a job, when the user deletes a job, then the system does not check whether the user also has the permission to delete samples, but proceeds to delete these, where required.
If the user has the permission to create a scheme, but the system is configured to create an accompanying QC mask, price code, method and scheme limit specification automatically, when the user creates a scheme, then the system does not check that the user also has the permission to create QC masks, price codes, methods or specifications, but proceeds to create them, where required.
If the user has the permission to create a product, in which a product specification is created, when the user creates a product, then the system does not check whether the user also has the permission to create a specification, but proceeds to create a product specification, where required. That is, even though the user can create a specification via production creation, they may not have permission to directly create a specification using the specification application.
If the user has the permission to create a standard, in which a standard lot and standard specification is created, when the user creates a standard, then the system does not check whether the user also has the permission to create a standard lot or specification, but proceeds to create a standard lot and standard specification, where required.
If the user has the permission to create a client quote, when the user attempts to create a client quote and new shareable quote in the process, then the system only checks the permission to create a client quote and does not check the permission to create a shareable quote. That is, even though the user can create a shareable quote via the client quote application, they may not have permission to directly create a quote using the quote application.

Applying Security Changes

Three security-related caches are used by the system: the authorisation cache, authorised applications, and core CCLAS securities.

Note: There is an 8-hour cache period for each of these security-related caches. Changes to security do not come into effect until after this cache period expires, and even then, where security permissions are changed for a user, the old security permissions still apply until the user logs in again.

Where the following actions succeed, then the security-related caches are cleared:

Assign Role to User

assignRole(Role role, Scope scope, String userName)

Un-assign Role from User

unassignRole(Role role, Scope scope, String userName)

Save attribute (the Resource attribute AT)

saveAttribute(AttributeConfiguration attribute)

Grant access (permission) to a Resource for a Right

grantRightResourceAccess(Right right, SecuredResource resource, String permission)

Revoke Application access for a Right

revokeRightApplicationAccess(Right right, String applicationName)

Revoke access to a Service for a Right (the term Class is used for Service in the logic)
```
revokeRightClassAccess(Right right, String className)
```

Revoke access to an Attribute for a Right

revokeRightAttributeAccess(Right right, String className, String attributeName)

Revoke access to a Resource for a Right

revokeRightResourceAccess(Right right, SecuredResource resource)

Add Right to Role
```
addRightToRole(Role role, Right right)
```

Remove Right from Role

removeRightFromRole(Role role, Right right)

In multi-server environments, the clearing of the security-related caches only occurs on the server where the ADMIN user (the user making the security permission changes) is logged into. The user whose security permissions are changed may be logged into another server: the 8-hour cache period must expire before security changes come into effect.

Licencing

When an attempt is made to add a user with an active security role to the system, or to add a security role (default active) to a user who currently has no active security roles, then the environment's licence key is checked to determine whether the user role can be added.

If there is no licence key in the table, then an error is raised: CCLAS Licence is not available. Contact LIMS Manager for Licence Update.
If there is a licence key in the table but the licence key is expired, then an error is raised: CCLAS Licence has expired on <ExpiryDate>. Contact LIMS Manager for Licence Update.
If there is a licence key in the table but the licence user count is reached or exceeded, then an error is raised: Licenced Users count exceeds the Licence Count of <MaxUserCount>. Contact LIMS Manager for Licence Update.

This also applies when Maintaining Users and an attempt is made to add an active security role to a user.