I'm looking for best practice advice/guidance (perhaps from Microsoft?) regarding denial of service (DoS) protection/mitigation for ASP.NET Core web applications.
The main two options I have found so far are:
AspNetCoreRateLimit (ASP.NET Core middleware)
Dynamic IP Restrictions (IIS module - assuming the site is hosted in IIS).
It seems like there are a number of pros and cons to consider when choosing one of these options over the other, so it would be good to understand what those are, and indeed if AspNetCoreRateLimit is intended to be used alongside Dynamic IP Restrictions or not.
Also note that AspNetCoreRateLimit is not part of ASP.NET Core releases from Microsoft, therefore I'm curious to know what Microsoft's official guidance is.
If you have a public facing website and want to prevent DDoS, doing it outside your ASP Core app would be the best method. You should investigate services like ClouldFlare.
Related
Was Kestrel present in .NET Framework or was it developed specifically for the ASP.NET Core?
I was not able to find an answer to this question by just googling, so I decided to ask it here. I need it because I am intended to work with the ASP.NET Core and would like to know the history of development better, because knowing it allows to better understand the decisions made by developers.
In order to give an official answer to this question, I copy here comments from #AnkushJain and #andrew-morton:
Kestrel is not available for .NET Framework. It is born with the origin of ASP.NET Core.
[In addition] since Kestrel is not a fully-featured web server, you should run it behind IIS or NGINX. It was designed to make ASP.NET as fast as possible but is limited in its ability to manage security and serve static files.
Windows Identity Foundation (WIF) is around for a while, may be 5 to 7 years or more!, now Microsoft made WIF part of .net framework (4.5) itself. As we know WIF is a middleware for building identity aware applications.
As the trend on the web technology is changing, we have now need to incorporate multiple other identity providers (Google, Facebook etc.), in our application.
Now the industry got other Middleware technologies like OWIN, ASP.NET Identity etc.,
My Question,
Is still the WIF relevant and do we need to consider using it for new projects?
Or
Do we need to implement OWIN as alternative middleware? (As I understand Microsoft is betting on OWIN / KATANA moving forward).
Please share your thoughts.
For new projects I highly recommend considering Katana and ASP.NET 5 OWIN middleware.
WIF remains supported as part of the .NET framework, however we stopped adding new features long ago - all the innovation has been poured in Katana and OWIN middleware in general. Also, we like to think that the OWIN middleware is significantly easier to use :) Again, if your project has legacy aspects that impose the use of WIF, you can go ahead knowing we'll support you: but if you have any chance of choosing, the OWIN middleware is the best path moving forward.
Totally agree with #vibronet but to answer the question - yes - still relevant.
There's a ton of WIF out there - I support lots of customers who still use it.
OWIN is easier to use but the nice thing about WIF is that everything is in the web.config so the details are more explicit and easier to change. However, that comes at the cost of a fairly steep learning curve.
Refer: OWIN : Differences with WIF and WIF : Wrappers around protocols.
As per the links:
"You can think of OWIN as MVC and WIF as Forms. Forms are still supported but all the new whizzy features and all the code samples relate to MVC.
It's important to note the neither OWIN nor WIF are protocols - they are the wrappers around the protocols. The protocols underneath both are identical."
Also consider we have moved some of the functionality of WIF into an open source project we refer to as Wilson. You can check it out here: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet
Advantage of using WebAPI as ProjectType over InterNet Application in asp.Net MVC?
Is any other use of WebAPI and why it's introduce in MVC4?
To name a few :
ASP.NET web api can be selfhosted outside IIS
ASP.NET web api is not specifically geared towards browsers...
ASP.NET Web api makes making a (level 2/3) RESTful webservice easier
I think that the biggest advantage WebAPI has over other solutions is the built in support for different formats such as XML , JSON, and the relative ease when adding your custom formats. Another advantage worth mentioning is the ability to support extensive OData without coding as much (can be as simple as returning IQueryable), and the support of objects.
That said, WebAPI still have scores of issues that need to be resolved, I keep getting questions from developers that find WebAPI can't resolve their methods, parameters that always result with NULL etc... so I wouldn't swear by it yet, we are all hoping to see a better version sooner rather than later.
I am learning to create RESTful services using WCF. There are a myriad of options to choose from. I am confused as to what should i use.
1.)REST Starter kit - Seems to be obsolete
2.)WCF WEbhttp service
3.)WCF Web API
4.)ASP.NET web api
I dont want to use ASP.NET MVC to build RESTFul services. I dont like the idea of services being in the same solution structure of a presentation layer. So what is it i should use?ASP.NET web api seems to be having going down the MVC route where the requests are handled by a controller which i feel does not fit into a "Service" terminology.
Take a look a that
Microsoft support for REST is moving to ASP.NET WebApi, but you are still free to use webhttpbinding to build your api if you want. The starter kit is no longer developed nor supported.
I don't get this part though
I dont like the idea of services being in the same solution structure
of a presentation layer.
You can build a webapi project in a different assembly than your web (presentation logic) project, and the solution it's only useful for you to keep all the things in one place, it does not affect the behavior of your projects/assembly, you can still use them/develop them independently. If you don't like the "style" of webapi (it's certainly "different" from what WCF developers are used to) it's another story.
Classic Asp (as I understand it) is not really “encouraged” by Microsoft (e.g. there is no classic ASP project in VS) and essentially is a collection of asp pages that contain HTML and some kind of scripting. There’s no .config file as such.
That being the case., can classic ASP sites be integrated into WIF?
How do you “force” the application to authenticate using a STS? (There’s no .config file for FedUtil to change).
How do you approach the problem of a large customer that still has a lot of legacy classic ASP sites and wants to move to federated authentication using a STS?
P.S. There is a reference on the Internet i.e. “In IIS7 you select the URLAuthorisation Module and untick the use for managed code only setting. I have used this to protect static files and a cgi exe, so I assume it will also protect .asp files too”.
I’m still confused as to where the STS comes into this solution? How does IIS 7 know where the STS is?
The issue here is that as you are using ASP, IIS doesn't run in pipeline mode. Therefore, it won't execute the HTTPModules required by ADFS. (Or any .NET httpmodules...)
In your case, I have two idea (both aren't pleasant, I am afraid)
You could implement the WIF protocol in ASP. It's documented. Well, you certainly could do it, but beware of errors in your implementation, which could damage the security of your application. The bright side is that you will be able to leverage all the WIF goodies in your apps.
You could attempt to host CGI/ ASP in an IIS HttpModule, in pipeline mode. Perfs would probably decrease, and you would need to send to CGI all the required request infos (and server parameters). It was the idea of this guy. I don't know if he succeded.
The first proposition is probably the good one. Hem. Good luck, WIF isn't a trivial piece of code. (Even if understanding the protocol is not very difficult. As always, hell lies in the details)