Forum Discussion
AltostratusPersistence after 302 redirect - header replacement Irule best method or others better?
Have a 3 layer application (IIS, Application, and single signon ie. SSO) all going through the LTM where persistence must be maintained across all 3 layers. A 302 redirect is preventing persistence to the SSO server. Think I have an iRule to do what we need but thought I would check with the devcentral community. The flow:
- client issues login to IIS virtual with cookie persistence
- IIS sends to App layer virtual. IIS-a tied to APP-a via Irule (b-to-b, c-to-c, etc)
- App layer issues 302 redirect to SSO virtual
- client logs in and steps 1 & 2 are repeated back to App layer
- App Layer validates login by request to SSO layer. If validation goes to different SSO server than initial client connection after 302, then an error occurs.
My idea was to have the web developer insert a response header on the 302 redirect with the app server designation "a", "b", "c", etc, and based on that, change the redirect location to SSO virtual server "a", "b".... and use cookie persistence across virtual servers so subsequent requests to the parent SSO virtual would still get directed to the proper back end server. Am I missing something - will this work? Even if this is viable, ss there an easier way to do this?
Also - here is the iRule which I cobbled together from some examples here on devcentral and any feedback much appreciated.
when HTTP_RESPONSE { if { [HTTP::status] == "302" } { if { [HTTP::header "Location"] starts_with "https://example.sso.server/login/" } { if { [HTTP::header "appServer"] equals "a" } { HTTP::header replace "Location" [string map example.sso.server example.sso.server-a} [HTTP::header "Location"] ] } elseif { [HTTP::header "appServer"] equals "b" } { HTTP::header replace "Location" [string map example.sso.server example.sso.server-b} [HTTP::header "Location"] ] } } } }
4 Replies
Steve_KnappSorry about the Irule format. It displayed correctly when I copied it in. I just went in to edit it and the pre-display version looks nice and formatted, each statement on its own line and with indents.
IheartF5_45022Nacreous
Hi so you shouldn't need an iRule for this - if you enable cookie insert persistence profile on your SSO virtual it will return a cookie to your browser. Then when App Layer validates login by request to SSO layer via redirect, the browser will again pick up your SSO cookie and you should be sent to the same server.
Or have I misunderstood something?
- Steve_Knapp
The issue is that the validation does not involve the browser so there is no way to make sure the App server goes to the same SSO server as the client's browser did in the first place.
- IheartF5_45022
Gotcha. From an architectural perspective, the best way is to ensure that the SSO layer uses shared memory to store authentication tokens, or is able to source the tokens from a shared backend. However if you need another solution, this is the first thing I think of....
I'm going to assume for the purposes of discussion that your sso domain is called sso.knapp.com and you app is called app.knapp.com (this won't work unless they share a domain). What we are going to do is to change the domain of the sso persistence cookie to be at the knapp.com level rather than the sso.knapp.com level;
when HTTP_RESPONSE { if {[HTTP::cookie exists "sso_knapp"]} { This assumes the cookie attached to the sso virtual is called sso_knapp HTTP::header replace Set-Cookie "sso_knapp=[HTTP::cookie "sso_knapp"]; Domain=knapp.com" } }This means that the sso_knapp cookie will be passed by the browser to requests to the app.knapp.com domain. Then, you just need to get your developer (on app.knapp.com) to include the cookie called sso_knapp from the browser request, in the request to sso.knapp.com and your request will be sent to the same server as the original signon.
I hope that is helpful.
