Role-Based Access Control - RBAC¶

The OctoSAM web interface implements a fine-grained authorization mechanism that allows to specify limited read and update rights for individual users. The authorization mechanism follows the RBAC de facto standard.

The classic OctoSAM Windows UI only has global read and global write rights, you cannot restrict access to parts of the data.

OctoSAM RBAC concepts and definitions¶

Privileges¶

A privilege is the right to perform a low-level operation. For example, the privilege Machine.Fields.DirectoryCity.Read allows read access to the field DirectoryCity on the Machine object. OctoSAM defines and manages all privileges and makes them available to be assigned to roles.

Roles¶

A role is a combination of privileges that together grant permissions required to perform a specific function.

Predefined roles¶

Administrators¶

The predefined role Administrators grants a combination of privileges required for application administration.

ReadOnlyUsers¶

The predefined role ReadOnlyUsers grants read access to the whole OctoSAM application.

SoftwareItemOwners¶

This role allows to own a Software Item. Owners of Software Items can be assigned additional rights on their owned items.

Users¶

RBAC users are replicated from Microsoft Active Directory. Currently, OctoSAM RBAC requires users to be defined in Active Directory.

Groups¶

RBAC groups are replicated from Microsoft Active Directory. Currently, OctoSAM RBAC requires groups to be defined in Active Directory.

Role to group relation¶

OctoSAM RBAC relates roles defined in OctoSAM to groups defined in Active Directory. A user that is member in multiple roles receives the cumulated privileges of all roles.

RBAC replication¶

All objects from Active Directory are replicated to the OctoSAM database during nightly housekeeping. The RBAC mechanism itself does not access Active Directory directly. This allows to verify an RBAC model without a live connection to AD.

Wildcard privileges¶

For example, OctoSAM defines the following privileges to access Modules in the OctoSAM web interface.

   Module.Admin.Execute
   Module.Inventory.Execute
   Module.Query.Execute
   Module.Monitor.Execute
   Module.License.Execute

You can assign the Privilege Module.ALL.Execute to a role to cover all of the Module Execute privileges. OctoSAM defines and manages all wildcard privileges. If a future release of OctoSAM defines a new module, execute privilege for this new module will automatically be included in the Role.

The ALL wildcard does not match the .

There is no hierarchy of privilege levels. The . is used only to delimit the Wildcard match. If you want to grant access to a subset of privileges instead of 'ALL' you have to specify each required privilege.

The ALL wildcard can be used on multiple parts such as ALL.ALL.ALL.Read

This would match

   Machine.Fields.Name.Read
   User.Fields.Domain.Read

List of privileges¶

Privilege names are intended to be self-explanatory. OctoSAM automatically manages the list of available privileges. Currently, there are approx. 2000 defined privileges. The web interface shows lists of granted and denied privileges per user. The denied privileges list helps you to find potentially missing privileges for a role.

Fields privileges¶

Field privileges control access to a specific object field. The names correspond to the names of the fields in the database. The fields are documented in the database Schema.Usually, the same names are used in the user interface, where possible. For objects that have multiple name components, the field PrintableName is usually used to display the object. So to display a Machine object, the user needs at least the Machine.Fields.PrintableName.Read privilege.

Annotation privileges¶

Annotations are site-specific object properties. One type of annotations are the Extended Attributes that can be defined via the Octopus2 UI. Other types of annotations are automatically created from inventoried systems that also allow site-specific annotations such as VMWare vCenter.

Relation privileges¶

A Relation privilege is used in the case where there is a relation to another object type. For example, a Software Package can be installed on multiple machines. To view Machines related to a SoftwarePackage a user needs the SoftwarePackage.Relations.Machine.Read privilege. To display the Machines, Machine.Fields.PrintableName.Read is also required.

Owner privileges¶

Some objects allow to set different permissions for 'Owned' objects. The meaning of 'owned' is specific to each object type. For Software Items, ownership can be defined explicitly in the application. For User objects it means the application users own User and RbacUser objects. For machine objects, ownership is computed from the user-to-device affinity.

Meta privileges¶

To update an object in the database, multiple permissions are sometimes needed. For example, to be able to update the Custom Field1 on Machine, required Permissions are

Machine.Fields.CustomField1.Write
Machine.Update

This is because an update to CustomField1 also implicitly updates some metadata on the machine (such as LastModification/LastModifiedBy)

Per object privileges¶

Some objects in the database allow per-object privileges. The objects are identified by their object GUID. If that is the case, a role can have different privileges on each object. For example, Access to Queries can be defined by Query.

Privilege elevation in queries¶

If a role allows access to a query, it depends on the definition of the query, whether the query itself filters access to data via RBAC or not. A query can potentially show data that the user does not have a direct access privilege. This can be used by site-specific queries, to create reports that show or aggregate data that the user can not normally read.