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.

Azure Active Directory B2C is now in public preview

For the last several years I’ve been working on a new technology and capability that we are calling “Azure Active Directory B2C.”   I’m delighted that I’m finally able to tell you about it, and share the ideas behind it.

For me it is the next step in the journey to give individual consumers, enterprises and governments the identity systems they need in this period of continuously more digital interaction and increasing threats to our security and privacy.

I don’t normally put official Microsoft content on these pages, but given how important the B2C initiative is, how closely I’ve been involved, and how well it has been received, I think it makes sense to show you Microsoft’s announcement about “B2C Basic”.  It appeared on the Azure Active Directory Blog.  Stuart Kwan does a great job of introducing you to the product.

I hope you’ll take a look at his introduction.  I’ll be posting a number of pieces which expand on it – exploring issues we faced, giving you the background on the thinking behind the architecture and implementation, and telling you about the “B2C Premium” offering that is coming soon. I think the combination of Basic’s accessibility and Premium’s feature completeness really offers a new paradigm and amazing opportunities for everyone.

Introducing Microsoft Azure Active Directory B2C

By Stuart Kwan

With Azure Active Directory B2C we’re extending Azure AD to address consumer identity management for YOUR applications:

  • Essential identity management for web, PC, and mobile apps: Support sign in to your application using popular social networks like Facebook or Google, or create accounts with usernames and passwords specifically for your application. Self-service password management and profile management are provided out of the box. Phone-based multi-factor authentication enables an extra measure of protection.
  • Highly customizable and under your control: Sign up and sign in experiences are in the critical path of the most important activities in your applications. B2C gives you a high degree of control over the look and feel of these experiences, while at the same time reducing the attack surface area of your application – you never have to handle a user’s password. Microsoft is completely under the covers and not visible to your end users. Your user data belongs to you, not Microsoft, and is under your control.
  • Proven scalability and availability: Whether you have hundreds of users or hundreds of millions of users, B2C is designed to handle your load, anywhere in the world. Azure AD is deployed in more than two dozen datacenters, and services hundreds of millions of users with billions of authentications per day. Our engineers monitor the service 24/7.
  • Unique user protection features: Microsoft invests deeply in protection technology for our users. We have teams of domain experts that track the threat landscape. We’re constantly monitoring sign up and sign in activity to identify attacks and adapt our protection mechanisms. With B2C we’ll apply these anomaly, anti-fraud, and account compromise detection systems to your users.
  • Pay as you go: Azure Active Directory is a global service benefiting from tremendous economies of scale, allowing us to pass these savings along to you. We offer the B2C service on a consumption basis – you only pay for the resources that you use. Developers can take advantage of the free tier of the service when building their application.

B2C uses the same familiar programming model of Azure Active Directory. You can quickly and easily connect your application to B2C using industry standards OAuth 2.0 and OpenID Connect for authentication, and OData v3 for user management via our Graph API. Web app, web API, mobile and PC app scenarios are fully supported. The same open source libraries that are used with Azure Active Directory can be used with B2C to accelerate development.

If you want, you can get started right now! The rest of this post takes a look at how B2C works in detail.

How it works

The best way to describe B2C is to see it in action. Let’s look at an example. Our heroes, Proseware, have a consumer-facing web site. The site uses B2C for identity management. In this case that means sign in, and user self-service sign up, profile management, and password reset. Here’s the Proseware homepage:

A new user would click sign up to create a new account. They have the choice of creating an account using Google, Facebook, or by creating a Proseware account:

One quick note. The Microsoft button doesn’t work yet, but it will soon. It isn’t available at the start of the preview as we have more work to do in our converged programming model before we enable this.

What’s a Proseware account? As it turns out, there are many people out there who don’t always want to use a social account to sign in. You probably have your own personal decision tree for when you use your Facebook, Google, Microsoft or other social account to sign in, or when you create an account specifically for a site or app. In B2C a Proseware account is what we call a local account. It’s an account that gets created in the B2C tenant using an email address or a flat string as a username, and a password that is stored in the tenant. It’s local because it only works with apps registered in your B2C tenant. It can’t be used to sign in to Office 365, for example.

If a person decides to sign up with a social account, B2C uses information from the social account to pre-fill the user object that will be created in the B2C tenant, and asks the user for any other attributes configured by the developer:

Here we can see the user is also asked to enter a Membership Number and Offering Type. These are custom attributes the Proseware developer has added to the schema of the B2C tenant.

If a person decides to sign up with a Proseware account, B2C gathers the attributes configured by the developer plus information needed to create a local account. In this case the developer has configured local accounts using email as username, so the person signing up is also asked to verify their email address:

B2C takes care of verifying the person signing up has control of that email address before allowing them to proceed. Voila, the user is signed up and signed in to Proseware!

You might ask yourself, how much code did I need to write to make this elaborate sign up screen? Actually, almost none. The sign up page is being rendered by Azure AD B2C, not by the Proseware application. I didn’t have to write any code at all for the logic on that page. I only had to write the HTML and CSS so the page rendered with a Proseware look and feel. The logic for verifying the user’s email address and everything else on the page is B2C code. All I had to do was send an OpenID Connect request to B2C requesting the user sign up flow. I’ll go into more detail on this later when I talk about how I wrote the app and configured the B2C tenant.

Let’s look at a return visit. The user returns and clicks sign-in:

If the user clicks one of the social network providers, B2C will direct the person to the provider to sign in. Upon their return B2C also picks up attributes stored in the directory and returns them to the app, signing the user in.

If the user clicks the Proseware account button, they’ll see the local account sign in page, enter their name and password, and sign in:

That’s it! Now I’ll show you how I built this example.

Configuring Azure AD B2C

Step one was to get an Azure AD B2C tenant. You can do this by going to the Azure AD section of the Azure management portal and creating a B2C tenant (for a shortcut, see the B2C getting started page). B2C tenants are a little different from regular Azure AD tenants. For example, in a regular tenant, by default users can see each other in the address book. That’s what you’d expect in a company or school – people can look each other up. In a B2C tenant, by default users cannot see each other in the address book. That’s what you’d expect – your consumer users shouldn’t be able to browse each other!

Once you have a B2C tenant, you register applications in the tenant 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. To configure these policies, you jump through a link to the new Azure management portal:

This is also the place where you find controls for setting up applications, social network providers, and custom attributes. I’m going to focus on sign up policy for this example. Here’s the list of sign up policies in the tenant. You can create more than one, each driving different behavior:

For the Proseware example I created the B2C_1_StandardSignUp policy. This policy allows a user to sign up using Facebook, Google, or email-named local accounts:

In sign up attributes I indicated what attributes should be gathered from the user during sign up. The list includes custom attributes I created earlier, Membership Number and Offering Type:

When a user completes sign up they are automatically signed in to the application. Using Application Claims I select what attributes I want to send to the application from the directory at that moment:

I’m not using multifactor authentication in this example, but if I did it’s just a simple on/off switch. During sign up the user would be prompted to enter their phone number and we would verify it in that moment.

Finally, I configured user experience customizations. You might have noticed that the sign up and sign-in experiences have a Proseware look and feel, and there isn’t much if any visual evidence of Microsoft or Azure AD. We know that for you to build compelling consumer-facing experiences you have to have as much control as possible over look and feel, so B2C is very customizable even in this initial preview. We do this by enabling you to specify HTML and CSS for the pages rendered by B2C. Here’s what the sign up page would look like with the default look and feel:

But if I configure a B2C with a URL to a web page I created with Proseware-specific look and feel:

Then the sign up experience looks like this:

You can probably imagine a number of different approaches for this kind of customization. We’re partial to this approach, as opposed to say an API-based approach, because it means our servers are responsible for correct handling of things like passwords, and our protection systems can gather the maximum signal from the client for anomaly detection. In an API-based approach, your app would need to gather and handle passwords, and some amount of valuable signal would be lost.

