I am developing an application that integrates with other business' Azure accounts. My application needs read access to the Azure Monitor service in our customers' Azure accounts. What is the best way to authenticate?
After reading, here's the current solution I came up with:
Have a customer create an App registration in their account. After creating the app registration, they assign the Monitoring Reader role to the application they created. The customer then will navigate back to the App registration and create a Client Secret. The customer then provides my service the client ID, tenant ID, and a Client Secret. My service will use those to authenticate with Azure and call Azure Monitor.
Is this the recommended way to authenticate with Azure as a 3rd party?
I am not sure if it the best way, but indeed it is a feasible way. This way named client credentials flow, you need to use this way to request the access token, then use the token to call azure rest api, e.g. Alert Rules - Get.
When you request the token, you need to specify the resource with https://management.azure.com/, also, you should note v1.0 endpoint is different with v2.0, v2.0 uses scope not resource, for difference details see this link. So you should choose the correct one depends on which version app your customer created.
Besides, correct some of your understanding of azure ad tenant and azure subscription. They are not called Azure account, the Azure monitor is a service in the subscription, the subscription locates in the tenant. The AD app(app registration) also locates in the tenant. You can understand the AD app is higher than the subscription, it is not in the subscription.
Related
We aim to collect data from the Azure Management APIs. These APIs provide information on the resources we have running in Azure, the consumed budget, etc (example). Following our design choices, we prefer to exclusively use Azure Data Factory to make the HTTP requests and store the data into our data lakes. This is fairly obvious, using the REST linked service. However, we struggle to correctly set up the OAuth2 authentication dance with this method.
Our first idea was to store the token and the refresh token within the Azure Key Vault. A series of HTTP requests within the pipeline would then test whether the token is still valid or otherwise use the refresh token to get a new token. The downside to this approach is that the token within the Azure Key Vault is never updated, when needed, and that the logic becomes more complex.
Alternatively, we were trying to set up the authorization through combination of a registered app and service principal to our Azure AD account. The REST linked service within Data Factory can be created with a service principal, which would then handle most of the information of the scope and consent. The service principal is also accompanied with a Azure app, which would hold the token etc. Unfortunately, we are unable to make this setup function correctly.
Questions we have:
Can we actually use a service principal / app to store our OAuth2 tokens? If so, will these be automatically refreshed within our app?
How do we assign the correct privileges / authorizations to our app that it can use this (external) API?
Is the additional logic with HTTP calls within Azure Data Factory pipeline needed to update the tokens or can these apps / service principals handle this?
Thank you for your time and help!
It is not a good idea to store the tokens in the keyvault, because they will expire.
In your case, two options for you to use.
Use service principal to auth
Use managed identity to auth(best practice)
Steps to use service principal to auth:
1.Register an application with Azure AD and create a service principal.
2.Get values for signing in and create a new application secret.
3.To call the Azure REST API e.g. Resources - List you mentioned, your service principal needs the RBAC role in your subscription.
Navigate to the Azure portal -> Subscription -> add your service principal as a Contributor/Owner role in the subscription like below.
4.In the linked service, configure it like below, fix them with the values got from step 2.
Don't forget to replace the {subscriptionId} in the Base URL.
https://management.azure.com/subscriptions/{subscriptionId}/resources?api-version=2020-06-01
5.Test the linked service with a copy activity, it works fine.
Steps to use managed identity to auth:
1.Make sure your data factory has enabled the MSI(managed identity), if you create it in the portal or powershell, MSI will be enabled automatically, don't worry about that.
2.Navigate to the Subsctiption in the portal, add the role to the MSI like step 3 in Steps to use service principal to auth, just search for your ADF name in the bar, the MSI is essentially a service principal with the same name of your ADF, which is managed by azure.
3.Then in the linked service, just change it like below.
At last, answer your questions.
Can we actually use a service principal / app to store our OAuth2 tokens? If so, will these be automatically refreshed within our app?
As I mentioned, it is not a good idea, just use the service principal/MSI to auth like the steps above.
How do we assign the correct privileges / authorizations to our app that it can use this (external) API?
To use the Azure REST API, just assign the RBAC roles like above, specify the correct AAD resource e.g. https://management.azure.com in this case.
Is the additional logic with HTTP calls within Azure Data Factory pipeline needed to update the tokens or can these apps / service principals handle this?
No need to do other steps, when you use the configuration above, essentially it will use the client credential flow to get the token in the background for you automatically, then use the token to call the API.
General Overview of what I am trying to achieve
I am trying to build an Azure AD Multitenant Web application which allows me to manage resources in customer subscriptions/tenants using the Azure Resource Manager (ARM) APIs. I am pretty new to Azure AD Multitenancy.
The Ideal control flow
1. A customer browses the Applications (ideal an admin of the customer tenant)
2. Will be granted with Azure AD authorize flow
3. Accepts everything and grants admin consent for the AD App in their tenant
4. Unclear: The AD App will be granted contributer access on a subscription or resource
5. My Web App will be able to use the AD App credentials to manage the customer resources using the ARM APIs
Problem
Steps 1-3, 5: Are clear and I know how to build that.
Step 4: I am not sure how to build that so that step happens automatically.
Solutions I have considered
The worst case would be the customer AD Admin must manually grant the AD App access to a subscription or resource using the Azure Portal.
One idea that came to my mind is that you require the user_impersonation permission on Azure Service Management API.
After the user logs in, you could list out the subscriptions available, allowing the user to select one.
Then list out the resource groups if needed.
Once the user confirms a selection, your app could add itself as a Contributor on the targeted resource through the Management API, on behalf of the currently signed-in user.
To do this, you will need the object id of the service principal for your app created in the target tenant.
You can get it by acquiring an app-only token for e.g. the Azure Management API from that tenant's token endpoint after the user has logged in.
The token will contain an oid claim, which is the object id for the service principal.
Of course the user who signs in would have to have the ability to modify access to the target resource.
I would say the downside of this approach is that the organization must trust your app to only do the thing it claims to do.
The approach where they grant the access manually allows them to be in control fully.
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
Is it possible to gain access to the Azure Management APIs through the client ID and secret for a web app?
I have a web app through which i want to be able to manage Azure. I want to do this using the credentials of the application itself so that the current user does not have to be an azure administrator.
I have given the web app the necessary role on my subscriptions and obtained the access token through the client credentials grant flow in AD but i still get an unauthorized.
This is probably because the azure management API has no permission set other than delegated - the access works fine if i use the authorization code grant flow for the logged in user, but thats not what i want.
So to reiterate, if, given a web app that has RBAC to a subscription and is able to obtain an access token from AD, is there any way, without an interactive user, that the web app is able to use the management API??
Yes, you can obtain a token from AAD for a service principal and use that to manage resources as long as that service principal has all the access you need.
Make sure the token you get has a resource/audience of "https://management.azure.com" and is for the tenantId that the subscription is associated with.
You can also see this article from Brady Gaster that explains how to use Azure AD applications to manage Azure Services from an external app : http://www.bradygaster.com/post/using-windows-azure-active-directory-to-authenticate-the-management-libraries
EDIT : Azure AD supports Service to Service calls using OAuth 2.0 client credentials: https://msdn.microsoft.com/en-us/library/azure/dn645543.aspx
Hope this helps,
Julien
I find the authorization flow confusing for calls to Azure's management APIs, i.e. not Azure API management which is the API gateway SaaS, and I'm hoping for some clarification.
From documentation at https://msdn.microsoft.com/en-us/library/azure/dn629581.aspx:
Although Azure originally allowed access only by Microsoft account users, it now allows access by users from both systems. This was done by having all the Azure properties trust Azure AD for authentication, having Azure AD authenticate organizational users, and by creating a federation relationship where Azure AD trusts the Microsoft account consumer identity system to authenticate consumer users. As a result, Azure AD is able to authenticate “guest” Microsoft accounts as well as “native” Azure AD accounts.
and http://blogs.technet.com/b/ad/archive/2014/08/15/prepping-for-new-management-features.aspx:
Your Microsoft Azure subscriptions uses Azure Active Directory to sign users in to the management portal and to secure access to the Azure management API.
The documentation leads me to believe the Azure AD tenant associated with a subscription acts as a STS with management API being the RP, or authorization server and resource server respectively using OAuth terminology. The tenant can also choose to trust third-party STSes, e.g. another tenant or Microsoft Account services, and thus allow for users from external identity providers access to the management API.
The blog post also writes:
Azure will soon require administrators to be registered in Azure Active Directory to be able to sign in to the Azure portal or use the Azure management API.
Disassociating an admin's account with the subscription's Azure AD tenant, irrespective if it is a "native" account to a tenant or a federated account, should in my mind revoke their access to the management APIs.
I tried validating the assumption using one my subscriptions and couldn't quite make sense of the result. Let's say the subscription has three admins:
Service admin SA using a federated Microsoft Account
A co-admin CA-AAD using an account "native" to the tenant trusted by the subscription
A co-admin CA-MSA again using a federated Microsoft Account
With all three accounts registered with the tenant, any of them can manage resources belonging to the subscription as well as use an web application that in turn access the Insights API through user impersonation.
Removing CA-AAD from the tenant disallowed the account from managing resources and accessing the Insights API once the cookie/access token had expired. This is the expected behavior, except the now non-exitant account still remains listed as a co-admin for the subscription.
However, removing CA-MSA from the tenant did not prevent the account from managing resources or accessing the API. This behavior even persisted between sessions and the account remained listed as a co-admin and not quite the expected outcome.
And now onto the questions:
Why is CA-MSA allowed continued access to management APIs despite it not registered with the tenant?
What is the authorization flow for accessing the management APIs?
How are accounts mapped to those listed as co-admins for a subscription?
Azure subscription refers only two directories for authorizing the users for accessing the management API.
the Azure AD to which the subscription is associated to.
Microsoft AD(MSA).
When a user with Microsoft Account is added as a subscription co-admin, user is indirectly registered in the Azure AD to which the current subscription is associated to. If the user is deleted from Azure AD, it still has the subscription access. It is because the user is still present in Microsoft Account AD.