Single SignOn and HTTP Cookies

Hello,
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.

Single SignOn and HTTP Cookies

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.

Cheers !!
Amit

Intercepting HTTP Response using Servlet Filter

Hello,
Servlet Filters are used to intercept the HTTP Requests/HTTP Responses.
Filters generally contain some logic that can be applied across a URL pattern.
I have used filters generally to verify if user is logged in or if user has appropriate privilege to access the resource.
While addressing such requirements we end up writing a Filter that is better known as Request Filter because it
intercepts the HTTP request. So most of the time when I ask someone if they know how to implement a HTTP Response Filter, they look puzzled. Of course,I too have gone through this situation in past.

Below is the sample code for Filter(Request Filter)  –

package com.amit.web.filter;

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;

public class MyFilter implements Filter {

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
// place your code here
 // pass the request along the filter chain
chain.doFilter(request, response);
}

public void init(FilterConfig arg0) throws ServletException {}
public void destroy() {}
}

You would know that the line “chain.doFilter(request,response)“, is responsible for executing the next Filter or web resource in line.
Hence if I map MyFilter for servlet named MyServlet then any request for MyServlet would be intercepted by MyFilter. When it encounters “chain.doFilter(request,response)“,it would call the MyServlet’s service method.
Once MyServlet has finished its task, the call to “doFilter” would return and if there is no code/logic written after this line, HTTP Response goes back to the client.
This precisely is the location where we can write the code that would alter the HTTP Response.
This means if we need to write a HTTP Response filter i.e. intercepting HTTP Response, then we need to write the business logic after “chain.doFilter(request,response)” and we are intercepting the HTTP response before it reaches the destination.  The method doFilter that would serve as HTTP Response filter is shown below –

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
chain.doFilter(request, response);
//PLACE YOUR CODE HERE THAT MODIFIES THE RESPONSE.
} 

Overall this is preety easy but usually goes unnoticed which is the reason I felt writing about this.

Another important point about Servlet Filters is –
Consider there are MyFilter1, MyFilter2 and MyFilter3 configured for any requests to Servlet MyServlet.
In this case MyFilter1, MyFilter2 and MyFilter3 will be executed in the order of configuration while intercepting the HTTP Requests.
While sending back the response they would be executed in the REVERSE order as shown in the diagram below.

Hope this helpes someone who is wondering how to implement HTTP Response Filters.Cheers !!
Amit