I am using Custom Policies on Azure B2C.
When I want to run the Custom Policy I can choose the application which I want to use with the policy. I saw that I'm not only able to use my applications from Azure B2C, I can use the applications from the App Registration section.
What is the differences. I've been able to signup and sign in users with both types of applications.
Thanks in advance!
The two sets of apps are completely independent of each other.
You should not be able to see any of the Azure AD B2C apps in the Application Registration in Azure Active directory.Also, the apps in the Application Registration should not be visible in the B2C .
In your issue , I assume that you should have add two apps in the two places.
What is the differences.
Application in Azure AD B2C :To build an application that accepts consumer sign-up and sign-in, you first need to register the application with an Azure Active Directory B2C tenant.
Application Registration in Azure AD: This creates an Application ID for the application, and enables it to receive tokens. In order to get a client ID and secret from Azure, you have to register the app and provide some basic information about it, including what resources your app wants to access, and what permissions it needs.
Depending on your scenario, you could register an application in both portals, and use the right one depending on the request you need to make.
The apps that are registered through each different location (Azure Active AD versus Azure AD B2C) are given credentials that are valid for any policy, including custom policies you have uploaded.
The end result is the same: you have an application that is registered with and can access the policy regardless of how that app/policy was created.
Related
Is it possible to configure msal to work with two different apps simultaneously? Or perhaps is it possible to have two instances running in parallel on the same Single Page Application SPA?
Specifically, I have a business app that is accessed by both B2C users and Corporate users. The business prefers that the Corporate users be able to log into the app without the need to create an additional B2C account (and using a federated B2C sign-in type). This would mean that I need an app in the B2C tenant and the Corporate tenant, and my single page application app would be protected by either app for any given user.
In other words, if you follow this link:
https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial#chapter-1-sign-in-a-user-to-your-application
it gives instructions for how to sign in with Azure AD, and how to sign in with Azure AD B2C. But how would I go about doing both at the same time?
I'm new to Azure AD B2C so I'm not fully certain of its capabilities. Either way, I'm trying to limit the access to one of my registered applications to users from the same AD B2C tenant (single-tenant scenario). The only way I was able to do this was through the App registrations (Preview), the Legacy Application registration doesn't seem to support this.
Once I set the single-tenant option, the application starts to appear under the Owned Applications tab on the App registrations (Preview) blade but I cannot make use of it. Whenever I try to run a default or custom flow I get this error:
The provided application with ID 'XXXXXX-XXX-XXXX-XXXX-XXXXXX' is not
valid against this service. Please use an application created via the
B2C portal and try again.
I also tried to set the multi-tenant scenario (AzureADMultipleOrgs) but I still get the same error. The only way I can make this work is by using the AzureADandPersonalMicrosoftAccount which leaves the app open to everyone and that's not what I need.
Am I missing an extra configuration or is this still not supported?
Thanks!
You need to use the B2C specific Application Registration option for it to be compatible with Azure AD B2C User Flows or Custom Policies. If you then need to further restrict the user base who should be able to login to the application, then you would need to implement some RBAC, see this sample:https://github.com/azure-ad-b2c/samples/tree/master/policies/relying-party-rbac
In AAD B2C, the Application Role assignment and Application Assignment is not honored, these are Azure AD concepts that are not respected by Azure AD B2C auth policies.
I'm exploring options I have when it comes to implementing user authentication and authorization in Angular app with ASP.NET Core 3.1 backend that will be deployed to Azure AppService.
Only selected, invited users will be allowed to use application. There will be no "Create account" page accessible to everyone. There is a possibility that subset of those users will be our company users so leveraging their Active Directory identity and allowing SSO would be great. Application will be multi-tenant. Multi factor authentication might be needed for selected tenants/users (based on role for example). We don't want to allow logging in with 3rd party Identity Providers like FB, Google and so on.
Based on my explorations on I have 2 (4?) options.
ASP.NET Core Identity - simple, builtin, well known. But probably won't allow me to to implement SSO and users will need another login/pass. I'm not sure if it supports inviting users (out of the box) or is this something I would need to implement myself. Same with password resets. It allows me to add custom properties to stored user entity (TenantId) to allow me to implement multitenancy, but I need to deploy SQL Server database and manage it myself.
Azure AD (B2B, B2C) - this is new to me. How I understand it is that with Azure AD Connect I could synchronize users between AD and Azure AD and this would allow me to implement SSO for our company users. Only selected OU's could be synchronized and based on groups in AD they could be assigned different roles in our app. Then assigning roles is responsibility of people which are already managing those users in AD. If person is released and their account is removed/locked in AD they lose access to our app. If they're removed from specific group they lose access to our app. And probably all our company users are already in Azure AD - I see myself and my colleagues in it when I use my work e-mail to login to Azure portal. When it comes to supporting users which are not in our AD I tested that I can add "Guest users". At first I thought this is something I would need Azure AD B2C for but looks like it's not the case. Then what is Azure B2B and B2C for? In this case I don't need to manage SQL database and have user managment for free. Both on AD and Azure Portal site. I don't know if I can add custom properties to users (TenantId).
Which one of those options is better? Maybe there are other options?
Azure AD B2B is indeed the way to go for your requirements.
B2C is required when you would like to open up your application to external users while allowing them to login using social providers.
You can read more about the differences between Azure AD B2B and B2C.
Summary: How do I make a multi tenant app available to other Azure AD tenants?
Details:
I am writing a C# ASP.NET library using which I want to create subscriptions and register for change notifications.
I am using Microsoft Graph API v1.0 for this operation.
I followed this documentation to obtain the access token for a service account.
The first step listed in the documentation requires us to register the app on Azure AD Portal
Since I am building this app for multiple customers, I want this to be a multi tenant app. I followed this reference to register a multi tenant application, but I have a query as to how to make this app discover-able by other tenants ?
Do I need to publish it to be able to achieve this? If yes, can anyone please direct me towards any article which tells how to do that ?
Do I need to publish it to be able to achieve this?
No, you don't. For a multi-tenant application, the initial registration for the application lives in the Azure AD tenant used by the developer. When a user from a different tenant signs in to the application for the first time, Azure AD asks them to consent to the permissions requested by the application. If they consent, then a representation of the application called a service principal is created in the user’s tenant.
Do you mean under Enterprise applications blade of any tenant or the
one where it was created ?
It will exist in any tenant once a user from that tenant signs in to the application.
Lets say I set up and create a new Azure Account and Subscription. Azure automatically creates me an Azure AD called "somedomain.onmicrosoft.com".
Later I deploy REST API and Angular SPA app to Azure. Since I'm using Azure AD for authentication and authorization on both of the applications I register them on my Azure AD, under the domain "somedomain.onmicrosoft.com".
Everything works fine, however after some time I realize that I want to allow access to my services/apps to other organizations. After doing some research I realize that what I want to achieve is multi-tenancy.
In order to register a new tenant I do the following:
Go to Azure portal.
On the left blade menu click on "Create a resource" and search for "Azure Active Directory".
Create a new directory called "tenant-1.onmicrosoft.com".
Next, I update my registered apps (on "somedomain.onmicrosoft.com") according to this documentation - enabling multi tenancy and common endpoint.
After all of this, both users from AD "somedomain.onmicrosoft.com" and "tenant-1.onmicrosoft.com" should be able to authenticate and access my services.
Question
Is this the correct way of achieving and implementing multi tenancy?
You don't need to create a new Azure AD tenant (xyz.onmicrosoft.com). Just register the application in the existing tenant or mark the existing application as multi-tenant. Then, existing other AAD tenants will be able to signup to use your app without doing further registrations. You will need to modify your app code to accept tokens from other tenants, e.g. enter link description here This link points to a regular .NET web app, not SPA. You will need to translate it to your SPA environment.
I'm not sure of your high level use case but one thing to note about the AAD multi-tenant approach. You are assuming that person signing in has an Azure AD tenant, for example through Office365.
If they don't have an Azure AD then they won't be able to sign in.
You 'could' create an AAD for each new tenant and create a user account in there.
They would have the bob#mydomain.onmicrosoft.com address and could add their own domain later.
That way they can then take advantage of all the enterprise features of AzureAD.
It might be a use case, but I think you would need an AAD per tenant and I'm not sure of the limits or if this is best practice.
You can also look at B2C if you want social logins/other OpenIDConnect.