WBSP
ProvidersDocsSign in
All pages

Managing application access (entitlements)

Audience: tenant administrators. This guide explains how to control which users can use which applications — both directly (per user) and through groups — from the Hosted Admin console, and the equivalent API calls for automation.

Every action here is also available through the HTTP API (see API reference §6.9 and §6.15); the console is a convenience layer over the same operations.

When does a grant matter?

A direct or group grant only changes access for applications in restricted mode:

  • open applications are available to every authenticated user — a grant has no effect.
  • restricted applications are deny-by-default — a user needs a grant (their own, or via a group) to obtain a token.
  • Applications configured with an external access-decision endpoint ignore stored grants entirely (the endpoint decides in real time).

The console shows each application's mode next to its name so you can tell when a grant will take effect.

Per-user access

  1. Sign in to the Admin Console at /t/{your-tenant}/hosted/admin.
  2. In the Users table, click Manage access on the user.
  3. You'll see the applications the user is directly granted. To add one, pick an application from the dropdown and click Grant access; to remove one, click Revoke.

The change takes effect on the user's next sign-in to a restricted application. Grants and revokes are idempotent — repeating one is harmless.

API equivalent (admin key with the application_access:write / :read scope):

# grant
curl -X PUT  -H "X-Admin-Key: $KEY" -H "X-Tenant-Id: $TENANT" \
  $BASE/v1/applications/$APP/access/$USER          # 204
# list a user's apps
curl         -H "X-Admin-Key: $KEY" -H "X-Tenant-Id: $TENANT" \
  $BASE/v1/identities/$USER/applications
# revoke
curl -X DELETE -H "X-Admin-Key: $KEY" -H "X-Tenant-Id: $TENANT" \
  $BASE/v1/applications/$APP/access/$USER          # 204

Group access

A group grants its active members access to one or more applications. Previously only a group's own owner/admins could change those grants; a tenant admin can now oversee any group's grants — even one they are not a member of.

  1. From the Admin Console, click a group name in the Groups table (or open /t/{your-tenant}/hosted/groups/{group_id}).
  2. In the Applications section, Grant the group an application or Revoke one.

Members who had access only through that group lose it when you revoke (unless they also hold a direct grant or another group grant). Disabled members get no group-derived access.

API equivalent — use your own session token as a tenant admin (no group membership required):

curl -X PUT    -H "Authorization: Bearer $ADMIN_SESSION" -H "X-Tenant-Id: $TENANT" \
  $BASE/v1/groups/$GROUP/applications/$APP          # 204
curl -X DELETE -H "Authorization: Bearer $ADMIN_SESSION" -H "X-Tenant-Id: $TENANT" \
  $BASE/v1/groups/$GROUP/applications/$APP          # 204

A group owner/admin uses the very same endpoints for their own groups. A user who is neither a tenant admin nor an owner/admin of the group is refused (403 forbidden).

Delegating control of one application (application administrators)

A tenant admin can hand day-to-day control of a single application to its owning team without making them tenant admins. From an application's detail page (/t/{your-tenant}/hosted/admin/applications/{id} → Administrators), add a user as an application administrator.

An application administrator can, for that one application only:

  • edit its settings, disable/enable it, rotate its secret, and delete it;
  • manage which users and groups can access it; and
  • add or remove co-administrators.

They get no tenant-wide powers: they cannot create applications, manage other applications, change tenant settings, or grant tenant administration. Their authority stops working if they are suspended, and there is no "last administrator" lock — a tenant admin always retains control, so you can remove the last application administrator at any time.

Application admins work from the same console pages a tenant admin uses (scoped to the apps they administer), and the same actions are available headlessly: an application admin drives the application lifecycle and access endpoints with their own session token (no admin key required). See API reference §6.8–6.9.

Creating applications and groups from the console: a tenant admin can also create a new application (/t/{your-tenant}/hosted/admin/applications → Create application; the confidential secret is shown once) and create a group with a chosen owner (/t/{your-tenant}/hosted/admin/groups/new), even when self-service group creation is disabled for the tenant.

What gets recorded

Every grant and revoke writes an audit entry attributing the action to the administrator who made it (application_access.granted / .revoked for per-user changes, group.application_grant_added / .removed for group changes, application.admin_added / .removed for application-administrator designations). No secrets are involved or logged.

What this does not change

  • It does not move applications between tenants, nor change an application's access_mode (set those via PATCH /v1/applications/{id}).
  • It does not alter how access is decided — only which grants exist. Open apps stay open; hook-governed apps still defer to their endpoint.