One quick side note. In the initial preview it is possible to do HTML/CSS customization of all the pages except the local account sign in page. That page currently supports Azure AD tenant-branding style customization. We’ll be adding the HTML/CSS customization of the sign in page before GA. Also, we currently block the use of JavaScript for customization, but we expect to enable this later.

That’s a quick look at how I set up a sign up policy. Configuring other policies like sign in and profile management is very similar. As I mentioned earlier, you can create as many policies as you want, so you can trigger different behaviors even within the same app. How to do that? By requesting a specific policy at runtime! Let’s look at the code.

Building an app that uses B2C

The programming model for Azure AD B2C is super simple. Every request you send to B2C is an OAuth 2.0 or OpenID Connect request with one additional parameter, the policy parameter “p=”. This instructs B2C which policy you want to apply to the request. When someone clicks the sign up button on the Proseware web app, the app sends this OpenID Connect sign-in request:

GET /prosewareb2c.onmicrosoft.com/oauth2/v2.0/authorize?
response_type=id_token&
client_id=9bdade37-a70b-4eee-ae7a-b38e2c8a1416&
redirect_uri=https://proseware.skwantoso.com/auth/openid/return&
response_mode=form_post&
nonce= WzRMD9LC95HeHvDz&
scope=openid&
p=b2c_1_standardsignup
HTTP/1.1

The policy parameter in this example invokes the sign up policy called b2c_1_standardsignup. The OpenID Connect response contains an id_token as usual, carrying the claims I configured in the policy:

POST https://proseware.skwantoso.com/auth/openid/return HTTP/1.1

id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IklkVG9rZW5TaWduaW5nS2V5Q29udGFpbmVyIn0.eyJleHAiOjE0NDIxMjc2OTYsIm5iZiI6MTQ0MjEyNDA5NiwidmVyIjoiMS4wIiwiaXNzIjoiaHR0cHM6Ly9sb2dpbi5taWNyb3NvZnRvbmxpbmUuY29tL2Q3YzM3N2RiLWY2MDktNDFmMy1iZTA5LTJiNzNkZWZkNDhhMC92Mi4wLyIsImFjciI6ImIyY18xX3N0YW5kYXJkc2lnbnVwIiwic3ViIjoiTm90IHN1cHBvcnRlZCBjdXJyZW50bHkuIFVzZSBvaWQgY2xhaW0uIiwiYXVkIjoiOWJkYWRlMzctYTcwYi00ZWVlLWFlN2EtYjM4ZTJjOGExNDE2Iiwibm9uY2UiOiJXelJNRDlMQzk1SGVIdkR6IiwiaWF0IjoxNDQyMTI0MDk2LCJhdXRoX3RpbWUiOjE0NDIxMjQwOTYsIm9pZCI6IjJjNzVkMWQ1LTU5YWYtNDc5Yi1hOWMzLWQ4NDFmZjI5ODIxNiIsImVtYWlscyI6WyJza3dhbkBtaWNyb3NvZnQuY29tIl0sImlkcCI6ImxvY2FsQWNjb3VudEF1dGhlbnRpY2F0aW9uIiwibmFtZSI6IlN0dWFydCBLd2FuIiwiZXh0ZW5zaW9uX01lbWJlcnNoaXBOdW1iZXIiOiIxMjM0IiwiZXh0ZW5zaW9uX09mZmVyaW5nVHlwZSI6IjEifQ.cinNfuoMCU4A2ZeeHBKLxAuc8B7UPKwd9sKngxQO8jy19ky3cAHhTJljO0KL7oQ1P5yMFQYs9i4hAun3mmL5hPyC3N7skjU9R0rYl91Ekk7QTlrYgDpGDp5uCF7eA-iWQr0Bmw8oUTYGpjrKfuQP2x8DFxiGgmFqkqz0a20-oy1R6Qr9PaSzr2r8KtjplPX97ADerKIBpdTeLRPmKILWqEDKzoG-bU40LULvPRdvA4yh4nlhRhn4CNUmjZfMWnBcCR3I6jBPl2M3qHQ10DoNXNe2qzL8GalzuMYNnG92OrUppZ5hmXRUXW9yrIRRzDGcERfRyrbyFuYPfu1JJBSTCA

Decoding the id_token from the response yields:

{
typ: “JWT”,
alg: “RS256”,
kid: “IdTokenSigningKeyContainer”
}.
{
exp: 1442127696,
nbf: 1442124096,
ver: “1.0”,
iss: “https://login.microsoftonline.com/d7c377db-f609-41f3-be09-2b73defd48a0/v2.0/”,
acr: “b2c_1_standardsignup”,
sub: “Not supported currently. Use oid claim.”,
aud: “9bdade37-a70b-4eee-ae7a-b38e2c8a1416”,
nonce: “WzRMD9LC95HeHvDz”,
iat: 1442124096,
auth_time: 1442124096,
oid: “2c75d1d5-59af-479b-a9c3-d841ff298216”,
emails: [
skwan@microsoft.com
],
idp: “localAccountAuthentication”,
name: “Stuart Kwan”,
extension_MembershipNumber: “1234”,
extension_OfferingType: “1”
}

Here you can see the usual claims returned by Azure Active Directory and also a few more. The custom attributes I added to the directory and requested of the user during sign up are returned in the token as extension_MembershipNumber and extension_OfferingType. You can also see the name of the policy that generated this token in the acr claim. By the way, we are in the process of taking feedback on claim type names and aligning ourselves better with the standard claim types in the OpenID Connect 1.0 specification. You should expect things to change here during the preview.

Since Azure AD B2C is in fact, Azure AD, it has the same programming model as Azure AD. Which means full support for web app, web API, mobile and PC app scenarios. Data in the directory is managed with the REST Graph API, so you can create, read, update, and delete objects the same way you can in a regular tenant. And this is super important – you can pick and choose what features and policies you want to use. If you want to build the user sign up process entirely yourself and manage users via the Graph API, you can absolutely do so.

B2C conforms to Azure AD’s next generation app model, the v2 app model. To build your application you can make protocol calls directly, or you can use the latest Azure Active Directory libraries that support v2. To find out more visit the B2C section of the Azure AD developer guide – we’ve got quickstart samples, libraries, and reference documentation waiting for you. Just for fun, I built the Proseware example using Node.js on an Ubuntu Linux virtual machine running on Microsoft Azure (shout out to @brandwe for helping me with the code!).

How much will it cost?

B2C will be charged on a consumption basis. You pay only for the resources you use. There will be three meters, billed monthly:

  1. Number of user accounts in the directory
  2. Number of authentications
  3. Number of multi-factor authentications

An authentication is defined as any time an application requests a token for a resource and successfully receives that token (we won’t charge for unsuccessful requests). When you consider the OAuth 2.0 protocol, this counts as when a user signs in with a local account or social account, and also when an application uses a refresh token to get a new access token.

You can find the B2C pricing tiers on the Azure.com pricing page. There will be a free tier for developers who are experimenting with the service. The current B2C preview is free of charge and preview tenants are capped at 50,000 users. We can raise that cap for you on a case by case basis if you contact us. We’ll lift the cap when billing is turned on. Do you have hundreds of millions of users? No problem. Bring ’em on!

What’s next

We’ve already worked with many developers to build apps using Azure AD B2C as part of a private preview program. Along the way we’ve gathered a healthy backlog of features:

  1. Full UX customization: Not just the aforementioned HTML/CSS customization of the local account sign in page, but also the ability to have your URL appear in the browser for every page rendered by B2C. That will remove the last visible remnant of Microsoft from the UX.
  2. Localization: Of course you have users all over the world speaking many languages. Sign in, sign up, and other pages need to render appropriately using strings you provide in the languages you want to support.
  3. Token lifetime control: The ability to control the lifetimes of Access Tokens, ID Tokens and Refresh Tokens is important both for user experience and for you to tune your consumption rate.
  4. A hook at the end of sign up: A number of people have said they want the ability to check a user who is signing up against a record in a different system. A little hook at the end of sign up would allow them to do this, so we’re considering it.
  5. Support for more social networks.
  6. Support for custom identity providers: This would be the ability to, say, add an arbitrary SAML or OpenID Connect identity provider to the tenant.
  7. A variety of predefined reports: So that you can review the activity in your tenant at a glance and without having to write code to call an audit log API.
  8. And more, this is just a fraction of the list…

