Persistent session update failure in Session Services - SSO in Policy Server
Article ID: 187439
Updated On:
Products
Issue/Introduction
When running 2 Policy Servers (A and B) and when the user logs into a persistent realm in environment A, when it tries to reach a non-persistent realm in environment B, he's challenged again.
The Policy Server in environment B reports:
[CSm_Auth_Message::SendReply][** Status: Not Validated. Failed to update persistent session in Session Services] User session should be accepted without having to challenge again.
Note that if both environments realms are non-persistent, then the user doesn't get challenged again.
This issue can occur when an authentication chain (like IDSP - VIP Authentication Hub) triggers a re-authentication to a higher level.
Environment
Policy Server all versions.
Cause
The flow works as designed, as the SMSESSION cookie has SessionSpec data which includes if the Session is persistent or not (1).
The transition from a non-persistent source realm to a persistent destination realm specifically causes the "Failed to update" error because the session spec already has the SessionPersistent flag set, but the Policy Server cannot find the session in the store.
In this specific use case, the SessionSpec SessionPersistent data is set, then, when validating the session, the Policy Server from environment B tries to find the data in a Session Store, and as it cannot find the data in a Session Store, it reports the error.
Resolution
To get SSO, realms should be the same type and not a mixture of persistent and non-persistent (2).
When realms are persistents, the Session Store should be shared between the environments, for each of them to find the Session that brings the SMSESSION and to be able to validate it without having to ask for credentials. Both environments should share the same Session Store.
Additional Information
Feedback
