Impersonation Policy with Sidecars

On a sidecar-connected repository, an Impersonation Policy lets a data consumer connect using a temporary token instead of a repository password. The data consumer signs in to ALTRNet with single sign-on (SSO) and generates the token; the sidecar evaluates the Impersonation Policy to determine which repository user the token maps to, then forwards or blocks the connection accordingly and logs the result.

How the Connection Works

The data consumer’s SQL client connects to the sidecar’s hostname and listener port using the same username and password fields it would use for a direct database connection. In place of the repository password, the password field carries the temporary access token; the token encodes which repository and which repository user the connection is requesting. The username field is still load-bearing — it must be set to the same repository user selected when generating the token, since the sidecar checks that the username matches the identity the token carries.

After signing in to ALTRNet with SSO, the data consumer selects which repository user they want to connect as before generating the token — a separate step from the admin-side policy configuration that determines which repository users a given user or group is allowed to select. For the connection steps themselves, see Connect to Repository Through Impersonation.

How the Sidecar Evaluates the Policy

When the sidecar receives a connection carrying an access token, it evaluates the Impersonation Policy to confirm the requesting identity is mapped to the requested repository user. If the mapping is allowed, the sidecar forwards the connection to the repository as that repository user; if it isn’t, the sidecar blocks the connection. Either outcome is recorded in ALTR’s audit trail.

For how to create and manage the policy itself — mapping identity provider (IdP) users and groups to repository users — see Allow Access to a Repository.