I have a classical 3-tier app (Database, API & UI) running on Azure cloud. Now I want to extend this app and enable it for a different set of customer base. So for now I'm having users pertaining to Company A in the Database. I'm using Azure AD for Authentication and once Auth is successful via logging in, the users can call the necessary API's.
I now want to extend this set up to Company B. I already identified that I would not use the same Database to hold the data for Company B. So I will have a new database to accomodate all the data for Company B. I will use the same UI & the API to server both Company A and Company B.
Right now, I'm using Azure AD for creating JWT tokens that I validate in my API upon every API call. With this multi tenant set up, I now also have to identify from this Token which Company the API call belongs to such that I can connect to the appropriate database. I have been reading about Multi tenancy in Azure AD, but not sure if this is the right thing I should be doing. Any ideas on how this could be done?
When designing multi-tenant application, you have to choose from several patterns.
https://learn.microsoft.com/en-us/azure/sql-database/saas-tenancy-app-design-patterns
Depending on many features:
Tenant Isolation, Scalability requirements, development complexity, operational complexity and customizations. The biggest factors would be security and isolation.
From what you described , it seems you are in the multi-tenant app with database per tenant.
https://learn.microsoft.com/en-us/azure/sql-database/saas-tenancy-app-design-patterns#d-multi-tenant-app-with-database-per-tenant
I recommend reading up on B2B and B2C collaboration in Azure Active Directory.
https://learn.microsoft.com/en-us/azure/active-directory/b2b/compare-with-b2c
Generally, I don't think you are doing anything wrong.
Related
I'm using Microsoft Graph API to access data from a variety of tenants' ADs. This is with a multitenanted Azure app hosted in my Azure tenancy. Authentication is handled using application level tokens and the client credentials flow; customer admins authorize the collection of data for their tenancy using OAuth. A customer is asking whether it's possible for me to restrict access to my Azure app based on location, so that our app dispenses tokens only to clients who are inside our data center.
It seems to me that this is not going to work. Microsoft recently added the possibility of conditional access based on workload identities; but are pretty clear that this only works for single-tenant apps, where the same tenancy hosts both the enterprise application and the app registration:
https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/workload-identity
Note
Policy can be applied to single tenant service principals that have
been registered in your tenant. Third party SaaS and multi-tenanted
apps are out of scope. Managed identities are not covered by policy.
But, I am not an expert and may be working on incorrect assumptions. Can anyone confirm or disconfirm what I have posted here? Is there some way I can provide what the customer is asking for?
As mentioned in the document that it is applicable only to the single tenants, If you want this feature to be available for the mutlti tenants as well you can raise a feature request for same here: https://techcommunity.microsoft.com/t5/microsoft-365-developer-platform/idb-p/Microsoft365DeveloperPlatform
Users in Azure Active Directory Azure
App Services for WebSite and Services
I am creating a Web Site that a Manager would authenticate with using an Azure Active Directory account. That website would offer up sales data on the staff they manage.
The service that returns the sales data for staff member A will be being called on behalf of the manager.
My question is what is the correct way to flow the "identity" of the logged in manager through the calls to the various services.
Do I simply protect the services with a System Level authentication at the level of the website and pass the manager's user identifier as a parameter in the request?
OR
Do I try and flow the oauth identity onward to the services so that they are called in the security context of the manager? If using this approach how would I do that?
In my opinion, if the your business doesn't have a high security requirement, the first option is great. But if you want higher security, you can use second option.
For second option, you need to register an application in your azure ad for your app service. Follow steps on this page. And register another application in AD to represent client app by following these steps. Then go to your client app and grant permissions to allow the client-app to call the backend-app. After that, the manager need to get access token before request the api in your app server to return sales data.
This Azure sample shows exactly what we want to acheive with an ASpNet Core Web Site calling own AspNet Core Service secured with our Active Directooy organisation
I am having some issues getting it to work but this sampple is what I was hoping for from asking this qeuestion. FWIW here is the seperate question covering the specific issue I am having implementing the sample, Why Http 401 when calling AspNet Core API secured with AAD. Our WebApp, Web API and AD Org
It is straightforward to configure Azure App Service authentication for one of the following authentication sources: Azure AD (federation), Microsoft (local AD), Facebook (OAuth), Google (OAuth) or Twitter (OAuth). I have two questions:
Is is possible to allow more than one authentication sources from that list (hence with a Home Realm discovery)
Is it possible to add any arbitrary SAML 2.0 Identity Provider?
I don't see a way to do either one via the Portal, but perhaps are there other ways, such as via API?
Thanks!
Usually the most desirable option is as follows:
Your company UIs receive tokens issued only by Azure AD
Your company APIs receive tokens issued only by Azure AD
Users can authenticate multiple ways
Azure AD can federate to other identity providers
BEWARE OF COMPLEX SOLUTIONS
Any solution that returns multiple types of token to your UIs and APIs is usually bad. They will add a lot of complexity to your apps.
AZURE AD FEDERATION
The goal is for your Azure AD to manage complexity for your apps, and to return a consistent user id regardless of the login method.
There are definitely working SAML2P options - many companies use them for corporate sign in to Office etc
AZURE APP SERVICE
Not sure which category this fits into, but it's worth clarifying your goals before choosing the tech. SAML2P is a little complex but tends to be widely used in the corporate world.
As part of "new customer onboarding process", we are going to develop custom application using Azure AD Graph API for synchronizing 3rd party tenant active directory user and group data with in our application’s data store.
What azure container should be best fit to hold custom business logic above requirement?
What authentication is required to connect & query 3rd party tenant?
Azure AD Graph API or LDAP query which is efficient/best fit ?
How any user or and group data changes in 3rd party tenant active directory will be notified to my custom application in order to sync up our application’s data store? Is it possible in LDAP approach?
We are in investigation phase
What azure container should be best fit to hold custom business logic above requirement?
This is quite a broad question, and one I cannot answer definitely.
But Web Jobs or Durable Functions could work.
What authentication is required to connect & query 3rd party tenant?
If this is like any tenant who starts using your app, then you'd register a multi-tenant app in your AAD and require application permissions to Read all users' basic/full info from Microsoft Graph API.
You then need to provide a functionality to the 3rd party tenant admin to consent to those permissions.
This means you'd need to redirect them to login to your app, at which time they'll be asked for permissions.
The topic of consent alone is a bit complex, the documentation is here though: https://learn.microsoft.com/en-us/azure/active-directory/develop/consent-framework.
Your app can then use Client Credential authentication in the background to get an access token for MS Graph API and do the sync / register for change notifications.
Azure AD Graph API or LDAP query which is efficient/best fit ?
Neither, use Microsoft Graph API.
How any user or and group data changes in 3rd party tenant active directory will be notified to my custom application in order to sync up our application’s data store?
You can get change notifications: https://learn.microsoft.com/en-us/graph/api/resources/webhooks?view=graph-rest-1.0.
But you'll probably need to make a full sync as well so that all works in case you miss some updates.
The simplest solution is just a full sync that runs on a schedule.
It isn't fast or efficient but it is quite reliable.
Dear Microsoft Azure AD personnel, (and anyone else who has been down this road)
We are building a User Interface as a front-end to our back-end architecture in Azure, mainly comprised of Azure SQL databases, VM clusters, Azure Search indexes, and SFC's.
Users who will login to this UI will be both internal (company employees) and external (our clients). The internal users will log in to perform various functions for services we provide our clients. Our clients will log in to perform search queries on certain tables of our databases.
Where we are lost is in the area of trying to plan and execute our identity management architecture along the lines of permissions and policies.
For our internal users, we will have several different permissions profiles that need to be defined - for example, User 1 should be able to access and write information about client 1, but not client 2. User 2 should be able to access and write information about client 2 and client 3, but not client 1. That is just a simple example.
For our clients, thus far, we have set a up a B2C tenant to allow them to sign-up for access with their email address. While this part is simple and straight-forward, it seems the B2C functionality is rather limited in that there are only policies for signup/sign-in, password reset, and profile editing. We will eventually need to offer different levels of access permissions to our clients as well.
Here are my questions:
For our internal users, should we be using our domain Azure AD (B2E), or should we also use B2C for them so all users are under the B2C architecture?
Are these different kinds of permissions I've mentioned defined and set inside Active Directory settings, or coded into the Application?
Should we use B2C at all, given that we will need to give different permissions structures to different users within our clients? Should we be using B2E for our clients as well, even though they are customers and not internal users on our domain?
I've been reading Azure documentation and watching videos since end of last week and I'm still having trouble determining what's right for us for what we're trying to accomplish.
I am by no means an expert in Azure AD (either the most generic enterprise/domain, B2C, or B2B), but based on my reading and experiments:
1) You can funnel all users through AAD B2C, using AAD B2C custom policies to allow enterprise/domain AAD users to be connected to your AAD B2C directory; this means your application(s) only have to integrate with a single directory (AAD B2C);
2) None of the AAD flavors is really designed to do fine-grained permissions/authorization; you will probably need to handle this in your own code, or using some other feature/service.
Martin