Forum Discussion
Dynamic , Variable RelayState in IdP initiated SAML SSO
I'm having difficulty finding a way to persist a RelayState for an IdP-initiated SSO with a vendor.
Considering a link like the following:
https://sso-myorganization.com?RelayState=12345
The Assertion Consumer service is set to:
https://sso-myvendor.com.login.do
This RelayState does not appear to append in the HTTP POST alongside the SAMLResponse value.
Any thoughts on this? Perhaps the F5 doesn't support RelayState in an IdP initiated SAML SSO scenario? If we manually edit the "RelayState" value in the SP Connector setting screen with a proper value, it works, but it doesn't appear to be dynamic
Just wanted to reply on this one, since we were able to figure this out. The solution consisted of a layered VIP that rewrites traffic:
- A newly-created "backend" VIP to host the Access Policy
- Create a new pool which consists of a single member - the new backend VIP hosting the access policy.
- Modify the existing VIP by a. Removing the Access Policy b. Adding the existing SSL client profile c. Adding a server SSL profile (since the backend VIP uses SSL) d. Add the backend pool as a resource
- Add the iRule defined below (this has been genericized, you'll need to change this) (there are likely much more elegant ways to handle this, but this is version 0.1)
The irule rewrites the final Access Policy page that contains the javascript that performs the HTTP POST to the Assertion Consumer Service URL, and adds an HTTP Post parameter "RelayState" that was contained in the original IdP link.
when HTTP_REQUEST { set relaystatesetter 0 set relaystatevalue 0 set relaystateexists 0 if {[HTTP::cookie exists "RelayState"]}{ set relaystateexists 1 set relaystatevalue "[HTTP::cookie RelayState]" } log local0. "iRule Logger - HTTP_REQUEST Starting hostname=[HTTP::host];uri=[HTTP::uri]" if {[HTTP::uri] contains "RelayState"}{ log local0. "iRule Logger - HTTP_REQUEST RelayState Store Cookie hostname=[HTTP::host];uri=[HTTP::uri]" set relaystatesetter 1 set relaystatevalue "[URI::query [HTTP::uri] RelayState]" log local0. "iRule Logger - RelayState is $relaystatevalue;relaystatesetter=$relaystatesetter" HTTP::cookie insert name "RelayState" value $relaystatevalue domain ".domain.com" } } when HTTP_RESPONSE { if {$relaystatesetter==1}{ HTTP::cookie insert name "RelayState" value $relaystatevalue domain ".domain.com" } log local0. "iRule Logger - HTTP_RESPONSE Triggered - relaystate=$relaystatevalue" if {$relaystateexists==1}{ STREAM::expression "@ @ @" STREAM::enable } }
Hopefully someone else will find this helpful. Also apparently you can set dynamic RelayState variables in 12.0 so this is probably only useful for people on 11.x
- AJ_01_135899Cirrostratus
Just wanted to reply on this one, since we were able to figure this out. The solution consisted of a layered VIP that rewrites traffic:
- A newly-created "backend" VIP to host the Access Policy
- Create a new pool which consists of a single member - the new backend VIP hosting the access policy.
- Modify the existing VIP by a. Removing the Access Policy b. Adding the existing SSL client profile c. Adding a server SSL profile (since the backend VIP uses SSL) d. Add the backend pool as a resource
- Add the iRule defined below (this has been genericized, you'll need to change this) (there are likely much more elegant ways to handle this, but this is version 0.1)
The irule rewrites the final Access Policy page that contains the javascript that performs the HTTP POST to the Assertion Consumer Service URL, and adds an HTTP Post parameter "RelayState" that was contained in the original IdP link.
when HTTP_REQUEST { set relaystatesetter 0 set relaystatevalue 0 set relaystateexists 0 if {[HTTP::cookie exists "RelayState"]}{ set relaystateexists 1 set relaystatevalue "[HTTP::cookie RelayState]" } log local0. "iRule Logger - HTTP_REQUEST Starting hostname=[HTTP::host];uri=[HTTP::uri]" if {[HTTP::uri] contains "RelayState"}{ log local0. "iRule Logger - HTTP_REQUEST RelayState Store Cookie hostname=[HTTP::host];uri=[HTTP::uri]" set relaystatesetter 1 set relaystatevalue "[URI::query [HTTP::uri] RelayState]" log local0. "iRule Logger - RelayState is $relaystatevalue;relaystatesetter=$relaystatesetter" HTTP::cookie insert name "RelayState" value $relaystatevalue domain ".domain.com" } } when HTTP_RESPONSE { if {$relaystatesetter==1}{ HTTP::cookie insert name "RelayState" value $relaystatevalue domain ".domain.com" } log local0. "iRule Logger - HTTP_RESPONSE Triggered - relaystate=$relaystatevalue" if {$relaystateexists==1}{ STREAM::expression "@ @ @" STREAM::enable } }
Hopefully someone else will find this helpful. Also apparently you can set dynamic RelayState variables in 12.0 so this is probably only useful for people on 11.x
- amass87_221296Nimbostratus
How did you get this to work? Local Virtual Servers are not supported as pool members. https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10379.html
- AJ_01_135899Cirrostratus
That may only apply to LTM v9? I can assure you we have local VIPs configured as pool members on both 11.5.4 and 12.1.1. Just create a pool, and add the IP:Port of the VIP you want to define as a member. You may need SNAT enabled on the VIPs as well, in our environment Auto Map works fine.
- amass87_221296Nimbostratus
Seems like you didn't read the article. Applies to at the top, goes all the way to 12.1.0. I did that and it never connects to the backend Virtual Server. I have done a lot of troubleshooting and the only reasonable explanation I can come up with is that it is not supported.
"However, the BIG-IP does not respond to its own ARP requests for locally-hosted virtual server addresses, and thus is unable to establish a network connection to a locally-hosted virtual server. As a result, if you add a locally-hosted virtual server to a BIG-IP load balancing pool, no traffic will ever be sent to that pool member, as it is not possible for the system to load balance traffic to that pool member."
https://support.f5.com/kb/en-us/solutions/public/10000/300/sol10379.html
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com