I'm running more than 10 dotnet core applications in IIS. I need to add a middleware in all those applications. How can I add the middleware in all the applications hosted in my IIS without touching the application code? I'm not allowed to change the code and redeploy each application in IIS. Is there a way to achieve this.
I implemented the middleware to print all the incoming requests based on some conditions. I don't want to use IIS logs
According to your description, I suggest you could consider writing a customer module to achieve your requirement.
An HTTP module is called on every request in response to the BeginRequest and EndRequest events. As a result, the module runs before and after a request is processed.
You could check the request at these module and write logs into it. More details about how to write httpmodule, you could refer to this article.
You cannot, there is non-code based way to wire up middleware. You need to change all 10 applications. There's one feature that may be interesting though to look at IHostingStartup as a way to provide cross cutting auto wire up for common application logic.
Related
Currently, I use Consul for storing App Settings and Configurations for ASP.NET Web application. But I got performance issue when every request need to query from Consul service.
I see Consul have watch feature in server but I did not know how to use it in Windows and how to announce Web Application know when key/value data change
As far as I know, watches allow you to invoke some handlers, which must be some executables. So you have to provide some API in your web-app to allow remotely call to reload configuration, for example, some kind of REST web service or something else, what can be called from outside.
Next you have to create some executable script on your agent's host and provide a logic to call this remote API of your web-app.
And finally you have to register a new watch, providing your script file as an executable.
I have looked into the iis logs and can see a post verb for calls made to asmx services. Is there any way to identify the parameters passed when calling the web methods. I am analysing an application in production and this information will be really useful. While no code changes can be made, I have permissions to change iis log settings.
IIS includes no ability in its logging to log POST fields (or the content of the request body).
To log that kind of data, easiest to add to to the web application's (ie. global.asax) BeginRequest event.
If you have receiving significant data (eg. file uploads) you might want to think about how much data that will generate.
Wondering about how to do the following efficiently, securely, and in a fashion that won't have us tearing our hair out because of overcomplication: we have an ASP.Net site that uses forms authentication and would like to implement some WCF restful web services that can be called from the first site, provided the user calling them has been authenticated.
We'd like to host the WCF RESTful service in a different web site from the ASP.Net site. Both sites will be in the same domain (my-domain.com for instance).
I've been reading up on the various bindings in WCF and am not sure if webHttpBindings are the way to go here (they being the most REST-friendly, but can they accommodate forms-authenticated users?)
I'm looking for suggestions and references as much as code, but I'd love to know where to start and what to look for, what's possible and what isn't.
Every time I read about WCF authentication it seems to inevitably sluice into discussions about WS-security and X509 certificates, and I don't know that I need all that for what I'm doing? What I'm really looking to build is a series of WCF restful services that only respond to forms-authenticated users. If that's not possible without diving deep into WS-Security and X509 then so be it, but I'd like to keep it as simple as possible.
Note: I asked a somewhat similar question about a month ago, but have decided to go with forms authentication.
If you are not calling your WCF services from the browser, then you don't even need to secure them. Just call them from your ASPX code to a non-public site that hosts WCF. Or use X509 certs in a server-to-server mode.
If you do plan to call them from the browser, then things get more complicated. In this case, you may want to ditch WCF and look at with Web API included in the MVC 4 beta release to build your REST services.
http://www.asp.net/web-api
Have your javascript generated from the code behind. If Page.User.IsAuthenticated, render the ajax script. If not, render javascript that alerts the user that they need to be logged in. If you don't want the user cutting the javascript out of the browser source and running it later, when they are not authenticated, you will need to generate a token based on the session ID, that can be passed between the site and the service.
Is there a way I can configure my asp.net web service to work with only some applications? In other words, I am saying "only these applications have access to this web service and can therefore use it. Others can't".
When other applications tries to discover the service, it shouldn't even show up, or at least it should conceal it web methods.
PS: I am wondering if this scenario is even applicable to the whole concept/domain of web services? Plus, I am asp.net 2.0 oriented, but you can give me answers based on higher framework versions, but be specific...Thanx in advance.
I'd look at WCF (after all ASMX web services are now regarded as legacy)- there is a whole load of options regarding security configuration. Patterns and Practises have Security Guidance here. It sounds like you are most interested in authorization, so read about Access Control Mechanisms.
Also to make the service non discoverable in WCF you just don't expose a MEX endpoint. That doesn't stop clients connecting, but makes it hard for people to work out how to call the service. That said you can also secure the MEX endpoints so that is another option.
Can you put some authorization or login method to initialize usage of webservice?
We control usage of services by explicitly logging into the webservice or provide some authorization token.
I am building a web based application written in ASP.NET and Flex. One of my biggest challenges is implementing security for the application in a flexible and maintainable way. This challenge is compounded when different technologies are involved. I'll try to describe what I have below.
The website is laid out as follows:
/mydomain.com/
Login.aspx
Default.aspx (hosts flex [.swf] application)
/Administration/
AddUsers.aspx
AddRoles.aspx
AddPermissions.aspx
etc...
/Services/
SecurityService.asmx
MapService.asmx
PhotoService.asmx
etc...
I am currently using forms authentication to secure the resources on the website. All pages/resources not in the /Services/ folder require an authenticated user and will be redirected to Login.aspx if they are not yet authenticated. The .asmx pages allow unauthenticated users. To secure these resources I throw an exception in the SOAP method. This avoids redirecting pages for SOAP web services which is not supported by any SOAP web service clients I am aware of. Finally, SecurityService.asmx contains a Login method to allow the Flex application to Login without redirecting to the Login.aspx page should the cookie expire for any reason. Because the cookie established is sent with any request to the server, including requests coming from the Flex application, this seems to work pretty well.
However, this still feels like a bad approach securing web services. I feel like I am using Forms Authentication for something it was not intended for. Specifically, I am concerned about:
This model will not work when the services are separated from the core website. This is a newly discovered requirement and I believe that Forms Authentication is not going to work well (if at all) without a lot more modification and trickery.
Clients other the Flex may require access to the services. Some of these clients may not even be able use cookies. If so, this model immediately falls apart. This is not an immediate requirement but it is known that this is one of the long term goals.
We will eventually (hopefully sooner rather than later) move to a REST based architecture (vs. SOAP) so any solution needs to work for SOAP and REST.
So, my question is.
What are the best authentication and authorization mechanisms for securing an application built on ASP.NET, Flex, and SOAP or REST web services?
Note: I am actively looking into OAuth; however, I am having a difficult time finding complete examples from which to learn. Additionally, I need to be able to filter the data returned for a given user based on the permissions that user has, OAuth seems to remove the identity of the user from the token. As such, I am not sure how OAuth applies in a fine grained security model.
Others may disagree, but I actually don't see a huge problem with handling it the way you are now; that's probably how I'd handle myself, at least initially. One way or another, even down the road, you'll probably want to keep the Flex app aware of the authentication state of the session, so if that means checking the ASP.NET session token directly, or some other cookie you set when you set that one, it seems like a fine and reliable way to go.
I do see what you mean about the services redirecting, but even so, with forms auth, it's not so much the service specifically that's handling the redirecting so much as the ASP.NET app itself. Later, should you need to use a different authentication scheme, you can consider that scheme's specific implementation considerations. Unless you've got concerns about using forms auth in general, there's probably no need complicate your approach simply because of the Flex client and Web services.
I admit I don't work with web services much, but what about requiring an access key as a soap header parameter? Any client app which can communicate with a soap web service is likely to have a low level API to modify the soap request, and use of the access key allows you to (in theory) limit the use of the service. Google, Amazon, and several other providers use this type of authentication for their web services and it seems to work very well.
This article seems like it might be a good place to start...
The WCF Security Guide published on CodePlex may help you there, if you are using, or can use WCF.
There's also Microsoft's Web Services Enhancements (WSE) 3.0 which I believe implements some of the WS-* security specifications.
Hope that helps.
If you move your services to another place, then the standard ASP.net authentication cookie can be re-used if both web apps have the same machineKey in the web.config.
As far as I know, FLEX will honour the asp.net authentication cookies because it will make http requests through the browser, which will pass the http cookies (including the asp.net authentication ticket) like a normal http request.
Have you tried securing your website and services using normal asp.net authentication yet?
I think it's best to have independent authentication systems - even if there are relations between the user and the auth tokens on the back end. They are different beasts that have differing capabilities and demands.
Use the normal forms based auth for the flex portion. That is good.
For web services, you could create a login method that returns some auth token which is used by subsequent tasks to execute. Or add a few fields to your web services (posted in the header or as params) to use a userid/password combo for authentication each and every time.
A side note: I wouldn't rely on a soap exception to handle authentication problems. But you wouldn't need to worry about the redirection if you send an auth token or user/pass with the WS requests.
EDIT:
RE: Comment-
Ideally there is. There are products out there (Tivoli access manager) that service those needs, but they are expensive.
I gave this recommendation because it eases the pain of allowing access to alternative clients and as long as you designed the services correctly it's stateless. It also gives you finer grained control over data level access on the service side of things.
See Web Services authentication - best practices?
Dave Dunkin wrote:
The easiest way to handle it across a
variety of platforms is to use HTTP
basic authentication and HTTPS for the
transport layer. WS-Security would be
good if your needs go beyond simple
username/password but the support is
going to vary quite a bit between
platforms. HTTP authentication is
supported by every decent SOAP
implementation.
and my Custom HTTP Basic Authentication for ASP.NET Web Services on .NET 3.5/VS 2008.