Create Customized Insurance policies For Azure Lively Listing B2C

Introduction

In some instances, we have to enable customers from a selected group in Azure AD B2C flows. Azure B2C offers 2 sorts of flows. Consumer flows and Customized Insurance policies. Customized insurance policies are used to deal with complicated enterprise situations in B2C.

This text demonstrates easy methods to configure particular Azure Lively Listing organizational person to Azure AD B2C.

Prerequisite

1. Configure customized insurance policies in Azure AD B2C from Native And Social Account with MFA
2. B2C Customized Coverage
3. Register an internet software

Studying Targets

1. Register Azure AD Utility
2. Configuring non-obligatory claims
3. Create coverage key in Azure AD B2C
4. Configure Azure AD as an identification supplier
5. Add a person journey and Add Identification supplier
6. Configure the relying occasion coverage
7. Add customized coverage
8. Check customized coverage

Let’s get began. Earlier than we transfer ahead, Please affirm that you’ve got registered Identification framework and proxy identification framework functions, created coverage keys, and uploaded customized insurance policies in Azure AD B2C tenant. If it isn’t carried out then comply with conditions part first and are available again once more.  

Register Azure AD Utility

1. Sign up to Azure Portal
2. Choose App registration
3. Click on on new registration
4. Enter title of the applying “Azure AD B2C App”
5. Settle for the default choice of supported account varieties for this software
6. Choose net for redirect URI, enter the next URL in all decrease case letters.
   https:// <B2C-tenant-name>.b2clogin.com/<B2C-tenant-name>.onmicrosoft.com/oauth2/authresp
   Exchange “B2C-tenant-name” with the title of your azure advert B2C tenant.
7. Click on on register and duplicate software ID which we might be utilizing it in a later step.
8. Generate new secret from Certificates and secret and duplicate it.

Configuring non-obligatory claims in Azure AD

If B2C requires claims from Azure AD tenant, it’s a must to configure claims in your software.

1. Go to your software which we have now registered earlier.
2. Click on on token configurations below the handle part
3. Add non-obligatory claims
4. Choose Token kind, ID
5. Choose non-obligatory claims so as to add family_name and given_name
6. Choose add.

Create coverage key in Azure AD B2C

We should retailer software secret key to Azure AD Coverage key part. This key might be utilizing in customized B2C coverage.

1. Login to Azure AD B2C tenant
2. Click on on Identification Expertise Framework below insurance policies
3. Click on on insurance policies below handle
4. Click on on add
   1. Choose guide in choices
   2. Enter title of the coverage
   3. Enter secret key which we have now copied whereas registering software in Azure AD
   4. Choose signature for key utilization
   5. Click on on create

Configure Azure AD as an identification supplier

It’s essential to configure Azure Advert as a declare supplier in order that Azure Advert B2C could work together over an endpoint to be able to enable customers to register utilizing Group Accounts.The endpoint presents a set of claims which can be utilised by Azure Advert B2C to substantiate {that a} explicit person has efficiently authenticated.

1. Open the TrustFrameworkExtensions.xml file.
2. Seek for ClaimsProvider factor. If doesn’t exist, add it below the foundation factor.
3. Add new ClaimsProvider

<ClaimsProvider>
  <Area>Contoso</Area>
  <DisplayName>Login utilizing Azure AD</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="AzureAD-OpenIdConnect">
      <DisplayName>Contoso Worker</DisplayName>
      <Description>Login together with your Contoso account</Description>
      <Protocol Identify="OpenIdConnect"/>
      <Metadata>
        <Merchandise Key="METADATA">https://login.microsoftonline.com/AzureADTenant.onmicrosoft.com/v2.0/.well-known/openid-configuration</Merchandise>
        <Merchandise Key="client_id">11111111-1111-1111-1111-111111111111</Merchandise>
        <Merchandise Key="response_types">code</Merchandise>
        <Merchandise Key="scope">openid profile</Merchandise>
        <Merchandise Key="response_mode">form_post</Merchandise>
        <Merchandise Key="HttpBinding">POST</Merchandise>
        <Merchandise Key="UsePolicyInRedirectUri">false</Merchandise>
      </Metadata>
      <CryptographicKeys>
        <Key Id="client_secret" StorageReferenceId="B2C_1A_ContosoAppSecret"/>
      </CryptographicKeys>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="oid"/>
        <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid"/>
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
        <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="title" />
        <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" />
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName"/>
        <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName"/>
        <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId"/>
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId"/>
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin"/>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

• Exchange “AzureADTenant” together with your Azure Lively Listing Tenant Identify
• Repalce “11111111-1111-1111-1111-111111111111” with Utility ID which we have now copied earlier.
• Exchange “B2C_1A_ContosoAppSecret” with Coverage title which is configured in azure advert b2c

Add person journey

Identification Supplier has been configured at this stage, however it isn’t accessible in any customized flows in B2C. Create a replica person journey from an current one.

1. Open a TrustFrameworkExtensions.xml file
2. Seek for UserJourneys
3. Paste under code inside UserJourneys

