Symantec Access Management

Though the persistent session is not in use (In the federation partnership and also in realm level)SPS is waiting for PS to validate the Persistent Session. Is this expected case?

log snippet:

[SMSESSION cookie has idled out. Persistent session will be validated from policy server.]

Anyone faced this issue before. Please assist, Appreciate your help.

Regards,

Venga

Venga Venga

It isn't clear what has been configured OR what exact journey is being executed (it is mentioned both federation and realm). Have you configured anything specifically for IdleTimeOut redirections to occur?

Also check the ACO Parameter, persistant cookie; has this been set to YES?

Regards

Hubert

Hello Hubert,

We have a federation Setup where we are acting as a SP. here in the partnership we have configured idle timeout for x mins (Persistent Session is enabled). Issue here is, After the idle timeout SPS says that "SMSESSION cookie has been idled out. and Persistent Session will be validated by policyserver". Why it is not redirecting the user to IdleTimeoutURL which is configured in ACO.

Could you please help me out here?

Thank You Venga Venga

Since you have persistent session enabled (on Partnership), it means there is a Session Store and there is a SessionID (SMSession) which also gets stored in Session Store. Hence on an event where the SMSession is invalidate (i.e. via Timeouts or Logout); there are 2 places where the Session needs to be invalidated. One is the SMSession Cookie on the Browser, the other is the SMSession references stored in Session Store. The Policy Server is the only authority who has the onus of updation (refresh / reset / invalidate / logout) of SMSession in Session Store. Therefore SPS has to send the request to Policy Server for Session Validation, if Persistent Sessions is enabled.

As such I feel the message that you are seeing is a valid message i.e. "SMSession Cookie has been idled out, Persistent Session will be validated by Policy Server". I have a lurking suspicion that the SPS code may be running into a loop here, hence getting stuck. SPS is seeing 2 actions to be honored i.e. (a) Send Session to Policy Server (b) Issue a redirect to IdleTimeout URL defined as per ACO; may be it is unable to decipher which one to honor first.

Test - 1 :

Now I would suggest for testing purposes (if possible unless this is production, nevertheless you should have an UAT / Dev Env) disable the ACO Parameter. Then test the journey.

Test - 2 :

Disable Persistant Session. Enable ACO Parameter.

These 2 Tests would suggest if both setting work independent of each other; however when applied mutually, they are disjoint (They don't function together). You should be in a good position to raise a Support Ticket here, in time.

Regards

Hubert

I have tested by disabling persistent session and enabling ACO parameter. but still it says.

[SMSESSION cookie has idled out. Persistent session will be validated from policy server.]

Have we checked the Policy Server trace log for equivalent txn?

Would we be able to confirm

A. Both SMSession on Browser and Session in SStore is invalidated? Kindly confirm this first under the Persistent Session enabled scenario.

B. About redirection using ACO parameter. Disable Persistent Session. Then Test. I did a test few weeks back with Web2.0 functionality and it had worked then. The difference being I did not have Persistent Session & I was testing Web2.0 with WebAgent.

Thanks for your help Hubert,

I have tested the things.

A.Both SMSESSION and Browser Session got invalidated at the same time.

B.I have disabled persistent session and tried but still i's not redirecting. throwing me to the Auth scheme page.

Thank You Venga Venga

OK this confirms that Persistent Session is not interfering. The only last item that we would do is use the same ACO and test it with a WebAgent (am sure this should work). Just to eliminate the difference between SPS and Standard WebAgent.

We are pretty sure that the IdleTimeOutURL is unprotected, correct?

Now here is the tricky piece, on SPS, WebAgent Process is a Java based agent running off the Tomcat. WAOP is also running off the Tomcat. We know for a fact that WAOP does not honor all set of ACO parameters like the Standard WebAgent (Refer below TechNote). May be there is some connection here between WAOP honoring limited set of ACO parameters and Java based Agent running on Tomcat which tries to honor all ACO parameters.

After this if it works with Standard WebAgent; we'd need to raise a ticket with CA Support.

WAOP ACO Parameter Support : http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec588967.aspx

Regards

Hubert