In a AzureAD authenticated app hosted in Azure i get the access token in the api controller like this
public override void OnActionExecuting(ActionExecutingContext context)
{
base.OnActionExecuting(context);
_client.DefaultRequestHeaders.Accept.Clear();
var tokenHeader = Request.Headers["X-MS-TOKEN-ADD-ACCESS-TOKEN"];
_client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", tokenHeader );
}
Since Azure AD app service injects the token it works only when hosted in Azure.
How can i make it work in my development environment? This of course generates an exception.
Im following this tutorial:
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-auth-aad#enable-authentication-and-authorization-for-back-end-app
Both backend and frontend are secured with AzureAD authentication.
The frontend app has had permission set to the backend app in AzureAD section in the portal.
In the code, there is nothing configured in appsettings.json.
According to your describe, you're using Easy Auth for your web App service. You know, Easy auth is for Azure Web App service, it's managed by Azure. So, I'm afraid of that you cannot use Easy Auth authentication for your app from your local machine.
For more detials about Easy Auth for Azure Web App service, you can refer to this documentation.
If you run the application locally on your development system, Easy
Auth will not be available and you will not have the access tokens,
etc. that you may need in your application. In order to debug those
features of your application, you will need to deploy to an Azure Web
App. An alternative approach is to do the login and authentication
workflow in the application code, but then you are no longer
leveraging Easy Auth.
However, there is a method to do Local Debugging of .NET Core Web App with Easy Auth.Here is a blog which introducts an approach to that. This blog may be helpful to give a thought for your scenario.
I have a web app written in Node and hosted as an Azure web app. I have setup Application Insights web tests for other sites that do NOT require auth and these work fine. Now I need to test a route that requires authentication, but it is not obvious how to do this on the Azure Portal. Can this actually be done? I have seen some posts about doing this through Visual Studio but I really want to avoid that if at all possible.
As per the article here - https://learn.microsoft.com/en-us/azure/application-insights/app-insights-overview - if you don't want to touch code (and hence, redeploy) you cannot do what you are asking in the question.
Looks like diving deep into code is the only way
I have two applications:
MVC Site (User-facing Web App secured via OAuth -> Google)
Web API Site ("Private" Web Services)
These are hosted in an App Service Plan in Azure. These web services will only be consumed by my own applications - I don't need to worry about outside consumption. In fact, I specifically don't want outside consumption. My Web App is using OAuth to Google - that shouldn't matter here.
So to get to the heart of my question: My web services currently have no authentication/authorization model in the code but I don't want it just publicly available to anybody. On prem, we just lock this down via IIS using Windows Auth and set the service account for the consuming web app to run as a user that Windows Auth allows access to. I'd like to do the equivalent in Azure.
I understand Azure isn't exactly the same but I have to believe this is possible. I have even gotten my web services locked down the way I want using the settings in the Authentication/Authorization tab (I can try to navigate to it but I only get my Swagger UI once I login with a valid organizational account). So half of my battle is solved but I cannot figure out how to do the other half - the equivalent of setting the service account for my consuming MVC application to run as.
Can I do this via the portal without having to code specifically to this scenario? I'd really like a PaaS-level or IaaS-level solution for the security portion of consuming the above locked-down services. I'm also open to other avenues if I'm going down the wrong path in having a PaaS or IaaS security solution to this problem. I'm not against making code changes - we did have a one-liner in our RestSharp code to engage Windows Authentication, but the bulk of the work/configuration was outside of code and that's what I'm going for here.
If going the IaaS path you can host the application inside of an VM in the exact same way as you did before when running it directly on-top of IIS. The benefit is that you can get running the same way as before but you will still need to manage the VM; i.e install updates and take care of its security.
However, if you want to have a PaaS solution, then you need to modify the code of your front-end application to pass on the authentication token to the back-end API, assuming the back-end accepts the same authentication as the front-end. See https://azure.microsoft.com/en-us/documentation/articles/app-service-api-dotnet-get-started/ as an example on how to pass on authentication information from one app to another.
Alternatively you can use the app identity to make calls to your back-end API. This way the calls are not related to any user but are instead done in the context of the app. See https://github.com/Azure-Samples/active-directory-dotnet-daemon for more details on how to set it up, both configuration and needed code.
If you want to allow your users to sign-in using their Google accounts then you could handle authorization to your API using the app identity (second alternative above), assuming the API is independent of the requesting users identity.
Enabling authentication for a Azure Web App directly through the menus in the Azure Portal adds Azure AD authentication in-front of your application and require your to pass an access token generated by Azure AD to your API for it to work.
I installed VS2015 and the latest Azure SDK. I'm somewhat confused by the addition of new project templates compared to VS2013 and the previous Azure SDK. I'm trying to get my head around the new Azure App Service.
I used to create a Web API project and publish it as an Azure Cloud Service. Now, I'm offered more options:
1) Azure Cloud Service -> ASP.NET Web Role -> Web API
I'm familiar with this one.
2) Azure Cloud Service -> ASP.NET Web Role -> Azure API App
Why would anyone create an Azure API App and publish it as a cloud service?
3) ASP.NET Web Application -> Web API
4) ASP.NET Web Application -> Azure API App
These two are essentially the same as the first two without the cloud service template. However, the way they are published confuse me even more. You could publish each as a Microsoft Azure Web App or Microsoft Azure API App.
How do the following compare and contrast:
Web API -> Published as a Web App
Web API -> Published as an API APP
API App -> Published as a Web App
API App -> Published as an API APP
I agree, the tooling has confused this a little. Here is how I am dealing with it:
"Cloud Services" seem to be a thing of the past, any new project I am doing I am going with AppService and scripting the set-up of that app service with an ARM (Azure Resource Manager) template. You will find a template for this under Cloud->Azure Resource Group in VS 2015. This is entirely optional, but is a great best practise.
As you point out above, all 4 combinations are valid. In fact an Azure API App uses the same technology under the surface as the website does (it is a little buried away in the portal, but you can navigate down from the API app to the underlying website by opening the API App in the preview portal, and under the label for "API App Host" double click).
Using the API App template in VS2015 you will just get a standard asp.net website like you do with the web app templates, but the main difference is that the API App is slimmed down by default unlike the website template that will have lots of libraries that are of no use to an API app (no jquery, bootstrap RazorViews etc). The smaller footprint should mean that there is less to load when asp.net starts-up, hence faster start-up times.
API apps have easy integration points for use in Logic Apps (think a workflow from Salesforce defined in the Logic app that requires to call your API to update data to your database). You could do this with a web app, but there will be more plumbing to do.
I believe the plan in the near future is a marketplace of API apps (app store style) that will allow us devs to sell APIs.
Swagger out the box. The API app template has Swashbuckle pre-installed for generating the Swagger documentation for you API (arguably you could just install this via nuget into your web app template).
On the whole API apps have the exact same functionality as web apps, but slimmed down with extra bits in places.
I've been reading a few tutorials now on deploying Web Apps and API Apps to Azure. However, I am still a little unsure as to why you would use one over another.
I can create a new .NET solution with API controllers and deploy this as a Web App, so why would I specifically require an API App? Are these optimized specifically for ASP.NET Web API, where as Web Apps are for delivering HTML?
Updating the answer to current state of Azure,
App Services now replaces all Mobile, Api and Web Apps flavors as a single app framework with all the functionality rolled over to make things more accessible across application types. Currently all of Web, Mobile and Api Apps are collectively called App Services. We still offer customer to be able to create a Mobile App and a Web App in the gallery but that is basically resolve into an App Service App.
https://azure.microsoft.com/en-us/documentation/articles/app-service-api-apps-why-best-platform/
Features for Mobile work for Web App as well such as Easy Tables and Easy API. And features for API apps like API Cors and API definitions now work on web apps as well. A customer can host a single web app to act as any mobile service or an api with all the features offered through the app services.
We also have a new service in preview particularly targeting API Apps by offering a management experience for your APIs, Basically you can control the generate try API pages, gather execution analytics, throttle and much more. Check out the feature blog to learn more about the Azure API Management Features. And yes you can host the APIs as a App Service App and hook things up with API Management.
https://azure.microsoft.com/en-us/documentation/articles/api-management-get-started/
There was a point in time when there were differences between the different app service types, but that is no longer true. The documentation now states:
The only difference between the three app types (API, web, mobile) is the name and icon used for them in the Azure portal.
So it no longer matters which app service type you choose to deploy to (unless you care what the icon looks like).
UPDATE
Function apps are now the exception. Creating a function app changes the user interface in the portal. The underlying web app, however, is no different. Setting an app setting named FUNCTIONS_EXTENSION_VERSION = ~1 turns any web app into a function app (minus the user interface in the portal).
There are many minor difference between Web API and API Apps, but the very notable and key differences are
Native Swagger implementation - When you create API App in Visual studio, swagger reference comes by default. Swagger provide very developer friendly features for API consumers to Interact with your API thru Swagger UI. Also Swagger based API's provides client SDK generation (both .Net based client and Javascript based client) which makes easy to call API's just like regular method call.
Note: Swagger implementation on regular Web API is possible manually.
Ability to publish your API Apps into Azure Market Place. Azure Market Place is the public repository for all API Apps that can be consumed freely or by charge.
this 15 minute video from Channel 9 gives an excellent overview about Api Apps.
To supplement Greg's answer, Here's an even more recent article describing the differences.
To sum up:
"The key features of API Apps – authentication, CORS and API metadata – have moved directly into App Service. With this change, the features are available across Web, Mobile and API Apps. In fact, all three share the same Microsoft.Web/sites resource type in Resource Manager."
And here's another important note:
"If your API is already deployed as a Web App or Mobile App, you do not have to redeploy your app to take advantage of the new features."
This can depend on what you are trying to do, but you would use a Web API when you are creating a service. ASP.Net Web API is a framework for building HTTP services that can be consumed by a broad range of clients. This allows you to build it not only for a web app, but have it open to connect to Android apps, IOS apps, web apps, Windows 8 apps, WPF apps etc..
So if you need a Web Service but you don't need SOAP then you can use Web API.
Here my comments:
API app:
Used for specific functionallity. Triggering that functionality from an URL.
Can be used to use with GET, POST, PUT, DELETE.
Can receive parameters at BODY (Json).
Response with valid status code (fail, sucess.)
Web APP: An application deployed with multiple functionallity, for example
a catalog for create, update and delete customers or to create a complete ERP.
Function APP: Is very similar to API app,
Used for specific functionallity. Triggering that functionality from an URL.
Can be used to use with GET, POST, PUT, DELETE.
Can receive parameters at BODY (Json).
Response with valid status code (fail, sucess.)
Actually you can deploy your aspnet webapi on Azure WebApp and a self host on Worker Roles.
On WebApp (former Azure websites), it will be deployed on IIS, so you can take advantage of IIS features.