401 Unauthorized Access Page for Identity Portal Protected Through SiteMinder

[Tiffany Kongpachith]

Hello everyone,

Have a current issue at the moment regarding CA Single Sign On (SiteMinder) and CA Identity Portal integration.
Both solutions are deployed in Linux environment. Web Agent version SP12.52 CR10 and Identity Portal (believe the latest version) on the vApp.

The Web Agent is fully deployed, configured, and registered to the Policy Server. We have set up the ProxyPass and ProxyPassReverse rules for AJP forwarding to Identity Manager and Identity Portal at the end of the httpd.conf file located in the /etc/httpd/conf directory.

The format looks like this (minus the real hostnames):
ProxyPass "/iam" "ajp://FQDNOFIDM:8009/iam"
ProxyPassReverse "/iam" "ajp://FQDNOFIDM:8009/iam"

ProxyPass "/sigma" "ajp://FQDNOFPROTAL:8010/sigma"
ProxyPassReverse "/sigma"  "ajp://FQDNOFPORTAL:8010/sigma"

Then we would restart Apache services to apply these changes. When we open the browser and up the URL of the Web Agent, for example: http://singlesignonwebagent.ca.com/iam/im/identityEnv - We get prompted a HTML form login (which is defined on the Realm) for authentication. We put in the credentials, and have no issues getting authorized and logging into Identity Manager.

However... when we try to go to, for example: http://singlesignonwebagent.ca.com/sigma/app - We get prompted the same HTML Form, we put in the EXACT same username and password for authentication to Identity Portal, but after submitting credentials/clicking Login -- the result is a blank, white page that says "Unauthorized Access". 

Why this is the case?

1) We checked the smaccess.log and saw that the user credentials submitted were AuthAccept and AzAccept which leads me to believe that AA went through no problem, since for instance we can log into Identity Manager with those same credentials no problem.
2) Portal has Enable SSO checkbox - Enabled in the Portal Admin UI Setup configuration - which I believe is all needed for the IDP-SSO integration. And SiteMinder Admin UI has the following ACO parameters, Domain, Realms, Rules, and Policy that is needed to protect Portal completed (follows the exact 4 ACOs needed to be edited and 6 realms needed to be protected listed in the TechDocs/Docops)
3) We also checked the logs from Portal and can see SiteMinder Headers being passed especially SM_USER and SMSESSION - But get this block of a message from Portal states "USER_NOT_AUTHENTICATED". When like I mentioned previously the same username and password is being used to log into Identity Manager and AA gets passed through no problem yet it does not work for Portal.
Here is the message -- 
Inbound Message
2019-12-09 14:33:04,753 INFO [stdout] (default task-78) ----------------------------
2019-12-09 14:33:04,753 INFO [stdout] (default task-78) ID: 59
2019-12-09 14:33:04,753 INFO [stdout] (default task-78) Response-Code: 500
2019-12-09 14:33:04,753 INFO [stdout] (default task-78) Encoding: ISO-8859-1
2019-12-09 14:33:04,753 INFO [stdout] (default task-78) Content-Type: application/json
2019-12-09 14:33:04,753 INFO [stdout] (default task-78) Headers: {connection=[close], Content-Length=[125], content-type=[application/json], Date=[Mon, 09 Dec 2019 22:33:04 GMT], Server=[vApp Web Server], Set-Cookie=[JSESSIONID=NrWkpWdlRrj1CLpy9UdCfz-t.iamnode1; path=/iam/im], X-Frame-Options=[SAMEORIGIN], X-Powered-By=[Undertow/1]}
2019-12-09 14:33:04,753 INFO [stdout] (default task-78) Payload: {"errorCode":51,"errorLiteral":"USER_NOT_AUTHENTICATED","message":"Username and password do not match.","backendMessages":[]}
2019-12-09 14:33:04,753 INFO [stdout] (default task-78) --------------------------------------

- Can someone help with giving me reasons as to why this error is occurring? 
- Is Portal throwing this 401 error message?
- Or is it SiteMinder that's throwing the 401 error page?
- Is the AJP Forwarding incorrect? Is the redirecting in the backend of Apache/AJP causing the issue? I don't believe if would if we can hit the URL/URI to Identity Manager and log in.
- Missed configurations in Portal? Or missed configurations in installation of Portal?
- Missed configurations in SiteMinder or the Web Agent? Or missed configurations in installation of the Web Agent?

Any insight, resource, or help will be gratefully appreciated! Thanks everyone.

[Peter Burant]

Hi Tiffany,

It sounds like you are indeed getting authenticated and authorized by Siteminder.  You can verify this via the web agent trace log: you will see the request for /sigma/app be received, the IsProtected call made, then followed by the IsAuthenticated and IsAuthorized calls.  This will show explicitly how the web agent is handling each of these calls, Based on the info provided, I suspect the user is passing both authentication and authorization in Siteminder.  This is in part because the default behavior of SM when a user fails either authentication or authorization is to re-challenge the user for credentials.  Since an unauthorized access message is displayed without re-challenging the user for credentials, I suspect this is the Portal application denying access.  

Since application integration is typically done via http header variable, check to verify that any header vars needed by the application are being set to the expected value(s).  It may be necessary to add a web agent response to set any header var values that are not being set, or reset any that may be set to the wrong value for the Portal application.

I have attached a zip file containing various header dump pages in case you need to view the headers being set as you troubleshoot.  Accessing one of these pages after authenticating will show all header variables set for the user along with their values.  This information cannot be seen in Fiddler or other http trace tools.

I hope this helps.

Regards,
Pete Burant

Attachment(s)

Header_Dump_Pages.zip   2 KB 1 version

[Tiffany Kongpachith]

Hi Pete,

Thank you for responding and giving me insight that you believe that SiteMinder with AA is working as well and I am not overlooking anything differently.
I had a feeling that the issue is coming from Portal side.

I was overlooking the TechDocs for integration with Portal and SiteMinder (SSO). I'll post the links to them again here:
http://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-identity-and-access-management/identity-portal/14-3/integrating/ca-single-sign-on-integration.html
http://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-identity-and-access-management/identity-portal/14-3/integrating/ca-single-sign-on-integration/ca-sso-prerequisites.html
http://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-identity-and-access-management/identity-portal/14-3/integrating/protecting-ca-identity-portal-with-ca-single-sign-on.html

I was reading and saw that TEWS must be enabled in Identity Manager for Portal, is that correct? Because TEWS must be configured for SSO authentication? I can check and see with the IDM team if that is enabled or not.

In regards to Header variables, with that Portal message I listed above, before that I can see that SM header variables were being passed. In the TechDocs it states the required SSO headers are: SM_USER, SM_USERDN, SM_AUTHTYPE, and SM_SERVERSESSIONSPEC. When indeed in the logs/message before shows ALL of those required headers.

So again, I am stumped upon what it is that's preventing us from logging into Identity Portal when A) configurations are done correctly, B) user credentials are valid for Identity Manager but not for Portal, and 3) SSO headers are being passed that are necessary and needed?

Do I also need to enable support for HTTP Delete Verb for Portal? I have not done that for the Dev environment, and the integration and AA worse flawlessly so I'm wondering if that's something needed to be done for our Staging environment now in order for it to work?

Let me know your thoughts, again I appreciate your feedback! And for anyone who stumbles upon this forum post for additional insights!