Single Sign On with Centralized Authentication Services

Thought Leadership | Princeton Blue

Today’s enterprise environment where multiple user interfacing subsystems are exposed through composite interface solutions like portals, creates the need for integrating these subsystems with existing authentication and authorization services. The approach described here can be applied to integrate BPM solution, e.g. Lombardi with a Centralized Authentication Service (CAS) provided that the CAS architecture supports token issuance and validation. This solution will address the authentication aspect of the Lombardi integration with the existing application infrastructure.

This Single Sign On solution addresses a scenario where an existing User Interfacing Portal requests a CAS for authentication and CAS responds back with a Token if User is authenticated, the token is passed to other distributed subsystems which validate the CAS token at their respective tier. This approach can be applied to integrate integrating Lombardi external activities or coaches with an existing portal presence.

Single Sign On with Centralized Authentication Services Implementation

The implementation of this Single Sign On approach involves the following significant implementation steps:

  1. The Lombardi client, i.e. Portal, sends the Token along with the request either as a cookie, request or session variable.
  2. Lombardi authenticates the token against CAS, if request is not authenticated the request is denied and a custom error message can be returned.
  3. The authentication can be performed using a Tomcat custom Valve or Filter
  4. Once the Portal request is authenticated at Tomcat Layer, a thread local variable or a session variable is set to authenticate and the request is relayed to the JBoss layer.
  5. A custom JBoss login module extending Jboss UserNamePasswordLoginModule class needs to override the validate password method. The method returns true if token was authenticated or false if it was not authenticated. The new login-module needs to be defined within login-config.xml with sufficient flag. The sufficient flag will bypass existing Lombardi LoginModule once user is authenticated
  6. The request interceptor (Valve or Filter code) and custom Login Module need to be deployed in process server/lib folder.

This approach will support the coexistence of Lombardi processes that are exposed using Lombardi’s internal Portal and its external activities/coaches that are integrated with external portals. Do follow Princeton Blue on Facebook, LinkedIn, Twitter & Google+ to get updates about BPM and related technologies.

Leave a Reply

Your email address will not be published. Required fields are marked *

Want to Learn More?
CONTACT US