Uright Tech Blog

I was working on a portal project that has a requirement of doing user impersonation from one application to anther application. This would require some kind Single Sign On mechanism. In Oracle WebLogic 10.3 framework, I’ve found four solutions that we can implement SSO easily. Depending on the environment setup, the design of your applications and the level of configurations we’d like to touch, one solution is better than the other one. Let’s go into more details for each of them.

Four solutions for SSO in Weblogic 10.3

1. Session Sharing
2. Security Realm Subject (Single Domain)
3. Global Trust
4. SAML 1.1/2.0

Session Sharing

When two applications share the same session, we can store user information in a session variable from one application, and use it in another application to check whether the user is authenticated or not.

Configuring session sharing in Weblogic is very simple. The applications would need to be deployed under same EAR file. Then we need to configure the weblogic-application.xml file under the EAR project.

<?xml version="1.0" encoding="ISO-8859-1"?>
<wls:weblogic-application xmlns:wls="http://www.bea.com/ns/weblogic/weblogic-application"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/javaee_5.xsd http://www.bea.com/ns/weblogic/weblogic-application http://www.bea.com/ns/weblogic/weblogic-application/1.0/weblogic-application.xsd">

 <wls:session-descriptor>
     <wls:persistent-store-type>memory</wls:persistent-store-type>
     <wls:sharing-enabled>true</wls:sharing-enabled>
 </wls:session-descriptor>
</wls:weblogic-application>

One of the advantages using session sharing is that it requires no domain level configurations. However, one disadvantage is the type of session variables have to be common for session sharing applications. Although we can simply implement some sort of common project that holds all the common types to resolve potential data type conflicts, this would require a lot of code changes and it isn’t preferred when you already have a lot of the code written and tested. Moreover, bundling multiple unrelated web applications into one single EAR for only the purpose of Single Sign On may sound a little awkward. For these reasons, it’s worth to look at other options.

Security Realm Subject (Single Domain)

The basic idea is if a user is authenticated in one application, the user principals are signed and stored in a subject container which is visible to all applications within the same domain. For more explanation regarding Weblogic Security Realm, please check out some documents from BEA.

I’ll describe very briefly and just to point out some key procedures in implementing SSO using this solution. When I get a chance, I’ll write another post to describe it in details. I’ve tested and verified that it works in environment with multiple managed servers.

Let’s assume we have two applications AppA and AppB such that AppA will have authenticate user from a form and provides an anchor to access

1. In Weblogic Admin Console, under security realm, add your own authentication provider. (Possibly ActiveDirectory or SQL Database provider)
2. In AppA, Authenticate user using UsernamePasswordLoginModule from weblogic which implements the standard JAAS LoginModule interface.

   @Jpf.Action
   public Forward login(MyForm form) throws Exception {
       try {
           this.login(form.getLoginName(), form.getLoginPassword());
           // Login Successful
           return new Forward();
       }
       catch (Exception ex) {
           // Login Failed
           throw ex;
       }
   }
   

3. In AppB, check for user principle.

   @Override
   public boolean preRender(HttpServletRequest request, HttpServletResponse response) {
       if (request.getUserPrincipal() == null) {
          // User is unauthenticated
       }
       else {
           // User is logged in
       }
   }
   

   Alternatively, you may secure contents in AppB by modifying the weblogic.xml and web.xml as follows:
   
   weblogic.xml

   <?xml version="1.0" encoding="UTF-8"?>
   <wls:weblogic-web-app xmlns:wls="http://www.bea.com/ns/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd">
       <security-role-assignment>
   		<role-name>Users</role-name>
   		<principal-name>everyone</principal-name>
   	</security-role-assignment>
   </wls:weblogic-web-app>
   

   
   
   web.xml

   <?xml version="1.0" encoding="UTF-8"?>
   <web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
       <security-constraint>
   		<web-resource-collection>
   			<web-resource-name>SecurePages</web-resource-name>
   			<description>These pages are only accessible by authorized users.</description>
               <url-pattern>/com/cit/ecommerce/controller/sso/SsoController.jpf</url-pattern>
               <http-method>GET</http-method>
               <http-method>POST</http-method>
   		</web-resource-collection>
   		<auth-constraint>
   			<description>These are the roles who have access.</description>
   			<role-name>Users</role-name>
   		</auth-constraint>
   		<user-data-constraint>
   			<description>This is how the user data must be transmitted.</description>
   			<transport-guarantee>NONE</transport-guarantee>
   		</user-data-constraint>
   	</security-constraint>
       <login-config>
   		<auth-method>CLIENT-CERT</auth-method>
   		<realm-name>myrealm</realm-name>
   	</login-config>
   	<security-role>
   		<description>These are the roles who have access.</description>
   		<role-name>Users</role-name>
   	</security-role>
   </web-app>
   

The good part about this solution is that it requires no custom configurations on the domain level. Though, it constraints applications to be deployed on a single domain. To support cross domain SSO, let’s look at the next option.

Global Trust

I haven’t had a chance to try this one out. But from readings, it’s really like spreading Domain Subjects pool across domains via RMI. Check this link out for details.

SAML 1.1/2.0

There’s a very detail explanation about how to configure SSO with SAML 1.1 in this article. It is secured and one of the standard protocol to exchange user principals across domains. One main advantage to use SAML over Global Trust is it works with other web applications that doesn’t neccessarily need to sit under Weblogic server.