Der findes en nyere version af resourcen her

OIOSAML.NET version 1.7.8

Releasedate: 2013-11-08


Removed the dependency on log4net by defining an IAuditLogger interface. The framework allows the implementor to define and use their own implementation for audit logging (see section 14 for more on audit logging).

Removed the refreshing of idP’s on every federation request. This is implemented using FileSystemWatcher on the folder that contains the idP metadata.

Fixed bug about Single Logout failing when session had expired. The framework now sends a successfull LogoutResponse even if the session has expired.

NOTE: Changed to the public API:

  • dk.nita.saml20.config.IDPEndpoints.Refresh() method is no longer public
  • dk.nita.saml20.config.IDPEndpoints.metadataLocation changed to a property dk.nita.saml20.config.IDPEndpoints.MetadataLocation

Filer og referencer

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

Problem setting up one web with multiple customer urls.

Henning Hetland


I am implementing an integration in our web-solution towards feide to allow students and teachers to log-in to our site. I am facing a problem with the way we have organized our site-structure on our servers. I am very poor at explaining, but I'll try my best:

We have multiple servers with the same version of our website and a load-balancer spreading the load in between those. Every customer have a dedicated URL to our site something like this:



https://ourweb.no/website/customer3 etc...

I have no problem setting up one customer, exchange metadata with feide and log-in using oiosaml.net. (However I did have to alter some parts of the code which is why Im still on version 1.7.8...I dont think my changes are relevant to this problem). My problem starts when trying to use oiosaml.net with multiple customers.

My first solution was to set up the webserver with a dedicated feide-website that hosts the .ashx files. Something like


and we would reach the metadata with the url


that I send to feide.

I have updated the web.config files on each server to map to the feide-website. My hope was that from customer1 be redirected to the feide-web to login and be transferred back to customer1-site when feide are done with their part. However a function called CheckReplayAttack() does a check on a session-value on a expected session-value and throws a "Replay Attack" message. This happens after Feide have acknowledged my user and passed control back to me...just to be clear.

I then thought we have to a insert <ServiceProvider>-element in web.config for every customer to use feide and exchange metadata with feide for each and every one. However since this isnt an array-element I can dismiss that idea (and Im kind of glad). As a final try I just added "https://ourweb.no/website/customer1" to AllowedAudienceUris in addition to the one in our <ServiceProvider> element pointing to our feide-website which also did not work.

Do you have any suggestions? Am I doing something fundamentally wrong somewhere? Hope you understand my problem and can help!


Henning Hetland

Hi Henning

We need some clarification. When you talk about customer1 and customer2 are you then talking about individual sites or sub-paths to a single site (one site equals one ServiceProvider)?

If they are individual sites then they are treated as individual ServiceProviders in OIOSAML and you must register metadata for each of them at feide.

However if you are using one site and sub-paths for the customers then you should be fine – and we are looking at a different problem. In that case, we would need a StackTrace to investigate.

Best regards,
Søren Pedersen

and thanks for quick response! In our production environment we have x customer applications located under one website in IIS. In addition we have one "feide-application" working as the global metadata provider that supplies the metadata we sent to feide. They all have the same physical path and thus the same web.config. The web.config file is updated with ServiceEndpoints that points to the feide-application.

I have set up my local environment to try to recreate our production environment. Our production environment is not currently set up in a way I can recreate the error in a easy matter (our customer is currently set up to be the feide-application which works fine). Here is the stacktrace:

dk.nita.saml20.Saml20Exception: Your session has been disconnected, please logon again at dk.nita.saml20.protocol.Saml20SignonHandler.CheckReplayAttack(HttpContext context, String inResponseTo) in c:\tfs\Mikromarc 3\Flamingo\Main\src\3pComp\dk.nita.saml20\Protocol\Saml20SignonHandler.cs:line 324 at dk.nita.saml20.protocol.Saml20SignonHandler.HandleResponse(HttpContext context) in c:\tfs\Mikromarc 3\Flamingo\Main\src\3pComp\dk.nita.saml20\Protocol\Saml20SignonHandler.cs:line 263

Debugging the code context.Session[ExpectedInResponseToSessionKey] is null.

However when trying this just before christmas this has not been the case...Im pretty sure context.Session[ExpectedInResponseToSessionKey] had a value but the check
if (inResponseTo != expectedInResponseTo)
equalled to true and fell through to a replay attack.

I should also point out Im using using the ReturnURL parameter to login.ashx as I need to pass on some querystring parameters. I'm not sure if this is relevant to this problem.

Hope I am more clear now!


Henning Hetland

Hi Henning

Could you please attach your Web.config file so we can have a look?

Best regards,
Søren Pedersen

Here you go


Henning Hetland

Hi Henning

We can’t see anything wrong in the Web.config file – with the limited knowledge we have of your setup.

But using multiple servers and a load-balancer, you are aware that you must use sticky sessions for this to work or have a distributed session cache of some sort!?

Best regards,

Søren Pedersen

It's good to hear the web.config file seems ok at least. The error is reproduced on my local developer environment. It is not set up with load balancing. Just a regular webserver with several applications.


Henning Hetland

Hi Henning

If you have made a plain vanilla installation:

  • One Service Provider and one IDP

  • Set all endpoints correct

  • Installed all the right certificates

  • Exchanged the right metadata

Then you should be good to go – you should definitely not get a Replay attack exception… unless you put something in the middle.

The only scenario that I can think of right now, is a scenario where you tried to implement a distributed cache yourself having to set some sort of SessionId in a secure session cookie, and then use normal http (this would wipe out the value of the SessionId since secure cookies won’t be send over normal http) – but this is just me thinking out loud, and probably not the case… but this would give a Replay attack exception.

So, I’m afraid you will have to attach a debugger and find out yourself where the session gets whacked.

Best regards,
Søren Pedersen