Authorization

This section describes Flexera's role-based access control system.

Roles

Resource access in Flexera One's API is governed by Flexera's Role Based Access Control (RBAC) system. Roles are organization-scoped; a principal's access to an organization's resources is defined by the roles that principal has been granted in the organization. When roles are granted to a group, each member of the group is indirectly granted the roles of the group.

Refer to Flexera One Roles for details of the different roles available in Flexera One.

Role Privileges

Each Flexera One role has a unique name, and is assigned a set of privileges to which it gives access. These privileges determine which APIs a user with the role may access.

Privileges are defined in the following format:

<suite>:<resource>:<action>

For example the identity and access management (IAM) privilege to create (send) an invitation is defined like this:

iam:invitation:create

A principal has access to every privilege assigned to each role the principal has been granted. In other words, to determine all the privileges to which a principal has access, take the union of each set of privileges assigned to each role the principal has been granted.

Role-Based API Access

Flexera APIs perform an authorization check after identifying each request's principal. The principal's roles are checked at the time of authorization, making any role changes effectively immediately, regardless if the principal is using a API credential that was generated before the role change.

API Privileges

Each Flexera API definition includes a set of privileges; access to any of the privileges in the set is sufficient to access that API.

The || and + operators in an API's privilege definition denote "or", for example:

iam:invitation:create||common:org:own

An API with the above privilege definition may be called by a user with access to the iam:invitation:create privilege or the common:org:own privilege.

APIs Without Privileges

Some APIs may not define any required privileges, indicating that no role is required to access these endpoints. One example of this is the refresh token API, which allows users to manage their active API credentials. These API credentials belong to the user, not to any organization, and therefore do not require any role.