Is there a way with a single app to access Graph, VSTS, and Azure information? It seems access to each of these requires it's own app with origination and callback urls.
For Azure, I'm using NPM's passport-azure-ad in a node js app.
Ideally, I would like to combine VSTS build info, Azure service usage info, and User profile info.
Each of the services you mentioned has their own API:
Azure REST API
Visual Studio Team Services REST API
Microsoft Graph
This does not however mean that they also each need their own "app". When you register your application in Azure AD via the Azure Portal you're able to request access to a number APIs. Each access_token you receive will be tied to one API (called a "resource") but you can use the refresh_token to switch the targeted resource:
The only exception here is the VSTS REST API. While most APIs use the same identity provider, VSTS has their own. So for the purposes of VSTS, you will need to have the user authenticate separately. Obviously, that isn't a great user experience but there is a useful workaround: Personal Access Tokens.
Using a Personal Access Token for VSTS allows you to authenticate the user via Azure AD OAuth and get an access token you can use with Microsoft Graph and the Azure REST API. Once you've authenticated them, you can ask them to provide a Personal Access Token to access VSTS. This allows you to forgot asking the user to authenticate a second time since you'll store their PAT use it for any calls to VSTS.
First, there is Allow scripts to access OAuth token option in the Phase of Build/Release definition, you can check this option and access the token through System.AcessToken variable.
To grant the permission for that user, you need to grant the permission(s) for Project Collection Build Service (xxxx) account.
Secondly, there are some tasks related to Azure (e.g. Azure PowerShell), that can access azure resources (The AAD application is associated to the Azure endpoint)
You can retrieve the necessary information in multiple task, then store the result in the variables through Logging Commands (##vso[task.setvariable]value), then combine them together.
Related
I have an Azure WebApp which needs to call the Azure DevOps API to trigger a build pipeline.
The only problem I have is to find out which is the proper way to authenticate from my web api against azure devops API.
Should I use a service principal account for that, or Managed Identity?
Do I have to create a service account in Azure AD, give him rights on Azure DevOps ?
I only have a route which then calls the DevOps API, so I need to authenticate at the moment the route was called with a Principal from the WebApp.
Iam a little bit lost how to do it the right way, because there is so much information about the auth topic.
Currently I use my personal account with PAT from Azure KeyVault, which is only a temporary solution.
Thanks & Regards
If you check this Choose the right authentication mechanism document, you will find several types of authentication mechanism from your Web App API against azure DevOps API.
But it's mostly recommended to use Azure DevOps Services Client Libraries for authentication and accessing Azure DevOps Services resources. You can authenticate your web app users for REST API access, so your app doesn't continue to ask for usernames and passwords.
Azure DevOps Services uses the OAuth 2.0 protocol to authorize your app for a user and generate an access token. Use this token when you call the REST APIs from your application. When you call Azure DevOps Services APIs for that user, use that user's access token. Access tokens expire, so refresh the access token if it's expired.
I would suggest to read this Authorize access to REST APIs with OAuth 2.0 document for the more explanation and detailed approach to achieve the result.
In case, if any required functionality is missing from the client libraries, MSAL is an alternative authentication mechanism to use with our REST APIs.
Currently, a user has to add my application within the Azure portal. I will then get a ClientID etc. and use that to get access to the users Consumption data. I wondered if I could streamline this process by asking for consent using the Azure authentication.
Pre-thanks!
**
Let me elaborate a bit more, I'm creating an application that will help the user by giving insights on there cloud spend. I get the data using the consumption API. At the moment I get access to that API by them giving my app credentials via the Azure portal. But I want to get the access via Azure authentication
**
In Azure AD, there are several auth flows, not sure which one you want to use. Generally, these flows can be divided into two types, user-interactive or non-interactive.
Per my understanding, you want to call the Azure Consumption REST API via Azure AD auth. If you want the user-interactive way, you could use auth code flow. If you want a non-interactive way, you could use client credential flow.
For more details, see https://learn.microsoft.com/en-us/rest/api/azure/
I am new to D365/PowerApps and wonder if i have a Azure Service, (Azure Functions or WebAPP) that is secured with Azure AD tokens (App Registrations).
Can I get an Access Token to my external services using Azure AD from within a plugin step in d365? How do I get such token on behalf of the context the plugin when running as a user.
You'll need to use Flow and compose a http request to get the token:
https://flow.microsoft.com/en-us/galleries/public/templates/edfa8fde25644f149448c8d8cff44699/call-a-web-service-from-a-powerapp/
Here's a good explanation on how to do it using the REST API:
https://stackoverflow.com/a/36982924/1384539
If I understand your question correct,
You have an Azure function APP or external azure service and that is secured by creating Azure AD App with it's roles delegation and so on.
Now you need Access token for this Azure APP with client ID and Client Secret.
We had this similar thing in Dynamics 365 i.e When we wish to use Dynamics 365 Webapi, We need to create Azure AD App and then provide roles delegation so that this app will have access to Dynamics 365.
In Plugin we can give details with client Id and Secret and then generate Token which will be used for Furthure process during plugin Execution.
Note: Most of these plugins we run under System context.
Here are few examples which will lead you to your desired direction.
Most of the Examples also talk about creating Non-Interactive user in Dynamics but in your case that shall not be needed because you are not communicating with Dynamics via (Azure AD App) rather you communicate with Azure functions or so on.
Link 1
Link 2
Link 3
I'm trying to register an application in Azure programmatically. Most examples are targeting use of Azure Portal, which doesn't meet my requirements. Other examples assume that I have a registered app already and hold a bearer token to use for this operation. Again that doesn't meet my requirements.
In my scenario. I'm an Azure AD administrator, and I want to programmatically register my first application, without going to the Azure Portal. Since this is easily done via portal, I was hoping to do this in code as well (http/C# preferred). And as a step 2, Add permissions and Grant admin consent - again programmatically.
Eventually, I'm using the registered app's ClientId and ClientSecret to retrieve the bearer token and then query Graph API. (This part is working fine, when I make the app registration manually via Azure Portal)
I hope this makes sense.
You can use the Microsoft Graph API.
The API to use to create an app is: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/application_post_applications
To grant permission you can refer here
I want to develop a SaaS application on Azure and deploy to the Azure marketplace. This app will be able to obtain information about the user's network. (for instance VNET information). Ideally I would like to have a single-page application that would authenticate with the user who subscribed to the app, and then make calls on a backend API tier, which would make calls to Azure management API endpoints.
The Azure docs layout a number of scenarios of how apps could interface with AD. how-to guides
I believe what im trying to do most closely matches the "Build a web app that calls web APIs" flow, which is an example of OBO. My question is, is that really describing what im doing? Is "calls web APIs" really an example of invoking APIs on the microsoft azure platform?
So my understanding is that I would develop my own API app, that would accept requests from my client browser code, which would contain an oauth token, and then the API layer would derive another token to pass onto the Azure API layer?
Im trying to keep the architecture as simple as possible, but im afraid I may be misinterpreting the Azure docs.
OBO (On-Behalf-Of) allows you to exchange an access token that your API received for an access token to another API.
The important bit is that the access token must have been acquired in the context of the user and must contain user information.
The new access token will then also contain this user's info.
So it allows your back-end API to call Azure Management APIs on behalf of the current user.
This means your API can't do anything the current user can't do.
It is limited to the user's own access rights.
The other option for authentication is to use client credentials authentication,
where your back-end API uses only a client id + certificate/secret to authenticate.
In this case the token will not contain user information.
To enable this approach, the target organization's users would have to assign RBAC access rights to your app's service principal, so it can act by itself.
You could also build a flow in your app where you setup these RBAC accesses on behalf of the current user.
Personally, I would prefer to use delegated access (OBO) whenever possible, as it will block the user from doing things they cannot do.
Though on the other hand, service principal-based access allows the organization to control your app's access better.