Authorization¶

Standard RBAC¶

Warrior has a role-based access control (RBAC) system with a set of pre-defined roles. The available roles for non-OIDC users are User, Model Owner, Administrator, and SuperAdmin. If enrolled in multiple organizations, the user can have a different role in each organization. For a full list of permissions for these 4 standard roles, please reference Permissions By Standard Roles.

User: Has view-only access to the models and data within the organization.
Model Owner: Can onboard new models in the enrolled organization as well as send data including reference data, inferences, and ground truth.
Administrator: Organization level administrator that has access to manage users and models within the organization.
Super Admin: Has full access to all data, models, and actions on the platform. Can create new organizations and manage users.

Standard RBAC for OIDC users.¶

For customers using OIDC Authentication (on-prem only), Warrior also has a standard RBAC system with a set of pre-defined roles. To assume these roles, your OIDC provider must supply one as an authenticated role. The authenticated user will then be authroized for that role across all of their authenticated organizations. For a full list of permissions for all standard roles, please reference Permissions By Standard Roles.

Custom RBAC for OIDC users¶

For customers using OIDC Authentication (on-prem only), Warrior provides the ability to set up a fully customizable RBAC. Please follow the below:

For each installation of Warrior there must be at least one role with global privileges to create organizations. There are two options for a global role:
- When setting up your OIDC provider via the YAML configuration, supply a global role name and set of permissions under administratorRoleDef that your OIDC provider will authenticate users with. This will create this global role in our Authorization system. See Authentication Docs for more information.
- Use the built in Super Admin role. To use this role, either your OIDC provider must supply “Super Admin” as an authenticated role, or a user must login manually outside of OIDC as the default Super Admin user.
That global role can then create custom role mappings for each organization:
- During organization creation, include the role configuration JSON (see below for example) in the request body when calling POST /organizations.
- After an organization is created, create or add custom_roles by sending the role configuration JSON (see below for example) in the request body when calling POST /autorization/custom_roles.
Users logging in through your OIDC must now have a valid known role in their token when accessing the Warrior Platform. Warrior will use this role to both authenticate that the user is a member of the organization and to determine the permissions they have.

Managing Roles and Permissions¶

Understanding Permissions¶

A permission is a combination of a resource and an action. For example raw_data read, users write, models delete.
For a full list of available permissions. please see Permissions Set.
For a directory of permissions by API endpoint, please see Permissions by API endpoint

Create Custom Roles¶

The POST /autorization/custom_roles endpoint is available for customers using OIDC to operatore on custom roles for each organization. A few notes:

This endpoint only operates on permission scopes within each organization. Permissions that have global scope (such as creating a new organization) cannot be granted via this endpoint, those permissions must be assigned to a role with global privileges via the OIDC configuration YAML (see above).
Roles can have a list of permissions to allow and/or a list of other roles to inherit permissions from.
Role names cannot conflict with default Warrior roles.
Supplied permissions must be valid known Warrior permissions.
Roles can inherit the permissions of other roles that are either default Warrior roles, or roles also defined in the same organization. Unknown inherited role names will be rejected.

Get Custom Roles¶

To retrieve a list of roles defined for an organization, use: GET /autorization/custom_roles. To filter on specific roles pass a comma separated list of role names in a roles query parameter. For example:/authorization/custom_roles?roles=role1,role2. If you wish to return all roles simply leave out the query parameter or pass "*" as role.

Delete Custom Roles¶

To delete a role or multiple roles from an organization, use DELETE /autorization/custom_roles](../../api-documentation/v3-api-docs.html#tag/authorization/paths/~1authorization~1custom_roles/delete). Specify which roles to delete in the JSON request body. For example, to delete a single role:

      {
           "roles": ["role3"]
      }

To delete all roles pass “*”

{
    "roles": ["*"]
}

Example Role Configuration JSON¶

Below is an example JSON request body that creates three roles. role1 has 3 permissions defined, role2 gets an additional permission and then inherits the 3 permissions from role1, and role3 inherites the permissions from Warrior’s default “Model Owner” role. For more details on the expected schema for each endpoint, see Authorization API documenation.

{
    "roles": [
        {
            "role_name": "role1",
            "permissions": [
                {
                    "resource": "metric_data",
                    "action" : "read"
                },
                {
                    "resource": "metric_data",
                    "action" : "write"
                },
                {
                    "resource": "tag",
                    "action" : "read"
                }           
            ]
        },
        {
            "role_name": "role2",
            "permissions": [
                {
                    "resource": "user_self",
                    "action" : "read"
                }
            ],
            "inherited_role_names": ["role1"]
        },
        {
            "role_name": "role3",
            "inherited_role_names": ["Model Owner"]
        }
    ]
}