Blog

I was recently at a client site who was having problems with their Single Sign-On Settings. They were using RSA ClearTrust with ALUI running behind WebLogic 8.1 and were seeing performance issues related to SSO. We started troubleshooting the problem by looking at a combination of RSA settings, the portalconfig.xml, and various settings on Apache and WebLogic.

The first thing that we found, which is a common best practice that is avoided, was that the whole portal application was protected by SSO instead of just the SSOServlet. When SSO is enabled in the portal, the first thing the portal will do when it receives a new request is redirect to the SSOServlet, which defaults to /portal/SSOServlet. By limiting your SSO protection to just the SSOServlet, you allow the portal to automatically log users into the portal and also automatically get redirected to the SSO Login screen without the overhead of having every portal request go through the SSO system. By making that change in their system, we were able to increase performance test numbers by over 100%.

The next thing we changed was session timeouts. When deciding session timeouts for the portal and SSO you want them to be close but have the portal session timeout just before the SSO Session timeout. Why? Let's look at both pieces of that statement. First, you want the sessions to be close mainly for performance reasons. Let's say you have your SSO session timeout set at 8 hours and your portal session set at 20 minutes. In this case, after every twenty minutes of inactivity, the portal's session will die and there will be new session created and a "login" to the system will happen behind the scenes. You want the portal session to timeout right before the portal to enforce the session timeout of the SSO server. Remember, as I mentioned above the portal will only redirect you to the SSOServlet when there is no portal session. So, if our scenario from earlier in this paragraph is reversed, the portal session will be valid for 8 hours, but after 20 minutes of inactivity the SSO session will be invalidated. Because of this, the user will be able to do whatever they want normally within the portal, but if she happens to launch another application that is protected by SSO she will be prompted for authentication because her SSO session has expired.

The last change we made was less of a best practice and more dealt with ClearTrust specifically. When we made the first change (only protecting SSOServlet), we had a problem where RSA would not recognize the url /portal/SSOServlet as a valid protected resource and would let all traffic through without protecting it. After trying numerous syntaxes to get it to work, we came up with a workaround. We changed the SSOServlet URL. To do this, we had to make 2 changes on the portal side and one on the RSA side. First, we edited the web.xml in the portal.war file and changed the from "SSOServlet" to "/sso/SSOServlet". Then we edited the portalconfig.xml and changed the SSOVirtualDirectory Path from /portal/ to /portal/sso/. Then finally we changed what was protected in RSA to /portal/sso/*.

So, to summarize. The major things to look for with SSO and the portal are:

1. Make sure you are only protecting the SSOServlet.
2. Make sure your portal session timeout is slightly shorter than your SSO session timeout.
3. If you are having problems protecting only the SSOServlet, change the path for it.