SSO Implementation

E HEALTH Oracle Adaptive Access

Management Implementation
Migration Design Document
Version 1.0

Page | 1
Confidential and proprietary information. For internal use only.
SSO Implementation

Table of Contents

Table of Contents
1. Version History..................................................................................................................................... 2
2. Introduction......................................................................................................................................... 3
2.1) Background................................................................................................................................. 3
2.2) Purpose of the project................................................................................................................. 3
2.3) Intended Audience...................................................................................................................... 3
2.4) Project Scope............................................................................................................................... 3
2.4.1) In-Scope..................................................................................................................................... 3
2.4.2) Out of scope............................................................................................................................... 4
3) Architecture Overview............................................................................................................................. 5
3.1) Oracle Access Manager Overview..................................................................................................... 5
3.1.1 OAM Components....................................................................................................................... 5
4) Logical Deployment Architecture............................................................................................................. 7
5) Physical Deployment Architecture........................................................................................................... 7
6) OAM Solution Architecture...................................................................................................................... 8
6.1) User Request Data Flow.................................................................................................................... 8
7.2) Authentication and Authorization..................................................................................................... 9
6.2.1) Authentication sequence for EBS Access Gates:.........................................................................9
7) Glossary................................................................................................................................................. 10

1. Version History
Version Date of Description of Reason for Affected Prepared by Approved
revision change change sections by
1.0 6/2/2017 Initial draft Initial draft All Kapstone
Team

2. Introduction

2.1) Background
Page | 2
Confidential and proprietary information. For internal use only.
SSO Implementation

Currently Health, Ontario is using Oracle Adaptive Access Manager (OAAM) 11gR1 as risk profiling and
multifactor authentication solution. MFA solution is built on windows platform. The purpose of OAAM
migration is
 Migrate adaptive services from Windows to Linux platform
 OAAM 11gR1 is not supported version by Oracle, hence migrating OAAM to 11gR2 PS3 version

2.2) Purpose of the project

As of this writing, the scope of the project aims at migrating select applications from the legacy
OAAM infrastructure based on OAAM R1 11.1.1.5.) to a new infrastructure based on Oracle Adaptive
Access Manager (OAAM)11gR2PS3 (OAAM 11.1.2.3.0).Currently env is running on windows platform
2008 R1 which is outdated to more compatible Linux platform.
In the project we also aim to create a High Availability OAAM environment for improving performance
which would eventually simplify the infrastructure and integrations, reduce operational cost and
complexity and run the infrastructure supported by the technology vendor.

2.3) Intended Audience

This document is primarily intended for the OAAM architects, OAAM engineers and OAAM
developers, and OAAM support staff at EHealth Ontario. Additionally, this document serves as a
reference for the application owners, other stakeholders and support staff.

2.4) Project Scope

2.4.1) In-Scope
1. Re-architect current environments from 2 -node oaam clusters setup.

2. Build new environment in a load balanced configuration using internal HA.

3. Build new Production SSO environment in a load balanced configuration using internal HA
Netscalers in the Houston datacenter.

4. New environments will be 11gR2 PS3, compatible with EBS 12.1.3

5. OID will be migrated off of the Exadata RAC platform and built on the new NetApp platform.

6. All existing federated policies and partners should be established in the new environments.

7. The implementation should be deployed such that there is minimal disruption to users and
existing operations.

8. Given the timeline that all data must be off of the Exadata system before October, this project
must be completed prior to that date.

2.4.2) Out of scope

1) Co-existence between new OAM Environment and legacy infrastructure. OAM is being built
as a stand-alone SSO solution and legacy infrastructure will be decommissioned.

2) Fine grained access control - The OAM solution will enforce the user access control based on
the existing infrastructure OAM Policies.

3) Native development or configuration changes on target applications/platforms - Any code or

configuration changes required inside the application to accommodate the OAM solution
Page | 3
Confidential and proprietary information. For internal use only.
SSO Implementation

will be handled by the respective application teams. The Identity and Access Management
(IAM) delivery team will communicate the required changes to the application teams and
collaborate with the application teams in change implementation.

4) Hardware infrastructure setup and the required network device changes to support OAM
implementation.

5) Setup of network infrastructure to support high-availability.

Page | 4
Confidential and proprietary information. For internal use only.
SSO Implementation

3) Architecture Overview
The architecture overview describes the high-level elements of the solution and how they interact with
each other.

3.1) Oracle Access Manager Overview

3.1.1 OAAM Components

The access management solution delivered by the IAM Delivery Team for Southwestern Energy
(SWN) is Oracle Access Manager (OAM), part of the Oracle Identity Management Suite. The OAM
access management solution consists of the following major components.

 Weblogic
OAM 11g is a 100% java application. Weblogic acts as a container for the OAM access server and
the OAM admin console.

 OAAM Server
The OAM access server acts as a policy decision point (PDP). All the authentication and
authorization decisions are made at the access server layer. The terms OAM Server, OAM Access
Server, and Access Server are used interchangeably in this document.

 Database
