Use Cases

Configuring medium-grained application access control through Azure AD, PingFederate, and PingAccess

PingAccess can interact directly with an OIDC IdP provider, so you don’t need to use PingFederate to authenticate against Azure AD.

However, when you add PingFederate to the equation, you gain additional features such as session management, data transformation from Azure AD before it gets sent to PingAccess, and local datastore lookups for additional information outside of Azure AD.

Components

  • PingFederate 8.3

  • PingAccess 4.2

  • Microsoft® Azure Active Directory (Azure AD)

This use case was developed with the specified product versions. With more recent product versions, the general workflow should apply although specific menu options and screens might differ.

Before you begin

  • Make sure that the components are installed and running.

  • For Azure AD, ensure that you have a verified domain name and at least one user and one group for testing.

Setting up Azure AD as an OIDC provider in PingFederate

Steps

  1. Access your Azure AD OIDC discovery document and record the Issuer value from the /.well-known/openid-configuration endpoint.

    Example:

    For example, if the Azure AD verified domain is “myglobalco.org”, the URL is: https://login.microsoftonline.com/myglobalco.org/v2.0/.well-known/openid-configuration.

  2. Log in to PingFederate as an administrator, and create an SP configuration for Azure AD using the Issuer value from the previous step as explained in Create an OpenID Connect IdP connection.

  3. Open a new tab and log in as Azure AD administrator to https://apps.dev.microsoft.com/#/appList.

  4. Add a new app that has a friendly and descriptive name to show on the Azure AD login screen for your application.

  5. Obtain an Application ID and Application Secret from Azure AD, and record them.

  6. In your PingFederate IdP Connection tab, add the Azure Application ID in the Client ID field and the Azure Application Secret in the Client Secret field. See Create an OpenID Connect IdP connection.

  7. To verify browser SSO settings, click Configure Browser SSO.

  8. In the Activation and Summary screen, change your connection status to Active, record the redirect URI, and click Save.

    To aid initial testing, record the SSO application endpoint.

  9. In the Azure AD administrator app list configuration, select your application from PingFederate, click Add Platform, select type Web, and paste your redirect URI.

  10. Change any other MS Graph Permissions, logo, Terms of Service or Privacy Statement options that you need to change, and click Save.

    To obtain group information, choose Advanced Options → Application Manifest and change “groupMembershipClaims” to “All”.

  11. To verify that your OIDC IdP connection is working, go to your SSO Application endpoint from PingFederate.

    You should be redirected to login with your Azure AD credentials, and you should be SSO’d into your SP adapter if one is configured.

Setting up Azure AD as an OIDC provider for PingAccess in PingFederate

About this task

This procedure assumes that you have configured PingFederate and PingAccess to talk to each other through OIDC. You need to add Azure AD as an authentication source for PingAccess in PingFederate.

For general instructions, see Create an OpenID Connect IdP connection

Steps

  1. From the Authentication Selector screen in PingFederate, select the Add or Update AuthN Context Attributebox next to the PingAccess entry, update your selector result values to include Azure AD as an authentication requirement, and click Save. See Configure the Requested AuthN Context Authentication Selector.

  2. Ensure there is a path in your authentication policy tree to include your new authentication requirement for Azure, verify that you are fulfilling your policy contracts, and click Save. See Defining authentication policies and Define authentication policies based on group membership information.

  3. Under Authorization Server Settings, extend the persistent grant to map the Azure AD group into the OIDC token to PingAccess. See Define grant contract fulfillment for IdP adapter mapping.

  4. Extend the access token attribute contract to include groups, fulfill the persistent grants from the authentication policy contract, and fulfill the access token mapping with the persistent grant. See Configure policy and ID token settings.

  5. In your OIDC policy, map from the access token or perform any additional lookups against local data stores. See Configure IdP adapter attribute sources and user lookup.

  6. Go to PingAccess and write a web session attribute rule for the group membership to which the rule applies. See Configure session management.

    Azure AD does not provide friendly names for their groups and instead returns them as object IDs.

    Apply this rule as needed for your specific use case, application, or API.

    Result:

    PingAccess verifies group membership in Azure AD and uses this group membership to enforce medium-grained access control.