random redirect loop with F5 in place

Are there any iRules applied to these VIPs?

Just one. A custom rule written to avoid one of the redirects.

when HTTP_REQUEST {
 if { ([string tolower [HTTP::uri]] starts_with "/dir/dir/file.aspx") and ([string tolower [HTTP::header "Referer"]] contains "login-blah.team") } {
       HTTP::redirect https://www-env.team.blah.com
 }
}

when HTTP_RESPONSE {HTTP::header insert X-UA-Compatible "IE=EmulateIE9,RequiresActiveX=true"} 

This works for a very specific redirect.

I guess the next question would be, what type of redirect loop? HTTP-to-HTTPS-to-HTTP? Redirecting from what to what? What is the relationship of the HTTP and HTTPS VIPs?

Great question. Here's what I understand. Some of the pages are secured, most are not. The initial request comes into the app server, which then redirects unauthenticated sessions to the single-sign on server. Once authenticated, the sessions is directed back at the app server. The current iRule prevents a loop here. However, the second loop is pure http and subsequent loops are inconsistent with the above (first) loop. When back at the app server the client can click a link the moves them to a page in a parallel folder on the app server. For about a dozen links, this throws the client into a loop. Clear as mud?

Can we establish what the redirects actually look like, as in what the redirect is from and to where it is pointing? The easiest way to do that is probably a client side capture tool like Fiddler. And a few additional questions:

1. Are the redirects from HTTP to HTTPS, or the reverse? Or across different hostnames? Is it redirecting back and forth between two URLs?

    

2. Do you have the redirect rewrite option enabled in the HTTP profile?

    

3. Do you have any HTTP class or rewrite profiles applied to the VIPs?

    

4. Can you elaborate on what happens if you remove the above iRule?

    

The first redirect is from HTTP (hostname1) to HTTPS (hostname2) to HTTPS (hostname1). Redirect Rewrite option has been turned on and off in the name of testing. Neither option seems to matter.

The only profile applied is the default HTTP profile. It is applied to ALL VIPs.

Here's the entire process without the iRule: Enter URL for app server App server looks for an authenticated session. If not authenticated, app server redirects to single-sign on server. Single-sign on server authenticates and redirects back to app server. (Loop begins) App server immediately redirects session back to SSO server, but since session is authenticated on SSO, SSO redirects back to app server. It remains this way until you refresh the page, then magically, the app server loads a page for the authenticated session.

Thanks for all of your help.

What is in the request to the app server that indicates the user is authenticated? Is it supposed to be a cookie? Query string? Form POST? Can you determine, from a client side (Fiddler) capture, if that value is getting transmitted correctly to the app server after authentication? What is different in the request to the app server before and after refreshing the page? A new cookie perhaps?

Is the single sign on being handled by the F5? Is the cookie domain set sufficient to cover all links?

The single-sign on is being handled by the second server (hostname2). I'm not sure about the cookie domain. I'll have to involve one of the developers.