You can track our progress by following the What’s New topic in the B2C section of the Azure AD developer guide, which you can find in the documentation pages and also by following this blog.

By the way, the proper name of this preview is the Azure Active Directory B2C Basic preview. We’re planning a Premium offering as well, with features that take policies to the next level. But that’s for another blog post!

Please write us

We’re eager to hear your feedback! We monitor stackoverflow (tag: azure-active-directory) for development questions. If you have a feature suggestion, please post it in the Azure Active Directory User Voice site and put “AADB2C:” in the title of your suggestion.

Stuart Kwan (Twitter: @stuartkwan)
Principal Program Manager
Azure Active Directory

 

Trust will make or break cloud ID management services

ZDNet’s John Fontana has written about the Webinar on Identity Management as a Service hosted last week by Craig Burton of Kuppinger Cole.  The session began with a presentation by Craig on the revolutionary impact of the API economy in shaping the requirements for cloud identity.  Then I spoke about the characteristics of Identity Management as a Service as they were shaping the industry and, especially Azure Active Directory, while Chuck Mortimer gave a good description of what we will be seeing in Salesforce.com’s emerging cloud directory service.  The Webinar is available to those who want the details.

John highlights a number of the key emerging concepts in his piece, titled “Trust will make or break cloud ID management services”:

If identity-management-as-a-service is to take hold among enterprises it will need to be anchored by well-crafted rules for establishing trust that incorporate legal parameters and policy requirements, according to a pair of identity experts.

“Where we have seen trust frameworks be really successful in the past is where member organizations have some means and motivation for cooperation be that altruistic, economic, etc.,” said Chuck Mortimore, senior director of product management for identity and security at Salesforce.com. He cited the Shibboleth Project deployed in academia that highly incents universities to collaborate and cooperate.

“We are seeing both the U.S. government and the British government selecting trust frameworks for their respective identity initiatives,” said Kim Cameron, Microsoft’ identity architect. “You need a bunch of people who share the interest of having a trust framework.”

Trust frameworks ensure trust between those issuing an identity and the providers that accept that ID for authentication to access services or data, and in increasing cases, to tap application programming interfaces (APIs).

To wit, 62% of the traffic on Salesforce.com is API calls, mobile clients and desktop clients.

Mortimore and Cameron appeared together Tuesday on a Webinar hosted by Kuppinger Cole analyst Craig Burton.

The identity-management-as-a-service (IdMaaS) concept is rising in importance due to an emerging “API economy,” according to Burton. That economy is characterized by billions of API calls to support services sharing data on a massive, distributed scale that stretches across the enterprise and the cloud.

IdMaaS defines a cloud service that manages identity for an organization’s employees, partners and customers and connects them to applications, devices and data either in the enterprise or the cloud.

“This won’t be a point-to-point situation,” said Cameron. He said existing systems can’t handle the identity, security and privacy requirements of the cloud and its API economy. “The domain-based identity management model of the ‘90s and early 2000s is a non-starter because no one will be staying within the enterprise boundary.”

Cameron said the only way all the requirements can be met is with an identity service that fosters simplification and lower costs. And the only way that gets off the ground is through the use of trust frameworks that simplify the legal and policy requirements.

Cameron pointed to a number of current trust frameworks certification programs including Kantara and the Open Identity Exchange.

Mortimore said end-users need to start with a “baseline of security and trust” and go from there.

He said he believes most enterprises will use a hybrid identity management configuration – enterprise infrastructure plus cloud.

“We firmly believe we will see that architecture for a long time,” said Mortimore. “If you look at the core imperatives for IT, cloud and mobile apps are forcing functions for IT investments, as well as, people looking at existing IDM infrastructure that is running up against friction like how do I expose this API.”

Mortimore said cloud identity management services represent a nice transition path.

Salesforce.com backed up that idea last month when it introduced Salesforce Identity, a service baked into its applications, platform, and development environment.

Mortimore ran the list of features: a directory that anchors identity management, reliance on standard schemas and wire protocols, extensibility and programmability.

“We are not running this as a Salesforce identity service, we are running it on behalf of customers. That is a critical part of these identity cloud systems. We need to facilitate the secure exchange of identities, federation, collaboration and attribute exchange,” said Mortimore.

Cameron concurred, saying “the identity management service operates your directory for you, that has to be the model.”

Microsoft’s service is called Azure Active Directory, and it offers the cloud-based services in a similar fashion to what Active Directory and other Microsoft infrastructure products (authentication, federation, synchronization) do within the enterprise.

“You need to use the efficiencies of the cloud to enable new functions in identity and provide more capability for less money,” he said.

While they are giants, Microsoft and Salesforce.com represent just a handful of providers that offer or are building cloud identity services. (Disclaimer: My employer offers a cloud identity service).

 

Yes to SCIM. Yes to Graph.

Today Alex Simons, Director of Program Management for Active Directory, posted the links to the Developer Preview of Windows Azure Active Directory.  Another milestone.

I'll write about the release in my next post.  Today, since the Developer Preview focuses a lot of attention on our Graph API, I thought it would be a good idea to respond first to the discussion that has been taking place on Twitter about the relationship between the Graph API and SCIM (Simple Cloud Identity Management).

Since the River of Tweets flows without beginning or end, I'll share some of the conversation for those who had other things to do:

@NishantK: @travisspencer IMO, @johnshew’s posts talk about SaaS connecting to WAAD using Graph API (read, not prov) @IdentityMonk @JohnFontana

@travisspencer: @NishantK Check out @vibronet’s TechEd Europe talk on @ch9. It really sounded like provisioning /cc @johnshew @IdentityMonk @JohnFontana

@travisspencer: @NishantK But if it’s SaaS reading and/or writing, then I agree, it’s not provisioning /cc @johnshew @IdentityMonk @JohnFontana

@travisspencer: @NishantK But even read/write access by SaaS *could* be done w/ SCIM if it did everything MS needs /cc @johnshew @IdentityMonk @JohnFontana

@NishantK: @travisspencer That part I agree with. I previously asked about conflict/overlap of Graph API with SCIM @johnshew @IdentityMonk @JohnFontana

@IdentityMonk: @travisspencer @NishantK @johnshew @JohnFontana check slide 33 of SIA322 it is really creating new users

@IdentityMonk: @NishantK @travisspencer @johnshew @JohnFontana it is JSON vs XML over HTTP… as often, MS is doing the same as standards with its own

@travisspencer: @IdentityMonk They had to ship, so it’s NP. Now, bring those ideas & reqs to IETF & let’s get 1 std for all @NishantK @johnshew @JohnFontana

@NishantK: @IdentityMonk But isn’t that slide talking about creating users in WAAD (not prov to SF or Webex)? @travisspencer @johnshew @JohnFontana

@IdentityMonk: @NishantK @travisspencer @johnshew @JohnFontana indeed. But its like they re one step of 2nd phase. What are your partners position on that?

@IdentityMonk: @travisspencer @NishantK @johnshew @JohnFontana I hope SCIM will not face a #LetTheWookieWin situation

@NishantK: @johnshew @IdentityMonk @travisspencer @JohnFontana Not assuming anything about WAAD. Wondering about overlap between SCIM & Open Graph API

Given these concerns, let me explain what I see as the relationship between SCIM and the Graph API.

What is SCIM?

All the SCIM documents begin with a commendably unambiguous statement of what it is:

The Simple Cloud Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns of exchanging this schema using standard protocols. In essence, make it fast, cheap and easy to move users in to, out of and around the cloud. [Kim: emphasis is mine]

