IISMiddleware shouldn't do automagical authentication

[kevinchalet]

Another oddity I discovered when torturing my ASOS port: IISMiddleware automagically populates HttpContext.User for every request (and you can't even disable it).

It's extremely weird, 'cause it's something that is already done by AuthenticationMiddleware, so there's really no reason to do that again in the IIS integration stuff.

/cc @Tratcher @HaoK

[Tratcher]

It has always done this and so has WebListener, disabling it now would cause regressions. The hosts have been treated a bit different in that the identity is available for you from the very beginning of the request. You don't even need the auth middleware for this host auth to work (in most cases).

[kevinchalet]

It has always done this and so has WebListener

With a fundamental difference: you could disable it in 1.x: https://github.com/aspnet/IISIntegration/blob/1.0.0/src/Microsoft.AspNetCore.Server.IISIntegration/IISOptions.cs#L17.

... in 2.0, you can't.

And if it did that, it was because of the inherent design of the authentication middleware, that all used to set HttpContext.User when active authentication was enabled.

Now that this concept is gone, there's no reason to be inconsistent here and treat the "host" handlers differently than the other ones. Specially since it leads to the fact that 2 handlers can set HttpContext.User for the same request, which was the major reason for changing the authentication design in 2.0.

[kevinchalet]

@Tratcher any chance this could be fixed in 2.0? It would surely be a blocker for me, as I only use WIA with passive authentication (it's way too risky to enable automatic authentication).

[Tratcher]

We're almost out of time for 2.0. We looked at this today and decided requiring the auth middleware for windows auth to work wasn't a regression we're willing to make.

At best we could put AutomaticAuthentication back to toggle setting HttpContext.User, but it's worth noting WebListener never had that option.

[kevinchalet]

Then I'll boycott 2.0 for apps using WIA as the non-primary authentication mode (typically, any ASOS-based authorization server allowing users to connect via WIA or another provider).

I'll never take the risk of seeing a XSRF attack made possible in an API controller because of this insane design decision. You realize that it will set HttpContext.User even if you configure a totally different scheme in DefaultAuthenticateScheme, right?

At best we could put AutomaticAuthentication back to toggle setting HttpContext.User, but it's worth noting WebListener never had that option.

I've never used WL for WIA anyway. The fact you couldn't customize the display name (harcoded to Windows:NTLM and Windows:Negociate... WTF?) was totally blocking for me.

[kevinchalet]

And BTW, it really makes no sense: automatic authentication will be always enforced, but not automatic challenge that will require manually setting DefaultScheme or DefaultChallengeScheme

I know 2.0 is really near, but that's not a reason for adopting a bad design. You must consider the security and functional aspects of this decision (and optionally, take consistency into account...)

[davidfowl]

This is too big of s breaking change to make this late. I agree that it should be fixed but windows auth has worked like this since forever. Do think it's worth migrating people to do things the right way by putting the middleware in but the old behavior needs to stay the same for now

[kevinchalet]

So you were fine breaking tons of cool scenarios that used to be possible with the authentication middleware in 1.0 (e.g branching) but asking folks that want to use WIA to add app.UseAuthentication() is totally unacceptable? 😅

At this point, wouldn't that be simpler if AuthenticationMiddleware was automatically registered in the pipeline?

[davidfowl]

but asking folks that want to use WIA to add app.UseAuthentication() is totally unacceptable?

Yes.

At this point, wouldn't that be simpler if AuthenticationMiddleware was automatically registered in the pipeline?

Yea, it would be, but that's a change that's needs discussing as well. We could do it in the WebHost.CreateDefaultBuilder uber method but that leads to discussions around what if you want to run before it. We'll see if it makes sense in 2.1.

[kevinchalet]

At the very least, we need an option to disable the automatic authentication. It's too risky.

[davidfowl]

Seems like something we could add in 2.1. The default windows principal isn't new behavior.

[kevinchalet]

The default windows principal isn't new behavior.

Read the first posts, you could disable it in 1.0. It's clearly a regression.

[davidfowl]

@Tratcher we should add the AutomaticAuthentication flag back since IISIntegration and WebListener are special in this regard WRT windows authentication.

/cc @muratg @Eilon

[kevinchalet]

I'd be fine with a flag, even if that's not consistent with the rest of the stack. But as I said, it won't really work as you expect. The Negotiate dance won't be automatically started so you'll always get a null identity until you update the default schemes OR explicitly call ChallengeAsync("Windows").