Microsoft Azure AD B2C   Custom Policies with Identity Experience Framework
Short introduction

Azure Active Directory (Azure AD) is a multi-tenant, cloud-based directory and identity management service.It combines core directory services, application access management, and identity protection into a single solution. Now Azure Active Directory B2C (Business to Customers) is a separate servicebuilt on the same technology but not the same in functionality as Azure AD. The main difference is that Azure AD B2C it is not to be used by single organization and its users. It allows any potential user to sign up with an email or social media provider like Facebook or Google. In this article I would like to present how to use Identity Experience Framework together with custom policieswhich are designed primarily to address complex scenarios like connecting with external service during the registration.

Structure and configuration

There is great documentation on Microsoft Docs about how to setup Azure AD B2C together with Identity Experience Framework. You can find it here . Once you add signing and encryption keys, register applications and download the starter pack with custom policies files, we can start from describing the structure of them.

Once you download custom policies files, please open “LocalAccounts” folder. You should see below files. It is very important to mention the structure of the custom policies and inheritance. Top level policy declaration is located in the “TrustFrameworkBase” file. Then “TrustFrameworkExtensions” file inherits from the previous file it means that if you declare some new claim in the “TrustFrameworkBase” file it will be accessible in the “TrustFrameworkExtensions” file. To summarize each policy can have base policy declared:

<BasePolicy>
<TenantId>yourtenant.onmicrosoft.com</TenantId>
<PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
</BasePolicy>

Try to open each file and search for “BasePolicy”. You will notice that each file has its base policy declared.

TrustFrameworkBase.xml

Contains most of the definitions. It is recommended that you make a minimum number of changes to this fileto help with troubleshooting, and long-term maintenance of the policies. In this file you can define custom claims for instance if you need to add some special information in the access token. Just right above of the “ClaimsSchema” tag you can add your additional claim definition:

<ClaimType Id="userUniqueIdentifier">
<DisplayName>userUniqueIdentifier</DisplayName>
<DataType>string</DataType>
</ClaimType> TrustFrameworkExtensions.xml

Holds the unique configuration changes for the tenant. This is the file where you can apply custom flow for the registration or login. Below is a fragment for the local account login from the original file:

<ClaimsProvider>
<DisplayName>Local Account SignIn</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="login-NonInteractive">
<Metadata><Item Key="client_id">ProxyIdentityExperienceFrameworkAppId</Item><Item Key="IdTokenAudience">IdentityExperienceFrameworkAppId</Item>
</Metadata>
<InputClaims><InputClaim ClaimTypeReferenceId="client_id" DefaultValue="ProxyIdentityExperienceFrameworkAppID" /><InputClaim ClaimTypeReferenceId="resource_id" PartnerClaimType="resource" DefaultValue="IdentityExperienceFrameworkAppID" />
</InputClaims>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider> SignUpOrSignIn.xml

Custom policy to hold the code responsible for user login or registration. Inherits from “TrustFrameworkExtensions.xml” file.

PasswordReset.xml

Custom policy to hold the code responsible for password reset definition.Inherits from “TrustFrameworkExtensions.xml” file.

ProfileEdit.xml

Custom policy to hold the code responsible for user profile edit.Inherits from “TrustFrameworkExtensions.xml” file.

Connecting external services

I mentioned ath the beginning of this article that custom policies should be applied only to complex scenarios. For instance when during the registration you have to connect to the external service and validate user data (or insert user data to the external database). Microsoft recommends to use built-in policies. You can read about them more here .

In this section I would like to present how to call external services during the registration and login process (in this case we will call Azure Function Apps).

Custom registration flow

Lets say that during the registration I would like to call Azure Function App which generates special code (GUID) and inserts this code together with user email in the Azure SQL database. In this case we have to declare new, custom claim provider. Open “TrustFrameworkExtensions.xml” file and search for “ClaimsProviders” section. Just right above closing tag of the “ClaimsProviders” add below code:

<ClaimsProvider>
<DisplayName>Generate Special Code During User Reistration</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="Users-Azure-Function-SignUp">
<DisplayName>Get user email and send it to Azure Function</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata><Item Key="ServiceUrl">https://your-function-app.azurewebsites.net/api/InsertNewUserFunction?code=FunctionCode</Item><Item Key="AuthenticationType">None</Item><Item Key="SendClaimsIn">Body</Item>
</Metadata>
<InputClaims><InputClaim ClaimTypeReferenceId="email" />
</InputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
<ValidationTechnicalProfiles><ValidationTechnicalProfile ReferenceId="Users-Azure-Function-SignUp" />
</ValidationTechnicalProfiles>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
<ClaimsProvider>

Lets discuss the code a little bit with comments:

<!-- Custom claims provider definition-->
<ClaimsProvider>
<!-- Custom claims provider description-->
<DisplayName>Generate Special Code During User Reistration</DisplayName>
<TechnicalProfiles>
<!-- Define technical profile for the custom claims provider-->
<TechnicalProfile Id="Users-Azure-Function-SignUp">
<DisplayName>Get user email and send it to Azure Function</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<!-- Here is the definition for the connection. As you can see we are connecting to the Azure Function App-->
<Metadat

本文系统(windows)相关术语:三级网络技术 计算机三级网络技术 网络技术基础 计算机网络技术

分页:12
转载请注明
本文标题:Microsoft Azure AD B2C Custom Policies with Identity Experience Framework
本站链接:https://www.codesec.net/view/628617.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 系统(windows) | 评论(0) | 阅读(135)