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.
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...
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,
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.
Related
I need to programmatically create an app in Azure AD and programmatically assign it permissions for Graph APIs. Somehow I am unable to find any good info on this. Please let me know if there is any good example of this.
I am able to create a basic app but not sure how to assign permissions to it.
I have a few basic queries:
Can we create an app and assign permissions at the same time? Or we need to first create app and then assign permissions?
How can I get a repository of all the possible permissions? Is there any way I can get a readable form of permissions and also its GUID representation?
Any C# example of this would be much appreciated.
PFB answer to your queries :
Can we create an app and assign permissions at the same time? Or we need to first create app and then assign permissions?
--> Yes you can create an app and assign permissions are the same time.
How can I get a repository of all the possible permissions? Is there any way I can get a readable form of permissions and also its GUID representation?
--> Here is the link for all the possible permissions :https://learn.microsoft.com/en-us/graph/permissions-reference
You can use Microsoft Graph explorer to execute queries and get the GUID representation.
Here is the link : https://developer.microsoft.com/en-us/graph/graph-explorer
You must first register an application in the Azure portal (or you must have an application first), and then grant the application permission or delegate permission to call MS graph api to create other applications, here is a detailed explanation Description.
Next, you can create other applications based on this application using C# code + MS graph api, and grant permissions to other applications (this is a separate operation, of course, you can also create an application and assign permissions at the same time).
At first you have to register your application in the Azure Active Directory.
Go to Azure Portal and navigate to the Azure AD -> App Registrations and create a new App.
In the Apps administration view, go to API-Permissions and click on "Add a permission". Now you can see all the available permissions you can grant to you application.
For some permissions (indicated by an orange warning sign) you have to grant admin consent afterwards.
After you have done those steps and you configured the redirect URLs (also in the Azure portal), you can access the data you have permissions from your application.
Note: You will also have to implement an authorization flow to make use of Microsoft Graph. You can find additional information here Microsoft Graph Authentication
I'm not a C# programmer so forgive the ignorance, but I'm trying to create a program that will use the Graph API to do simple AzureAD commands, such as listing users, groups, etc. All articles that I've read on how to do this says the app first needs to be registered within AzureAD in order to do this, but I'd like this program to not be tied to that tenant. It'd prefer to just have a user authenticate to their tenant and use that access token to access Azure instead. I'd love any resources or where to begin. I tried to follow this article https://www.c-sharpcorner.com/article/write-your-first-program-using-microsoft-graph-sdk/ but it didn't work.
The correct approach is to register the app in your tenant as a multi-tenant app.
https://learn.microsoft.com/en-us/azure/active-directory/develop/single-and-multi-tenant-apps
This will allow the users to login with their tenant.
Your app can define the permissions it requires, which the other tenant users must consent to.
If you want to know Azure AD information, the tenant must be provided.
You can get the tenants for your account by calling
GET https://management.azure.com/tenants?api-version=2019-06-01
Reference:
https://learn.microsoft.com/en-us/rest/api/resources/tenants/list
I have enabled multi tenant access to my app in azure portal and now i'm able to access my app from other active directory users.I mean multi tenant access is working.
I enabled multi tenant access to my app like as shown in image:
But now i need to restrict some user from other tenants.
I tried so many articles but i didn't get correct result
I followed this article but here i didn't get how to add users to the Tenant restrictions
in this url
Any answer appreciated
Thanks in Advance......!
AAD Enables you, as an Administrator of a Tenant, to control which applications users in your tenant are able to access.
However, it does not enable you, as a Multi-Tenant App Developer, to control what kinds of tenants or users can authenticate to your app. Instead, you must build that logic into your application, using details from the Graph API to learn about the logged in user, which tenant they are from, what groups they are a part of, etc...
Microsoft Graph Overview
// How to get different user / meeting room calendar events?
We are trying with the graph REST API to get calendar events of another user (shared calendar to the authenticated user) or a meeting room (should be an Active Directory user with shared calendar to all users within the organization).
We still get "Forbidden" response.
We can successfully get the user(himself) authenticated calendar events.
We can also get user details of the authenticated user and even of another user (user authenticated as John.Doe#company.com and can get user details of elise#doe.company.com) but we cannot get details of the meeting room user even though it should be a normal user in our AD.
We tried to setup all delegated and even app permission scopes, nothing helped.
Example:
var endpoint = "https://graph.microsoft.com/v1.0/users/"+userId+"/calendarView";
Is there a way to retrieve this information?
The problem is that your token does not have the correct scope. To be able to access shared calendars, you need the Calendars.Read.Shared (or Calendars.ReadWrite.Shared). How you get that scope into your token depends on where you registered the app (which answers your first question!)
Does it matter where or how the application was registered?
Yes, this matters. Both methods will work, but where you register affects how you request authorization and tokens. Also, apps registered in Azure Management Portal can only authenticate Office 365 users, not Outlook.com users. More on this in #2.
Does it matter what authentication URL we use?
Yes! The URL you use is directly related to which place you registered your app. I'm going to break this down below.
App scope permissions vs delegated scope permissions - does it matter which ones we set up in the application? Will our desired functionality work with delegated permissions?
Yes it matters. App permissions are granted to the app, and for Outlook APIs, these are global to the entire organization. So if you grant an app Mail.Read, it can read mail for all users in the org. The app acts as itself, and does not authenticate a user. Because of this, the auth method requires a certificate instead of a client secret. This method is meant for daemon-type apps. You most likely want delegate permissions since you want to authenticate users and then give them access to just those other mailboxes/calendars they are allowed to view.
Do AD permissions somehow influence the permissions user has in the application?
Well yes, in the sense that if you include a .Shared scope in your permissions, what the user has access to is set by what other users have shared with them (and this ties back to AD).
How do I add a shared scope
As I said above, this matters on how you registered your app.
Azure Management Portal
Apps registered in the Azure Management Portal use the "v1" version of Azure's OAuth2 implementation. Under this model, you have to specify the permissions for your app "up front" on the app registration itself. To add a shared permission, you have to modify the app registration in the portal. The permissions are shown in the portal as "Read user and shared calendars" (for Calendars.Read.Shared) and "Read and write user and shared calendars" (for Calendars.ReadWrite.Shared).
If your app is registered here, then you MUST use the v1 auth and token endpoints:
https://login.microsoftonline.com/common/oauth2/authorize
https://login.microsoftonline.com/common/oauth2/token
Additionally, under the v1 scheme, if you add new scopes to your app registration, you MUST have the user's reconsent. Otherwise, the next time they sign in to your app, they will just get the same permissions they had before. To do this, when sending the users to the authorize endpoint, add a prompt=consent parameter to the authorize URL.
Application Registration Portal
Apps registered here use the v2 Azure implementation and gain a few benefits. First, you can authenticate Microsoft accounts (Outlook.com) as well as Office 365 users. Second, adding scopes doesn't require modifying your app registration. And last, you don't have to manually reconsent users, the auth endpoint will detect the change and prompt for you.
Apps registered here use the v2 auth and token endpoints:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token
Scopes are specified in the scope URL parameter in the auth endpoint. So to add the shared scopes, you would just replace your existing Calendars.Read and/or Calendars.ReadWrite with the .Shared equivalent.
I currently have an app which using Active Directory for authentication. In other words, the IIS virtual directory is setup Active Directory authentication and I do no have to deal with it at all. If you are on the domain, you can get in.
Some customers now also want to add a feature where they can log in using a standard userid/password combo. The scenario being a contractor coming in for a few days with their laptop and need access to the app. There is no point of creating an Active Directory account for such a person.
Is this possible in an ASP.NET app? How would I go about it?
If you converted your app to use Forms Authentication, then you could configure 2 membership providers; one to authenticate against active directory, and the other could use the standard SqlMembershipProvider. This second provider is the one you would create your temporary accounts in.
In regards to authenticating against multiple providers, this is quite straight-forward. This article describes the process.
If you convert the application to use Forms Authentication, you can then process the login method to authenticate off of either Active Directory, or your own internal user database, depending on whatever criteria you expect. There are several articles out there on how to write your own code to perform a simple authentication against Active Directory.
I'd say you probably want your own Authentication Provider as discussed in this article. You'd build the validation logic to auth against the right store depending on your criteria.