Menu
I'm currently developing a multitenant Angular SPA application that connects to multiple webAPI's in the backend and uses AzureAD authentication where each AD represents a tenant.
Azure documentation on multitenancy points to an example applicaiton called Tailpsin.Surveys which I was able to run after following the steps on the page. That application differs from my scenario as it is a WebApp no an SPA.
In this webApp, during OpenId middlreware setup, an implementation of OpenIdConnectEvents is passed.
That implementation overrides TokenValidated method and blocks tenants that hadn't gone through signup before.
That's what I'm trying to achieve in in my application, but would that mean that each and every WebAPI should always check for issuer claim on token to validate the tenant?
That seems like something repetitive and could turn into a performance issue, I believe.
Is there any configuration in Azure or some other ways of restricting access to your application to a set of defined tenants?
975
Select the application you want to configure to require assignment. Use the filters at the top of the window to search for a specific application. On the application's Overview page, under Manage, select Properties. Locate the setting User assignment required? and set it to Yes.
You can enable Azure AD Multi-Factor Authentication to prompt users and groups for additional verification during sign-in. For more granular controls, you can use Conditional Access policies to define events or applications that require MFA.
Click on the Menu and select Azure Active Directory. Click in the menu on User settings. Click under Administration portal > Restrict access to Azure AD administration portal on Yes. Click Save.
To my knowledge, there is no such setting in Azure Active Directory. The options around 'tenancy' are multi-tenant or single-tenant. Multi-tenant means that technically all tenants could get an access token for your service.
For your specific scenario, I believe you would want your service to keep a whitelist of tenants which are allowed to call your API, and check that the token has the correct issuer or tid claim. You mention that you think this check might be a performance issue, but you are already checking every token that the aud claim is correct, and that the token is signed by Azure AD, and checking the scope/role claims in the token for permissions, so checking an additional claim should not really add significant overhead.
185
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
