We have been using OIOSaml.net for awhile now together with an external Identity Provider supporting e-id, BankId, Telia E-leg, and so on.
This has worked well and we are now trying to do SSO between our different web applications. We have a link in one application (service provider 1), the user is logged in using OIOSAML and our IdP.
In this application a link is supplied, and when the user clicks this link a GET is sent to our IdP, telling them which service provider (our other web application, service provider 2) to transfer the user to and sending a param sprelaystate which contains information to be used by service provider 2.
The IdP the POSTs a SAMLResponse and the RelayState to ServiceProvider 2, specifically a page default.aspx.
ServiceProvider basically is built like the demoapp with a SAML20SignonHandler . However the POST never reaches the SAML20SignonHandler as FormsAuthentication steps in.
Default.aspx is protected (location tag) and FormsAuthentication redirects to SAML20SignonHandler.ashx (the loginurl) but also adds a ReturnUrl in the form of a QueryString parameter.
This all of a sudden transforms this POST into a GET and all Form Values are lost, SAMLResponse and RelayState.
Needless to say this doesnt work....
Is there anyone who have tried a similar scenario?
Is it possible to do this using the OIOSaml.net Api?
Is there a way to loose the FormsAuthentication? It seems like a way to redirect the request to the SignOnHandler, I don't understand why though. Couldn't it be built like an ordinary HttpHandler and using path to set which requests to handle?
All help and tips are appreciated
Regards Jonas Rosqvist
Sorry, but I have little knowledge about the inner workings of OIOSAML.NET. I'm not sure I really understand what it is you are trying to achieve - "SSO between our different web applications"? If both SP's are using the same IdP (and federation) then what are you missing? Depending on what you expect from it, you might be crossing the very concept of SAML V2 Web SSO.
Why don't you just link to SP2 and have it do a (passive) authentication request, then you'll have the user logged in a the possibility to user whatever parameter you send along in SP2. From my current understanding I don't see the need for IdP initiated SSO.
Brian, thank you for taking the time to respond so quickly!
Your suggestion of a passive authentication might very well work but unfortunately we use IdP intitiated SSO in all other cases when we do SSO between us and partners. So the its a request from the product owner that we use the same teqnique.
We have however never been the recipient of such a request before. Our partners all use another api, ComponentSpace so unfurtunately no help is available from them.
We are now trying to bypass the FormsAuthentication module when the IdP POST the unsolicited SAMLResponse by letting the IdP Post directly to the SAMLSignonHandler. Perhaps this will work if OIOSaml supports unsolicited SAMLResponses. Will update status when tested, but until then all suggestions, tips, questions are welcome.
Well, now it works, the Posting directly to SAMLSignonHandler did the trick for the most part. Also since this is an unsolicited SAMLResponse sent from the IdP you have to be careful that you set all redirecturl correctly, they are otherwise set when creating the SAMLRequest.
First off congrats on your succes. Second what did you exactly do, altered the code or just the configuration?
I did look at little into IdP-initiated web SSO, and most certainly SAML V2.0 (still) supports this, but it's not used in our OIOSAML profile and hence I would not guarantee support for it.
I does resemble a scenario I recall from the US eAuthentication with a central portal providing links between different service and identity providers. To have it working I guess you need some kind of URL-scheme (template) for the IdP to have it send the unsolicited SAMLResponse to the intended service provider, and a target url?
For others interested I suggest to have a look at the SAML V2.0 Technical Overview.
The IdP sent the response to http://ombudsportalen.mycompany.se/logon/
which resulted in redirect to
Default.aspx was protected by formsautentication so it redirected to the SAML20SignOnhandler but with a GET which resulted in the SPRelay in the form and the SAMLResponse to be removed.
Solution was to let the idp send the response directly to the SAML20SignOnHandler.
Finding other problems with formsauthentication as its used in the example later on we removed it and registered SAML20SignOnHandler as an ordinary HttpHandler
I would like to conclude on your findings and please correct me if I got it wrong.
When you registered the endpoints as ASP.NET Http Handlers, like described in the documentation, it worked correctly.
IdP-initiated SSO works with OIOSAML.NET, and the problems you experienced was solved by accesing the endpoint (handlers) directly instead of by further redirects(HTTP or HTML).
Best regards Brian