<UserJourney Id="CustomSignUpSignIn">
  <OrchestrationSteps>

    <OrchestrationStep Order="1" Kind="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
      <ClaimsProviderSelections>
        <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
        <ClaimsProviderSelection TargetClaimsExchangeId="AzureADContosoExchange" />
      </ClaimsProviderSelections>
      <ClaimsExchanges>
        <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-E mail" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- Verify if the person has chosen to register utilizing one of many social suppliers -->
    <OrchestrationStep Order="2" Kind="ClaimsExchange">
      <Preconditions>
        <Precondition Kind="ClaimsExist" ExecuteActionsIf="true">
          <Worth>objectId</Worth>
          <Motion>SkipThisOrchestrationStep</Motion>
        </Precondition>
      </Preconditions>
      <ClaimsExchanges>
        <ClaimsExchange Id="AzureADContosoExchange" TechnicalProfileReferenceId="AADRCDemo-OpenIdConnect" />
        <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- For social IDP authentication, try to search out the person account within the listing. -->
    <OrchestrationStep Order="3" Kind="ClaimsExchange">
      <Preconditions>
        <Precondition Kind="ClaimEquals" ExecuteActionsIf="true">
          <Worth>authenticationSource</Worth>
          <Worth>localAccountAuthentication</Worth>
          <Motion>SkipThisOrchestrationStep</Motion>
        </Precondition>
      </Preconditions>
      <ClaimsExchanges>
        <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- Present self-asserted web page provided that the listing doesn't have the person account already (i.e. we should not have an objectId). 
      This may solely occur when authentication occurred utilizing a social IDP. If native account was created or authentication carried out
      utilizing ESTS in step 2, then an person account should exist within the listing by this time. -->
    <OrchestrationStep Order="4" Kind="ClaimsExchange">
      <Preconditions>
        <Precondition Kind="ClaimsExist" ExecuteActionsIf="true">
          <Worth>objectId</Worth>
          <Motion>SkipThisOrchestrationStep</Motion>
        </Precondition>
      </Preconditions>
      <ClaimsExchanges>
        <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- This step reads any person attributes that we could not have obtained when authenticating utilizing ESTS to allow them to be despatched 
      within the token. -->
    <OrchestrationStep Order="5" Kind="ClaimsExchange">
      <Preconditions>
        <Precondition Kind="ClaimEquals" ExecuteActionsIf="true">
          <Worth>authenticationSource</Worth>
          <Worth>socialIdpAuthentication</Worth>
          <Motion>SkipThisOrchestrationStep</Motion>
        </Precondition>
      </Preconditions>
      <ClaimsExchanges>
        <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
      </ClaimsExchanges>
    </OrchestrationStep>
    <!-- The earlier step (SelfAsserted-Social) might have been skipped if there have been no attributes to gather 
         from the person. So, in that case, create the person within the listing if one doesn't exist already 
         (verified utilizing objectId which might be set from the final step if account was created within the listing. -->
    <OrchestrationStep Order="6" Kind="ClaimsExchange">
      <Preconditions>
        <Precondition Kind="ClaimsExist" ExecuteActionsIf="true">
          <Worth>objectId</Worth>
          <Motion>SkipThisOrchestrationStep</Motion>
        </Precondition>
      </Preconditions>
      <ClaimsExchanges>
        <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- Telephone verification: If MFA is just not required, the subsequent three steps (#5-#7) needs to be eliminated.
         This step checks whether or not there is a cellphone quantity on document,  for the person. If discovered, then the person is challenged to confirm it. -->
    <OrchestrationStep Order="7" Kind="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="PhoneFactor-Confirm" TechnicalProfileReferenceId="PhoneFactor-InputOrVerify" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- Save MFA cellphone quantity: The precondition verifies whether or not the person offered a brand new quantity within the 
         earlier step. In that case, then the cellphone quantity is saved within the listing for future authentication 
         requests. -->
    <OrchestrationStep Order="8" Kind="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="AADUserWriteWithObjectId" TechnicalProfileReferenceId="AAD-UserWritePhoneNumberUsingObjectId" />
      </ClaimsExchanges>
    </OrchestrationStep>
    <OrchestrationStep Order="9" Kind="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />

  </OrchestrationSteps>
  <ClientDefinition ReferenceId="DefaultWeb" />
</UserJourney>

Configure the relying occasion Coverage

1. Open current “SignUpOrSignin.xml”
2. Exchange under code with <RelyingParty> node.

<RelyingParty>
  <DefaultUserJourney ReferenceId="CustomSignUpSignIn" />
  <Endpoints>
    <!--points to refresh token journey when app makes refresh token request-->
    <Endpoint Id="Token" UserJourneyReferenceId="RedeemRefreshToken" />
  </Endpoints>
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Identify="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      <OutputClaim ClaimTypeReferenceId="surname" />
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
      <OutputClaim ClaimTypeReferenceId="identityProvider" />
      <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Coverage:TenantObjectId}" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

Enter customized person journey ID which we have now created in DefaultUserJourney node. 

Add customized coverage

1. Add under customized insurance policies to Azure AD B2C tenant
   1. TrustFrameworkExtensions.xml
   2. SignUpOrSignin.xml

To check this software

1. Open Azure AD B2C Tenant
2. Click on on Identification expertise framework below insurance policies
3. Choose “B2C_1A_SIGNUP_SIGNIN” coverage
4. Choose Utility the place redirect URI is https://jwt.ms
5. Click on on run now.

Conclusion

We now have realized easy methods to create a customized coverage to attach Azure AD person in Azure AD B2C Stream.

Let me know in feedback if anybody has discovered any subject in provision. I’m comfortable that can assist you.