The case of broken SignalR Authentication.
I’m playing with a sample project that utilizes ASP.Net MVC, WebAPI and SignalR. My need is to add a very basic authentication mechanism to show how to handle identity propagation to endpoints when using NServiceBus and messages.
Something similar to the WS-Federation on top of NServiceBus scenario but using a much simpler authentication mechanism, in the end it’s a sample that aims to show how to propagate authentication information not how to create and use authentication.
The sample is based on OWIN so I started by adding the following configuration to my
With my surprise I immediately run into the following issue:
What was happening is that despite the fact that is claimed to be supported the authentication engine was not regenerating the incoming
ClaimsIdentity when dealing with
SignalR requests. What was really strange, as you may notice from the screenshot, is that the APS.Net authentication cookie is available in the incoming request. So something else was preventing the
ClaimsIdentity to be created.
With great surprise, after reading hundreds of SO questions and blog posts talking about
SignalR authentication support, most of them suggesting that the only solution is to move to a Bearer Token based authentication, I discovered, by accident, that the solution was as easy as:
Simply, at OWIN configuration time, be sure to configure
SignalR after the authentication configuration. Once done the
SignalR incoming request principal is populated as expected:
As pointed out by Stéphane in this Twitter conversation it’s the OWIN expected behavior: the order in which configuration options are invoked determines the order in which OWIN middlewares, managed by those configuration options, are added to the OWIN pipeline.
Based on Stéphane’s last comment I’m not the only one bitten by this. Shouldn’t the API be more explicit?