---
title: Configuring medium-grained application access control through Azure AD, PingFederate, and PingAccess
description: PingAccess can interact directly with an OIDC IdP provider, so you don't need to use PingFederate to authenticate against Azure AD.
component: solution-guides
page_id: solution-guides:data_and_application_security_use_cases:htg_config_med_grained_app
canonical_url: https://docs.pingidentity.com/solution-guides/data_and_application_security_use_cases/htg_config_med_grained_app.html
revdate: July 18, 2022
section_ids:
  components: Components
  before-you-begin: Before you begin
  setting-up-azure-ad-as-an-oidc-provider-in-pingfederate: Setting up Azure AD as an OIDC provider in PingFederate
  steps: Steps
  example: Example:
  setting-up-azure-ad-as-an-oidc-provider-for-pingaccess-in-pingfederate: Setting up Azure AD as an OIDC provider for PingAccess in PingFederate
  about-this-task: About this task
  steps-2: Steps
  result: Result:
---

# 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](https://cdn-docs.pingidentity.com/archive/pdf/pingfederate/pingfederate-91.pdf#page=460).

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](https://cdn-docs.pingidentity.com/archive/pdf/pingfederate/pingfederate-91.pdf#page=460).

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](https://cdn-docs.pingidentity.com/archive/pdf/pingfederate/pingfederate-91.pdf#page=460)

### Steps

1. From the Authentication Selector screen in PingFederate, select the **Add or Update AuthN Context Attribute**box 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](https://cdn-docs.pingidentity.com/archive/pdf/pingfederate/pingfederate-91.pdf#page=61).

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](https://cdn-docs.pingidentity.com/archive/pdf/pingfederate/pingfederate-91.pdf#page=233) and [Define authentication policies based on group membership information](https://cdn-docs.pingidentity.com/archive/pdf/pingfederate/pingfederate-91.pdf#page=237).

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](https://cdn-docs.pingidentity.com/archive/pdf/pingfederate/pingfederate-91.pdf#page=286).

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](https://cdn-docs.pingidentity.com/archive/pdf/pingfederate/pingfederate-91.pdf#page=316).

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](https://cdn-docs.pingidentity.com/archive/pdf/pingfederate/pingfederate-91.pdf#page=227).

6. Go to PingAccess and write a web session attribute rule for the group membership to which the rule applies. See [Configure session management](https://cdn-docs.pingidentity.com/archive/pdf/pingaccess/pingaccess-72.pdf#page=121).

   |   |                                                                                                   |
   | - | ------------------------------------------------------------------------------------------------- |
   |   | 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.
