Deflate/decode the SAML request passed to the BIG-IP as an IdP

Hi Simon,

Maybe you can use the example that is shown in this code snippet:

https://devcentral.f5.com/s/articles/surfconext-second-factor-only-sfo-authentication-1012

This code snippet uses iRulesLX to perfrom the inflate/deflate, because it's not possible with the standard iRules (TcL).

If possible, use the new ACCESS_SAML events. Not sure I they fit your needs, but you could always try.

Kind regards,

--Niels

Hi Niels,

Thanks for your response and the link.

I had a suspicion that iRulesLX would be involved, given that I couldn't find anything like a ACCESS_SAML_STARTED event or similar.

I'm trying to identify the the issuer of the request so I can modify the APM logic based on where the request comes from.

I'm configuring APM to support IdP and SP initiate logins along the lines of this https://techdocs.f5.com/kb/en-us/products/big-ip_apm/manuals/product/big-ip-access-policy-manager-saml-configuration-14-1-0/02.html

I have a 1:1 mapping of local IdP service to external SP, so I will see if I can force it by updating each local IdP entity ID to be something like {fqdn}/saml/idp/{issuer}

If that works, it's probably simpler than trying to pull it out of the SAML assertion anyway.

Cheers,

Simon

Well that didn't work. I had thought that the entityID would be used to populate the SingleSignOnService attribute in the local IdP metadata and I could use a landing uri check to branch my policy. but the SSOService stays {fqdn}/saml/idp/profile/redirectorpost/sso/

Might have to play with some iRulesLX 😋

Unless there are any other suggestions?

Cheers,

Simon