Following on from our introductory webinar on Microsoft Azure AD B2C, our second one went into detail on customising user journeys and integrating different sites with B2C using OpenID Connect and SAML2. The webinar included expert insight, demonstrations of B2C’s capabilities, and a Q&A session to close.
As the series continues, we’ll cover topics like federation and single sign-on, API integration, user migration, and more! This blog is a recap of our second webinar, and if you have any questions for our presenters David Manning, and Dave Downs, don’t hesitate to get in touch.
Webinar content
Initial custom policy
In this session we set up B2C custom policies allowing a user to register for an application and sign in to that application, including verifying the user’s email address using a one-time passcode, validating the details the user entered, and capturing custom information such as where the user heard about the service.
We showed a breakdown of how the relying party application is defined in a custom policy, how user journeys are structured, and what goes into writing the components that the user journey executes to register and authenticate a user.
Custom branding
We demonstrated how the default B2C branding templates are set up, how policy authors can host their own custom branding templates, and how custom policies can be used to override the defaults, styling B2C pages using a company’s own branding.
Integration with an OpenID Connect relying party
We went through the configuration of a B2C tenant, including uploading custom policies, where signing keys are configured, and how an application can be registered with B2C allowing that app to make use of B2C policies for authentication using OpenID Connect.
Integration with a SAML2 relying party
Finally, we demonstrated how to add additional custom policies to enable authentication from a SAML2 relying party, how the configuration of that application compares to an OpenID Connect application, and how to make use of single-sign-on to provide a seamless authentication experience for users of multiple services.
Q&A
Can we use variants of branding for different apps or areas of the same site?
The way B2C does branding through content definitions is very flexible.
Parameters can be passed as part of the to the request for a HTML template and, based on those parameters, the site serving the HTML can return custom templates. B2C supports providing those parameters either for all template requests in a user journey or for individual template requests as needed.
Because the templates are loaded based on content definitions in B2C – content definitions just being a section of the policy that defines the URLs used to load templates – and each page in B2C defines which content definition it uses, individual pages can load different templates depending on their requirements.
As all of this is defined in the B2C custom policies, and because the custom policies are hierarchical, all that configuration can be overridden for different journeys, different steps in a journey, or different relying parties as needed.
Overall, this shows there is quite a lot of flexibility when it comes to branding.
Can deployment be automated using technology like Azure DevOps?
There are some parts which aren’t yet automatable, such as the creation of the B2C tenant. Still, things like the deployment of policies are fully automatable, and we do that ourselves on projects using Azure DevOps.
This typically includes writing custom policies as a set of templates and then replacing variables within those templates as we deploy to different environments, through a standard Azure DevOps pipeline.