SAML behind APM - POST data lost on initial redirect

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.

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.

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.

"This worked but hurt my soul." I know what you mean :)

Well, for what it's worth, my current solution is this. When a new SAML request arrives, if it's GET: proceed trough APM as usual.

If it's POST: if user is already APM authenticated: POST gets trough the back-end. I supply the credentials I got inside the APM session using HTTP Basic Auth. Works perfectly.

If it's POST and user is NOT APM authenticated: I allow the initial SAML request to go to the back-end. I also add a token to the query string in the received Location header I get from the back-end.

Then the client asks for this URL with the token and goes trough the APM flow. At the end, when APM is complete and request will get trough to the back-end, I recognize the token and I enable forms based authentication so the user never sees the login form.

Don't know if this is useful in other situations.

Only problem is that I assume that the first form I get is the user/pass form in the special situation I describe. Shibboleth IdP does not work with HTTP Basic Auth after the initial SAML POST/GET. And you know what they say about assumptions...

Still searching for a way to be sure that the presented form is the login form.

"This worked but hurt my soul." I know what you mean :)

Well, for what it's worth, my current solution is this. When a new SAML request arrives, if it's GET: proceed trough APM as usual.

If it's POST: if user is already APM authenticated: POST gets trough the back-end. I supply the credentials I got inside the APM session using HTTP Basic Auth. Works perfectly.

If it's POST and user is NOT APM authenticated: I allow the initial SAML request to go to the back-end. I also add a token to the query string in the received Location header I get from the back-end.

Then the client asks for this URL with the token and goes trough the APM flow. At the end, when APM is complete and request will get trough to the back-end, I recognize the token and I enable forms based authentication so the user never sees the login form.

Don't know if this is useful in other situations.

Only problem is that I assume that the first form I get is the user/pass form in the special situation I describe. Shibboleth IdP does not work with HTTP Basic Auth after the initial SAML POST/GET. And you know what they say about assumptions...

Still searching for a way to be sure that the presented form is the login form.

I've managed to avoid Shibboleth so far, but I was looking at IdPAuthRemoteUser with some hope. As long as it doesn't try to use AJP protocol and just blindly accepts the header, it might be possible to inject REMOTE_USER via HTTP_REQUEST_RELEASE.

Also, have you tried setting ACCESS::disable until a GET request is detected that's certainly going to land the user on the Shibboleth login page? I've used that technique with one rather complex site in the past. I had a site that used NTLM but the NTLM SSO Profile didn't work because it would ignore the NTLM header sent by APM until after a WWW-Authenticate was sent from the application server (the request that sent the WWW-Authenticate header was triggered by a redirect).

Just a quick note that APM behaviour may have changed since I originally posted this question. Or perhaps I hadn't fully investigated the post data behaviour if multi-domain SSO wasn't applied to the IdP site.

I've noticed that using a single domain to reverse proxy all your IdP technologies as suggested, e.g. apm.mydomain.com/adfs and apm.mydomain.com/idp works just fine as APM now seems to retain a copy of the post data in the request that triggered the login page redirect (in this case apm.mydomain.com/my.policy). So external Service Providers that post SAMLRequest to these either of these IdP's seem to get through fine.

Post data is only lost if the initial post is to one of the multi-domain sites not hanging off of the Primary Authentication URI. That issue still appears to be outstanding as of 12.1.