I have been working a while trying to find out how to connect multiple tenants to the same Azure APP to access graph. I end up using ConfidentialClientApplication because I have a daemon service which can't ask for authentication all the time, so tenant admin grants permissions once to my Azure app and I able to access tenant's data with MS Graph API.
I need help understanding whats wrong with the following scenario:
Consider we have 2 tenants: tenant1, tenant2. Both granted permissions to my app. But this means tenant2 can access tenant1's data by specifying tenant1 authority like https://login.microsoftonline.com/tenant1 and email. How to overcome this situation security-wise, should I use one azure app per customer, may be some other MSAL authentication flow for daemon apps? Totally confused.
If your customers can control the authority your daemon app uses, it sounds like you cannot use the approach of a single app with app permissions to all customer tenants.
This approach can be used when you have a multi-tenant app with a background process that runs in your infrastructure that the customer cannot control.
Either your app needs to talk to infrastructure that only you control, which then uses the app permissions, or you need separated applications.
An application would need to be created as a single-tenant app in each customer's AAD.
Either they do it, you do it, or you provide a script to do it.
Then they can enter those credentials into your app's config and start using it.
Related
I've done some reading in regards to Azure AD, but I still can't wrap my head around it. The confusion might be there also because of how my company tries to standarize how a azure project should look like.
Imagine I have two things: SPA app (served by App Service) and API (on this App Service, ASP.NET). The approach that the company is suggesting is that both of those should have their App Registrations.
Now, I'd like the API to have access to Ms Graph. In order to do that, looking at other projects, I updated my AppRegistration to request for Ms Graph roles, Admin gave consent, and in API I used ConfidentialClient to reuse my Client Id/Secret to get token and then access MsGraph.
Why the hustle? Why not just use Managed Identity of my API and grant needed permissions using New-AzureAdServiceAppRoleAssignment?
Why do I need App Registration here? Do I need both? Should I access Ms Graph using my App Registration and confidential client in my API? How does my App Service relate to my App Registration in code?
Let's take a step back and define a few things that will make things easy to understand:
Your app service: this is just a compute environment, just as Azure Functions, Logic apps or VMs. This is where your code executes.
Azure AD App registration: this is an identity that you can use in your code to identify your service and get access to resources you need. The Azure AD app registration has several capabilities:
build an app in one tenant and used in multiple tenants (multi-tenant app)
consent framework, allowing you to request permissions and the owner to grant it
define roles and permissions, so that you can configure who is allowed to call your API
3-legged OAuth flows which allows you to act on behalf of the user
confidential client flows which allow the app to act on its own (like a service account)
Azure Managed Identities: this is also an identity that you can use to identify your service and get access to resources you need. It only has a subset of the capabilities of Azure AD app.
confidential client flow which allows the identity to act on its own (like a service account)
credentials managed for you by the platform
Depending on what you are trying to do, you can use one or the other identity: rarely if ever you will need both.
In your case, you need an identity to act on its own. So either app registration or managed identity will work. Your API may benefit from using an app registration if you want to define roles and permissions. The primary advantage of using an app registration in your scenario is that the consent model is simpler to use and understand. The disadvantage is that you need to manage credentials for the app. This pro/con is reversed when using a managed identity.
You don’t need both at a time. These are two ways to get the access of MS graph for your API. They are used for different purpose.
Managed Identity (Using System Identity)
· Use the Managed Identity if you don’t require your API to be authenticate from any provider.
· A managed identity from Azure Active Directory allows App Service to access resources through role-based access control (RBAC), without requiring app credentials
· It known as safe way to give your web app access to data is to use a system-assigned managed identity
· Currently, there's no option to assign any permissions(MS graph) through the Azure portal for Managed Identity
· When we do Manged Identity of any application its show only for Enterprise application.
Reference : Tutorial - Web app accesses Microsoft Graph as the app - Azure App Service | Microsoft Docs
App Registration.
· To set the authentication and authorization of your app from different provider its need your app registration id.
· It’s required to configure a service and get a token from the Microsoft identity platform endpoint that service can use to call Microsoft Graph under its own identity.
·In this using portal you can add permission (MS Graph) for your application.
Reference : https://learn.microsoft.com/en-us/graph/auth-v2-service
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
please, is here any way how to make relationship between applicaiton in Azure AD and User with client secret.
My use case. User ask for token with client secret(as deamon) and call my web api and a verify this token. Token is valid but there is no information about user who call it or who registered app. User gets token via API (https://learn.microsoft.com/en-gb/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow#get-a-token)
When user ask for token interactive everything is ok.
I tried to use a information about who created app, but Azure AD does not set it when user is administrator.
Is there any way how to use deamon which will be connected with some user?
Is there anywhere i can save this relationship in azure AD?
My idea, every user who wanted use my web api as deamon create his application and connect to mine web api, which use his app for verification. Relationship between app creator and user can be enough. but when i delete user and he has still client secret, he can access. I dont want to use his username and password because it will be saved on different computers and it is not save enough.
If you have more questions, dont hesitate to ask!
Thank you for any idea.
For scenarios, such as this one, your application should have an App Role with the allowedMemeberTypes having Application and as mentioned in the docs, this will show up as an application permission to other apps.
So the consumers of your API will have to add this application permission to their daemon app (which requires admin consent). This will trigger a flow internally that creates a Service Principal (like a user persona of the application) and adds that as a user to your application (you should be able to see it listed under Enterprise Applications > (Your API) > Users and Groups).
When you want to deny this daemon access to your API, you will just have to revoke the admin consent provided at first.
I believe you could even automate this process by using the Microsoft Graph APIs.
I would like to create a daemon app on Azure that would allow to access multiple personal Microsoft accounts (not in same tenant). My idea: I create a multi tenant app in my tenant. Each user that authorizes access to his personal account, should give explicit consent.
I feel like it's possible when I read the doc but I'm not able to do it.
What I currently did:
Create a V2 Multi Tenant app in Azure AD
Give Graph API: Files.Read.All and User.Read access on App permissions
Then I'm not sure how I should ask for the consent of users ?
And then how can I get a token for a particular user to have daemon access ? (without explicitly having to ask again his consent)
Thanks for the help!
Even if it is not really clear out of the documentation of Microsoft as first it seems it's possible, I have the impression that it's not possible: Daemon applications can work only in Azure AD tenants. It wouldn't make sense to build a daemon application that attempts to manipulate Microsoft personal accounts. If you're a line-of-business (LOB) app developer, you'll create your daemon app in your tenant. If you're an ISV, you might want to create a multitenant daemon application. Each tenant admin will need to provide consent. (https://learn.microsoft.com/bs-cyrl-ba/azure/active-directory/develop/scenario-daemon-overview)
We have an Azure resource app whose APIs we want to expose for access by a client app on Azure. The two apps are on different tenants. The users accessing the APIs (Office 365 account holders) are on different tenants.
The whole set up works when we manually provision a service principal on the tenant that is trying to authenticate from the client app against the resource app. By that I mean they are able to log in using their Office 365 account and are shown the consent screen.
If we do not provision a service principal on the AAD tenant of the user trying to authenticate, we get this error:
AADSTS65005 - The app needs access to a service <service> that your
organization org.onmicrosoft.com has not subscribed to or enabled. Contact
your IT Admin to review the configuration of your service subscriptions.
It is not feasible for us to provision a service principal on every tenant that is accessing our app (resource app). Is there something we are missing? Are we using the right flow?
You can find help for your scenario here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-devhowto-multi-tenant-overview#understanding-user-and-admin-consent. (Scroll down to Multiple tiers in multiple tenants)
In the case of an API built by an
organization other than Microsoft, the developer of the API needs to
provide a way for their customers to consent the application into
their customers' tenants.
The recommended design is for the 3rd party
developer to build the API such that it can also function as a web
client to implement sign-up:
Follow the earlier sections to ensure
the API implements the multi-tenant application registration/code
requirements
In addition to exposing the API's scopes/roles, ensure
the registration includes the "Sign in and read user profile" Azure AD
permission (provided by default)
Implement a sign-in/sign-up page in
the web client, following the admin consent guidance discussed earlier
Once the user consents to the application, the service principal and
consent delegation links are created in their tenant, and the native
application can get tokens for the API
Basically, all of the parts that your app needs must be present as service principals in the customer's tenant. This is a requirement of AAD.
The only way for that to happen is for an admin to go through consent for the API and app separately, since they are registered in different tenants.
If they were registered in the same tenant, you could use the knownClientApplications property in the manifest to allow consenting to both at the same time.
In my case, I am exposing my own API and trying to access this API from my other Application (Client Credentials mode), I removed the default permission on both of the app(consuming app and api app) - "Azure Active Directory Graph-> User. Read" since I thought I don't need that but that caused this problem "The app needs access to a service .... that your organization has not subscribed to or enabled. Contact your IT Admin to review the configuration of your service+subscriptions.
I got the clue from the answer of #juunas - point 2. Thx Juunas