Skip to content

Enterprise Mobility + Security


Howdy folks,

Twitter traffic, blog post visits and overall customer interest in Azure Active Directory B2C have been huge so far, greatly exceeding our expectations! Amazingly we already have customers working with us that together represent over >1B consumer identities. And these customers are all on track to go live with the service in the next 120 days.

Given the level of demand here, I thought you might be interested in a deep dive into Azure AD B2C, our policy based architecture and our new Identity Experience Engine.

To do that, I’ve asked Kim Cameron, one of our distinguished engineers, to walk you through our architecture and how it’s unique in the market. For most of you, Kim doesn’t need an introduction. He’s been a long time thought leader in the identity industry and his Seven Laws of Identity is considered by many to be the seminal document for modern digital identity. Kim has been the key thought leader behind our B2C work and I’m excited to have him share his insights with you. You’ll find Kim’s blog post below.

And as always, we’d love to get any feedback or suggestions you have!

Best regards,

Alex Simons (Twitter: @Alex_A_Simons)

Director of Program Management

Microsoft Identity Division

————————————-

Hello,

Kim Cameron here!

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 offering, now in public preview, actually works. It will also provide insight into the capabilities of our upcoming advanced features. I think it will become evident that the combination of our existing and future 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 Azure AD scenarios besides B2C. All enterprise computing can benefit from policy-based identity and you likely already recognize that Azure AD Premium’s Conditional Access introduces these capabilities into B2E scenarios.

It is our goal to make Azure AD 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 offering solves the customer identity challenges of a wide cross section of companies solving straightforward issues.

B2C uses all the same technology as will the more advanced upcoming features.   The difference is that the existing B2C policies are 100% written by our Azure AD B2C 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.

The upcoming advanced B2C capabilities will be a superset of the existing in which you will be able to take advantage of all the other capabilities of the system that are not present in the portal. 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 the existing Azure AD B2C capabilities in light of the whole world of capabilities the upcoming features are opening up.

Thank you,

Kim Cameron (Twitter: @Kim_Cameron)

Identity Architect & Distinguished Engineer

Microsoft Identity Division