Thursday, December 8, 2011

Open AM, and WebLogic Application Server - Single Sign On

Summary
Since OpenAM(previously OpenSSO), and WebLogic Application Server 10.x support SAML2.0, Single Sign On can be implemented using SAML 2.0.  A simple prototype was developed, and Single Sign On was implemented relatively easily.
Architecture
Open AM was deployed on Tomcat 6.0.20.  A basic secured J2EE application using form login, and role based authorization was deployed in WebLogic Application Server.  Circle of Trust was configured in Open AM with OpenAM on Tomcat as Identity Asserter, WebLogic Application Server as Service Provider.  SAML2Identity Asserter was configured in the realm->security->providers tab for authentication.
SAML2IdentityAsserterNameMapper
Name Mapper is required to decrypt the userid received from the Identity Asserter, and delegate the authorization to WebLogic Application Server.  While Open AM documentation is limited to Open AM implementation of Circle Of Trust, there was no mention of WebLogic Application Server, WebLogic documentation is spread across multiple documents, and is a little challenging to figure out the relevant parts of information.  Configuring the Name Mapper was challenging, as the debug messages, and error messages were at best clueless.
WebLogic requires that the Name Mapper class should implement the interface SAML2IdentityAsserterNameMapper.  Accordingly created a single class implementing the required interface, SAML2IdentityAsserterNameMapper.  The interface consists of single method, and the implementation is shown below:
    @Override
    public String mapNameInfo(SAML2NameMapperInfo saml2NameMapperInfo, ContextHandler arg1) {
        String user = saml2NameMapperInfo.getName();
        System.out.println(user);
        return user;
    }
That provided the userid, inplain text, and was usable by WebLogic Application Server for authorization.
Jar File Location
While developing code was no brainer with clear documentation, deploying the jar file in the correct location was a little challenging.  Tried copying the jar file into various locations with clueless error messages.  After digging deep into WebLogic documentation, finally found that the jar file should be placed in WebLogic's system classpath and accordingly modified the file <WL_HOME>\common\bin\commEnv.cmd and included the location of the jar file as part of the environment.  This enabled WebLogic to find the Name Mapper class, and specify the Name Mapper while configuring the Identity Asserter.
Incorrect Location of Jar File, and Error Messages
For any other location, the error messages in the console and log files were:
Message icon - Error An error occurred during activation of changes, please see the log for details.
Message icon - Error [Management:141191]The prepare phase of the configuration update failed with an exception:
Message icon - Error SAMLBeanUpdateListener SAML2IdentityAsserter: prepareUpdate() failed with exception: [Security:096628]The value configured for NameMapper attribute: com.security.test.TesterImpl1 is not valid.
Go and figure out the meaning of the error messages.
Benefits of the Implementation
With this simple approach, secured J2EE application was accessible through SSO login, and also the form login without modifications to the existing war/ear.  Compared to OpenAM's Fedlet, and Agent Based approaches SAML2.0 provides a clean approach for Single Sign On without making any changes to existing applications, and enable Single Sign On.  


Saturday, October 8, 2011

GlassFish 3.01 - Problems with Automatic update - PWC6177: XML parsing error

Glass Fish Application Server v3.01
Had a full working version of Glass Fish Application Server v3.01, configured with datasources, security configuration, custom resources, a couple of applications deployed.  Left it overnight, and started adding new functionality to the application early in the morning with the new ideas collected overnight.  While trying to test the very first idea, hit with the Glass Fish's application server automatic update defect.  Can not open the admin console, can not deploy any application.  The details of the errors are:

Can't Open the admin console

[#|2011-10-08T18:41:57.383-0400|SEVERE|glassfish3.0.1|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=24;_ThreadName=Thread-23;|DPL8005: Deployment Descriptor parsing failure : [Ljava.lang.Object;@2fd6fc1b|#]

[#|2011-10-08T18:41:57.392-0400|SEVERE|glassfish3.0.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=24;_ThreadName=Thread-23;|Exception while deploying the app
java.io.IOException: Unable to locate the DTD to validate your deployment descriptor file [WEB-INF/web.xml] in archive [__admingui]. Please make sure the DOCTYPE is correct (no typo in public ID or system ID) and you have proper access to the Internet.

. . .      . . .

. . .      . . .

Caused by: java.net.ConnectException: Connection timed out: connect
        at java.net.PlainSocketImpl.socketConnect(Native Method)

. . .     . . .

. . .     . . .

Can't deploy any application

[#|2011-10-08T18:45:28.686-0400|SEVERE|glassfish3.0.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=25;_ThreadName=AutoDeployer;|Exception while loading the app
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.apache.catalina.LifecycleException: org.apache.jasper.JasperException: PWC6177: XML parsing error on file file:/C:/Users/htotapally.IF-SWS-TESTLTP4/glassfishv3/glassfish/modules/jstl-impl.jar

While trying to figure out the problems why Glass Fish Application Server doesn't start, came across quite a few blogs, and none of them providing any clear solution.  However the following two were useful:

Useful links

http://blogs.oracle.com/jluehe/entry/validate_your_tag_library_descriptor
http://thegreyblog.blogspot.com/2010/11/glassfish-30x-admin-console-not.html

Based on the error message:
org.apache.catalina.LifecycleException: org.apache.jasper.JasperException: PWC6177: XML parsing error on file file:/C:/Users/htotapally.IF-SWS-TESTLTP4/glassfishv3/glassfish/modules/jstl-impl.jar
unzipped the file, and the dtds were referring to java.sun.com and the update package application was trying to access pkg.glassfish.org.  Both servers were not accessible.  This lead me to believe that the update application caused the problem.  Wasted about 10 hours trying to troubleshoot the problem, and finally no solution insight reinstalled the application server.  After renaming console-updatecenter-plugin.jar to console-updatecenter-plugin.jar.old, restarted, and reconfigured the application server, redeployed the application, and every thing started working finally, but have to wait another day to implement last nights ideas.  What a pain?