Case Study: ABS OAM

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

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.


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.


(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)


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.


Case Study: ABS OAM

Documents

Transcript of Case Study: ABS OAM