I support this goal. Further, I like the concept of spec writers being crisp about the essence of what they are doing: “Make it fast, cheap and easy to move users in to, out of and around the cloud”.  For this type of spec to be useful we need it to be as widely adopted as possible, and that means keeping it constrained, focussed and simple enough that everyone chooses to implement it.

I think the SCIM authors have done important work to date.  I have no comments on the specifics of the protocol or schema at this point – I assume those will continue to be worked out in accordance with the spec's “essence statement” and be vetted by a broad group of players now that SCIM is on a track towards standardization.  Microsoft will try to help move this forward:  Tony Nadalin will be attending the next SCIM meeting in Vancouver on our behalf.

Meanwhile, what is “the Graph”? 

Given that SCIM's role is clear, let's turn to the question of how it relates to a “Graph API”.  

Why does our thinking focus on a Graph API in addition to a provisioning protocol like SCIM?  There are two answers.

Let's start with the theoretical one.  It is  because of the central importance of graph technology in being able to manage connectedness – something that is at the core of the digital universe.  Treating the world as a graph allows us to have a unified approach to querying and manipulating interconnected objects of many different kinds that exist in many different relationships to each other.

But theory only appeals to some… So let's add a second answer that is more… practical.  A directory has emerged that by August is projected to contain one billion users. True, it's only one directory in a world with many directories (most agree too many).  But beyond the importance it achieves through its scale, it fundamentally changes what it means to be a directory:  it is a directory that surfaces a multi-dimensional network.  

This network isn't simply a network of devices or people.  It's a network of people and the actions they perform, the things they use and create, the things that are important to them and the places they go.  It's a network of relationships between many meaningful things.  And the challenge is now for all directories, in all domains, to meet a new bar it has set.    

Readers who come out of a computer science background are no doubt familiar with what a graph is.  But I recommend taking the time to come up to speed on the current work on connectedness, much of which is summarized in Networks, Crowds and Markets: Reasoning About a Highly Connected World (by Easley and Kleinberg).  The thesis is straightforward:  the world of technology is one where everything is connected with everything else in a great many dimensions, and by refocusing on the graph in all its diversity we can begin to grasp it. 

In early directories we had objects that represented “organizations”, “people”, “groups” and so on.  We saw organizations as “containing” people, and saw groups as “containing” people and other groups in a hierarchical and recursive fashion.  The hierarchy was a particularly rigid kind of network or graph that modeled the rigid social structures (governments, companies) being described by technology at the time.

But in today's flatter, more interconnected world, the things we called “objects” in the days of X.500 and LDAP are better expressed as “nodes” with different kinds of “edges” leading to many possible kinds of other “nodes”.  Those who know my work from around 2000 may remember I used to call this polyarchy and contrast it with the hierarchical limitations of LDAP directory technology.

From a graph perspective we can see “person nodes” having “membership edges” to “group nodes”.  Or “person nodes” having “friend edges” to other “person nodes”.  Or “person nodes” having “service edges” to a “mail service node”.  In other words the edges are typed relationships between nodes that may possibly contain other properties.  Starting from a given node we can “navigate the graph” across different relationships (I think of them as dimensions), and reason in many new ways. 

For example, we can reason about the strength of the relationships between nodes, and perform analysis, understand why things cluster together in different dimensions, and so on.

From this vantage point, directory is a repository of nodes that serve as points of entry into a vast graph, some of which are present in the same repository, and others of which can only be reached by following edges that point to resources in different repositories.  We already have forerunners of this in today's directories – for example, if the URL of my blog is contained in my directory entry it represents an edge leading to another object.  But with conventional technology, there is a veil over that distant part of the graph (my blog).  We can read it in a browser but not access the entities it contains as structured objects.  The graph paradigm invites us to take off the veil, making it possible to navigate nodes across many dimensions.

The real power of directory in this kind of interconnected world is its ability to serve as the launch pad for getting from one node to a myriad of others by virtue of different  relationships. 

This requires a Graph Protocol

To achieve this we need a simple, RESTful protocol that allows use of these launch pads to enter a multitude of different dimensions

We already know we can build a graph with just HTTP REST operations.  After all, the web started as a graph of pages…  The pages contained URLs (edges) to other pages.  It is a pretty simple graph but that's what made it so powerful.

With JSON (or XML) the web can return objects.  And those objects can also contain URLs.  So with just JSON and HTTP you can have a graph of things.  The things can be of different kinds.  It's all very simple and very profound.

No technology ghetto

Here I'm going to put a stake in the ground.  When I was back at ZOOMIT we built the first commercial implementation of LDAP while Tim Howes was still at University of Michigan.  It was a dramatic simplification relative to X.500 (a huge and complicated standard that ZOOMIT had also implemented) and we were all very excited at how much Tim had simplified things.  Yet in retrospect, I think the origins of LDAP in X.500 condemned directory people to life in a technology ghetto.  Much more dramatic simplifications were coming down the pike all around us in the form of HTML, latter day SQL and XML.  For every 100 application programmers familiar with these technologies, there might have been – on a good day – one who knew something about LDAP.  I absolutely respect and am proud of all the GOOD that came from LDAP, but I am also convinced that our “technology isolation” was an important factor that kept (and keeps) directory from being used to its potential.

So one of the things that I personally want to see as we reimagine directory is that every application programmer will know how to program to it.  We know this is possible because of the popularity of the Facebook Graph API.  If you haven't seen it close up and you have enough patience to watch a stream of consciousness demo you will get the idea by watching this little walkthrough of the Facebook Graph Explorer.   Or better still just go here and try with your own account data.

You have to agree it is dead simple and yet does a lot of what is necessary to navigate the kind of graph we are talking about.  There are many other similar explorers available out there – including ours.  I chose Facebook's simply because it shows that this approach is already being used at colossal scale.  For this reason it reveals the power of the graph as an easily understood model that will work across pretty much any entity domain – i.e. a model that is not technologically isolated from programming in general.

A pluggable namespace with any kind of entity plugging in

In fact, the Graph API approach taken by Facebook follows a series of discussions by people now scattered across the industry where the key concept was one of creating a uniform pluggable namespace with “any” kind of entity plugging in (ideas came from many sources including the design of the Azure Service Bus).

Nishant and others have posed the question as to whether such a multidimensional protocol could do what SCIM does.  And my intuition is that if it really is multidimensional it should be able to provide the necessary functionality.  Yet I don't think that diminishes in any way the importance of or the need for SCIM as a specialized protocol.  Paradoxically it is the very importance of the multidimensional approach that explains this.

Let's have a thought experiment. 

Let's begin with the assumption that a multidimensional protocol is one of the great requirements of our time.  It then seems inevitable to me that we will continue to see the emergence of a number of different proposals for what it should be.  Human nature and the angels of competition dictate that different players in the cloud will align themselves with different proposals.  Ultimately we will see convergence – but that will take a while.   Question:  How are we do cloud provisioning in the meantime?  Does everyone have to implement every multidimensional protocol proposal?  Fail!

So pragmatism calls for us to have a widely accepted and extremely focused way of doing provisioning that “makes it fast, cheap and easy to move users in to, out of and around the cloud”.

Meanwhile, allow developers to combine identity information with information about machines, services, web sites, databases, file systems, and line of business applications through multidimensional protocols and APIs like the Facebook and the Windows Azure Active Directory Graph APIs.  For those who are interested, you can begin exploring our Graph API here:  Windows Azure AD Graph Explorer (hosted in Windows Azure) (Select ‘Use Demo Company’ unless you have your own Azure directory and have gone through the steps to give the explorer permission to see it…)

To me, the goals of SCIM and the goals of the Graph API are entirely complementary and the protocols should coexist peacefully.  We can even try to find synergy and ways to make things like schema elements align so as to make it as easy as possible to move between one and the other. 

There is no hub. There is no center.

