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