Is there a mechanism in Azure AD to have a completely headless authentication? Most likely this would mean (in my mind) that the server running the API would have a perpetual authentication session to Azure.
If the purpose matters... We have a need to expose our thumbnailImage attribute from AD and I just need to make it so that the server doesn't care who requests the image. So basically we will have https://domain.com/api/Image/userid and the api will return an Image object (image/jpeg). I have this functioning internally and now I'm just migrating to Azure.
I found this question... I just want to confirm two things...
Daemon or Server Application to Web API is the method I should be looking at
Using this method will function as I'm expecting... a.k.a. WebAPI can access that attribute and use it like I currently use it while inside our internal domain.
Indeed. Azure AD supports the client credential OAuth flow. Yes, you are looking at the right help topic. The corresponding sample application is here: https://github.com/AzureADSamples/Daemon-DotNet.
If you haven't already, use Azure management portal to register your WebAPI as an application in your Azure AD directory and add a client secret (under the section named 'key' in the 'configure' tab of the 'application'). This key will be used as the client credential.
To configure permissions for your WebAPI to be able to call Graph API using client credential flow token, go to the application tab in the Azure Portal, under Azure AD and in the section titled 'Permissions to other applications', add an 'Application Permission' to 'Windows Azure Active Directory' to 'Read directory data'.
What you refer to as perpetual authentication session is basically your WebAPI caching the access token to Graph, and getting a new access token (using client credential flow) when the current access token is about to expire.
Hope this helps.
Related
I have an application which is sitting behind WAF (Web Application Firewall).
Application is using Microsoft Active Directory for authentication.
Here are the steps
User try to access the application using the browser.
WAF layers see that REQUEST is not authenticated, hence forward it to Azure Active Directory
AAD shows the login page and the user enters username/password/MFA
Now token from AAD send back to the browser and it will be sent to the backend application
Now question is,
How backend application verify this token? Does it need an outbound connection to AAD or will it talk to AAD through WAF and browser?
Do I need to have NSG rules (outbound ) to talk with AAD?
It depends on which auth flow you are using.
For Authorization code flow, your application would need to talk to AAD to redeem auth code for access token and refresh token via back channel. So, you would need to allow connection to AAD (login.microsoftonline.com).
For Implicit grant flow, it's browser which directly gets access token from AAD via front channel. So, in that case, you won't need whitelisting in backend WAF.
I have resolved the issue by using service tag feature in NSG. Backend application need to be able to reach AAD in order to validate the access token.
I have added outbound rule with Destination Service Tag Azure Active Directory as shown below.
Here is the link: https://learn.microsoft.com/en-us/azure/virtual-network/service-tags-overview
I'm trying do some Azure Web Job management (i.e. List, Run, Stop) from a web app and am having trouble finding an example of the Authorization header to use for Azure App Service API.
I'm attempting to follow the documentation
Also, is this the recommended way of doing this or should I be using Kudu API?
Both of the two documents you provided is right.
The Azure Resource Manager API is used for general-purpose operations that are not service specific, such as list and get. And it use Azure Active Directory OAuth2 Flow to authenticate.
While the KUDU API is using Deployment credentials to authenticate.
How can I add the authorization header for Azure App Service API?
You can use Postman to set up your authorization header for Azure App Service API as below:
For rest api, you can choose Bearer Token and send your token in it:
For Kudu api, you can choose Basic Auth and send your username and password as Deployment credentials said. Then it will automatically generate token.
I have created a custom OData feed using ASP.NET Web API. This service is configured using Azure Active Directory for Authentication. The issue I currently have is when I try and connect Power BI or Power Query up to the OData feed. Once I have entered my credentials I get the following error:
Invalid_resource: AADSTS50001: The application named https://localhost:44320 was not found in the tenant named XXX.onmicrosoft.com. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.
I'm pretty sure that I have configured AAD correctly as I can connect up through the web browser with no issues. I'm not sure if it's even possible to connect up with Power Query as I have seen conflicting posts in various forums!
Any help would be greatly appreciated.
I also experienced this error when trying to use PowerQuery to get API data into an Excel spreadsheet, and had a hard time getting past it mainly as the documentation around all this is somewhat slim.
Problem - How to import data from an API in Azure into an Excel spreadsheet?
I had a ASP.NET API running in Azure and exposed on my own domain at a URL e.g. https://api.myapp.net (rather than a built-in azure URL). This API was hooking into Azure AD via the OWIN middleware: UseWindowsAzureActiveDirectoryBearerAuthentication, i.e. the App Service in Azure had AAD authentication turned OFF. The application was registered in AAD as multi-tenant, in a different tenant to the where the app service resource was hosted.
Issue 1 - Credentials
So first off in Excel do Data > From Web > https://api.myapp.net/Products and select "Organisational Account" and click "Sign-in", giving this error:
There are two different fixes for this:
1. Return WWW-Authenticate response header on all 401s
If you have enabled AAD on your API in code using the owin middleware, then you need to ensure the service returns the correct WWW-Authenticate header in the 401 response to the client, specifically we must specify the AAD sign-in end-point as the authorization uri, e.g.:
WWW-Authenticate: Bearer realm="",
authorization_uri="https://login.microsoftonline.com/<<tenant id of your users>>"
See: this TechNet question which suggested this solution
2. Turn on AAD authentication for the API app service in the Azure portal
Alternatively in the Azure Portal for the tenant where the App Services themselves are hosted
Go to App Services and locate the API app service
In Authentication / Authorization turn App Service Authentication ON
For "Action to take when unauthenticated" select "Log in with Azure Active Directory"
Under "Authentication Providers" click "Azure Active Directory" and select "Advanced" settings
Under "Client id" enter the application id for the API app registration
Under "Issuer Url" enter the sign-in end-point for the tenant the users of the API originate from
Under "Allowed Token Audiences" ensure you have added the actual url of your API e.g. https://api.myapp.net
Save the changes
Essentially this config is described here
Issue 2 - App Registration
Now back in Excel when you click sign-in on the query a pop-up will open and take you to the Microsoft sign-in page for the tenant you configured. When you enter credentials and sign-in you may then get this error (the one in the question):
To fix this issue you need to ensure the the application is registered correctly with AAD.
Here is how...
In the Azure Portal for the tenant where your applications are registered
Go to Azure Active Directory > App Registrations and locate the registration for the API service
Edit the Manifest and ensure the actual deployed API URL is configured in the list of identifierUris e.g. https://api.myapp.net (there will be an Azure built-in URL already configured)
{
"identifierUris": [
"https://api.myapp.net",
"https://<mytenant>.onmicrosoft.com/<myappregname>"
]
}
If the application is multi-tenant you will need to ensure the domain used in this URL is verified with Azure
You must also ensure the user_impersonation scope is available for the application:
{
"oauth2Permissions": [
{
"adminConsentDescription": "Allow the application to access myapp on behalf of the signed-in user.",
"adminConsentDisplayName": "Access myapp",
"id": "xxxxx-xxx-xxx-xxx-xxxxxxx",
"isEnabled": true,
"lang": null,
"origin": "Application",
"type": "User",
"userConsentDescription": "Allow the application to access my on your behalf.",
"userConsentDisplayName": "Access my app",
"value": "user_impersonation"
}
]
}
Save changes.
Issue 3 - Allowed token audience
Now back in Excel, you should be able to get past the sign-in but when clicking on "Connect" you may get this error:
Now looking in fiddler you will see the AAD login works and returns a token but when this is sent to the API you get a 401.
This is only an issue if you have enabled AAD via code rather than through the Azure portal (see Issue 1 above!). To fix it you need to ensure the TokenValidationParameters class passed to the owin middleware has ValidAudience set to the actual url of your deployed API.
Run the query
With all that set-up everything should now work, back in Excel ...
Click sign-in a pop-up will open and take you to the Microsoft sign-in page for the tenant you configured, sign-in with you credentials
Click Connect
PowerQuery editor will then open and display the retrieved data from the API
Click Home > Advanced Editor you will be able to view the raw query - this is in M-query syntax the query language used by PowerQuery, in my case the data was a flat array so this sufficed:
let
Source = Json.Document(Web.Contents("https://api.myapp.net/Products")),
#"Converted to Table" = Table.FromRecords(Source)
in
#"Converted to Table"
Click Close & Load to return the data to the Excel worksheet
How this works
In case you care (and are still reading this!), the way this works seems to be:
PowerQuery requests access to your API under the "Microsoft PowerQuery For Excel" built-in application (client id a672d62c-fc7b-4e81-a576-e60dc46e951d)
When you sign-in AAD grants the dynamic scope user_impersonation on your API (identified by the resource URL https://api.myapp.net) to the "Microsoft PowerQuery For Excel" app
You can see this in the portal by going to Enterprise Applications, checking Microsoft Applications and searching for Microsoft PowerQuery For Excel
Sorry for the long post but hopefully this helps somebody do something seemingly quite trivial - pull data from an API in Azure into Excel!
I have managed to get past this issue by publishing my WebAPI to an Azure Web App. Interestingly, when its hosted on Azure it prompted to allow "Power Query for Excel" access. The issue could be limited to the fact I was running it on IIS Express on my Dev box.
I have a Web Api (just a result of the VS wizard with Azure AD authorization option turned on). I want to test this api directly, not using Azure API Management Portal or anything else. Particularly I want to use Advanced REST Client (often called ARC: https://chrome.google.com/webstore/detail/advanced-rest-client/hgmloofddffdnphfgcellkdfbfbjeloo), but any web client will suite me, for example curl.
Could somebody go through all the necessary steps to perform a proper authorization or recommend a good resource on this topic?
I expect all the work to be done manually, not using any tools except my browser and curl or arc
To make the request to the web API which protected by Azure AD, we need to get the access token through OAuth 2.0. After we create the web API project by Visual Studio, we still need to register an app on Azure portal which used to call the Web API.
For example, the Azure AD created an app active-directory-webapi for me when I create the web API project active-directory-webapi using the Visual Studio wizard with Azure AD authentication.
Then I open the Azure AD portal though this link and register an web application named as active-directory-webapi-client. Since it is a web application, we need to generate an secret for it. And to use call the web API, we need to add the web api application to grant the permission for it. Here is an figure for basic information for app I register it manually:
Then we can use OAuth 2.0 require the token for this app:
Get: https://login.microsoftonline.com/{tenantId}/oauth2/authorize?response_type=code&client_id={clientId in figure }&redirect_uri={redirect Url in figure}
Then we need to input the username/password and get the OAuth code in the Url. And we can get the token through the OAuth code by request below:
POST: https://login.microsoftonline.com/{tenantId}/oauth2/token
client_id={client_id in figure}&client_secret{secret in figure}&code={OAuth code in the previews request}&grant_type=authorization_code&redirect_uri={ redirect Url in figure }&resource={ it as the Audience in the web.config of web API project}
At last, we can call the web API use the token from request above:
Get: https://localhost:44305/api/values
authorization: bearer {accessToken}
More detail about OAuth 2.0 authorization flow you can refer here.
I'm a bit confused regarding the authentication/authorization setting on the settings blade for an Web/Api App in Azure.
If I enable Azure AD authentication via the portal.
Is there any way to get hold of user information in the actual service then?
I know there is the Bearer security header, but can I extract any useful information from that?
Or is the authentication/authorization setting acting only as a proxy before the call to the service. that is, it requires valid AD credentials, but the service never have to deal with any of the details around it?
What would be the main differences between using that setting vs. creating an Web/Api App that uses Asp.NET authentication via code. e.g. its possible to set that up using the standard ASp.NET templates.
In those templates you get an OWIN app that uses an Azure AD authentication provider.
If I use the latter, is there any benefit from the authentication/authorization setting? or can I simply ignore that if the App itself has an authentication provider?
Using the authentication in the portal allows you to get some very rudimentary information about the logged-on user via the header "X-MS-CLIENT-PRINCIPAL-NAME", and you also have access to whatever claims are passed in. There's a good example here: Websites-Authentication-Authorization