I'd like to capture custom request headers in my Azure websites but I don't have access to the website's source code (ASP.NET). I do of course have access to the web.config.
Can I capture custom request headers via a configuration change? I see that IIS allows enabling of advanced logging (https://www.iis.net/learn/extensions/advanced-logging-module/advanced-logging-for-iis-custom-logging#server_logging) which can capture custom request headers but I don't see how to do it on Azure websites.
I don't think Azure Web Sites has enabled the Advanced Logging (or Enchanced Logging) so this doesn't seem to be possible using the standard Azure logging mechanism.
But to make sure, have you tried enabling the diagnostics for your site? Especially the Web Server Logs should be interesting for you. The following Azure documentation deals with logging on Azure Web Sites.
Enable diagnostics logging for web apps in Azure App Service
Related
I have this legacy intranet app using an AngularJS SPA consuming an an ASP.NET Web API (on .NET 4.6.1) and I can't manage to get the user authenticated on the domain inside the API, when calls are made by AngularJs.
Inside the API I have situations where I need to get the domain authenticated user. I have tried several combinations inside IIS to set both the AngularJS app and the API with Windows authentication, Impersonation, Authorization Rules. I've read several questions in Stackoverflow and other forums and also searched through several articles but I can't manage to find a solution, I'm feeling helpless in this one.
When I make a direct call to the API using a tool like Postman or through Swagger, System.Web.HttpContext.Current.Request.LogonUserIdentity.Name shows the correct authenticated user.
When I make the very same call to the API but through the client, like loading a page that requests data from the API, the user shown in LogonUserIdentity, is the one set on the app pool.
The authentication between the client and the API uses bearer token.
Here's my current scenario:
IIS:
Windows authentication enabled for both the client and the API, Impersonation enabled for both the client and the API
Authorization rules for ASP.NET and IIS set with allow all users for both Client and API
Session state in-proc, using cookies and with UseHostingIdentity set to false on both Client and API
Both the client and the API are using the same AppPool, with integrated Pipeline, .NET CLR v4.0,
If there's more info to supply please let me know, I'll update the question with the required info.
I have a separate frontend (single page application) which is utilizing HERE places API autosuggest feature. However, rest of the application logic which accesses HERE REST APIs is located at the backend side. These services are located on different cloud instances.
I can protect the API credentials by using the frontend SPA domain in "Secure app credentials against a specific domain" in the HERE project page. This blocks the API usage from the backend side. Is there a way to protect the credentials against both services?
You can try the HERE Serverless Apps approach. They provide security of AppID and AppCode: because it is in a central cloud Serverless Application being copied and used in every client application. Read more about it here https://www.here.com/en/aws-serverless.
Update: If you are not able to use Serverless, you can also add up to 10 allowed domains in your project in developer site.
I bypassed this problem by creating separate projects for frontend with domain limits and backend without.
Not an elegant solution, but it works, it's simple, and if I have to block a project in case someone hijacks the keys (everything sent through browser can be read by users) it's just some dynamic maps that wouldn't work until I update the site. Everything else is routed through the server.
I have a ASP.Net WebAPI service that is used by my AngularJS front end and I am making use of Owin and bearer token.
Now there is a need that we need to install an agent on the few of the client machines (developed in .Net core mostly) that is able to connect to our application and make similar calls. I can create a separate controller for this need, but want to host it in the same website.
How can I create a secure connection between this agent and the ASP.Net server hosted on Azure?
Currently I am looking at generating a Token during the agent installation based on the client MAC address and giving it with each call, but I am checking if there are any better way to address this need.
Any help in this direction is welcome.
Regards
Kiran
It seems that you’d like to enable only valid “agents” that installed on the client machines to communicate with your server, if that is the case, Azure AD provides Native Application to Web API authentication scenario (a native application that runs on a phone, tablet, or PC needs to authenticate a user to get resources from a web API that is secured by Azure AD), you could refer to it.
Is there a (new) way to configure which fields should be logged by IIS in Azure (Web Role / Website)? For example, I don't want the server ip or the http referrer to be logged.
I only found an older post describing two approaches:
programmatically set site.LogFile.LogExtFileFlags in the web bole entry point (this requires the web role to be run in elevated mode);
running an appcmd-based script (did not work - infinite wait, sites were never ready :P, perhaps the set-up sequence had changed in the meantime).
You can also do this using your web.config file.
See: http://www.iis.net/configreference/system.webserver/httplogging
For Azure Websites (Web apps) you cannot configure IIS logging fields.
We are building our public facing website on Wordpress and on a Linux server. The user will be logging into the WordPress site with OAuth2. Our data and API is going to be built on an ASP.net MVC4 server. I have a couple of problems that I need to resolve and am trying to figure out the most secure way to Authenticate on the IIS server.
1. I need to authenticate with Wordpress.
2. I need to associate customer numbers to the login from 1 above.
3. Somehow I need to then be able to use that associated customer number and some for of Authentication to allow the IIS server to service the requested API.
Some thoughts were to store some kind of UUID for each customer number and store it on the WP and IIS server and then when the request comes in to IIS confirm that the passed UUID matches what was issued to the WP server in step 2 above. My concern is though that this UUID could be compromised/forged at a later time and that UUID could be used to make calls to the API on the IIS server.
What is the best way to implement security on the IIS server that allows the customer to login only on the Wordpress server?
I'm currently using a Custom Http Authentication Module in IIS, so when I need to consume the web api from WP, I follow this approach: I build petition with my custom authentication rules (example: you can use a custom http header, o something else to pass credentials), in web api side, I check credentials (using http authentication module, of course), if everything is fine, http authentication module allow requests, if not, It deny request.