Hi Asger

I am not able to reproduce it in our test environment.

Does the "oiosamlSession" cookie exist when request is send to SP after IdP login?

Best regards

Kasper Møller

Hm, after an involuntary reboot I can no longer replicate the problem. I thought I had tried all the usual things. 

Oh well; please disregard.

Ok, so it happened again. And again I was able to resolve the issue by downgrading.

I rebooted, cleared caches, cookies etc, and captured the following from the browser network log (see attachments).

It seems the oioSamlSession changes value underway.

Hi Asger

Have you found any pattern I can use in order to reproduce the issue?

What do you see if you set a break point in line 21 and 23 in dk.nita.saml20.session.inproc.InProcSessions?

Does SessionId have a value?

If yes ... does Sessions contain the SessionId?

I guess not since a new oiosamlSession ID is generated. But it would be nice to know if it is because SessionId is null or Sessions does not contain SessionId.

A session should only be removed if it is removed on purpose or the session is timed out. I use the word "should" because something else could be the reason in this case :)

I assume you use standard timeout ... which is 30 minutes.

Are you able to do a Fiddler recording and attach it on this thread?

Best regards

Kasper Møller

I've attached the fiddler feed below.

I set the breakpoint you asked for, and stopped and started the project again.

on line 21, on first request, the SessionId is 

SessionId = {3c719b53-4786-429b-831e-faa264b3f911}

for second request (from TransferClient), it is the same.

I then get redirected to IdentityProviderDemo, and type in a valid username and password, and get the third request on line 21 from CheckReplayAttack

The session id for the third instance is 

SessionId = {4cfe735d-3cb7-49cb-bb97-99f6ebdc8e13}

In all three instances, the sessions object contains an object on line 23.

Hi Asger

I will look into your recording and get back.

If session id is always set ... then we need to set a breakpoint at line 51 in

dk.nita.saml20.session.inproc.AbstractSessions.

This is the only place where new sessions are generated. From the call stack is should be possible to see when this happens.

Best regards

Kasper Møller

I am running from VS2013 onto a local IIS. 

I can see when I restart the project, the Sessions object contains a number of entries (in my case 9). I'm assuming this is cache data from the Application Pool held by the local IIS.

I tried restarting the application pools for both the service provider and identity provider, and checked the Sessions count. It contained 3 items, two of which had keys 

- Key = "__AppStartPage__~/_appstart.vbhtml"

and 

- Key = "__AppStartPage__~/_appstart.cshtml"

and a third which had a GUID as key and had value InProcSession. 

I added the breakpoint in AbstractSessions as requested.

First, it fires on

> dk.nita.saml20.dll!dk.nita.saml20.session.AbstractSessions.Current.get() Line 51 C#
dk.nita.saml20.dll!dk.nita.saml20.protocol.Saml20SignonHandler.SendRequest(System.Web.HttpContext context) Line 189 C#
dk.nita.saml20.dll!dk.nita.saml20.protocol.Saml20SignonHandler.Handle(System.Web.HttpContext context) Line 99 C#
dk.nita.saml20.dll!dk.nita.saml20.protocol.Saml20AbstractEndpointHandler.ProcessRequest(System.Web.HttpContext context) Line 49 C#

And then again from 

> dk.nita.saml20.dll!dk.nita.saml20.session.AbstractSessions.Current.get() Line 51 C#
dk.nita.saml20.dll!dk.nita.saml20.protocol.Saml20SignonHandler.CheckReplayAttack(System.Web.HttpContext context, string inResponseTo) Line 317 C#
dk.nita.saml20.dll!dk.nita.saml20.protocol.Saml20SignonHandler.HandleResponse(System.Web.HttpContext context) Line 260 C#
dk.nita.saml20.dll!dk.nita.saml20.protocol.Saml20SignonHandler.Handle(System.Web.HttpContext context) Line 84 C#
dk.nita.saml20.dll!dk.nita.saml20.protocol.Saml20AbstractEndpointHandler.ProcessRequest(System.Web.HttpContext context) Line 49 C#

Hi Asger

I can see what happens from your Fiddler trace.

You are not running https. The oiosamlSession cookie is secure and is not transfered to the SP with each request. Hence, a new one is created with each request.

Previously the ASP.Net session state was used. This cookie is not secure as it can be used for many other purposes than security. However, oiosamlSesssion cookie is only used for security purposes and therefore it should always only be transfered over https.

The change of implementation from ASP.Net to custom session implementation was needed in order to be able to support SOAP Logout.

Best regards

Kasper Møller

Ah,

That makes perfect sense. 

Thank you.