Mary Jo Foley knows her stuff, knows identity and knows Microsoft.  She just published a piece called “With Azure Active Directory, Microsoft wants to be the meta ID hub“.  The fact that she picked up on John Shewchuk's piece despite all the glamorous announcements made in the same timeframe testifies to the fact that she understands a lot about the cloud.  On the other hand, I hope she won't mind if I push back on part of her thesis.  But before I do that, let's hear it:

Summary: A soon-to-be-delivered preview of a Windows Azure Active Directory update will include integration with Google and Facebook identity providers.

Microsoft isn’t just reimaginging Windows and reimaginging tablets. It’s also reimaginging Active Directory in the form of the recently (officially) unveiled Windows Azure Active Directory (WAAD).

In a June 19 blog post that largely got lost among the Microsoft Surface shuffle last week, Microsoft Technical Fellow John Shewchuk delivered the promised Part 2 of Microsoft’s overall vision for WAAD.

WAAD is the cloud complement to Microsoft’s Active Directory directory service. Here’s more about Microsoft’s thinking about WAAD, based on the first of Shewchuk’s posts. It already is being used by Office 365, Windows InTune and Windows Azure. Microsoft’s goal is to convince non-Microsoft businesses and product teams to use WAAD, too.

This is how the identity-management world looks today, in the WAAD team’s view:

And this is the ideal and brave new world they want to see, going forward.


WAAD is the center of the universe in this scenario (something with which some of Microsoft’s competitors unsurprisingly have problem).

[Read more of the article here]

The diagrams Mary Jo uses are from John's post.  And the second clearly shows the “Active Directory Service”  triangle in the center of the picture so one can understand why Mary Jo (and others) could think we are talking about Active Directory being at the center of the universe. 

Yet in describing what we are building, John writes,

“Having a shared directory that enables this integration provides many benefits to developers, administrators, and users.”

“Shared” is not the same as “Central”.  For the Windows Azure AD team the “shared directory” is not “THE hub” or “THE center”.  There is no one center any more in our multi-centered world.  We are not building a monolithic, world-wide directory.  We are instead consciously operating a directory service that contains hundreds of thousands of directories that are actually owned by individual enterprises, startups and government organizations.  These directories are each under the control of their data owner, and are completely independent until their data owner decides to share something with someone else.

The difference may sound subtle, but I don't think it is.  When I think of a hub I think of a standalone entity mediating between a set of claims providers and a set of relying parties.  

But with Azure Active Directory the goal is quite different:  to offer a holistic “Identity Management as a Service” for organizations, whether startups, established enterprises or government organizations – in other words to “operate” on behalf of these organizations.  

One of the things such a service can do is to take care of connecting an organization to all the consumer and corporate claims providers that may be of use to it.  We've actually built that capability, and we'll operate it on a 24/7 basis as something that scales and is robust.  But IdMaaS involves a LOT of other different capabilities as well.  Some organizations will want to use it for authentication, for authorization, for registration, credential management and so on.  The big IdMaaS picture is one of serving the organizations that employ it – quite different from being an independent hub and following a “hub” business model. 

In this era of the cloud, there are many cloud operators.  Martin Kuppinger has pointed out that “the cloud” is too often vendor-speak for “this vendor's cloud”.  In reality there are “clouds” that will each host services that are premium grade and that other services constructed in different clouds will want to consume.  So we will all need the ability to reach accross clouds with complete agility, security and privacy and within a single governance framework.  That's what Identity Management as a Service needs to facilitate, and the Active Directory Service triangle in the diagram above is precisely such a service.  There will be others operated by competitors handling the identity needs of other organizations.  Each of us will need to connect enterprises we serve with those served by our competitors. 

This said, I really accept the point that to express this in a diagram we could (and should)  draw it very differently.  So that's something John and I are going to work on over the next few days.  Then we'll get back to you with a diagram that better expresses our intentions.

 

Disruptive Forces: The Economy and the Cloud

New generations of digital infrastructure get deployed quickly even when they are incompatible with what already exists.  But old infrastructure is incredibly slow to disappear.   The complicated business and legal mechanisms embodied in computer systems are risky and expensive to replace..  But existing systems can't function without the infrastructure that was in place when they were built…  Thus new generations of infrastructure can be easily added, but old and even antique infrastructures survive alongside them to power the applications that have not yet been updated to employ new technologies.

This persistence of infrastructure can be seen as a force likely to slow changes in Identity Management, since it is a key component of digital infrastructure.

Yet global economic and technological trends lead in the opposite direction. The current reality is one of economic contraction where enterprises and governments are under increasing pressure to produce more with less. Analysts and corporate planners don’t see this contraction as being transient or likely to rebound quickly. They see it as a long-term trend in which organizations become leaner, better focused and more fit-to-purpose – competing in an economy where only fit-to-purpose entities survive.

At the same time that these economic imperatives are shaking the enterprise and governments, the introduction of cloud computing enables many of the very efficiencies that are called for.

Cloud computing combines a number of innovations. Some represent new ways of delivering and operating computing and communications power.  But the innovations go far beyond higher density of silicon or new efficiencies in cooling technologies…  The cloud is ushering in a whole new division of labor within information technology.

Accelerating the specialization of functions

The transformational power of the cloud stems above all else from its ability to accelerate the specialization of functions so they are provided by those with the greatest expertise and lowest costs.

I was making this “theoretical” point while addressing the TSCP conference recently, which brings together people from extremely distributed industries such as aeronautics and defense.  Looking out into the audience I was suddenly struck by something that should have been totally obvious to me.  All the industries represented in that room, except for information technology, had an extensive division of labor across a huge number of parties.  Companies like Boeing or Airbus don't manufacture the spokes on the wheels of their planes, so to speak.  They develop specifications and assemble completed products in cost effective ways that are manufactured and refined by a whole ecosystem.  They have massively distributed supply chains.  Yet our model in information technology has remained rather pre-industrial and there are innumerable examples of companies expending their own resources doing things they aren't expert at, rather than employing a supply chain.  And part of the reason is because of the lack of an infrastructure that supports this diversification.  That infrastructure is just arriving now – in the form of the cloud.   

Redistributing processes to be most efficiently performed

So  technologically the cloud is an infrastructure honed for multi-sourcing – refactoring processes and redistributing them to be most efficiently performed.

The need to become leaner and more fit-to-purpose will drive continuous change.  Organizations will attempt to take advantage of the emerging cloud ecology to substitute off-the-shelf commoditized systems offered as specialized services. When this is not possible they will construct their newly emerging systems in the cloud using other specialized ecosystem services as building blocks.

Given the fact that the best building blocks for given purposes may well be hosted on different clouds, developers will expect to be able to reach across clouds to integrate with the services of their choice. Cloud platforms that don’t offer this capability will die from synergy deficiency.

Technological innovation will need to take place before services will be able to work securely in this kind of loosely coupled world – constituting a high-value version of what has been called the “API Economy”. The precept of the API economy is to expose all functionality as simple and easily understood services (e.g. based on REST) – and allow them to be consumed at a high level of granularity on a pay-as-you-go basis.

In the organizational world, most of the data that will flow through these APIs will be private data. For enterprises and governments to participate in the API Economy they will require a system of access control in which many different applications run by different administrations in different clouds are able to reuse knowledge of identity and security policy to adequately protect the data they handle.  They will also need shared governance.

Specifically, it must be possible to reliably identify, authenticate, authorize and audit across a graph of services before reuse of specialized services becomes practicable and economical and the motor of cloud economics begins to hum.

 

Governance is key

I want to return to Nishant's concerns with the way I've presented IdMaaS:

What I was surprised to find missing from Kim’s and Craig’s discussion about IdMaaS were the governance controls one needs in identity management (and therefore IdMaaS) – like approval workflows, access request and access recertification. In other words, those crucial business tools in identity management that have led many analysts and vendors (including me) to repeat on stage many, many times that “Identity Management is about process, not technology”. And this is the part that makes identity management, and therefore IdMaaS, really hard, as I alluded to in my talk about ‘Access Provisioning in a Services World‘ at Catalyst a couple of years ago.

