Chapter��2.��Application Bus

Description. Provides system administrators with a single point of management for creating users and granting access rights to multiple applications.

Provides users with a single login for multiple applications, Also provides users with a browser toolbar that presents application available and access with a single click.

Solves. Enables integration of multiple applications into a unified user experience.

2.1.��Introduction

2.1.1.��Problem Addressed

????

2.1.2.��AppBus Concept

???

Figure��2.1.��AppBar - User View of AppBus

AppBar - User View of AppBus

2.1.2.1.��FROM PRESS RELEASE

Reno, Nevada, April 26, 2006 – SQI Incorporated today unveiled AppBus™ - the SQI Application Integration Bus. AppBus is middle-ware technology that addresses one of the most difficult issues in the open source revolution – how to integrate separately developed applications into a seamless and secure user experience. SQI uses this innovative middle-ware in its open source-based, on-demand business process offerings.

AppBus includes SQI Authority Services (SAS) and Authority Messaging and Synchronization Framework (AMSF) components. SAS is the central repository of user information – name, password, application access authorization, etc. SAS provides authentication and authorization services to the applications. AMSF provides the messaging interface to the SAS services. For example, when a user tries to access an application, the application sends three requests using the AppBus messaging framework: 1) authenticate the user, 2) validate the user is authorized to access the application, and 3) establish the user's authorized roles with the application.

AMSF supplies synchronization services between an application's view of the user information and the SAS central database of users. This is a unique and critical aspect of the integration. AppBus enables integration with the central database and at the same time maintains application-specific information in the application's original data structure – tight integration with a minimum of code changes.

The synchronization of user information is bi-directional. For example, if a systems administrator uses the SAS web tools to change user information, the changes are propagated out to each application's user data structures. Or, if an application creates a new user on the fly when an email request is processed, the new user information is synchronized to the SAS central database of users.

“AppBus is another example of the power of open source and SQI's commitment to the revolution,” said Jeff Elpern CEO of SQI Inc. “When faced with this integration issue we turned to the open source community for a solution. Central Authentication Server (CAS), originally developed at Yale, gave us a solid solution to the authentication part of the problem. We leveraged CAS and extended the framework to address the full range of integration issues, particularly our need for flexibility with security.”

“Flexibility is an important aspect of open source integration,” said Steve Tindle, Chief Integration Architect for SQI. “The design of AppBus allows multiple levels of integration. At the lowest level, user authentication and access rights services are provided by AppBus with minimal change to the application's user management code. At the top end, an application relies on AppBus for all user management. This allows an application to be quickly integrated into the SQI framework with the opportunity to increase integration over time.”

2.2.��Operations

???

2.2.1.��New User - An Example of Integration and Single Point of Management

???

Figure��2.2.��Use AppBar to go to Use Management

Use AppBar to go to Use Management

Figure��2.3.��Select New User function

Select New User function

Figure��2.4.��Create User

Create User

Figure��2.5.��Grant Access to Applications

Grant Access to Applications

2.3.��Reference Material

2.4.��Technical Overview

2.4.1.��Steve's Email

This figure outlines the major components of the SQI CIE3 system.

Figure��2.6.��Component Overview

Component Overview

  • Sphere. At the heart of CIE3 is the Sphere server (upper left). Sphere's primary purpose is to provide a communication and synchronization framework for diverse software services. Applications integrated in to CIE3 are extended to allow communication with this framework. By allowing all the applications to communicate with Sphere, new features are possible.

    For example, when someone searches using the instant search bar on the AppBar, a request is sent to the KnowledgeDex Search component in Sphere. This component then sends a request to the KnowledgeDex Server to get a full list of results across all indexed applications. Because not everyone will have the permission to view every page in a site, security has to be applied to the results. A call is made to all applications that have the Permissions RPC extension to make sure the current user has the right to even know the existence of the document. The newly filtered results for this user are then sent back to the AppBar and displayed in less than a second.

    The above example demonstrates the power of connecting diverse applications in ways that the original programmers never intended to occur. We took two different open source applications (Apache Lucene and MoinMoin) along with authentication and authorization integration to create an enterprise-quality permissions-based search engine at a much lower cost than creating the entire system from scratch.

  • AppBus. Sphere components can communicate to other outside services in any manor it needs to, but ultimately these communications are adapted so that they may be accessed on the AppBus. This allows for applications that do not need to know everything about the other applications it communicates with so long as it follows a specific interface. For example, the Identity Manager itself does not know anything about the Knowledge Center or Incident Manager. All it knows about are Identity Providers. There are adaptors for the other applications that translate this standardized communication in to something the local application can understand. This allows for a simplified framework where new features do not break existing integration.

  • Authentication Server and Manager. SQI CIE3 uses one of the best multi-site single-sign-on services in existence. Based on Yale Central Authentication Service, SQI uses the same base service that is usually only seen on very large and scalable internet systems. CAS is used by organizations with large user bases including a company that sells and hosts a massively multiplayer online role playing game (MMORPG) with over 16 million players.

    SQI has also developed a more robust and efficient integration of CAS and Apache HTTP server. There is a performance increase of approximately 40% over the other authentication plugins currently available for CAS integration with Apache HTTP server and supports multiple servers and web services to be authenticated by the same Authentication Server instance for a client's site. SQI can integrate nearly any web service designed to run on Apache quickly and with little effort. As an aside, if a client would like to run certain services on their own servers, those services can be authenticated with SQI's Authentication Server. Sign on once to be authenticated with many applications on many servers at different locations.

  • Identity Management.  The Identity Manager built in to Sphere allows a user to be created in a single location, then information to be pushed to the other applications with a Sphere Connector. The site administrator has the option to allow a user to only access certain applications and to synchronize information with all of the applications a user is created in. This easy synchronization takes a lot of frustration out of managing multiple web services.

2.4.2.��JA-SIG Central Authentication Service

2.4.2.1.��Overview

Single Sign-on for the Web
[Note]Note

The content in this section extracted from the JA-SIG CAS Home page

Welcome to the home of the JA-SIG Central Authentication Service (CAS). CAS provides enterprise single sign on service:

  • An open and well-documented protocol

  • An open-source Java server component

  • A library of clients for Java, .Net, PHP, Perl, Apache, uPortal, and others

  • Integrates with uPortal, BlueSocket, TikiWiki, Mule, Liferay, Moodle and otherst

  • Community documentation and implementation support

  • An extensive community of adopters

CAS is an authentication system originally created by Yale University to provide a trusted way for an application to authenticate a user. CAS became a JA-SIG project in December 2004.

2.4.2.2.��CAS 1 Architecture

[Note]Note

Content in this section extracted for JA-SIG web page CAS 1 Architecture

2.4.2.2.1.��Rationale and Overview
  • To facilitate single sign-on across multiple web applications, as well as to core services that aren't necessarily web-based but have a web front end.

  • To allow untrusted services offered by organizations other than ITS (as well as, of course, trusted services) to authenticate users without having access to their passwords.

  • To simplify procedures that applications need to follow in order to perform authentication.

  • To localize actual ("primary") authentication to a single web application, which makes it easier for users to safeguard their passwords and which lets ITS change authentication logic if necessary without having to change numerous applications.

2.4.2.2.2.��Design and Implementation

The Central Authentication Server (CAS) is designed as a standalone web application. It is currently implemented as several Java servlets and runs through the HTTPS server on secure.its.yale.edu. It is accessed through three URLs described below: the login URL, the validation URL, and the optional logout URL.

2.5.��Extensions

[Note]Note

Here are links to note on nest steps for this technology.

InfraComps/ChapAppBuss (last edited 2015-03-06 18:11:26 by localhost)