ASB2C custom policy integration with Ping Multiple tenants

Aravind Rajasekharan Pillai 21 Reputation points
2022-08-23T19:18:05.467+00:00

We are using ADB2C as our identity provider with the existing federation to Azure AD and Ping Identity. Here Ping Identity is owned by Third Party say Customer 1. Now we have a request to integrate to customer 2 which also uses Ping Identity. Should I set up the code block below for customer 2 after procuring the client id and secret from customer 2? I know that if it is an MS AD tenant then I can just add the tenant id in the ValidTokenIssuerPrefixes and MS will handle the organization routing. Wondering if something similar exists for Ping Identity federation as well

<ClaimsProvider>  
  <Domain>pingone.com</Domain>  
  <DisplayName>PingOne</DisplayName>  
  <TechnicalProfiles>  
    <TechnicalProfile Id="PingOne-OpenIdConnect">  
      <DisplayName>Ping Identity</DisplayName>  
      <Protocol Name="OpenIdConnect" />  
      <Metadata>  
        <Item Key="METADATA">Your PingOne OIDC discovery endpoint</Item>  
        <Item Key="client_id">Your PingOne client ID</Item>  
        <Item Key="response_types">code</Item>  
        <Item Key="scope">openid email profile</Item>  
        <Item Key="HttpBinding">POST</Item>  
        <Item Key="UsePolicyInRedirectUri">0</Item>  
      </Metadata>  
      <CryptographicKeys>  
        <Key Id="client_secret" StorageReferenceId="B2C_1A_PingOneSecret" />  
      </CryptographicKeys>  
      <OutputClaims>  
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />  
        <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />  
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />  
        <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="family_name" />  
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />  
        <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" />  
        <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" />  
      </OutputClaims>  
      <OutputClaimsTransformations>  
        <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />  
        <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />  
        <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />  
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />  
      </OutputClaimsTransformations>  
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />  
    </TechnicalProfile>  
  </TechnicalProfiles>  
</ClaimsProvider>  
Microsoft Entra External ID
Microsoft Entra External ID
A modern identity solution for securing access to customer, citizen and partner-facing apps and services. It is the converged platform of Azure AD External Identities B2B and B2C. Replaces Azure Active Directory External Identities.
2,706 questions
Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
20,102 questions
{count} votes

1 answer

Sort by: Most helpful
  1. Austin Beauchamp 76 Reputation points Microsoft Employee
    2022-08-24T19:20:06.63+00:00

    Hello Aravind,

    I was just looking over this and to explain to everyone, you're wondering if the method described in this document could be applicable to a PingOne/PingIdentity implementation: https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-azure-ad-multi-tenant?pivots=b2c-custom-policy#restrict-access.

    While I don't have as much familiarity with Ping, reviewing the documentation on the B2C side: https://learn.microsoft.com/en-us/azure/active-directory-b2c/openid-connect-technical-profile#metadata

    This indicates that this can be used to support any multi-tenant identity provider such as Azure AD. Theoretically, this would be doable with PingOne, however I would make sure you have a common Metadata endpoint that can be used across each PingOne tenant, similar to how AAD does this, and then ensure that you have the ValidTokenIssuerPrefixes enabled and pointing to the right PingOne issuer values, this could all theoretically work, however I'm not very familiar with the PingOne/PingIdentity IdP so there may be a limiting factor there.

    0 comments No comments