Let me begin by saying I agree completely with Nishant about the importance of governance.  In fact, in my first blog about IdMaaS I highlighted two fundamental aspects of IdMaaS and digital identity being:

  • confidential auditing; and
  • assurance of compliance.

I also agree with him on the urgent requirement for “approval workflows, access request and access recertification.”  I believe we need identity and access process control.

I'm therefore surprised about the confusion on whether or not I think governance is important, but I'm glad to get this cleared up right at the beginning.

Let me explain what I had in mind as a way to achieve some depth in this discussion.  It seemed to me we need to decompose the overall service capabilities, rather than trying to discuss “everything simultaneously”.  I started by trying to talk about the IdM models that have led us to the current point in time, in order to set the stage for the exploration of the new emerging model of  Identity Management as a Service and its capabilities, as illustrated in this graphic: 

Composable capabilities of IdMaaS

Now my point here is not to argue that this  graphic captures all the needed IdMaaS capabilities – it's very much a work in progress.  It is simply that, when you look at the whole landscape, you see there are a number of areas that warrant real discussion in depth…  My conclusion was that we will only succeed at this by looking at things one at a time.

The point can be made, and perhaps this is what Nishant was saying, that governance applies to everything.  I accept that this is true, but governance still can be factored out for purposes of discussion.  I think we'll achieve more clarity if that's what we do.  For one thing, it means we can dive more deeply into governance itself.

Let me know if this decompositional approach seems wrong-headed and we should just have a free-for-all where we discuss everything as it relates to everything else.  I agree that this can be interesting too.

That said, I want to take up some of the points Nishant makes when talking about governance in the Domain Identity Model.

In…  ‘Identity management before the cloud (part one)‘, Kim says “In the domain paradigm identity management was thought to be the CRUD and little more.”. But that is not true. What made identity management so hard and expensive was the need to supplement the CRUD features with a governance layer that included policy and process to manage over the entirety of the identity management infrastructure. The responsibility for this was early on thrust upon the provisioning products like Thor Xellerate and Waveset, and later on spawned more specialized handling in IAG products like Sailpoint and Aveksa. Kim alludes to these when he says “A category of Identity Management integration products arose … often brittle point products and tools that could only be deployed at high cost by skilled specialists”. That’s accurate, but not because they were pointless or overhead or overkill. These products were difficult to deploy and needed customization because it wasn’t well understood how to introduce the controls needed in IAM in a manner that was practical and usable. And it was always assumed that every customer would demand unique business processes, so the approach was a toolkit approach rather than a solution approach.

Reading this, I hold even more strongly than before to the statement that the Domain Model was about CRUD and absolute control by The Domain.   The fact that businesses required governance is historically true but doesn't change the way Domains were conceptualized, built and sold by everyone in the industry.  So I agree with Nishant about the importance of governance but don't think this changes the essence of what domains actually were.

For a at least several decades computer governance was provided as an outcome of security analysts configuring domain based systems to implement a variety of well-known techniques (physical security, separation of duties, multiple approvers and the like) in order to satisfy business objectives and comply with normative standards prevalent in the industries and national or geographical jurisdictions. 

I'm sure many of us witnessed the calisthenics of colleagues in banks and financial institutions, who, as security officers, figured out how to use mainframes and LANS in both their nascent and more evolved forms to be effective at this.  I know I used to marvel at some of what they accomplished. 

We are talking about a time when governance wasn't synonymous with government regulation. Governance was more or less orthogonal to the way products were built by the industry.  Domain products could be used in ways that accorded with asset protection requirements if the right expertise was present to set the systems up to achieve these ends.  And on a pessimistic note, has so much really changed in this regard since then?

Many of the provisioning concepts that appeared in products like Waveset and Xellerate appeared earlier in products like ZOOMIT VIA and Metamerge.  But those, like Waveset, Xellerate and Aveksa were actually, in my view,  “post-domain” products that attempted a holistic solution working across product boundaries.  

Still, while being post-domain in some ways (e.g. meta),  they continued to require extensive manual intervention by security experts to coax “compliant” behaviors out of them, and this intervention was embodied in detailed configurations and scripts dependent on the behaviors of underlying products.  This meant they were often fragile:  if the underlying products were upgraded, for example, they might no longer be compatible with the framework intended to manage them. 

Nishant goes on to say,

And an IdMaaS architecture as alluded to by Kim and illustrated by Craig in this diagram just makes the solving of this problem more difficult and even more critical due to the zero trust environment. Since the identities have not been created and are not controlled by the organization that needs to make the access decisions, approval and review controls become even more important because they’re all the enterprise has. The ability to de-provision access based on events or manual intervention becomes a crucial component of access lifecycle management. These are the safety measures the organization needs to put in place for security and compliance.

I agree the ability to de-provision is key and in fact it is key to what we will be delivering.  On the other hand, Nishant's conclusion that “the [IdMaaS] architecture.. must make the solving of this problem more difficult… due to the zero trust environment” is I think absolutely unfounded.  As I will show when we go through the requirements for IdMaaS, Trust Frameworks are a necessity, and I know of few Trust Frameworks that are based on “zero trust”. 

There is a bit too much flailing at paper tigers for me to take all of this apart in a single post.  Let's take a deep breath and delve systematically both into requirements and the details of what is being proposed in WAzAD.

 

Freedom of choice != Your choice of captor

I am happy to see that Nishant Kaushik (@NishantK)  has responded to the posts I've been doing on IdMaaS.  Nishant has strong ideas, having led product architecture and strategy within the Identity Management & Security Products group at Oracle for many years.  Nowadays he is with a startup called Identropy and writes the blog TalkingIdentity.

Nishant's main concern in his first post was that I've gone as far as I have without discussing the importance of governance controls.  I'm going to save this issue for my next piece, since Nishant also ended up in a spirited conversation with Craig Burton that is really worth following.  He wrote:

Craig Burton thinks that this vision, and the associated work Microsoft is doing on Windows Azure Active Directory (as described in this post by John Shewchuck) is “profoundly innovative”. I’ll be honest, I’m having a little trouble seeing what is so innovative about WAAD itself. How is the fact that becoming an Office 365 customer automatically gives you an AD in the cloud that you can build/attach other Azure applications to that different from Oracle saying that deploying a Fusion Application will include an OUD based identity store that the enterprise can also use for other applications? Apart from being in the cloud and therefore far easier to use in federated identity (SAML, OpenID, OAuth) scenarios. But I’ll wait to hear more before commenting any further (though John Fontana and others have already weighed in).

Craig Burton, as is his trademark, includes a few lightning bolts in his response:

Nishant must not have read my post very carefully. In my explanation of why Microsoft’s vision for IDMaaS is so profound, he failed to notice that I never once mentioned WAAD (Windows Azure Active Directory) or Office 365. There is a reason for that. I am not applauding Microsoft’s — or any other vendor’s — implementation of IDMaaS.

What is so profound about this announcement is that Microsoft is following Kim Cameron’s directives for building a Common Identity Framework for the planet, not just for a vendor.

In 2009 Kim Cameron, Reinhard Posch and Kai Rannenberg wrote Proposal for a Common Identity Framework: A User-Centric Identity Metasystem.

In section 5.4 of that document, the authors spell out the requirement for customer Freedom of Choice.

Freedom of Choice

Freedom of choice for both users and relying parties refers to choice of service operators they may wish to use as well as to the interoperability of the respective systems.

This definition is quite different than the freedom of choice Mr. Kaushik writes about in his blog piece. I posit that the Microsoft vision is so profound because it is built on a definition of Freedom of Choice that fits the above description and not where the customer is free to choose a particular captor.

And so I state again:

Freedom of Choice != Your Choice of Captor

Microsoft’s vision has changed the playing field. Any vendor building IdMaaS that is not meeting the Freedom of Choice requirements defined here is no longer in the game. That is profoundly innovative because this is truly a vision that benefits everyone — but mostly the customer.

