Initial uri is stored in an sessions variable called session.server.landinguri
Client is redirected to IdP(F5 SAML federation with IDP)
Authentication takes place and if completed the client is redirected to the landinguri and a jwt is signed and generated via an iRule (signature, username etc)
jwt is passed to the URI (yes, the applications requires this. HTTP header via authorization header is not supported)
We have tried generating the jwt in the APM but are unable to decrypt it in to proper format for appending to the URI. This is why we are doing this in an iRule
Our problem is that the iRule jwt is being generated at the start of the APM in the initial session BEFORE the authentication is taking place which results in e.g an empty username being displayed. We have been experimenting with ACCESS_POLICY_AGENT_EVENT but cant get things to work as it still picks up the jwt that is generated prior to SAML authentication.
When debugging we can see 3 jwts being generated in the flow, the first one with an empty username, the following 2 (after successful auth) contain the correct info.
Any advice on troubleshooting this is highly appreciated!
Thanks @Lucas_Thompson for helping out. ACCESS_ACL_ALLOWED did not help but your input lead us to try ACCESS_POLICY_AGENT_EVENT with a different approach and it appears to have done the trick!
Hi Keda, it sounds like an interesting use case. As you've found, a per-session policy only executes a single time at the beginning.
To make the code execute upon every request, you can use Per-Request policies (and call your irule from there) or you can use iRules (use the ACCESS_ACL_ALLOWED event so you're inside the user's session context). In either Per-Request or iRules you can append an HTTP header to the user's request. Use the "http header replace" function (https://clouddocs.f5.com/api/irules/HTTP__header.html), as it will replace any existing and potentially incorrect user-supplied header.
Thanks @Lucas_Thompson for helping out. ACCESS_ACL_ALLOWED did not help but your input lead us to try ACCESS_POLICY_AGENT_EVENT with a different approach and it appears to have done the trick!
