Tl;dr: You can use NTLM authentication without relying on IIS or HttpListener in OWIN projects by using my OWIN autentication middleware: more information on my Github project: Pysco68.Owin.Authentication.Ntlm middleware. It’s working flawlessly with ASP.NET Identity 2.0! And there’s a Nuget package too!
As you may have noticed, I’m relatively busy these days with things like OWIN and surrounding technologies. All there shiny and new things that just fit together so well. And then you have customers just requiring plain old things like NTLM for their latest shiny intranet application.
I bet this sounds familiar to most software developers out there! To put you a bit more in the situation; here’s the setup I dealt with:
– ASP.NET WebAPI 2 on OWIN combo
– ASP.NET Identity 2.0 (roles, claims etc…)
– EntityFramework 6 with MariaDB as underlying DBMS
– oAuth login providers of all kinds
– Plain application accounts (individual accounts)
– two factor authentication as a nice-to-have requirement
And then came “we need NTLM when accessing the back-end from our intranet”. So what do you end up doing? Well you write your own NTLM-Authentication middleware for OWIN and ASP.NET Identity 2.0.
By just reading the above list you probably understand why I really wanted to stick with Identity 2.0. All of the nasty things were already there.
Configuring IIS to just authenticate differently when a request comes from the intranet? Doable, but then how to wire it all up with the roles and claims. And how to do the linking to existing user accounts usable from outside the intranet? Pure mess!
Writing a second back-end for intranet users? Not an option either!
Implementation details
The hard part was mostly to figure out how to implement a clean OWIN authentication middleware. And I was running in circles for a few days. At that point really big HUGE kudos to Anders Abel for his great post on how to “Write an OWIN authentication middleware“. The other difficulties were tied to the interaction with the Win32 API for the actual authentication and to the many-round-trips handshake . At this point many thanks to Alexey Shytikov for his NTLM authentication implementation for NancyFX!
Here are the key features:
- It is a passive middleware (one of your controllers has to issue an authentication challenge for “NTLM” to trigger authentication)
- It’s relying on the standard ASP.NET Identity 2.0 Cookie based authentication
- Thus it’s performing relatively well (only one time authentication round-trip – three requests – then it relies on the session cookie)
- your code has much control over what’s happening (you can define a callback to restrict authentication to a certain domain or group for example)
- No more IIS/HttpListener magic
Using it
You’ll find the full fledged example on the Github page, but it boils down to installing the Nuget package, some lines of configuration and a route to trigger the NTLM authentication.
NTLM Security considerations
NTLM is evil stuff! Seriously. Don’t ever use it over unsecured transport! Never! Ever. I really couldn’t emphasis this more! The authentication protocol and the used cryptographic mechanisms have numerous known flaws. So protecting your user’s identity should be top-of-the-list priority. Furthermore there are known attack vectors targeting the pseudo-random number generator and the challenge/responses generated by the protocol. Some were addressed but as always the deployment of the patches is poor at best. So please don’t every make use of this in untrusted environment!
Bottom line
I hope some of you guys (and girls!) will find the Authentication provider helpful if you end up in such a situation. Feel free to ask any question in the comments below! Oh, and btw. as always contributions, pull requests and bug reports are welcome over at the Github project!
