Adding Applications programmatically in Azure AD using Client Credentials Flow - api

For use with the Azure API Management, I am trying to add Applications to an Azure Active Directory (AAD) programmatically, in my case by using the Graph API.
My scenario is the following: In order to secure a Web API I want to manage with Azure API Management, I want to leverage AAD's OAuth functionality to do the heavy lifting regarding authentication and issuing JWT Tokens, and then just use the validate-jwt policy to verify everything is okay in Azure API Management. This has the advantage I can more or less omit authentication in my backend service.
This works fine, as long as I have created an application in the Azure AD for the consuming web application, but this has to be done manually from the Azure Portal; Azure APIm does not do it automatically.
Now for what I am trying to do to get the done automatically: I wanted to delegate the subscription to APIs in APIm to some other web app I am writing, and from there I want to leverage the Graph API to create an Application in the Azure AD and grant permissions to the Application of the API.
The first thing I tried to do was to have a third application (my service application) to have full application permissions to the Windows Azure Active Directory application in the Azure AD; this lets my application access AAD using the Graph REST API. I manage to get an Access Token using the client_credentials grant (from login.microsoft.com), but this Token does not let me do a POST on https://graph.windows.net/(my AAD ID)/applications?api-version=1.5:
{
"odata.error": {
"code": "Authorization_RequestDenied",
"message": {
"lang": "en",
"value": "Insufficient privileges to complete the operation."
}
}
}
I found (https://msdn.microsoft.com/Library/Azure/Ad/Graph/howto/azure-ad-graph-api-permission-scopes) that even if I grant the Directory.ReadWrite.All permission, the application (app-only) will not be able to create or update Applications:
Note: Specifically excludes create or update for entities not listed above.
This includes: Application, Oauth2PermissionGrant, AppRoleAssignment, Device,
ServicePrincipal, TenantDetail, domains, etc.
The next thing I tried was the Resource Owner Password Grant (grant_type=password), passing my own credentials additionally, so that I can impersonate myself in the Graph API. Now, my POST to the applications end point succeeds.
My bottom-of-the-line question is: Can I grant sufficient permissions to my application so that I can add applications programmatically using the client credentials flow, and not any flow which acts on behalf of a user? And if so, how is it done?

Sorry Don. We don't currently have any permission scopes for the client credential flow (app-only) that can be used to create applications or service principals or create any oauth2 permission grants (or any of the other entities that you mentioned above through the Directory.ReadWrite.All permission). We are working on additional app-only permissions that will enable you to light up this scenario, but I don't have an ETA that I can give you.
This operation should be possible if you use the app+user (code flow) and grant the app the Directory.AccessAsUser.All permission - as long as there is a user using your app AND that they are a tenant admin. Not sure if this is an acceptable workaround for you (and I guess is similar to what you are using with the password flow - although I would recommend you use the code flow here).
UPDATE: There are a couple of new app only permissions we added for AAD Graph. Application.ReadWrite.OwnedBy (which allows an app to create/own another app - but only update the apps it created - it won't be able to touch any other apps it doesn't own) AND Application.ReadWrite.All (which allows an app to create/manage ALL apps in a tenant). Seems like the first one would be appropriate. You can see these show in the Azure Portal for the AAD Graph resource.

Related

Interacting with Azure Service from Azure Function from Client app on behalf of the user (user impersonation)

Context
I have a client app, represented through an Azure Active Directory app that needs to send a HTTP request to a HTTP trigger Azure Function on behalf of the user that is logged in to the client app. To achieve that I followed https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad. Doing so I am successfully able to execute the function on behalf of the user.
Goal
From this triggered Azure Function on behalf of the user I want now to achieve that I can interact with another Azure Service (let's say an Azure Storage Account) on behalf of the user. The user can do on this Storage Account what is allowed by the roles the user has on the Storage Account.
Problem
I don't get it working. I tried the approaches described in How to impersonate logged in user to manage other Azure service and https://blog.brooksjc.com/2020/06/21/accessing-graph-api-with-an-azure-function-through-impersonation/ And in this context I also don't get it working for Azure Data Factory respective Graph as described in the posts. For instance, when I call .auth/me I just get an empty array.
Question
Given this context how can I achieve my goal of interacting with the Storage Account on behalf of the user via the Azure Function that has been triggered on behalf of the user?
Thanks
EDIT
I am aware of the OAuth 2.0 On-Behalf-Of flow (see https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow) and this one works (i.e., I am able to authenticate the user, retrieve another token and use this one to interact with the Storage Account on the users behalf). What I would like to achieve is similar to the posts shared above that the user authenticates against the app and by doing so already a token is made available for the interaction with the Storage Account, so that I don't have to make the additional request to https://login.microsoftonline.com/{{tenant_id}}/oauth2/v2.0/token to get that token using e.g. client credentials. And this is not about specific code (e.g. C#) but about the general set up. Is this possible?

Microsoft Identity Delegated and Application Permissions in same API

I've been working with some of the ASP.NET core examples for APIs secured using Microsoft Identity. One scenario I haven't been able to find an example for is when you have a protected API that needs to make requests to another API (Microsoft Graph, one of my own APIs, etc) with delegated AND application permissions.
For example, say I want to update a user's profile on behalf of the user (delegated), but then I want the application to update their manager's profile using the application permissions (on behalf of the application's identity). Is there an example of this scenario? Would the application that's making the API calls request two tokens?

How is it possible to authenticate an application using Azure AD

I'm trying to setup an application to validate identity using Azure AD and acquire a token to allow access to a secure api. The front end application is written in angular and allows anonymous access. What can I use to access AAD authenticate and return an access token?
This will be an angular 6+ UI that is communicating to a secure .Net api using Azure AD for authentication. I have done a couple days research and everything points to a user logging in to authenticate using the login page. I need it to be by app and open the login page. I tried a couple examples where it utilized authentication/authorization and that didn't work because the app needs to authorization the user to talk to the api. I have seen where people were using Microsoft graph but once again it was user based and they were redirected to an azure login. I am looking for a solution that will allow me to setup an account in azure ad and authenticate the app on start to get an access token to allow communication to my secure api. If I have missed something somewhere in my research and test attempts let me know. This is my first Azure AD auth attempt and I feel like I am missing something for application authorization.
The problem is an Angular app is what we call a public client.
It cannot hold secrets and thus cannot prove its identity.
So, only user-based authentication flows should be used by public clients.
Confidential clients on the other hand can hold secrets as they run on servers that you control.
So for example, a back-end Web application or API would be a confidential client.
Those can use the client credentials flow to acquire access tokens and call APIs as themselves without a user being involved.
There is a bit of a fundamental issue in your question.
Your API requires authentication, but you want functionality to be available to anonymous users.
So you want to bypass authentication.
If you really want to bypass authentication for parts of the API, you could just make those endpoints available anonymously without a token.

Office 365 authentication via REST without registering an application

Is there any way of authenticating a user via the Office 365 REST API, without registering an application first?
For example, the documentation of Microsoft Graph has numerous authentication scenarios, including how an application can
Get access on behalf of a user
but there is no such scenario for a user calling the REST API with some credentials (e.g., username and password) and gets authentication tokens as a response, so that they can subsequently use the rich functionality provided.
The Azure Active Directory Authentication Libraries (ADAL) provide user-level authentication functionality, but they do not expose the REST API.
There is no way to call the Microsoft Graph without registering an app first. All calls to the graph are authenticated using a OAuth2 flow (of which there are several) and all require an app to be registered.
For your question, I think we can use background daemons or services to get authorize the user.We can use the following steps:
Get access without a user.
We can refer to this document to learning more information.
2.Authorize the user
When we get the user's profile by using the access token in the step one, then we can authorize him by checking him is exist in our system.

Connect to Azure to create an Application registration

I'm trying to write a C# console app that will register an application in Azure Active Directory. It should work just as the web application project creation wizard in VS 2013 when you Change Authentication and select Organizational Accounts in Azure.
Following the fiddler trace, I can see that it authenticates the user using wsfederation and an oauth2 token and then uses the graph.windows.net graph api to configuration the AAD directoryObjects service principal and application.
I have tried to use the sample Graph API app, but it requires the app be registered first so that I have the clientId (application id) and password (key) to send in the Acquire Token request using the Windows Azure AD Authentication Library for .NET.
I've tried using a bunch of the different Azure APIs but they all have my chicken and egg problem, I want to use an unregistered client application to register an application in AAD. I need to avoid Configuring Application Authentication and Authorization for the Graph API so that the user has no manual steps.
Does anyone know how Visual Studio does it, using just the user login with browser prompt or if there is a standard application id and password that can be used to access the graph API, like there is the standard login URL, https://login.windows.net/common? Some C# samples would be greatly appreciated.
This post does the Application creation, but requires a clientId and password, which I don't think I have.
You can't register a new application using the Graph API from an unregistered client. The only reason the VS2013 flow works is because VS2013 is already registered in a special way within Azure AD -- it's a first party application and has unique permissions. In my Fiddler trace, VS2013 uses a client ID of 872cd9fa-d31f-45e0-9eab-6e460a02d1f1. Technically you can use this client ID and the redirect URI of VS2013 to initiate sign-on with Azure AD. This still involves user interaction (the user has to authenticate via browser pop-up) so it doesn't meet your requirement for "no manual steps," but it's somewhat helpful for understanding the protocol flows and how registration works.
The bottom line is that if you want to call the Graph API without user interaction (client credential flow), the client needs to be registered with the proper application permissions.