Welcome back to part 2 of our FastTrack for ISV Series - Identity on Azure.
In this next part of our session, we're going to cover Managing external identities.
Azure provides a couple of ways to manage external identities and I will use this section to highlight those two concepts
and talk about when you should use what.
As well as some identity concerns an ISV might have when setting up a SaaS application. If you
If you did not see part 1 of this video I encourage you to go back and watch for an over view of identity on Azure
If you would like to skip the overview and jump into managing external identities then keep on watching.
So theres two main ways to manage external identities. One is Azure AD B2B-Business to Business
and the other is Azure AD B2C Business to Client
Azure AD B2B is made for collaborating using your own applications. So let's say your organization
is working with an external vendor or partner or you’ve hired a third party agency to work on your application and help
you build it out. Youre going to invite that third party consulting company into your
Azure AD tenant so that they can collaborate with you on your same source code repository or Azure DevOps
or whatever azure resources youre using within your Azure AD Tenant.
A simple invitation and redemption process lets partners
use their own credentials to access your company's resources. Developers can use Azure
AD business-to-business APIs to customize the invitation process or write applications like
self-service sign-up portals. The other way you can manage external identities on Azure is using
Azure B2C. B2C is used for managing access to custom developed applications. So if youre
creating a SaaS app, youre going to use B2C for that. So in this case your customers aren't actually
invited to your azure AD tenant . These users are managed and maintained in a separate azure active directory.
Your customers use their preferred social, enterprise, or local account identities to get single sign-on access
to your applications and APIs. As an ISV one of the most important decision you need to make with
your application is how you want to manage external identities. But first you need to understand the concept of
who and what data your managing. So if youre managing your own corporation's data, youre going
to be using Azure AD single tenancy and B2B. So you control all of the access policies,
so policies around MFA , conditional access, licensing what features may be
available and which guests are invited into your Azure AD. If you're
If you're managing your customers data - then you want to use either multi tenancy active directory if youre only
managing Azure AD identities Or B2C if youre managing Azure AD and social identity providers
like FB or google. With Azure AD B2C, you can completely customize and control how
customers sign up, sign in, and manage their profiles when using your applications.
In this case your customer actually controls access. Youre providing a single pane of glass for your
customer to log in and your application is going to do a redirect to the customers identity provider to authenticate them.
So if your customer is logging in with corp identity, your app will do a redirect and then use whatever protocols that are in
place for your customer Corp identity system. Then you'll get the token back of who that customer is and then off you go.
In this final section I want to talk a little bit about multitenant application patterns.
A tenant is a group of users. In a SaaS application, the tenant is a subscriber or customer of the application.
Multitenancy is an architecture where multiple tenants share the same physical instance of the app.
Although tenants share physical resources (such as VMs or storage), each tenant gets its
own logical instance of the app. There are a couple of ways we can approach this for managing multitenancy and
single tenancy in applications. So lets talk through what are the different options. The first approach is
is building multitenancy with B2C. If you offer a SaaS application to many organizations,
you can configure your application to accept sign-ons from any Azure Active Directory (Azure AD) tenant
We've talked a little bit about you, partner.onmicrosoft.com is going to allow other
tenants which are all the different companies your application serves access to your application. This would be granted
through the common AAD endpoint which is what’s going to authenticate them and allow them access to your apps.
One thing to keep in mind is, before an application can be made multi-tenant, Azure AD
requires the App ID URI of the application to be globally unique. The App ID
URI is one of the ways an application is identified in protocol messages. For a single-tenant
application, it is sufficient for the App ID URI to be unique within that tenant. For a multi-tenant
application, it must be globally unique so Azure AD can find the application across all tenants.
Global uniqueness is enforced by requiring the App ID URI to have a host name that matches a verified
domain of the Azure AD tenant. I also want to draw some attention to some other scenarios
For example with single tenant for B2B. In this case, what you're doing is inviting customers into your tenant
and granting them guest access. To do this you send an invitation email to the guest, the invitation includes
a link the guest can redeem to get access to your app or portal. The invitation email is just
one of the ways guests can get access to your resources. As an alternative, you can add guests to your directory and give
them a direct link to the portal or app you want to share. Regardless of the method they use, guests are guided through
a first-time consent process. This process ensures that your guests agree to privacy terms and accept any terms
of use you've set up. While this reduces complexity, there can still be some concerns
since you will have guest users in your tenant. You would need to make sure that they have limited access to resources
and have a limit to how long they can access the resources they do. With B2B collaboration, you can securely
share your company's applications and services with guest users from any other organization, while maintaining
control over your own corporate data. The other case is Single tenant with azure AD.
In this case, everyone within your Azure AD tenant is able to access the resources but people from other companies won't be able
to access. You'll get this sign in error if you try to log in when youre out of the directory.
All user and guest accounts in your directory can use your application or API. You would use this option
if your target audience is internal to your organization. For this last section I want to cover
identity in SaaS Applications and some considerations you may have when you build it out. So when youre building out
a new SaaS identity there are a few concerns you may have that are very different then when you may have been deploying your solution
into your customers tenant. The first main concern here is around tenant identity. Tenant identity
is the blending of both my core identity (user name and password ) along with my tenant.
So think in a traditional web app, you're only concerned with my user name and password identity. Now I'm adding more
Now I'm adding my core identity (user/pass) along with my tenant. The other concern is managing multiple identities.
When youre creating a SaaS app you potentially want to offer that app to different types of people who will be coming into
your app with different types of identities. You might be serving your application to a number of corporate networks
or enterprise identities that you would want to sign in via single sign on with their corp identity. You may want to allow your app
access to social identities like FB google and so on. The last thing would be if you don’t have any
of those things we'd be logging in with a local provider so using just username and password that’s created for me.
The next concern is tenant isolation. So once I log in , typically when youre creating a SaaS application
you're sharing resources like storage SQL etc and theyre being shared between tenants
So how would you isolate those resources using their identity. One other concern is onboarding new
tenants and making sure you can register there, and then finally being able to add new users to that tenant once its been created.
So to address those concerns theres some key actions you’d want to take; the first being create App Registrations
So every application (be it web or native) and API that is being secured must be
registered in Azure AD B2C. If an app has both a web and native version of iOS
and Android, you can register them as one application in Azure AD B2C with the same client ID.
The second thing you'd want to do is choose user flows for most scenarios. The Identity Experience Framework
of Azure AD B2C is the core strength of the service. Policies fully describe identity
experiences such as sign-up, sign-in, or profile editing. To help you set up the most common identity tasks,
the Azure AD B2C portal includes predefined, configurable policies called user flows
With user flows, you can create great user experiences in minutes, with just a few clicks. Finally, you'd
want to leverage our library of proven custom policy patterns. You can find samples for
several enhanced Azure AD B2C customer identity and access management (CIAM) user journeys.
Now lets look and see what setting up your identity looks like in the portal. So this is an azure ad B2C
tenant. As you can see it looks a lot like my traditional Azure AD tenant but theres a couple of different things that stand out.
The first being is the presence of the social identity providers.
You can configure Azure AD B2C to allow users to sign in to your application with credentials from external
social or enterprise identity providers (IdP). With external identity provider
federation, you can offer your consumers the ability to sign in with their existing social or enterprise accounts,
without having to create a new account just for your application. Once you select one of the external identity providers
they're taken (redirected) to the selected provider's website to complete the sign in process.
After the user successfully signs in, they're returned to Azure AD B2C for authentication
of the account in your application.
In addition to configuring social identity providers you can also configure Azure AD itself using what is
called the identity experience framework. It allows you to really customize their experience of your log in
You can even add Azure AD providers. so lets see how to do that.
The way you do that is by creating custom policies which we mentioned very briefly earlier. Custom policies
are XML files that define the login experience or the type of claims etc as part of your login
experience like site policy like password reset. Now lets see how one might
add some custom policies. So to start we have a ton of starter files that you can use and leverage
that encapsulate all the things the user will do as part of their login like password reset or profile edit.
So what ive done is Ive actually gone out and went to Github where you can pull these files
and now I can actually start editing. So these files are sort of additives. You have a base file,
you have an extension files and then on top of that I can add policies for sign up or sign in
for editing customer profile or for doing password reset.
Typically you don’t want to do too much with the base file, but what I can do here is I can go into my extensions
file and I can define different claims providers. You can see here I have FB claims
provider defined, local account provider defined. And now I'm going to define an Azure AD profile
or claims provider. When I define this , essentially what I'm doing is I'm saying here is how I want this
user to connect I'm going to create an app registration as previously shown that will connect to this
client ID. Also with my client ID I'm going to define a secret which will be stored in a secure
store and then after that I will define the claims I want to get back.
I want to get the user ID, the customer's name and display name
and I can define other output claims and then I can do things like transforming the output claims
This will allow you to do things like manipulate the claims values, validate claims, or set default values
for a set of output claims. So I can set this all up and once its all defined
I would go to the sign up XML file and then add this as an additional policy profile that the user can use
for logging in. Once that is done, I would upload these policies. And you actually want to upload
these policies in reverse order so I uploaded my base then my extension then my signup or sign in.
Now that I have that done, one of the things I can do is quickly test this out. The way you
can do that is you have an endpoint, or in this case an app registration that I'm connected to
saying that once you obtain the access token I'm going to reply with the URL. So I'm going to go ahead and
try this out and copy this end point to test out the flow. And the idea here is that
you're going to set up all your sign in / sign up flows, your password resets and your're going to test them in this
B2C client and then once youre comfortable you can begin to incorporate them into your actual application
that's made in React , .NET , Java etc
So I'm going to open an incognito window just to make sure that I've done this correctly.
And you can see once I logged in, it gives me the option to either sign in with an existing account
or do multitenant AD and ive also configured Facebook.
So this would walk the user through signing in and I can log in with my MS account
or any other Azure AD account and that will give me the login credentials and once that happens I would be provided with
a JWT token and that JWT token would provide all my claims and things that can be used by application
All this combined together gives you a really good approach to creating identity with your SaaS
application using B2C. So we've talked about a lot today, as customers move
their identity systems to the cloud, there’s increasing demand from them that the applications
they use integrate with their existing identity system. Azure AD provides a tremendous
opportunity for developers to integrate into this ecosystem and quickly build SaaS Applications.
As an ISV you always want to design with identity in mind. Visit our docs to learn more about how you can
set up Identity quickly for your applications. I hope you are able to learn a little bit about Identity on Azure