SAML SSO Without a Webtop

Has anyone gotten cookie persistence to work with IDP initiated and when using a webtop. I can't get this to work!

Irule: log local0.notice "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Policy Completed" switch -glob [ACCESS::session data get session.server.network.name] { "recruitment.company.com" { log local0.notice "recruitment: Policy Completed" ACCESS::respond "/saml/idp/res?id=/SSO/recruitment" ACCESS::respond 302 Location "/saml/idp/res?id=/Common/bobscloud.com" } "bluetube.company.com" { log local0.notice "recruitment: Policy Completed" ACCESS::respond "/saml/idp/res?id=/SSO/Kaltura" ACCESS::respond 302 Location "/saml/idp/res?id=/Common/bobscloud.com" }

}

Has anyone gotten cookie persistence to work with IDP initiated and when using a webtop. I can't get this to work, Im trying to bypass the webtop and get it to respect the cookie:

  log local0.notice "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Policy Completed"
    switch -glob [ACCESS::session data get session.server.network.name] {
                    "recruitment.company.com"
                                    {
                                          log local0.notice "recruitment: Policy Completed"
                                        ACCESS::respond "/saml/idp/res?id=/SSO/recruitment"
                                       ACCESS::respond 302 Location "/saml/idp/res?id=/Common/bobscloud.com"
                                    }
                     "bluetube.company.com"
                                    {
                                        log local0.notice "recruitment: Policy Completed"
                                        ACCESS::respond "/saml/idp/res?id=/SSO/Kaltura"
                                       ACCESS::respond 302 Location "/saml/idp/res?id=/Common/bobscloud.com"
                                    }

}

Can you elaborate on which persistence cookie you're talking about?

It does make sense, but after further investigation I don't think it's really a persistence issue. If you watch the traffic as you attempt to go back to the IdP webtop, you'll see that the client will indeed send back the original IdP access session token. It's just that the access policy rejects it and starts a new access session. I'm just spitballing here, but it's as if a webtop (resource assignment) doesn't qualify as a "completed" access session - you don't get to the allow block. So when you try to go back to the original base URI, it attempts to start over. The following iRule is the best I've been able to come up with so far. Tweak at will.

when HTTP_REQUEST {
     if the URI isn't a redirect to an SP resource, and it's an active session - redirect to the SAML SP resource
    if { not ( [HTTP::uri] starts_with "/saml/idp/res?id=" ) and ( [HTTP::cookie exists MRHSession] ) and ( [ACCESS::session exists -state_allow -sid [HTTP::cookie value MRHSession]] ) } {
        switch [string tolower [HTTP::host]] {
            "idp.domain.com" {
                HTTP::redirect "/saml/idp/res?id=/Common/idp.domain.com-resource" 
            }
        }
    }
}
when ACCESS_POLICY_COMPLETED {
     redirect to the SAML SP resource
    switch -glob [string tolower [ACCESS::session data get session.server.network.name]] {
        "idp.domain.com" {
            ACCESS::respond 302 Location "/saml/idp/res?id=/Common/idp.domain.com-resource" 
        }
    }
}

So basically I'm duplicating the redirect code in the HTTP_REQUEST and ACCESS_POLICY_COMPLETED events, and only only perform the redirect in HTTP_REQUEST if it's an active (authenticated) session. Now when you go back to the IdP webtop, if performs a new IdP-initiated response redirect (based on the Host header).

Normally an IdP-initiated connection from the webtop opens another tab in the browser, which leaves the webtop accessible. In the iRule you're essentially replacing the IdP webtop tab with the call to the SP and I'm still mostly convinced that since it never technically gets to the allow block, a new access request simply causes the existing to be overwritten.

The MRHSession and LastMRH_Session cookies seem to get overwritten when I hit the virtual again with the second URL

Can you elaborate on this?

I think I am going to hazard a guess what's going on wrong here. If the user navigates away from the webtop, and hits the virtual again, they will be sent to the login page even if they present a valid MRHSession cookie. You can control that behavior using an irule as well:

when HTTP_REQUEST {
   if { ( [HTTP::cookie exists MRHSession] ) and ( [ACCESS::session exists -state_allow [HTTP::cookie value MRHSession]] )  and ( [HTTP::uri] equals "/" ) } {
     HTTP::redirect "https://[HTTP::host]/vdesk/webtop.eui?webtop=/Common/portal_webtop&webtop_type=webtop_full"
   }
}

I think I am going to hazard a guess what's going on wrong here. If the user navigates away from the webtop, and hits the virtual again, they will be sent to the login page even if they present a valid MRHSession cookie. You can control that behavior using an irule as well:

when HTTP_REQUEST {
   if { ( [HTTP::cookie exists MRHSession] ) and ( [ACCESS::session exists -state_allow [HTTP::cookie value MRHSession]] )  and ( [HTTP::uri] equals "/" ) } {
     HTTP::redirect "https://[HTTP::host]/vdesk/webtop.eui?webtop=/Common/portal_webtop&webtop_type=webtop_full"
   }
}

Our configuration is we have a single load balancer per datacentre that have their configurations kept in-sync (manually).

We often shift traffic for these various *.company.com hosts like mentioned above, with cookie persistence, this creates issues with the APM module when it receives a cookie from another F5 load balancer.

What seems to happen is a redirect to /my.logout.php3?errorcode=20 with message: Invalid Session ID. Your session may have expired.

Any ideas here of what we can do? Perhaps replicate the APM session database somehow?

Replicating the APM session database isn't possible today. How do you shift traffic? DNS? Do you use domain cookies?

Right, because you're sending the new APM an access token that it doesn't own. It's a little tricky here because you're using DNS to flip between the sites, so regardless of the domain scope the host name would be the same (with different IP) so the client would still send the cookie. The domain scope only exacerbates that problem. The only option I can think of is to maybe perform a check in the HTTP_REQUEST, such that if a client presents a session token that doesn't exists in the local session table, forcefully remove that cookie in a redirect back to the requested URL.