Forum Discussion

AJ_01_135899's avatar
AJ_01_135899
Icon for Cirrostratus rankCirrostratus
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

 

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:

    1. A newly-created "backend" VIP to host the Access Policy
    2. Create a new pool which consists of a single member - the new backend VIP hosting the access policy.
    3. 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
    4. 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

  • 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:

    1. A newly-created "backend" VIP to host the Access Policy
    2. Create a new pool which consists of a single member - the new backend VIP hosting the access policy.
    3. 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
    4. 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's avatar
      AJ_01_135899
      Icon for Cirrostratus rankCirrostratus

      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's avatar
      amass87_221296
      Icon for Nimbostratus rankNimbostratus

      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