Azure AD multitenant permissions

7
votes

I have an Azure webapp that's managing it's users via Azure AD. I want the users to be able to register in my Azure AD directory to create an account (self-service), so I gave the app read-write access to the directory and setup a page using the Graph API to create the users.

Until here, everything is great. But the problem I have now is that I want to enable multi tenancy, so users of external AD directories can login to my app. This works, but I need to login as an administrator for the account because it also asks read-write access to their directory.

Is there a way to fix this? I only want read-write access to my directory to be able to create user accounts. I don't want to ask permission to touch their directory because, most probably, they wouldn't trust my app.

Thanks.

3
c#azureasp.net-mvc-5azure-active-directory
The short answer is no, you cannot. Azure has ways of integrating AD 1 with AD 2, but that is with 2 specific domains, not with "everything out there." But, you can use another AD as a 3rd party authenticator and still create a local user that you have admin over. – Dave Alperovich

3 Answers

2
votes

I found a quick and dirty solution: Add another app to the Active Directory. This app should be single tenant and have only permission to read and write the active directory. We can the use this app's credentials to access the Graph API and the other app's credentials to authenticate users.

I wait to see if someone has a better solution for this scenario...

0
votes

sorry for the late response here. In general, an operation to create objects in a directory (like users) requires admin permissions. Also it looks like the web app you are creating uses app-only permissions, which definitely requires admin consent. In the multi-tenant case, the admin of the consenting tenant must be the one to consent to this type of app - only someone in this role really has the authority to grant consent for this level of access.

Hope the helps,

0
votes

No need to use a secondary app in lieu of the authentication role - - there may be some peculiar side effects on the authenticating user anyway such as extraneous / incomplete logging, role inconsistencies, and missing system / internal references.

What are you using for login credentials for your app (TenantID etc.)? AD is very strict in credential management, so I would go back to the app structure.

At the query level, you could make all tables entirely separate per tenant with no shared table data and include a multitenant identifier column so no one can sql inject if you were sure to include the multitenant identifier as an explicit variable.

Then in an entity model, you could inherit a multitenant interface for everyone which referred back to the tenant identifiers (as a part of EF).

This way the burden is isolated to OAuth or other libraries on top of that to take care of the third-party authentication.