Product
Hosting Environment
Operating System
Capability
Task Type
Draft Beta
Close

Ping Identity Use Cases

Updated 14

Add to MyDocs | Hide Show Table of Contents

Table of Contents

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

Published: January 25, 2019

Components

  • PingFederate 8.3 (or later)

  • PingAccess 4.2 (or later)

  • Microsoft® Azure Active Directory (Azure AD)

Note: Because PingAccess has capabilities to interact directly with an OIDC IdP Provider, you do not need PingFederate to authenticate against Azure AD. However, when you add PingFederate to the equation, you gain additonal 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.

Before you begin

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

Follow these steps to set up Azure AD as an OIDC Provider to PingAccess to provide medium-grained access control to a header-based application behind PingAccess.

Brief workflow explained in more detail in text.
  1. Set up Azure AD as an OIDC Provider in PingFederate.
    1. Access your Azure AD OIDC discovery document and record the Issuer value from the /.well-known/openid-configuration endpoint.
      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.
      Tip: Obtain an Application ID and Application Secret, and record them.
    5. 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.
    6. To verify browser SSO settings, click Configure Browser SSO. Browser SSO settings should be mapped out. You might want to change the Overrides, map it to an actual SP adapter, or put a placeholder OpenToken adapter if you are not using any SP adapters.
    7. In the Activation and Summary screen, change your Connection Status to Active, record the Redirect URI, and click Save.
      Tip: To aid initial testing, also record the SSO Application Endpoint.
    8. In the Azure AD administrator app list configuration, select your Application from PingFederate, click on Add Platform, select type Web, and paste your redirect URI.
    9. Change any other MS Graph Permissions, logo, Terms of Service or Privacy Statement options that you need to change, and click Save.
      Tip: To grab group information, you will need to edit Application Manifest under Advanced Options to change “groupMembershipClaims” to “All”. You could also set this to “SecurityGroups” but all will give you all the user group memberships beyond Security Groups from Azure AD.
    10. 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.
  2. Set up Azure AD as an OIDC Provider for PingAccess in PingFederate. For general instructions, see Create an OpenID Connect IdP connection in the PingFederate documentation.
    Note: This step assumes that you already configued PingFederate and PingAccess to talk to each other through OIDC. You need to add Azure AD as an authentication source for PingAccess in PingFederate.
    1. From the Authentication Selector screen in PingFederate, click the box to Add or Update AuthN Context Attribute 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 in the PingFederate documentation.See Configure the Requested AuthN Context Authentication Selector in the PingFederate documentation.
    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 Define authentication policies and Define authentication policies based on group membership information in the PingFederate documentation.
    3. Extend the persistent grant to map the Azure AD group into the OIDC token to PingAccess under Authorization Server Settings. See Define grant contract fulfillment for IdP adapter mapping in the PingFederate documentation.
    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 in the PingFederate documentation.
    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 in the PingFederate documentation.
    6. Go to PingAccess and write a Web Session Attribute rule for the group membership to which the rule applies. See Configure session management in the PingAccess documentation.
      Note: Azure AD does not provide friendly names for their groups and instead returns them as object IDs.
      Apply this rule/policy as you wish to your specific use case or application/API.
      PingAccess verifies group membership in Azure AD and uses this group membership to enforce medium-grained access control.