The following is an explanation and implementation guide on how to integrate SiteMinder into an ALUI 6.1 Portal infrastructure. The guide is based on actual implementation struggles and solutions we came up with in our environment. A reference doc is here.
ALUI integration with SiteMinder enables the use of SSO between different portal communities, other SiteMinder integrated Applications, and the use of Federation services. BEA documentation on SiteMinder integration can be found here. (pdf here) To really understand this guide, there is a base assumption that you are familiar with the standard methods to deploy ALUI with SiteMinder.
SiteMinder and ALUI will generally share a common ldap store. The users and attributes are sync'd into the ALUI database. On the ALUI side, these are the Auth Source. As in SiteMinder, you can have multiple auth sources. The way SSO works is based on the ALUI SSOServlet getting enough information from the default SiteMinder header values to map the authenticated user with a unique user in the ALUI database. This is done by taking the SM_USER, the DefaultAuthSourcePrefix, and putting those two values together which then map to the user in the ALUI DB.
However, one of the major limitations with the default implementation method (aka SSOVendor=2), is that you must select a single default SiteMinder Domain to store all the policies you would want to use in your portal. This is just fine if your portal implementation is small and used for a single user type like employees. However, if you are building a large scale enterprise implementation for many community types, then you will quickly find that you need to be able to map multiple SiteMinder domains to matching communities.
Our integration design
In our implementation, we had requirements to handle different URLs mapped to different communities each protected by unique SiteMinder domains. We configured ALUI using SSOVendor=50, the basic SSO configuration. By using the basic SSO configuration, you are able to configure the header mapping components used by the SSOServlet. We mapped the values to be the same as when using SSOVendor=2 with one difference. We added a variable to match the ALUI auth source category name. This value is configured as a response header on the SiteMinder policy.
By controlling the PrefixHeader with a variable PT_DOMAIN, we control via SiteMinder policy responses, we can control which auth source the SM_USER is mapped to.
This is how our SiteMinder-ALUI authentication flow is now setup.
The final configuration is done with Experience Definitions. They turn on the SSO process with the communities that are using them. SSO needs to be enabled on the particular experience definition being used to allow for the automatic re-direct to SSOServlet.
