PingOne for Enterprise

Connect to Azure

About this task

The Microsoft Azure identity bridge uses OpenID Connect and OAuth to connect to your Azure provider (OP) to authenticate your users and access user information. In OpenID terms, PingOne for Enterprise is the Relying Party (RP) that sends authentication and information requests to the Azure provider.

To configure the identity bridge, you’ll be working on both the Azure and PingOne for Enterprise sides and copying information from your Azure tenant to the PingOne for Enterprise identity bridge setup.

OpenID Connect supports a discovery mechanism whereby an OpenID Connect host publishes metadata using a well-known URL, by convention of the form: https://host.com/.well-known/openid-configuration. The URL returns OpenID Connect and OAuth endpoints, supported scopes and claims, public keys used to sign tokens, and other metadata. We use this metadata to complete your authentication requests and requests for user information.

Steps

  1. In PingOne for Enterprise, go to Setup → Identity Repository, click Connect to an Identity Repository, and select Microsoft Azure AD. Click Next.

  2. Sign on to your Azure tenant and go to Azure Active Directory → Add → App registration.

    1. On the Register an application page, enter a name for the PingOne for Enterprise client (such as, "PingOne").

    2. Under Supported Account Types, click to select which Microsoft account types you will allow access.

    3. Optional: Under Redirect URI, select an authentication method from the list, and in the text field enter a URL.

    4. Click Register to save the PingOne for Enterprise client.

      Result:

      The application overview page is displayed.

  3. Copy the Application (client) ID value.

  4. PingOne for Enterprise, on the Configure Your Microsoft Azure Connection tab, paste the Application (client) ID value into the Client ID field.

  5. In Azure, click Add a certificate or secret and click New client secret.

    1. Enter a description and expiration for the client secret.

    You’ll need to update the client secret when it expires.

    1. Click Add to add the new client secret.

    2. Copy the Value value.

  6. In PingOne for Enterprise, paste the Client ID value into the Client Secret field.

  7. In Azure, return to the overview page.

    1. Click Endpoints to display the OAuth endpoints for your Azure tenant.

    2. Copy the URL for the OpenID Connect metadata document endpoint.

  8. In PingOne for Enterprise, while still on the Configure Your Microsoft Azure Connection panel, for Discovery Endpoint, enter the URL for the OpenID Connect metadata document endpoint you copied from your Azure tenant.

  9. Click Verify.

    PingOne for Enterprise will verify that it can query the endpoint or endpoints you’ve specified. If verification isn’t successful, check that the endpoint or endpoints appear exactly as they do on your OpenID Connect provider.

  10. For Scope, select the OAuth scopes that you’d like us to include in authentication requests, then click Next.

    The available scopes of authorization for your Azure tenant are displayed based on the response from your supplied Discovery Endpoint. The scopes indicate the access privileges you’re requesting for the access token returned by Azure. We use the access token to request additional claims from the userinfo endpoint.

  11. In Azure, close the Endpoints panel and from the clientName IdP (Test) page, click API permissions for your PingOne for Enterprise client.

    1. Check whether User.Read is already added by default.

    If it isn’t already added, you’ll add it in a subsequent step.

    1. Click Add a permission.

    2. The Request API permissions page is displayed. Select Microsoft APIs → Microsoft Graph.

    3. For What type of permissions does your application require?, select Application permissions.

    4. The list of APIs is displayed. Expand Group and select Group.Read.All.

    5. If the User.Read permission wasn’t added by default, expand User and select User.Read.

    6. On the API permissions page, click Add permissions.

    7. Click Grant admin consent for…​.

      Doing this ensures your users don’t need to grant consent during SSO.

  12. On the clientName IdP (Test) page, click Manifest.

  13. Find the groupMembershipClaims element and change it from "null" to either "SecurityGroup" or "All".

    This will ensure that the group membership claim is sent in the access token to PingOne for Enterprise during SSO.

  14. In PingOne for Enterprise, on the Microsoft Azure Provider panel, copy the displayed PingOne Redirect URI.

    The PingOne Redirect URI is the URI assigned by PingOne to which your Azure tenant sends OAuth authorization codes indicating whether or not a user was authenticated.

    To ensure security, the PingOne for Enterprise redirect URI includes a verification code unique to your account. The redirect URI used by your Azure tenant for the PingOne client must include the verification code for SSO to be successful.

  15. In Azure, go to the Overview page for your registered PingOne for Enterprise client and click the link for Redirect URIs.

    1. Add a new Redirect URI of type Web.

    2. Enter the URI you copied from the Microsoft Azure Provider panel in PingOne for Enterprise.

    3. Click Save.

  16. In PingOne for Enterprise, assign the Azure provider-to-PingOne for Enterprise attribute mapping.

    This assignment maps your selected Azure provider attributes to the default PingOne for Enterprise attributes (used by PingOne for Enterprise dock). This attribute mapping is not used by applications that you add to PingOne for Enterprise. You will configure those identity provider-to-service provider attribute mappings for each application.

    If you’re also using PingID for Azure Conditional Access, make sure the MFA_SUBJECT mapping for PingOne for Enterprise matches the username mapping for PingID.

    For more information, see Configuring PingID MFA for Microsoft Azure AD Conditional Access in the PingID documentation.

    1. For any of the attribute mappings, you can choose to configure an advanced mapping. See Creating advanced attribute mappings for instructions.

    2. Click Next when you’re finished.

  17. Choose whether or not to synchronize the user groups on your Azure provider with your PingOne user groups.

    Group synchronization relies on the Microsoft Graph API permissions you specified for the PingOne client you registered in Azure. The permissions User.Read and Group.Read.All are required for synchronization to be successful.

    Any PingOne for Enterprise user groups that do not exist in your Azure provider will be replaced by the Azure groups.

    Each of your Azure group members are automatically added to the corresponding PingOne for Enterprise groups when the user initially signs on (SSO) to PingOne for Enterprise This is PingOne for Enterprises just-in-time user provisioning.

    1. When you elect to synchronize your Azure groups with PingOne for Enterprise, a banner is displayed notifying you that synchronization is under way. In the banner is a User Groups link. Clicking this link will take you to the User Groups page where you can see the groups being added to PingOne for Enterprise

      The Azure groups are added using their Azure group IDs. After this initial synchronization, when additions or changes to your Azure groups occur, you’ll need to choose to resynchronize the groups using the Synchronize Groups button on the User Groups page. See Add groups for more information.

    2. Click Done.

Result

Your Azure identity bridge is now set up.