In our current enterprise project we have a single sign on requirement, and IBM portal is planned to be used as the main gateway in our system. Basically, we need to provide an authentication mechanism, through which users should only need to login to the portal, and then be able to access all of their authorized web applications without being authenticated again. They could also be able to access those web applications directly if they know their URLs, this time they have to get authenticated before using any of them.
We have chosen to use Central Authentication Service, which is an open source enterprise web single sign on application, in order to implement our SSO requirements. We have also chosen Acegi Security Framework as our security infrastructure and be very happy with it. We have many security requirements, that are very common to many enterprise systems, and be able to resolve them easily via Acegi. Acegi has also support for Central Authentication Service.
The problem here was to integrate IBM Portal with our security infrastructure. IBM provides a single sign on mechanism among its family of products, based on LTPA token. We didn?t want to depend on such a solution as it is more specific to IBM products. CAS provides a much less intrusive, and more open platform SSO mechanism.
Luckly, IBM Websphere Application Server provides an interceptor mechanism, called Trust Association Interceptor, in its security infrastructure. Basically WAS supports identity assertion, instead of requiring proof of identity. Clients pass identity information to WAS via TAI, and WAS trusts that passed identity information and doesn?t require an authentication further. Once authentication has occurred, it creates an LTPA token and sends it as a session cookie to user?s browser. As a result, other IBM products, such as portal, gets authenticated via this LTPA token automatically.
Following diagram shows our IBM portal and CAS SSO integration architecture via TAI. I want to explain what is going on when an unauthenticated request arrives at our portal.
When an unauthenticated request comes to the portal?s main page (wps/myportal), normally users are redirected to portal?s login page. In our solution we modified that login page, and redirected users automatically to the CAS?s login page, providing portal?s main page URL (wps/myportal) as CAS service URL.
When users arrive at CAS login page, they provide their credential information, and CAS authenticates them by looking at our user registry. In our system, we have users both defined in active directory, and in a relational database. This user registry structure brings some oddness to portal-active directory integration, but I will mention about it later.
If CAS has authenticated users successfully, it redirects them to the service URL (wps/myportal) , by the way providing service ticket as a request parameter.
TAI is configured to get activated and begin its work when it sees that ticket request parameter in coming requests.
public boolean isTargetInterceptor(HttpServletRequest request) throws WebTrustAssociationException {
String value = request.getParameter("ticket");
boolean result = StringUtils.isNotEmpty(value);
return result;
}
If it sees ticket request parameter, it begins its work. Basically, what it does in its public TAIResult negotiateValidateandEstablishTrust(HttpServletRequest request, HttpServletResponse response) method is explained below;
- First it extracts service ticket value from request, and validates it through CAS validation url.
- Then it looks for user information via received netid from CAS validation process through domino directory server, which is configured as user registry for IBM portal. The reason behind using it instead of active directory lies in our user registry configuration as I said above, and will mention about it later on.
- If it doesn?t find any entry corresponing to the current netid, it creates one user definition, utilizing our current user information, which resides either in active directory, or relational database. If portal were using active directory and active directory were our user registry alone, there wouldn?t be such a step here.
- It prepares a JAAS subject corresponding to that user entry in domino directory server.
- Finally, it returns a successfull TAIResut, containing that Subject instance in it.
After return of TAI, portal trusts that authentication information, and lets user get into its main page. Following user queries necessary for portal execution are done through domino directory server, which is configured as portal?s user registry.
As a result, we have a cleanly integrated IBM portal into our SSO infrastructure, and from that point on portal can be seen as if an ordinary web application in our big picture!