American Bureau of Shipping engaged Partners Consulting to deploy a single sign-on solution for its customer-facing applications. Partners implemented Oracle Access Manager for centralized authentication, authorizing users through WebLogic Security Provider Interface. They migrated user data to Oracle Internet Directory and configured Oracle Access Manager policies and WebGates to provide single sign-on for over 20 portal applications while integrating with the existing WebLogic security framework.

1. American Bureau of Shipping
Oracle Access Manager and the WebLogic SSPI
In 2009, Partners Consulting was engaged by a worldwide marine and offshore
classification and standards organization located in Houston, Texas. The primary
focus of the business was to verify that merchant ships and marine structures
comply with rules that the society has established for marine and offshore
design, construction and periodic survey. The organization’s divisional offices
support a worldwide network of more than two hundred representative offices in
over 60 countries.
Centralized Access Management
The organizational goal was to deploy a commercial off-the-shelf solution in
order to provide Enterprise Single Sign-On (SSO) to their customer facing web
applications. The marine and offshore compliance and standards applications
(and other static resources for builders were all served from a WebLogic Portal
environment. External users could either register by phone or via the portal
interface and request the appropriate access or rights from the organization.
However, in the organization’s existing access request model, development
teams would still have to write custom authentication into each of the web based
applications in order to achieve SSO with other applications not served from
WebLogic Portal.
It was determined that it was necessary to license and deploy an Access
Management solution that would not only provide seamless integration with the
WebLogic Security Provider Interface, but also help eliminate the cost and time
required to write authentication into individual customer facing applications.
The Challenges Faced
• Credentials were stored in separate Oracle databases and the
organization had no centralized LDAP repository.
• Customers had to logon to each application separately to receive the
appropriate authorization
• Existing development effort had not kept up with growth, compounding
current Access Management issues.
www.partnersconsulting.com | 1(866) 736.5500

2. The Partners Consulting Approach
Partners leveraged our 4D Methodology™ that we developed from our years of
consulting experience. Using our methodology, we were able to provide expert
oversight, monitoring, and reporting on the issues enabling the organization to
make decisions that were best for their needs at the appropriate time throughout
the project.
Partners Consulting Enabled Success
• Determined the specific technical, functional, and business requirements
for a new development environment.
• Migrated existing user data from internal and external Oracle databases
to a single instance of Oracle Internet Directory (OID).
• Established a SSO development environment with integrated Oracle
Access Manager (OAM) and WebLogic Portal installations.
• Deployed the Oracle WebLogic SSPI Connector and custom security
realm to map users and security roles to centralized access policies.
• Delivered detailed training for the Web Security teams tasked with
managing the OAM deployment.
• Provided a roadmap for the steps necessary to build additional test and
production environments.
www.partnersconsulting.com | 1(866) 736.5500

3. Oracle Access Manager
With the guidance of Partners Consulting, the American Bureau of Shipping
chose Oracle Access Manager (OAM) over other competitors as their web
access management solution to address their needs with respect to:
• Enterprise Single Sign-on (SSO)
• Centralized Policy Management
• WebLogic SSPI Integration
A Central User Repository
Partners Consulting installed an instance of Oracle Virtual Directory (OVD) to
connect to the existing Oracle Database instances and provide a view
(“virtualized” abstraction) of user data in a structured LDAP hierarchical format.
Once the connectors were defined and a single unified user tree was created in
OVD, Partners Consulting then performed a data migration using standard
Oracle utilities and exported the user data. A new central user repository was
created and stored in a new instance of OID.
The OID would hold the new user directory tree with organizational units to
contain user, group, and access policy data. The OID instance would serve as a
central repository for all of this data going forward, and OAM would be able to
authenticate from this LDAP directory. OID now provides the organization the
ability to integrate web based applications protected with OAM while minimizing
the need to change either the infrastructure or the applications being developed.
A Single Sign‐On (SSO) Environment
To alleviate the burden of having to re-write individual applications to integrate
with an existing SSO solution, Partners Consulting had to deploy an Access
Management solution that would integrate with existing WebLogic Portal
applications and their security realms. The solution would not only need to
provide SSO to all customer facing applications, but it would have to perform
role-based authorizations that would be understood by WebLogic Portal.
Partners Consulting installed OAM to provide the authentication, authorization,
and auditing services necessary to protect more than 20 portal applications.
www.partnersconsulting.com | 1(866) 736.5500

4. (SSO, continued)
The base solution was comprised of OAM Identity and Access Servers
installed on a single machine. These servers serve as the “decision making”
components in basic user and access management for the organization. Then
OAM’s “WebGates” were plugged into existing web servers as the “policy
enforcement points”.
User’s requesting access to portal applications would either have to present an
SSO authentication token or they would have to authenticate to with whichever
authentication mechanism was defined for that application. Once a user
authenticates to a WebGate protected resource he or she is granted an
obSSOCookie (token) and is not authenticated again until a designated timeout.
Existing WebLogic Security
The greatest challenge for the organization however, was not in simply creating
an environment where users had only a single authentication. For this
organization, the entirety of their applications in the portal had all been written to
authenticate and authorize users within the WebLogic security model.
In this model, a security principal (user or group with a collective set of
permissions) is set and the roles assigned to that principal are determined for
authorization to a given resource.
The SSPI Connector
In the development environment, OAM was integrated with the existing
WebLogic Server and Portal by installing and configuring a WebLogic SSPI
Connector. The SSPI connector installation forms a bridge between OAM and
WebLogic. A new security realm is created and was configured to trust OAM’s
session cookie for authentication and to read and map user roles to WebLogic
security roles and application permissions. The connector allows SSO and
eliminates the need to re-write security in existing applications.
(A diagram of the OAM and WebLogic authentication flow is included on the last
page of this document)
www.partnersconsulting.com | 1(866) 736.5500

5. How the Connector Works
1) In the client’s environment, a user attempts to access an OAM protected
Web application that is deployed on the WebLogic Server as a part of the
Corporate Portal.
2) Then OAM’s WebGate plug-in, intercepts the request and queries an Access
Server to check if the resource is protected.
3) If the resource is protected, WebGate redirects the user’s browser to the
Corporate Portal login page portlet.
4) In the login portlet the user presents their user name and password for
authentication as they normally would.
5) If the user authenticates successfully, WebGate generates a session cookie,
which it appends as an HTTP header; the Web server forwards this HTTP
request to the WebLogic proxy plug-in which forwards the request to the
WebLogic server.
6) The WebLogic proxy plug-in passes the cookie in the HTTP header to the
WebLogic Server.
7) The WebLogic Server's security service was configured to expect the OAM
cookie as an external token for validating the user. The WebLogic security
service then sets the cookie in the HTTP response.
8) The WebLogic Identity Assertion Provider then extracts the cookie
information from the HTTP header, validates the cookie, and retrieves the
user identity from the OAM Access Server.
9) When authentication is successful, a Role Mapping Provider uses the
WebGate to communicate with the Access Server to determine what OAM-
defined roles are assigned to this user. These roles are then mapped to
security roles in WebLogic.
10) The Authorization Provider uses the WebGate to ask the Access Server to
verify that the user has permission to access the requested resource. The
policies that protect resources are specified in OAM.
11) If authorization is successful, the WebLogic Server allows the user access to
the requested resource.
12) In this scenario, if the cookie is already set, the user is logged in without
being challenged.
www.partnersconsulting.com | 1(866) 736.5500