On December 2nd, we hosted the third webinar in our series on Microsoft Azure AD B2C. In this session, experts Rob Gathergood and Dave Downs looked at federation and single sign-on for Azure AD B2C. If you missed the webinar, it’s now available to view on YouTube. In this blog article, we recap the Q&A session from the day.
Throughout our webinar series, we’ve introduced Azure AD B2C, looked at customising user journeys, and have now delved into federation and single sign-on. As the series continues, we’ll take a deeper dive into API integration and user migration with Azure AD B2C, as well as focusing on larger-scale systems, multi-language, multi-region, and distributed user base.
For any questions, or if you’d like to see any specific topics covered during this webinar series or in future, don’t hesitate to contact us on info@condatis.com.
Q&A
Different Active Directories
Can I authenticate against different active directories?
Yes, and there are a couple of different ways of doing this. The first is by setting up multiple technical profiles, there’s no blocker when it comes to setting up more complicated logic and having multiple Active Directories that are redirected to. Alternatively, B2C can also be set up to do multi-tenant authentication, and from here Microsoft decides which tenant, and which directory this request should be accessing.
Both ways are possible, it just depends on the logic. Using more complicated logic, such as having email addresses going in different directions, is more applicable when accessing multiple kinds of federation that aren’t all Active Directories. If you have multiple directories you would like to talk with, it’s more likely the multi-tenanted route will be the most effective.
Social Sign-In
How can I get analytics from sign–in, for example, Google vs Facebook?
We can do it similarly to detecting that users used a social provider, federated provider, or a local account; but we can be more specific than that. We can have B2C populating claims to record which social provider the user chose, then pass that information to an external API call that writes an audit record. Alternatively, as part of doing the authentication, we can have B2C make an external API call that directly records the authentication method chosen by the user.
Either way, we end up making an API call from B2C to an external system, passing along which sign–in method was used. From here you can do what you want with that API call – determining analytical information such as sign–ins from Google, or x number of registrants from Facebook.
Ultimately, it’s about adding a claim within the policy, specifying ‘this particular sign-in method was used’, and then adding an API call within this policy to call into an external system such as Cosmos or EventHub. Our upcoming webinar in the series will dive into external systems in more detail.
Log in and Access
How can I stop one of my customers trying to sign up with a staff email address?
This is done on the client-side by setting up the policy to ensure the ability for the user to sign–in with a staff email address is disabled. Logic would also be added into the policy, so if the user bypasses this on the client-side they’re prevented from progressing further server-side.
If I federate for my staff, can they impersonate customers?
Yes, this can also be done by creating a custom policy. An impersonation custom policy can be set up which federates authentication for staff members, or ensures the user is signed in as a staff member first. From here your impersonation logic in the custom policy should be set up to do whatever you need it to do. The exact logic will be dependent on your system, what you want your relying party to do with the token that comes back, and how you need to identify that the staff member is impersonating another user. The underlying principle however is yes, there’s nothing stopping you from setting up a policy in B2C to do this.
Can I do multi-factor authentication for certain VIP users?
This can indeed be done if you have a way of identifying a user as a VIP. If there’s some information stored in the directory for example or even some information you can read using an API, this can be pulled in as part of your B2C user journey. From here, a step would be added that does the multi-factor authentication. This MFA step would be a conditional step just like any other, meaning it’s just another step in the user journey that executes when the “is VIP” condition is matched and then shows B2C’s MFA page.
Up next
To watch this webinar on federation and single sign-on, head over to our YouTube channel. Our next webinar in the series takes place on Wednesday 13th January, in which our specialists delve into API integration and user migration using Azure AD B2C.
We still have two webinars to go in our series on Azure AD B2C, and we’ll continue to provide attendees with a comprehensive look into the power of Azure AD B2C, and its many capabilities.