A look inside AzureAD B2C

Alex Simons asked me to write a piece for his Azure Active Directory Team Blog on our policy-based architecture and the “Identity Experience Engine” we developed to handle AzureAD’s B2C scenarios.  You can read what amounts to my first public description of our new technology at “A look inside AzureAD B2C with Kim Cameron” – reprinted here for convenience:

Last month Stuart Kwan wrote a great intro to our new Azure Active Directory B2C service and showed people how to start using it. As he explained, “Once you have a B2C tenant, you register applications and configure policies which drive the behavior of sign in, sign up, and other user experiences. Policies are the secret sauce of Azure AD B2C.” He gave step-by-step instructions and showed examples like this one of using the B2C Admin Portal to configure a policy based on social network providers: Today I’d like to build on Stuart’s introduction by explaining why we saw a customizable, policy-based approach to B2C as being essential – and what it means for the rest of our identity architecture. This will help you understand how our B2C Basic offering, now in public preview, actually works. It will also provide insight into the capabilities of our upcoming B2C Premium offering, currently in private preview with Marquee customers. I think it will become evident that the combination of our Basic and Premium products will represent a substantial step forward for the industry. It means organizations of any size can handle all their different customer relationships, grow without limitation, gain exceptional control of user experience and still dramatically reduce risk, cost, and complexity.

The Why

Readers of this blog probably already know quite a bit about enterprise identity management. So let me begin with what I think is the most important piece of information I can convey to people who are already expert: B2C does not just involve a couple of tweaks on the identity management we have learned to do for employees and devices. The underlying technical infrastructure, the developer model, the protocols and information storage concepts, continue to apply. But whole new technical capabilities are also required that make B2C, well… different.

To fully understand what’s at play we need to ask, “What are the differences between the way businesses interact digitally with their customers and the way they interact with their employees?” This isn’t the place to explore this – I’ll do so on identityblog. For now I’ll sketch the big picture as I see it.

Organizations and their employees typically have a close and ongoing relationship. Employers “know” their employees, having verified their qualifications and made them part of an enterprise team. They assign them a “corporate identity” – an account and password (and potentially a smartcard or OTP device) through which they identify themselves to corporate systems. To maximize productivity, employees typically log in once and work using their corporate identity for long periods of time. Internal identity systems have not generally been context-aware: the context has simply been that the employee is at work, doing his or her job.

Meanwhile organizations have had a completely different approach towards their customers. Relationships with customers have been driven by sales and marketing departments, not by traditional IT departments. The goal has been to eliminate friction (and clicks!) so new customers come on board – even before the enterprise knows the slightest thing about them – and then deepen the relationship and get to know the customer based on his or her specific needs and behaviors. Succeeding at this results in retention of the customer over time. Marketers in a number of industries actually see the ultimate role of customer identity being to learn how to delight their customer.

Clearly there are also cases where customers need access to their own valuable possessions and information, for example, in financial, health, insurance and government scenarios. Here customers will be willing to jump through various hoops to prove their entitlement and protect what is theirs. But far from being an exception, such high value scenarios drive home the fact that interacting with customers is all about being able to match the customer experience and related identity interaction to the specific activity a customer is engaged in rather than imposing some inflexible one-size-fits-all approach on everything.

The essential is that B2C scenarios demand, above all else, the ability to customize the customer’s identity experience to what is right for whatever they are doing.

The what

The requirement for continuous customization led us to create a technology enabling organizations to create “policies” that allow complete control over identity behaviors and experiences, and use these to drive the behavior of a flexible “identity experience engine” that handles all the issues around security, information protection, protocols, support for mobile and web devices and applications, and scalability.

Any application developer, department, enterprise, or group of enterprises can create policies. Then applications and portals can, depending on their context, invoke the identity experience engine passing the name of a policy and get precisely the behavior and information exchange they want without any muss, fuss or risk. These policies are what Stuart Kwan called “the secret sauce of Azure AD B2C”.

What behaviors of the identity experience engine do the policies control?

  • The set of html and css pages that are scrubbed for security compliance (e.g. cross-site scripting vulnerability) and then presented to users
  • User journeys – the visual experiences through which the customer progresses in a given policy
  • Identity providers (for example the social networks, ISVs, and enterprise or national IdPs that can be used to establish identity)
  • Relying parties who can use the policy
  • Authentication requirements, including multifactor orchestration
  • Integration with claims verifiers (hosted within an enterprise or provided by external partners)
  • Shared schema and mappings to participants (different systems name things differently)
  • Claims transformations and data minimization (hashing and/or transformation of attributes revealing PII into non-identifying demographic attributes)
  • Blinding and encryption
  • Claims storage
  • Web Service calls and workflow initiation
  • Protocol Conversion (SAML, OAuth2, and OpenIdConnect)

The idea of user journeys is key to the customization of customer experience and sheds light on how the system works at the protocol level. The identity experience engine operates as a pipeline and uses request/response claims exchanges to communicate with its internal components as well as with external entities.

The diagram below shows the example of a browser application or mobile application redirecting to the identity experience engine while specifying a policy that invokes a user journey. This particular journey begins with an identity selection experience – completely customized by the policy to blend into the rest of the application or portal. The customer then chooses whether to log in with an email-based “application-specific account” or with a social network. Because the journey is intended to control access to a high value resource, the customer’s phone numbers are retrieved from the customer directory and she is asked to up-level her authentication using an SMS or phone call. Then a token is issued for the application providing a number of claims retrieved from the store. Of course the policy author could have created any other journey appropriate for a given use case. There is no requirement to use MFA, consult a store, use social providers or anything else: all is flexible and extensible.

The How

It is important to understand that the identity experience engine used in B2C is an intrinsic part of Azure Active Directory, not some new service. The policy-based approach applies to many AAD scenarios besides B2C. All enterprise computing can benefit from policy-based identity and you likely already recognize that AAD Premium’s Conditional Access introduces these capabilities into B2E scenarios.

It is our goal to make AAD B2C identity management available to every organization regardless of size or complexity. We’ve been working with a host of companies in preview to make sure our B2C Basic offering solves the customer identity challenges of a wide cross section of companies solving straightforward issues.

B2C Basic uses all the same technology as will B2C Premium. The difference is that the Basic policies are 100% written by our B2C Basic Admin Portal. As Stuart explained, to author policy, you pick all the options you need to integrate a growing number of social providers and/or a customizable identity provider uniquely for your tenant. You can extend schema and select multi-factor authentication, do email verification and much more. You choose what information is released to which application. As you maneuver through the portal it writes your policy.

B2C Premium will be a superset of B2C Basic in which you will be able to take advantage of all the other capabilities of the system that are not present in the Basic portal. Premium is not yet in public preview. But I invite you to follow a set of posts I will be beginning soon on identityblog to tell you all about it and show examples of how it works.

I hope to hear from you there. Meanwhile, please take a good look at B2C Basic in light of the whole world of capabilities AAD B2C Premium is opening up.

Published by

Kim Cameron

Work on identity.