Impersonation Policy

Impersonation policies enable data consumers to access repositories using single sign-on (SSO), without needing to know the underlying database credentials. ALTR administrators can define impersonation policies at the SSO user or SSO group level and specify which repository user(s) can be accessed.

This approach enables secure access for databases that don’t support native SSO or SCIM, while eliminating the need to create, manage and rotate separate database credentials for each data consumer.

Benefits:

• Simplified user management: Manage human users in Okta instead of the database.
• Secure database accounts: Users can access databases without exposing underlying database credentials.
• Flexible access controls: Define policies based on Okta users or groups — membership changes in Okta automatically apply in ALTR.
• Reduced administrative overhead: Teams only manage a few database credentials while maintaining granular access control via ALTR.

Prerequisites

Before configuring impersonation policies, ensure:

• SSO and SCIM have been configured in Okta
• Repository and repository users have been registered to ALTR
• Sidecar has been installed and registered to ALTR. Contact ALTR Support to get started.
• The sidecar has been bound to the relevant repositories

Create Impersonation Policy

To create an impersonation policy:

1. Log into ALTR via Okta.
2. Click Policy in the navigation menu.
3. Click Create Policy.
4. Locate the Impersonation Policy card.
5. Click Create Policy.
6. Locate the card for your database.
7. Click Create Policy.
8. Enter a Display Name. This is a user-friendly name to identify the policy.
9. Select a Data Source. This is the repository name as it appears in your database.
10. Click Next.
11. Define the rule statement by selecting the following options:
    • A user or group and entering the Name. This is either an individual user or a group, such as Marketing team, as configured in Okta.
    • A Repository User that the IdP user/group will impersonate.
12. (Optional) Expand IdP User/Group to add additional user/groups to the rule statement.
13. Click Save.

Edit Impersonation Policy

Edit an impersonation policy to revoke or grant additional control to repository users.

To edit a policy:

1. Select Policy in the navigation menu.
2. Expand the policy to edit.
3. Click Edit Policy.
4. Update the policy as needed.
5. Click Save.

Delete Impersonation Policy

Deleting an impersonation policy removes the ability for IdP users or groups to impersonate the specified repository users.

To delete a policy:

1. Log into ALTR via Okta.
2. Click Policy in the navigation menu.
3. Expand the policy to delete.
4. Click Edit Policy.
5. Click Delete Policy; a modal displays to confirm.
6. Click Delete Policy.

Conflicting Masking Policies

If multiple policies are applied to a tag where a role is assigned more than one masking policy, masking policies may conflict. If a conflict exists, the most permissive policy is enforced.

The following is a ranking of masking policies from most permissive to least permissive:

1. No Mask — most permissive
2. E-Mail
3. Show Last Four
4. Full Mask
5. Constant Mask — least permissive

For example, one policy specifies that the DataStewards group can access data tagged as PII with No Mask applied. Since the AllUsers group is not included in this policy, users in that group will see NULL values. However, if a second policy grants the AllUsers group access to the PII tag with a Full Mask, users in that group will instead see masked values rather than NULLs. The most permissive applicable policy is enforced.