With these remarks Craig starts really getting to the bare bones of what it takes to be trusted  to manage identity for enterprises and governments. 

It didn't take long before Nishant fired off a second dispatch accepting Craig's  points and clarifing what he saw as the real issues:

I want to be clear: I am not questioning the vision that Kim Cameron has started to talk about in his posts about IDMaaS (though I was bringing up a part – the governance controls – that I felt was missing and that I believe has a major impact on the architecture of a Common Identity Framework, as Craig called it). And I am completely in agreement with what Craig described in his original post in the section “Stop Gushing and Lay it Out for Me”.

Craig talks about how Freedom of Choice necessarily includes Freedom from Captor. He then says “This definition is quite different than the freedom of choice Mr. Kaushik writes about in his blog piece“.  I’m not sure why he thinks that, because what I am saying is exactly in line with what Craig and Kim are saying. It is what I have been saying since back in 2006 when I first started talking about the Identity Services Platform, which talks about the framework through which identity-enabled applications (essentially any application) consume identity from standardized services that can plug into any identity system or metasystem.

What I was pointing out was that John Shewchuck’s post about WAAD seemed to indicate a lack of Freedom of Choice in what Microsoft is rolling out, at least right now. Becoming an Office 365 customer would “automatically create a new Windows Azure Active Directory that is associated with the Office 365 account“, forcing you to store and manage your identities in WAAD.  It should simply ask for the domain from which users could use this, and you could simply point to the Google Apps domain of your company, sign up for WAAD if needed, or grant access to contractors/partners using whatever identity they choose (traditional AD environment, Facebook or Twitter accounts, even personal OpenIDs). By the way, the governance controls I was talking about are essential here in order to define the process of granting, managing and taking away access in this deployment model.

When I said “I’m having a little trouble seeing what is so innovative about WAAD itself”, I was pointing out my opinion that the details in John’s post did not seem to match up with the vision being outlined in Kim’s post, representing the kind of disconnect that Craig himself called out as a risk at various times in his post, but most notably in the section titled Caveats. I guess I’m not quite ready to make the leap that Microsoft’s work will line up Kim’s vision, and was calling out the disconnect I was seeing. And when Craig said “Microsoft is not only doing something innovative – but profoundly innovative”, I assumed he was talking about WAAD and related work, and not just referring to what Kim is talking about.

Nishant goes on to give more examples of how he thinks Office 365 could be implemented.  I won't discuss those at this point since I think we should save our implementation discussions for later.  First we need a more thorough conversation about what IdMaaS actually involves given all the changes that are impacting us.  It is these definitions that must lead to implementation considerations.  I hope Nishant will bear with me on this so we can continue the discussion begun so far.

I also want, in deference to Nishant and others who may have similar concerns, make a few remarks on what we have rolled out right now.  I want to be really clear that while I think we already do a number of things really well and in a robust way at very high scale, there are all kinds of things we still don't do that form an integral part of our vision for what must be done.  Anyone who says they can do all that is needed just doesn't, in my view, have a vision.

On the other hand, I hope we can steer clear of overly simplified recipies for what complicated offerings like Office 365 require as identity management.  For example, applications like Office need directories and places to store information about people in them, and nowhere is it written in stone that this should be done by sending realtime queries to dozens or thousands of systems.   Enterprise users want directory lookup that is as fast and reliable when served from the cloud as it is on premises.  And so on.  My point here is not to argue for one solution versus another, but to invite Nishant and others who may be interested to zero in on the broad set of requirements before getting overly committed to possible ways of meeting them.

      

Craig Burton on Microsoft's Identity Management as a Service

Craig Burton first achieved prominence as the Senior Vice President of Corporate Marketing and Development who drove Novell's innovation and market strategies in the days when it was aggressively turning computing upside down. Some years later he founded the Burton Group with Jamie Lewis.  Today he is a Distinguished Analyst for Kuppinger Cole, where he just published an intriguing response to the blogs John and I have been doing:  Microsoft is Finally Being Relevant.

For now I'll refrain from comment and just offer up the goods:

Microsoft is Finally Being Relevant
Surprise surprise. For the last few years it looked as if the battling business units and power struggles within Microsoft had all but rendered the company incapable of doing anything innovative or relevant. But clearly something has happened to change this lack of leadership and apparent stumbling in the dark. Microsoft is not only doing something innovative — but profoundly innovative.

In a dual post by Microsoft’s John Shewchuk and Kim Cameron, the announcement was made about what Kim Cameron alluded to at the KuppingerCole EIC in April — Identity Management as a Service (IDMaaS). This is not trivial, and does not suck. It ROCKS.
Why is Identity Management as a Service a Big Deal
From a technical perspective, the place where innovation really makes a difference is the place where the rubber meets the road — infrastructure. Infrastructure is not only fundamental—as it provides the technical framework and underpinning to support big change — but infrastructure is hard.

It’s also hard to get funded and hard to sell both outside and inside of companies that make infrastructure.

This is because there is little possibility of showing a direct ROI in core infrastructure investment. It takes vision and guts to invest in infrastructure.

Nobody wants to buy identity infrastructure. In fact no one should have to pay for identity infrastructure. It should be ubiquitous, work, and be free to everyone and controlled by no one. Infrastructure at this level is as fundamental as air. You don’t think about it, you don’t buy it; you just breathe it in and out and get on with the details.

Metaphorically, when it comes to the maturity of identity infrastructure today—we are all sucking on thin air from teeny tubes of infrastructure veneer connected to identity silos (Facebook Connect, Twitter, Federated Identity and so on.)

It’s much like the other core suite of protocols of the Internet — like TCP/IP. TCP/IP is free as far as a piece of software goes. No one ever pays for the transport anymore.

So should be the protocols and infrastructure for doing Identity Management.  With this announcement Microsoft is showing that it understands Identity Infrastructure is fundamental to everything in the hybrid world of social-mobile-cloud networking that we are stumbling towards.

Further, Microsoft is making it clear it understands that the current identity provider-centric world we live in now is broken and simply will not work for the future. Significant movement forward from this wretched state requires massive change — which is what Microsoft is proposing.

From a political and business perspective, Kim Cameron’s vision of a ubiquitous Identity Metasystem has somehow prevailed inside Microsoft and is starting to emerge. This is a big deal. Finally a company with lots of talent that has been wallowing from lack of leadership has stepped up and put a stake in the ground about Identity. Bravo!

Everybody else of significance that could be doing something significant with identity infrastructure — Google, Facebook, and Amazon for starters — are trapped in their current business models of trafficking your identity for short term profit. For each of them, the little piece they hold captive of your identity is the product by which they are making money. This is both short sighted and unsustainable.

Microsoft’s plan is much grander. Invest in the hard stuff, solve the really tough identity infrastructure problems across the board—simple, private, and scalable. By taking this high road, Microsoft is betting it can take the leadership role by increasing the size of the pie for other SaaS services and apps that organizations and individuals want and are willing to pay for. Much more visionary that continuing to fight over whatever crumb you can get based on the current broken model.

If Microsoft is allowed to pull this off, it is a good thing.
Stop Gushing and Lay it Out for Me
To understand the significance of IDMaaS, it’s useful to take a quick look at how identity management systems have evolved.

Figure 1 shows how identities started out being managed within the boundaries of a domain. Domain-based identity managed need hardly be mentioned here as it can’t possibly meet any of the requirements for identity management in today’s organizational environments. For its day, it worked and it was a good place to start.

Figure 1: Domain Contained Identity

Figure 2 illustrates the first generation of federated identity management systems. This is a powerful model and was a big step forward from the domain model. In this model there is a service provider that accepts claims from an identity provider. A person can then prove who they are to the identity provider and present claims to the service provider to assure proper access to services and resources. This model works when these a relatively small number of parties involved. But as soon as there a diverse number of parties, it quickly breaks down.

Figure 2: Identity Federation Model

