Skip to content

Latest commit

 

History

History
110 lines (70 loc) · 5.62 KB

rbac.md

File metadata and controls

110 lines (70 loc) · 5.62 KB

Role Based Access Controls

Semantic Model

In order to restrict access to certain portions of the CMDB, Onix divides the data into logical partitions.

Users, logged under a specific role, can then be granted privilege to create/update, read and or delete data in a logical partition.

The following diagram shows how access control works:

Onix Data Model.

Partitions can be assigned to either:

  • A model and all its related item types, link types and link rules.
  • An item and any links associated with it.

Default partitions

By default, Onix provides two partitions as follows:

Partition Description
REF The reference data default partition. Any model information is added to this partition by default, unless the model data is explicitly assigned to a different partition.
INS The instance data default partition. Any item and related links are added to this partition by default, unless configuration data explicitly assigned to a different partition.

Default Roles

By default, Onix provides three roles as follows:

Role Description
ADMIN Has default privilege to create/update, read and delete on both the REF and INS partitions.
READER Has default privilege to read on both the REF and the INS partitions.
WRITER Has default privilege to read on the REF partition and to create/update, read and delete on the INS partition.

In other words:

Role Partition Create? Read? Delete?
ADMIN REF Y Y Y
ADMIN INS Y Y Y
WRITER REF N Y N
WRITER INS Y Y Y
READER REF N Y N
READER INS N Y N

Role Levels

Any role is associated with an administration level.

The administration level determines the privilege the role has to create, update, read and delete partitions and other roles.

In other words, the administration level determines which kind of administrator the role is.

The following table shows the three available levels:

Level Description
0 The role cannot modify or read neither partitions nor roles data. This level is associated with non-admin roles. It is the default level for any role.
1 The role can only modify / read partitions or roles data for the ones which are owned by the role. That is, partitions and roles that have been created by the role in the first place. If the role attempts to modify or read a partition or role owned by another role, then an error message is displayed.
2 The role can modify / read any partition or role data. This is the case of a super administrator role (i.e. ADMIN role)

Authentication Modes

Onix supports three authentication modes, based on the value of the AUTH_MODE environment variable as follows:

AUTH_MODE Description RBAC Behaviour
none No authentication is required. Intended only for development. Role ADMIN is applied to the user by default.
basic Basic authentication is required. Three fix set of credentials can be configured at the service level mapping to ADMIN, WRITER and READER roles above.
oidc OpenId Connect authentication is required. The token presented to the service must have a claim called role containing the name to be mapped to the role defined in the Onix data model. This role in turn defines the privileges the user has on one or more logical partitions.

Controlling access to data with OpenId Connect

Suppose you want to restrict access to read part of the data model to a group of users. For instance, a particular project team needs to read and write data for the project but users of other projects should not have access to this data.

A logical partition is created for example with the name of the project. Any data the project creates in the CMDB is set to use such partition.

In parallel, two roles are created, namely Project_Reader and Project_Writer.

Privileges are also created for each role. The Project_Reader is granted read access to the Project partition whereas the Project_Writer is granted create, read and delete rights to the Project partition.

The OpenId provider fronts a user directory where two groups exist for the project, namely Project_Reader and Project_Writer.

When the user access the Onix service, the service request the provider to authenticate the user and issue a token.

The provider verifies the user credentials and if successful, adds a claim named role to the token. The value of the claim is based on the group membership of the user in the directory. For example, if the user is in the Project_Writer role, then the claim role contains the Project_Writer value.

The token is passed back to Onix, which extracts the claim role and match it against the role defined in the database. Any data operation requested by the user is subjected to verification of its role privileges. If the role does not have a privilege to execute the requested data operation, an exception is raised.