Steps to Integrate SiteMinder with Backend 3<sup>rd</sup> Party Application's Basic Authentications.
Article ID: 52983
CA Single Sign On Secure Proxy Server (SiteMinder)AXIOMATICS POLICY SERVERCA Single Sign On SOA Security Manager (SiteMinder)CA Single Sign-On
Steps to Integrate SiteMinder with Backend Basic Authentications from 3rd party application.
After the user is authenticated and authorized by SiteMinder, user will access the backend resource and get Basic Challenge.
Once user submit the userID/PWD for the backend application, users get prompt to submit credential again for other backend resources. For example, "/backend/app1" get prompt, "/backend/app1/abc.png" get prompt, "/backend/app2/display?abc=123" get prompt.
Apache Reverse Proxy Server with WebAgent Enabled.
3rd Party application (for example, weblogic or tomcat resource) protecting resource with Basic Authentication. In this document, eHealth 6.1 is the sample application.
<Please see attached file for image>
From the above, SiteMinder can be installed on to [A] or [B].
If WebAgent is installed on [A], it does not touch any of eHealth components so the configuration is independent.
This document will base on having WebAgent installed on [A] as shown above.
Configure [A] ASF Apache to work as a reverse proxy server.
On Unix, it can be compiled with following parameters.
On Linux, you need run LIBS="-lpthread" then export LIBS before you run the above
On Windows, you just need to uncomment the following modules from default setting.
Enable reverse proxy by adding the following entries in the httpd.conf file. http://eh61.ca.com is the sample eHealth Apache RP Server.
Allow from all
ProxyPass / http://eh61.ca.com/
ProxyPassReverse / http://eh61.ca.com/
Run Agent Configuration Wizard to enable WebAgent. (Make sure prerequisite objects such as agent identity and so on are created)
Modify Agent Config Object to remove non-siteminder extensions from the IgnoreExt parameter.
Setup a UserStore/Domain/Realm/Rule/Policy to protect "/" realm and authenticate user using HTML Form Authentication Scheme. This Form Authentication Scheme may need to be served from other Web Server as /siteminderagent/forms/login.fcc resource will also be proxied to eHealth Apache RP. (Or you can use Basic Auth from SiteMinder but for a better sample and reference purpose, Form Authentication Scheme is used)
Create an "OnAccessAccept" rule.
Create a "Response" to set the following header(Choose "Static" for response type).
Header name: 'HTTP_AUTHORIZATION'
Header value: 'Basic <%userattr= "title "%>'
In this sample, "title" user attribute will store the encoded credential. If you do not want to use an existing user attribute, it would be better to create a custom user attribute to store the a base64 encoded user credential for this integration purpose.
The user credentials need to be in specific format before base64 encode.
"<userID>:<password>" and this is the user credential that will be accepted by the backend ([C]) application's basic auth challenge.
For example, if the "user1" and his password "[email protected]" need to be encoded, it should be "user1:[email protected]" and base64 encoded value will be "dXNlcjE6UEBzc3cwcmQ="
This base64 encoded string need to be stored in "title" user attribute.
Note: SiteMinder user credential and eHealth user credential may be different. For example, "user1" logon to SiteMinder but that user is "euser20" in eHealth. The credential to store in the user attribute is the eHealth credential.
When user is authorized by SiteMinder, OnAccessAccept rule will be triggered and the tied response will load the "title" user attribute and formulate the HTTP_AUTHORIZATION header with the value "Basic dXNlcjE6UEBzc3cwcmQ=".
Ensure OnAccessAccept Rule is tied to the response in the policy.
Test the feature
Accessing [A] (http://rp.support.lab) and get redirected to login form from SiteMinder.
Submit userID and Password to login
Browser will redirect back to the originally requested resource and then to eHealth welcome page.
Click on the "continue" button and you will get challenged by eHealth.
At this point, with the above configurations, eHealth will be fed with HTTP_AUTHORIZATION header and with the value "Basic dXNlcjE6UEBzc3cwcmQ=" so the user will seamlessly get access to eHealth resource.
This concept should work with most Basic Authentication Schemes coming from the backend applications.
The base64 encoded user credential need to be updated for each individual users that will access eHealth (or any backend application).
If user want to self-change password, a custom code will be required to update the user attribute with the new base64 encoded credential.
In order to set the HTTP_AUTHORIZATION header and its value, all non-SiteMinder extensions from IgnoreExt need to be removed.