OAM stores its access policies in a database.
OHS
OHS act as a policy enforcement point (PEP) for web applications. The webgates are installed at
the web tier and track user URL requests. Webgates rely on the access server to determine
whether a resource is protected, whether a particular user has access to a specific application
etc. and enforces those access decisions at the web server layer.

 OAAM Admin Console (PAP)

The access server configuration is done using the OAM Admin Console. The admin console acts
as a policy administration point (PAP) where the application access policies and authentication
schemes could be configured.

Page | 5
Confidential and proprietary information. For internal use only.
SSO Implementation

HIGH LEVEL ARCHITECTURE

Net Scalar Global VIP - OHS

7777/443

OHS Server 1 OHS Server 2

Webgate Webgate
Mod_WL_OHS Mod_WL_OHS

14100/14101

OAM Server 1 OAM Server 2

ADMIN Server
OAM/OIF Managed Server
OAM/OIF Managed Server OAM Policy
OID Server 1 Store
– OID

User Identity
ADMIN Server
Net Scalar Global VIP

Store
ODSM Managed Server
OID Instance
3131
NETAPP
OID Server 2 USER
Details
USER
ODSM Managed Server Details
OID Instance EBS AG Server 1 EBS AG Server 2

ADMIN Server
OAM/OIF Managed Server
OAM/OIF Managed Server

Page | 6
Confidential and proprietary information. For internal use only.
SSO Implementation

4) Logical Deployment Architecture

The Production OAM infrastructure will be deployed in the Southwestern Energy (SWN) environment
with high-availability. The primary OAM infrastructure will run in the Houston datacenter in active mode.
All applications in-scope for the SSO Track have Production infrastructure located in the Houston data
center, and will be secured by OAM.
1) Multiple Web servers/Webgates/Accessgates are load balanced for high-availability.
2) Two OAM Access Servers are deployed in a clustered mode on Weblogic in each data center.
Webgates are registered with existing configuration in legacy infrastructure. Session
management within the cluster is managed by the Coherence layer in the Weblogic server. If one
access server becomes unavailable for any reason, the Webgates timeout and fall back to the
other access servers in the cluster for high-availability.
3) Two OHS instances will be deployed on each of the 2 Weblogic nodes to host the login page. This
model ensures that the access servers are isolated from the login page load and that the two
OHS instances in each node will ensure high-availability and load balancing for the login page.
4) The database instances at Southwestern Energy (SWN) are deployed on Netapp .
5) Design and implementation of OAM in PROD and QA environments are going to be identical.

5) Physical Deployment Architecture

Following is the list of servers in QA and PROD Environment

Environment QA PROD

6) OAM Solution Architecture

Users once authenticated by OAM, will have SSO across EBS and multiple Federated applications
integrated with OAM.

Page | 7
Confidential and proprietary information. For internal use only.
SSO Implementation

6.1) User Request Data Flow

When a user logs into an OAM protected application, the user will be redirected to an OAM login page for
credentials. After submitting valid credentials, the user will be redirected back to the OAM protected
application.
Below diagram the user request data flow:

END USER

FEDERATED APPLICATIONS
SERVERS

NETSCALAR LOAD BALANCER

http://

From Load
Balancer
Traffic Comes
To OHS Servers

END USER OHS WEB SERVER 1 OHS WEB SERVER 2

ACCESS
EBS PORTAL
DIRECTORY (OID) SERVERS
OHS Sends Requests To
OAM Servers

OAM
CLUSTER

 OAM Goes to Directory Servers (OID)

for User Authentication
 OAM checks Policy in Database

EBS App Stores/Fetch

User Details
From DB & OID

EBS AG Servers

DATABASE SERVER
NETAPP

7.2) Authentication and Authorization

Page | 8
Confidential and proprietary information. For internal use only.
SSO Implementation

A user logging into an OAM protected application may encounter four possible basic events.

 Successful authentication
 Failed authentication
 Successful authorization
 Failed authorization

6.2.1) Authentication sequence for EBS Access Gates:

1) User Accessing SSO login URL of E-Business Suite and EBS redirects the request to EBS
AccessGate URL protected using OAM.
2) Webgate challenges the user to provide credentials and user submits the user credentials.
Webgate passing user credentials to OAM.
3) OAM validates the user credentials with SSO user store. OID returns authentication status and
OAM policy returns value of attributes storing EBS username and orclguid to Webgate.
4) Webgate sets EBS Username and orclguid in header variables USER_NAME, USER_ORCLGUID
respectively.
5) Webgate redirects the request to protected EBS AccessGateURL.
6) EBS AccessGate links local user in FND_USER table in DB and adds subscription for local user to
SSO in OID.
7) AccessGate redirects the authenticated user to E-Business Suite.
8) User session is created in EBS with the details supplied by OAM and user will be able to access
EBS.

7) Glossary

Acronym Description
OAM Oracle Access Manager
Page | 9
Confidential and proprietary information. For internal use only.
SSO Implementation

SSO Single Sign On

EBS E-Business Suite
OID Oracle Internet Directory
DB Database
PEP Policy Enforcement Point
PDP Policy Decision Point
PAP Policy Administration Point
OHS Oracle HTTP Server

Page | 10
Confidential and proprietary information. For internal use only.