Azure B2C - Identity Experience Framework

Azure B2C – why do I need that?

Have you heard about Azure B2C? Yes? What about Azure B2C Identity Experience Framework? This is something I've had pleasure to play with a little bit, it is still in Preview but has a lot of benefits when you want to manage customer entities outside of your organization. Actually there’s a nice 'know-how' guide that I would recommend on reading available here. I was thinking whether I should start right of the bat with some custom scenarios but even now Identity Experience Framework still lacks detailed documentation so this time I'll to go high-level over the possibilities and structure of this platform. So...

Identity Experience Framework 

I assume you already know what B2C is used for and have some experience with built-in policies so I'll move right to the IEF part.

Identity Experience Framework is Azure based orchestration platform to manage trust between entities using standard protocols like OAuth, SAML, OpenID, it is being configured using policy files starting from schema definitions with custom authorization at the end.

Policy files

Identity Experience Framework is based on custom policy files. Those XML files are used to define the User Journey (the so-called user flows), required schema, validations and related process.  Basically we can treat those as extended built-in policies, where we have the control and are able to add any additional steps to any flow. We can also define totally customized flows like allowing users to sign in using the invitation policy or use policy to link local and social account.
When talking about policies we should have 3 types of files in our minds

1. Base – this one contains all basic information, starting from schema, technical profiles as well as defining user journeys, recommended not to be changed as it quickly becomes really heavy and hard to maintain
2. Extension - This one usually contains our tenant specific configuration, like tenant id, application ids., custom claims etc.
3. Relying Party (RP) - This defines the endpoint policy that will be used to execute the flow, it defines the final schema of the JWT payload, it is used to add Application Insights to the given flow, defines single sign-on behaviour, session time etc.,

Above image is pretty much similar to one that is on the recommended ms doc but there were few things that I found missing.
First of all the extends flow of the policy files.
In each policy file we define which policy we would like to extend (except base one)

<BasePolicy> <TenantId>b2cdevlab0.onmicrosoft.com</TenantId> <PolicyId>b2c_1a_ext</PolicyId> </BasePolicy>

With this we can modify existing attributes inside our configuration as well as add new (if those were not there before). I find this useful as I can modify my ClaimsProvider TechnicalProfile and add additional metadata, extend set of attributes that is being extracted from the AD etc.,

Second thing I find missing would be the basic parameters set that is being send to the login.onmicrosoft.com page during the invoke policy process and those would be the:

• application id (that has been registered in Azure B2C with the list of valid reply URLs)
• tenant id  - id of the Azure B2C tenant
• reply URL - where user should be redirected after finishing the round trip
• policy name - flow which we would like to execute

Policy structure

TrustFrameworkPolicy XML node has a couple of different main nodes that are being used for the Azure B2C user flow configuration. I would highly advise to use .xsd schema when trying to add new values as there's no designer tool allowing to generate policy files. Schema can be found almost in every github repository related to azure b2c policies, for example it can be found [here].

As the Azure B2C Identity Experience Framework lacks documentation I want to go through main blocks available inside the policies.

1. BuildingBlocks
1. ClaimsSchema - this node has a set of attributes as well as variables that will be used within our policy. When operating with ReadUserProfile kind of technical profile claim types names have to match our Azure B2C attributes. If you are not sure of the name you can always use the Graph API to query about user. 
2. ClaimsTransformations - this defines a set of useful operations that can be used to create values, for example string concatenation
3. ClientDefinitions - there's not much of documentation on this matter. The element defines properties specific to end-user device for which the policy is being executed. This XML node is being considered deprecated and can be ommited (but it is part of every sample scenario).
4. ContentDefinitions - this defines our look and feel, we can create our own html files with proper branding. See this to see it in action
5. Localization - we can localize our html page, we can define available languages and based on the user browser settings he will receive a localized content
2. ClaimsProviders- this one is the most complex as it defines the CRUD operations with the Azure AD B2C, integrations with 3-rd party auth providers (FB, G+, Federated Accounts etc.) custom REST API requests
3. UserJourneys - each user journey defines the flow that user will experience when executing given policy
4. BasePolicy - this one is used in either extension or replyingParty type of file, it defines which file we want to extend
5. RelyingParty - used in relyingParty xml file to define which user journey is should be executed as well as defines journey behaviour (single sign on, logging etc.), as well as the output JWT properties

Now that we have the basics I'll start describing different scenarios I've encountered that might help others when trying to use the Azure B2C Identity Experience Framework.