I am currently developing an Azure Web App, which uses the Microsoft identity platform. Everything works fine as a single- and multi-tenant application. I only have one big problem, where I did not find any good solution, or at least best practices.
I would like the application to support multiple tenants. This means that I definitely need a multi-tenant application. Anyways, this allows ALL Microsoft users to access my Web App, which I highly do not want. The business plan is as follows: Businesses buy the subscription/product and then gain access to the application (initially manually).
At first I thought that there might be some sort of setting in Azure to manually white-/blacklist certain tenants directly in the portal. I did not find anything regarding this, but maybe I missed it.
My second thought is, that I have to implement the logic in the server directly. This should not be a problem, but are there already any existing resources you can use, regarding this? My idea was that after/before each redirect to a page, the server checks the database, if the tenant is allowed to visit the page. If not, a redirect to a "You are not allowed to visit this page!" page should happen.
Did I miss anything major here? I am 100% certain, that this is a somewhat common use-case and therefore am baffled that I did not find anything relevant regarding this.
Single-tenant applications can be accessed only by users who have an organizational account in the same AAD where the application is registered. Multi-tenant applications can on the other hand be accessed by anyone who has a valid organizational account.
The first time you try to authenticate to a multi-tenant application it isn't registered with your organization's AAD. You have to trigger the consent flow which will allow the user to login with their organizational account and grant the application the necessary permissions.
One way to solve your problem is by restricting access to tenants in Azure Active Directory. Check this document for detailed information.
Another way is by setting up sign-in for multi-tenant Azure Active Directory using custom policies in Azure Active Directory B2C. Check this document for more information.
Related
We have a simple scenario but technologies(or implementation) have made things bit complex -
We have Sitecore as CMS for client's main web site and for business functionality we have Dynamics 365 Portal and we are using Azure AD B2C as identity provider for both.
We have heavily customised B2C custom policy to cater specific requirements.
We are using same custom policy in Sitecore and in Dynamics 365 Portals so sign in individually and works perfect without any issues.
With regards to SSO, we have kept the configuration as OOTB as you can find it here.
Only 1 or 2 user journeys are absolutely perfect as good as seamless journeys. In specific journeys we need user to be logged in both ends to make it work (we can force user to go to sign in page, but it is not required on all the pages).
In order to understand how real and proper SSO should work in Azure AD B2C, I have no idea or experience to relate this process to. so I am looking for guidance and help here.
I found very good information in this about how B2C works in terms of signin and providing tokens process but it bit old question and things have changed a lot since then specifically UI and some of the operations.
Use the following docs when configuring sessions management for a custom policy. Session Behavior section is where you define which SSO behavior. Specifically:
<SingleSignOn Scope="Application" />
If you want your users to get SSO between all applications, then define this value as "Tenant". There are several useful scenarios in creating separation between sessions - such as a company that has multiple brands that do not want to conflict each other. Or a separation of experiences.
Follow the exact format and location to be placed in your policy or you will not get the desired result.
Another concept that is important is the understanding the session provider:
SSO session management has two parts. The first deals with the user's interactions directly with Azure AD B2C and the other deals with the user's interactions with external parties such as Facebook. Azure AD B2C does not override or bypass SSO sessions that might be held by external parties. Rather the route through Azure AD B2C to get to the external party is “remembered”, avoiding the need to reprompt the user to select their social or enterprise identity provider. The ultimate SSO decision remains with the external party.
Session providers are used to define maintain what goes into generating the session when your policy is being executed (inside the Identity Experience Framework). If marked incorrectly, this could lead to undesirable results such as wrong claims being sent, additional MFA prompts, parts of your policy not being maintained when ran or just general errors.
This is for those who are interested in how we achieved this -
Sitecore also does offer OOTB Azure AD B2C configuration however the supplier of Sitecore delivery side decided not to use OOTB configuration approach and hence it caused lot of issues. From what I have read about Sitecore configuration for Azure AD B2C it does work smoothly with B2C with careful configuration.
Work Around: We had to rely on external triggers(e.g. cookie) which will indicate and trigger that a user has signed on either sides and accordingly the sign in process on both side kicks off.
I'm hoping to use the Microsoft Identity Platform - Azure Active Directory - to manage authentication for my app.
I using the v2.0 endpoint.
I've registered my application in the new Application Registration Portal (apps.dev.microsoft.com), and it is now showing up in the main Azure portal under Azure Active Directory > App registrations
I need to restrict access to my application to certain organisations - I'm working on the assumption this means I need to allow access to a specific set of AD tenants.
In the application manifest, there's a signInAudience property, the options for which are AzureADMyOrg, AzureADMultipleOrgs and AzureADandPersonalMicrosoftAccount
AzureADMultipleOrgs sounds the closest to what I'm looking for, but so far it means anyone with an AD account can access my app.
I've come across documentation for an orgRestrictions property (https://github.com/microsoftgraph/microsoft-graph-docs/blob/master/api-reference/beta/resources/application.md) which sounds useful but it just says Reserved for future use
I assume this is a common use case e.g. only allow access to organisations that subscribe to your product, but I don't see a straightforward way to do it.
I assume this is a common use case e.g. only allow access to organisations that subscribe to your product, but I don't see a straightforward way to do it.
Yes it is, and most multi-tenant samples showcase this.
Currently there is no way to say that a given app should allow login from X and Y, so it'll have to allow all Azure AD tenants.
(though that is a feature that has been heavily requested)
Then after authentication, your app can check the tid claim.
You could for example check from a database if this tenant has a valid subscription.
If they don't, redirect them to an error page and don't log them in.
I am the primary developer on a multi-tenant SaaS web application hosted in Microsoft Azure. We use Azure AD for all authentication. Because our application holds personal information, we and our customers want a way to restrict access to specific users. We just need a simple yes/no restriction in place so only assigned users may access the application. We've considered Application Roles, but it seems like a lot of overhead when the only needed option is "authorized".
While researching this, I came across the following "User assignment required" property in Azure AD.
User assignment required property in Azure Portal
After some testing, I found that it functioned exactly as we need it to. The customer has full control over which users may access the application, and neither party has to configure Application Roles. The only downside is that this property is configured on the customer's end. Is there a way for me, as the developer, to require this setting? Or perhaps a way to enable this setting by default?
Clarification: The end-goal is minimal configuration done by the customer. If "User assignment required" can be enabled by the developers (before customer registration), that would be ideal.
Basically you cannot specify it in advance, it is up to the customer's administrator to set up the requirement.
This is their concern, not your application's concern.
One possible way would be to set appRoleAssignmentRequired on the created Service Principal to true via a Graph API call.
But that will require quite privileged access, with their admin logged in.
Service Principal entity reference
Get SP by app Id
We have a multi-tenant single page app (and backend) that uses Azure AD for authenticating users. We'd like do queries to customer's Azure AD for retrieving groups but make it an opt-in behavior for customers (tenants). The reasoning behind that is that not all customers necessary need the functionality and would rather not grant us access to their AAD unnecessarily.
Is there some way of implementing this with Azure AD?
I've been trying to test with different OAuth /authorize calls with resource IDs and scopes but mostly I end up with "AADSTS65001: The user or administrator has not consented to use the application with ID ''. Send an interactive authorization request for this user and resource." error. Configuring the web app or backend to require the permission would surely fix the error but that will also make the approval of it mandatory for all users of the app.
Is there a way of using the authorize/consent API to request access to a new application on-demand?
An ugly work-around that should work would be to have 2 client IDs and 2 backend IDs with different permissions but ADAL.js doesn't seem to be designed to work with multiple Client IDs (it's singleton, for starters). Also Application Permissions should of course work but I'm not sure how much of those are required to search for groups.
Is there a way of using the authorize/consent API to request access to
a new application on-demand?
Do take a look at Azure AD v2.0. With their incremental & dynamic consent model, it is possible to do so though I am not sure if this specific functionality (managing groups) is available there.
I had a discussion with Azure AD team member recently about this (as we are also facing the same problem) and he suggested that we take a look at this.
Essentially the way things work in Azure AD v2.0 is that you start with basic set of permissions (like sign in, read profile etc.). Then when some tenant need specific permission, you essentially ask them to grant those permissions to your application at that time only. What this means is that different users in your application have granted different permissions to your application.
If you are using MSAL, and looking for a way to dynamically change your scopes before authenticating, have a look at this: https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-angular/docs/v2-docs/configuration.md#msalguard---dynamic-auth-request
More here: https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-angular/docs/v2-docs/configuration.md#platformbrowserdynamic
I'm aware of the limitation of B2C that dictates that it doesn't support
Daemons/Server Side Apps applications authenticating with non-interaction.
https://azure.microsoft.com/en-gb/documentation/articles/active-directory-b2c-limitations/
In my case,
I have a user on my application whom is available to enter their details but i want complete control of the Journey, i don't want to have to redirect to https://login.microsoftonline.com etc... to acquire the token.
I know the B2C Azure portal allows you to provide a static HTML page as a template for the login page, but this isn't good enough for my scenario.
My guess is this isn't currently supported but eventually will be.
I think that is not possible due to the nature of the service. Full control of the pipeline is possible when you use the service that provides such capabilities out of the box. Here, it is more like that user is "isolated" from some of the boilerplate functionality which is the benefit sometimes.
If you need to have a full control, i think that you will need to use something like Windows Identity Foundation and federated authentication which may be customized.
The type of authentication you are asking for is the resource owner password credentials. Right now, it is in scoping and they said it will be released by summer 2017. Note: Supports only for local accounts, not any external providers like FB, Google etc..
For more details https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/13817784-add-support-for-resource-owner-password-credential
You can upvote and let the team work on it