Hi dear community,
We are working on implementing an SSO cross domain and have chosen a CA SiteMinder Cookie Provider advance.
I have a question about CA SiteMinder Cookie provider configuration:
- We have an ca sso in one domain ".d1.fr". The SSO in ".d1.fr" is working fine.
- We want to implement an SSO between ".d1.fr" and 2 new domains: ".d2.fr" and ".d3.com"
We have follow the documentation of cookie provider configuration: Configure Web Agent Single Sign-On Settings - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation.
In this use case the cookie provider domain is ".d1.fr".
We have configured ".d2.fr" as the following: A web agent running in a reverse proxy Apache (Linux redhat 6.8) in a new ACO. In this ACO we have the SmMakeCookie referenced as indicated in the previous documentation.
We have created an application "app1.d2.fr" protected by an webAgent in ".d2.fr".
When we try an access to "app1.d2.fr" we have the authentication scheme and are redirect to ".d1.fr" login page correctly. We are correctly authenticated in ".d1.fr" but we cannot access to "app1.d2.fr".
By checking the siteMinder smaccess log file, we have an AzReject for app1.d2.fr.
Have you any idea about this use case ?
Thank you for your help.
If we are having an AzReject that may be due to Access Policy (within Policy Domain) for app1.dr2.fr.
If SSO was an issue, then it would have been rejected as ValidateAccept. But it seems like your AuthAccept from dr1.fr and ValidateAccept from dr2.fr worked.
We could further validate this theory by looking at the WebAgentTrace logs for app1.d2.fr. We should see received SMSESSION, decoded SMSESSION and Identified the Authenticated User. However the subsequent Authorization Call failed.
Thank you for your answer.
When we try to connect to "app1.d2.fr" the AuthAccept and ValidateAccept are ok.
The user has the authorization for app1.d2.fr but still have AzReject.
Do you know if any modification to do in the Authentication scheme for "app1.d2.fr" ?
Thank for your help.
You could check in the Policy Server traces what happens at this point, so maybe there is a missing Policy or other reason to reject it.
The problem is not the user. The user may be mapped correctly into the "POLICIES" within Policy Domain (app1.d2.fr).
The problem may be the REALM / RULE that is created within Policy Domain (app1.d2.fr) and the actual URI (resource) that we are trying to access.
As mentioned by Albert please refer to smtracedefault.log (Policy Server Trace log). Map the lines from smtracedefault.log to the REALM / RULE within Policy Domain (app1.d2.fr) for identifying the issue.
You cookie provider configuration is all set for authentication, and it seems to be working. If it's authorization issue, it could be that the user in the domain .d2.fr may not be in the associated realm/ resource/ user directory where s/he needs to be part of the group allowed to access the resource. I agree with Hubert this appears to be a policy design issue.