Problematic user identity case is something you’re highly likely to experience if you are working with a big customer-centered organization. I’ve prepared for you a case study from our experience in dealing with problematic user identities. Here’s how we built a first class loyalty app for a huge retail chain.
An IT perspective on building a loyalty app for a large enterprise
Imagine for a moment that you are leading the IT department for a retail chain organization. You are sitting in a meeting; the sales and marketing heads are with you. Suggestions are flying all over the place.
And then someone has an idea – let’s build an online loyalty app for our customers.
Competitors did it! We should too.
Now, Marketing & Sales, of course, think this is a piece of cake.
You – as an IT professional, on the other hand, see the real complexity behind this task…
What are the risks here?
- First, you will need to allow the customer to interact with a brand across a variety of channels.
- Second, this app will need to be flexible enough to put all the company brands on the same setup.
- And on the top of that, you must ensure data security, so your company won’t make headlines as the “scariest data breach of the year!”.
This was a case I was working on with a company running a retail chain. What’s cool nowadays is that you don’t need to build much from scratch.
You just need to pick the right services and design how they cooperate with each other.
Let’s see how we did it.
Why Azure AD B2C
There are multiple services available in IdaaS space. There is growing demand for it, and the market is responding with products.
In our case, we have chosen Azure Active Directory B2C (AAD B2C) as the solution.
It is consumer focused, IdaaS offered from Microsoft.
If you are familiar with Azure AD, you’ll notice that Azure Active Directory B2C it is built on the same underlying technology for scale and security, but its focus is on CONSUMER IDENTITY.
Key facts on AAD B2C:
- Service and all other information is stored in the Azure platform.
- Handles all the authentication processes and security aspects related to it.
- Handles social media provider logins (Facebook, Google, Microsoft, Yahoo, LinkedIn) as well as local accounts. For complex cases, you can also configure it to use other identity providers (like Salesforce or your corporate Azure AD for your employee access).
- Supports OpenID Connect and OAuth 2.0 for application and APIs protection.
- Allows own branding.
- Supports user self-service for password resets and user profile editing.
- Delivers integration with multi-factor authentication (an important element regarding security and upcoming regulations under the GDPR within the European Union!)
- It can integrate with additional data sources and services to build a single consumer identity view.
Already using Azure AD and puzzled with differences between versions? We have it covered for you in another article on the blog. Check here.
Let’s look into the process of how we set it up.
Step #1: Solution architecture
Every journey starts somewhere – in our case, the first step was to build the right application architecture. It had to support the current application need and provide an identity handling service for all new applications going forward.
Our choice was to use Azure AD B2C as a service and trusted identity provider.
Azure AD B2C is provided as a service. You don’t have to deploy it on your own, just start a service tenant, and you are ready to go.
The Web and mobile applications can integrate with it, using a simple API model and a set of libraries.
It is based on OpenID Connect and OAuth (but it can handle more protocols like SAML). Developers will not have a problem with getting the right samples and SDK’s for specific platforms. In this link, you will find a guide on how to start with your own application and AAD B2C.
A user coming to the web application is redirected to Azure AD B2C for authentication – via social media identity or local identity. In more advanced scenarios we can also use external identity providers. Using this capability, we can allow your employees to access these apps using their corporate accounts.
Permitted authentication methods and the user journey in the process are controlled through policies – you can build multiple rules here for what is permitted in which application.
In this video, you can see how solution components interact with each other from an architectural point of view.
Identity service takes care of the user registration process, if they come here for the first time – it gathers required consents and profile information.
If you are more curious about the architecture models for apps in the organization, you can also check out my White Paper where I present a detailed overview of different architectural models.
Step #2: Identity pipeline configuration
Wait – what if we have the users’ data already?
It’s highly likely that you’ve collected your user information in the past as part of some campaign or from one of the many applications built previously.
Will they have to register again?
The good news is that we can handle this! Azure AD B2C delivers a processing engine for the identity pipeline – Identity Experience Engine.
Azure AD B2C is using policies configured within the service to let you control the user journey through the sign-up and sign-in process.
You are in control of other elements like profile editing and password reset policies as well.
The first policy element you will discover with this service is the configuration of identity providers.
You can assign different providers (like Google, Facebook, Amazon, Microsoft – the list continues) for different policies.
Effectively this controls how users get authenticated and how their data are processed before it reaches the application.
In this video, I show you how you can configure and enable applications with a new identity provider through policies configuration.
These are basic operations. But it might get more complex in real use cases. This is where advanced policies step in.
Using Azure AD B2C policies you can pull user information from your existing consumer data system. You can match it, process it and issue information for the application.
You can do some advanced things as well. Going back to our example of existing user data – your policies can be configured to do just-in-time data migration from an existing data source to Azure AD B2C in the instant a user first signs-in to your application.
Do you need to step up the authentication process when a user wants to perform some sensitive information? No problem!
Add an additional 2-factor authentication before the user can do this through policy configuration.
Step #3: It’s all about APIs
Right, so we now have the user signed-in and authenticated in our application. What’s next?
The application needs to call an API to execute actions!
Azure AD B2C is built to support the OAuth 2.0 authorization framework. Once a user is authenticated in the application, the app can call the API to obtain data and perform business functions.
You can’t allow anyone to call your APIs. It wouldn’t be wise on the Internet. We need proper authorization.
To provide it, the application can requests an access token to a specific API from the service.
The API is registered with the service as well and can receive and validate tokens issued from Azure AD B2C.
At the service level, we can control which application can call which API and what OAuth scopes this application can use.
On the screenshot below you can see a new addition to Azure AD B2C functionality – ability to control APIs scopes (in OAuth 2.0 terms) which can be called by an application.
Azure AD B2C functionality – a new addition
Access tokens issued for this application will contain only the scopes granted for a given API at the service level. This is another access control layer in the service.
What if an application requires additional data about the user?
This is a common need: To store and provide some specific information about a user profile.
How can we collect it?
Again service policies come into play. When a user signs-up to the service, we can guide the user through a journey to capture additional pieces of data, mobile phone, consent to send newsletters and so on. Don’t worry, users are still allowed to change this through their profile settings.
All this information is stored in a service directory.
How can the application access it?
It can pull it from the service using a Graph API – REST interface exposing access to directory data stored in Azure AD B2C.
Using a Graph API is easy and intuitive for developers. If you want to try it there are plenty of examples on how to do this. Here you have examples and code snippets provided by Microsoft on how an app can interact with Azure AD B2C data through a Graph API.
Don’t worry. It’s not like everyone can query this information. Access to the Graph API is secured with the same security model. So it’s locked down tight.
Where can you use Azure AD B2C?
This example is about a retail company.
But of course, it can be used in many other cases.
Business cases we have worked with where Azure AD B2C was used:
- Manufacturing companies – an app so their customers can access and handle service and telemetry data
- Logistics companies – security services for its multiple brands to handle a single consumer identity across all applications
- Educational organizations – a security model to handle access to applications for teachers, students, and their parents
The list goes on.
Azure AD B2C is also used by government organizations at a national or local state level to enable its citizens to access digital services.
If you are in the local government area, this might be the missing piece to start a digital revolution.
Benefits of Azure AD B2C versus building your own solution
Why not build this service on your own? Your development team can probably pull off some solution or find examples on the web on how to do this with your own code.
True. But, in the end, it’s all about customer data and security – in this day and age, this can’t be taken lightly.
To address this issue, we have used a cloud service where its main goal is to protect your customer identity. AAD B2C built on top of the Azure platform uses its scale and security to protect your consumer identity information.
Key benefits from the IT perspective:
- You don’t have to deal with the security of identity data on your own. It is delivered to you as a service.
- You don’t have to deal with complex protocols and changing services. Things change! A good example is a recent change in Google authentication mechanisms handled by Azure AD B2C team. Using this service, you don’t have to track it on your own. It will be handled by a platform and your apps will not be affected.
- User self-service or strong authentication requirements – it’s there! Instead of building flows for self-service – configure it with policies and complete it with your UI designs. Additional authentication required – it is there as part of the service.
Key benefits elements from a business perspective:
- Time to deliver. Development of a similar service internally would be a long project for the organization.
- Single point of the consumer relationship expressed through identity. Need a new application or program to be created for your customer? You don’t need to force them to register. If you have their identity already, they can use it right away. Across multiple brands and applications.
- Building user profiles connected to users on-line identity. Single point of identity handling in Azure AD B2C allows you to build processes to link a user identity to an existing consumer profile.
That’s not all, folks
Use cases in Consumer Identity is a broad topic and we can’t explore it all in a single blog post.
I’ve presented the basics of the service – its use cases, benefits and the general architecture of the service and applications based on it.
But it is not limited to these elements. There is room for it to be much more advanced and address multiple scenarios.
You can use the same pattern in your industry, regardless if it’s retail, sales, manufacturing or delivering utility services.
The same service can be applied in different ways to address specific requirements or user application flow.
We will be covering case studies of our projects and solution patterns of what we’ve learned on practical projects delivered to our clients.