"Azure Active Directory B2C helps us bring the stadium closer to our 450 million fans around the globe with simplified registration and login through social accounts like Facebook, or traditional username/passwords login. We're able to provide a seamless experience across mobile applications on any platform. By using Azure Active Directory B2C we were able to build a fully customized login page without having to build custom code. Additionally, with a Microsoft solution in place, we alleviated all our concerns about security, data breaches, and scalability ."
Rafael de los Santos, Head of Digital, Real Madrid
Carl Zeiss, an international leader in the fields of optics and optoelectronics, use Azure Active Directory B2C to power their customer software download portal:"Azure Active Directory B2C helped us bring our customer software download portal online within weeks instead of months. Support, scalability, and easy to handle software convinced us B2C was the right choice for this critical project. "
Fabian Peschel, Carl Zeiss Industrial Metrology
Azure AD B2B Collaboration is a new set of capabilities in Azure AD that enable secure collaborate between business-to-business partners. These new capabilities make it easy for organizations to create advanced trust relationships between Azure AD tenants so they can easily share business applications across companies without the hassle of managing additional directories or the overhead of managing partner identities. With 6 million organizations already ready using Azure AD, chances are good that your partner organization already has a AAD tenant, so you can start collaborating instantly. But even if they don't, Azure AD's B2B capabilities make it easy for you to send them an automated invitation which will get them up and running with Azure AD in a matter of minutes. Kodak Alaris, a company that is passionate about using technology to transform organizations and improve people's lives across the planet, uses Azure AD B2B collaboration to provide access to shared resources to all their partners:"We needed to quickly and cost effectively stand up new IT infrastructure including extranet applications for thousands of business partners. Azure AD B2B provides a simple and secure way for partners, large and small, to use their own credentials to access Kodak Alaris systems. The Azure AD team has been an incredible partner in our re-creation of a more agile and cost-effective hybrid cloud IT infrastructure."
Steven C. Braunschweiger, Chief Enterprise Architect, Kodak Alaris
These new B2B Collaboration capabilities can be used with Azure AD Free, Azure AD Basic and Azure AD Premium. To walk you through Azure AD B2C, I've asked Stuart Kwan, the Principal Program Managers in our team responsible for the service to write up a deep dive blog post. You'll find it immediately below. Additionally, Arvind Suthar, the Principal Program Manager responsible for our new B2B capabilities has also written a deep dive post on our new B2B Collaboration capabilities which I hope you take a moment to read as well. We're incredibly pumped to make these services available and we're looking forward to receiving any feedback or suggestions you have! Best Regards, Alex Simons (Twitter: @Alex_A_Simons ) Director of Program Management Microsoft Identity Division ------------------------------------ Hi everyone! It's me, Stuart Kwan. As you've all experienced, there are a lot of places on the Internet where you sign in as a consumer. Your bank, your child's school, online shopping, online games, on the web or your phone or your PC, the list goes on. Today, developers who build the identity management function of these apps face growing challenges around cost, scalability, and security: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.
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.
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!).You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.