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

 

application delivery
BIG-IP Access Policy Manager (APM)
iRules
LTM
saml
single sign on
  • AJ_01_135899's avatar
    AJ_01_135899
    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:

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

    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