Role Based Access Control

RBAC Overview

Role based access controls (RBAC) allows fine-grained control on which users are allowed to view, access and update apps. RBAC is supported using OAuth based auth (like GitHub, GitLab etc). When using OAuth, users have to be added to groups in the OpenRun RBAC config. RBAC is also supported with OpenID Connect, like Okta and Microsoft Entra etc. With OIDC, the group information can be detected automatically through the user profile information or it can be configured in the OpenRun config.

Authentication versus Authorization

RBAC is used for multiple authorization checks, like list (view app info), access (access the app) and various update related actions. When RBAC is enabled at the system level, by default RBAC is used for the list and update actions. App access is controlled by the authentication check alone. For example, if app is using google for auth, any user who can login to the google account can access the app. If app access also needs to be controlled using RBAC, then the app auth needs to be changed to rbac:google. With that change, only users having access grant on the app can access the app.

RBAC Configuration

The RBAC configuration is managed through dynamic config. The structure of the RBAC config is

{
  "version_id": "ver_32wLWdqboA08eCRDO1KEznxBxka",
  "rbac": {
    "enabled": true,
    "groups": {
      "group1": ["github_local:abc", "oidc_oktatest:def@example.com"],
      "group2": ["group:group1", "oidc_oktatest:xyz@example.com"]
    },
    "roles": {
      "accessor": ["access"],
      "viewer": ["list"],
      "fullaccess": ["role:accessor", "list"]
    },
    "grants": [
      {
        "description": "view on all apps",
        "users": ["group:group1", "github_local:xyz"],
        "roles": ["viewer"],
        "targets": ["all"]
      },
      {
        "description": "access on one app",
        "users": ["group:customgroup"],
        "roles": ["fullaccess"],
        "targets": ["example.com:/myapp"]
      }
    ]
  }
}

If enabled is false (default), RBAC is not used. groups is a map of group name to group members. Members are user ids, prefixed with the auth provider name. Group composition is supported, for example group2 includes all group1 users. roles is a map of role name to permissions. Roles also can be composed, for example role fullaccess gets all permissions of role accessor.

Users have no permissions by default. Grants have to be added for each permission. A grant has a:

• description which is a note about the grant
• users which is list of users or groups
• roles which is list of roles granted
• targets which is the glob path list of apps to which the grant applies.

The group name referenced in a grant can be a group which is seen at runtime in the user profile. This works for OIDC based auth, like Okta.

Group Info

To get the group info dynamically as part of the user login (instead of statically defining in the config file), the requirements are:

• OpenID Connect based auth is used
• The appropriate scope is requested, like groups
• The Identity Provider is configured to return the groups info the in the user profile, with the groups key. For example, see Okta forum about configuring Okta.
• The group name as returned in the user profile is used in the grant

Notes

• The auth provider name has to be prefixed with rbac: for the RBAC rules to apply for app access.
• Updates using the CLI client are done as the admin system user. There are no RBAC restrictions on the admin.