Session Security Redirect Loop

[jlegan]

Andre,

I spent some time with Troy Hunt's latest Pluralsight video the other day and came across your project for the first time. I had been implementing most of this functionality myself but your project was a huge win in terms of portability and thoroughness of implementation so thank you very much.

Now onto what I am seeing. I had everything implemented in NWebSec with the exception of SessionSecurity and everything was working as expected. While I know this is not a defect in your code it appears to be an interoperability issue between my IdP (Thinktecture's IdentityServer 3) and the massaging that SessionSecurity is performing on the identity. Without SessionSecurity in the web.config I get redirected to my IdP, authenticate and can login without incident. When I say without it in the web.config I mean entirely. Simply setting enabled="false" does not allow me to login.

I can walk the AuthorizationCodeReceived notification of the OpenId event and see that the AuthenticationTicket is written out correctly. I then receive a RedirectToIdentityProvider event as something is invalidating the User and I suspect it is in the massaging of SessionSecurity.

Are there any known defects or "gotchas" when using OIDC, how the authentication tickets are written, etc... that would allow me to move past this?

Thanks,

Jim

[klings]

Thanks for the positive feedback!

NWebsec.SessionSecurity is only concerned with session ids, and does not alter the identity in any way. In order to create session ids per user, it will read the IsAuthenticated and Name properties on the HttpContext.Current.User.Identity.

If you set enabled=false, the custom SessionIDManager will simply call the base class implementation so it's a bit weird that this should cause any issues.

Could there be some other code that could be causing the issue? Anything that checks for something on the session object?

I'm pretty sure it's not IdentityServer's fault, so we can look into it here instead of in IdentityServer/IdentityServer3#1765.

[jlegan]

I will take some time to get a test project created on Monday. I recently created a test project for Brock for a nasty Katana Idv3 bug with HTTP logging so I should be able to turn it around very quickly.

The MVC project at present is fairly vanilla. There is some cookie manipulation and some interesting things happening in some owin middleware but nothing that would jump out as session manipulation.

This came to light after a recent AppSpider scan of the site which picked up session fixation vulnerabilities in an app that is under development. I will also grab your source on Monday and see if I can see what is causing the issue.

Thanks,

Jim

[jlegan]

In looking at the code I see that we are shoving items into the Owin Context (i.e. OwinContext.Environment["TenantData"]). Would that have an impact? We are not using the Session object anywhere in the code base. I am going to grab your source now and see if I cannot figure out where it is happening.

Thanks,

Jim

[klings]

The session security library is contained in a separate project, and has no relation to OWIN since it's a thing of "classic" ASP.NET. It's hidden in the SessionSecurity solution folder. The entry point is the AuthenticatedSessionIDManager, which is called into by the framework when the session id manager is specified in web.config.

[jlegan]

André,

I ran a little bit behind today but tomorrow first thing I will get a sample project working using a vanilla Idv3 server as the IdP and an MVC project using the SessionSecurity source and make sure I can reproduce it. Just so that I make sure I am not barking up the wrong tree, where exactly under the hood does the session come into play in an OWIN based MVC app? I know that probably sounds like a foolish question however in all of the reading I did over the weekend I found a tremendous amount of conflicting information. I am very familiar with Session's usage in traditional ASP.NET (webform) development but have never used nor come across is in straight MVC development.

Thanks,

Jim

[jlegan]

Andre,

I found post today when poking around. I will look into it in the AM as well (half way down is where progress is made)

https://github.com/IdentityServer/IdentityServer3/issues/294

Thanks,

Jim

[jlegan]

Adding this to my Global.asax fixed the issue.

  protected void Session_Start(object sender, EventArgs e)
        {
            // required in order to allow the NWebSec session security package to work when using OIDC and cookies for authentication.   
        }

[klings]

Hmm, that smells like an ASP.NET/Katana bug. Thanks for investigating!