Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Clear all filters
code share

Form Based SSO for Dynamically built HTTP forms

Problem this snippet solves:

This snippet solves a challenge where Client Initiated Form Based SSO is required but you have no available trigger that you can configure to allow APM to detect the form.

This is typically something you can face when you try to configure SSO Forms for some version of the Citrix Storefront Web UI. when digging in the html and javascript, you can see that a single Javascript build the HTML content and thus the forms, so no ways to detect the form when data are in transit.

How to use this snippet:

You have to install a single irule on the Virtual Server protecting the web application. This irule use ACCESS commands so assuming you have APM and an access profile is attached to the Virtual Server.

Tested on Version:
Comments on this Snippet
Comment made 4 months ago by Niels van Sluis 2742

Hi Yann, thanks for sharing this. It came to good use today. However, I had to make one small adjustment. It had to do with jQuery. I had to include the jQuery library, because the website didn't use jQuery. See below an example of the changes I made to the HTTP_RESPONSE_DATE event.

set jquery "<script src='https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js'></script></head>" 
set newpayload [string map [list "</head>" $jquery] $payload]
set newpayload [string map [list "</html>" $sso] $newpayload]
Comment made 4 months ago by Yann Desmarest 4489

Hi Niels,

Good point

Thank you for your feedback. Indeed, the script has been built for Citrix Storefront and thus JQuery was already loaded.

I will update the original content with your code.

Thanks again for your help



Comment made 4 months ago by Niels van Sluis 2742

Hi Yann, thanks for updating. I stumbled into another error. An user was using the ampersand character in the password. The solution in this case was to use URI::encode the password. The client was already sending the Content-Type: application/x-www-form-urlencoded header, so there was no need to add this header. See the changes in the HTTP_REQUEST_DATA event below.

set password [URI::encode [ACCESS::session data get -secure session.sso.token.last.password]]
set newpayload [string map [list "f5-sso-token" $password] $payload]
Comment made 2 months ago by Yann Desmarest 4489

Nice finding Niels. Indeed, I forget to manage this use case. My mistake.

I will update the code shortly to integrate your fix.