X

Best Practices from Oracle Development's A‑Team

A Work-around for the Session Overwrite Problem in WebLogic SAML SSO

Introduction

While working on my previous post "Configure SAML 2 for SSO with Oracle BAM Dashboard", I noticed an issue. After SSO to BAM happens from mywebapp1, if I reload the mywebapp1 page, I get prompted for login again. A little debugging pointed me to the session overwrite issue, in which I will get into more detail next. This issue puts a significantly limitation on WebLogic SAML SSO. While it has been documented several times out on the internet, a solution to this issue is harder to find. I tried a few possible work-around suggested by some posts such as changing the application cookie names. But they did not work in my testings.

With a little luck, I happened to run into a discussion forum (link here). Buried deep in the forum is a snippet of WebLogic Apache Plugin configuration posted by user Luis. The snippet is used to manipulate cookie names to get around this issue. In my testing, this idea actually worked flawlessly. In this post, I am trying to provide a more detailed explanation of the issue and the work-around, as well as the complete set of configuration files used in my testing.

The Issue

The issue is best explained in the following sequence of messages related to SAML SSO.

saml-post

The fact that WebLogic SAML web app (/saml2/idp, /saml2/sp) has a fix default session ID (JSESSIONID) forces all SAML SSO participating web apps to use the same session ID. You can see, in the above diagram, step 10 is where the new session ID value from "saml2/sp" over writes the old value from webapp1. So in step 11, when a reload of mywebapp1 is requested, mywebapp1 cannot find an existing session based on the new value and thus, another login prompt.

A Solution

The basic idea of this solution is to use WebLogic Apache plugin to rename the default cookie name (JSESSIONID) to something unique (mywebapp1JSESSIONID and bamJESSIONID) before the proxy sends response to browser so that there is no chance of overwrite. When requests are going from browser to servers, the plugin will reverse the process and rename the unique cookie names (mywebapp1JSESSIONID and bamJESSIONID) back to JSESSIONID so that servers can understand. The following diagram illustrates the details.

saml-post-proxy

Configuration

As a final step, we need to configure Front End Host and Port parameters in WebLogic Console to point them to the proxy servers and do the same for "Published Site URL" in both IDP and SP SAML 2.0 General Configuration in the Federation Service tab.

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha