Support for POST preservation when APM Multidomain SSO is configured
Problem this snippet solves: F5 doesn't support the preservation of the initial POST request when the Virtual Server has an access profile configured for Multidomain SSO. After authentication, the user is redirected to the initial URL endpoint and issue a GET request instead of a POST request. How to use this snippet: We share a code sample to demonstrate how to support POST preservation in this typical scenario. This irule may need some additional configuration and settings to work properly. As a PoC, we configured two endpoints : sp.expertlab.net and idp.expertlab.net on the same Virtual Server and access profile. The access profile is configured for Multidomain SSO and we prompt the user for a form based authentication. We also added a dummy form prompted to the user after authentication to simplify our testing. Please note that the irule has been successfully tested with Chrome and Firefox. We are still running tests for Internet Explorer and Edge Browsers. Note : APM behave differently between v11, v12 and v13. To make POST preservation work for v11 and v12, you need to add the following variable assign settings before the Allow ending in your access policy : session.server.body = Session Variable session.server.initial_req_body session.policy.result.redirect.url = Session Variable session.server.landinguri_base64 Please note that the order of variable assignment is very important. Moreover, you need to change the name of the request body session variable in the irule too (static::body_var) Flow in v13.x POST https://sp.example.net/post_action.php 307 Temporary Redirect - Location: https://idp.example.net/F5Networks-SSO-Req?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA POST https://idp.example.net/F5Networks-SSO-Req?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA 302 Found - Location: /my.policy GET https://idp.example.net/my.policy 200 OK POST https://idp.example.net/my.policy 302 Found - Location: https://sp.example.net/F5Networks-SSO-Resp?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA&TOKEN=123954 GET https://sp.example.net/F5Networks-SSO-Resp?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA&TOKEN=123954 302 Found - Location: https://sp.example.net/post_action.php?ct=application%2Fx-www-form-urlencoded GET https://sp.example.net/post_action.php?ct=application%2Fx-www-form-urlencoded 200 OK - Body contains JS to force an auto-POST action POST https://sp.example.net/post_action.php ... Flow in v12.x POST https://sp.example.net/post_action.php 307 Temporary Redirect - Location: https://idp.example.net/F5Networks-SSO-Req?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA POST https://idp.example.net/F5Networks-SSO-Req?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA 302 Found - Location: /my.policy GET https://idp.example.net/my.policy 200 OK POST https://idp.example.net/my.policy 302 Found - Location: https://idp.example.net/F5Networks-SSO-Req?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA GET https://idp.example.net/F5Networks-SSO-Req?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA 302 Found - Location: https://sp.example.net/F5Networks-SSO-Resp?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA&TOKEN=123954 GET https://sp.example.net/F5Networks-SSO-Resp?SSO_ORIG_URI=aHR0cHM6Ly9zcC5leGFtcGxlLm5ldC9wb3N0X2FjdGlvbi5waHA&TOKEN=123954 302 Found - Location: https://sp.example.net/post_action.php?ct=application%2Fx-www-form-urlencoded GET https://sp.example.net/post_action.php?ct=application%2Fx-www-form-urlencoded 200 OK - Body contains JS to force an auto-POST action POST https://sp.example.net/post_action.php ... Code : ### # POST preservation feature # for Virtual Server with Multidomain SSO configured # # require : APM ### ### # Special notes # To support POST preservation in v11 and v12, # the administrator needs to configure special session variable assignment before the Allow ending in a Access policy # session.server.body = Session Variable session.server.initial_req_body # session.policy.result.redirect.url = Session Variable session.server.landinguri_base64 ### ### # Release notes # # 2017/11/23 # * Basic support for POST preservation in v13 # * Add support for v11 and v12 environments # # 2017/11/24 # * Replace static::idp_host by [PROFILE::access primary_auth_service] # * Add a static var to enable or disable the dummy form designed for testing purposes # * Avoid POSTing real body multiple times. A dummy var is used to retrieve the original POST content # # 2017/11/25 # * Remove some coding errors # * Refactoring of some parts of the irule ### when RULE_INIT { set static::md_start_uri "/F5Networks-SSO-Req?SSO_ORIG_URI=" # for v11.x and v12.x deployment # set static::body_var "session.server.body" # for v13.x deployment set static::body_var "session.server.initial_req_body" # enable or disable autogenerated testing forms set static::dummy_form 1 } when HTTP_REQUEST { if { ![ACCESS::session exists [HTTP::cookie MRHSession]] and !([HTTP::path] eq "/F5Networks-SSO-Resp") } { if { [HTTP::method] eq "POST" } { # save post data set ct [HTTP::header Content-Type] set uri [HTTP::uri] if { [URI::query $uri] != "" } { set uri $uri&ct=[URI::encode $ct]&f5-mdsso-post=1 } else { set uri $uri?ct=[URI::encode $ct]&f5-mdsso-post=1 } HTTP::respond 307 noserver Location "[PROFILE::access primary_auth_service]$static::md_start_uri[URI::encode [b64encode https://[HTTP::host]$uri]]" Connection Close return } else { HTTP::respond 302 noserver Location "[PROFILE::access primary_auth_service]$static::md_start_uri[URI::encode [b64encode https://[HTTP::host][HTTP::uri]]]" Connection Close return } } if { [ACCESS::session exists [HTTP::cookie MRHSession]] and [HTTP::query] contains "f5-mdsso-post=1" and [ACCESS::session data get $static::body_var] != "" } { set ct [URI::decode [URI::query [HTTP::uri] ct]] set dummy [getfield [expr {rand()}] "." 2] ACCESS::session data set session.server.dummy $dummy ACCESS::session data set session.server.ct $ct HTTP::respond 200 content " this page is used to hold your data while you are being authorized for your request. you will be forwarded to continue the authorization process. if this does not happen automatically, please click the continue button below. " noserver Content-Type "text/html" return } if { [ACCESS::session exists [HTTP::cookie MRHSession]] and [HTTP::method] eq "POST" and [HTTP::payload] contains "dummy" and [ACCESS::session data get session.server.dummy] eq [URI::query "/?[HTTP::payload]" dummy] } { HTTP::header replace Content-Type [ACCESS::session data get session.server.ct] HTTP::payload replace 0 [HTTP::header Content-Length] [ACCESS::session data get $static::body_var] } }
Multi Domain SSO APM configuration, evaluate policy before HTTP_REQUEST
Hello everyone, Have a bit of a head scratcher... Heres the scenario. I have 2 VSs. One serves up content to the user, the other is an authentication token provider which has iRuleLX/node.js code powering the auth token logic. The iRulesLX VS doesn't have an associated pool because it only uses the node.js logic. Both VS servers use the SAME APM policy. The APM policy has a multi domain SSO configuration setup with each of its urls. I have done Multi Domain SSO configurations before, so I know how to configure them. The workflow goes as follows... User hits VS_1 (content server), authenticates to APM, if successful, gets load balanced back to a node member and is 302 redirected to VS_2. VS_2 again has the SAME APM policy attached to it. VS_2 also has the same SSL client profile (were doing client cert auth). After being redirected to VS_2, the APM policy (should) see that the client has an established MRHSession via its MRHSession cookie and allows the connection to be associated with the session. Once associated with the session, the session variables can be used to create the token via the iRulesLX/node.js code. Bottom line, we need those session variables. Heres the problem... The iRule which is attached to VS_2, fires off the iRuleLX/node.js code to carry out the token assignment (I do not want to get into the intricacies of what the node.js code is doing, just know it works). The node.js code sits within an HTTP_REQUEST event. Because of this (I think) the user is not being associated with their APM session due to how iRule workflows work. See the following... https://devcentral.f5.com/articles/http-event-order-access-policy-manager Again this is my theory... Within the HTTP_REQUEST event on VS_2, we have it check to see if a session exists via the MRHSession cookie, and if not, stop execution and display message via HTTP 200 Response notifying the user to reauthenticate at VS_1. Now, when I do a single SSO domain configuration and just use the parent domain, everything works FINE. Unfortunately, this is NOT an option because it inhibits all my other VSs that are within that domain space using APM policies. So I know the configuration and code works. This is an APM/iRules workflow issue. Another thing, if I call the node.js code within a ACCESS_ACL_ALLOWED event, the session is associated fine in a multi domain SSO configuration because the session is assessed by APM. Unfortunately I can not use this configuration because I need to execute a HTTP::response command which isn't allowed within this event. I'm posting this hoping someone has ran into something similar and find out how they dealt with it. Maybe I'm over thinking this (I hope) but I've been pounding on this issue for the last week. I'll see if I can post snippets of the code. Its on a customers site so I don't know how much I can share. Thanks for any and all help!
Multi-Domain SSO Profile and Citrix iApp
We are working on getting SSO into Citrix (Storefront 3.0, XenApp 7.6) working using a multi-domain access profile (already created and performing SSO into other apps using NTLM, Kerberos, and SAML). When we have tried to add Citrix to the multi-domain AP, we end up hitting a wall. It seems that in the default Access Profile that the iApp creates, it sets the session.sso.token.last.username to "domain\[mcget {session.logon.last.username}]". That variable is then used by the form sso configuration object for authentication. But if I set this variable as described above in the multi-domain access profile, authentication breaks for other apps. Is there a way to set a different or custom variable and then leverage that variable for the form instead of the session.sso.token.last.username variable? If so, how would I set that variable? Any help is greatly appreciated. Thank you.
Multiple Domains SSO with APM and SAML
Hoping to get some ideas on this issue. I have an "overlay" vip working well with multiple host names point to it and it routing to an APM enabled "internal" VIP that does SAML client side and Kerberos server side as talked about in this thread. So far all my host names have been in the same domain (domain1.com) but now there is a new host name that is in another root domain (domain2.com) I have been using a domain cookie for all the domain1.com hosts and it works well (I am fine that APM is not fired client side once I have a session and go to other hosts under domain1.com). I now need to get domain2.com going and I need SSO between domain1 and domain2. So on the APM policy associated to my domain2.com VIP, I have a couple questions on this. 1) For the primary authentication URI should I point to a host name under domain1.com? 2) If yes, then when I use a host name that resolves to my overlay vip on domain1.com I get redirected to /my.logout.php3?errorcode=22 with an error "Access policy configuration has changed on gateway. Please login again to comply with new access policy configuration" in the browser an in the apm log file I get "No matching domain found for request host: host.domain2.com. So that makes me wonder what I should use for the Primary Authentication URI. I want/need it to be a SAML enabled authentication VIP, so why cannot I use a host name on my overlay vip? 3) Should my primary authentication uri be a specific authentication end point / VIP in domain1.com that is NOT my overlay VIP that is used just to establish a session in domain1.com and get my domain scoped cookied for domain1.com? Basically I need to get SSO going between domain1.com and domain2.com where both have overlay VIPS for multiple host names under each domain and route to internal vips that have an APM policy applied with SAML client side auth setup to an external IdP. Thanks in advance for any input or perspective on this one.
How do I tell if fix for ID453531 made it into 11.5.1.3.0.131?
Whilst I wait for support paper work to be sorted. I can't see a reference in the Release notes to 453531, so it seems likely it isn't fixed. If so I'll need an engineering hotfix for each release until it is incorporated (if ever), presumably that also requires support.