Forum Discussion
NimbostratusSAML behind APM - POST data lost on initial redirect
I note that this has been acknowledge in many other threads here. Nowhere have I found a discussion of any possible solutions to this problem though.
I'm developing a Multi-Domain SSO Access Policy with the goal of consolidating logins for a range of different systems/technologies. Included in the list of target systems are ADFS 3.0 and Shibboleth IdP's.
I've considered putting them on the "Primary Authentication URI" such that if users login with apm.mydomain.com/my.policy, ADFS pool would hang off apm.mydomain.com/adfs and Shibboleth pool hangs off apm.mydomain.com/idp. This should work for any internal Service Providers, as I can simply apply the Access Profile to those virtual servers so as to ensure they login and get a working session that'll apply to the IdP's before they can hit the SP application (hence no additional redirects when the application POSTs it's SAMLRequest). However, this doesn't cover me for the scenario of externally hosted Service Providers (which is kind of the point of SAML). How do I make this work?
Possibly related question, does an F5 SAML IdP behind APM suffer the same fate? I wouldn't be looking forward to reconfiguring everything to use a new IdP, but if that's the only option I'd consider it.
13 Replies
Sam_HallLacking any better suggestion, I've found one option available is to decode the post data to determine which SP the request is attempting to start a session for. Then use that information to craft an idpinitiated GET request. Some SP also seem to provide enough information to do this in the RelayState URL parameter. Is this a terrible approach?
amolariCirrostratus
which information are you looking for? the entityID?- Sam_HallI think it was called the relying party id for ADFS. It's not to hard to implement and seems to work fine, I'm just wondering if it's the best thing to do. I've still not got it working for our Shibboleth instance, I think I need to enable IdPUnsolicitedSSO, which seems to be frowned upon... https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUnsolicitedSSO
- Sam_HallI've convinced myself that there's nothing wrong with translating the POST request to an idpinititated GET request redirect. All you lose is the ability for ADFS to detect a "relay attack", which is apparently just a DoS threat for ill prepared IdP platforms (ASM can mitigate against that probably more effectively). Relay attacks and idpinititated login presents no additional security risks to the Service Provider, which is all I was really concerned about.
Vinne73_96575Hi Sam,
I've got the same problem. Client visit external SP, they do a POST to my F5, user is unauthenticated there, POST data = lost.
Did you get this decoding of POST data to work? Would you mind sharing this code? :)
Tx in advance Vincent
Vinne73Cirrus
It's a Shibboleth SP we're talking about here. So it posts to the F5 APM, because our Shib IdP are load balanced behind it.
- Vinne73_96575
It's a Shibboleth SP we're talking about here. So it posts to the F5 APM, because our Shib IdP are load balanced behind it.
- Sam_Hall
In the case where I couldn't determine what SP had generated the SamlRequest, I ended up forwarding the post data to a web service to tell me which IdPInitiated GET request I needed to generate. Using the HTTP Super Sideband library. I couldn't find a TCL way to crack open the SAMLRequest.
As a more generic solution to the lost POST data issue, I also toyed with recording the POST data from the payload and then later generating a form that auto-submits with some javascript. This worked but hurt my soul.
- Vinne73
Hi Sam,
I've got the same problem. Client visit external SP, they do a POST to my F5, user is unauthenticated there, POST data = lost.
Did you get this decoding of POST data to work? Would you mind sharing this code? :)
Tx in advance Vincent
