Skip to main content

Users and roles

Octostar users and roles live in Timbr. An administrator grants a role to a user in Fusion, or with SQL in Fusion's SQL Lab as the admin user:

GRANT ROLE `os_developer` TO `alice`;
REVOKE ROLE `os_developer` FROM `alice`;

With single sign-on, oidc.roleMapping in local-env.yaml can grant a role to the members of an identity-provider group (see Keycloak and custom OIDC).

Platform roles​

RoleWhat it gives
adminFull access. Admin-only platform settings and every action below.
os_adminAdmin access to the platform, including app management.
os_userQuery access to the ontology. Give it to every user.
read_all_workspacesRead access to every workspace.
write_all_workspacesWrite access to every workspace.
admin_all_workspacesAdmin access to every workspace.
os_developerApp management: create, change, deploy and undeploy apps, and change their files, settings and secrets.

admin, os_admin and the *_all_workspaces roles are admin-class roles: single sign-on does not grant them unless oidc.allowAdminRoles is set. os_developer is not admin-class, so a group can map to it.

App developers: os_developer​

Apps run code in the cluster, so only app developers manage them. A user who does not have os_developer, admin or os_admin gets 403 Forbidden from these actions:

  • deploy an app, and deploy, redeploy or undeploy apps in bulk
  • undeploy an app
  • change or delete an app's secrets
  • create an app
  • change, move or delete an app, its settings, or a file or folder in it
  • move a file or folder into an app
  • delete a folder or a workspace that holds an app

The developer also needs write access to the app's workspace. In a workspace they create, the developer is the owner. Undeploying leftovers that name no workspace, and tearing down orphaned app deployments, need admin or os_admin. Users without the role can still open and use apps that are deployed.

admin_all_workspaces is a workspace role, not a platform admin role: it does not let a user manage apps.

Octostar reads the user's roles from Timbr, not from the login session, so a grant or a revoke applies within 10 seconds. The user does not need to log in again.

Developers who log in with single sign-on​

A role granted by hand in Timbr stays when the user logs in again, until an administrator revokes it. A role that a group mapping grants follows the group: Octostar revokes it at the next login after the user leaves the group. To give os_developer to the members of an identity-provider group, map the group in local-env.yaml:

oidc:
  groupsClaim: "groups"
  roleMapping:
    octostar-users: "os_user"
    octostar-developers: ["os_user", "os_developer"]

The group must exist in the identity provider. The bundled Keycloak creates only octostar-users and octostar-admins: create octostar-developers in Keycloak first, and add the developers to it. A role granted directly in Keycloak, not through a group, does not reach Timbr.

Installs and upgrades​

A new install creates the os_developer role and grants it to nobody: an administrator grants it to each app developer.

If users get 403 Forbidden on deploy after an upgrade, check the role in Fusion's SQL Lab as admin:

SHOW ROLES;
SELECT username FROM timbr.sys_users_roles WHERE role = 'os_developer';
  • os_developer is missing: restart octostar-api, which creates it.
  • os_developer exists but those users do not hold it. Grant it by hand to each of them: GRANT ROLE `os_developer` TO `alice`;