For the complete documentation index, see llms.txt. This page is also available as Markdown.

Using Privileged Cloud JIT Elevation with IDP Authentication

Use direct or federated identity providers for Privileged Cloud JIT elevation.

Overview

This guide explains how Keeper Privileged Cloud handles elevation through either a direct identity provider or a federated identity provider.

Use direct authentication when the target platform manages identity in its own provider. Use federated authentication when the target platform relies on a separate provider for authentication and authorization.

In both models, KeeperPAM applies Workflow and JIT settings to grant temporary access through the identity provider for the approved time window.

Choose the Authentication Model

Direct authentication means KeeperPAM authenticates and authorizes the user against the identity provider defined on the target PAM configuration. For example, if AWS is configured as the PAM network, the gateway communicates directly with AWS IAM.

Federated authentication means the target PAM network uses a separate identity provider for authentication and authorization. For example, AWS Identity Center can federate to Azure Entra ID, and KeeperPAM applies the elevation through the Azure tenant.

Example - AWS using Identity Center, with Azure Entra ID as Federated IDP

In the following example, an AWS tenant is configured to use Entra ID as it's source of authentication and authorization.

For this to work, the following steps need to be taken:

  1. In Keeper Vault, create separate folders for each tenant. In this example:

    1. "AWS Resources Folder"

    2. "Azure Resources Folder"

  2. Create a Secrets Manager Application in Keeper Vault for each tenant.

  3. The federated identity application must be given access to the application using a federated identity, due to access permissions required by the gateway to read resource settings within that application. In this example, the "AWS Resources Folder" must be able to be accessed by the "Azure Application" — at a minimum, read only access is required.

  4. Create a PAM configuration for each cloud provider using the steps outlined in the PAM Configuration pages:

  5. Provision a gateway that can access the Azure tenant — this is necessary because we are using Azure as the Identity Provider to elevate the user's access through the workflow and JIT settings of a record.

  6. If needed, provision a gateway that can access the AWS tenant — this is needed when a PAM Machine or Database is provisioned in AWS that needs to be accessed by a user via Keeper Vault records.

  7. Follow the documentation from Amazon for integrating AWS Identity Center into Azure Entra ID. The documentation can be found in the official AWS help pages: https://docs.aws.amazon.com/singlesignon/latest/userguide/idp-microsoft-entra.html

  8. Set the AWS PAM configuration to federate identity through the Azure PAM configuration. An example will be provided below.

Creating a KSM Application

As stated above, a folder has been created for each of the applications being configured. For more information on Keeper Secrets Manager applications, see Applications on how to create KSM applications.

AWS Application

Azure Application

Creating the PAM Configurations

In this example, both AWS and Azure tenants have been configured as PAM networks. The AWS PAM configuration points to the Azure PAM configuration as its source of identity (federated directory). To enable this feature, the "Federated Directory" box must be checked, and the correct IDP selected from the list.

AWS PAM Configuration

Azure PAM Configuration

Once these PAM configurations are setup correctly, and the IDP is integrated with the cloud platform, JIT elevation should occur within the IDP tenant when a user either requests access or elevates their permissions.

Last updated

Was this helpful?