capturing and appending to HTTP::payload in a POST to a SAML assertions consumer URL

I can read the payload with HTTP::payload but not able to change the payload in transit.

doesn't HTTP::payload replace work or probably stream?

HTTP::payload

stream

Thanks no I couldn't get the replace to work. I started by changing the assertion consumer URL for the HTTP post to be a local test virtual server with the intention of manipulating the payload in transit. This will probably not work seeing as its an encoded XML based assertion, adding more complexity..

Would it be possible with stream to capture this 302 post to the assertion consumer service URL?

i.e. my browser does a post with body to https://wd3.myworkday.com//login-saml.flex:

SAMLResponse=PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbDJwOlJlc3BvbnNlIElEPSJfMWIxMDdmOTc2YWI3MTc0NGM3MDBjYmRlZDRlODM1OGE4YTJkZDEiIElzc3VlSW5zd

Decoded will be:

So it all seems possible, I could if necessary post to a local layered virtual server. Capture and deflate the decoded SAMLResponse, replace the Destination value, inflate the SAML response and then post it to the correct service provider.
It all seems pretty painful!

The decoded value of that SAMLresponse:

Are you attempting to actually add data to the POSTed SAMLResponse value? The good news here is that SAML POST response is usually not deflated, but base64-encoded, so with a layered VIP you could certainly look inside the assertion data. The problem is that this data is almost always digitally signed, so making any modifications would destroy the signature.

Thanks for posting Kevin. The way Workday developed the SP initiated deep linking was to use a parameter called done. This if captured in the querystring can be appended to body and not the samlresponse as i see from the example. So assuming that's the case then the signed SAMLresponse should then not be modified in transit.

I see where you are going with the layered VIP, the only way I thought to change this was to modify the assertion consumer service URL to a local layered VS to be able to capture it, problem is the payload would then be incorrect and need deflated XML manipulation so it's not ideal.

I've pushed the vendors to spawn the necessary relaystate parameter to feed our IDP as I believe that is what it was designed for.

If you're the IdP, then a layered LTM VIP can add the header to the HTTP response. Are you getting the value from a query string or from inside the SAMLResponse? In either case, adding the header should have no effect on the payload or payload length.

The value I'm getting from the querystring in the initial GET request is ?done=http://company.serviceprovider.com/customlink99.

It does this as opposed to a regular AUTHn request. It's just if I configure my SP connector's assertion consumer service URL to be something that's local to my BIGIP for capture like sso.company.com/payloadgrab, this will get encoded in the SAMLResponse value and then be part of the assertion which could potentially cause an issue as I understand it.

The layered LTM VIP would have to sit directly in front of the IdP or SP (VIP?) and thus should not require any modification to URLs. So for example, let's say you're the IdP. The SP sends an assertion request to the IdP. That traffic passes through the layered LTM VIP and the response with the SAMLResponse payload can be edited to include this new header (on its way to the client). Now let's say you're the SP. The SP traffic flows through the layered LTM VIP, so any POST request passing through it with the SAMLResponse payload can be edited to include this new header.