Der findes en nyere version af resourcen her

OIOSAML.NET version 1.7.10

Releasedate: 2014-06-27


The OIOSAML.net component now supports verification of XML documents signed with SHA256 signature. However, this functionality is only supported in .NET 4.0 or greater.

The OIOSAML.net component now uses a custom session implementation instead of the ASP.NET session. Note that session timeout is now configured in the federation config section. For further information see the session provider section.

The OIOSAML.net component now supports SOAP logout. Thus, users can be logged out through a back channel. SP must now, in the beginning of each user request, check using the Saml20Identity.IsInitialized() to verify if the user is still logged in or has been logged out using SOAP logout (if it has been enabled).

The IAction interface has been expanded with an extra method called SoapLogoutAction(AbstractEndpointHandler, HttpContext, string) which is called when a SOAP logout request is received. It is still necessary at each HTTP request to check whether or not the user has been logged out by a SOAP logout request as this is not possible at the time the implementation of SoapLogoutAction is called.

Filer og referencer

Titel Type
oiosaml_net_1.7.10.zip application/octet-stream
Net SAML2 Service Provider Framework.pdf pdf


Asger Jensen

After upgrading from 1.7.9 to 1.7.10 in my service provider I can no longer log in. I can see its CheckReplayAttack that fails, because the session is empty for the user, after the login succeeds in the demo IDP and user is redirected back to the site.

If I replace the 1.7.10 dll with the 1.7.9 everything goes back to working order.

I'm using the 1.7.10 IdentityProviderDemo.

Any clues? 

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


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"


- 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


That makes perfect sense. 

Thank you.