The following will dive into the underlying components of Azure AD B2C, these components are referred to as Technical Profiles which drive the functionality of your Azure AD B2C policy. All interactions with partners to perform claims exchanges are completed via technical profiles.
You can think of Technical Profiles like functions. They can:
- Send claims to the partner - "input claims"
- Execute a procedure - E.g. Render a page to collect information from the user
- Return claims to Azure AD B2C – "output claims"
Technical profiles provide a framework with a built-in mechanism to communicate with known Azure AD B2C components, REST APIs and Identity Providers via open standard protocols.
There are various types of technical profile:
- Identity Provider - Denoted by the Protocol of the Identity Provider (OAuth1, OAuth2, OpenID Connect, SAML and Ws-Fed)
- REST API - Allows interfacing with an external API
- Self-Asserted - Allows presenting a page to the user
- Azure MFA - Allows presenting the Azure MFA screen to a user.
- Azure Active Directory - Allows Read/Write operations against the directory
- Application Insights - Allows sending custom events to an App Insights instance.
- Token Issuer - Allows issuing a token after authentication completes.
All types of technical profiles share the same concept as per the following diagram.
Input claims transformation - Before a claim is provided to this Technical Profile, the claim can be manipulated via a claims transform. For example, concatenate two claims and provide it as an input claim to this technical profile.
Input claims - Claims that are provided as inputs to the type of Technical Profile being executed. Since each type of Technical Profile provides its own built in functionality, these input claims can act differently.
- Self Asserted - Pre-populate fields that are displayed on the screen.
- REST API - Act as claims to be sent as a JSON key value pair to the API endpoint.
- Identity Provider (OpenId) - Additional query parameters as part of the authentication request.
- Azure MFA - Pre-populate the phone number for an prior enrolled user.
- Azure Active Directory - To lookup the user in the directory.
Technical profile execution - As each Technical Profile has a type, the execution is dependant on that.
- Self Asserted - Display a page for the user to interact with. The user can provide information, or edit information about their profile.
- REST API - Ability to call a REST API endpoint to exchange claims.
- Identity Provider - Ability to redirect the user to an external Identity Provider.
- Azure MFA - Provides the user a page to perform Azure MFA.
- Azure Active Directory - Allows Azure AD B2C policy to read or write to the directory.
Validation technical profile - When a user provides data via a Self-Asserted technical profile, this information may need to be validated. A common example is to have the user provide a loyalty number, which is then validated at an external system to determine if it is valid.
A Self-Asserted technical profile can therefore call another Technical Profile, or multiple consecutively, which provide the means to validate the information.
This will either allow the user to continue or prevent any further execution if an error is thrown. In the case where the user can continue, the validation technical profile can output claims and add them to the claims bag for any subsequent validation technical profiles to run as part of the this Self-Asserted technical profile.
Claims that a Validation technical profile shared (output) with the Self-Asserted technical profile are not automatically available for subsequent steps in the Azure AD B2C policy to use, unless those claims are output within the Self-Asserted technical profile itself.
In the example of validating a loyalty number, the Validation technical profile can reference a REST API technical profile to have the loyalty number validated at an external system.
Output claims - Claims to return back to the claims bag. Depending on the technical profile type, the output claims behave differently, however all types of Technical Profile will return the output claim into the claims bag.
- Self Asserted - Will display the fields to the user, unless satisfied by a Validation technical profile.
- REST API - The expected JSON key value pairs from the APIs response.
- Identity Provider - The expected JSON key value pairs from the JWT received.
- Azure MFA - The ability to confirm the SMS/Phone Number completed MFA.
- Azure Active Directory - Issues claims after reading or writing to a user into the claims bag.
You can use these claims as input claims into subsequent orchestration steps, create conditional logic around the journey execution, or manipulate them via output claims transformations as part of this technical profile.
Output claims transformations - A technical profile may contain a list of output claims transformations to be executed to manipulate the claims before sending them to the claims bag.
As an example, take the first name and last name and use an output claims transformation to concatenate these values into a new single claim value. Subsequent steps will then be able to have access to the concatenated string.
- Session management - A technical profile can contain a reference to a session management technical profile that is responsible to manage whether the user will skip a step in the policy when experiencing single sign on.
Validation technical profile
As mentioned above, a Self-Asserted technical profile may define one or more validation technical profiles to be used for validating some or all of its output claims.
A validation technical profile is an ordinary technical profile from any type(protocol), such as Azure Active Directory or a REST API. The Validation technical profile returns output claims or returns an HTTP error message.
The most common use of a Validation technical profile is to validate the username and password the user provides during Sign-In.
Another example during Sign-up, before allowing a user to create their account, Azure AD B2C must check if the account already exists.
Therefore, once the user enters their information through a Self-Asserted technical profile, it must validate the email does not already exist in the directory.
To achieve this, the Self-Asserted technical profile calls a Validation Technical profile which searches the directory for the users email. An Azure Active Directory technical profile type is used, which is configured to throw an error if the user exists, or otherwise continue silently.
You can further augment this process to call another Validation technical profile of type REST API. This could validate any other information the user provided during sign up, for example their ID Number.
Integration with line of business applications
You can use REST API technical profile to:
- Validate user input data - This action prevents invalid data from being persisted into Azure AD B2C claims bag. If the value from the user is not valid, your RESTful service should return an error message that instructs the user to provide a valid entry. For example, you can verify that the email address provided by the user exists in your CRM platform.
- Overwrite input claims - For example, if a user enters the first name in all lowercase or all uppercase letters, you can format the name with only the first letter capitalized.
- Enrich user data by further integrating with corporate line-of-business services - Your RESTful service can receive the user's email address, query the CRM platform, and return the user's loyalty number to Azure AD B2C. The return claims can be stored in the user's Azure AD account, evaluated in the next Orchestration Steps, included in the id token or a combination.
- Run custom business logic - You can send push notifications, update corporate databases, run a user migration process, manage permissions, audit databases, and perform other actions.