Forum Discussion

Cirrostratus

Sep 28, 2016

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 ...

application delivery

BIG-IP Access Policy Manager (APM)

Sep 30, 2016

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_135899

Cirrostratus

Sep 30, 2016

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)

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_221296
Nimbostratus
Nov 30, 2016
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_135899
Cirrostratus
Nov 30, 2016
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_221296
Nimbostratus
Nov 30, 2016
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
AJ_01_135899
Cirrostratus
Nov 30, 2016
Well, I don't know what to tell you, this appears to work fine in our environment. I haven't traced packets, but health monitors on the pool are green and the traffic flows fine.
Stanislas_Piro2
Cumulonimbus
Nov 30, 2016
Hi,

did you try without layered VS by changing
HTTP_RESPONSE
event with
HTTP_RESPONSE_RELEASE
event?
amass87_221296
Nimbostratus
Nov 30, 2016
Running into an issue trying to use STREAM within HTTP_RESPONSE_RELEASE TCL error: /Common/Test_iRule - Operation not supported (line 1) invoked from within "STREAM::expression
amass87_221296
Nimbostratus
Dec 02, 2016
Thanks guys, I ended up getting this to work. I had to use an iRule to send traffic to the virtual server hosting the access policy. Thanks to AJ for posting this iRule. I was able to pass the necessary data between virtual servers via cookies and use a stream profile to modify the message in transit.
AJ_01_135899
Cirrostratus
Dec 02, 2016
I'm glad you got this working. It's unfortunate that APM doesn't support this functionality natively but thankfully there are many custom options on the F5 so we can get it to work anyway! Feel free to post a scrubbed version of your iRule if you care to...

Incidentally amass87, which version of F5 are you running?
amass87_221296
Nimbostratus
Dec 05, 2016
Running 12.1.1
amass87_221296
Nimbostratus
Jan 10, 2017
I created a post with scrubbed iRules and explanation here: https://devcentral.f5.com/s/feed/0D51T00006i7fFTSAY
¬†

Thanks again AJ 01 and Stanislas!
¬†