eHealth Ontario Enhanced Authentication

Detailed Design Document

E HEALTH Oracle Adaptive Access

Management Implementation
Migration Design Document
Version 1.0

Page | 1
Confidential and proprietary information. For internal use only.
 eHealth Ontario Enhanced Authentication
Detailed Design Document

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.
 eHealth Ontario Enhanced Authentication
Detailed Design Document

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 environment in a load balanced configuration using internal HA.

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

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

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

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
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.

Page | 3
Confidential and proprietary information. For internal use only.
 eHealth Ontario Enhanced Authentication
Detailed Design Document

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

Page | 4
Confidential and proprietary information. For internal use only.
 eHealth Ontario Enhanced Authentication
Detailed Design Document

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 OAAM admin
server,OAAM Server ,OAAM offline Server and the OAAM admin console.

 OAAM Admin Server

This component is used for administration and configuration of OAAM_SERVER application. This
component is developed using the Oracle JAVA ADF Framework the Identity Management shell
and deployed as Web applications in a J2EE container. It is packaged as an EAR file.

 OAAM Server
This component contains the OAAM Admin and OAAM Server sub-components within a single
web application. The OAAM_SERVER component is packaged as an EAR file and is composed of
Servlets and JSPs in addition to Java classes.

 OAAM Offline Server

This component is a standalone application. OAAM Offline has its own database. This database
has an identical schema to that of the OAAM Online version. It is used to load customer data to
perform risk analysis and tune rules. OAAM Offline can support both login and transaction data.

 Database
OAAM stores session information & policies in a database.

 OHS
Oracle HTTP Server is the Web server component for Oracle Fusion Middleware .

 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.
 eHealth Ontario Enhanced Authentication
Detailed Design Document

HIGH LEVEL ARCHITECTURE

OAM Server 1 OAM Server 2

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

ID
UserUSER

– O
Identity
ADMIN Server Details
Store
ODSM Managed Server
OID Instance
3131
NETAPP

etScalarGlobal VIP
OID Server 2

N
USER
ODSM Managed Server Details
OID Instance

Page | 6
Confidential and proprietary information. For internal use only.
 eHealth Ontario Enhanced Authentication
Detailed Design Document

4) Logical Deployment Architecture

The Production OAAM infrastructure will be deployed in the EHealth Ontario environment with high-
availability.
1) Multiple Web servers are load balanced for high-availability.
2) Two OAAM Access Servers are deployed in a clustered mode on Weblogic in Ehealth Ontari
environment . Session management within the cluster is managed by the Coherence layer in the
Weblogic server. If one adaptive access server becomes unavailable for any reason the access will
fallback on the second server.
3) Two OHS instances will be deployed on each of the 2 Weblogic nodes to host the login page. This
model ensures that the 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 OAAM in PROD and DEV environments are going to be identical.

5) Physical Deployment Architecture

Following is the list of servers in QA and PROD Environment

Platform Node Hardware Software

4 Core Processor Oracle Adaptive Access Manager 11gR2 PS3
16 GB RAM Red Hat Enterprise Linux el7.x86_64
150GB Disk Oracle JDK 1.7.0_80 64-Bit
(AdminServer + OAAM Admin RCU 11.1.1.9
OAAM 2
+ OAAM Server+ OAAM
Offline)
  WebLogic Server 10.3.6
Oracle HTTP Server 11.1.1.9

Page | 7
Confidential and proprietary information. For internal use only.
 eHealth Ontario Enhanced Authentication
Detailed Design Document

6) OAAM Solution Architecture

Users once authenticated by OAAM, will authorize access to the designated target applications.

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

Page | 8
Confidential and proprietary information. For internal use only.
 eHealth Ontario Enhanced Authentication
Detailed Design Document

7.2) Authentication and Authorization

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.

Page | 9
Confidential and proprietary information. For internal use only.
 eHealth Ontario Enhanced Authentication
Detailed Design Document

7) Glossary

Acronym Description
OAM Oracle Access Manager
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.