In this article we will see how the Single Sign On implementations use the HTTP Cookies.
Recently we integrated one of our intranet portals in a company-wide SSO. I wanted to test some functionality in the portal locally before releasing it to the Integration environment but was not able to login to the portal
because the codebase was dependent on the SSO solution.
To address this one of my colleague suggested to hit Integration environment and login there. After this in the same browser window type the URL of the locally deployed application.
Of course this is not going to work. Even if the local application has the similar URI, the browser shall not transmit cookie belonging to other domains to locally deployed application or for that matter applications in different domains.
To understand this we need to see how cookies are used in SSO applications.
Let’s say we own on a portal “foo.com” that is SSO enabled. In a Siteminder enabled SSO solution the cookie named “SMSESSION” is used to store the client identity. Consider that I am developing a webapp that will be part of foo.com named “myapp”. Now when we want to integrate this “myapp” as part of the SSO solution we use a sub-domain say “myapp.foo.com”. Of course we need to write some code that would read this SMSESSION and do the thing that would login the respective user in your application.(in this case “myapp”).
Now why we need the sub-domain in this case.
Domains share their cookie information with their sub-domains.
Hence when the Siteminder solution sets the cookie for “foo.com” and when we navigate to “myapp.foo.com”, the server side code serving “myapp” would get SMSESSION cookie that is set at the domain level. Reading and using SMSESSION, “myapp” can login the user in “myapp” and proceed.
In the figure below I am trying to explain this graphically.
Hence if you try a workaround as mentioned above it is not going to work.
In case of tomcat my URL will be “http://localhost:8080/myapp” which is not part of the main domain “foo.com”. Due to this cookie information will never be shared with “myapp” deployed locally.
Hope this helps someone looking for information on this topic.
Your comments/suggestions/corrections are always welcome.