As I understood, in the latest Abp Framework, a user can link to only one tenant right?
I wonder how to customize ABP so that a user can link to multiple tenants?
I have a scenario as below:
The admin create a new account for a user and assign him to 2 or more organizations (multiple tenants).
He can use this account to login to multiple tenants and can access data corresponding to each tenant
Many thanks!
Related
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
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/
I'm building a small CRM SPA application using Angular 2 (front-end) and Web API 2 as back-end with ASP.Net Identity and OWIN for token based authentication.
I've got ASPNetUsers, ASPNetRoles and I'm able to grant access to users based on roles but I don't understand how to grant access to a certain user. For example:
a user logs-in with role 'Manager' and loads a page that makes a request for some resource that belongs to this Manager. This request reaches an API controller. How this controller method will know whether to grant access to this user or not? Is this user the owner of a ..say some Client. /api/Client/1
Is there a simple way of finding out (with EntityFramework) up the hierarchy of relations if a Client (or another resource) belongs to a current ASPNetUser or not?
This is how I plan the db relations will look like:
In the end the goal is to give user access to resources that he owns, and restrict other users to load them - sort of a personal account.
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
In my application, a User is assigned multiple Roles, and a Role is assigned(granted) multiple Permissions.
So in my code, I never check against a Role, but always against a fine grained Permission.
Here is described why I think Permissions based access is better than Role based:
https://softwareengineering.stackexchange.com/a/299732
Within Azure AD, I can assign roles to a user.
But I see no way of creating Permissions and associate them to Roles, so I guess this part must stay in my app ?
Then how should I link the Azure Application Roles to my app's Permissions ?
My assumption is I need to build an UI for doing this, using the Graph API to retrieve the list of roles defined in Azure for the application.
If that is the case, then I don't see much benefits using the built-in roles function in Azure vs keeping the role definition in my app...
Am I missing something ?
The key point of using Azure AD claims is to keep users information in the Active Directory rather than in the application.
In you case, you need to create permissions mapped to roles in your application.
Then theses roles can be mapped to Azure AD AppRoles or Groups.
I suggest you not to map directly users to roles.
If you deals with Group, you don't need to add/remove users to/from applications: Roles and permissions are inherited from groups users belong to.
Mapping directly to Groups
For the moment, it would be my preferred scenario. Users are assigned to groups and your customs roles are mapped to these groups.
When you create a new user, you just need to add it in some groups and there is no action required in your application (same things when you delete the user).
If you are not afraid of preview (and have an Azure AD Premium license), Azure Ad provides a way to dynamically assign users to group.
Just keep in mind that for the moment nested group memberships aren't currently supported.
So if a Group A is in Group B and Group B has some permissions in your application, Users from Group A will not have permission inherited from Group B.
Mapping Groups to application roles
This option seems to be an overkill because it requires one more step: Map Azure Ad Group to Azure Application Roles and Map theses roles to your custom roles.
You need to implement all this logic using the AAD Graph API and your UI will be more complex.
Only reason to use this option in your scenario is if you have a large directory with lots of groups and applications : If a user is in more than 200 groups so the Jwt token returned by the Azure AD will not contain the groups and you will have to query one more time the Azure AD to get the user groups (see).
In this scenario, it could make sense to map groups to application roles because when a user authenticates to an application, Azure Ad will always provides you the roles of the users (or the roles of the group that the user belong to)
you can find interesting code sample here:
active-directory-dotnet-graphapi-console.
At this point in time, Azure Active Directory application roles are meant primarily for the scenario where each user can only have one role and thise roles are mapped to a simple authorization model.
While it is technically possible to support multiple roles per user, that can only be managed via the Graph API and would require you to build a UI for your user admin / users to manage.
As you've noted, your scenario is more complex than this with multiple roles per user and multiple (potentially customizeable and overlapping) set of permissions.
Given these two points, your approach of implementing all of the authorization yourself is a sound one.
Check out this article which outlines in more details the authorization scenarios Azure AD is best suited for:
https://azure.microsoft.com/en-us/documentation/articles/guidance-multitenant-identity-app-roles/