For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Vinne73's avatar
Vinne73
Icon for Cirrus rankCirrus
Oct 19, 2015

APM multi domain SSO, incorrect timeout URL

Hi,

 

I've set up APM with multidomain SSO. Let's say I have a site "service.mydomain.com" and a login URL "login.mydomain.com".

 

Works fine, I go to service.mydomain.com, I don't have an APM session, I get redirected to login.mydomain.com. I can log in, I go back to service.mydomain.com. SSO gets activated, all is well.

 

Now let's say I don't log in on login.mydomain.com and let it timeout. A link appears: "Expired/Timeout, click here to start a new session". The link points to the root of login.mydomain.com.

 

When I click on the link, The SSO_ORIG_URI from the first redirect is lost, there is no link back to the service. The correct thing for the APM would be to link to the SSO_ORIG_URI, which it knows because it was in the redirect that was sent by the service when this specific session was created.

 

Am I missing something here? Or is this bad behaviour by the BigIP/APM?

 

Thanks Vincent

 

BIG-IP Access Policy Manager (APM)
security

4 Replies

  • Seth_Cooper's avatar
    Seth_Cooper
    Icon for Employee rankEmployee
    Oct 19, 2015

    The SSO_ORIG_URI is going to be consumed by login.mydomain.com and then it is part of the session. When the session timeout hits the session is removed. When you click "start a new session" this is completely independent of the previous request/session and a new request for my.policy happens in the browser. This new request gets a new session id and has no idea about the previous SSO_ORIG_URI so it will stay on the login.mydomain.com resource.

     

    I suggest configuring a longer timeout value if this is a problem.

     

    Seth

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Oct 19, 2015

    If I may add, while a longer timer is definitely the way to go, here's an iRule solution that will extend the SSO_ORIG_URI across access sessions:

    when ACCESS_SESSION_STARTED {
    if { [HTTP::uri] contains "/F5Networks-SSO-Req?SSO_ORIG_URI" } {
        set sid [string range [ACCESS::session sid] [expr [string length [ACCESS::session sid]] -8] end]
        table set -subtable SSO ${sid} [findstr [HTTP::uri] "=" 1]
    }
}
when HTTP_REQUEST {
    if { [HTTP::cookie exists MRHSession] } {
        set sid [string range [HTTP::cookie value MRHSession] [expr [string length [HTTP::cookie value MRHSession]] -8] end]

        if { ( [HTTP::uri] equals "/" ) and ( [HTTP::cookie exists MRHSession] ) and not ( [ACCESS::session exists -sid [HTTP::cookie value MRHSession]] ) and ( [table lookup -subtable SSO ${sid}] ne "" ) } {
            HTTP::respond 302 Location "/F5Networks-SSO-Req?SSO_ORIG_URI=[table lookup -subtable SSO ${sid}]"
            table delete -subtable SSO ${sid}
            unset sid
        }
    }
}
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Oct 20, 2015

    Just a question: am I correct in that this only works for a short while? Meaning that if the timeout happened long ago, the corresponding sid "parent" is already deleted from the table?

     

    That is correct. You're at the mercy of the session table's timeout. The only other reasonable way would be to send the URI data to the client in a cookie.