We are facing an issue with header variable in SSO 12.7
We have an application protected by SM. We have created roles/groups for this let us say AppAdmin, AppUser & AppTest. We have created responses as well for these like isappadmin, isappuser & is apptest.
Scenario : Application will be accessible wrt the response attributes received.
When the user logs in with "AppAdmin" role , the header variable should go as "HTTP_isappadmin=yes"
same way when user logs in with "AppUser" roles, the header variable should go as "HTTP_isappuser=yes"
Issue : For us, the first time header variable which is carried is only coming even the role is changed to different one.
Let us say when we changed the role from "AppAdmin" to "AppUser", still we are getting the "HTTP_isappadmin=yes" as header varaible
1. Changed the cache size in policy server and restarted the sever. below is path
2. set AllowCacheHeaders to NO
Could anyone advise on this.?
Have we tried these configuration within Responses.
The Attribute Caching section is where you specify whether the agent should cache the attribute value or periodically recalculate the value.
Have you checked if correct response is getting triggered in the first
place from the PS trace logs?
Does the user get to change role after login or is it only at the time of
On Thu, 20 Sep 2018 at 1:27 am, HubertDennis <
Yes, we have checked the PS logs response triggered is correct.
We changed the role after successful login & logout from previous role.
Had given a 10 mins gap before/after assigning the role.
Whatever the role assigned first, the respective response is triggering for any other role.
We are facing this issue for all applications we are protecting, which we didn't face in SSO6.
Recently we have migrated SM from 6 to 12.7. We have enabled the Cache Value option in both the versions.
Its not working in new SSO whereas no problems in old one.
I have set this and restarted PS also. But still the same issue.
I'd say lets go ahead and raise a CA Support Case, since it is suggested that it is impacting all applications.
I think, if the issue exists, it should be quick to reproduce in a brand new fresh install of R12.7 or R12.8 or R12.8.01. I would try it once I get my R12.8 lab server back.
It'd be best, if we have a CA SSO (SiteMinder) Test tool run against the CA SSO Policy Server to reproduce the problem. Just to eliminate components e.g. Web Agent from the mix and see what happens. Have tracing (smtracedefault.log) enabled to the fullest, so as to be able to see all possible details.
We have upgraded policy server to R12.8.01. Still we are facing the issue.? Can someone help us here.?
Hi Tarakeswaray. Did you open an support issue? What is the issue number?
Yes. my team mate raised( on Sep 19, 2018 ) and still no response there. Will check with my team mate and let you know the case number.
Thanks everyone. We have fixed this by changing the DsInfoTimeout value in registry file.
We have not yet received any update from CA support regarding this.