Figure 3 shows the scenario with diverse people with diverse relationships with different IPs. When you add diverse and numerous types of devices — cell phones, tablets, laptops and so on — it even makes the case stronger as to why the current federated identity model is reaching its limits.

 

Figure 3: Diverse People and Devices

So if the Federated Identity model doesn’t work, what will? Figure 4 shows one school of thought were a single IP can somehow grow big enough and inclusive enough, it can manage all of the identity claims of all entities. This architecture is both frightening and poorly thought out. People and organizations need to have the freedom of choice of how their identities are managed and not be locked into an identity management silo of a single provider.

Figure 4: Omni Identity Provider

Figure 5 is another — simpler — graphic showing how a single organization could have federated relationships with multiple constituents. Again, this approach works to a point, but as soon as you consider the impact of the identity explosion brought on by — cloud computing, social computing, mobile computing, and the API economy — this approach simply won’t do the job.

Figure 5: Organization Federated to Many Constituents

Figure 6 then, shows the simplified notion of the IDMaaS architecture. Any number of organizations, constituents or entities can generate and consume claims through the service in the cloud.

Figure 6: Any Entity and Any Number of Entities

Of course Figure 6 doesn’t very effectively illustrate what the three black dots really mean. With the identity explosion we are talking about, the number of entities that are inevitable are several orders of magnitude bigger than anything we have even thought about up to this point.

We are in new territory, it is very unclear what is going to happen as a result all of this.

The fact that Microsoft seems to be acknowledging this fact and is working with vision to address the matter is highly encouraging.

We are not seeing this kind of vision — or anything close to it — from any other major vendor to date.
Caveats
The biggest problem I see here is Microsoft itself. It isn’t like Microsoft has the reputation of always taking the high road to enhance technology to the benefit of all. To the contrary, Microsoft has the reputation of pretending to take the high road with an “embrace and extend-like” position while executing an exacting and calculating “embrace and execute” practice. Microsoft has become the arrogant elephant to dance with that IBM once was. Microsoft’s past is going to be difficult to shed and it will be a significant effort to convince others that the elephant won’t trample on everyone when it gets the chance.

Figure 7: The New Microsoft?

(Source: Craig Burton, drawn on the iPhone with Autodesk SketchBook Pro)

So the tough questions are:

  • Can Microsoft really execute on such a brave direction?
  • Will Microsoft follow up on allowing true “Freedom of Choice” for the customer? (Think interoperability. i.e. IDMaaS from any vendor, not just MSFT)
  • Will the RESTful implementation be usable?
  • Can the technology transcend the limitations of Kerberos and LDAP as it moves Active Directory to the cloud?

 

Summary
My explanation is a simplified one, but if you study it a bit, you will start to see where Microsoft is going.

In short, the vision of an Identity Metasystem based on Identity Management as a Service is brilliant thinking.

The proof will be found in how Microsoft executes.

There is a lot to work out here to show if this can really work. But I believe it can happen. Microsoft is in a good position to garner the expertise to give us this first implementation so organizations and people can start to vet the idea and see if this can really fly.

I will be anxious to watch carefully at the progress of this direction.

I don't mind taking a few knocks from Craig, and don't think this would be the place to respond to them, even if I do think that the interoperable claims based identity technology we have been building and shipping for the last few years is the rocket fuel needed to “transcend the limitations of Kerberos and LDAP as we move Active Directory to the cloud” – one of his main concerns.

But why quibble?  Craig really gets what's important.  I like the fact that he takes the time to explain why Identity Management as a Service really is a big deal.  I suspect part of what he is saying is that it dwarfs the incremental changes we have seen over the last few years because it will impact every mainstream technology.

Craig's points about why infrastructure is hard are all golden, as is his wonderfully simple statement that “the current identity provider-centric world we live in now is broken and simply will not work for the future.”

As for the tough questions, execution can only be judged by looking at what is shipped and how it evolves over time.  I'd like to take up the more general, IdMaaS-related questions in upcoming posts.  John will be talking in his posts specifically about our RESTful implementation and providing readers with access so they can judge for themselves and give us feedback.  At a practical level, we will be making things available incrementally in cloud time, adding breadth and depth as we go on.  This whole aspect of cloud innovation makes it hugely exciting.

By the way, I love Craig's elephant – I only wish I could dance so well, metaphorically at least.  I also love his graphics: he improved and extended the amateur ones I used in my European Identity and Cloud Conference keynote.  So if it's OK with him, I'm going to pitch my own and go with his in my upcoming posts.  Thanks Craig.

 

Identity management before the cloud (part one)

Since identity is a fundamental requirement of computing infrastructure, organizations have been involved in digital identity management for decades.  Over the years, three models have emerged and co-existed.  Of course I'm tempted to skip the history and jump headfirst into what's new and fresh today.  But I think it is important to begin by reviewing the earlier models so we can get crisp about how the IdMaaS model differs from what has gone before. (Some day people who want to skip the previous models will be able to click here.)

Firewall Era Identity Model

Domain boundariesEnterprise identity technology evolved incrementally from mainframe days using the concept of administrative and security “domains”: collections of resources tightly integrated under a single, closed organizational administration.

To control access to networks, computers, applications and information stores, it was necessary to identify them and recognize their legitimate users – whether people or software services. This required registration systems – often called directories – through which human and non-human identity records could be created, retrieved, updated and deleted (CRUD). In the domain paradigm identity management was thought to be the CRUD and little more.

While closed administrative domains were simple in theory, business requirements drove enterprises to adopt an assortment of unrelated internal systems and applications. Most came with their own independent user directories. Enterprises ended up with hundreds of different systems that had to be administered independently and would soon diverge.

With the advent of network PCs, we began to see Network Operating System domains that were collections of PC's working in conjunction with servers.  Banyan‘s StreetTalk and Novell's Netware were both gamechanging products that introduced LAN directory coupled with identity management and authentication capabilities, but over time Active Directory achieved predominance as the administrative and security domain for PC users and applications. These products greatly simplified management of personal computers but the plethora of specialized business systems remained.  In fact some enterprises ended up with multiple Active Directories.

A category of Identity Management integration products arose as a response to these problems: a dizzying array of often brittle point products and tools that could only be deployed at high cost by skilled specialists. They generally had to be customized to the point of being one-off solutions that paradoxically made the legacy even harder for customers to unravel.

In retrospect the most striking characteristic of the domain based model is that each domain spoke with absolute authority.  It named things and asserted their attributes.  The machines, services and administrators that were part of the domain took its assertions as being unquestionable.  Trust for the domain was a condition of membership.  There was no need for the evaluation of assertions since they came from the domain and the domain was right by definition.

Another characteristic was that each domain created identifiers within a namespace it controlled and they  could be used to access the information about domain members and components by any entity the domain authorized.  Systems typically employed a single namespace, and services used the same identifiers that were associated with domain components and users at authentication time.

In other words, until domains began to collide, it was a pretty simple world.  Conversely, in todays interconnected and permeable world, most of the assumptions underlying the domain apply with growing caveats.   

Internet-facing Identity Model

The explosion of the Internet surrounded the closed enterprise security domains with outward-facing systems aimed at customers and suppliers.

Once Web usage went beyond public applications like PR and advertising, organizations discovered that to enhance relationships with individual customers – and ultimately do e-Business – they needed ways to register them over the web.   Customers and suppliers were seen as a different category of domain object, but the systems built for them still followed the domain model.  Anything the domain said about its customer or supplier was taken to be true by all the applications in it.

Consumer and supply chain identity management was most often customized on top of existing business databases that were completely independent from the directories of employees maintained inside the corporate firewall. 

This created problems in linking employees with customers. In the wake of mergers and acquisitions, companies struggled to deliver a unified experience to customers across multiple business units with diverse origins, and competition drove them to seek more unified identity and resource management services.

The Identity Management market thus expanded to include products that performed single sign-on and unified access control across a set of colliding domains, accompanied by large expenditures on hand-crafted integration projects.

Next:  Identity Management before the cloud – the Identity Ecosystem Model