Background: We have an application integrated with SiteMinder instances in each environment from DEV through PROD.
Issue: A user logs into to application, say in DEV. User opens another tab in IE to successfully login to same application in SYST using SYST URL. Now when he goes back to access DEV, his session is logged out. It appears the DEV SiteMinder session is overwritten by SYST SiteMinder session.
Theoretically, even though these are two different SiteMinder sessions - one from DEV and another from SYST, it should not log out user. Both sessions should be maintained, correct?
This is the expected behavior in the same browser session, by default. If you want to have both the environment accessible at a time in your machine you may need to use multiple different browsers such as Chrome/IE/Firefox... or even you can access it in incognito mode.
The reason is SMSESSION is the cookie name which is getting generated by webagent on successful authentication which is same for all the Tiers(DEV/INT/QA/PROD).
If you really want to change the SMSESSIOn cookie name, you may need to go with Security Zone setup approach as below:
Refer this link - Security Zones for Single Sign-on - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation
You configure SSO security zones using two Agent Configuration Object (ACO) parameters:
A single Web Agent instance supports only one local SSO zone, which you identify using the SSOZoneName parameter. An Agent implicitly trusts its local zone. Multiple zones cannot be named using the same Agent instance.
Based on the zone a web agent is configured to use, the agent generates the session and identity cookies with unique names. These names reflect the zone affiliation. For example, for the default zone named "SM", the session cookie is named SMSESSION. However, if an agent is configured to use a zone that is named "MY" instead of "SM" the SMSESSION cookie becomes MYSESSION.
Agents enforce zones by storing the zone name in the session and identity cookies. Users cannot rename the session or identity cookies to change their zone. When the agent validates these cookies, the agent verifies whether the zone name stored in the cookie matches the prefix in the cookie name.
Another perspective is......
Using the same Cookie Domain across all ENV. It seems like we are using the same Cookie Domain across all ENV.
Ideally we should be differentiating FQDNs between ENVs e.g. server.dev.company.com and server.syst.company.com. If we are using Cookie Domain as .company.com; then we end up in this situation. If we use Cookie Domain as .dev.company.com and .syst.company.com; then SMSESSION Cookie Overwrite would not occur. It all depends on how we are designing / implementing overall infrastructure, from different KEYs to different Cookie Domains.
Additional note. If we logged into DEV and obtained an SMSESSION, then traversed to SYST; even with ZONE feature, if we are active in SYST, SMSESSION in DEV will expire due to inactivity (if Idle Timeout is set) even though the cookie is not overwritten, thus needing relogin on Dev.
Agree Hubert. Nice Trick. !!!