Skip to main content
Impersonation lets users act on behalf of others—like support reps accessing customer accounts—by temporarily inheriting a subset of their permissions through a combination of impersonation facts and policy rules.

Implementation

There are two main components to impersonation:
  1. A fact that indicates whether a user is impersonating another user.
  2. A policy that grants permissions to users who are impersonating another user.
In our example, members with a “support” role need to impersonate admins.
In our test case:
  1. Alice is a customer support rep and is impersonating Bob.
  2. Bob is an admin of the acme organization.
  3. And so Alice can see anything Bob can.

Common scenarios

There are several ways to define who has permission to impersonate another user. Common ones include: From a relationship with the user:
Or from a role on the organization:
The is_impersonating fact can be included as an ephemeral context fact or more durably synced to Oso Cloud.
  • If included as a context fact, when a user “ends” an impersonation session, the application stops sending the impersonation context fact.
  • If stored in Oso Cloud, you need to delete the persisted fact to end the impersonation.
Use context facts to scope impersonation to a single application or service, and persisted facts to share impersonation sessions across multiple services.