I am reading this docs that talks about security for a multi tenant application. https://learn.microsoft.com/en-us/azure/architecture/multitenant-identity/.
Let's say that my application is Tailspin. At least 2 companies, Contoso and Fabrikam, decide to use my application.
Those are my questions
Do I need to create a tenant for each customer that decide to start using my service?
Let's say Fabrikam already use a provider other than Azure Active Directory. If Fabrikam wants to use Tailspin, am I going force them to create a tenant?
EDIT
This short video shows how to start using Slack.
The first person to join Slack will enter all the information to create the space.
After that, that person will enter emails, inviting people to join the organization in Slack.
What I have noticed is that, they invitees don't need to belong to an organization [tenant] as they can have gmail, yahoo, etc. Yet, when user is logged in a space, he/she only sees what's in user's space.
I don't know how slack works, but if you have to implement something similar using Azure Active Directory as Identity provider:
Are you going to create a tenant for each customer [you said I shouldn't do that]
Should I create a security group for each customer that join so that its members can be part of that group?
Thanks for helping
You shouldn’t create a separate tenant for these companies. if in case those companies are hosted on different Identity provider. You can federate those Companies identity provider with your application IDP, and you will be accessing the application from their company’s identity itself.
Note: Your application should have capabilities to Federate with other IDP.
You can refer this document how to Microsoft federate with other IDP.
Note: For multi-Tenant, tenants share physical resources (such as VMs or storage), each tenant gets its own logical instance of the app.
For Single Tenant Architecture where each tenant has a dedicated physical instance
Related
I'm adding an external identity provider, Azure multi-tenant, as a login option. I have local accounts right now and they know nothing about Azure AD users.
I want to create an Azure Enterprise App that other tenants can use to set up SSO using OpenID Connect. Also I want the app to support User Provisioning by setting up a SCIM API.
I can't really find any documents on how to handle linking Azure AD users with the existing accounts in my IDP. I've seen examples where users can login using their local account, authenticate with Azure, and then their local account is updated to have the Azure AD User ID. This approach still seems pretty manual. Another thought was to have a step in the login journey, where if no local account has the Azure AD User ID then find a local account with the same email. I don't like this approach either since the emails might not always match. Is there an approach where an admin can automatically link all accounts with a sync or upload?
SYSTEMS
First it's worth clarifying roles:
Role
Details
Authorization Server (AS)
Your UIs and APIs receive tokens from this. It is where accounts and linked accounts are stored. It is where you use SCIM to update account records. It is where you apply account linking logic.
Identity Provider (IDP)
There can be multiple of these. When your apps call the AS it manages connections to them, and exchanges IDP tokens for AS tokens that are returned to apps. It is not usual to use SCIM against an IDP.
You are using IdentityServer as the AS so your UIs and APIs will continue to use IdentityServer tokens and remain simple. Meanwhile Azure AD will become an alternative IDP. So on the data side of things your architecture is in a good place.
AUTHENTICATION ACTIONS
I would aim to solve your problems via custom authentication actions, and to design this in a vendor agnostic way. Not all providers support these concepts, but IdentityServer has some pretty good extensibility features, so hopefully it has what you need.
A bit of code, configuration and technical investigations in IdentityServer feel like the correct direction, with no complexity added to your applications. I will describe techniques in terms of Curity (where I work), but the same principles can apply to any system.
USERNAME AUTHENTICATOR
A great way to deal with user specific differences is to make the initial screen prompt only for an email. See this example for how that looks. Later, when authentication has completed, you could set a cookie so that this screen is not shown on subsequent logins.
Then, before asking for credentials, apply some scripted logic, eg to look up existing account attributes, and decide how the user should authenticate. You might decide to route unknown users to Azure AD or do something based on business partner email suffixes.
DATA UPDATES
Something simple that might work in advance of adding Azure AD support is to assign all users a Tenant ID, and perhaps existing users get a Tenant ID of 1. Only those users are allowed to sign in with Identity Server - all others have to use Azure AD.
SCRIPTED LOGIC AND ACCOUNT LINKING
For a worked example of how this looks, see this Account Linking with Facebook tutorial. In this example the objective is to update the main account with a new linked account. This account linking doc may give you some additional ideas for your scenario. It should be possible to run custom logic before triggering authentication or once your have the Azure IDP attributes.
INVOLVE THE USER IF NEEDED
It may also be useful to present a custom screen to ask the user if they have an existing account when they first login via Azure AD. If not then an Azure AD login can create the primary account in IdentityServer data in addition to a linked account.
USERS AND PARTNERS
How users onboard is interesting, and discussed in this detailed article. I always start by getting a feel for the type of assets involved:
Type
Description
Personal Assets
You allow any user to sign up and they only have access to their own assets
Corporate Assets
Users are provisioned by an administrator, eg a banker is granted access to financial data according to business rules
In your case it feels like users are from the second category, so to enable a user to fully sign up you need data from the partner, either fed in manually or by getting them to call your API, before you can assign the user the correct tenant ID. This might eventually result in TenantID=23, but there is nothing to stop you initially allowing users to onboard and placing them in a default TenantID=0 bucket.
Ultimately this all comes down to data, claims and API authorization. Eg APIs could return certain data to TenantID=0 users but only return privileged data to users whose tenant ID has been asserted by an administrator. Not sure if these thoughts of mine match your scenario but hopefully they provide a useful hint or two.
SUMMARY
Reliable account linking is tricky, but it should be solvable via the building blocks of the Authorization Server, using the above techniques. The end result should be deterministic user data, with no duplicate users.
I am revamping an existing product, it has multi tenancy with separate database for each tenant. Now we need a single API to authenticate user without the information of tenant, as that is common login portal. What is the best approach for this problem ?
There are below given approaches
Case 1 Use a shared collection of tables that contain some data about the tenant's, their users etc.
In this case you will have a scalable admin service (can be a microservice) that talks to this database and can authenticate the users, tenants
Case 2 If the application is on large corporates and uses user's email address in the company domain's (as like in AD), steps are below.
you get the email address,
identify the domain
choose the tenant based on the identified domain
resolve the connection string based on the tenant
identify the database based on the identified tenant
Route to the DB and do the authentication
Case 3 when there are user's that can work in multiple tenants (like financial auditors), the idea of having a global users table is a good option. I get myself authenticated, then choose my tenant based on my mapping. Get into the tenant, do the tasks.
You can read more on this in my blog post https://dsaravanan.wordpress.com/2021/05/02/user-authentication-schemes-in-a-multi-tenant-saas-application/
In our organization, we have been inviting guest users to our AAD Tenant to successfully share resources with our B2B partners. However, we have a fear that there may be some business users that have been oversharing with individuals (e.g. xxx#gmail.com accounts or Business accounts we don't approve of).
We would like to better monitor these scenarios, and I've been able to determine a user's source via the Azure Portal:
Here, we can easily see that this particular user is coming from an External Azure Active Directory.
Is there a Microsoft Graph API or Azure AD API where I can get this information, so we can write some automation around this? Also, is there a way to determine which tenant this user is homed in? I have played around with the Users endpoint a bit, but don't see this information...maybe there is a different endpoint or permissions scope that I need?
Thanks for any assistance!
You cannot get tenant information of a guest user, but we can handle users by domain the user belongs to. you can allow or block invitations to B2B users from specific organizations .Please refer to this document.
Is there a way to prevent users from logging into their own AAD tenants? For example, allow login to contoso.onmicrosoft.com but not fabrikam.onmicrosoft.com.
My customer has a highly-controlled Azure environment where they are running some servers and PaaS/SaaS applications. Users connect to those servers are use a variety of Azure services and some SaaS (primary concern is PowerBI). They’re concerned that a user could login with a non-company account (wahid#hotmail.com) and then upload sensitive data their own PowerBI workspace.
You cannot prevent a user who has already been in the tenant to login to that AAD tenant, except deleting the user from that tenant.
If one account was created/invited to one tenant, the user just can login to that tenant.
For the scenario you described, I suggest you could revoke the Product license for those users. If you don't assign product license to the user, the user cannot use that App or cannot see that app in My Apps panel. For other SaaS/PaaS app(Web App), you may use user assignment to allow specific users to access the App.
For others: Daniel answered this for me. Short answer, this isn't easy, you would need to inspect the response body for the tenant ID (or name) and then block it. This would also lead to a poor user experience but that's all we can do today.
Yes, you have a few options.
Option 1: Single tenant apps
If you have the ability to create apps in the tenant you want to accept users from, you can mark your app as available to only this tenant (the field is called availableToOtherTenants). This will notify the token service to only authorize access from users in the tenant the app was created in.
Option 2: Multi-tenant app w/ token validation
The other option is to mark your app as multi-tenant (same field as above, just set to true) and implement logic in your app to validate the user's tenant from which the token was issued.
In this scenario, you will need to have some kind of web service that can safely validate access tokens (.NET code sample on this). To check the tenant the user's account belongs to, you'll need to validate the iss field. It'll look something like this,
"iss": "https://sts.windows.net/7fe81447-da57-4385-becb-6de57f21477e/"
in which the GUID represents the tenant ID. This allows your web API to have an allow or deny list based off tenant IDs.
More help
Here's an excellent blog post on token validation.
Azure AD Developer Docs
.NET Web API Code Sample
I'm using passport-azure-ad library to authenticate people into our app. We are using v2.0 endpoint. I have created multiple applications in Microsoft app registration portal. And have a lot of redirect url's because we have a lot of different environment apps. It was registered under my Microsoft employee account. Now I need to transfer ownership to another developer. How can I do it? Do I need to recreate all this apps in another account? I assume that this will create a new app id's and thus will ask for permissions for all users again. Is there a way to transfer ownership and not recreate all apps again?
Assuming you created your applications using your Azure Active Directory account (like your Microsoft Employee Account) you will have access to an "Owners" field where you can add new owners to the application which are in the same tenant as you.
If you are trying to transfer an application to a user from a different Tenant or using an MSA account, that is not currently supported, but something that is being considered for the future.
If you need to create a new application id, you will not be able to transfer the consent that you had from the first app over to this second one. That is just not really possible nor something we would look to support due to the security implications.