Why does B2C "live" in its own Azure directory?
This seems to be the odd duck, no? Are there other Azure services this way? All of my other Azure resources live in the "default" directory.
It might help in understanding this by understanding the purpose of B2C. The idea here is to support a consumer facing application. For example, you might be building a consumer facing application and people all over the world might access it. You might want to outsource the security piece of that application to Azure AD.
Instead of integrating the application with your corporate Azure AD tenant, you can create a different AD directory, a B2C directory, that simply stores consumer identities. In this case, the B2C AD is completely separate from your corporate / main AD.
We all know that for one AAD tenant, it represents an organization. We can use AAD to manage users and resources for an organization. But for AAD B2C, it is just a service for authentication/authorization to all customers which relys application. It can integrate Soical accounts. AAD B2C cannot define those users belong to one organization.
However,AAD B2C still needs AAD to do authentication/authorization and manager users. In B2C, users are Local accounts or social accounts. In AAD, users are cloud accounts or on-premise synced accounts.
For example. If we use normal tenant also as a B2C tenant, the AAD authentication/authorization endpoint will be same. With this situation, we cannot distinguish the kind of users.It will result bad logic in product.
For distinguishing this two AAD, the B2C tenant must be separated.
Here is the clarify in official documentation:
Azure AD and Azure AD B2C are separate product offerings and cannot
coexist in the same tenant. An Azure AD tenant represents an
organization. An Azure AD B2C tenant represents a collection of
identities to be used with relying party applications. With custom
policies (in public preview), Azure AD B2C can federate to Azure AD
allowing authentication of employees in an organization.
Hope this helps!
Related
Our App is a public facing app. For sign up and sign in, we set up AD B2C as it provides an easy tool out of the box. Consequently, Azure has created a different tenant where all users will be managed.
We also have setup a Blockchain app, which can be done only in AD tenant (not in AD B2C). Now, we would like users in B2C to interact with the blockchain API. This cannot be done as only users in AD are allowed.
Is there a way to link users in B2C to AD? Other solution?
The documentation for Azure Active Directory B2C states ADConnect can’t be used to migrate users. I believe this is referring to the native store.
“No, Azure AD Connect is not designed to work with Azure AD B2C.”
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-faqs
But can I use ADConnect if I configure Azure Active Directory as an Identity Provider?
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-setup-oidc-azure-active-directory
If you setup sync to an Azure AD from on-prem AD with AAD Connect,
and then connect that AAD as an identity provider to B2C,
it will work.
Note you should use another Azure AD tenant for this, OT the one underneath the B2C tenant.
It also works quite nicely at least based on my short testing that if you have a single IdP in the sign-in policy, the B2C pages don't even show up.
Of course the first time, users will have to "sign up" to the B2C tenant with their AAD account.
Technically the sentence is correct that you can't migrate users to B2C with AAD Connect, but there is this roundabout way of doing it.
Technically the users are not migrated to B2C, but we migrate them to a place where they can be utilized from by B2C.
Is there any way to restrict the user login from two different devices?
Unfortunately, Azure AD B2C cannot do this.
I understand why do you need this. But I think it should be configured in your Application ,not Azure AD B2C. For example, you can let your Application get the users' deviceIDs and restrict them can login from one device.
Actually, Azure AD B2C can do cloud identity management, so it cannot collect more information from users. For the security and private policy, Azure AD B2C may not have very powerful features.
Hope this helps!
Before Azure AD B2C and Azure AD B2B come into the picture, usualy I added my applications to Azure AD of our tenancy and office 365 users could access the applications using their account (SSO).
I am not a guru so I need to see code and read about exact examples to understand the concepts.
Can I use B2C for SSO as I usually used Azure AD? otherwise how/when can I use B2C and B2B?
Thanks and appreciate all kind of advice.
Azure AD is a directory service with the goal of serving organisations and their needs for identity management in the cloud. You develop against Azure AD, you can secure your applications with it - their users in Azure AD tenants can use it.
Your application is targeted for a specific organisation or multiple organisations using Azure AD (Office 365).
Azure AD B2B is just a feature of Azure AD. It allows organisations to grant access to their applications and services for users from other tenants. From your app perspective nothing changes. It is still same Azure AD app. Azure AD B2B has an API which can be used to create flows for the invitation of users from another directory but it is not changing your app design, etc.
Azure AD B2C is another service built on the same technology but not the same in functionality as Azure AD. Azure AD B2C target is to build a directory for consumer applications where users can register with e-mail ID or social providers like Google, FB, MSA, known as Federation Gateway. The goal for Azure AD B2C is to allow organizations to manage single directory of customer identities shared among all applications i.e. single sign-on.
Azure AD B2C is not targeted at organisation users but consumers.
03.2021 Update: Microsoft has introduced a new solution which merges B2B and B2C - It is called "External Identities".
What is "External Identity":
It is a mechanism to allow you, to have external users, self-registration for them and control on their process, within your Azure AD (corp) tenants.
Why it is a merge between Azure AD B2C and Azure AD - those are external users, like in B2C, they can use their own username / e-mail (not a corp domain) and self-register, but within AAD Enterprise tenant. You can also extend authentication flows for External identities with calls to external systems similar like in AAD B2C.
Let's talk about scenario, application for schools:
Internal users -> Azure AD, covers internal applications, employees etc. in organization. User is in Azure AD
External users, like guest teachers from other school, partners -> Azure AD B2B, guest user in Azure AD
External users, but not associated with any organization, e.g parents who need an access to students grades in particular application -> External Identities, they can self-register, they exists within the context of specific app, you can call additional API to check, for example if they match the record in CRM during registration
External users, open to the internet, e.g. art contest for pupils -> Azure AD B2C. Anyone can register, students, teachers and employees can access it through Azure AD.
Pricing update: There is pricing update which affects Azure AD B2C and External Identities.
First - price is per monthly, active user (MAU). MAU means someone logged on at least once during the billing period (month).
Second - first 50k users in Azure AD B2C or external identities are Free. So first 50k users in a month, free - next are paid, so 60k active users within a month costs something like 16USD.
Simple:
Azure AD - apps for organisations and their corporate users
Azure AD B2C - apps for customers, like mobile apps, shopping portals etc.
For quick reference I've gathered this in blog post: https://www.predicagroup.com/blog/azure-ad-b2b-b2c-puzzled-out/
For update on External Identities and reference in video format, I've gathered it in this video: https://www.youtube.com/watch?v=E6S1yJKTB7c
Here is the 'official' doc comparing B2B and B2C
My organization has our own custom software solution hosted as a Web App in Azure. We are utilizing Azure AD for our authentication security. Some of our customers may have their own Office365 AD tenants, and so we take advantage of the B2B capabilities to invite these users to our apps and have some visibility of their accounts in our AD tenant (as external users).
We have one customer who would like for us to integrate with their Shibboleth service. We would like to support using their Shibboleth service as the identity provider for their users, and allow their MFA settings to be honored. We don't want to force them to create new identities in AD. What would be needed on our side to support this sort of trusted federation with Shibboleth? Ideally we'd like to be able to see their identities surfaced as external users in our AD tenant so that we're using a single security model for our app.
Azure AD's only equivalent for "trust" or "federation" with others is, as you've been doing, via B2B. Currently there is no B2B-like equivalent that supports direct federation to non-Azure AD IdPs.
However it is possible to set up Azure AD so that it leverages a third party IdP as its primary auth mechanism.
You should be able combine these two approaches to achieve what you want.
Have your customer sign-up for Azure AD
Have your customer configure Shibboleth as per the steps in this article: https://msdn.microsoft.com/en-us/library/azure/jj205456.aspx
Add your customer's users to your Azure AD via B2B as you've been doing for everyone else.