Cookie Provider Idle Timeout Forcing Reauthentication

[Chris Bertagnolli]

Ok, maybe I'm just missing something really obvious....but got a little weird behavior when we began implementing the Cookie Provider.

Basically, I log into multiple domains using a master cookie provider in Domain 1. After idle timeout is reached, I'm forced to re-authenticate to every single domain application even though the master domain is active after the first re-authentication. Basically, each subsequent application visit is killing the master domain session.

Goal is to provide single sign on using the Cookie Provider to all domains and a consistent timeout behavior. I.e., after timout and logging into just 1 application I am NOT required to re-authenticate to the remaining. 

Example:

Idle timeouts for all domains is set to 10 minutes.

Master Cookie Domain = .master.com

Application 1 Domain = .app1.com

Application 2 Domain = .app2.com

Application X domain = any subsequent domains

1 - Go to app1.com and redirected to master.com to authenticate

2 - Log in successfully and obtain a .master.com and .app1.com SMSESSION

3 - Go to app2.com and redirect to master.com. I am NOT required to authenticate - I have an active session in that domain - and returned to the app with a session. I now have active SMSESSION for .master.com, .app1.com and .app2.com (this is good and all seems well)

4 - I am idle for 15 minutes and repeat the log in process for app1 and app2::

5 - Go to app1.com again and redirected to master.com to authenticate

6 - Log in successfully and obtain a new .master.com and .app1.com SMSESSION 

7 - Go to app2.com and redirected to master.com. My master.com session is removed and I am forced to authenticate again; essentially breaking my SSO for this browser session (this is bad).

8 - Repeat with any number of subsequent X domain apps (app3.com, app4.com....so on)

 

Is there some parameter or configuration I've completely overlooked that controls this behavior?

[System]

cbertagnolli:

Ok, maybe I'm just missing something really obvious....but got a little weird behavior when we began implementing the Cookie Provider.

Basically, I log into multiple domains using a master cookie provider in Domain 1. After idle timeout is reached, I'm forced to re-authenticate to every single domain application even though the master domain is active after the first re-authentication. Basically, each subsequent application visit is killing the master domain session.

Goal is to provide single sign on using the Cookie Provider to all domains and a consistent timeout behavior. I.e., after timout and logging into just 1 application I am NOT required to re-authenticate to the remaining. 

Example:

Idle timeouts for all domains is set to 10 minutes.

Master Cookie Domain = .master.com

Application 1 Domain = .app1.com

Application 2 Domain = .app2.com

Application X domain = any subsequent domains

1 - Go to app1.com and redirected to master.com to authenticate

2 - Log in successfully and obtain a .master.com and .app1.com SMSESSION

3 - Go to app2.com and redirect to master.com. I am NOT required to authenticate - I have an active session in that domain - and returned to the app with a session. I now have active SMSESSION for .master.com, .app1.com and .app2.com (this is good and all seems well)

4 - I am idle for 15 minutes and repeat the log in process for app1 and app2::

5 - Go to app1.com again and redirected to master.com to authenticate

6 - Log in successfully and obtain a new .master.com and .app1.com SMSESSION 

7 - Go to app2.com and redirected to master.com. My master.com session is removed and I am forced to authenticate again; essentially breaking my SSO for this browser session (this is bad).

8 - Repeat with any number of subsequent X domain apps (app3.com, app4.com....so on)

 

Is there some parameter or configuration I've completely overlooked that controls this behavior?

Hi All,

Any ideas here for this one?

Thanks!

Chris

[Ujwol]

I don't see a reason why it works first time and doesn't work second time .. also it is surprising why the second time master.com session is removed.

 

Could you provide following files for troubleshooting :

• HTTP Header trace (eg fiddler)
• Webagent trace from (cookie provider agent and .app2.com agent)

 

Also what is the version of SiteMinder ?

[Chris Bertagnolli]

Hi, sorry I completely missed your reply.

 

This is SiteMinder 12.52 (Policy Server and Web Agents). I went ahead and opened a ticket and working with CA support on the issue. If I get some time to sanitize the logs I will certainly upload them.

 

I had seen another post regarding timeouts with Cookie Provider as well, so going to poke through some of that and look at all the available configs / options.

 

One thing to note, the Agents use the base IISDefault that comes with the product, then just updated with minimal configs at this point: cookieprovider URL, agent names, target domain. The rest were default settings. There's also no timeout responses configured on the application objects for either the cookie provider or external apps.

[Anon Anon]

You might want to check the value of your SessionUpdatePeriod parameter.

[Chris Bertagnolli]

We've played with different settings but it hasn't really helped it. Basically once a secondary domain is timed out, it destroys the master domain session when a user goes to it whether the master is active/valid or not.

 

From what I got from support so far, this is expected behavior (still working on alternative options). Although if that's expected, it probably should change since it essentially breaks SSO even though the user had re-authenticated to the master domain and it's active; that master cookie should then allow immediate access to the other domains and just set a new session for them.

[Anon Anon]

Chris,

 

Something sounds funny about the answer you got (working as expected) for the reasons you gave.

I'd be curious whom you worked with as that might explain why they said that...

 

-Josh

[Chris Bertagnolli]

They're still working on possible solution/alternatives, so hopefully something will come out of it. If anything does will update the thread.

 

Just as a note, another issue we've run into is with AJAX calls when using the cookie provider. If some PUT/DELETE/other action is taken but the Sessionupdateperiod has elapsed, it causes errors due to the call out to the SmMakeCookie.ccc (so first request fails because of the extra [in its view] redirect but subsequent attempt works). Anyhow, just an extra tidbit issue we've been running into with the cookie provider.

[venkatk]

As a temporary solution you can try implementing the "IdleTimeoutURL" in the ACO and invoke the logout URL on idle timeout.