D63114GC10 sg2

Oracle Access Manager 11g: Administration
Volume II Student Guide
D63114GC10 Edition 1.0 December 2010 D71611
Authors
Vishal Parashar David Goldsmith
Copyright 2010, Oracle and/or it affiliates. All rights reserved. Disclaimer This document contains proprietary information and is protected by copyright and other intellectual property laws. You may copy and print this document solely for your own use in an Oracle training course. The document may not be modified or altered in any way. Except where your use constitutes "fair use" under copyright law, you may not use, share, download, upload, copy, print, display, perform, reproduce, publish, license, post, transmit, or distribute this document in whole or in part without the express authorization of Oracle. The information contained in this document is subject to change without notice. If you find any problems in the document, please report them in writing to: Oracle University, 500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not warranted to be error-free. Restricted Rights Notice If this documentation is delivered to the United States Government or anyone using the documentation on behalf of the United States Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS The U.S. Governments rights to use, modify, reproduce, release, perform, display, or disclose these training materials are restricted by the terms of the applicable Oracle license agreement and/or the applicable U.S. Government contract. Trademark Notice Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Technical Contr ibutors and Reviewer s

Amjad Afanah Jeremy Banford Abhijit Bhatode Rama Bollu Vikas Pooven Chathoth Toby Close Jui Deshpande Steve Doinidis Sunil Gupta Beomsuk Kim Ashish Kolli Vadim Lander Derick Leo Mayank Maria Madhu Martin Vamsi Motukuru Rey Ong Vimal Patel Peter Povinec Deepak Ramakrishnan Shankar Raman Chitra Sabapathy Narasimhaiah Sreehari Ramya Subramanya Ramana Turlapati Venkat Venkatnarayan Weifang Xie
Editor s
Smita Kommini Priti Goswami
Gr aphic Designer
Satish Bettegowda
Publisher s
Sujatha Nagendra Giri Venugopal
Contents
Course Overview Course Objectives 1-2 Course Agenda: Day 1 1-4 Course Agenda: Day 2 1-5 Course Agenda: Day 3 1-6 Course Agenda: Day 4 1-7 Course Agenda: Day 5 1-8 Practice Environment: Overview 1-9 Introduction to Oracle Access Manager Objectives 2-2 Oracle Identity Management: Oracle + Sun Combination 2-3 Oracle Access Management Suite Plus 2-6 Salient Features of OAM 2-8 OAM 11g Architecture 2-10 Enterprise Deployment Architecture 2-11 SSO Login Processing with OAM Agents 2-15 Installation and Configuration 2-18 Installation and Configuration Configuration Wizard Screenshot: Templates 2-20 OAM 11g R1 Run-Time Architecture 2-21 Management Interfaces 2-23 Backward Compatibility of Agents in a Heterogeneous Environment 2-25 Coexistence of OAM 10g and 11g Servers 2-26 Coexistence of OSSO 10g and OAM 11g Servers 2-27 Session Management 2-28 Oracle Coherence in Session Management 2-30 Usability and Life Cycle Management Enhancements 2-32 Usability and Life Cycle Management Enhancements: Operational Metrics 2-33 Windows Native Authentication 2-34 Upgrade for OracleAS Single Sign-On 10.1.4.3.0 2-35 Rich ADF-Based UI 2-36 Connection Simulator: Access Tester 11g 2-37 Access Tester 11g 2-38 Key Enhancements in OAM 11g 2-39 Oracle Access Manager 11g Comparison with Oracle Access Manager 10g 2-42
iii
Oracle Access Manager 11g Policy Object Comparison 2-46 Product Component Mapping 2-47 Summary 2-48 Quiz 2-49 Practice 2 Overview: Viewing New Features Viewlet 2-53 3 Installation and Configuration Objectives 3-2 Road Map 3-3 Domain: Overview 3-4 Domain Diagram 3-6 Domain Restrictions 3-8 Server 3-10 Administration Server 3-11 Managed Server 3-13 Interaction Between the Administration Server and Managed Servers 3-14 What Is a Machine? 3-15 Relationship of Machines to Other Components 3-16 Cluster 3-17 Cluster Guidelines 3-19 WebLogic Scripting Tool (WLST) 3-20 WLST Modes 3-21 WLST Example 3-22 Oracle WebLogic Server ILT Courses 3-23 Road Map 3-24 Oracle Fusion Middleware Home and Oracle WebLogic Server Home 3-25 Oracle Home 3-26 Installing and Configuring Oracle Identity Management: Sequence of Steps 3-27 Wizards: Installation Versus Configuration 3-28 System Requirements for Oracle Identity Management 11g R1(11.1.1.3.0) 3-29 Road Map 3-30 Oracle WebLogic Server 11g R1 PS 2 (10.3.3) Installation 3-31 System Requirements for Oracle WebLogic Server 3-33 GUI Mode Installation 3-35 Choosing or Creating a Home Directory 3-36 Registering for Support 3-37 Choosing an Installation Type and Products 3-38 Choosing the JDK and Product Directory 3-39 Windows-Specific Screens 3-40 Installation and Summary 3-41 QuickStart 3-42
iv
Console and Silent Mode Installations 3-43 Post-Installation: Middleware Home 3-44 Oracle WebLogic Server Directory Structure 3-45 Setting Environment Variables 3-47 Practice 3 Overview: Installing Oracle WebLogic Server 10.3.3 3-48 Road Map 3-49 Installing Oracle Database 3-50 Creating Schemas by Using RCU 3-51 Practice 3 Overview: Running the Repository Creation Utility 3-55 Road Map 3-56 Installing Oracle Identity Management: Welcome and Prerequisite Checks 3-57 Installing Oracle Identity Management: Install Location and Summary 3-58 Installing Oracle Identity Management: Progress Bar and Install Complete 3-59 Practice 3 Overview: Installing Oracle Identity Management 11g 3-61 Road Map 3-62 Configuration Wizard: Creating Domain and Domain Source 3-63 Configuration Wizard: Domain and Administrator Settings 3-65 Configuration Wizard: Server Start Mode, JDK, and Customization Options 3-66 Configuring JDBC Data Source: OAM with Database Policy Store 3-68 Configuration Wizard: Administration and Managed Servers 3-69 Configuration Wizard: Clusters and Machines 3-72 Configuration Wizard: Assigning Servers to Machines and Target Deployments 3-75 Configuration Wizard: Target Services and RDBMS Security Store 3-77 Configuration Wizard: Configuration Summary and Creating Domain 3-79 Configuring OHS For Oracle WebLogic Server 3-80 Practice 3 Overview: Creating a New Domain and Configuring OAM Server 3-83 Configuration Wizard: Extending Domain and Domain Source 3-84 Output of Configuration Wizard: Directory Structure 3-92 Road Map 3-94 Starting Oracle Access Manager 3-95 Practice 3 Overview: Starting Administration and Managed Server 3-97 Validating a Successful Installation and Configuration 3-98 Oracle WebLogic Server Administration Console 3-99 Oracle WebLogic Server Administration Console: Server Status 3-100 OAM_Server1: Applications Deployed 3-101 AdminServer: Applications Deployed 3-102 Oracle Access Manager Administration Console 3-103 Oracle Enterprise Manager Fusion Middleware Control 3-105 Relationship Between Farm and Domain 3-107
Practice 3 Overview: Sanity Checks and Walkthrough of Management Interfaces 3-108 Road Map 3-109 Uninstalling Oracle WebLogic Server 3-110 Uninstalling Oracle Identity Management Home 3-111 Uninstalling Oracle Common Home and Deleting Domain Home 3-112 Summary 3-113 Quiz 3-114 4 System Configuration: Servers, Data Sources, and Agents Objectives 4-2 Practice 4 Overview: Installing and Configuring OHS 11g 4-3 Road Map 4-4 Servers 4-5 Creating and Deleting a New Managed Server 4-7 Managing Servers 4-8 Individual Server Properties 4-9 OAM Proxy 4-11 Managing Servers from WLS Admin Console and Command Line 4-12 Road Map 4-13 Agents 4-14 WebGate Provisioning and Installation 4-17 Installing and Configuring WebGate 11g 4-18 Practice 4 Overview: Installing, Creating, and Configuring an OAM 11g WebGate 4-21 Road Map 4-22 Registering Agents 4-23 Creating or Registering OAM Agents by Using OAM Admin Console 4-26 Viewing and Editing OAM Agent Registration by Using OAM Admin Console 4-28 Creating or Registering OSSO Agents by Using OAM Admin Console 4-32 Viewing and Editing OSSO Agent Registration by Using OAM Admin Console 4-33 Configuring OAM 10g WebGate in an Existing OAM 10g Deployment to Use OAM 11g Server 4-35 In-Band Versus Out-of-Band Registration of Agents 4-37 Registration Tool 4-39 Output Files 4-42 Registration Tool 4-43 Request File 4-45 Sample Request File: Short Version 4-47 Key Request Parameters 4-51 Request File: Parameter Guidelines 4-52
vi
Out-of-Band Registration Using oamreg Tool 4-58 Remote Registration: Common Issues 4-62 10g WebGate Installation: General Comments 4-63 Practice 4 Overview: Registering Agents: OAM Admin Console, In-Band, Out-Of-Band Modes 4-64 Road Map 4-65 WLS Agent (or OAM Agent) Topology 4-66 General Features of OAM Agent 4-68 WLS Agent Configuration 4-70 Resources Protected via WLS Agent 4-73 Road Map 4-74 Data Sources 4-75 Data Repositories 4-77 User Identity Store: WLS Embedded LDAP Server 4-78 User Identity Store: Managing LDAP Servers 4-80 Testing LDAP Connection 4-84 Practice 4 Overview: WLS Embedded LDAP, OID as LDAP Store, WLS Agent 4-85 Road Map 4-86 Keystore 4-87 Securing Communication Between WebGate and OAM Server 4-88 Generating Private Key, Certificate Request, and Downloading Certificates from CA 4-90 Configuring OAM Server to Use Certificates 4-91 Configuring WebGate to Use Certificates 4-96 Summary 4-98 Quiz 4-99 Practice 4 Overview: SSL Enabling WebGate and OAM 11g Server 4-104 5 Policy Configuration: Shared Components and Application Domains Objectives 5-2 Road Map 5-3 Shared Components: Resource Types 5-4 Shared Components: Host Identifier 5-5 Road Map 5-8 Access Control 5-9 Authentication 5-11 Authorization 5-12 Road Map 5-13 Authentication Module 5-14 Authentication Module Features 5-17
vii
In-Band Registration Using oamreg Tool 4-54
Step-Up Authentication Feature 5-19 Shared Components: Authentication Schemes 5-20 Multi-Level Authentication 5-25 Road Map 5-27 Policy Object Comparison: OSSO 10g 5-28 Policy Model: Key Differences Between OAM 11g and OSSO 10g 5-29 Policy Model: Key Differences Between OAM 11g and OAM 10g 5-30 Other Policy Features in OAM 11g 5-32 Road Map 5-33 Application Domain: AuthN Policies 5-34 Application Domain: AuthZ Policies 5-36 Resource 5-38 Key URL Patterns 5-40 Authentication Policies 5-42 Authorization Policies 5-44 What Are Responses? 5-46 Responses 5-47 How Are Responses Used? 5-49 Authentication and Authorization Responses 5-50 Response Expressions 5-51 Response Examples 5-52 Response Flows 5-54 Response Providers 5-56 Supported Variable Names Request information 5-58 Supported Variable Names Session information 5-59 Supported Variable Names User information 5-60 Authorization Constraints 5-61 Road Map 5-63 Application Domain 5-64 Conceptual Relationships for Policy Objects 5-65 Summary 5-67 Quiz 5-68 Practice 5 Overview: Protecting Resources by Using Application Domains 5-72 6 Single Sign-On and Session Management Road Map 6-2 Objectives 6-3 Road Map 6-4 Oracle Access Manager Single Sign-On 6-5 Oracle Access Manager Single Sign-On Scenario 6-6 Oracle Access Manager Single Logout Scenario 6-7
viii
Road Map 6-8 Session and Cookie Creation in Authentication 6-9 Session and Cookie Usage After Successful Authentication 6-12 The OAM Session and the OAM_ID Cookie 6-14 Agent Cookies 6-15 Single Sign-On Cookie Reference 6-16 Cookie and Communication Security 6-20 Session and Cookies in Single Logout 6-22 Quiz 6-24 Road Map 6-27 Session Life Cycle 6-28 Session Timeouts 6-30 Road Map 6-31 Session Caching and Persistence 6-32 Road Map 6-34 Configuring Single Sign-On: Overview 6-35 Road Map 6-36 Default Login Page 6-37 Options for Displaying the Single Sign-On Login Page by Using Form-Based Authentication 6-38 Configuring an Authentication Scheme for a Customized Login Page 6-41 Customizing Logout 6-42 Road Map 6-44 Configuring Session Management Options 6-45 Managing Sessions 6-46 Road Map 6-47 Windows Native Authentication 6-48 User Validation Replaces Credential Collection 6-49 Configuring an Oracle Access Manager Deployment for WNA 6-50 Quiz 6-52 Summary 6-53 Practice 6 Overview: Examining Single Sign-On and Managing Sessions 6-54 7 Using Oracle Access Manager With WebLogic Applications Road Map 7-2 Objectives 7-3 Road Map 7-4 Java EE Authentication and Authorization 7-5 Using OAM for Perimeter Authentication and Authorization With a WebGate 7-6 Using OAM for Perimeter Authentication Without a WebGate 7-8 Road Map 7-9
ix
Identity Assertion Providers 7-10 Oracle Access Manager Identity Assertion Provider 7-11 OAM Identity Assertion Provider Event Sequence 7-12 Road Map 7-14 OAM Authenticator 7-15 Quiz 7-16 Summary 7-17 Practice 7 Overview: Using an Identity Assertion Provider 7-18 8 Auditing and Logging Road Map 8-2 Objectives 8-3 Road Map 8-4 Auditing and Logging: Overview 8-5 Road Map 8-9 The Fusion Middleware Audit Framework 8-10 Road Map 8-12 Audit Output Options 8-13 Audit Architecture Using a Database as the Audit Store 8-14 Deploying Auditing by Using a Database as the Audit Store 8-15 Road Map 8-17 Audit Settings 8-18 Road Map 8-20 Examples of Audited Events 8-21 Examples of Data Recorded When an Audited Event Occurs 8-22 Quiz 8-23 Road Map 8-25 Oracle Business Intelligence Publisher 8-26 Deploying BI Publisher to Support FMW Audit Framework and Oracle Access Manager Reports 8-27 Generating Oracle BI Publisher Reports 8-28 Navigating to Common User Activities Reports 8-29 Navigating to Oracle Access Manager Reports 8-30 Oracle BI Publisher Reports for Oracle Access Manager 8-31 Road Map 8-33 Administrator Tasks: Logging 8-34 Logging Configuration Objects 8-35 Log Levels 8-37 Oracle Access Manager Loggers and Log Level Inheritance 8-38 Log Handler Settings 8-39 Logging Configuration Tools 8-41
x
Viewing the Logging Configuration by Using FMW Control 8-42 Modifying Log Level by Using FMW Control 8-43 Creating or Configuring Log Handlers by Using FMW Control 8-44 Using the WLST Tool to Configure Logging 8-45 Road Map 8-50 Locating Log Files 8-51 Viewing and Downloading Log Files by Using FMW Control 8-52 Road Map 8-53 Log Files from Other Servers in an Oracle Access Manager Deployment 8-54 Quiz 8-55 Summary 8-57 Practice 7 Overview: Auditing and Logging 8-58 9 Upgrading Oracle Single Sign-On 10g to Oracle Access Manager 11g Objectives 9-2 Overall Sequence 9-3 Retain Ports Versus Change Ports 9-4 Summary of Upgrade Process 9-5 Upgrade OSSO 10g Associated with Oracle Portal 9-6 Verifying a Successful Upgrade 9-10 Scenarios Not Supported for Upgrade to OAM 11g 9-11 Typical OSSO 10g to OAM 11g Upgrade Topology 9-12 Components Involved in an Upgrade 9-14 Upgrade Flow 9-16 Upgrade Assistant 9-17 Post-Upgrade Validation 9-18 Coexistence of OSSO 10g and OAM 11g 9-20 Key Functionality for Coexistence Model 9-22 Coexistence Scenario I: User Authenticated by OAM 11g 9-23 Coexistence Scenario II: User Authenticated by OSSO 10g 9-25 Typical OSSO Server Production Deployment Topology 9-26 Typical Production Deployment Topology 9-27 Rolling Upgrade: Hybrid Configuration 9-28 Upgrade Process 9-30 Interplay of SSO_ID and OAM_ID cookies 9-31 Summary 9-32 Quiz 9-33 Practice 9 Overview: Performing OSSO 10g to OAM 11g Upgrade 9-36
xi
10 Troubleshooting and Management Objectives 10-2 Road Map 10-4 Access Tester 10-5 Use Cases: Access Tester 10-6 Access Tester Simulating Steps 1, 3, 5, 6 of Agent and OAM Server Interaction 10-8 Access Tester: Core Functionality 10-9 Access Tester Architecture 10-10 Output Files and Security Features 10-12 Starting Access Tester 10-13 System Properties 10-15 Access Tester Console 10-18 Test Cases and Test Scripts 10-20 Road Map 10-24 Using weblogic.Admin Utility to Check the State of Servers 10-25 Examining Admin Server and Managed Server Logs 10-26 WebLogic Admin Server and Managed Server Thread Dump 10-28 Agent and Server Monitoring 10-30 OAM Proxy Errors 10-31 Configuration Data 10-32 Road Map 10-33 Top Problem Areas 10-34 LDAP Server 10-35 OAM Runtime Servers 10-36 Agent Side Issues 10-37 Run-Time DB Issues 10-38 Admin Change Propagation and Activation 10-39 Policy Repository DB Issues 10-40 Road Map 10-41 WLST Architecture 10-42 Offline Mode And Online Mode 10-43 Executing WLST Commands 10-44 Example: Create Identity Store Embedding WLST Command in Python Script 10-45 WLST Commands for OAM 11g 10-46 Road Map 10-49 Oracle Enterprise Manager Fusion Middleware Control 10-50 FMW Control: Performance Overview 10-51 Topology 10-52 MBean Browser 10-53 How to Re-register an Agent from the OAM Admin Console 10-54
xii
Summary 10-55 Quiz 10-57 Practice 10 Overview: Working with Access Tester, WLST, and FMW Control 10-61 11 Horizontal Migration Objectives 11-2 Use Cases: Horizontal Migration 11-3 Perform Horizontal Migration Using WLS Template Builder 11-4 Performing Horizontal Migration by Using WLS Template Builder 11-5 Source and Target Processing 11-6 Policy Migration 11-7 Partner Migration 11-8 Dependencies 11-9 Horizontal Migration Use Cases 11-10 Summary 11-12 Quiz 11-13 Practice 11 Overview: Performing Horizontal Migration 11-15 12 High Availability Road Map 12-2 Objectives 12-3 Road Map 12-4 High Availability (HA) Goals 12-5 Road Map 12-7 Potential Points of Failure in an Oracle Access Manager Deployment 12-8 Load Balancing on the Web Tier 12-10 Clustering the Oracle Access Manager Server on the Application Tier 12-12 WebLogic Server Cluster 12-13 Configuring a WebLogic Cluster of Oracle Access Manager Servers on Multiple Hosts 12-15 Converting a Single OAM Server on a Single Host to a Clustered Configuration 12-17 Handling Administration Server Failure in a Cluster of Oracle Access Manager Servers 12-20 Data Tier 12-22 Other Issues to Be Aware of in HA Deployments 12-23 Road Map 12-24 Session Replication and Configuration Change Distribution 12-25 User Session Continuity in a Single Oracle Access Manager Server Environment 12-28
xiii
User Session Continuity in a Clustered Oracle Access Manager Server Environment 12-29 Road Map 12-30 Backing up an Oracle Fusion Middleware Deployment 12-31 Recovering Your Environment 12-33 HA Topology Review 12-35 Summary 12-36 Quiz 12-37 Practice 12 Overview: Configuring Oracle Access Manager for HA 12-38 A Introduction to Oracle Access Manager Oracle Access Manager 11g Comparison with Oracle Access Manager 10g and OSSO 10g A-2 Credential Collection A-7 Kerberos Operation A-8 Coexistence and Backward Compatibility A-9 Request Flow: Authentication A-11 Request Flow: Authorization A-14 B Installation and Configuration WebLogic JMX: Overview B-2 Navigating JMX MBeans B-4 Node Manager B-6 Node Manager Architecture B-8 C System Configuration: Servers, Data Sources, and Agents Coherence Properties C-2 Common Server Properties C-3 Backward Compatibility C-9 WLS Agent Without a WebGate C-11 D Policy Configuration: Shared Components and Application Domains Custom Resource Types D-2 Custom Authenticator Use Case D-4 Fusion Applications SSO Use Case D-5 Creating Custom Resources D-6 Authentication Parity with OAM 10g D-7 OAM 10g Parity Items Features Not Implemented in 11g R1 D-8 Authentication: Troubleshooting Tips D-9 Success and Failure URL D-10 Returning Session or Cookie or HTTP Header Variable D-11
xiv
Validating Authentication and Authorization in an Application Domain D-13 Authentication Module Features D-14 Shared Components: Authentication Schemes D-15 E Monitoring OAM 11g by Using Oracle Grid Control Objectives E-2 Enterprise Manager Architecture E-3 Oracle Enterprise Manager Grid Control Identity Management Pack E-5 Oracle Identity Management Pack Key Capabilities: Performance Monitoring and Diagnostics E-7 Oracle Identity Management Pack Key Capabilities: Service Level Management E-10 Features in the Upcoming Release of Grid Control Comprehensive Monitoring E-11 Features in the Upcoming Release of Grid Control Integration with FMW Control and WLS Admin Console E-13 Features in the Upcoming Release of Grid Control Improved Performance Monitoring and Diagnostics E-14 Grid Control: Home Page E-15 Identity and Access Targets E-16 Identity and Access System E-18 Generic Service E-19 Discovering Oracle Access Manager E-20 Create Identity and Access System E-21 Create Service E-22 Create a Service Dashboard Report E-24 Adding or Removing Targets from the System Topology E-26 Removing Servers or Components from an Existing Identity Management Topology E-27 Updating Monitoring Configuration E-28 Alerts Based on Performance and Usage Metrics E-29 Metric Baselines E-31 View All Metrics Collected for Oracle Identity Management Target E-33 View All Metrics for Oracle Access Manager E-34 Metric and Policy Settings E-36 Availability E-37 Service-Level Rules E-39 Topology E-41 Service Performance and System Component Status E-42 Performance Summary for Oracle Access Manager E-43 Managing Oracle Access Manager and Running Reports E-44 Alerts and Alert History E-45
xv
Blackouts E-47 User-Defined Metrics E-50 Summary E-52 F Introduction to Access SDK Road Map F-2 Objectives F-3 Road Map F-4 Custom Requirements for Authentication and Authorization Services F-5 Road Map F-7 Access SDK F-8 Road Map F-10 Oracle Access Manager Clients F-11 AccessGate Variations F-12 Road Map F-13 Developing and Deploying AccessGates: Overview F-14 Preparing Systems for AccessGate Development and Deployment F-15 Installing Access SDK F-17 Developing the AccessGate F-19 Example of Access SDK API Usage in an AccessGate F-20 Configuring Oracle Access Manager to Support AccessGates F-22 Road Map F-24 Access SDK Support in Oracle Access Manager 11g F-25 Quiz F-26 Summary F-28
G Single Sign-On and Session Management Intranet Single Sign-On: End-User Experience G-2 Internet Single Sign-On: End-User Experience G-3 Oracle Fusion Middleware 11g R1 Products for Single Sign-On G-5
xvi
Auditing and Logging
Copyright 2010, Oracle and/or its affiliates. All rights reserved.
Road Map
Objectives Auditing and logging Fusion Middleware Audit Framework Audit output options Configuring audit settings Audited events and recorded data Generating audit reports Configuring logging settings Locating and examining logging output Locating log files from other servers
Oracle Access Manager 11g: Administration 8 - 2
Objectives
After completing this lesson, you should be able to: Differentiate between auditing and logging Describe the Fusion Middleware Audit Framework Describe audit output options Configure audit settings Describe audited events and data recorded when an audited event occurs Generate audit reports Configure logging settings Locate and examine logging output Locate log files from other servers in an Oracle Access Manager deployment
Road Map
Auditing and Logging: Overview

Auditing: Helps users attain compliance with regulatory requirements; for example, Sarbanes-Oxley and Health Insurance Portability and Accountability Act (HIPAA) Is normally enabled in production environments Records authentication, authorization, and administrative events Uses the Oracle Fusion Middleware Audit Framework:
Writes to a single, centralized Oracle Database instance or to flat files Integrates with Oracle Business Intelligence Publisher, which provides a predefined set of compliance reports

This section describes the auditing and logging features of Oracle Access Manager server at a high level. Subsequent sections describe auditing and logging in greater detail. Auditing Compliance is a major requirement in the enterprise. With regulations such as SarbanesOxley (financial) and Health Insurance Portability and Accountability Act (health care), many organizations must be able to audit identity information and user access of applications and devices. Events that require auditing might include the following: User authentication and access activities Administrative changes to systems By reviewing recorded audit data, compliance officers can perform periodic reviews of compliance policies. While auditing can be enabled or disabled, it is normally enabled in production environments. Auditing has a minimal performance impact, and the information captured by auditing is useful; sometimes mission-critical.
Auditing and Logging Overview (continued)

Oracle Fusion Middleware Audit Framework Oracle Fusion Middleware Audit Framework is a new service in Oracle Fusion Middleware 11g Release 1, designed to provide a centralized audit framework. The framework provides a common audit service for Oracle Access Manager and other Fusion Middleware component products. With the Oracle Fusion Middleware Audit Framework, you can write all audit data to a single Oracle Database instance, or to flat files. The framework also integrates with Oracle Business Intelligence Publisher, which provides a predefined set of compliance reports.

Logging: Records OAM component messages that are useful when diagnosing problems. Normally configured to log only errors and system notifications in production environments. Writes to flat files only.
Auditing and Logging: Overview (continued)

Logging Oracle Access Manager server logging records messages from various OAM components. You control the amount of logging output by specifying log levels for each OAM component for which a logger is defined. Log messages are used for problem diagnosis, either by users or by Oracle Technical Support. Documentation for log messages is not available. In some cases, users might be able to diagnose problems on their own by reading log files. More typically, you enable logging to produce files that you send to Oracle Technical Support for problem diagnosis. Note: Diagnosing problems by using the information in the log files is not an objective for users of this course. Configuring logging and locating log files are objectives for users of this course. By default, the log level for all OAM server components is the notification level. Logging at the notification level generates log records for system errors and notifications only, therefore producing a relatively small amount of output. However, other log levels result in voluminous logging output; so much output that enabling some log levels can impact OAM server performance.
Auditing and Logging: Overview (continued)

Therefore, in production environments, the log level is set to a level (for example, the notification or error level) that results in a relatively small volume of logging output. The OAM logging system writes output to flat files only. Logging to an Oracle Database instance is not supported.
Road Map
The Fusion Middleware Audit Framework

A common audit framework across the Fusion Middleware product stack that includes the following features: Audit-aware component products Audit policies Configuration through Enterprise Manager and WLST commands Flat file and database audit data stores Audit database initialized by Repository Creation Utility Pre-defined reports in Oracle Business Intelligence Publisher
The Fusion Middleware Audit Framework

Writing audit records to a database provides numerous advantages over writing to flat files, and is the preferred mode of operation for Oracle Access Manager server in production environments. Advantages include the following: Database logging implements a common auditing framework employed across a range of Oracle Fusion Middleware component products. Fusion Middleware products that leverage the common audit framework benefit from the commonality of auditing functionality at the platform level. Other Oracle Fusion Middleware component products that leverage the Fusion Middleware Auditing Framework include (but are not limited to) Oracle Identity Manager, Oracle Web Services Manager, Oracle Internet Directory, Oracle Virtual Directory, and Oracle Directory Integration and Provisioning. Stand-alone applications can be integrated with the Oracle Fusion Middleware Audit Framework.
The Fusion Middleware Audit Framework (continued)

Audit policies are declarations of the types of events to be captured by the audit framework for particular components. For Java components, audit policies are defined at the domain level. For system components, audit policies are managed at the component instance level. Pre-defined policy types include the following: None Low (audits fewer events) Medium (audits many events) Custom (implements filters to narrow the scope of audited events) The Fusion Middleware Audit Framework integrates with Oracle Enterprise Manager Fusion Middleware Control for UI-based configuration and management, thus leveraging the Oracle Fusion Middleware 11g infrastructure. It also supports the WLST tool for command-line configuration. Two output formatsflat files and databaseare provided. Maintaining a common location for all audit records simplifies maintenance. When you use Oracle Database as the audit data store, you run the Repository Creation Utility (RCU) to initialize the predefined Oracle Fusion Middleware Audit Framework schema. Once configured, all the audit loaders are aware of the data store and upload data to it periodically. The audit data in the database is expected to be cumulative and grow over time. Ideally, this should not be an operational database used by any other applications; rather, it should be a stand-alone database used for audit purposes only. The data in the audit store is exposed through predefined reports in Oracle Business Intelligence Publisher (Oracle BI Publisher). By using Oracle BI Publisher reports, you can drill down through the audit data to perform analyses based on selected criteria. For example: Username Time range Application type Execution context identifier (ECID)
Road Map
Audit Output Options
Default OAM Server Auditing Configuration Flat File
OAM Server Auditing to Oracle DB Oracle DB
Audit Output Options

You can write audit records to a flat file or to an Oracle Database instance. Although the formats differ, the content in the flat file and the database is identical. Writing Audit Records to a Flat File The default configuration for audit output is to write audit records to a flat file. Writing Audit Records to a Oracle Database You can configure Oracle Access Manager to write audit records to an Oracle database. Subsequent slides describe the architecture for database logging, and the advantages of using a database for audit logging rather than a flat file. A section later in this module describes how you configure audit logging to a database.
Audit Architecture Using a Database as the Audit Store
Oracle Access Manager Server
Audit Loader
Repository Creation Utility
Oracle BI Publisher
Audit Architecture Using a Database as the Audit Store

The following features comprise the architecture for auditing when using a database as the audit store: An Oracle Database instance is required. For the required version of Oracle Database software, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager. Schema for the audit log tables is provided by the Repository Creation Utility. You must run this utility before you can log to a database. The Oracle Access Manager server writes its audit data to a flat file. An independent process, called the audit loader, reads the flat file and inserts records in the log table in the Oracle database. Pre-defined reports in Oracle Business Intelligence Publisher expose the data in the audit database.
Deploying Auditing by Using a Database as the Audit Store

4
Use FMW Control to enable auditing by using a database Restart WebLogic admin and managed server instances
5
Oracle Access Manager Server
Audit Loader
Run Repository Creation Utility
Create database Oracle BI Publisher
Configure a data source on the admin server and managed server instances
Deploying Auditing by Using a Database as the Audit Store

To deploy auditing when using a database as the audit store, perform the following tasks. Creating the Audit Database Before you can configure Oracle Access Manager to write audit records to a database, you must create the database. Refer to the Oracle Access Manager Certification Matrix on Oracle Technology Network to obtain a list of supported Oracle Database versions for Oracle Access Manager 11g. Running Repository Creation Utility Next, run the Repository Creation Utility (RCU) to insert the auditing schema into the Oracle Database instance. Select the Audit Services check box when running RCU, as shown on the screen shot on the following page.
Deploying Auditing by Using a Database as the Audit Store (continued)
Configuring a Data Source for the Audit Database In this step, you define a JDBC data source for the audit database so that the WebLogic server can access the database. You must configure the data source on the administration server and on all WebLogic managed server instances running Oracle Access Manager server. Refer to the Oracle Fusion Middleware Security Guide 11g Release 1 for specific steps to follow to configure the data source. Enabling Auditing by Using a Database in FMW Control You must define the auditing type as database logging by using FMW Control. To enable auditing in FMW Control, you select the WebLogic Domain > Security > Audit Store option and specify the JNDI name of the data source for the audit database. Restarting WebLogic Server Instances Finally, you must restart all the WebLogic Server instancesthe admin server and all the managed server instancesin the domain. During the restart, the audit loader rereads the audit store configuration and starts using the database for auditing.
Road Map
Audit Settings
Audit Settings
The screen shot shows configurable options for Oracle Access Manager auditing. Options include the following: Maximum Directory Size The maximum size of the directory that contains audit output files. For example, assuming that the maximum file size is 10 MB, a value of 100 for this parameter implies that the directory allows a maximum of 10 files. Once the maximum directory size is reached, auditing stops. The Maximum Directory Size setting applies to auditing by using flat files only. Maximum File Size The maximum size, in MB, of the audit file. Once the size of the audit file reaches the maximum size, a new audit file is created and the previous log file is renamed. The Maximum Directory Size setting applies to auditing by using flat files only. Note: The two users listed by default in the filter settingsthe orcladmin and SSOAdmin userare provided only as examples and can be removed if they are not required.
Audit Settings (continued)

Filter options: Filter Enabled Select this check box to enable event filtering. Filter Preset Controls the amount of audit information recorded. Events for the preset levels are defined in the MIDDLEWARE_HOME/user_projects/ domains/DOMAIN/config/fmwconfigcomponent_events.xml file. You cannot modify the content in this file. When the filter preset is set to the level NONE, no auditing takes place. Audit Users A list of users whose actions are audited irrespective of filter preset. This setting is effective if the filter preset is not set to the level NONE. The filter options apply to auditing using flat files and auditing by using a database.
Road Map
Examples of Audited Events

Type of Audited Event
Authentication
Event
Credentials collected Authentication succeeded Authentication failed
Authorization
Authorization succeeded Authorization failed
Administrative
Authentication scheme created Administration console login failed Server configuration changed
Examples of Audited Events

The slide shows several examples of audited events. For a complete list of audited events, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager.
Examples of Data Recorded When an Audited Event Occurs

Audited Event
Authentication failed
Data Collected
IP address, username, user DN, resource ID, authentication scheme ID, failure error code, retry count, authentication policy ID, partner ID IP address, user DN, resource ID, authorization policy ID Username, IP address, roles
Authorization succeeded Administration console login succeeded
Examples of Data Recorded When an Audited Event Occurs

The slide shows several examples of the different types of data that is recorded when an Oracle Access Manager event is audited. For a complete list of the data collected during event auditing, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager.
Quiz
To deploy auditing by using Oracle Database as the audit store, which two of the following actions must you take? a. Create a separate WebLogic managed server instance that executes the auditing logic b. Configure an identity data source in Oracle Access Manager c. Enable auditing using a database by using FMW Control d. Run the Repository Creation Utility
Answer: c, d
Quiz
Which tool can you use to view predefined audit reports for Oracle Access Manager? a. The WLST tool b. grep c. Oracle BI Publisher d. The Oracle Access Manager console
Answer: c
Road Map
Oracle Business Intelligence Publisher

Supports Fusion Middleware Audit Framework predefined reports Provides flexible report display:
Output type Appearance
Provides report filtering Provides report scheduling Supports custom reporting requirements
Oracle Business Intelligence Publisher

Oracle Business Intelligence is a general-purpose reporting and analysis tool that you can use to answer a range of business questions. For example: How is my business performing? Which factors are influencing my business? Where is my business headed? Where should we focus our efforts? The Fusion Middleware Audit Framework leverages Oracle BI Publisher to analyze audit data recorded to an audit database. A set of predefined Oracle BI Publisher report templates are provided with Oracle Access Manager. By using these report templates, you can run reports to analyze audit data. By using Oracle BI Publisher, you can take advantage of powerful reporting features such as flexible report display, filtering, scheduling, and custom reporting.
Deploying BI Publisher to Support FMW Audit Framework and Oracle Access Manager Reports
1 2
Install Oracle BI Publisher Configure a data source in Oracle BI Publisher (if not already configured)
BI Publisher Installation Directory XMLP/Reports Subdirectory
Copy and unjar AuditReport Templates.jar File
Copy and unzip oam_audit_reports_ 11_1_1_3_0.zip File
Deploying BI Publisher to Support FMW Audit Framework and Oracle Access Manager Reports
To deploy Fusion Middleware Audit Framework reports and reports specific to Oracle Access Manager in Oracle BI Publisher, perform the following steps: 1. Install the Oracle BI Publisher Web application. 2. In the Web container in which you installed Oracle Business Intelligence Publisher, define a data source for the audit database if you have not already done so. 3. Copy the AuditReportTemplates.jar file from the Fusion Middleware software installation directory to the XMLP/Reports subdirectory of the Oracle BI Publisher top-level installation directory. Unjar the AuditReportTemplates.jar file. 4. Copy the oam_audit_reports_11_1_1_3_0.zip file from the middleware_home/idm_home/oam/server/reports directory to the XMLP/Reports subdirectory of the Oracle BI Publisher top-level installation directory. Unzip the oam_audit_reports_11_1_1_3_0.zip file.
Generating Oracle BI Publisher Reports
Report filtering and sorting options
OAM audit data
Generating Oracle BI Publisher Reports

To generate Fusion Middleware Audit Framework reports in Oracle BI Publisher, perform the following steps: 1. Log in to Oracle BI Publisher. The default user ID is Administrator and the default password is Administrator. 2. 3. 4. 5. Select the Reports tab. Click More to expose the list of standard reports, including audit reports. Click Oracle _Fusion_Middleware_Audit, then navigate to the report you want to run. Use filter options in the top part of the report page to filter reported data in various ways. Report data appears on the bottom part of the report page.
Navigating to Common User Activities Reports
Navigation Path Is Shared Folders / Oracle_Fusion_Middleware_Audit
User Activities Report
Navigating to Common User Activities Reports

Perform the following steps to run the Fusion Middleware common user activities reports in Oracle BI Publisher: 1. Start the Oracle BI Publisher console. The consoles default URL is http://host:9704/xmlpserver. 2. Log in to Oracle BI Publisher. The default user ID is Administrator, and the default password is also Administrator. 3. 4. 5. 6. Click More. Click Oracle_Fusion_Middleware_Audit. Click Common_Reports. Select the report that you want to run.
Navigating to Oracle Access Manager Reports

Navigation path Is Shared Folders / Oracle_Fusion_Middleware_Audit / Component_Specific / Oracle_Access_Manager
Navigating to Oracle Access Manager Reports

Perform the following steps to run the Oracle Access Manager reports in Oracle BI Publisher: 1. Start the Oracle BI Publisher console. The consoles default URL is http://host:9704/xmlpserver. 2. Log in to Oracle BI Publisher. The default user ID is Administrator, and the default password is also Administrator. 3. 4. 5. 6. 7. Click More. Click Oracle_Fusion_Middleware_Audit. Click Component_Specific. Click Oracle_Access_Manager. Select the report that you want to run.
Note: The common user activities reports appear both in the Common_Reports folder and in the Oracle_Access_Manager folder. You can run the common user activities reports from either location in the Oracle BI Publisher console.
Oracle BI Publisher Reports for Oracle Access Manager

Fusion Middleware Common User Activity Reports:
Authentication History Multiple Logins from Same IP Authorization History Event Details Dashboard Authentication from IP by User Authentication per IP Authentication Statistics per Server Authentication Statistics
Oracle Access Manager reports:

Oracle BI Publisher Reports for Oracle Access Manager

The BI Publisher reports for Oracle Access Manager are divided into two categories: Reports that are not specific to Oracle Access Manager Reports that are specific to Oracle Access Manager Fusion Middleware Common User Activity Reports The Fusion Middleware Audit Framework includes a set of user activity reports that provide information about events that occurred in both Oracle Access Manager and other Fusion Middleware component products. For example, the Authentication History report includes authentications to Oracle Access Manager, but might include binds to Oracle Internet Directory as well. Oracle Access Manager Specific Reports In addition, reports that are specific to Oracle Access Manager are included in the predefined set of Fusion Middleware Audit Framework reports. These reports provide information solely about audit events recorded by Oracle Access Manager.
Oracle BI Publisher Reports for Oracle Access Manager (continued)

The following reports specific to Oracle Access Manager are available: Authentication From IP by User For each IP address from which users have attempted to authenticate, this report shows the number of distinct users who have attempted to authenticate, the total authentication attempts, and the IDs of users who have attempted to authenticate. Authentication Per IP The Authentication Per IP report is an abbreviated form of the Authentication From IP by User report. For each IP address from which users have attempted to authenticate, this report shows the number of distinct users who have attempted to authenticate and the total authentication attempts. Authentication Statistics Per Server This report shows the authentication success and failure count for each Oracle Access Manager server instance. Authentication Statistics This report provides a list of users who incurred the most successful and failed authentication attempts.
Road Map
Administrator Tasks: Logging

Configure logging as requested by Oracle Support Locate logging output in order to send to Oracle Support for problem diagnosis Reset logging to the default level after obtaining needed log output to minimize performance impact
Administrator Tasks: Logging

Administrators and Oracle Support use Oracle Access Manager server logging to diagnose problems. When the Oracle Access Manager server does not operate as expected, a customer might call Oracle Support to determine the cause of the problem. If the cause of the problem is not easily diagnosed, Oracle Support might ask the customer to generate logs to help Oracle Support analyze the problem and make recommendations for correcting the problem. Therefore, administrators need to know how to configure Oracle Access Manager server logging in order to produce diagnostic output for Oracle Support. They need to know how to locate output log files so that they can send them to Oracle Support upon request. They need to know how to reset the logging configuration back to default levels after requested logs have been produced, so that logging overhead does not adversely affect Oracle Access Manager server performance. Administrators are not expected to interpret logging output. Oracle Access Manager documentation does not describe log file formats or content; nor does this course. While experienced administrators might learn to interpret logging output, being able to do so is not a learning objective of this course.
Logging Configuration Objects

Loggers Log Handler(s)
Authentication engine logging at TRACE:32 level
SSO controller logging at TRACE:32 level
Credential collector logging at TRACE:32 level odl-handler All other OAM components logging at NOTIFICATION:1 level
Logging Configuration Objects

Like all Fusion Middleware 11g component products, Oracle Access Manager implements the Oracle Diagnostic Logging (ODL) framework, an architecture that complements and extends the Java EE logging framework encapsulated in the java.util.logging classes. Two componentsloggers and log handlerswork together in this architecture. Loggers Oracle Access Manager calls component loggers when events require logging. The set of component loggers is predefined in the Oracle Access Manager configuration. Some examples of component loggers are the authentication engine logger, the SSO controller logger, and the credential collector logger. Oracle Access Manager logger names begin with the string oracle.oam. For a complete list of Oracle Access Manager loggers, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager.
Logging Configuration Objects (continued)

Log Handlers Log handlers typically receive messages from loggers and write the messages to files. By default, Oracle Access Manager loggers use the odl-handler log handler. This log handler writes to the DOMAIN_HOME/servers/OAM_SERVER/logs/OAM_SERVERdiagnostic.log file.
Log Levels
INCIDENT_ERROR:1 ERROR:1 WARNING:1 NOTIFICATION:1 (default log level) NOTIFICATION:16 TRACE:1 TRACE:16 TRACE:32
Log Levels
You can change the amount of logging output for loggers by modifying their log levels. The ODL log levels are listed on the slide. The INCIDENT_ERROR:1 level produces the least logging output. The TRACE:32 level produces the most output. The default log level for Oracle Access Manager server loggers is the NOTIFICATION:1 level. While you can control the volume of output produced by logging, you cannot customize individual messages that loggers write when you set a given log level on a logger. The level associated with a log message is predefined in the Oracle Access Manager code. ODL and Java EE Log Levels Oracle Access Manager uses log levels defined in the ODL. The log levels are analogous to log levels defined in the java.util.logging.Level class in the Java EE logging architecture. The Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager provides a table that correlates ODL log levels to Java EE log levels.
Oracle Access Manager Loggers and Log Level Inheritance

Log level explicitly set to NOTIFICATION:1 level oracle logger Log level not explicitly set, inherits log level from oracle logger oracle.oam logger Log level not explicitly set, inherits log level from oracle.oam logger oracle.oam.audit logger
Oracle Access Manager Loggers and Log Level Inheritance

The ODL framework uses an inheritance model to determine loggers' log levels. Logger names can consist of multiple strings delimited by periods. For example, the logger for Oracle Access Manager audit events is the oracle.oam.audit logger. To determining a logger's log level, the logging system first looks to see if a log level is explicitly defined for the logger. In the example, no explicit log level is defined for the oracle.oam.audit logger. If no explicit log level is found for the logger, the logging system strips the right-most string and period from the logger name to construct a new logger name. In the example, the new logger name is oracle.oam. The logging system then checks to see if a log level is explicitly set for this logger. If a log level has been explicitly defined, the original logger inherits this log level. The logging system repeats this action until the logger name has been stripped of all characters, oracle. The Oracle Access Manager logging configuration explicitly defines the NOTIFICATION:1 log level as the oracle logger's log level. Therefore, Oracle Access Manager loggers that do not have explicitly defined log levels default to the NOTIFICATION:1 log level.
Log Handler Settings

Name Maximum log size Log file rotation configuration Log file path Log handler type Loggers that write to the log handler Log level for loggers that write to the log handler
Log Handler Settings

Log handlers receive messages from one or more loggers and typically write the message to files. You can configure a variety of log handler settings. Log Handler Name When you define a new log handler, you specify a unique log handler name. Log Size Two configuration settings determine the log size: The maximum size of any single log file. When this file size is exceeded, the logging system no longer writes to the current log file. Instead, it renames the log file and creates a new log file with the same name as the original log file. The maximum size of the log file and saved log files. Log File Rotation Configuration The logging system can rotate the log files based on a configurable start time, a rotation frequency, and a retention period.
Log Handler Settings (continued)

Log File Path You can specify the path to which the log handler writes. Log Handler Type The Oracle Access Manager server loggers use the oracle.core.ojdl.logging.ODLHandlerFactory handler type. Loggers You can specify loggers that write to the given log handler, or remove loggers from the list of loggers that write to the log handler. Log Level You can specify a log level to be used by all loggers that write to the log handler. If desired, you can override this setting for individual loggers.
Logging Configuration Tools

The Oracle Enterprise Manager Fusion Middleware Control (FMW Control) Web-based management system The WLST tool
Logging Configuration Tools

You use the Oracle Enterprise Manager Fusion Middleware Control (FMW Control) and the WLST tool to configure Oracle Access Manager logging. The Oracle Access Manager console does not provide the ability to configure Oracle Access Manager logging. Oracle FMW Control Oracle Enterprise Manager Fusion Middleware Control is a Web-based management system for administering Oracle Fusion Middleware products. With Fusion Middleware Control, you can manage services in your enterprise, including hosts, databases, listeners, application servers, HTTP Servers, and Web applications as one cohesive unit. You start the FMW Control by navigating to the following URL: http://host:port/em, where host and port are the host name and port number of the WebLogic admin server. The WLST Tool You can use the WLST tool to perform a variety of logging configuration tasks. Specific WLST commands that you use to configure logging are described later in this lesson.
Viewing the Logging Configuration by Using FMW Control
Log levels
Associated log handlers
OAM loggers
Viewing the Logging Configuration by Using FMW Control

View the logging configuration for the domain in which Oracle Access Manager is installed as follows: 1. Start Enterprise Manager Fusion Middleware Control by navigating to the following URL: http://host:port/em. In this example, host and port are the host name and port number of the WebLogic admin server. 2. In the navigator that appears in the left window pane, select Identity and Access > OAM > oam_server. 3. The Oracle Access Manager menu appears in the right window pane below the label, oam_server. Select Logs > Log Configuration from the pull-down menu. 4. The logger structure appears in the right window pane. The oracle logger appears in the list. Other Oracle Access Manager server loggers appear when you expand the list's nodes.
Modifying Log Level by Using FMW Control
2
Locate logger
Select log level
Modifying Log Level by Using FMW Control

FMW Control provides a user interface for modifying log levels. To modify the log level by using FMW Control, perform the following steps: 1. Start FMW Control and view the logging configuration. 2. Select the Log Levels tab. 3. Locate the logger that you want to modify. 4. Select the new log level from the drop-down list to the right of the logger's name. 5. Click Apply.
Creating or Configuring Log Handlers by Using FMW Control

Provide log handler details
3 1
Select Log Files tab
Click Create, Create Like, or Edit Configuration
Creating or Configuring Log Handlers by Using FMW Control

You can use FMW Control to create new log handlers and change the configuration of existing log handlers. To locate the functionality for creating and configuring log handlers, start FMW Control and view the logging configuration. Then select the Log Files tab. Buttons for creating new log handlers and modifying the configuration of existing log handlers appear on the page.
Using the WLST Tool to Configure Logging

Use the following commands to configure logging: The listLoggers command The setLogLevel command The configureLogHandler command The listLogHandlers command For examples, refer to the slide notes.
Using the WLST Tool to Configure Logging

You can use the WLST tool to perform a variety of logging configuration tasks. Two Versions of the WLST Tool Every WebLogic Server installation provides the WLST tool. The WebLogic Server WLST tool is located in the WLS_HOME/common/bin directory. When you install Oracle Access Manager or other Fusion Middleware identity management products, a second version of the WLST tool is installed. This version contains commands unique to Fusion Middleware software, including the commands that you can run to configure logging, if you want to configure logging by using the command line. This version of the WLST tool is located in the ORACLE_HOME/common/bin directory. To verify that you are using the version of the WLST tool that provides the commands unique to Fusion Middleware software, you can run the WLST help("listLoggers") command. If help is available for the listLoggers command, then you are using the version of the WLST tool that you need for configuring Oracle Access Manager logging.
Using the WLST Tool to Configure Logging (continued)

WLST Commands for Configuring Oracle Access Manager Logging Use the following WLST commands to configure logging: The listLoggers command, for viewing loggers and their log levels. The setLogLevel command, for setting the log level for a single logger. The configureLogHandler, for defining log handlers, associating a logger with a log handler, and associating a default log level with a log handler. The listLogHandlers command, for viewing log handlers and their configuration settings. Listing Oracle Access Manager Loggers Use the WLST listLoggers command to list the Oracle Access Manager server loggers. The following example WLST session illustrates the listLoggers command usage and output: ./ORACLE_HOME/common/bin/wlst.sh > connect("weblogic","Welcome1","t3://localhost:7001") > listLoggers(pattern="oracle.oam.*",target="OAMServer") ------------------------------------------+---------------Logger | Level ------------------------------------------+--------------oracle.oam | <Inherited> oracle.oam.admin.foundation.configuration | <Inherited> oracle.oam.agent-default| <Inherited> oracle.oam.audit | <Inherited> oracle.oam.binding | <Inherited> oracle.oam.commonutil | <Inherited> oracle.oam.config | <Inherited> oracle.oam.controller | <Inherited> oracle.oam.default | <Inherited> oracle.oam.diagnostic | <Inherited> oracle.oam.engine.authn | <Inherited> oracle.oam.engine.authz | <Inherited> oracle.oam.engine.policy| <Inherited> . . . In the preceding WLST session: Specifying the pattern="oracle.oam.*" and target="OAMServer" parameters to the listLoggers command lists only the Oracle Access Manager server loggers. In this example, OAMServer is the name of the WebLogic managed server instance that hosts Oracle Access Manager that you provided when you configured Oracle Access Manager configuration. The default Oracle Access Manager server name is oam_server1.

The listLoggers command output shows the loggers that you specified and their log levels. The <inherited> level indicates that the log level is inherited from the parent logger. In this example, the oracle logger is the parent logger. You could run the listLoggers(pattern="oracle",target="OAMServer") command to determine the inherited log level. Note: To run the listLoggers command, use the version of the WLST tool located in the ORACLE_HOME/common/bin directory.
Setting Log Levels Use the WLST setLogLevel command to set the log level for an Oracle Access Manager server logger. The following example WLST session provides an example of the setLogLevel and listLoggers commands' usage and output: > setLogLevel(logger="oracle.oam.engine.authn", target="OAMServer", level="TRACE:32",persist=1) > listLoggers(target="OAMServer",pattern="oracle.oam.engine.authn") ------------------------------------------+----------------Logger | Level ------------------------------------------+----------------oracle.oam.engine.authn | TRACE:32 > setLogLevel(logger="oracle.oam",target="OAMServer", level="TRACE:32",persist=0) > listLoggers(target="OAMServer",pattern="oracle.oam.*") ------------------------------------------+-----------Logger | Level ------------------------------------------+-----------oracle.oam | TRACE:32 oracle.oam.admin.foundation.configuration | <Inherited> oracle.oam.agent-default | <Inherited> oracle.oam.audit | <Inherited> . . . In the preceding example: 1. The first setLogLevel command sets the oracle.oam.engine.authn logger's level to the TRACE:32 level. 2. The first listLoggers command shows the updated log levels. 3. The second setLogLevel command sets the oracle.oam logger's level to the TRACE:32 level. 4. The second listLoggers command shows the updated log levels.

The following comments apply to the preceding WLST session: In this example, OAMServer is the name of the WebLogic managed server instance that hosts Oracle Access Manager that you provided when you configured Oracle Access Manager configuration. The default Oracle Access Manager server name is oam_server1. You can use the persist=1 option to save a new log level in the Oracle Access Manager logging configuration, so that when you restart the WebLogic Server instance that hosts Oracle Access Manager, the new log level remains active. If you use the persist=0 option, the new log level does not remain in effect after a WebLogic Server restart. Run the listLoggers command after you change a logger's log level to verify that you have changed the log level correctly. Note: To run the setLogLevel command, use the version of the WLST tool located in the ORACLE_HOME/common/bin directory. Configuring a New Log Handler You can use a new log handler to isolate logging output for one or more loggers. For example, you might configure a new log handler for the Oracle Access Manager server loggers. Then you could enable a finer log level to write log output required to diagnose a problem. The log output would be written to the path specified in the log handler configuration. Use the WLST configureLogHandler command to configure a new handler, or to modify the configuration of an existing log handler. The following example WLST session illustrates the use of the configureLogHandler command to change the location to which the oracle.oam logger writes logging output: > setLogLevel(logger="oracle.oam", target="OAMServer", level="NOTIFICATION:1",persist=1) > configureLogHandler(name="myLogHandler", target="OAMServer", path="${domain.home}/oamlogs",addHandler="true", addToLogger="oracle.oam", handlerType="oracle.core.ojdl.logging.ODLHandlerFactory") Handler Name: myLogHandler type: ODL path: ${domain.home}/oamlogs > listLogHandlers(target="OAMServer",name="myLogHandler") Handler Name: myLogHandler type: ODL path: D:\Middleware_home\user_projects\domains\idm_domain\oamlogs

In the preceding WLST session: The configureLogHandler command works only with persistent loggers. By default, the oracle.oam logger is not a persistent logger. Therefore, in the example, the setLogLevel command changes the oracle.oam logger to a persistent logger. Specifying the path="${domain.home}/oamlogs" parameter to the configureLogHandler command causes the log handler to write to the diagnostic.log file in the oamlogs subdirectory of the Oracle Access Manager domain's home directory. Specifying the addHandler=true parameter creates a new log handler. You can use the removeHandler=true parameter to remove an existing log handler. Specifying the addToLogger parameter with a list of one or more logger names causes the log handler to be added to each logger in the list. Specifying the oracle.core.ojdl.logging.HandlerFactory class with the handlerType parameter uses the ODL framework for logging. With the listLogHandlers command, you can verify that you have configured the log handler correctly. Note: To run the configureLogHandler command, use the version of the WLST tool located in the ORACLE_HOME/common/bin directory. Other Log Handler Configuration Parameters Use the level parameter to specify the level for loggers that write to the log handler. Use the encoding parameter to specify file encoding for the log file associated with the log handler. Use the rotationFrequency, baseRotationTime, and retentionPeriod parameters to configure log file rotation. Use the maxFileSize and maxLogSize parameters to control the size of the current and retained log files.
Road Map
Locating Log Files

The default Oracle Access Manager server log file location is the DOMAIN_HOME/servers/OAM_SERVER/logs/ OAM_SERVER-diagnostic.log file. If you modify the log handler configuration, you must determine the location of the log file or log files from the log handler configuration.
Locating Log Files

You need to know how to locate log files when Oracle Support requires you to send log files to assist you with problem diagnosis. By default, the Oracle Access Manager log file is the DOMAIN_HOME/servers/OAM_SERVER/logs/OAM_SERVER-diagnostic.log file. This file contains the logging system output if you have not made any changes to the log handler definitions in the logging configuration. If you have made changes to log handler definitions in the logging configuration, you need to review the configuration to determine the location of Oracle Access Manager server log files. You can configure multiple log handlers with multiple paths. Therefore, your logging system output might be distributed across multiple files.
Viewing and Downloading Log Files by Using FMW Control
Download
Viewing and Downloading Log Files by Using FMW Control

You can view Oracle Access Manager server logs by using FMW Control as follows: Start Enterprise Manager Fusion Middleware Control by navigating to the following URL: http://host:port/em. In this example, host and port are the host name and port number of the WebLogic admin server. In the navigator that appears in the left window pane, select Identity and Access > OAM > oam_server. The Oracle Access Manager menu appears in the right window pane below the label, oam_server. Select Logs > View Log Messages from the pull-down menu. Click Target Log Files. A list of log files appears. Select the log file that you want to examine and click View Log File. Click Download if you want to download the log file.
Road Map
Log Files from Other Servers in an Oracle Access Manager Deployment

Software
Oracle WebLogic Server Oracle HTTP Server
Log File Location

DOMAIN_HOME/servers/SERVER/logs OHS_HOME/instances/INSTANCE/diagnostics/ logs/OHS/INSTANCE_ID/access_log OHS_HOME/instances/INSTANCE/diagnostics/ logs/OHS/INSTANCE_ID/INSTANCE_ID.log OHS_HOME/instances/INSTANCE/diagnostics/ logs/OHS/INSTANCE_ID/oblog.log OID_HOME/diagnostics/logs INSTANCE/logs ORACLE_BASE/admin/ORACLE_SID
WebGate running on Oracle HTTP Server Oracle Internet Directory Oracle Directory Server Enterprise Edition Oracle Database
Log Files from Other Servers in an Oracle Access Manager Deployment

Oracle Access Manager does not run independently. It is always deployed together with other software, including the following: WebLogic Server WebGates Web servers Directory servers Oracle Database The table in the slide provides the log file locations of software commonly deployed together with Oracle Access Manager.
Quiz
Which of the following are properties of loggers? a. Log level b. Output path c. Handler type d. All of the above
Answer: a
Quiz
Which of the following are properties of log handlers? a. Log level b. Output path c. Handler type d. All of the above
Answer: d
Summary
In this lesson, you should have learned how to: Differentiate between auditing and logging Describe the Fusion Middleware Audit Framework Describe auditing output options Configure auditing settings Describe audited events and data recorded when an audited event occurs Generate audit reports Configure logging settings Locate and examine logging output Locate log files from other servers in an Oracle Access Manager deployment
Practice 8 Overview: Auditing and Logging

This practice covers the following topics: Changing the auditing configuration to use Oracle Database as the audit data store Installing Oracle BI Publisher Configuring Oracle BI Publisher for Oracle Access Manager reports Running Oracle Access Manager Reports in Oracle BI Publisher Examining the default logging configuration and logging output Modifying the log level Resetting the log level to the default level
Upgrading Oracle Single Sign-On 10g to Oracle Access Manager 11g
Objectives
After completing this lesson, you should be able to: Describe the OAM upgrade overview Perform Upgrade Step 1: Configuring a User Store Perform Upgrade Step 2: Creating a Policy Domain Perform Upgrade Step 3: Migrating Partners Understand the Retain and Change Port options Upgrade OSSO 10g associated with Oracle Portal Verify successful upgrades Explain the scenarios not upgraded to OAM 11g
Overall Sequence
Configuring a User Store OSSO 10g has OID configured as the user store. This OID is now configured as the user store for OAM 11g. Configuring a Policy Domain A new application domain called migratedSSOPartners is created for all the partner applications that are migrated from OSSO 10g to OAM 11g. Migrating Partners Partner applications registered with OSSO 10g are migrated to OAM 11g.
OAM 11g
1. Configure User Store
OSSO 10g Shared Information
OAM 11g Admin Server
2. Create Application Domain 3. Migrate Partners
OID
Retain Ports Versus Change Ports

When the OAM 11g managed server is installed on the same host and same port as the OSSO 10g server, the upgrade is performed in the retain port mode. Depending on whether the Retain Port or the Non-Retain mode is used, a configuration file (osso.conf) is created for each of the partner applications.
Retain Ports: No changes are required on partner applications, but downtime is required for the server. Change Ports: No downtime is required for the server, but partner applications need a new osso.conf, which is generated by the Upgrade Assistant.
Retain Ports Versus Change Ports

Downtime requirements for the transfer and post-transfer tasks are partly based on the following: If the original OSSO 10g server host and port are retained, no manual tasks for the agent are needed post-transfer. In this case, the upgrade utility transfers the partner applications from the OSSO 10g server's database into OAM 11g. The mod_osso agents should automatically start working again because the same address and port was used and the change of the back-end server is transparent. If the original OSSO 10g host and port are replaced with a new host and port, an administrator must manually register the agent to communicate with and redirect requests for authentication to the Oracle Access Manager 11g run-time server.
Summary of Upgrade Process

1. Load OAM schema in the supporting database by using RCU. 2. Install WLS. 3. Install and configure OAM 11g. 4. Start the WLS admin and managed servers. 5. Run the Upgrade Assistant (UA) to upgrade Oracle Single Sign-On 10g to OAM 11g. 6. Perform post-upgrade tasks. 7. Verify the upgraded environment.
Summary of Upgrade Process

Steps 1 through 4 have already been covered in Lesson 3, Installation and Configuration. In this lesson, you learn how to perform Steps 5, 6, and 7. Note: You can upgrade an existing OracleAS SSO 10g Release 2 (10.1.2.3) through OracleAS SSO 10g Release 2 (10.1.4.3) to Oracle Access Manager 11g. Oracle uses the term "upgrade" when referring to moves between Oracle product versions and technologies. For instance, a move from OC4J to Oracle WebLogic Server is an upgrade; moving from OracleAS 10g SSO to OAM 11g SSO is an upgrade. Oracle uses the term "migration" for moves from a non-Oracle technology stack to an Oracle technology stack; for example, a move from MS SQL Server to Oracle Database, or a move from IBM WebSphere to Oracle Fusion Middleware.
Upgrade OSSO 10g Associated with Oracle Portal

Oracle Portal does not use the configuration file to direct authentication requests. Instead, Oracle Portal has the details of the SSO server in the portal schema. When OSSO 10g associated with Oracle Portal is upgraded in the Change Ports option, the portal schema also needs to be updated with the new OAM server details.
A post-upgrade SQL script is provided for this.
When OSSO 10g is upgraded to OAM 11g in the Retain Port mode, all the other applications deployed on the Oracle HTTP server (OHS) that hosts OSSO 10glike the Oracle Internet Directory Delegated Administration Services (OIDDAS)need to be deployed on another OHS.
Upgrade OSSO 10g Associated with Oracle Portal

Proposed topology for upgrading OSSO server to OAM 11g with the Retain Port option: A typical 10g IDM installation has an OHS 10g server hosting OSSO server and OIDDAS among other applications. The topology deals with making sure that the links to other applications like OIDDAS are not broken, by making use of the OHS module called mod_proxy. Note: The topology changes need to be made before the upgrade. 1. Shut down OHS 10g and restart the server on a new port (this will be a front-ending OIDDAS URL). Following are the steps to change the port of OHS 10g: 1. Edit the httpd.conf at $ORACLE_HOME/Apache/Apache/httpd.conf. Look for the existing port in this file and change the port. 2. Stop the OHS server by running ./opmnctl stopall at $ORACLE_HOME/opmn/bin. 3. Start the OHS server by running ./opmnctl startall at $ORACLE_HOME/opmn/bin.
Upgrade OSSO 10g Associated with Oracle Portal (continued)

2. Install OHS 11g by using the OHS 10g original port. 3. Install the OAM server and front-end the OAM server managed server with OHS 11g. Use mod_wl_ohs to front-end the OAM server with OHS 11g. Following are the steps to front-end OAM with OHS 11g: 1. Edit mod_wl_ohs.conf at $OHS_INSTANCE_HOME/config/OHS/<ohs_instance_name>/mod_wl_ohs.conf . 2. Edit the file as follows: <IfModule weblogic_module> WebLogicHost <OAM Managed Server Host> WebLogicPort <OAM Managed Server Port> Debug ON WLLogFile /tmp/weblogic.log MatchExpression *.jsp </IfModule> <Location /> SetHandler weblogic-handler PathTrim / ErrorPage </Location> 3. Restart OHS 11g by running the following commands: $OHS_INSTANCE_HOME/bin/opmnctl stopall $OHS_INSTANCE_HOME/bin/opmnctl startall 4. Edit oam-config.xml to change the "OAMSERVER" entry to point to the OHS 11g host and port, since OHS 11g is now front-ending the OAM server. Following are the steps to change the "OAMSERVER" entry: Find the following entry in oam-config,xml at $OAM_MW_HOME/user_projects/domains/<domain_name>/config/fmwconfig/oam -config.xml and edit as the serverhost and serverport <Setting Name="OAMSERVER" Type="htf:map"> <Setting Name="serverhost" Type="xsd:string"><OHS 11G HOST></Setting> <Setting Name="serverprotocol" Type="xsd:string">http</Setting> <Setting Name="serverport" Type="xsd:string"><OHS 11G PORT></Setting> <Setting Name="MaxRetryLimit" Type="xsd:integer">5</Setting> </Setting> 5. Restart the OAM admin server and managed server. Oracle Access Manager 11g: Administration 9 - 7 http:/WEBLOGIC_HOME:WEBLOGIC_PORT/

6. Register the OHS 10g on which OIDDAS, among other applications, is deployed as a partner with the OAM server and copy the osso.conf created to the OHS 10g server. Restart OHS 10g. This registration is required because the port of OHS 10g has been modified now. OAM's remote registration utility needs to be used to register the OHS 10g as a partner with OAM. Following are the steps to register the OHS 10g with OAM: Log in to the OAM console and switch to the System Configuration tab. Create an OSSO agent (Agent Name: ohs_name, Agent Base URL: http://ohs_host:ohs_port). Once the agent is created, the osso.conf is generated at $DOMAIN_HOME/output/$AGENT_NAME/. Copy this agent to the OHS at $OHS_CONF/osso. 4. Use the mod_proxy to redirect the OIDDAS request to the OHS 10g server. Make the following entries in the httpd.conf of the OHS 11g server. Following are the steps to make the entries: 1. Go to httpd.conf at $OHS_INSTANCE_HOME/config/OHS/<ohs_instance_name>/httpd.conf 2. Edit this file and make the following entries _ProxyPass /oiddas http://pdcasqa143.us.oracle.com:7777/oiddas/ _ProxyPassReverse /oiddas http://pdcasqa143.us.oracle.com:7777/oiddas/ 3. Restart OHS 11g by running the following commands: $OHS_INSTANCE_HOME/bin/opmnctl stopall $OHS_INSTANCE_HOME/bin/opmnctl startall Note: There are two approaches that can be followed to configure Oracle Portal with an OAM server. In both these approaches, upgrade tool needs to be run to upgrade the OSSO server associated with Oracle Portal to the OAM server. Approach 1 (recommended): 1. Run the upgrade tool at $MIDDLEWARE_HOME/bin/ua. 2. Follow the post-upgrade steps listed when the upgrade tool completes. 3. Follow the specific post-upgrade steps for Oracle Portal listed as follows. Once the Oracle Portal's OSSO server is upgraded to the OAM server, an additional configuration step is required to update the portal schema with the OAM server details. The table wwsec_enabler_config_info$ needs to be updated. a. Connect to the DB that hosts the portal schema and log in with the portal schema username and password. Run the following command to get the portal schema password: ldapsearch -v -D "cn=orcladmin" -w "orcladminpassword" -h OIDHost -p OIDPort -s sub -b "cn=IAS Infrastructure Databases, cn=IAS, cn=Products, cn=OracleContext" "orclresourcename=PORTAL" orclpasswordattribute b. Run portal_post_upgrade.sql at $ORACLE_MIDDLEWARE_HOME/oam/server/upgrade/sql after upgrade. When prompted, enter the OAM managed server host and port. Oracle Access Manager 11g: Administration 9 - 8

Approach 2: 1. Run ssocfg from $INFRA_ORACLE_HOME/sso/bin to update the SSO server details to point to OAM server ./ssocfg.sh http <OAM host> <OAM port> 2. Run ptlconfig from $MIDTIER_ORACLE_HOME/portal/conf to update the LS_LOGIN_URL in WWSEC_ENABLER_CONFIG_INFO$ to point to the OAM server 3. Once this command is run, reset the SSO server details to point to the original SSO server ./ssocfg.sh http <OSSO host> <OSSO port> 4. Run the OAM upgrade tool and follow post upgrade steps listed when the upgrade tool completes.
Verifying a Successful Upgrade

To verify a successful upgrade, in the non-retain port mode, copy the generated configuration file (osso.conf) to the OHS that hosts the partner application. Restart the OHS. Verify that the authentication requests are now directed to the OAM 11g server.
Scenarios Not Supported for Upgrade to OAM 11g

OSSO 10g with WNA integration External applications Password store (Pstore)
Typical OSSO 10g to OAM 11g Upgrade Topology

Supported OSSO 10g versions for upgrade 10.1.2.x 10.1.4.x
Typical OSSO 10g to OAM 11g Upgrade Topology

Note: You can directly upgrade from OSSO 10.1.2.x to OAM 11g (11.1.1.3.0) or OSSO 10.1.4.x to OAM 11g (11.1.1.3.0). In the diagram on the slide, note that mod_osso continues to function as the OSSO agent after the upgrade. Also, note that the OSSO server (running within the OC4J container) is now replaced with an OAM 11g server running within the WLS managed server. In other words, the OAM 11g server is backward-compatible with the OSSO agent mod_osso. The backward compatibility of mod_osso to continue to operate after the upgrade with the OAM 11g server is provided by the OAM proxy server. During the upgrade process, partner applications and associated Oracle HTTP server agents are registered with Oracle Access Manager 11g along with corresponding host identifiers. OAM 11g is added to the front-end load balancer of the existing OSSO 10g servers. After the upgrade, OAM 11g coexists with either a single OSSO server or cluster of OSSO servers, and existing partner applications (including Portal, Forms, and Reports) start using Oracle Access Manager 11g as the SSO provider. The load balancer routes some of the authentication requests to the OAM server while the rest continue to be served by the
Typical OSSO 10g to OAM 11g Upgrade Topology (continued)

existing OSSO 10g servers. Once the user is authenticated by either the OSSO 10g or OAM 11g server, the user can access any of the partner applications without having to reauthenticate. In a typical OSSO 10g topology, you have mod_osso (the sole partner to the OSSO server) talking to the OSSO server that runs within the OC4J container named OC4J_Security. There are two possible post-upgrade topologies: a. Topology with mod_wl on the proxy server: The Oracle HTTP server front-ending the OSSO 10g server points to the Oracle WebLogic server where Oracle Access Manager 11g is installed. mod_osso redirects requests to the 11g OAM server for authentication through a proxy. The proxy (mod_wl) replaces mod_oc4j. mod_wl enables single sign-on to work without any changes on the Oracle HTTP server side. In this post-upgrade view, Oracle Access Manager 11g is used for authentication. b. Topology without the proxy server: In this topology, the proxy server that once included mod_oc4j has been eliminated entirely. The Oracle HTTP server containing mod_osso points directly to the Oracle WebLogic Server where Oracle Access Manager 11g is installed.
Components Involved in an Upgrade

OSSO 10g agent (mod_osso) policy.properties file Oracle Internet Directory for OSSO 10g Oracle Access Manager 11g shared services infrastructure
Components Involved in an Upgrade

mod_osso: mod_osso is an Oracle HTTP Server module that provides authentication and single signon services to applications running against Oracle Application Server 10g. mod_osso resides on the Oracle HTTP Server that enables applications protected by OracleAS Single Sign-On to accept HTTP headers in lieu of a username and password once the user has logged in to the OracleAS Single Sign-On server. The values for these headers are stored in a mod_osso cookie. mod_osso simplifies the authentication process by serving as the sole partner application to the Oracle Single Sign-On server. After the upgrade, mod_osso acts as an OSSO agent which communicates with the Oracle Access Manager 11g server instead of the OSSO 10g server. After upgrading, OracleAS 10g SSO provides authentication by using OAM 11g authentication policies with the reprovisioned mod_osso agents. However, only OAM agents (WebGates and AccessGates) use OAM 11g authorization policies. mod_osso-protected applications cannot use the authorization policies specified in OAM 11g.
Components Involved in an Upgrade (continued)

policy.properties file: The policy.properties file is a configuration file for OracleAS Single Sign-On. This file contains basic parameters required by the single sign-on server. The policy.properties file is located on the computer hosting the OracleAS Single Sign-On server in the following path: <ORACLE_HOME>/sso/conf/policy.properties Oracle Internet Directory for OSSO 10g: Oracle Internet Directory is the repository for all 10g single sign-on user accounts and passwords: administrative and non-administrative. The single sign-on server authenticates users against their entries in the directory. At the same time, it retrieves user attributes from the directory that enable applications to validate users. During the upgrade from OSSO 10g to Oracle Access Manager 11g, information about Oracle Internet Directory is needed to enter when running the Upgrade Assistant. After the upgrade, information about the OID appears under the identity store in the OAM admin console. Oracle Access Manager 11g Shared Services Infrastructure: This consists of the token processing engine and session management engine used by Oracle Access Manager 11g single sign-on engine. In addition, the OSSO proxy acts as the legacy OSSO server to provide support for the legacy SSO implementation.
Upgrade Flow
Upgrade from back to front: Server followed by agent
OSSO Agent Side
OSSO 10g / OAM 11g Server Side
Migration tool input validation
Migrate OSSO partners to OAM
Old ports retained by server? No Manually update the new obfuscated file
Yes Yes
Old ports retained? No Generate obfuscated file for all partners
Migrate GITO configuration
Migrate policy.prope rties Manual configuration by administrator if any
Upgrade Assistant
Launch Upgade Assistant <MW_HOME>/<ORACLE_HOME>/bin /ua.bat
Upgrade Assistant
Enter the following command to launch Upgrade Assistant. On Windows systems (located at MW_HOME\Oracle_IDM1\bin): ua.bat
Post-Upgrade Validation
Post-Upgrade Validation
1. Stop the Oracle HTTP Server on the computer that is hosting the 10g OSSO server. 2. Restart the 11g OAM server. 3. In the Oracle Access Manager 11g administration console: System Configuration, Agents: Confirm that the upgraded 10g partner applications have appropriate agent configurations. While the 10g application ID is not recorded in the agent configuration for OAM 11g, most configuration details are included and remain the same: - Site Token: The application token. - Login URL - Single Sign-off URL - Success URL - Failure URL - Start Date These details were derived from the Oracle Internet Directory 10g associated with OSSO 10g during automated upgrade processing.
Post-Upgrade Validation (continued)

Policy Configuration, Shared Components: Confirm that a new host identifier definition was created: migratedssopartners. Policy Configuration, Application Domain: - Confirm that a new application domain was created: migratedssopartners. Within the new application domain, confirm that resources exist for migratedssopartners. Within the new application domain, confirm that an authentication policy exists with the appropriate host identifier: protected resource policy. The OAM 11g authentication scheme SSOCoexistMigrateScheme is used. Confirm that there are no authorization policies (because it is a mod_osso agent).
4. Access the partner application and confirm that authentication occurs through Oracle Access Manager 11g (check the login form for 11g).
Coexistence of OSSO 10g and OAM 11g

OSSO 10g topology before upgrading
Topology after upgrading
Coexistence of OSSO 10g and OAM 11g

OSSO 10g Topology Before Upgrading A typical OSSO setup has a number of OSSO servers with a front-end load balancer. All OSSO servers in the cluster have the same back-end user identity store. The load balancer routes authentication requests to any of the OSSO servers in this cluster. Coexistence After Upgrading Migration to OAM 11g starts by installing a new OAM 11g server and transferring the partner applications to this OAM server. One of the existing OSSO servers is brought down. The OAM 11g server replaces the downed OSSO server and the load balancer starts routing authentication requests to the newly added OAM 11g server (and continues routing authentication requests to remaining OSSO 10g servers). Note: Over time, each of the OSSO 10g servers should be replaced by an OAM 11g server; this is sometimes referred to as rolling upgrade. Once the user is authenticated by either OSSO 10g or OAM 11g, the user can access all the partner applications protected by either server. OAM 11g and OSSO 10g set appropriate cookies to achieve single sign-on.
Coexistence of OSSO 10g and OAM 11g (continued)

OAM 11g creates a session for each request and sets a cookie that contains this session ID. The session represented by this cookie has the JAAS subject of the authenticated user, among other details. In case of OSSO 10g, the server sets a host cookie that contains information about the logged-in user. To provide single sign-on for the user to access any of the partner applications, OAM 11g accepts the user authenticated by the OSSO server as an authenticated user. Also, when OAM 11g validates a user, the server sets appropriate cookies that the OSSO server can understand. The OSSO server does not validate the user again. Note: After you upgrade OSSO 10g to OAM 11g server, the data source migratedUserIdentityStorebecomes the primary data source (this is the existing OSSO 10g user store). It is possible that the OAM 11g data source is not that instance of the data source, or maybe not even the same data source type. In this case you have two choices: a. Consolidate the data source as a post-migration step b. Create a new data source for OVD and set that as the primary with the OSSO 10g and OAM 11g data sources behind it
Key Functionality for Coexistence Model

The Upgrade Assistant migrates all the partner applications registered with OSSO from OSSO 10g to OAM 11g. The Upgrade Assistant migrates the keystore from OSSO 10g to OAM 11g. The SSO engine of OAM 11g supports two modes to authenticate a user:
The user has not been authenticated by the OSSO server The user has been authenticated by the OSSO server
With the OAM 11g server operating in coexistence mode, a user session is valid only if both the OSSO and OAM cookies are set.
Key Functionality for Upgrade and Coexistence Model

The Upgrade Assistant migrates all the partner information from OSSO 10g to OAM 11g. Along with this, the Upgrade Assistant migrates the keystore as well. This is because the OSSO server key is now required by OAM 11g to decrypt the cookies set by the OSSO server. The SSO engine for OAM 11g has two modes to authenticate the user. The first mode is where the user has not been authenticated by the OSSO server. In this mode, the user is shown the credential collection page. The credentials are evaluated and authentication is completed. The OAM server also sets an OSSO cookie along with the OAM cookie. The second mode is the assertion mode. Here, the user is already authenticated by the OSSO server. Here, the SSO engine of the OAM server decrypts the cookie set by the OSSO server by using the server key of the OSSO server. After successfully validating the OSSO cookie, the OAM server creates a session for the request and also sets an OAM cookie with this request ID. The SSO engine for the OAM 11g server knows if it is operating in stand-alone mode or in coexistence mode. If the OAM server is operating in coexistence mode, then the user session is valid only if both the OSSO and OAM cookies are set.
Coexistence Scenario I: User Authenticated by OAM 11g

Single sign-on and off across partner applications registered with OSSO 10g and OAM 11g servers
Graphics team: Change OSSO 11g to OSSO 10g
Coexistence Scenario I: User Authenticated by OAM 11g

Suppose a user accesses a partner application that has been migrated from OSSO 10g to OAM 11g. Assume that the load balancer routes the users authentication request to OAM 11g. The OAM 11g server shows the login page and collects user credentials. Once the user is validated, the server sets the SSO cookie for OAM 11g. The server also updates the session information accordingly. Then the user tries to access an application. Assume that the load balancer routes the authentication request to OSSO 10g. This scenario is described in the picture on the slide. The OAM 11g server shows the login page to collect user credentials and, once the user credentials are validated, sets the cookie in the users browser. Now, to achieve single signon, the OAM 11g server also sets a cookie that OSSO 10g can decrypt and understand. The OAM 11g cookie has a flag to indicate that an OSSO cookie must also exist for this cookie to be valid. Once this is done, when the user accesses an application protected by OSSO 10g, since an OSSO 10g cookie is already set in the browser, the user is not challenged for credentials again and can directly access the application.
Coexistence Scenario I: User Authenticated by OAM 11g (continued)

When the user logs out of a partner application that is protected by OAM 11g, the user is also logged out of both the OAM 11g and OSSO 10g servers. To achieve this, the logout process deletes the OAM 11g cookies and OSSO 10g cookies. Both the OAM 11g and OSSO 10g cookies are kept in sync. Any session information that is updated in the OSSO 10g cookie is synchronized with the OAM 11g cookie and vice-versa.
Coexistence Scenario II: User Authenticated by OSSO 10g
Coexistence Scenario II: User Authenticated by OSSO 10g

Suppose a user accesses the partner application and the users authentication request is routed to OSSO 10g by the load balancer. The OSSO server shows the login page and, after collecting and validating user credentials, an OSSO cookie is set in the users browser. When the user accesses the partner application protected by the OAM 11g server, the OAM server checks if a valid OSSO cookie already exists before showing the login page. If a valid OSSO cookie already exists, the OAM 11g server creates an OAM 11g SSO cookie from the OSSO cookie. The OAM 11g cookie has a flag to indicate that an OSSO cookie must also exist for this cookie to be valid. Hence, the user is allowed to access the partner application without authenticating again. When the user logs out of a partner application that is protected by OSSO 10g, only the OSSO cookie is deleted. After the OSSO cookie has been deleted, if the user tries to access an application protected by OAM 11g, the OAM server checks for the OAM cookie. If this OAM cookie has a flag that indicates that there must be an OSSO cookie as well for the OAM cookie to be valid, the OAM cookie is also deleted and the user is shown the login page. The OAM 11g server ensures that the session information in both the OSSO and OAM cookies are in sync. Oracle Access Manager 11g: Administration 9 - 25
Typical OSSO Server Production Deployment Topology

Topology
A cluster of 10g SSO servers Front-ended by a load balancer (LBR)
Flow
A user accesses a protected resource. The agent intercepts it and redirects to the LBR. The LBR routes the request to one of the SSO servers in the cluster. The SSO server authenticates and sets an SSO_ID cookie containing the session state.
Typical OSSO Server Production Deployment Topology

Typically in an enterprise, single sign-on is not provided by a single SSO sever but by a number of servers behind a load balancer. When the SSO server needs to be upgraded from OSSO 10g to OAM 11g, all the partners registered with the OSSO server need to be migrated. This implies that every OSSO 10g server in the cluster needs to be replaced by an OAM 11g server. Therefore, while upgrading OSSO 10g to OAM 11g, both the servers have to coexist till the rolling upgrade process is complete.
Typical Production Deployment Topology

SSO_ID Cookie
User accesses protected resource
Load Balancer
10g SSO Server
10g SSO Server
10g SSO Server
10g SSO Server
Typical Production Deployment Topology

The load balancer can route the authentication request to any of the SSO servers. Once a user is authenticated by any one of the servers, the user must be able to access any of the partner applications without logging in again.
Rolling Upgrade: Hybrid Configuration

Customers prefer a phased migration approach (rolling upgrade), where only one OSSO 10g instance is migrated to OAM 11g at a time. A cluster has both OSSO 10g servers and OAM 11g servers (till all the servers are upgraded; that is, the rolling upgrade completes). Potential problem:
The SSO 10g server sets an SSO_ID cookie. The OAM 11g server sets an OAM_ID cookie. They do not understand each others cookies; they dont honor sessions created by each other. Single sign-on does not work across OSSO 10g and OAM 11g.
Solution:
OAM 11g should be able to read the OSSO 10g cookie. OAM 11g should be able to create and update the OSSO 10g cookie.
Rolling Upgrade: Hybrid Configuration

If coexistence implementation was not supported, a user authenticated by the OAM 11g server is not recognized by the OSSO 10g server and vice-versa. That is, since the OSSO 10g server uses a cookie called SSO_ID to manage session details, and OAM 11g uses another cookie called OAM_ID to manage its session details; without coexistence, the SSO 10g server only understands the SSO_ID cookie and the OAM 11g only understands the OAM_ID cookie. In order to provide coexistence of both servers, the OAM 11g server not only needs to understand (and trust) the 10g SSO_ID cookie, but also needs to be able to create an SSO_ID cookie. This would ensure coexistence of OSSO 10g servers and OAM 11g servers in a cluster. Now, in the coexistence mode, OAM servers also generate and update or understand 10g SSO_ID cookies so that, no matter which server (OSSO 10g or OAM 11g) within the cluster the user's authentication request is routed to, the user session is intact.
Rolling Upgrade: Hybrid Configuration (Coexistence Topology)

SSO_ID Cookie OAM_ID Cookie
Load Balancer
10g SSO Server
10g SSO Server
10g SSO Server
11g OAM Server
Upgrade Process
You upgrade an OSSO 10g server to an OAM 11g server by invoking the Upgrade Assistant, which:
Migrates partner information Migrates data stores Migrates keys
Coexistence mode is turned on by default after an upgrade. Post-upgrade, the OAM 11g server is set to read, create, and update an SSO_ID cookie. Once all the OSSO 10g servers are upgraded, you turn coexistence mode off by using a WLST command:
disableCoexistMode()
Interplay of SSO_ID and OAM_ID cookies

The OAM 11g server, at any point in time, looks for an SSO_ID cookie as the source of truth.
If an SSO_ID cookie is present and valid:

It implies that a session exists. If an OAM_ID cookie is present:
Sync the session information in the OAM_ID cookie with that from the SSO_ID cookie Create a new OAM_ID cookie
If an OAM_ID cookie is not present:
If an SSO_ID Cookie is not present:

It implies that a session does not exist. The user needs to be authenticated. Both SSO_ID and OAM_ID cookies need to be created.
Summary
In this lesson, you should have learned how to: Describe the OAM upgrade overview Perform Upgrade Step 1: Configuring a User Store Perform Upgrade Step 2: Creating a Policy Domain Perform Upgrade Step 3: Migrating Partners Understand the Retain and Change Port options Upgrade OSSO 10g associated with Oracle Portal Verify successful upgrades Explain the scenarios not upgraded to OAM 11g
Quiz
In OAM 11g R1, upgrade is referred to as: a. Move from OSSO 10g to OAM 11g b. Move from OAM 10g to OAM 11g c. Move from OSSO 10g to OAM 10g to OAM 11g d. Move from non-Oracle environment to OAM 11g
Answer: a
Quiz
Coexistence of OSSO 10g and OAM 11g works because: a. OSSO 10g can read, create, and update an OAM_ID cookie b. OAM 11g can read, create, and update an SSO_ID cookie c. Both of the above
Answer: b
Quiz
When performing the upgrade by using the Retain Ports option a. Manually update the osso.conf file b. No changes are required on partner applications but downtime is required for the server c. No downtime is required for the server
Answer: b
Practice 9 Overview: Performing OSSO 10g to OAM 11g Upgrade

This practice covers the following topics: Practice 9-1: Verify the OSSO 10g server and configure a new OHS instance Practice 9-2: Configure OSSO 10g to work with the load balancer Practice 9-3: Register partner OHS with OSSO 10g Practice 9-4: Restart an OHS partner instance and verify SSO to the partner application Practice 9-5: Run the Upgrade Assistant Practice 9-6: Post-upgrade user store configuration Practice 9-7: View the migrated content in the OAM admin console Practice 9-8: Coexistence verification Practice 9-9: Replace mod_osso with an OAM 11g WebGate agent
Troubleshooting and Management
Objectives
After completing this lesson, you should be able to: Work with Access Tester Identify connectivity issues
Between agents and servers (impact of load balancers and firewalls)
Explain OAM-specific WLST commands Work with Oracle Enterprise Manager Fusion Middleware Control
Objectives
After completing this lesson, you should be able to: Describe the diagnostic capabilities within OAM 11g
OAM Access Tester
Explain EM FMW Control integration

Server processes and charts Topology viewer Farm and domain OAM server management MBean browser
Road Map
Working with Access Tester WLS troubleshooting tips and agent and server monitoring Top problem areas Working with WLST Monitoring by using EM FMW Control
Access Tester
Simulates interactions between registered OAM agents and OAM 11g servers
You can verify agent connection and test policy definitions. An administrator emulates the end user and the Access Tester emulates agents.
Is a stand-alone Java application that ships with Oracle Access Manager 11g Can be run from any computer Has both a GUI (manual testing) and command-line interface (automated testing)
Access Tester
The Access Tester can simulate interactions between registered OAM agents and OAM 11g servers to help troubleshoot issues involving agent connections and to test application policy definitions. IT professionals can use the Access Tester to verify connectivity and troubleshoot problems with the physical deployment. Application administrators can use the Access Tester to perform a quick validation of policies. The Access Tester can be used from any computer, either within or outside the WebLogic administration domain. Command-line mode for running the Access Tester enables complete automation of test script execution in single- or multi-client mode environments. During testing, the Access Tester emulates the agent and communicates with the OAM server, while the administrator emulates the end user.
Use Cases: Access Tester

Use Cases:
Simulate interaction between OAM agents and the OAM server Handle the response from the OAM server in the same manner as a real agent Review the results of intended policy changes Troubleshoot issues with agent connections or access policy definitions Track the latency of authentication and authorization requests Stress-test the OAM server Establish performance metrics
Use Cases: Access Tester

The Access Tester: Enables you to configure a request to be sent to the OAM server that emulates what a real agent would send to the OAM server in a real environment Sends your request to the OAM server and receives a response that is the same as the response that would be received by a real agent Processes and displays the server response Allows you to proceed in the manner in which a real agent would handle the response Helps review performance characteristics of intended policy changes Tracks the latency of authentication and authorization requests Stress-tests the OAM server to establish performance low- and high-water marks relative to desired user loads, and to size back-end hardware Helps establish performance metrics and measuring on an ongoing basis to prove desired outcomes
Use Cases: Access Tester (continued)

The Access Tester offers advanced functionality that enables you to group a number of individual requests into a test script that can be sent to the OAM server for processing. The output of such a test run can be captured by the Access Tester and used to compare against a similar document containing "known good" responses. In this way, the Access Tester can be used for automated testing of policy configuration against errant changes.
Access Tester Simulating Steps 1, 3, 5, 6 of Agent and OAM Server Interaction

User WebGate (agent) 2 4
1. 2. 3. Agent connects to OAM server - Connect User accesses application resource Agent makes IsProtected (Validate) request 3 1 OAM server returns Yes/No and type of credentials required 5 6 For protected resources, agent prompts user for credentials User or user agent submits credentials Agent makes IsAuthenticated request OAM server validates user credentials and returns Y/N and additional responses For authenticated users, agent makes IsAuthorized request OAM server evaluates policies and returns Y/N and additional responses Oracle Access Agent grants or denies access to application Manager Server
Application
4.
User Store
5.
6.
Policy Store
7.
Access Tester: Core Functionality

Testing Connect to policy servers Validate resource protection Authenticate users Authorize users Automation and Analysis Collect test cases Generate test scripts Run test scripts Evaluate results and analyze differences Usability GUI (manual) and command-line (automated) testing modes Scalable testing framework via separation of test cases from physical servers Auto-import of resources to test XML persistence
Access Tester: Core Functionality

The Access Tester is a portable, stand-alone Java application that ships with Oracle Access Manager 11g. The Access Tester can be used to verify connectivity and troubleshoot problems with the physical deployment and to perform a quick validation of policies. The Access Tester can be used from any computer, either within or outside the WebLogic Server domain. Both a graphical user interface and a command-line interface are provided. Note: The Access Tester does not currently support OAM servers and agents configured for Cert mode transport security.
Access Tester Architecture
Access Tester Architecture

Access Tester Modes and Administrator Interactions: In Console mode, the Access Tester provides a single window for interactions with the user. All Access Tester operations are available in the main window, which performs as a central dashboard where users can submit specific details for the test case and view responses. Alternatively, you can use the Access Tester in command line mode and develop test scripts, which you can run interactively or in batches for computerized execution to maximize productivity and minimize costs and resources. Run-Time: The Access Tester requires nap-api.jar in the same directory as the main JAR, oamtest.jar. Starting the application requires oamtest.jar. Regardless of the mode you choose for running the Access Tester, your primary interactions with the Access Tester include: Issuing Requests and Reviewing Results: You use the Access Tester to issue requests to the OAM server to validate resource protection, policy configuration, user authentication, and user authorization. You can immediately analyze test case results and also retain the data for longer-term analysis, if needed.
Access Tester Architecture (continued)

Managing Test Scripts: You can build test scripts by capturing the data generated by test execution, which is available as stand-alone documents. You can run the test script for manual or automated analysis. The Access Tester provides for some automated analysis after each test run, while collecting a full set of statistics to enable analysis after the fact. Managing OAM Server Connectivity: You can manage application settings that include server connection information.
Output Files and Security Features

The following XML files are produced when you run the Access Tester :
config.xml script.xml oamtest_target.xml oamtest_stats.xml oamtest_log.xml
Security:
Supports Open and Simple modes Encrypts passwords
Output Files and Security Features

Configuration Script: config.xml is the output file generated by using the Save Configuration command within the Access Tester. The name of this document is used within the input script to provide proper connection information to the Access Tester running in command line mode. Input Script: script.xml represents a script that is generated by the Access Tester after capturing one or more test cases. Target Output Script: oamtest_target.xml is generated by running the Access Tester in command line mode and specifying the input script. For example: Dscript.scriptfile="script.xml" -jar oamtest.jar Statistics: oamtest_stats.xml is generated together with the output script. Execution Log: oamtest_log.log is generated together with the output script. The Access Tester does not currently support OAM servers and agents configured for Cert mode transport security. The Access Tester encrypts all password-type values that it saves to configuration files and test cases. All network connectivity inherits the NetPoint Access Protocol or Oracle Access Protocol (NAP/OAP) limit of a single connection pool (one primary or secondary connection pool). Oracle Access Manager 11g: Administration 10 - 12
Starting Access Tester

Ensure that the computer from which the tester will be run includes JDK/JRE 6
Java version
Copy the Access Tester JAR files:

IDM_HOME/oam/server/tester/oamtest.jar IDM_HOME/oam/server/tester/nap-api.jar
Ensure that the nap-api.jar is present in the same directory as oamtest.jar on any computer from which you want to run the Access Tester. Start in Console mode:
java Dlog.traceconnfile=d:\conn.txt -jar oamtest.jar
Start in command line mode:

java -Dscript.scriptfile=d:\tests\script.xml" Dcontrol.ignorecontent="true" -jar oamtest.jar
Starting Access Tester

The Access Tester consists of two JAR files that can be used from any computer, either within or outside the WebLogic Server domain. Installing the Access Tester involves copying the Access Tester JAR files to a computer from which you want to run tests. The Access Tester must be started from a command line regardless of the mode you choose for test input: Console mode or command line mode. The Access Tester supports a number of configuration options that are used for presentation or during certain aspects of testing. These options are specified at startup by using the Java -D mechanism. To run a test script, or to customize Access Tester operations, you must start the tester in command line mode and include system properties by using the Java -D option. When running in command line mode, the Access Tester returns completion codes that can be used by shell scripts to manage test runs. When you run the Access Tester in Console mode, you do not need to act upon codes that might be returned by the Access Tester.
Start Access Tester (continued)

Shell scripts that wrap the Access Tester to execute specific test cases must be able to recognize and act upon exit codes communicated by the Access Tester. In command line mode, the Access Tester exits by using System.Exit (N), where N can be one of the following codes: 0 indicates successful completion of all test cases with no mismatches. This also includes a situation where no test cases are defined in the input script. 3 indicates successful completion of all test cases with at least one mismatch. 1 indicates that an error prevented the Access Tester from running or completing test cases. This includes conditions such as No input script specified, Unable to read the input script, Unable to establish server connection, and Unable to generate the target script. These exit codes can be picked up by shell scripts ($? In Bourne shell) designed to drive the Access Tester to execute specific test cases.
System Properties
Property log.traceconnfile display.fontname display.fontsize display.usesystem script.scriptfile control.configfile control.testname control.testnumber control.ignorecontent control.loopback Mode Console and Command Line Console Console Console Command Line Command Line Command Line Command Line Command Line Command Line
System Properties
The Access Tester supports a number of configuration options that are used for presentation or during certain aspects of testing. These options are specified at startup by using the Java -D mechanism log.traceconnfile Console and command line modes Logs connection details to the specified file name. -Dlog.traceconnfile="<file-name> display.fontname Console mode Starts the Access Tester with the specified font. This could be useful in compensating for differences in display resolution. -Ddisplay.fontname ="<font-name> display.fontsize
System Properties (continued)

Console mode Starts the Access Tester with the specified font size. This could be useful in compensating for differences in display resolution. -Ddisplay.fontsize ="<font-size> display.usesystem Console mode Starts the Access Tester with the default font name and size (Dialog font, size 10). -Ddisplay.usesystem script.scriptfile Command line mode Runs the script <file-name> in command line mode. -Dscript.scriptfile="<file-name> control.configfile Command line mode Overwrites the script's "configfile" attribute containing the absolute path to the configuration XML file with the connection information. The Access Tester uses the configuration file to establish a connection to the OAM server indicated by the connection element. -Dcontrol.config="<file-name> control.testname Command line mode Overwrites the script's "testname" attribute of the Control element containing a string representing a name of the test series to be used in naming output script, stats, and log files. Output log files begin with <testname>_<testnumber>. -Dcontrol.testname="<String> control.testnumber Command line mode Specifies the control number to be used in naming output script, stats, and log files. Output log files begin with <testname>_<testnumber>. -Dcontrol.testnumber="<String>". Although the auto generated string is a seven-digit number based on current local time (two character minutes + two character seconds + three character hundredths), any string can be used to denote the control number as long as it can be used in a file name. control.ignorecontent Command line mode Overwrites the script's "ignorecontent" attribute of the Control element, indicating that the Access Tester should ignore differences in content between the original test case and current results.
System Properties (continued)

-Dcontrol.testname="true|false control.loopback Command line mode Runs the Access Tester in loopback mode to test the Access Tester for internal regressions against a known good script. Used for unit-testing the Access Tester. -Dcontrol.loopback="true"
Access Tester Console
Access Tester Console

Access Tester Console Panels: Server Connection: Provides fields for the information required to establish a connection to the OAM server (a single primary server and a single secondary server), and the Connect button. You enter required information for the OAM server and the agent that you are emulating in the Access Tester Connection panel and then click the Connect button. The tester initiates the connection, and displays the status in the Status Messages panel. Once the connection is established, it is used for all further operations. Once the connection is established, it cannot be changed until you restart the Access Tester console. In the Status Messages panel, verify a Yes response. If the connection still cannot be made, start the Access Tester console by using the Trace Connection command mode and look for additional details in the connection log. Save Good Connection Details. From the Test menu, click the Generate a Script command and enter a name for this configuration file (or use the default name, config.xml). Protected Resource URI: Provides information about a resource whose protected status needs to be validated. The Validate button is used to submit the Validate Resource server
Access Tester Console (continued)

request. Before a user can access a resource, the agent must first validate that the resource is protected. By using the Access Tester, you can act as the agent to have the OAM server validate whether or not the given URI is protected, and communicate the response to the Access Tester. User Identity: Provides information about a user whose credentials need to be authenticated. The Authenticate button is used to submit the Authenticate User server request. Before a user can access a resource, the agent must validate the user's identity based on the defined authentication policy on the OAM server. By using the Access Tester, you can act as the agent to have the OAM server authenticate a specific user ID for the protected resource. All relevant authentication responses are considered during this policy evaluation. Before a user can access a resource, the agent must validate the user's permissions based on defined policies on the OAM server. By using the Access Tester, you can act as the agent to have the OAM server validate whether or not the authenticated user identity can be authorized to access the resource. All relevant authorization constraints and responses are considered during this policy evaluation. Status Messages: Provides a scrollable status message area containing messages displayed by the application in response to user gestures. The Authorize button is used to submit the Authorize User server request. Command Buttons in Access Tester Panels: Connect: Submits connection information and initiates connecting Validate: Submits information provided in the Protected Resource URI panel and initiates validation of protection Authenticate: Submits information provided in the User Identity panel and initiates authentication confirmation Authorize: Submits information provided in the User Identity panel and initiates authorization confirmation
Test Cases and Test Scripts
Test Cases and Test Scripts

A test case is created from the request sent to, and response data received from, the OAM server by using the Access Tester. Among other data elements, a test case includes request latency and other identifying information that enables analysis and comparison of old and new test cases. Once captured, the test case can be replayed without new input, and then new results can be compared with old results. If the old results are marked as "known good," then deviations from those results constitute failed test cases. Creating and managing a test case: From the Access Tester console, you can connect to the OAM server and manually conduct individual tests. You can save the request to the capture queue after a request is sent and a response is received from the OAM server. You can continue capturing additional test cases before generating a test script and clearing the capture queue. If you exit the Access Tester before saving the capture queue, you are asked if the test cases should be saved to a script before exiting. Oracle recommends that you do not clear the queue until all your test cases have been captured.
Test Cases and Test Scripts (continued)

Once you have the test script, you can run it from either the Access Tester console or from the command line. To capture one or more test cases Initiate a request from the Access Tester console. After receiving the response, click the Capture last "..." request command button on the toolbar (or choose it from the Test menu). Confirm the capture in the Status Messages panel and note the capture queue test case count at the bottom of the console. Generating an Input Test Script: A test script is a collection of individual test cases that were captured by using the Access Tester console. When individual test cases are grouped together, it becomes possible to automate test coverage to validate policy configuration for a specific application or site. You can create a test script to be used as input to the Access Tester and drive automated processing of multiple test cases. The Generate Script option enables you to create an XML file test script and clear the capture queue. If you exit the Access Tester before saving the capture queue, you are asked if the test cases should be saved to a script before exiting. Note: Do not clear the capture queue until you have captured all the test cases you want to include in the script. To record a test script containing captured test cases: Perform and capture each request that you want in the script. Click the Generate Script command button on the toolbar (or choose it from the Test menu to include all captured test cases). In the New dialog box, select or enter the name of your new XML script file and then click Save. Test Script Execution: You can interactively execute tests scripts from within the Access Tester console, or use automated test runs performed by command scripts. Automated test runs can be scheduled by the operating system or a harness such as Apache JMeter, and executed without manual intervention. Process Overview: Access Tester Behavior When Running a Test Script 1. The Access Tester loads the input XML file. In command line mode, the Access Tester opens the configuration XML file defined within the input test script's Control element. 2. The Access Tester connects to the primary and secondary OAM proxy by using information in the Server Connection panel of the console. In command line mode, the Access Tester uses information in the Connection element of the configuration XML file. 3. In command line mode, the Access Tester checks the Control elements in the input script XML file to ensure none have been overwritten on the command line (command line values take precedence).

4. For each original test case defined in the script, the Access Tester: a. Creates a new target test case b. Sends the original request to the OAM server and collects the response c. Makes the following comparisons: Compares the new response to the original response Compares response codes and marks as mismatched any new target test case where response codes differ from the original test case. For instance, if the original Validate returned "Yes," and now returns "No," a mismatch is marked. When response codes are identical, and the ignorecontent control parameter is "false," the Access Tester compares Content (the name of the authentication scheme or post-authorization actions that are logged after each request). If Content sections differ, the new target test case is marked "mismatched." d. Collects new elapsed time and stores it in the target use case e. Builds a new target test case containing the full state of the last server request and the same unique ID (UUID) as the original test case f. Updates the internal statistics table with statistics for the target test case (request type, elapsed time, mismatched, and so on). 5. After completing all the input test cases, the Access Tester: a. Displays summary results b. Obtains and combines the testname and testnumber, and generates a name for the "results bundle" (three files whose names start with <testname>_<testnumber>. Note: Shell scripts can automate generating the bundle by providing testname and testnumber command-line parameters. Obtain testname from the command-line parameter. If not specified in the command line, use the testname element of the input script's Control block. Obtain testnumber from the command-line parameter. If not specified, testnumber defaults to a seven-character numeric string based on the current local time: two character minutes, two character seconds, three character hundredths. c. Generates the "results bundle": three files whose names start with <testname>_<testnumber>: The target XML script contains the new test cases: <testname>_<testnumber>_results.xml. The statistics XML file contains a summary and detailed statistics of the entire test run, plus those test cases marked as "mismatched": <testname>_<testnumber>_stats.xml The execution log file contains information from the Status Message panel: <testname>_<testnumber>_log.log. d. In command line mode, the Access Tester exits with the exit code.
To run a test script: Confirm the location of the saved test script before exiting the Access Tester.

Submit the test script for processing by using one of the following methods: From the Access Tester console, click the Run Script command button on the toolbar (or select Run Script from the Test menu), then follow the prompts and observe the messages in the Status Message panel as the script executes. From the command line, specify your test script with the desired system properties java -Dscript.scriptfile="\tests\script.xml" Dcontrol.ignorecontent="true" -jar oamtest.jar Evaluating Test Results At the end of a test run a "results bundle" gets generated containing three documents: Target script: An XML document containing new test cases Execution log: A text file containing the messages displayed during script execution Execution statistics: An XML document containing test metrics and a list of mismatched elements
Road Map
Using weblogic.Admin Utility to Check the State of Servers

weblogic.Admin utility is a command-line interface that you can use to administrate, configure, and monitor WebLogic Server.
Run setWLSEnv.bat java weblogic.Admin -url t3://localhost:7001 -username weblogic password <Password> GET pretty -type ServerRuntime
java weblogic.Admin -url t3://localhost:7001 username weblogic password <Password> GETSTATE java weblogic.Admin -url t3://localhost:7001 username weblogic password <Password> GETSTATE oam_server1
Using weblogic.Admin Utility to Check the State of Servers

In Linux, run the ". ./setWLSEnv.sh" or set the classpath manually.
Examining Admin Server and Managed Server Logs

Default location for the WebLogic Server log files:
DOMAIN_NAME\servers\SERVER_NAME\logs\SERVER_N AME.log
Domain log resides in:

DOMAIN_NAME\servers\ADMIN_SERVER_NAME\logs\DO MAIN_NAME.log
HTTP subsystem keeps a log of all HTTP transactions in:

DOMAIN_NAME\servers\SERVER_NAME\logs\SERVER_N AME.out
Node manager writes its startup and status messages to:

NM_HOME\nodemanager.log
WebLogic auditing provider saves auditing information to:

WL_HOME\DOMAIN_NAME\servers\SERVER_NAME\logs\ DefaultAuditRecorder.log
Examining Admin Server and Managed Server Logs

The default location for the WebLogic Server log file is DOMAIN_NAME\servers\SERVER_NAME\logs\SERVER_NAME.log, where DOMAIN_NAME is the name of the directory in which you located the domain and SERVER_NAME is the name of the server. You can also monitor the domain log file. Each server instance forwards a subset of its messages to a domain-wide log file. (By default, servers forward only messages of severity level NOTICE or higher.) The domain log resides in DOMAIN_NAME\servers\ADMIN_SERVER_NAME\logs\DOMAIN_NAME.log, where DOMAIN_NAME is the name of the directory in which you located the domain and ADMIN_SERVER_NAME is the name of the administration server.
Examining AdminServer and Managed Server logs (continued)

The HTTP subsystem keeps a log of all HTTP transactions in a text file located in the same directory as the server log. If you use the node manager to start a managed server, messages are written to a single log file for that server instance, located at DOMAIN_NAME\servers\SERVER_NAME\logs\SERVER_NAME.out. The node manager writes its startup and status messages to a single log file, NM_HOME\nodemanager.log, where NM_HOME designates the node manager installation directory, by default, WL_HOME\common\nodemanager. The WebLogic auditing provider saves all its auditing information in WL_HOME\DOMAIN_NAME\servers\SERVER_NAME\logs\DefaultAuditRec order.log. This is done per server, not per security realm. Configuring an auditing provider is optional; it is not configured by default. The JVM, in which a WebLogic Server instance runs, sends messages to standard error and standard out. Through a configuration option, you can redirect the JVM output to all the registered log destinations, like the server terminal console and log file. When enabled, a log entry appears as a message of NOTICE severity. Redirecting the JVM output does not capture output from native code, for example thread dumps from the JVM.
WebLogic Admin Server and Managed Server Thread Dump

Thread dumps are JVM reports that can be used to analyze admin and managed servers, as well as JVM hang situations, and determine the root cause of the issue. To take a thread dump:
Admin console > Server > <Server_Name> > Monitoring > Threads > Dump Thread Stack
connect(weblogic,'weblogic,'t3://localhost:7001 ) cd (Servers) ls() cd (AdminServer) ls() threadDump()
WebLogic AdminServer and Managed Server Thread Dump

Thread dumps are one of the very important JVM reports that can be used to analyze admin and managed servers as well as JVM hang situations, and determine the root cause of the issue. It is recommended to collect at least three to four thread dumps taken 10 to 15 seconds apart. The simplest option to take a thread dump is: Log in to the admin console > Server > Your admin or managed server (for example, oam_server1 ) > Monitoring > Threads > Dump Thread Stack Thread dumps WLST can also be obtained by using a WLST command. By writing a small script as shown below, it is possible to see the thread dumps on the same shell prompt without the need to look into the server STDOUT Step1: Connect (weblogic,'weblogic,'t3://localhost:7001) cd (Servers)
WebLogic AdminServer and Managed Server Thread Dump (continued)

ls() cd (AdminServer) ls() threadDump() Step2: Open a command shell and then run setWLSEnv.sh Step3: Then run the WLST script like: java weblogic.WLST AdminThreadDump.py
Agent and Server Monitoring
OAM Proxy Errors

Uses Apache log4j for logging Writes logging information into a log file mentioned in log4j.properties
The logger name used by OAM proxy components is oracle.oam.proxy.oam
OAM Proxy Errors

OAM proxy uses Apache log4j for logging, and writes logging information into a log file mentioned in a log4j.xml or properties file. Since the client needs to complete the handshake with the OAM proxy before it can send service requests, WebGate logs can be used to check the details about the failed request. Similarly, 11g server logs can be used for request tracing. HTTP trace can be used to check if the request was redirected correctly to /obrareq.cgi, /obrar.cgi. The logger name used by OAM proxy components is oracle.oam.proxy.oam.
Configuration Data
Stored in an XML file: oam-config.xml
<Default Domain Directory>/config/fmwconfig
Only OAM admin console or WLST commands to be used for changes; do not edit this file manually
Configuration Data
Oracle Access Manager auditing configuration is also recorded in an oam-config.xml file. An audit record contains a sequence of items that can be configured to meet particular requirements.
Road Map
Top Problem Areas

LDAP server and identity store OAM run-time servers and hosts Agent side configuration and load Run-time database issues (audit and session data) Admin change propagation and activation Policy repository database issues
LDAP Server
Operational slowness: Non-OAM load impacting OAM operations Capacity problems due to gradual increase in peak load Consequences:
Poor user experience Agent timeouts leading to retries
LDAP server availability Outage of all LDAP servers Load balancer timing out old connections Consequence:
Total loss of service
LDAP Server
Test: Set up an OAM server and confirm that authentication and authorization work. Shut down the OID server. Restart your browser. Try to access a protected site: Observe errors in the managed server log file. Try to access the OAM admin console: Observer errors in the admin server log file. Bring up the LDAP server again. Retry access to the protected application. Retry access to the admin console.
OAM Runtime Servers

Capacity problems CPU cycles Memory issues Consequence:
Poor user experience due to slow operations Agent timeouts and retry may result in extra load
Interference with other services on host CPU cycle contention Memory contention File system full Consequence:
Same as above
OAM Runtime Servers

Test: Shut down the OAM run-time server. Try to access a WebGate- or mod_osso-protected resource. Bring up the OAM run-time server. Bring up the Access Tester to test authentication and authorization. Use top to figure out the CPU and memory consumption of the OAM server as you use the Access Tester. Get a thread dump of the OAM server.
Agent Side Issues

Difference in clock time between agent and server Agent thinks the token issued by the server is invalid. Agent keeps going back to the server to re-issue the token. Consequence:
High CPU usage at both agent and server User experiences a hang
Agent Side Issues

Test: Set up 10g WebGate on a different host. Change system time of agent to be two days ahead of the server. Access the protected resource and observe: Client access hangs High CPU usage on agent and server
Run-Time DB Issues
Write versus Read tuning DB not tuned for write-intensive operations DB unavailable due to maintenance Space issues in DB Consequence: Audit operations and session operations are slow File system on server can get full with audit data yet to be written out Loss of in-memory session data when one of the servers in the cluster fails
Runtime DB Issues
Test: Set up the system to have a WebGate-protected resource. Enable auditing to the DB. Shut down the DB used to store audit and session data. Try to access a protected resource. Observe the error or warning messages in the managed server log files.
Admin Change Propagation and Activation

Admin changes not getting propagated to managed servers due to:
Servers being too busy handling run-time requests (CPU contention) Coherence network slowness
Consequence:
Changes to policy do not take immediate effect. Changes to system configuration do not take immediate effect.
Admin Change Propagation and Activation

Test: Protect a resource by using mod_osso or a WebGate. Confirm that single sign-on works. Shut down the admin server. Restart your browser and access the protected resource: Access should go through. Invoke RREG to register a new partner: Remote registration should fail. Start up the admin server.
Policy Repository DB Issues

DB unavailable due to maintenance: Consequence: No policy changes are allowed. No impact on run time. Space issues in DB: Consequence: No policy changes are allowed. No impact on run time.
Policy Repository DB Issues

Test: Shut down the DB used for storing policies. Try to access a protected resource: You observe that run-time access is not impacted. Try to access the admin console to edit policies: You observe errors in the admin server log file.
Road Map
WLST Architecture
Shares the same foundation layer with the OAM admin console
WLST Architecture
Note: All WLST commands are case-sensitive.
Offline Mode And Online Mode

WLST commands for managing and configuring OAM system configuration Online Mode:
Connects to the MBean server running on the admin server The MBean server can be running remotely. Invokes OAM WLST MBean methods; the methods are executed in the server OAM WLST MBeans return the result of the execution to the WLST commands.
Offline Mode
Method invocation happens locally in the WLST shell Requires OAM domain home as a mandatory input
Offline Mode and Online Mode

The WebLogic Scripting Tool (WLST) is a command-line scripting environment that you can use to create, manage, and monitor WebLogic Server domains including admin servers, managed servers and the node manager. It is based on the Java scripting interpreter, Jython. In addition to supporting standard Jython features such as local variables, conditional variables, and flow control statements, WLST provides a set of scripting functions (commands) that are specific to WebLogic Server.
Executing WLST Commands

1. Ensure that your OAM admin server is running. 2. Set up the environment for WLST by running DOMAIN_HOME\bin\setDomainEnv.sh. 3. Go to <Oracle_IDM>\common\bin. 4. Execute wlst.cmd to enter the WLST shell. 5. Execute help(oam) to list the available OAM WLST commands. 6. Execute help(<command name>) to get help on a specific WLST command. 7. To run a command in offline mode, provide domainHome as an input to the command. 8. To execute online commands, connect to the MBean server by using the command connect().
Example: Create Identity Store Embedding WLST Command in Python Script

ADMIN_USER_NAME = "weblogic" ADMIN_PASSWORD = "welcome1" ADMIN_SERVER_PORT = "7001" LDAP_HOST = myhost.us.oracle.com" LDAP_PORT = "20440" LDAP_PRINCIPAL = "cn=orcladmin" LDAP_CREDENTIAL = "welcome1" LDAP_BASE_DN = "dc=us,dc=oracle,dc=com" LDAP_USER_BASE_DN = "cn=Users,dc=us,dc=oracle,dc=com" LDAP_GROUP_BASE_DN = "cn=Groups,dc=us,dc=oracle,dc=com connect(ADMIN_USER_NAME, ADMIN_PASSWORD,'localhost:'+ADMIN_SERVER_PORT) print "*** Creating User IdentityStore createUserIdentityStore(name="UserIdentityStore4",principal=LDAP_PRINCI AL, credential=LDAP_CREDENTIAL, type="OID", userAttr="uid",ldapProvider="OID", userSearchBase=LDAP_USER_BASE_DN, groupSearchBase=LDAP_GROUP_BASE_DN, ldapUrl="ldap://%s:%s" % (LDAP_HOST, LDAP_PORT), isPrimary="false") #type="LDAP", roleSecAdmin="Administrators", roleSysMonitor="Monitors", roleSysManager="Deployers", roleAppAdmin="Operators", userIDProvider="<userIDProvider>", domainHome="<domainHome>" print "*** Display User IdentityStore" print displayUserIdentityStore(name="UserIdentityStore4") disconnect()
WLST Commands for OAM 11g

WLST commands for OAM are available within oamWlstCmd.py under <IDM_HOME>\common\wlst Some key WLST commands:
createOAMAuthenticator (delete and update as well) displayOssoAgent (edit and delete as well) displayWebgateAgent (edit and delete as well) displayWebgate11gAgent (edit and delete as well) displayOAMMetrics listOAMAuthnProviderParams
displayUserIdentityStore createOAMIdentityAsserter (edit, create, delete as well) (update as well) displayOamServer (create, edit, delete as well) displayTopology changeLoggerSetting
WLST Commands for OAM 11g

For certain OAM administrative tasks, the WebLogic Scripting Tool (WLST) provides custom commands that can be used as an alternative to the OAM administration console. Custom WLST commands for OAM can be used for setting and managing OAM system configuration only by OAM administrators. The WebLogic Scripting Tool shares the same foundation layer with the OAM administration console. WLST for OAM is available within IDM_HOME\common\wlst. The oamWlstCmd.py file refers to JAR files available in: <Oracle_IDM>/oam/server/lib/jmx <Oracle_IDM>/oam/server/lib/wlst Most WLST commands for OAM operate in both online and offline modes. For more on WLST, refer to Oracle Fusion Middleware WebLogic Scripting Tool Command Reference 11g Release 1 (10.3.3) On the slide, you see some WLST commands which are substitutes for some of the operations you perform in the labs by using the OAM admin console or WLS console or EM console.
WLST Commands for OAM 11g (continued)

createOAMAuthenticator Online command that creates an Oracle Access Manager authenticator in the current domain. Description: Creates an Oracle Access Manager authenticator with a given name in the current domain. Before executing this command, make sure that no Oracle Access Manager authenticator is already configured in the default security domain. In the event of an error, the command returns a WLSTException. displayOssoAgent Online and offline command that displays OSSO agent configuration details. Description: Displays OSSO agent registration details, which also appear in the OAM administration console. The scope of this command is an instance only. The scope is not an argument. displayWebgateAgent Online and offline command that displays a 10g WebGate registration. Description: Displays all 10g WebGate registration details, which can also be seen in the OAM administration console. The scope of this command is an instance only. The scope is not an argument. displayUserIdentityStore Online and offline command that displays user identity store registration information. Description: Displays information of the user identity store registered with Oracle Access Manager. The scope of this command is an instance only. The scope is not an argument. displayWebgate11gAgent Online and offline command that enables you to display an 11g WebGate agent registration. Description: Displays an 11g WebGate agent registration. The scope of this command is an instance only. The scope is not an argument. displayOAMMetrics Online and offline command that enables the display of metrics of OAM servers. Description: Enables the display of metrics of OAM servers. The scope of this command is an instance only. The scope is not an argument. listOAMAuthnProviderParams Online command that lists the values of the parameters in effect in a domain authenticator or identity asserter.
WLST Commands for OAM 11g (continued)

Description: Lists the values of the parameters set for a given Oracle Access Manager authenticator or identity asserter. In the event of an error, the command returns a WLSTException. createOAMIdentityAsserter Online command that creates an Oracle Access Manager identity asserter in the current domain. Description: Creates an identity asserter with a given name in the current domain. Before executing this command, make sure that no Oracle Access Manager identity asserter is already configured in the current domain. In the event of an error, the command returns a WLSTException. displayOamServer Online and offline command that displays OAM server registration details. Description: Displays OAM server registration details, including the host, port, registration name, OAM proxy port and server ID, and, optionally, the OAM proxy shared secret. The scope of this command is an instance only. The scope is not an argument. changeLoggerSetting Online and offline command that changes the logger level. Description: Changes the level of one or more, or all, loggers. The scope of this command is an instance only. The scope is not an argument. displayTopology Online and offline command that displays the information about all the OAM servers in a deployment. Description: Lists the topology of deployed OAM servers. There are no arguments for this command.
Road Map
Oracle Enterprise Manager Fusion Middleware Control

Systems management interface for OAM 11g Key operations: Performance overview and drilldown Dynamic log level changes and log searches (will be discussed later in the course) Topology overview MBean browser
FMW Control: Performance Overview
FMW Control: Performance Overview

OAM server home page and Performance Summary page (OAM > Performance Summary)
Topology
View a graphical representation of the topology
Topology
Click the Topology link on the top-left corner of the Oracle Enterprise Manager Fusion Middleware Control.
MBean Browser
View key MBeans Invoke methods
Mbean Browser
OAM > System MBean Browser
How to Re-register an Agent from the OAM Admin Console

1. Delete the agent. 2. Application Domain > AuthN and AuthZ policies > Delete the resources under the protected and public resource policies and then delete the protected and public resource policies. 3. Delete the resources under the application domain. 4. Delete the application domain. 5. Delete the host identifier.
Summary
In this lesson, you should have learned how to: Work with Access Tester Identify connectivity issues
Between agents and servers (impact of load balancers and firewalls)
Describe OAM-specific WLST commands Work with Oracle Enterprise Manager Fusion Middleware Control
Summary
Learn the diagnostic capabilities within OAM 11g
OAM Access Tester
Explain EM FMW Control integration

Server processes and charts Topology viewer Farm and domain OAM server management MBean browser
Quiz
Which of the following is true: a. You must run Access Tester from the OAM server machine b. You must run Access Tester from the agent machine c. You can run Access Tester from any machine d. You must run Access Tester from the WLS admin server machine
Answer: c
Quiz
Following are the management interfaces for OAM 11g: a. WLST command line b. WLS admin console c. OAM admin console d. EM FMW Control e. All of the above
Answer: e
Quiz
When Access Tester connects to the OAM server, it acts like an: a. Agent b. End user client c. OAM administrator d. OAM proxy server
Answer: a
Quiz
EM FMW Control allows you to: a. View performance overview and drilldown of the OAM server environment b. Configure dynamic log level changes and view log searches c. View OAM environment topology d. Interact with methods, attributes, and their operations by using the MBean browser e. All of the above
Answer: e
Practice 10 Overview: Working with Access Tester, WLST, and FMW Control
This practice covers the following topics: Practice 10-1: Working with Access Tester Practice 10-2: Using OAM-specific WLST commands Practice 10-3: Working with Oracle Enterprise Manager Fusion Middleware Control
Horizontal Migration
Objectives
After completing this lesson, you should be able to: Describe the OAM horizontal migration overview Plan and execute policy migration Plan and execute partner migration Study horizontal migration use cases
Use Cases: Horizontal Migration

Horizontal migration can be used to:
Move Oracle Access Manager 11g data from a test deployment (the source) to a production deployment (the target) Test and roll out upgrades
Methods to move from test to production:

Full Replication Full migration of policies but not partners Golden Template Full migration of policies and partners (used for an HA scenario: multiple OAM servers front-ended by a load balancer) Delta-Replication - Delta migration of only policies
The source OAM server contains the "truth." Any conflicts between the source and the target are resolved based on the source.
Use Cases: Horizontal Migration

OAM 11g configuration data is stored in files, while OAM 11g policy data is stored in a database. Note: Partner migration is always full the first time you perform it, and subsequently it is delta. This is available only in case of a golden template use case.
Perform Horizontal Migration Using WLS Template Builder

Key Steps:
Install IM and WLS software on the production machine. Run RCU to create production schemas for OAM and audit service. Use Template Builder to package the test domain and create the production domain by using this template. Connect by using WLST to AdminServer on test. Export policy data. Connect by using WLST to AdminServer on production.
Import policy data. Log in to the OAM admin console on production. Modify the host name for Primary and Secondary Servers in the WebGate registration to the production host name(s). Modify the host name in the Logout Redirect URL field for WebGate 11g to the production host name. Modify the host name in Server Instance Properties to the production host name.
Perform Horizontal Migration Using WLS Template Builder

Test-to-production migration targets migrating policy and partner information from the stage OAM server to the production server. The production domain can either be created by using WLS Template Builder or created from the beginning on the production machine. You will learn the latter approach in this lessons lab exercise. Note: Using WLST Template Builder approach, you dont have to explicitly export partner data because this data is implicitly carried forward from the test to the production domain as part of creating production domain by using the test domain template. A prerequisites for the test-to-production migration is that the admin servers of the test and the production domains must be up and running during the test-to-production migration.
Performing Horizontal Migration by Using WLS Template Builder

Key Steps:
Change the serverhost value for OAMServerProfile in oamconfig.xml to the production host name. Transfer the new ObAccessClient.xml and cwallet.sso files from production to WebGate machines.
Performing Horizontal Migration by Using WLS Template Builder

Replace the obAccessClient.xml and cwallet.sso for OAM 11g WebGates from the <Domain_Home>/output/<Webgate11g_Name> directory on production machine to the <OHS_Instance>\config\OHS\ohs1\webgate\config directory on the WebGate machine. Replace the obAccessClient.xml for OAM 10g WebGates from the <Domain_Home>/output/<Webgate10g_Name> directory on the production machine to the <Webgate10g_Home>\access\oblix\lib directory on the test machine. Note: One of the key advantages of this approach over creating the production domain from the beginning is that all the artifacts in WLS are carried forward implicitly from the test to the production domain. Hence, there is no need to recreate those artifacts again in the production domain. Some of these artifacts are security providers, JDBC data sources, applications deployed on WLS and so on.
Source and Target Processing

WLST online Test OAM server (WLS) (MBean on admin server)
ExportPartners() ExportPolicy()
Call ExportPartners on test Call ImportPartners on production
Call ExportPolicy on test Call ImportPolicy on production
Production OAM server (WLS) (MBean on admin server)

ImportPartners() ImportPolicy()
Source and Target t2pClient Processing

Exporting replicates and exports application domains and partner information to a temporary dump file. To protect this sensitive information, a keystore is generated with the dump file. The key in this keystore is used to encrypt the dump file. The export mode commands for t2pClient run on the test source OAM server that is hosting the partner to be exported. Importing decrypts the generated dump file by using the key in the keystore and imports the dump file contents to the target OAM server. You can import partners, policies, or policy differences. Import commands are run on the target OAM server
Policy Migration
Export Policy: exportPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >') Import Policy: importPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >') Import Policy Delta: importPolicyDelta(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >')
Policy Migration
exportPolicy: This command is used to export the policy from the test environment. This command needs to be run from the OAM server, from where the policy needs to be exported. This command takes the path to the temporary oam-policy file as a parameter. This command exports application domain and policy data from the source. OAM application domains are exported with all dependencies. importPolicy: This command is used to decrypt and import application domain and policy data to the production environment. This command overwrites all the policy information in the production environment. This command needs to be run from the OAM server to which the policy needs to be imported. This command takes the path to the temporary oam-policy file that was created during the export operation as a parameter. importPolicyDelta: This command is used to import the policy to the production environment. This command imports only the changes to the production environment without overwriting the unchanged policy data on the target. This command needs to be run from the OAM server to which the policy needs to be imported.
Partner Migration
Export Partners exportPartners(pathTempOAMPartnerFile =', <pathTempOAMPartnerFile>') Import Partners importPartners (pathTempOAMPartnerFile=', <pathTempOAMPartnerFile>')
Partner Migration
exportPartners(): Exporting a partner creates an object with all partner information, along with the key for each of the partners. This command is used to export the partners from the test environment. This command needs to be run from the OAM server from where the partners need to be exported. This command takes the path to the temporary oampartners file as a parameter. importPartners(): Decrypts and imports partner data by using the key in the keystore. This command is used to import the partners to the production environment. This command needs to be run from the OAM server to which the partners need to be imported. This command takes the path to the temporary oam-partners file as a parameter.
Dependencies
ConfigureUserStore() Used to configure the LDAP identity store definition on the production server Before migrating an OAM 11g application domain, a dependency tree must be constructed for each of the application domains to be migrated.
Dependencies
Configure User Identity Store: This command configures the user store of the production (target) to match the test (source). The application domain consists of authentication and authorization policies over resources. Each authentication policy is configured with an authentication scheme and each authentication scheme has an authentication module configured. To migrate data for an application domain, the shared components (modules, AuthN schemes, and host identifiers) must be migrated first, if they are not already migrated. Shared component data migration is followed by application domain data migration.
Horizontal Migration Use Cases

Full Replication
exportPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >') importPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >')
Golden Template
exportPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >') importPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >')

Golden Template
exportPartners(pathTempOAMPartnerFile=', <pathTempOAMPartnerFile>') importPartners(pathTempOAMPartnerFile=', <pathTempOAMPartnerFile>')
Delta-Replication
exportPolicy(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >') importPolicyDelta(pathTempOAMPolicyFile=', <pathTempOAMPolicyFile >')

Golden Template requires the ConfigureUserStore command in the t2pClient tool.
Summary
In this lesson, you should have learned how to: Perform OAM horizontal migration Plan and execute policy migration Plan and execute partner migration Study horizontal migration use cases
Quiz
Horizontal migration is a process of a. Moving from test to stage to production environment b. Moving from OAM 10g to OAM 11g c. Scaling up your environment for capacity tuning as peak load increases d. Migrating OSSO 10g environment in a rolling fashion to OAM 11g environment
Answer: a
Quiz
Golden template migration involves a. Moving partner data but not policy data b. Moving policy data only c. Moving partner and policy data d. Moving policy data but not partner data
Answer: c
Practice 11 Overview: Performing Horizontal Migration

This practice covers the following topics: Perform prerequisite steps on the production machine before starting horizontal migration Perform horizontal migration to move from test (Windows) to production (Linux) environment Perform post migration tasks Verify the production domain
High Availability
Road Map
Objectives High availability goals Mitigating potential points of failure High availability for OAM sessions and configuration Backing up and restoring OAM
Objectives
After completing this lesson, you should be able to: Describe high availability goals Mitigate potential points of failure in an OAM deployment Provide high availability for OAM sessions and configuration data stored in XML files Back up and restore OAM
Road Map
High Availability (HA) Goals

Minimize down time Provide user session continuity Provide recovery from data loss or corruption Provide recovery from data center loss
High Availability (HA) Goals

Oracle Access Manager controls access to enterprise resources. If Oracle Access Manager goes down, enterprise users have no access to business applications. Therefore, Oracle Access Manager is a critical infrastructure component that must be always available under most circumstances. In an HA deployment, Oracle Access Manager is available for use all the time or nearly all the time. One of the primary goals of HA deployments is to minimize down time. Depending on the amount of permissible down time, different strategies for providing HA are employed. For example, in some organizations, it might be acceptable for Oracle Access Manager to be down one day every three months, while in other organizations, it might be acceptable for Oracle Access Manager to be down only five minutes per year. User session continuity is another common goal of HA deployments. Without user session continuity, if the server to which a user authenticated goes down, the user's session no longer exists, and the user is required to re-authenticate in order to access resources protected by Oracle Access Manager. With user session continuity, sessions can survive the failure of an Oracle Access Manager server. If the Oracle Access Manager server fails, users can continue to use resources protected by Oracle Access Manager without reauthenticating. Oracle Access Manager 11g: Administration 12 - 5
High Availability (HA) Goals (continued)

Data loss or corruption might occur if, for example, a hard drive fails. Deploying redundant servers can protect a deployment from data loss. Backup and recovery procedures can help you restore operations to their full capacity. Finally, the entire data center might fail due to a catastrophic event. For mission-critical deployments, strategies such as data streaming and standby hardware can be used to bring a deployment back into operation quickly. The scope of this lesson is to describe techniques you use to provide HA for Oracle Access Manager deployments. But keep in mind that planning for HA is rarely limited to providing HA for Oracle Access Manager alone; rather, for an entire ecosystem in which Oracle Access Manager is a part.
Road Map
Potential Points of Failure in an Oracle Access Manager Deployment
Audit and Policy
Web Tier
Application Tier LDAP Database Tier
Potential Points of Failure in an Oracle Access Manager Deployment

The term single point of failure describes a deployment node which, if it fails, renders an entire deployment unavailable. The slide identifies single points of failure in an Oracle Access Manager deployment. Subsequent slides describe strategies to mitigate single points of failure. Web Tier A deployment's Web tier consists of agents: 10g WebGates, 11g WebGates, and OHS instances running the mod_osso module. These agents serve as policy decision points for Oracle Access Manager. An agent can be a single point of failure for an Oracle Access Manager deployment. Assume the following conditions are true: A user requests a resource protected by an agent. There is only a single agent deployed in an Oracle Access Manager deployment. The host on which the agent is deployed is down, or the process running OHS is down. In this scenario, the user's request fails.
Potential Points of Failure in an Oracle Access Manager Deployment (continued)

Application Tier The WebLogic managed server instance running the Oracle Access Manager application resides on the application tier, serving as a policy decision point. A WebLogic managed server instance can be a single point of failure for an Oracle Access Manager deployment. Assume the following conditions are true: A user requests a resource protected by an agent. The agent attempts to communicate with the Oracle Access Manager server, by using the server's OAP or HTTP port. The host on which the server is deployed is down, or the process running the WebLogic managed server instance is down. In this scenario, the user's request fails. Data Tier Back-end databases accessed by Oracle Access Manager serverthe audit database, policy database, session database, and identity storecomprise the data tier. A database on the data tier can be a single point of failure for an Oracle Access Manager deployment. Assume the following conditions are true: A user requests a resource protected by an agent. The agent attempts to communicate with the Oracle Access Manager server, by using the server's OAP or HTTP port. Oracle Access Manager server receives the request, and attempts to retrieve the policy that defines the authentication scheme for the resource. The policy databases host is down, or the process running the database is down. In this scenario, the user's request fails. Other Considerations Availability of resources served by Web servers and application serversthe resources that Oracle Access Manager protectscan also be single points of failure for a resource request. Providing high availability for resources served by Web servers and application servers is beyond the scope of this course.
Load Balancing on the Web Tier
Application Tier Load Balancer
Redundant Oracle Access Manager Agents
Load Balancing on the Web Tier

To protect against failure of a server running an agent, deploy redundant agents on the Web tier, and deploy a load balancer to forward requests to the agent. The agents must be of the same type. For example, you could not have 10g and 11g WebGates deployed behind the same load balancer. You can use a hardware or software load balancer in this deployment. Hardware load balancersfor example, Cisco Local Director or F5 Networks BIG-IP provide speed, high reliability, and advanced features. Software load balancersfor example, the reverse proxy plug-in for Oracle HTTP Serverare less expensive and suitable under certain circumstances. By placing a load balancer in front of redundant agents, the load balancer can detect whether the agent is available and, if not, will route requests only to agents that are available. Note: The slide shows a deployment with a single load balancer. To eliminate the load balancer as a single point of failure, deploy redundant load balancers. The slide also shows two redundant agents. Deploy as many agents as you need to satisfy reliability and scalability requirements.
Load Balancing on the Web Tier (continued)

The F5 Networks BIG-IP LTM WebGate The F5 Networks BIG-IP LTM is a hardware load balancer with built-in WebGate support. By deploying the BIG-IP LTM on the Web tier of an Oracle Access Manager deployment, you can provide agent redundancy. Cookie Stickiness Oracle Access Manager does not require you to configure cookie stickiness on the load balancer. Requests can be handled on any of the redundant agent instances. You can configure cookie stickiness to take advantage of other features, such as Web caches. Sticky cookies are not required by Oracle Access Manager, but are recommended for optimal performance. Configuring Multiple Redundant Agents behind a Load Balancer You can configure multiple redundant agents that reside behind a load balancer without registering each agent instance. Instead, perform the following steps: 1. Install WebGate software on every instance deployed behind the load balancer. 2. Register a single agent with Oracle Access Manager. If you use the oamreg remote registration utility, be sure the agent URL in the input file specifies the host name and port number of the load balancer. 3. Copy the agent artifact files to the WebGate configuration directory on each agent instance.
Clustering the Oracle Access Manager Server on the Application Tier
Web Tier Load Balancer or Web Proxy Server Plug-in
Data Tier
Clustered Oracle Access Manager Servers
Clustering the Oracle Access Manager Server on the Application Tier

To protect against failure of an Oracle Access Manager server running on the application tier, deploy a cluster of WebLogic managed server instances, each running the OAM server and other required applications and libraries. WebLogic clustering ensures that requests are routed to an available instance. You can configure the front end of the cluster with a load balancer or a Web proxy server plug-in. The load balancer or Web proxy server can detect whether a server is available, and if not, will route requests only to servers that are available. It is not necessary to configure the front end for cookie stickiness. Requests to the Oracle Access Manager server can be satisfied by any instance running in the cluster. The deployment of redundant Oracle Access Manager servers across multiple WebLogic Server clusters or domains is not supported in Oracle Access Manager 11g Release 1. Note: The slide shows a deployment with two clustered Oracle Access Manager server instances. You can deploy as many servers as you need to satisfy reliability and scalability requirements.
WebLogic Server Cluster

Domain Machine Server Cluster Server Server Server Machine
A cluster is a logical group of WebLogic managed servers. Oracle WebLogic Server clusters provide:
High availability (reliability) Load balancing (scalability)
A cluster is transparent to a client.
WebLogic Server Cluster

An Oracle WebLogic Server cluster consists of multiple Oracle WebLogic Server instances, running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients as one Oracle WebLogic Server instance. The server instances that constitute a cluster can run on one machine or on different machines. You can increase a clusters capacity either by adding server instances to the cluster on an existing machine, or by adding machines to the cluster to host the incremental server instances. Each server instance in a cluster must run the same version of Oracle WebLogic Server. A cluster is a group of Oracle WebLogic Servers that coordinate with one another to provide clients access to the services provided by the entire cluster. Each Oracle WebLogic Server cluster is managed by a single administration server. These services may be a superset of the services provided by a single Oracle WebLogic Server instance.
WebLogic Server Cluster (continued)

A cluster can exist on one or more computers as long as there are multiple Oracle WebLogic Server instances that are executing. The cluster provides an encapsulated interface to the services of the cluster. The cluster appears as a single instance to clients, whether these clients are Web-based or Java-based. By replicating the services provided on a single Oracle WebLogic Server instance, an enterprise system achieves a fail-safe environment and a scalable one. High availability is achieved through the replication of services so that when one server fails, a second server can resume operation where the first left off. Scalability is achieved by balancing the load of incoming requests across the servers in the cluster. If there are four Oracle WebLogic Server instances in a cluster and four requests enter the cluster, scalability can be achieved by balancing the four requests evenly across the cluster instances. A cluster is part of a particular Oracle WebLogic Server domain. All server instances in a cluster must reside in the same domain; you cannot split a cluster over multiple domains. Cluster Configuration Guidelines Observe the following guidelines when configuring WebLogic Server clusters: A cluster cannot span domains. All servers in a cluster must also be in the same domain. All servers within a cluster must be at the same version level. Clustered servers can be on the same or different machines with the same or different operating systems. There can be multiple clusters in a domain. There can only be a single cluster of Oracle Access Manager servers per domain.
Configuring a WebLogic Cluster of Oracle Access Manager Servers on Multiple Hosts

Perform the following steps: Install WebLogic and Oracle Access Manager software on all hosts. Configure Oracle Access Manager on the first host. Propagate the domain configuration to all other hosts. Change the request cache type from BASIC to COOKIE if the URL size is limited. Install and configure the load balancer, and configure Oracle Access Manager to support the load balancer. Change agent configurations as necessary.
Configuring a WebLogic Cluster of Oracle Access Manager Servers on Multiple Hosts

You typically configure a clustered, highly available Oracle Access Manager deployment on multiple hosts. Use the following procedure to configure Oracle Access Manager in a clustered configuration on multiple hosts. Installation and Configuration Install WebLogic Server on each host. All installations must use the same version of WebLogic Server software. It is not required that the hosts run the same operating system. Install Oracle Access Manager on each host. Then configure Oracle Access Manager on the host on which you want to deploy the domain's administration server. During the Customize Server and Cluster Configuration step, identify all the servers and the cluster on which Oracle Access Manager will run. On the host that runs the administration server, start the node manager and the administration server.
Configuring a WebLogic Cluster of Oracle Access Manager Servers on Multiple Hosts (continued)
Domain Configuration Propagation Next, propagate the domain configuration from the first host to all other hosts on which managed server instances participating in the cluster reside. To propagate the domain configuration, use the pack.sh and unpack.sh utilities. Run the pack.sh utility on the first host to package the domain configuration, and unpack.sh on all other hosts to install the domain configuration. Start node managers on all the hosts to which you are propagating the domain configuration. Then start the other managed server instances running Oracle Access Manager by using the command line or the WebLogic console. Changing the Request Cache Type from the BASIC Type to the COOKIE Type Next, you can change the cookie request type from the BASIC type to the COOKIE type. This optional configuration change causes information normally maintained in the URL string during authentication to instead be maintained in the OAM_REQ cookie. You should make this change if your users' browsers enforce small size limits on the length of the URL string; this option enables you to decrease the URL size. Use the following WLST command to change the cache request type: configRequestCacheType(type="COOKIE") After changing the cache request type, you must restart all the managed server instances in the WebLogic cluster. Installing and Configuring the Load Balancer Next, you place a hardware load balancer, software load balancer, or Web proxy in front of managed server instances in the WebLogic cluster. The steps you follow depend on the type of load balancer you choose. You must configure the Oracle Access Manager server to be aware of the load balancer. In the console, change the host name and port number in the SSO engine configuration to the load balancer's host name and port. After changing the SSO engine host name and port number, you must restart all the managed server instances in the WebLogic cluster. Reconfiguring Agents Agents that previously communicated directly with the Oracle Access Manager server must be reconfigured to communicate with the load balancer. To reconfigure agents: Modify the agent configuration parameters to contain the cluster members' hosts and OAP port numbers. Note that agent HA is based on a primary/secondary failover model. Reregister the agent. Copy the agent artifacts to the agent configuration. Restart the agent.
Converting a Single OAM Server on a Single Host to a Clustered Configuration

Perform the following steps: Create the WebLogic cluster, and add the existing instance to the WebLogic cluster. Retarget applications and data sources to the cluster. Clone additional managed server instances and add them to the cluster. Change the request cache type from BASIC to COOKIE if the URL size is limited. Install and configure the load balancer, and configure Oracle Access Manager to support the load balancer. Modify the Oracle Access Manager configuration to reference the load balancer host name and port number. Change agent configurations as necessary.
Converting a Single OAM Server on a Single Host to a Clustered Configuration

When working in a development environment with a single host, you might want to convert an environment with a single Oracle Access Manager server to a clustered environment with multiple managed server instances, each running Oracle Access Manager server. You use this technique in the practices for this lesson. Cluster Configuration Stop the managed server instance running Oracle Access Manager server. Use the WebLogic administration console to create a cluster and add the managed server instance running Oracle Access Manager server to the cluster.
Converting a Single OAM Server on a Single Host to a Clustered Configuration (continued)

Application and Data Source Retargeting Review all applications targeted to the managed server instance in the WebLogic administration console. Retarget applications and libraries that comprise Oracle Access Manager server. It is not necessary to retarget administrative applications, such as Oracle Access Manager administration console. Next, review JDBC data sources, and retarget any data sources used by Oracle Access Manager to the cluster. Cloning New Servers Clone as many new WebLogic managed server instances as you need, and add them to the cluster. Restart all the managed server instances in the cluster. Changing the Request Cache Type from the BASIC Type to the COOKIE Type Next, you can change the cookie request type from the BASIC type to the COOKIE type. This optional configuration change causes information normally maintained in the URL string during authentication to instead be maintained in the OAM_REQ cookie. You should make this change if your users' browsers enforce small size limits on the length of the URL string. This option enables you to decrease the URL size. Use the following WLST command to change the cache request type: configRequestCacheType(type="COOKIE") After changing the cache request type, you must restart all the managed server instances in the WebLogic cluster. Installing and Configuring the Load Balancer Next, you place a hardware load balancer, software load balancer, or Web proxy in front of managed server instances in the WebLogic cluster. The steps you follow depend on the type of load balancer you choose. You must configure the Oracle Access Manager server to be aware of the load balancer. In the console, change the host name and port number in the SSO engine configuration to the load balancer's host name and port. After changing the SSO engine host name and port number, you must restart all the managed server instances in the WebLogic cluster.
Converting a Single OAM Server on a Single Host to a Clustered Configuration (continued)

Reconfiguring Agents Agents that previously communicated directly with the Oracle Access Manager server must be reconfigured to communicate with the load balancer. To reconfigure agents: Modify the agent configuration parameters to contain the cluster members' hosts and OAP port numbers. Note that agent HA is based on a primary/secondary failover model. Re-register the agent. Copy the agent artifacts to the agent configuration. Restart the agent.
Handling Administration Server Failure in a Cluster of Oracle Access Manager Servers

Host A
Admin Server (Active) Web Tier Load Balancer or Web Proxy Server Plug-in Host B
Admin Server (Standby) Clustered Oracle Access Manager Servers

Handling Administration Server Failure in a Cluster of Oracle Access Manager Instances

If the WebLogic administration server goes down, the managed servers running Oracle Access Manager server remain active. But the administrative UIsthe Oracle Access Manager console and the WLST commandare no longer available, and you cannot change the WebLogic Server or Oracle Access Manager configuration. If the domain contains clustered server instances, the load balancing and failover capabilities supported by the domain configuration remain available, even if the administration server fails. You can start a managed server even if the administration server is not running. In this case, the managed server uses a local copy of the domains configuration files for its starting configuration and then periodically attempts to connect with the administration server. When it connects, it synchronizes its configuration state with that of the administration server.
Handling Administration Server Failure in a Cluster of Oracle Access Manager Instances (continued)
Starting a Standby Administration Server After an Administration Server Failure The reference architecture provides for a standby administration server on each host running redundant Oracle Access Manager servers. When you propagate the WebLogic domain to multiple hosts running clustered managed server instances, a copy of the administration server is also propagated. The slide shows the presence of two administration servers in the deployment, with one administration server active and the other administration server available as a standby. In normal operation, all the managed server instances run, while only a single administration server runs. In the event of an administration server failure, one of the standby instances can be brought up to service requests for configuration changes.
Data Tier
The audit and policy data store for production OAM deployments is an Oracle Database. Use Oracle RAC for HA. Audit and Policy If the LDAP data store is Oracle Internet Directory, use Oracle RAC for HA. For other LDAP data stores, the HA deployment varies depending on the LDAP implementation. LDAP
Data Tier
Oracle Access Manager uses the following types of data, which reside on the data tier: Audit data Oracle Access Manager policies Oracle Access Manager sessions Identity data For Oracle Access Manager 11g R1, audit data, policies, and sessions are always stored in an Oracle Database. A typical strategy for Oracle Database HA is Oracle Real Application Clusters (Oracle RAC). Refer to the following URL for more information about Oracle Database high availability, including Oracle RAC: http://www.oracle.com/technetwork/database/features/availability/ index.html. If you use Oracle Internet Directory for your identity store, then identity data is stored in an Oracle Database instance. Use Oracle RAC or another Oracle Database HA strategy. If you use a non-Oracle product for your identity store, refer to your vendor's documentation for information about making the identity store highly available.
Other Issues to Be Aware of in HA Deployments

Firewalls:
Where to place Which ports to open
Security: Which network traffic to encrypt Data center failure and disaster recovery
Other Issues to Be Aware of in HA Deployments

When deploying Oracle Access Manager in an HA environment, a number of issuessuch as the issues listed on the slidethat are beyond the scope of this course come into play. Although these issues are not covered in this course, you should be aware of them and be prepared to handle them, depending on your organization's needs.
Road Map
Session Replication and Configuration Change Distribution

Oracle Coherence provides: In-memory session replication for clustered Oracle Access Manager servers Persistent session replication to the session data store Distribution of changes to the Oracle Access Manager configuration
Session and Configuration Replication

Oracle Access Manager server uses Oracle Coherence to replicate user sessions and the Oracle Access Manager configuration. The eCO Grid The eCO Grid (embedded Coherence grid) is a high-performance distributed caching system that enables Oracle Access Manager to propagate creation and modifications to user sessions across multiple distributed servers. The nature of the distributed cache system implicitly supports site affinity such that any run-time servers have access to the same set of sessions when serving access requests that may have bounced through multiple servers. Making session stores persistent further empowers eCO Grid. With persistent session stores, it is possible to recover from mass failures in the security environment and maintain the same user sessions once the failures are resolved.
Session and Configuration Replication (continued)

Session Replication Oracle Access Manager user sessions are created on the server on which a user authenticates. The number of sessions that can be stored concurrently varies, depending on the following factors: The amount of memory available for session storage on the host The size of user sessions In addition to being stored in-memory on the host, sessions are also written to the Oracle database when they are created or updated. When Oracle Access Manager is running in a clustered environment, with multiple servers running on different hosts, sessions are also replicated to the other hosts on which Oracle Access Manager servers run. Therefore, in the clustered environment, there are three possibilities for session retrieval: Sessions can be retrieved from the same host. Sessions can be retrieved from another host in the cluster. If all the Oracle Access Manager servers in a cluster go down, sessions are recovered from the database as needed after one or more Oracle Access Manager servers are restarted. Session Management Sessions are deleted by Oracle Access Manager as follows: When a user logs out When an administrator deletes the session by using the Oracle Access Manager console After the session lifetime timeout interval has been exceeded An asynchronous process periodically purges expired sessions from the in-memory caches and the database. Session Cache Size The Coherence session cache must be sized so that it never runs out of memory. Use the following property in the oam-config.xml file to specify the maximum cache size: DeployedComponent/Server/NGAMServer/Profile/Sme/SessionManagers /ServerSessionManager/DistributedCacheMaxSize You express the DistributedCacheMaxSize propertys value as a value of type memorySize. For example, 100 MB. Note: You cannot use the Oracle Access Manager console or the WLST utility to change the DistributedCacheMaxSize propertys value.
Session and Configuration Replication (continued)

Distribution of Configuration Changes Oracle Access Manager also uses the eCO Grid to distribute changes in the Oracle Access Manager configuration to multiple hosts running Oracle Access Manager server. When an administrator changes the Oracle Access Manager configuration, the changes are written to the oam-config.xml file, then pushed through the eCO Grid to all hosts running Oracle Access Manager server. Note: Unlike user sessions, the Oracle Access Manager configuration is not written to the database. Oracle Coherence Instance Used by the eCO Grid The eCO Grid uses a separate instance of Oracle Coherence software that is automatically installed with Oracle Access Manager. The eCO Grid Coherence instance is not the same Coherence instance that you can optionally install when you install WebLogic Server.
User Session Continuity in a Single Oracle Access Manager Server Environment

Sessions are saved in the eCO Grid and in the database as they are created.
The OAM server goes down and is restarted. Upon restart, the server has no sessions in-memory.
Sessions are retrieved from the database as needed.
User Session Continuity in a Single Oracle Access Manager Server Environment

Session replication supports Oracle Access Manager's user session continuity capability. With user session continuity, when an Oracle Access Manager server fails, it is possible for the user to continue to access protected applications without re-authenticating to the server. The slide shows how, in an environment with a single Oracle Access Manager server, sessions can fail over after a server restart because the eCO Grid stores sessions in a database as they are created. The eCO Grid can retrieve sessions from the database if it cannot locate sessions in its memory cache. If sessions resided only in-memory, they would be lost after a server process or host went down, forcing users to re-authenticate after a server restart.
User Session Continuity in a Clustered Oracle Access Manager Server Environment
X
Web Tier Load Balancer or Other Cluster Front End
(This Server Is Not Available)
Session Store
User Session Continuity in a Clustered Oracle Access Manager Server Environment

In an environment with a cluster of Oracle Access Manager servers, sessions can fail over without a server restart. If a single Oracle Access Manager server remains up and running, that server can obtain sessions for any user from the eCO Grid. The eCO Grid might retrieve a user's session from any of the following locations: The memory cache on the local host A memory cache on another host The session store in the database, if retrieval from memory caches fails Sticky cookies are not required for user session continuity. The slide shows an environment with two Oracle Access Manager servers. When both servers were up, three users logged in to Oracle Access Manager. Two users' sessions were distributed to other hosts in the eCO Grid, and all the sessions were written to the session store in the database. After one of the servers failed, two users' sessions continued to be available in the eCO Grid. The third session, if needed, could be fetched from the session store.
Road Map
Backing up an Oracle Fusion Middleware Deployment

Back up the Oracle Fusion Middleware environment: Take full offline backups:
When the environment is fully shut down After installation After applying patches or upgrades
Back up run-time artifacts regularly when the environment is up and running.
Backing up an Oracle Fusion Middleware Deployment

The slide provides an overview of Oracle Fusion Middleware backup. Backing up the Oracle Fusion Middleware Environment It is important to consider your entire Oracle Fusion Middleware environment when performing backup and recovery. The installations of an Oracle Fusion Middleware environment are interdependent in that they contain configuration information, applications, and data that are kept in synchronization. For example, when you perform a configuration change, information in configuration files is updated. When you deploy an application, you might deploy it to all managed servers in a domain or cluster. You should back up your entire Oracle Fusion Middleware environment after installation, then regularly. If a loss occurs, you can restore your environment to a consistent state. The backup strategy proposed in the Oracle Fusion Middleware Administrator's Guide is to perform full backups when the system is downafter installation, upgrading, and patching and backups of run-time artifacts regularly.
Backing up an Oracle Fusion Middleware Deployment (continued)

Static Files and Directories: Backed up During Full Backups Only Static files and directories change rarely. The Oracle Fusion Middleware Administrator's Guide recommends backing up the following files only when the environment is fully shut down: The Middleware home directory The OraInventory directory The OraInst.loc and oratab files The beahomelist file For Windows installations, the following registry nodes: HKEY_LOCAL_MACHINE\Software\oracle HKEY_LOCAL_MACHINE\System\ControlSet001\Services HKEY_LOCAL_MACHINE\System\ControlSet002\Services HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
Run-Time Artifacts: Backed up During Full Backups and Regular Backups Run-time artifacts can change often. The Oracle Fusion Middleware Administrator's Guide recommends backing up the following files on a regular basis, typically nightly: Domain directories Oracle instance homes Applications artifacts, such as .ear and .war files, that reside outside of the domain Database artifacts, such as the policy and audit data store The identity store, which might or might not reside in an Oracle database
When performing the backup of run-time artifacts, do not back up local audit files if your Oracle Access Manager deployment is configured to write audit records to the database. Duplicate records might be uploaded to the audit database after a restore. Backup Utilities Oracle Fusion Middleware does not provide users with any special backup utilities or tools. You use tools provided with operating systems or other software: For file backup, use tools such as the tar utility on Linux and UNIX, and the xcopy command on Windows. For database backup, use Oracle Recovery Manager. For more information about Oracle Recovery Manager, refer to the Oracle Database Backup and Recovery User's Guide. For registry key backup, use the regedit utility or any other registry backup tool. For identity store backup, use Oracle Recover Manager for Oracle Internet Directory. If you use a different identity data store, refer to the documentation for the backup procedure for the identity store.
Recovering Your Environment

In an Oracle Access Manager deployment, you might need to perform one or more of the following recovery procedures: Recover the Middleware home Recover the domain Recover Oracle homes Recover instance homes Recover the administration server configuration Recover managed servers Recover data in the data tier
Recovering Your Environment

The slide provides a list of different types of failures and outages that might occur during operation of an Oracle Access Manager deployment. The notes provide brief overviews of the steps you take to recover from the failures and outages. For complete information about recovery procedures, refer to the Oracle Fusion Middleware Administrator's Guide. Recovering a Middleware Home 1. Stop all processes related to the domain, such as the administration server, managed servers, and node managers. 2. Recover the Middleware from backup. 3. Restart domain processes.
Recovering Your Environment (continued)

Recovering a Domain 1. Stop all processes related to the domain, such as the administration server, managed servers, and node managers. 2. Recover the domain directory from backup. 3. Restart domain processes. Recovering Oracle Homes 1. Recover the Oracle home to its original directory from backup. 2. Restart managed servers to which the applications are deployed. Recovering Instance Homes Perform the following procedure if the instance home was deleted from the file system: 1. Stop any processes related to the instance. 2. Recover the instance directory from backup. 3. Restart instance processes. Perform the following procedure if the instance was deregistered from the domain: 1. Recover the instance directory from backup. 2. Register the instance and all of its components with the administration server by using the opmnctl registerinstance command. Recovering the Administration Server Configuration 1. Stop all processes related to the domain, such as the administration server, managed servers, and node managers. 2. Restore the domain home backup to a temporary location. 3. Restore the config directory to the DOMAIN_HOME/config directory. 4. Restart the administration server and verify that it is accessible. 5. Restart other domain processes. Recovering Managed Servers Procedures for recovering managed servers vary, depending on the failure. Refer to the Oracle Fusion Middleware Administrator's Guide for managed server recovery scenarios. Recovering Data in the Data Tier To recover audit data, policy data, and identity store data for Oracle Internet Directory, use Oracle Database Recovery Manager. For more information about Oracle Recovery Manager, refer to the Oracle Database Backup and Recovery User's Guide. For other identity stores, refer to the documentation for the identity store.
HA Topology Review
HA Topology Review
The diagram on the slide provides a reference topology for high availability Oracle Access Manager deployments. While your specific deployment might differ in some areas, the reference topology is a good starting point for complex Oracle Access Manager deployments. Some deployment elements on the slide have been covered earlier in this lesson. For example: Redundancy on the Web, application, and data tiers Usage of load balancers Other deployment elements on the slide are not in the scope of this lesson but are important to consider when configuring a high availability deployment. For example: Placement of firewalls Port numbers to be opened in firewalls Redundancy of the directory service
Summary
In this lesson, you should have learned how to: Describe high availability goals Mitigate potential points of failure in an OAM deployment Provide high availability for OAM sessions and configuration data stored in XML files Back up and restore OAM
Quiz
When configuring Oracle Access Manager for HA, under what condition might you need to change the cache request type from the BASIC type to the COOKIE type: a. b. c. d. The URL string is encrypted because you are using SSL. There are limits on the size of the URL string. You want to protect users from cookie hijacking. Your applications use HTTP basic authentication, and you want to force the Web container to write a session cookie every time a user authenticates.
Answer: b
Practice 12 Overview: Configuring Oracle Access Manager for HA

This practice covers the following topics: Creating a WebLogic Server cluster Adding the WebLogic managed server instance and targeting OAM applications and data sources to the cluster Creating a second WebLogic managed server instance running OAM Adding the second instance to the OAM configuration Changing the request cache type Creating a new OHS instance for load balancing Configuring the load balancer port number in OAM Modifying the WebGate definition in OAM and reconfiguring the WebGate
Introduction to Oracle Access Manager
Oracle Access Manager 11g

Comparison with Oracle Access Manager 10g and OSSO 10g Feature
Components
OAM 11g
WebGate, OAM managed server and administration server One per partner: OAMAuthnCookie_hos t:port_<randomnumb er> set by WebGate OAMRequestCookie_< host:port>_<random number> One for specific OAM Server: OAM_ID One per agent secret key shared between WebGate and OAM server, generated during agent registration One OAM server key, generated during server registration
OAM 10g
WebGate, access server, policy manager Domain-based ObSSOCookie for each WebGate
OSSO 10g
mod_osso, OracleAS SSO server Host-based authentication cookie: one per partner: OHS-host-port one for OSSO server: SSO_ID Domain-level session cookie for global inactivity timeout (GITO) if enabled One key per partner shared between mod_osso and OSSO server OSSO server's own key One global key per OSSO setup for the GITO domain cookie
Cookies
Crypto keys
One global shared secret key per OAM

Cookies: In OAM 11g, host-based authentication cookies: One per partner: OAMAuthnCookie-host-port set by WebGate by using the authentication token received from the OAM server after successful authentication. Note: A valid OAMAuthnCookie is required for a session. One for the specific OAM Server: OAM_ID. In OAM 10g, a domain-based ObSSOCookie for each WebGate (including the authentication WebGate), for both authentication and session management. In OSSO 10g, host-based authentication cookies; one per partner: OHS-host-port, and one for OSSO server: SSO_ID. Domain-level session cookie for global inactivity timeout (GITO) if enabled.
Oracle Access Manager 11g: Administration A - 2

Key Storage
OAM 11g
Agent side: A per-agent key is stored locally in the Oracle Secret Store. OAM 11g server side: A per-agent key, and server key, are stored in the directory server on the server side. Cryptography is performed at both the agent and server ends. Maintain ClientIP, and include it in the hostbased OAMAuthnCookie. Include RequestTime in obrareq.cgi and copy it to obrar.cgi to prevent response token replay.
OAM 10g
Global shared secret stored in the directory server only (not accessible to WebGate)
OSSO 10g
mod_osso side: partner keys and GITO global key stored locally in obfuscated CONFIG file OSSO server side: partner keys, GITO global key, and server key are all stored in the directory server Cryptography is performed at both mod_osso and OSSO server. Include the original clientIP inside the host cookie.
Encryption / Decryption Client IP
Cryptography is performed at AccessServer. Include the original clientIP inside the ObSSOCookie. N/A
Response token replay prevention
Include RequestTime (time stamp just before redirect) in the site2pstore token and copy it to the urlc token to prevent token replay.
Oracle Access Manager 11g (continued)

ClientIP: In OAM 10g, if IP validation is configured, when a cookie is presented in later authentication or authorization requests, this original clientIP is compared with the presenter's IP. Rejection occurs if there is no match. OSSO 10g includes the original clientIP inside the host cookie. In later authentication requests, when the cookie is presented, the original clientIP is compared with the presenter's IP. Rejection occurs if there is no match Encryption/Decryption: In OAM 11g: 1. A WebGate encrypts obrareq.cgi by using the agent key. Note: obrareq.cgi is the authentication request in the form of a query string redirected from the WebGate to the OAM server. 2. The OAM server decrypts the request, authenticates, creates the session, and sets the server cookie.

3. The OAM server also generates the authentication token for the agent (encrypted by using the agent key), packs it in obrar.cgi with a session token (if using cookie-based session management), authentication token, and other parameters, and then encrypts obrar.cgi by using the agent key. Note: obrar.cgi is the authentication response string redirected from the OAM 11g server to the WebGate. 4. The WebGate decrypts obrar.cgi, extracts the authentication token, and sets a hostbased cookie. In OAM 10g: Both obrareq.cgi and obrar.cgi are sent in plain text on the wire (not encrypted). In OSSO 10g: 1. A site2pstore token (request from mod_osso to the server) is encrypted by using the partner key locally at mod_osso. 2. The OSSO server decrypts the site2pstore token, authenticates, and generates its own cookie. 3. A urlc token (the response from the OSSO server to mod_osso) is encrypted by using the partner key at the server. 4. mod_osso decrypts the urlc token locally and re-encrypts by using its own format to set in a host-based cookie.

Crypto algorithm protection Single SignOff
OAM 11g
Includes salt in every encryption for randomness and to prevent cryptographic algorithm break The logOutUrls (OAM 10g WebGate configuration parameter) is preserved. New 11g WebGate parameters: logoutRedirectUrl logoutCallbackUrl doneURL OAM 10g session idle timeout behavior is supported through the Oracle Coherence-based session management engine (SME). AuthN and AuthZ services
OAM 10g
N/A
OSSO 10g
Includes salt in every encryption for randomness and to prevent cryptographic algorithm break The OSSO server cookie includes a list of partner IDs.
Single domain is supported.
Session Management
Single domain is supported.
Single domain is supported through a domain-level cookie for global inactivity timeout (GITO). AuthN service
AuthN and AuthZ
AuthN and AuthZ services

Single Sign-Off: In OAM 11g, the logout process works as follows: logOutUrls triggers initial logout. During logout, a WebGate clears the cookies and redirects the user to a central logout page on the server (specified by using logoutRedirectUrl). logoutCallbackUrl: The WebGate clears cookies during callback. When the central logout page loads, it attempts to load all agents' configured callback URLs. When the WebGate redirects to a server logout page, it also records a doneURL as a query parameter. The OAM 11g server should redirect back to this doneURL after logout. In OAM 10g, once a user logs off from one WebGate, the domain cookie is cleared and the user is considered to be logged off the entire domain. Multi-domain SSO can be supported through chained customized logout pages. In OSSO 10g, when a user logs off from one partner application, the OSSO server pulls a list of the logout URLs. The OSSO server clears its own cookie.

The OSSO server redirects to a customized JSP page (hosted on the OSSO server), and passes the list of logout URLs in the request. The JSP page loads those logout URLs that contain some image tags of check marks, and as a result of the loading, the cookies for those mod_ossos are cleared. Session Management: In OAM 11g, session states are retained in-memory by using Oracle Coherence. In OAM 10g, in case of multi-domain, if a user idles out on one domain, but not on the authentication WebGate, the AWG cookie is still valid; re-authentication is not needed. A new cookie is generated with the refreshed timeout. In OSSO 10g, in case of multi-domain SSO: After a user logs in to one domain, and then goes to a different domain, he or she is considered idle from the first domain, When the idle times out on the original domain, the user must re-authenticate on the original domain.
Credential Collection
OAM 10g collects credentials at the WebGate:
Can be set up to always go to an authentication WebGate Can also be set up for credential collection at every WebGate Login pages are presented by the OAM run-time servers. OAM run-time servers can redirect to login pages located in a separate Web server. Regardless of where the login pages are, credentials are sent to the OAM run-time servers for collection. Login pages are provided out-of-the-box.
OAM 11g collects credentials at the runtime server:
Kerberos Operation
IE Browser OAM 11g Windows KDC
HTTP/SPNEGO Kerberos Token Validate Token GSS APIs Authenticated Subject
User Authenticated
Coexistence and Backward Compatibility
Oracle Single Sign-On Agent Protocol Compatibility Framework
Single Sign-On
Oracle Access Manager 11g WebGate
Oracle Single Sign-On Agent
Oracle SSO 10g

Oracle Single Sign-On Agent
Coexistence and Backwards Compatibility

Backward compatibility and support for mixed-release agents Coexistence and authentication by OAM 11g or OracleAS 10g SSO servers: Supports OracleAS SSO 10g Release (10.1.2.0.2) through OracleAS SSO 10g Release (10.1.4.3.0). Coexistence requires the same back-end user identity store: Oracle Internet Directory (OID).
Coexistence and Backward Compatibility
Oracle Single Sign-On Agent Protocol Compatibility Framework

Delegates authentication to OAM 10g Upon OAM 10g authentication, receives token for credential mapping
Single Sign-On
Oracle Access Manager 11g WebGate
OAM 10g WebGate (handles AuthN) OAM 10g WebGate (handles AuthN)

Collects credential to authenticate user Upon successful authentication, insert header representing authenticated identity
Request Flow: Authentication

OAM server responds to WebGate with policy information Is the resource protected?
4
Challenge based on AuthN schema HTTP request
WebGate/AccessGate/ OSSO agent
5 1
End user
OAM server
Content
3
OAM server checks policy store
Web server
Policy store (DB)

The following steps describe the authentication process that occurs when a user attempts to access a URL protected by a WebGate: 1. The client submits an HTTP request to a Web server for a Web resource as a URL. 2. The WebGate intercepts the request and asks the OAM server whether the resource is protected by an authentication scheme and, if so, what challenge method (Form, Basic, and so on) is used. WebGate acts as a PEP (policy enforcement point). The agent plays the role of a gatekeeper to secure resources such as HTTP-based applications and manage all interactions with the user who is trying to access that resource. This is accomplished according to access control policies maintained on the policy server (OAM server). 3. The OAM server queries the policy store (DB) to determine whether the request is protected and, if so, by what authentication scheme it is protected. The OAM server acts as a PDP (policy decision point). The role of the OAM server is to provide policy, identity, and session services to the agent to properly secure application resources, authenticate, and authorize users, and manage user sessions.
Request Flow: Authentication (continued)

4. The OAM server responds to the WebGate by indicating whether or not the resource is protected and, if it is protected, what challenge method to use to obtain user credentials. 5. If the resource is protected, and the user is not already authenticated (that is, the required cookie is not found), the WebGate presents a challenge method to the user.

11 7 12 6
End user Successful authentication User credentials WebGate Content Web server OAM server responds to WebGate. WebGate passes credentials to OAM server.
8
OAM server calls the AuthN module corresponding to the AuthN scheme
Access server
9
OAM server checks identity store for DN (in case of LDAP AuthN module)
10
Directory server responds with 0 or 1 DN
13
Encrypted cookie set for browser
Identity store
Request Flow: Authentication (continued)

After the WebGate challenges the user with the appropriate authentication scheme for that protected URL, the user submits credentials to the WebGate. 6. The user enters credentials in response to the challenge. 7. The WebGate queries the cache if the resource is protected. The response from the cache indicates if the resource is protected and, if so, by what challenge method. The WebGate looks into the request for the credentials expected to be given in response to the challenge method. Assuming that the credentials are found, they are passed on to the OAM server for evaluation. 8. The OAM server translates the credentials to a user DN. 9. The directory is contacted to obtain the user DN (in case of an LDAP AuthN module). 10. This DN is returned to the OAM server. 11. The OAM server responds to the WebGate based on the authentication response. 12. The WebGate receives the authentication response from the OAM server and formulates the appropriate HTTP response. If the user is accepted, the WebGate starts a session for the user by setting up a user session block in the cache. 13. A single sign-on cookie is created. Oracle Access Manager 11g: Administration A - 13
Request Flow: Authorization

16 14 17
Returns requested resource OAM server responds to WebGate with policy information Is the user authorized? What are the associated actions? Access server
End user
WebGate Content Web server
15
OAM server checks policy store for AuthZ policy
Policy store (DB)
Request Flow: Authorization

Authentication is the process of proving that users are who they say they are, whereas authorization is the process of determining whether these users have access to a protected resource. The following are the authorization steps that are used between a WebGate and an OAM server: 14. After returning the authentication success status to the browser, the WebGate asks the OAM server whether the user is authorized to perform the requested operation for the resource. 15. The OAM server queries the policy store for the authorization policy information. 16. The access server responds to the WebGate with authorization information. 17. The WebGate returns the requested resource if the user is authorized.
Installation and Configuration
WebLogic JMX: Overview

JMX MBeans: Are hierarchical Java objects found on the server Have attributes and operations Support the configuration, management, and monitoring of all types of server resources
ServerMBean LogMBean SSLMBean LogMBean DomainMBean ServerMBean ClusterMBean AppDeployment MBean
SSLMBean
WebLogic JMX: Overview

This diagram shows the hierarchical structure of MBeans. JMX is the Java EE solution for monitoring and managing resources on a network. Like SNMP and other management standards, JMX is a public specification, and many vendors of commonly used monitoring products support it. The administration console, WebLogic Scripting Tool, and other Oracle WebLogic Server utilities use JMX APIs. The JMX specification does not impose a model for organizing MBeans. However, because the configuration of an Oracle WebLogic Server domain is specified in an XML document, Oracle WebLogic Server organizes its MBeans into a hierarchical model that reflects the XML document structure. For example, the root of a domains configuration document is <domain> and below the root are child elements such as <server> and <cluster>. Each domain maintains a single MBean of the DomainMBean type to represent the <domain> root element. Within DomainMBean, the JMX attributes provide access to the MBeans that represent child elements such as <server> and <cluster>.
Oracle Access Manager 11g: Administration B - 2
WebLogic JMX: Overview (continued)

All Oracle WebLogic Server MBeans can be organized into one of the following general types: Run-time MBeans contain information about the run-time state of a server and its resources. They generally contain data about only the current state of a server or resource, and they do not persist with this data. When you shut down a server instance, all run-time statistics and metrics from the run-time MBeans are lost. Configuration MBeans contain information about the configuration of servers and resources. They represent the information that is stored in the domains XML configuration documents. A managed bean (MBean) is a Java object that represents a JMX manageable resource in a distributed environment, such as an application, a service, a component, or a device. When Oracle Internet Directory is registered with an Oracle WebLogic Server admin domain, Oracle Internet Directory MBeans are deployed in the Oracle WebLogic admin server. These MBeans enable management of Oracle Internet Directory configuration through Oracle Enterprise Manager Fusion Middleware Control or WLST.
Navigating JMX MBeans

Use the cd, ls, and pwd commands to navigate the server configuration or run-time MBeans, as with a file system. Use the get or set commands to read or update the MBean attributes. The cmo variable refers to the current MBean.
>connect('myuser','mypass','localhost:7001') >cd('Servers') >ls() dr- AdminServer dr- ServerA >cd('ServerA') >ls() dr- Log dr- SSL -r- ListenPort 7011 -r- StartupMode RUNNING >cd('Log/ServerA/StdoutFilter')
Navigating JMX MBeans

WLST online provides simplified access to MBeans. The JMX APIs require you to use JMX object names to interrogate MBeans, whereas WLST enables you to navigate a hierarchy of MBeans in a fashion similar to navigating a hierarchy of files in a file system. For example, to navigate back to a parent MBean, enter the cd('..') command. Oracle WebLogic Server organizes its MBeans in a hierarchical data model. In the WLST file system, MBean hierarchies correspond to drives, MBean types and instances are directories, and MBean attributes and operations are files. WLST traverses the hierarchical structure of MBeans by using commands such as cd, ls, and pwd in a way similar to navigating a file system in a UNIX or Windows command shell. After navigating to an MBean instance, you interact with the MBean by using WLST commands. WLST online provides a variable, cmo, which represents the current management object. You can use this variable to perform any get, set, or invoke method on the management object. WLST sets the value of cmo to the current WLST path. Each time you change directories, WLST resets the value of cmo to the current WLST path. In the ls command output information, 'd' designates an MBean with which you can use the cd command (analogous to a directory in a file system), 'r' indicates a readable property, 'w' indicates a writable property, and 'x' an executable operation.
Navigating JMX MBeans (continued)

To locate a particular MBean and attribute, you use the find command. WLST returns the path name to the MBean that stores the attribute and its value. You can use the getMBean command to return the MBean specified by the path.
Node Manager
Is a utility or process running on a physical server that enables starting, stopping, suspending, or restarting the administration and managed servers remotely Is not associated with a domain
Can start any server instances that reside on the same physical server
Is required if you use the administration console to start servers Has the following versions:
Java-based Script-based
Node Manager
The server instances in the production environment of an Oracle WebLogic Server are often distributed across multiple domains, machines, and geographic locations. Node manager is an Oracle WebLogic Server utility that enables you to start, shut down, and restart administration server and managed server instances from a remote location. Although a node manager is optional, it is recommended if your Oracle WebLogic Server environment hosts applications with high-availability requirements. A node manager process is not associated with a specific Oracle WebLogic server domain but with a machine. You can use the same node manager process to control the server instances in any Oracle WebLogic Server domain, as long as the server instances reside on the same machine as the node manager process. The node manager must run on each computer hosting the Oracle WebLogic Server instanceswhether the administration server or the managed serverthat you want to control with the node manager. Oracle WebLogic Server provides two versions of the node manager: Java-based and script-based, with similar functionality.
Node Manager (continued)

Node manager is a Java utility that runs as a separate process from Oracle WebLogic Server and allows you to perform common operations for a managed server, regardless of its location with respect to its administration server. While the use of a node manager is optional, it provides valuable benefits if your WebLogic Server environment hosts applications with high availability. Requirements If you run the node manager on a machine that hosts managed servers, you can start and stop the managed servers remotely by using the administration console or the command line. The node manager can also automatically restart a managed server after an unexpected failure. Java-Based Node Manager The Java-based node manager runs within a Java Virtual Machine (JVM) process. You should run it as a Windows service on Windows platforms and as a daemon on UNIX platforms, allowing it to restart automatically when the system is rebooted. This version of node manager determines its configuration from the nodemanager.properties file. The Java-based node manager provides more security than the script-based version. Script-Based Node Manager For UNIX and Linux systems, Oracle WebLogic Server provides a script-based version of node manager. This script is based on UNIX shell scripts, but uses SSH (Secure Shell) for increased security. SSH uses user-ID based security. The advantage of the script-based node manager is that it can remotely manage servers over a network that has been configured to use SSH. No additional server installation is required. The scripts merely have to be copied to the remote machine. Note: It is recommended that you run script-based node manager as an operating system daemon, which allows it to restart automatically when the system is rebooted. Determining Which Node Manager Version to Use If you are installing Oracle WebLogic Server on a Windows system, you must use the Java version of node manager. The scripted version of node manager is not supported on Windows. The script-based node manager requires a much simpler security configuration than the Java version. RSH (Remote Shell) and SSH are easier to configure than secure sockets layer (SSL), which is the method of security used by the Java version of node manager. The script version of node manager also requires a smaller footprint than the Java version. The Java version of node manager can be used with inetd on supported UNIX systems. inetd allows the node manager to be automatically restarted upon receiving a request on the configured port.
Node Manager Architecture

Machine A WLST Node Manager (NM) Admin Console
JMX Client
Administration Server
Node Manager Managed Server 1 (MS1) Machine C

Node Manager Managed Server 2 Machine B
Node Manager Architecture

The diagram illustrates the relationship between a node manager, its clients, and the server instances it controls. A node manager client can be local or remote to the node managers with which it communicates. You can access either version of node managerthe Java version or the script-based (SSH) versionfrom the following clients: Administration Server: Administration console, from the Environments > Machines > Configuration > Node Manager page JMX utilities WebLogic Scripting Tool (WLST) commands and scripts: WLST offline serves as the node manager command-line interface that can run in the absence of a running administration server. You can use the WLST commands to start, stop, and monitor a server instance without connecting to an administration server. Starting the administration server is the main purpose of the stand-alone client. However, you can also use it to: - Stop a server instance that was started by the node manager - Start a managed server
Node Manager Architecture (continued)

Access the contents of a node manager log file Obtain server status for a server that was started with the node manager Retrieve the contents of the server output log
System Configuration: Servers, Data Sources, and Agents
Coherence Properties
Coherence Properties
Coherence provides replicated and distributed (partitioned) data management and caching services on top of a reliable, highly scalable peer-to-peer clustering protocol. Coherence has no single points of failure; it automatically and transparently fails over and redistributes its clustered data management services when a server becomes inoperative or is disconnected from the network. When a new server is added, or when a failed server is restarted, it automatically joins the cluster and Coherence fails back services to it, transparently redistributing the cluster load. Coherence includes network-level fault tolerance features and a transparent soft restart capability to enable servers to self-heal. Coherence modules consist of the properties with their corresponding values and types for the individual server instance. Coherence logging appears only in the WebLogic Server log. There is no bridge from Oracle Coherence logging to Oracle Access Manager logging. Note: Oracle recommends that you do not modify Oracle Coherence settings for an individual server unless you are requested to do so by Oracle Support. LogLevel: The Coherence log level (from -1 to 9) for OAM server events Local Port: The listening port for Coherence logging on the WebLogic Server LogLimit: The Coherence log limit Oracle Access Manager 11g: Administration C - 2
Common Server Properties

OAM admin console > System Configuration tab > Server Instances OAM server common properties are: Audit Configuration settings
Log Directory

Maximum Directory Size Maximum File Size Filter Enabled Filter Preset Audit Users
Filter Settings


Common OAM server properties apply to all OAM server instances. Common server properties appear on the Server Common Properties subtab when you select Server Instances in the navigation tree and click the View button (or from the Actions menu, click Open Common Properties; or from the Server Instance Specific Properties page, click the Server Common Properties link). Audit Configuration: Oracle Access Manager supports auditing for a large number of administrative and run-time events, uniform logging and exception handling, and the diagnostics of all audit events. Note: The log directory cannot be configured by using the administration console. It is the default directory for the Common Audit Framework audit loader. Changing the directory impacts the audit loader and is not supported. Maximum Directory Size: The maximum size, in MB, of the directory that contains audit output files. For example, assuming that the maximum file size is 10, a value of 100 for this parameter implies that the directory allows a maximum of 10 files. Once the maximum directory size is reached, the audit logging stops. For example, a value of 100 specifies a maximum of 10 files if the file size is 10 MB. If the size exceeds this, the creation of the audit logs stops. Oracle Access Manager 11g: Administration C - 3
Common Server Properties (continued)

Maximum File Size: The maximum size, in MBs, of an audit log file. Once the size of a file reaches the maximum size, a new log file is created. For example, specifying 10 directs file rotation when the file size reaches 10 MB. Filter Enabled: Select this check box to enable the filtering of events. Filter Preset: This setting determines the amount of information that is logged. In increasing order of information logged, the values of this parameter can be None, Low, Medium, or All. It is applicable only when the filter is enabled. The default value is Low. Events for filter preset Low or Medium are recorded in the read-only component_events.xml file. Editing of this file is not supported. The events are logged to the file based on the events defined in filter presets. The default filter preset is "Low". Audit Users: Specifies the list of users whose actions are audited, irrespective of the filter presets. It is applicable only when the filter is enabled. All actions of the audit users are audited, irrespective of the filter presets configured. Administrators can add, remove, or edit audit users by using the table.
Oracle Access Manager 11g: Administration C - 4

OAM server common properties are: SSO engine properties
OAM Server Host, Port and Protocol IP Validation SSO Token Version
Session management properties

Session Lifetime Idle Timeout Max Number of Sessions per User

SSO Engine: The SSO engine is the controller for user sessions. SSO engine settings are global and common to all OAM servers in the WebLogic administration domain. OAM Server Host, Port and Protocol: Specifies the OAM server host, port (14100 default) and Protocol (HTTP default or HTTPS). IP Validation: Specific to WebGates and is used to determine whether a client's IP address is the same as the IP address stored in the ObSSOCookie generated for single sign-on. Session Management: Session management refers to the process of managing the life cycle requirements of a user session, and notification of session events to enable global logout. Global logout is required for OSSO agents (mod_osso) to ensure that the logging out of a session on any entity propagates the logout to all entities. Session Lifetime: The amount of time, in minutes, that a user's authentication session remains valid. When the lifetime is reached, the session expires. Default = 480 minutes. A value of 0 disables this timeout setting. Note: Session data for an expired session is automatically deleted from the in-memory caches (or database).

Idle Timeout: Amount of time in minutes that a user's authentication session remains valid without accessing any Oracle Access Manager protected resources. When the user is idle for a longer period, he or she is asked to re-authenticate. A value of 0 disables this timeout setting. Note: Session data for an inactive session is automatically deleted from the in-memory caches (or database). Maximum Number of Sessions Per User: The exact number of sessions that each user can have at one time. Use this setting to configure multiple session restrictions for all users.

Oracle Coherence settings:
Port Multicast Address Multicast Port Time to Live
OAM proxy:
Global Passphrase PEM Keystore Alias PEM Keystore Alias Password

Oracle Coherence: Common Oracle Coherence settings that are shared by all OAM servers differ from those that are configured for individual OAM servers. However, in both cases, Oracle recommends that you make no adjustments to these settings unless instructed to do so by an Oracle Support representative. Port Multicast Address Multicast Port Time to Live OAM Proxy: Simple Mode Configuration: The global passphrase for Simple mode communication using OAM-signed X.509 certificates. This is set during initial OAM server installation. Administrators can edit this passphrase and then reconfigure all existing OAM agents to use it.

Cert Mode Configuration: Details required for the keystore where the Cert mode X.509 certificates signed by an outside Certificate Authority reside: Keystore Alias Keystore Alias Password Note: These are set during initial OAM server installation. The certificates can be imported by using the import certificate utility or the keytool shipped with JDK. Administrators can edit the alias and password and then reconfigure all existing OAM agents to use them.
Backward Compatibility
OAM 11g server is compatible with not only OAM 11g agents (WebGate or AccessGate) but also OAM 10g (WebGate or AccessGate) and OSSO 10g (mod_osso) agents.
Backward Compatibility
You can register an agent that has been freshly installed or previously installed and is operating in an existing OAM 10g SSO or OSSO 10g deployment. After registration, Oracle Access Manager 11g servers are compatible with both 10g and 11g agents in any combination: OAM 11g agents (WebGates or AccessGates) OAM 10g agents (WebGates or AccessGates) OSSO 10g agents (mod_osso) Registering 10g agents that are not used in an existing 10g SSO deployment is the same as registering 11g agents. You can also register a 10g agent that is performing within an existing 10g SSO deployment. In this case, there are some differences between registration techniques as you will see later in this lesson. Legacy OAM SSO agents: The integrated proxy server installed along with each OAM server provides support for legacy Oracle Access Manager SSO deployments by acting as the legacy access server. The OAM proxy can accept requests from multiple access clients concurrently and enables existing access clients (registered OAM 10g WebGates, for instance) to interact with Oracle Access Manager 11g services.
Backward Compatibility (continued)

Legacy OracleAS SSO agents: The integrated OSSO proxy handles token generation and validation in response to token requests during authentication by using OSSO agents. The OSSO proxy needs no configuration. The OAM 10g ObSSOCookie is an encrypted session-based single sign-on cookie that is generated when a user authenticates successfully. The OAM 10g ObSSOCookie stores user identity information, which you can cache if needed. The integrated OAM proxy supports the AES encryption algorithm of the 10g ObSSOCookie to enable backward compatibility with release 10.1.4.x WebGates. The 10g access server can decrypt the cookie created by the OAM 11g proxy (and vice versa). Note: An OAM 11g ObSSOCookie created by OAM proxy is compatible with the ObSSOCookie created by an Oracle Access Manager 10g access server.
WLS Agent
Without a WebGate
Browser
OAMAuthnCookie OAMAuthnCookie_<h>:<p>
WLS agent
IAP
WLS admin server
Console
WLS agent
OAM server
WLS Server
WLS Agent
Co-location with WebGate and IAP
Browser
WebGate
OAM_REMOTE_USER=John OAMAuthnCookie_<h>:<p>
WLS agent
IAP
WLS admin server
Console
WLS agent
OAM server
WLS Server
Policy Configuration: Shared Components and Application Domains
Custom Resource Types

OAM 11g utilizes custom resource types to support nonHTTP resources. Non-HTTP resources are used by fusion applications and other JEE applications as a basis for AuthN and AuthZ when communicating with the OAM server. Some examples where custom resource types are utilized:
Fusion applications SSO Custom authenticator for JEE applications (non-WebGate scenario) Identity asserter for OWSM CredMapper for JEE applications auto login
Custom Resource Types

Identity asserter for OWSM (Oracle Web Services Manager): In this use case, a user is already authenticated with a valid ObSSOCookie. This user then accesses an OWSM-protected Web service resource, and that is when the OWSM calls the OAM identity asserter (IA) implementation in the CSS layer to assert the identity based on the ObSSOCookie. The OAM IA in turn makes a validateUser call by using NAP channel to OAM. In this case, OAM does not have the information like clientIP address and hostID, and also, the request could come from any WebGate. Only the ObSSOCookie is available to assert user identity. Identity Asserter for Fusion Applications SSO: This use case is observed in an ADF application scenario. When an ADF application determines that authentication is required for a particular resource, it redirects the user to a WebGate-protected dummy resource. After successful login, an ObSSOCookie is generated and the dummy page redirects the user to the original ADF resource. This time, the OAM identity asserter intercepts the request and validates the ObSSOCookie by opening a NAP channel to OAM, before the request reaches the ADF application.
Oracle Access Manager 11g: Administration D - 2
Custom Resource Types (continued)

Cred Mapper (as Identity Authenticator) for Fusion Applications Auto Login: In this scenario, the J2EE application is protected either by a WebGate or the OAM identity authenticator. A new user accesses the registration application to register, and when the registration succeeds, a new ObSSOCookie is generated and the user is redirected to the protected resource. This time, the request is validated by a WebGate (or the identity authenticator) by using a NAP channel to OAM.
Custom Authenticator Use Case
1 A user accesses the J2EE application directly because there is no WebGate in this scenario. 2 The application authenticates with the OAM identity authenticator implementation in the CSS layer by passing the username and password. 3 To fulfill the authentication, the OAM identity authenticator contacts OAM on a NAP channel. 4 Upon successful authentication, the OAM identity authenticator returns the subject to the J2EE application.
Custom Authenticator Use Case

In this scenario, a J2EE application is responsible for authentication. A WebGate is not present in this case. The client comes to the application directly and the application uses the OAM identity authenticator implementation to talk to OAM for authentication. The application sends the username and password combination to the OAM identity authenticator and receives a subject, as shown in the diagram.
Fusion Applications SSO Use Case
1 A client accesses an ADF application, which is protected by an anonymous authentication. The ADF application determines that authentication is required, so it redirects to a WebGate-protected ADF authentication servlet. 2 The WebGate connects to OAM for the authentication policy. 3 If AuthN is successful, access to the ADF AuthN servlet is granted, which then redirects to the original ADF controller application. 4 The OAM identity asserter intercepts the request and asserts the identity of the user. 5 This step is optional. The identity asserter may or may not contact OAM to assert the user. It can be configured to trust the connections from the WebGate, in which case it does not need to contact OAM. 6 The request goes back to the ADF controller application.
Creating Custom Resources
Note: No host ID is prefixed for custom resources; no support for virtual hosts. No patterns are supported for custom resource types (they are all literals).
Authentication Parity with OAM 10g

Feature
Support for SSO over protected resources within domain Support for multi-level and step-up authentication Custom authentication plug-in Authentication step (authentication module chaining) Orchestration across multiple authentication steps Support for centralized Web server for credential collection Support for distributed/external credential collection BASIC/FORM/X.509 authentication OCSP/WNA EXT Authentication/CRL Support
OAM 10g
YES YES YES YES YES YES YES YES NO YES
OAM 11g
YES YES NO NO NO YES NO YES YES NO
OAM 10g Parity Items

Features Not Implemented in 11g R1
Feature
Authorization expressions URL query string-based resource matching Additional wildcarding support Policies scoped to a specific HTTP operation Chained authentication schemes AuthN/AuthZ extensibility SPIs User properties, mapping LDAP attributes (or other sources) into the deployment Referential objects (constraints, responses), used from policies in multiple domains
Authentication: Troubleshooting Tips

Logging OAM11g server logs can be used for request tracing. The logger name used by the authentication engine components is oracle.oam.engine.authn. WNA - HTTP trace can be used to check SPNEGO/NTLM passed in a request (NTLM is not supported).
Success and Failure URL

This shows an example of redirection where a more meaningful message is returned than File not found.
2
Web server
Authorization fails
1 Requests access to
resource
WebGate Content
OAM server
AuthzFailure.html
We are sorry but you are not authorized to access this resource. If you would like to request access, contact Application Administrator.
WebGate redirects to AuthzFailure.html
Success and Failure URL

Redirection upon authentication and authorization success or failure is a fairly common scenario. You can redirect users to a specified URL upon authentication or authorization success or failure. For example, you may want to redirect a user, upon authorization failure, to a page with specific information for the unauthorized user. You may also want to redirect users, upon authentication failure, if you want them to see a more informative Web page than the standard HTTP 404 Page not found error or login error. To specify redirection to a URL, perform the following steps: Edit the existing authentication or authorization policy. In the Success URL and Failure URL field, enter the complete URL where you want to redirect users. Click Apply.
Returning Session or Cookie or HTTP Header Variable

2
Web server
Authorization succeeds
1 Requests access to
resource
OAM server
Authorization success
WebGate Content
3 4
Set header variable HTTP_WELCOME_CN Application processes header variable and embeds the CN attribute in returned page
Welcome John Smith!
Returning Session or Cookie or HTTP Header Variable

Oracle Access Manager enables you to pass information in a session or cookie or header variables upon authentication and authorization success or failure. Name: A unique name to distinguish this response from other responses that use the same mechanism (type). Type: The mechanism used to convey the response. Form of the action to be taken with the value string: - HEADER (Header variables): Sets an HTTP request header for downstream applications by using the defined value to dictate the action to be taken (such as the assertion of a user ID by using a predefined HTTP header name). - SESSION: Sets an attribute inside the user session by the client (to enable single sign-on) based on the defined session variable name and value. - COOKIE: Sets a variable name and value (typically set by Web agents) inside the authentication session cookie to enable single sign-on. In cookieless mode, Web-cache is currently used to store cookies from a WebGate. However, in cookieless mode, the end application does not have access to cookies and cannot use them.
Returning Session or Cookie or HTTP Header Variable (continued)

Value: The response expression, set as a variable. Each response consists of two inputs (a type and an expression) and a single output (the value of the evaluated expression). The expression declares how the value should be constructed when the expression is processed. The response type defines the form of action to be taken with the value string. To verify the cookie response, use a browser plug-in tool or turn on the browser "show cookies" settings. To return an HTTP header variable or cookie or session, perform the following steps: 1. Edit the authentication or authorization policy. 2. Click the Response tab and then click the + link 3. Enter a name for your new header variable or cookie or session object. The variable name that you enter here should match the variable name in the script or program where you will pass the value. 4. Select Header or Cookie or Session as the type. 5. Insert your cursor in the Value field. Enter the static text value that you want displayed to users upon authentication or authorization success or failure. 6. Enter the name of the identity attribute that you want to pass to a back-end script or program. This is the attribute name as it appears in the LDAP directory. 7. Click Apply.
Validating Authentication and Authorization in an Application Domain

Enter the URL for an application protected by the registered agent.
Confirm that the login page appears.
Enter a valid username and password.
Validating Authentication and Authorization in an Application Domain

There are several methods for confirming that agent registration as well as authentication and authorization policies are operational. The procedures are nearly identical for both OAM agents and OSSO agents (mod_osso). However, OSSO agents use only the authentication policy and not the authorization policy.
Authentication Module Features

Delegated Authentication Module (DAP):
Asserts user identity by using tokens Delegates authentication to a trusted service OAM verifies the token provided by the service OAM-OIF integration
Shared Components: Authentication Schemes

Challenge methods:
DAP LDAP Module

DAP The Delegated Authentication Protocol (DAP) challenge method is new and required for OIFScheme (Oracle Identity Federation integration) with the DAP authentication module and external context type. The DAP challenge mechanism indicates that OAM does an assertion of the token that it receives, which differs from the standard challenge "FORM" mechanism with the external option. DAPModule is a new assertion module, though it is specialized for this one application and does not appear in the list of authentication modules in the OAM administration console. This integration replaces OSSO 10g with OAM 11g, with no changes from the OIF side The DAP challenge mechanism delegates authentication to a third party (OIF in this case). The challenge_url points to the OIF server URL. When a resource is protected by this scheme, the OAM server redirects to the OIF server URL for credential collection. The OAM server does not perform the credential collection or validation in this case. OIF collects the credentials, authenticates the user against its identity store and returns an assertion token to the OAM server consisting of the username. OAM receives and decrypts this token, checks whether the user is a valid user in the primary identity store for OAM. If the user is valid, OAM gives access to the resource. Oracle Access Manager 11g: Administration D - 15
Shared Components: Authentication Schemes (continued)

The DAPToken is encrypted and decrypted with a key that is shared between OAM and OIF. The DAPToken is built from the OAM side. The OIF administration EM console provides a way to generate the keystore containing the encryption keys that will be used to secure communications between the OAM 11g and OIF. OAM provides a WLST command (registerOIFDAPPartner), that takes the keystore location generated by the OIF store and retrieves the key and stores it on the OAM side.

AuthN Scheme
Anonymous Basic
AuthN Module
Anonymous LDAP
Challenge Method
None Basic
AuthN Level
0 1 2 2 2 2 2 1 5 2 2
LDAPNoPasswordValidation LDAPNoPasswordAuth Form LDAP Kerberos OAAMBasic OAAMAdvanced OIM X509 OAM 10g OIF LDAP Kerberos LDAP LDAP LDAP X509 Form WNA Form Form Form X509
LDAPNoPasswordAuth OAM 10g DAP DAP

Authentication Schemes: AnonymousScheme: Can be used to unprotect specific Oracle Access Manager URLs and allows users to access URLs without a challenge. Users are not challenged and do not need to enter their credentials: KerbScheme: Can be used to protect Oracle Access Manager-related resources (URLs) for most directory types based on a Windows native authentication challenge method and valid WNA credentials in Active Directory: OIMScheme: Can be used to protect Oracle Identity Manager-related passwordmanagement URLs based on a Form challenge method. LDAPScheme: Can be used to protect Oracle Access Manager-related resources (URLs) for most directory types based on a form challenge method. X509Scheme: This authentication scheme is a certificate-based user identification method. To use this method, a user certificate must be installed on your browser and the Web server must be SSL-enabled. BasicScheme: Protects Oracle Access Manager-related resources (URLs) for most directory types.

OAAMBasic: Protects OAAM-related resources with a default context type. This scheme should be used when basic integration with OAAM is required. Here, advanced features like OTP are not supported. This is more of an integration when mod_osso is used as the agent. OAAMAdvanced: Protects OAAM-related resources with an external context type. This authentication scheme is used when complete integration with OAAM is required. A WebGate must front-end the partner.
LDAPNoPasswordValidationScheme: Protects Oracle Access Manager-related resources (URLs) for most directory types based on a Form challenge method. Used with the identity asserter for SSO when you have resources in a WebLogic container. Authentication Modules: In Oracle Access Manager 11g, each authentication scheme requires an authentication module. Several preconfigured authentication modules are available for use out-of-the-box: Kerberos Module: A credential mapping module that matches the credentials of the user who requests a resource (username and password) to the user defined for Windows native authentication in Active Directory. LDAP Module: A credential mapping module that matches the credentials of the user who requests a resource (username and password) to a user definition stored in an LDAP directory server. An LDAP module is required for Basic and Form challenge methods. X509 Module: Similar to LDAP with additional properties that indicate which attribute of the client's X.509 certificate should be validated against the user attribute in LDAP. Note: Only preconfigured authentication modules can be used in an authentication scheme. You cannot use a custom authentication module.
Monitoring OAM 11g by Using Oracle Grid Control
Objectives
After completing this lesson, you should be able to: Describe Oracle Enterprise Manager Grid Control architecture List the key capabilities of Oracle Identity Management pack Work with identity and access targets Discover and monitor Oracle Access Manager
Oracle Access Manager 11g: Administration E - 2
Enterprise Manager Architecture
Enterprise Manager Architecture

Enterprise Manager is viewed as a single entity. Technically, it is built with the following software components: Oracle Management Service (OMS) Oracle Management Agent (Management Agent) Oracle Management Repository (Management Repository) While OMS acts as the brain of the Enterprise Manager Grid Control architecture responsible for communicating with management agents and a central repository that stores information, management agents act as the hands and legs of a body responsible for collecting information from the monitored targets and transporting them to OMS. The management repository is the repository configured in Oracle Database to store the collected information. After installing Enterprise Manager Grid Control, what you see is the Grid Control console, the user interface that displays information about the health of the monitored targets. However, internally, OMS orchestrates with management agents to discover targets, monitor and manage them, and store the collected information in a repository for future reference and analysis.
Enterprise Manager Architecture (continued)

To summarize, Enterprise Manager Grid Control has the following core components: Oracle Management Agent (Management Agent) Management Agent is an integral software component that is deployed on each monitored host. It is responsible for monitoring all the targets running on those hosts, communicating that information to the middle-tier Oracle Management Service, and managing and maintaining the host and its targets. Oracle Management Service (OMS) OMS is a J2EE Web application that orchestrates with management agents to discover targets, monitor and manage them, and store the collected information in a repository for future reference and analysis. OMS also renders the user interface for the Grid Control console. OMS is deployed to the application server that is installed along with other core components of Enterprise Manager Grid Control. Oracle Management Repository (Management Repository) Management Repository is the storage location where all the information collected by the management agent gets stored. It consists of objects such as database jobs, packages, procedures, views, and tablespaces. Technically, OMS uploads the monitors data it receives from the management agents to the management repository. The management repository then organizes the data so that it can be retrieved by OMS and displayed in the Grid Control console. Since data is stored in the management repository, it can be shared between any number of administrators accessing Grid Control. Management Repository is configured in Oracle Database. This Oracle Database can either be an existing database in your environment or a new one installed along with other core components of Enterprise Manager Grid Control. Enterprise Manager Grid Control Console The Enterprise Manager Grid Control console is the user interface you see after you install Grid Control. From the Grid Control console, you can monitor and administrate your entire computing environment from one location on the network. All the services within your enterprise, including hosts, databases, listeners, application servers, and so on, are easily managed from one central location.
Oracle Enterprise Manager Grid Control

Identity Management Pack
10g Oracle Internet Directory 10g Oracle Access Manager 10g Oracle Identity Federation 10g Oracle Identity Manager 11g Oracle Internet Directory 11g Oracle Virtual Directory 11 g Oracle Identity Federation 11 g Oracle Identity Manager 11g Oracle Access Manager 11g Oracle Adaptive Access Manager
Discover Oracle Identity Management deployments and model end-to-end services. Monitor the health of all critical IDM components and set up alerts against a wide range of performance metrics. Record service tests to simulate key enduser activities and to actively measure performance and availability of the IDM service. Define Service Level Objectives (SLO) based on business requirements. Track configuration changes for Oracle Identity Management components.
Oracle Enterprise Manager Grid Control

Oracle Identity Management provides a unified, integrated security platform designed to manage user identities, provision resources to users, secure access to corporate resources, enable trusted online business partnerships, and support compliance (identity analytics) across the enterprise. Oracle Identity Management products include the following: Oracle Access Manager 10g Oracle Identity Manager 9.x Oracle Identity Federation 10g and 11g Oracle Identity Management Suite 10g (including Oracle Internet Directory, Single Sign-On, Delegated Administration Services, and Directory Integration Platform) Oracle Internet Directory 11g Directory Integration Platform 11g Oracle Virtual Directory 11g Oracle Identity Manager 11g
Oracle Enterprise Manager Grid Control (continued)

Oracle Access Manager 11g Oracle Adaptive Access Manager 11g
Using Grid Control for Monitoring Identity Management Targets Enterprise Manager helps you monitor the availability and diagnose the health of identity manager targets within your enterprise configuration. By deploying a management agent on each host, you can use Enterprise Manager to discover the identity management components on these hosts, and automatically begin monitoring them by using default monitoring levels, notification rules, and so on. Enhanced Interface for Managing Fusion Middleware ADF-based interface Navigation tree on the left controls details displayed on the right Customization of home page views via drag-and-drop of regions Context-sensitive menus In-context drilldowns to Fusion Middleware Control and WebLogic Server administration console
Oracle Identity Management Pack

Key Capabilities: Performance Monitoring and Diagnostics Aggregate System Status: Monitor the health of all critical IDM components. Analyze performance charts in real-time or in historical view. Set up alerts against a wide range of performance metrics. Notification Methods: Notification methods could be defined to send email, trigger SNMP traps, or to kick off custom scripts.

Key Capabilities: Performance Monitoring and Diagnostics
End User Monitoring monitors the health of IDM from an enduser perspective. Record synthetic Web transactions or LDAP queries to be used as the criteria for determining the services availability. Define beacons that are used to play back service tests from locations that are representative of your user communities.

Automated Identity Management Monitoring and Alerts: Enterprise Manager automatically gathers and evaluates diagnostic information from identity management targets distributed across the enterprise. As with all targets managed by Enterprise Manager, an extensive number of identity management performance metrics are automatically monitored against predefined thresholds. Alerts are generated in Grid Control when metrics exceed these thresholds. Performance Management Performance monitoring for Identity Management 11g components, including Oracle Internet Directory, Oracle Virtual Directory, Directory Integration Platform, and Oracle Identify Federation. A wide range of out-of-the-box performance metrics to find root causes of problems that could potentially slow performance, extend response times, or create outages Customizable performance summaries with a Metric Palette that allows users to drag and drop performance charts
Oracle Identity Management Pack (continued)

Performance Management (continued) Drill down into usage and performance statistics for: Oracle Identity Federation Providers showing authentication requests and responses, HTTP and SOAP requests and responses, and authentication response processing time Oracle Internet Directory User Statistics showing failed and completed LDAP operations like Add, Bind, Compare, Delete, Modify, and Search Directory Integration Platform Synchronization and Provisioning Profiles showing job status; successful, skipped, and failed changes; completion time; and errors

Key Capabilities: Service Level Management
Model Services: Model services down to the level of components they depend on Define SLOs: Define Service Level Objectives according to business requirements Monitor Against SLOs: Proactively monitor your services and make sure that the performance and availability targets are being met SLM Reports: Report on Service Level Agreement (SLA) compliance Service Dashboards: Create customized dashboards that enable IT staff to have greater visibility into system performance
Features in the Upcoming Release of Grid Control Comprehensive Monitoring

Oracle Grid Control Identity and Access page provides: An overview of all monitored IDM components (including both 10g and 11g components) Automated wizards for discovering identity management deployments Creation of customized systems and services for different administrative scopes
Features in the Upcoming Release of Grid Control

Diagnosing Identity Management Performance and Availability Problems: You can use Grid Control to diagnose performance and availability problems with your identity management services. For example, if a service outage occurs, Root Cause Analysis will determine if the primary cause is an outage of a critical service or system component. If a service performance issue is found, an administrator can examine detailed metrics over time related to that service and any of the service or system components used by that service. When you suspect that there is a problem with one or more server components in the identity management system, the system home pages provide metrics and charts for diagnosing the issue. Administrators can monitor the health of all critical identity management components, including both Identity Management 10g and Identity Management 11g components. Thresholds may be defined against server and component statistics such as CPU utilization, the number of failed and successful authentications or authorizations, average response time, provisioning metrics (e.g. number of newly provisioned, created, deleted, disabled, and locked users), identity provider and service provider metrics, and up/down status of servers and components. In addition to relying on system performance metrics, you may
Features in the Upcoming Release of Grid Control (continued)

use Management Pack for Identity Management Service Tests to record synthetic Web transactions that include a combination of one or more navigation paths within the application to be used as the criteria for determining the availability of the service. For example, Oracle Access Manager requires that a user be successfully authenticated and authorized against a certain WebGate for the service to be considered available. Enterprise Manager uses these logical tasks or transactions to define the availability of the identity management environment. In addition to synthetic Web transactions, Enterprise Manager also supports LDAP tests that allow you to record LDAP operations against a specific LDAP server (including Oracle Virtual Directory). With the LDAP tests, you can specify the username or password, Search Filter, Search Base, and Compare Attribute Name or Value. These synthetic Web transactions are recorded, and the stored transaction or service test can be launched at a user-defined interval from strategic locations across the user-base.

Integration with FMW Control and WLS Admin Console Integrated navigation across Grid Control, FMW Control and WebLogic Server console

Improved Performance Monitoring and Diagnostics Oracle Access Manager
Current
Successful Authentications Failed Authentications Successful Authorizations Failed Authorizations Requests Processed
New in Grid Control 11g R1

Average Authentication and Authorization Latency LDAP Operations/Sec Average LDAP Operation Latency LDAP Operation Success Rate Log Operation Latency Audit Operations/Sec Queue Size Cache Operations Ratio and Average Latency
Grid Control: Home Page
Grid Control: Home Page

Before you start monitoring Oracle Identity Management targets in Enterprise Manger, you must perform the following tasks: Install the Enterprise Manager Grid Control 11g Release 1 (11.1.0.1.0) The information required to perform these steps is available in the Oracle Enterprise Manager Grid Control Basic Installation Guide 11g Release 1 (11.1.0.1.0) http://download.oracle.com/docs/cd/E11857_01/install.111/e15838/toc.htm Install Grid Control 11g Release 1 (11.1.0.1.0) agent on each of the hosts that run Oracle Identity Management components.
Identity and Access Targets
Identity and Access Targets

New Enterprise-Wide View of Oracle Identity Management: A new Identity and Access page provides a centralized view of all Oracle Identity Management components, including Identity Management 10g and Identity Management 11g components. From the Identity and Access page, users can discover identity management components, create systems and services based on the underlying dependencies and monitor the overall health of the identity management environment. Identity Component Server Home Page: In Enterprise Manager Grid Control 11g Release 1, an Identity and Access page provides a central site for monitoring all discovered identity management components. The Identity and Access page can be added to the Targets subtabs by clicking Preferences > Target and by adding Identity and Access to the selected target subtabs. From the Identity and Access page, you can discover both Identity Management 10g and Identity Management 11g components, create systems and services based on the end-to-end identity management environment, and monitor the health of all discovered identity management components
Identity and Access Targets (continued)

from a single page. All identity management targets, whether Access, Identity, Identity Federation, or Identity Manager have their own server home pages that provide easy access to key information required by the administrators. The home page of each identity management server provides the following information: Server status, responsiveness, and performance data. This includes a wide range of out-ofthe-box performance metrics like CPU utilization, failed and successful authentications or authorizations, average response time, provisioning metrics, and up/down status of servers and components, to find root causes of problems that could potentially slow performance, extend response times, or create outages. Customizable performance summaries with a Metric Palette that allows users to drag and drop performance charts and drill down into usage and performance statistics for: Oracle Identity Federation Providers that show authentication requests and responses, HTTP and SOAP requests and responses, and authentication response processing time. Oracle Internet Directory User Statistics that show failed and completed LDAP operations like Add, Bind, Compare, Delete, Modify, and Search. Directory Integration Platform Synchronization and Provisioning Profiles that show job status, successful, skipped, or failed changes, completion time, and errors. Resource usage for the server and its components Functionality to start, stop, and restart components
Identity and Access System
Generic Service
Discovering Oracle Access Manager
Discovering Oracle Access Manager

To discover Oracle Access Manager, perform the following: Log in to Enterprise Manager. Navigate to the Targets tab and select the Identity and Access subtab. Note: If the Identity and Access subtab is not shown, please add it by performing the following steps: a. Click Preferences (on the top right-hand corner of the screen) and then select Target subtabs. b. Move Identity and Access to the Selected Target Subtabs section. c. Click Apply to save your changes. Select Identity Management 11g from the Add drop-down menu and click the Go button.
Create Identity and Access System
Create Identity and Access System

From the View drop-down menu, select Systems and Services. Select Identity and Access System from the drop-down menu and click Go.
Create Service
Create Service
To create a target of type Generic Service associated with any of the monitored Identity Management Systems, perform the following steps: Click Add from the Services section. Enter the general information requested for the new Generic Service. Click Continue once all the information requested is entered. a. Name: Enter a name for your new Generic Service, for example, Oracle Access Manager Access Service . b. Time Zone: Select a time zone for your service. c. Select System: Select a system to be associated with your new service, for example, Access Manager Access System. Enter the availability information requested for the new Generic Service. Define availability based on: i. Service Test: Select this option if the availability of your service is determined by the availability of a critical functionality to your end users. For more information, please see the Service Level Management section.
Create Service (continued)

ii. System: Your service's availability can alternatively be based on the underlying system that hosts the service.
Enter the service test information requested for the new Generic Service. Test Type: Select the type of test that you would like to record or configure. For regular Web transactions, select Web Transaction. For LDAP Service Tests, select LDAP. a. Name: Enter a name for your new service test, for example, Simple Login Test. b. Collection Frequency (Minutes): Enter the desired collection frequency for your service test. c. Transaction: iii. Basic Single URL: If you would like to test a single page, enter a URL for your service test. iv. Record a Transaction: Click the Go button to record a Web transaction that navigates through multiple pages in your application. Enter the beacon information requested for the new Generic Service. Add: Select an available beacon where a Grid Control agent is running. a. Create: Create a new beacon by selecting a discovered Grid Control Agent. Enter the performance metrics information requested for the new Generic Service. Add Based on Service Test: Click the Go button to add performance metrics based on the recorded service test. Define the Warning Threshold and Critical Threshold for your alerts. b. Add Based on System: Click the Go button to add performance metrics based on the monitored Oracle Identity Management components. Define the Warning Threshold and Critical Threshold for your alerts. Enter the usage metrics information requested for the new Generic Service. Add Based on System: Click the Add button to add usage metrics based on the monitored Oracle Identity Management components. Define the Warning Threshold and Critical Threshold for your alerts. Review the information and click Finish to complete the creation of your new Generic Service.
Create a Service Dashboard Report
Create a Service Dashboard Report

Once you have created Generic Service or Web Application targets associated with your monitored Oracle Identity Management Systems, you can create a Services Monitoring Dashboard that summarizes Service Level Agreement Compliance, Actual Service Level Achieved, Key Performance and Usage Metrics, and Status of Key Components. Perform the following steps to create a Services Monitoring Dashboard: 1. rom the Enterprise Manager console, click the Reports tab. 2. lick the Create button. 3. nter the general information requested for the new report. a. Title: Enter a title for your new dashboard. b. Category/Sub-Category: Select a category and sub-category for your dashboard, for example, Category: Monitoring, Sub-Category: Dashboards. c. Use the specified target: Leave blank if this report has no report-wide target. d. Options Visual Style: Select Dashboard for a dashboard view of your services. 4. Click the Schedule tab. a. Add: Select Services Monitoring Dashboard and click the Continue button.
Create a Service Dashboard Report (continued)

b. Set Parameters: Click the Set Parameters button. Select the available services and click the Move button to add them to the Selected Services. 5. Enter the schedule information requested for the new Report. a. Schedule: Enter your scheduling preferences for the report. b. E-Mail Report: Enter the email address and preferences for the report recipient. 6. Click the Access tab to enter information about your access and security preferences for the new report. The report definition can be edited by the report owner and all super administrators. The reports can be viewed by the report owner, by all super administrators, and by the administrators and roles defined in this tab. Click OK to create the new Services Monitoring Dashboard.
Adding or Removing Targets from the System Topology
Adding or Removing Targets from the System Topology

The Management Pack for Identity Management allows you to create the following system targets: Identity and Access System Access Manager Access System (10g) Access Manager Identity System (10g) Identity Federation System (10g) Identity Manager System (10g) For 11.1.1.3.0 release, the pertinent system component is Identity and Access System. Perform the following steps to add or remove a target from the System topology: 1. Click the Targets tab on the Enterprise Manager console. 2. Click the All Targets tab. 3. Click the Oracle Identity Management System targets, for example, Identity and Access System for Dogwood. 4. Click the Edit System link from the Related Links section. 5. Click the Add or Remove button and select the target you would like to add or remove from the system topology. Oracle Access Manager 11g: Administration E - 26
Removing Servers or Components from an Existing Identity Management Topology
Removing Servers or Components from an Existing Identity Management Topology

After discovering Oracle Identity Management targets, you can manually remove individual targets. However, this will delete the respective target information from the Enterprise Manager repository. After that entry is deleted, Enterprise Manager does not monitor that target anymore. Perform the following steps for manually removing components from an existing enterprise: Go to the All Targets tab, search for the server or component you want to delete, select the radio button next to the server or component name, and click the Remove button.
Updating Monitoring Configuration
Updating Monitoring Configuration for Individual Identity Management Targets

You can update the monitoring configuration details for individual Oracle Identity Management targets. Updating monitoring configuration details for individual Oracle Identity Management targets can be used to enter new details about monitored targets including information about the host name, Installation home, host login credentials, database credentials, and SNMP agent designated port and community name. For instance, if the database credentials for accessing the Oracle Identity Manager tables changed, then you can update the monitoring configuration details for the Identity Manager server by using the Monitoring Configuration page. Perform the following steps to update monitoring configuration for individual BI-EE targets: 1. From the Enterprise Manager console, click the Targets tab. 2. Click the All Targets tab. 3. Click the Oracle Identity Management target that you would like to update. For instance, if you would like to update Identity Manager server, click the target of type Identity Manager Server. 4. Click the Monitoring Configuration link in the Related Links section. 5. Update the information and click OK to save the new changes.
Alerts Based on Performance and Usage Metrics
Alerts Based on Performance and Usage Metrics

You can define metrics to measure the performance of the service. You can add performance metrics from any of the key components that are critical for running the service. Once you've added metrics, you can define thresholds, which, when exceeded, will generate alerts. Perform the following steps to add performance metrics based on any of the key components and change the warning and critical thresholds for the selected metrics: 1. Click the Targets tab on the Enterprise Manager console. 2. Click the Identity and Access tab. Note: If the Identity and Access subtab is not shown, please add it by clicking Preferences > Target subtabs. 3. From the View drop-down menu, select Systems and Services. 4. Click one of the Oracle Identity Management Service targets of type Generic Service. 5. Click the Monitoring Configuration tab. 6. Click the Performance Metrics link. 7. Select Based on System from the Add drop-down list and click the Go button.
Alerts Based on Performance and Usage Metrics (continued)

8. Select the Oracle Identity Management target that you would like to monitor from the Target Type drop-down list, and then select the desired performance metric from the Metric drop-down list. Click Continue to proceed. 9. Define the Warning Threshold and Critical Threshold for the selected performance metric and click OK to save your changes. Perform the following steps to add usage metrics: 1. Click the Targets tab on the Enterprise Manager console. 2. Click the All Targets tab. 3. Click the Oracle Identity Management Service target of type Generic Service or Web Application. 4. Click the Monitoring Configuration tab. 5. Click the Usage Metrics link. 6. Click the Add button and select the desired usage metrics. 7. Define the Warning Threshold and Critical Threshold for the selected performance metric and click OK to save your changes.
Metric Baselines
Metric Baselines
Metric baselines are statistical characterizations of system performance over well-defined time periods. Metric baselines can be used to implement adaptive alert thresholds for certain performance metrics, as well as provide normalized views of system performance. Adaptive alert thresholds are used to detect unusual performance events. Baseline normalized views of metric behavior help administrators explain and understand such events. Metric baselines are well defined time intervals (baseline periods) over which Enterprise Manager has captured system performance metrics. The underlying assumption of metric baselines is that systems with relatively stable performance should exhibit similar metric observations (that is, values) over times of comparable workload. Two types of baseline periods are supported: moving window baseline periods and static baseline periods. Moving window baseline periods are defined as some number of days prior to the current date (for example: the last 7 days). This allows comparison of current metric values with recently observed history. Moving window baselines are useful for operational systems with predictable workload cycles (for example: OLTP days and batch nights). Static baselines are periods of time that you define that are of particular interest to you (for example: end of the fiscal year). These baselines can be used to characterize workload periods for comparison against future occurrences of that workload (for example: compare the end of the fiscal year from one calendar year to the next). Oracle Access Manager 11g: Administration E - 31
Metric Baselines (continued)

Once metric baselines are defined, they can be used to establish alert thresholds that are statistically significant and adapt to expected variations across time. For example, you can define alert thresholds to be generated based on significance level, such as the HIGH significance level thresholds, which are values that occur 5 in 100 times. Alternatively, you can generate thresholds based on a percentage of the maximum value observed within the baseline period. These can be used to generate alerts when performance metric values are observed to exceed normal peaks within that period. Note: Metric baselines are supported for the Oracle Identity Management Service of type Generic Service only; other Oracle Identity Management targets do not support metric baselines. Perform the following steps to customize metric baselines for the Oracle Identity Management Service of type Generic Service: 1. Click the Targets tab on the Enterprise Manager console. 2. Click the Identity and Access tab. Note: If the Identity and Access subtab is not shown, please add it by clicking Preferences > Target subtabs. 3. From the View drop-down menu, select Systems and Services. 4. Click the Oracle Identity Management Service target of type Generic Service. 5. Click the Monitoring Configuration tab. 6. Click the Metric Baselines link in the Related Links section.
View All Metrics Collected for Oracle Identity Management Target
View All Metrics Collected for Oracle Identity Management Target

Perform the following steps to view all metrics collected for a monitored Oracle Identity Management target: 1. Click the Targets tab on the Enterprise Manager console. 2. Click the Identity and Access tab. Note: If the Identity and Access subtab is not shown, please add it by clicking Preferences > Target subtabs. 3. Click one of the Oracle Identity Management targets (under the Services section). 4. Click the All Metrics link in the Related Links section.
View All Metrics for Oracle Access Manager

Perform the following steps to view all metrics collected for a monitored Oracle Identity Management target: 1. Click the Targets tab on the Enterprise Manager console. 2. Click the Identity and Access tab. Note: If the Identity and Access subtab is not shown, please add it by clicking Preferences > Target subtabs. 3. Click one of the Oracle Identity Management targets (under the System section). 4. Click the Components tab 5. Click oam_server1 of Oracle Access Manager type. 4. Click the All Metrics link in the Related Links section.
Metric and Policy Settings
Metric and Policy Settings

Some metrics have associated predefined limiting parameters called thresholds that cause alerts to be triggered when collected metric values exceed these limits. Enterprise Manager allows you to set metric threshold values for two levels of alert severity: Warning Attention is required in a particular area, but the area is still functional. Critical Immediate action is required in a particular area. The area is either not functional or indicative of imminent problems. Perform the following steps to change the warning and critical thresholds of performance metrics for a monitored Oracle Identity Management target: 1. Click the Targets tab on the Enterprise Manager console. 2. Click the Identity and Access tab. Note: If the Identity and Access subtab is not shown, please add it by clicking Preferences > Target subtabs. 3. Click one of the Oracle Identity Management targets. 4. Click the Metric and Policy Settings link in the Related Links section.
Availability
Availability
Availability of a service is a measure of the end users' ability to access the service at a given point in time. However, the rules of what constitutes availability may differ from one application to another. For example, for a Customer Relationship Management (CRM) application, availability may mean that a user can successfully log on to the application and access a sales report. For an online store, availability may be monitored based on whether the user can successfully log in, browse the store, and make an online purchase. Grid Control allows you to define the availability of your service based on service tests or systems. Service Test-Based Availability: Select this option if the availability of your service is determined by the availability of a critical functionality to your end users. While defining a service test, choose the protocol that most closely matches the critical functionality of your business process, and beacon locations that match the locations of your user communities. You can define one or more service tests by using standard protocols, and designate one or more service tests as key tests." These key tests can be executed by one or more key beacons" in different user communities. A service is considered available if one or all key tests can be executed successfully by at least one beacon, depending on your availability definition.
Availability (continued)
System-Based Availability: Your service's availability can alternatively be based on the underlying system that hosts the service. Select the components that are critical to running your service and designate one or more components as key components," which are used to determine the availability of the service. The service is considered available as long as at least one or all key components are up and running, depending on your availability definition.
Perform the following steps to define the availability of a service: 1. Click the Targets tab on the Enterprise Manager console. 2. Click the All Targets tab. 3. Click the Oracle Identity Management service target of type Generic Service or Web Application. 4. Click the Monitoring Configuration tab. 5. Click the Availability Definition link. 6. You may select Service Test or System from the Define Availability Based On dropdown list. 7. Enter the request information and click OK to save your changes.
Service-Level Rules
Service-Level Rules
Service-level parameters are used to measure the quality of the service. These parameters are usually based on actual service-level agreements or on operational objectives. Grid Control's Service Level Management feature allows you to proactively monitor your enterprise against your service-level agreements to verify that you are meeting the availability, performance, and business needs within the service's business hours. For service-level agreements, you may want to specify the levels according to operational or contractual objectives. By monitoring against service levels, you can ensure the quality and compliance of your business processes and applications. Perform the following steps to edit a service-level rule for a service: 1. Click the Targets tab on the Enterprise Manager console. 2. Click the All Targets tab. 3. Click the Oracle Identity Management service target of type Generic Service or Web Application. 4. Click the Monitoring Configuration tab.
Service-Level Rules (continued)

5. Click the Edit Service Level Rule link from the Related Links section. 6. Enter the requested information and click OK to save your changes.
Topology
Topology View
Use the Topology page (subtab), to view the dependencies between the service, its system components, and other services that define its availability. Upon service failure, the potential causes of failure, as identified by Root Cause Analysis, are highlighted in the topology view. In the topology, you can view dependent relationships between services and systems.
Service Performance and System Component Status
Service Performance and System Component Status

Grid Control provides a graphical representation of the historic and current performance and usage trends in the Charts page (subtab). You can view metric data for the current day (24 hours), 7 days, or 31 days. The thresholds for any performance or usage alerts generated during the selected period are also displayed in the charts. This helps you to easily track the performance and usage of the service test or system over time and investigate causes of service failure. If performance of a service seems slow, it may be due to high usage of the service. Monitoring the service usage helps diagnose poor performance by indicating whether the service is affected by high usage of a system component.
Performance Summary for Oracle Access Manager
Performance Summary for Oracle Access Manager

In Oracle Enterprise Manager Grid Control 11g R1, customizable performance summaries are available for Oracle Identity Management 11g R1 targets with a Metric Palette that allows users to drag and drop performance charts.
Managing Oracle Access Manager and Running Reports
Alerts and Alert History
Alerts and Alert History

Alerts When a metric threshold value is reached, an alert is generated. An alert indicates a potential problem; either a warning or critical threshold for a monitored metric has been crossed. An alert can also be generated for various target availability states, such as: The target is down. The Oracle Management agent monitoring the target is unreachable. When an alert is generated, you can access details about the alert from the Enterprise Manager console. In the All Targets Alerts section of the Enterprise Manager home page, you can view Critical alerts, Warning alerts, and errors for all monitored targets. You can also view a summary of alerts for monitored Oracle Identity Management targets on the Identity and Access page. The home page of any of the monitored Oracle Identity Management targets lists the alerts specific to that target. You may also view a history of alerts for diagnostic purposes.
Alerts and Alert History (continued)

Perform the following steps to view he history for a monitored Oracle Identity Management target: 1. Click the Targets tab on the Enterprise Manager console. 2. Click the Identity and Access tab. Note: If the Identity and Access subtab is not shown, please add it by clicking Preferences > Target subtabs. 3. Click one of the Oracle Identity Management targets. 4. Click the Alert History link in the Related Links section. Enterprise Manager provides various options to respond to alerts. Administrators can be automatically notified when an alert triggers and/or corrective actions can be set up to automatically resolve an alert condition.
Blackouts
Blackouts
Blackouts allow you to support planned outage periods to perform emergency or scheduled maintenance. When a target is put under blackout, monitoring is suspended, thus preventing unnecessary alerts from being sent when you bring down a target for scheduled maintenance operations such as database backup or hardware upgrade. Blackout periods are automatically excluded when calculating a target's overall availability. A blackout period can be defined for individual targets, a group of targets, or all targets on a host. The blackout can be scheduled to run immediately or in the future, and to run indefinitely or stop after a specific duration. Blackouts can be created on an as-needed basis, or scheduled to run at regular intervals. If, during the maintenance period, you discover that you need more (or less) time to complete maintenance tasks, you can easily extend (or stop) the blackout that is currently in effect. Blackout functionality is available from both the Enterprise Manager console as well as via the Enterprise Manager commandline interface (EMCLI). The EMCLI is often useful for administrators who would like to incorporate the blacking out of a target within their maintenance scripts. When a blackout ends, the Management Agent automatically re-evaluates all metrics for the target to provide current status of the target post-blackout.
Blackouts (continued)
If an administrator inadvertently performs scheduled maintenance on a target without first putting the target under blackout, these periods are reflected as target downtime instead of planned blackout periods. This has an adverse impact on the target's availability records. In such cases, Enterprise Manager allows super administrators to go back and define the blackout period that should have happened at that time. The ability to create these retroactive blackouts provides super administrators with the flexibility to define a more accurate picture of target availability. Perform the following steps to set up blackouts for a monitored Oracle Identity Management target: 1. Click the Setup link on the Enterprise Manager console (located in the upper-right section). 2. Click the Blackouts tab. 3. Click the Create button to launch a blackout wizard. 4. Select the desired target types and enter all the requested information.
Blackouts
User-Defined Metrics
Targets > Hosts > <Host for IDM products> > Related Links > User Defined Metrics
User-Defined Metrics
User-defined metrics allow you to extend the reach of Enterprise Manager's monitoring to conditions specific to particular environments via custom scripts. Once a user-defined metric is defined, it is monitored, aggregated in the repository, and can trigger alerts like any other metric in Enterprise Manager. The supported user-defined metrics in the Management Pack for Identity Management are the ones created at the host level (Operating System). Operating System (OS) user-defined metrics can be accessed from host target home pages and allow you to implement custom monitoring functions via OS scripts. Perform the following steps to set up user-defined metrics for the underlying hosts supporting the Oracle Identity Management environment: 1. Click the Targets tab on the Enterprise Manager console. 2. Click the All Targets tab. 3. Click the target of type Host on which Oracle Identity Management components are running. 4. Click the User-Defined Metrics link in the Related Links section. 5. Click the Create button to create a new user-defined metric.
User-Defined Metrics (continued)

6. Enter all the requested information and click OK to save your changes. If you already have your own library of custom monitoring scripts, you can leverage Enterprise Manager's monitoring features by integrating these scripts with Enterprise Manager as OS user-defined metrics.
Summary
In this lesson, you should have learned: Oracle Enterprise Manager Grid Control architecture Key capabilities of Oracle Identity Management pack How to work with identity and access targets How to discover and monitor Oracle Access Manager
Introduction to Access SDK
Road Map
Objectives Custom requirements Access SDK AccessGates Providing administrative support for the development and deployment of AccessGates Accessing SDK support in Oracle Access Manager 11g
Oracle Access Manager 11g: Administration F - 2
Objectives
After completing this lesson, you should be able to: Identify custom requirements for authentication and authorization services Describe the Access SDK Describe AccessGates Provide administrative support for development and deployment of AccessGates Describe Access SDK support in Oracle Access Manager 11g
Road Map
Custom Requirements for Authentication and Authorization Services

Protect URLs on a Web server with no available WebGate
Protect a Java EE server with no available identity assertion provider
Enable a command-line application to prompt users for authentication credentials
Custom Requirements for Authentication and Authorization Services

Servers make calls to Oracle Access Manager by using two Oracle-provided facilities: WebGatesprovided with the Oracle Access Manager binariesare plug-ins for Web servers that enable the Web servers to interface with Oracle Access Manager to achieve single sign-on. Identity assertion providersprovided with the Oracle Access Manager binaries enable Java EE servers to use Oracle Access Manager as a single sign-on provider and specify security policy for Java EE applications. But what if you want to protect resources other than resources that can be protected by using WebGates or identity assertion providers? For example, you might want to: Force applications that users run from the command line to authenticate to Oracle Access Manager Protect URLs on Web servers for which WebGates are not available, and then base access decisions on policies configured in Oracle Access Manager Have Oracle Access Manager protect non-HTTP resources on Java EE application servers other than those supported by identity assertion providers
Oracle Access Manager Access System Development Kit

Oracle Access Manager provides a system development kit (SDK) with which developers can write custom code to protect resources when Oracle-provided functionality is not available with Oracle Access Manager or Oracle Fusion Middleware.
Road Map
Access SDK
Authentication Services Authorization Services
Access SDK
Using Access SDK, developers can write custom code to protect resources when Oracleprovided functionality is not available with Oracle Access Manager or Oracle Fusion Middleware. Access SDK is a set of application programming interfaces (APIs) with which programmers can call Oracle Access Manager from programs written in the following languages: Java C C++ C# This lesson explains Access SDK capabilities and how OAM administrators work with Access SDK. Administrators might perform tasks such as supporting developers who code applications that use the Access SDK APIs, and installing applications that use the Access SDK APIs.
Access SDK (continued)

Since administrators are not usually responsible for writing applications, this lesson does not describe in detail how you write applications that use Access SDK. Therefore, even though examples of program code that calls Access SDK APIs are provided in this lesson, you need not know any programming languages to successfully master this lesson. Relationship of Oracle Access Manager 10g Access SDK to Oracle Access Manager 11g Oracle Access Manager 11g uses the Oracle Access Manager 10g Access SDK. As a result, when you work with Access SDK, you use Oracle Access Manager 10g components as follows: To obtain the Access SDK, download and install the Oracle Access Manager 10g Core Components. There is no separate Oracle Access Manager 11g SDK download. To ensure that you have the correct prerequisite components installed on systems on which you develop and deploy AccessGates, refer to the Oracle Identity Management 10g Release 3 (10.1.4.x) Certification Matrix on the Oracle Technology Network. To find out more about AccessGate development, including descriptions of the Access SDK APIs, refer to the Oracle Access Manager Developer Guide 10g. Access SDK Documentation The Access SDK APIs are documented in the Oracle Access Manager Developer Guide 10g. Note that the Access SDK APIs have not changed between Oracle Access Manager versions 10g and 11g. Therefore, the API descriptions in the version 10g documentation are applicable for version 11g. Note: The Oracle Access Manager Developer Guide 10g describes a superset of the APIs available in Oracle Access Manager 11g. Only the authentication and authorization APIs are available in Oracle Access Manager 11g. Access SDK Documentation Javadoc for the Java-language Access SDK APIs is distributed with the Access SDK binaries. Developers can find the Javadoc in the apidoc subdirectory of the top-level Access SDK installation directory.
Road Map
Oracle Access Manager Clients
WebGates (OracleProvided)
AccessGates (OracleProvided or Customized)

Software programs that make calls to Oracle Access Manager are called Oracle Access Manager clients. Since Access SDK provides the APIs you use to call Oracle Access Manager, Oracle Access Manager clients, by definition, are software programs that employ Access SDK APIs in their code. WebGates are Web server plug-ins that intercept HTTP requests for Web resources and forward the requests to the Oracle Access Manager for authentication and authorization. Since WebGates are written by using Access SDK APIs, WebGates are Oracle Access Manager clients. The term AccessGate is used to denote all Oracle Access Manager clients except for WebGates, AccessGates can be provided by Oracle; for example, identity assertion providers shipped with Oracle Fusion Middleware are AccessGates. You can also develop your own custom AccessGates to meet requirements for authentication and authorization that are not satisfied by capabilities provided in Oracle Access Manager.
AccessGate Variations
Category
Operating system Programming language Protected server type Protected resource type Credential collection
Options
Windows, Linux, Solaris Java, C, C++, C# Web server, Java EE application server, other URL, other resource HTTP FORM-based, session tokens, command-line input
AccessGate Variations
AccessGates differ based on a variety of factors: The operating system of the host computer on which they are installed. Each operating system requires a different Access SDK installation package. For supported operating system versions, refer to the Oracle Access Manager Certification Matrix on the Oracle Technology Network. The programming language in which they are written. Java, C, C++, and C# APIs are available. These programming languages provide a choice of interfaces to the underlying functionality of the API. The type of server for which they are written. You can protect Web servers or Java EE application servers. The type of resources they protect. You can protect both HTTP URLs and non-HTTP resources. The ways in which they retrieve user credentials. You can enable HTTP FORM-based input, the use of session tokens, and command-line input, among other methods.
Road Map
Developing and Deploying AccessGates: Overview

1. 2. 3. 4. Prepare systems for running AccessGates. Install Access SDK on the developers system. Develop the AccessGate. Install Access SDK on the system that will run the AccessGate. 5. Transfer the AccessGate code to the system on which it will run, if necessary. 6. Configure Oracle Access Manager to support the AccessGate. 7. Test the AccessGate.
Developing and Deploying AccessGates: Overview

The following section of this lesson describes tasks that administrators and developers perform when developing and deploying AccessGates. Information about the tasks that developers typically perform is provided so that administrators attending this training can better understand the entire process required to develop and deploy AccessGates. The code examples in this section are provided for illustration purposes only.
Preparing Systems for AccessGate Development and Deployment
Supported Java SDK Version Supported OS Version Developers System Environment Variables
AccessGate System
Preparing Systems for AccessGate Development and Deployment

Before installing Access SDK, perform the following steps: 1. Verify that prerequisite components are installed on developer systems: - For Java AccessGate development, ensure that the Java SDK version on the developers system meets the requirements specified in the Client Certification worksheet of the Oracle Identity Management 10g Release 3 (10.1.4.x) Certification Matrix on the Oracle Technology Network. - For .NET AccessGate development, ensure that the Visual Studio version on the developers system meets the requirements specified in the Client Certification worksheet of the Oracle Identity Management 10g Release 3 (10.1.4.x) Certification Matrix on the Oracle Technology Network. Note: It is not necessary to install a Java run-time environment on the system on which you deploy the AccessGate. The Java run-time environment is included with the Access SDK installation, and the AccessGate uses this version of the run-time environment when it executes.
Preparing Systems for AccessGate Development and Deployment (continued)

2. Make sure that the operating system on which the AccessGate will run is a supported version, and verify that any required patches have been applied and required libraries have been installed. Refer to the Server Certification worksheet of the Oracle Identity Management 10g Release 3 (10.1.4.x) Certification Matrix on the Oracle Technology Network for a list of supported operating system versions, patch requirements, and library requirements. Set environment variables as documented in the Oracle Access Manager Developer Guide 10g.
3.
Installing Access SDK
Use the Oracle Access Manager 10g Access SDK to Develop AccessGates for Oracle Access Manager 11g
Installing Access SDK

To install Access SDK, perform the following steps: 1. Obtain the version of Access SDK that you need. You can obtain the Access SDK binaries at the Oracle Fusion Middleware 11g R1 Software Downloads page on the Oracle Technology Network Web site. Locate the Access Manager Core Components (10.1.4.3.0) downloads; then select the download for the operating system on which you want to install Access SDK. 2. Unzip the Access Manager Core Components (10.1.4.3.0) download. The download contains several installers, including the Access SDK installer. For Microsoft Windows, two Access SDK installers are available in the Core Components download: - Access SDK for Microsoft Windows with .NET 1.1, which supports Microsoft Visual Studio 2002 - Access SDK for Microsoft Windows with .NET 2.0, which supports Microsoft Development Environment Visual Studio 2005 and later For other operating systems, a single Access SDK installer is available.
Installing Access SDK (continued)

3. To install Access SDK on Microsoft Windows, run the .exe file that you obtained in the previous step. The only information you need to provide to the Installation Wizard is the install directory location. 4. To install Access SDK on UNIX (including Linux), change to the directory in which you placed the Access SDK installation script. Make sure that you have sufficient permissions to execute the installation script. Then execute the script. The only information you need to provide to the installation script is the install directory location. Note: Ensure that the correct version of JDK is being used in your environment by setting the JAVA_HOME and LD_LIBRARY_PATH environment variables to the appropriate JDK path.
Developing the AccessGate

Developers use the Access SDK to write code that performs functions such as the following: Initializing the Access SDK Determining whether a resource to be accessed is a protected resource Collecting authentication credentials, if necessary Passing the credentials to Oracle Access Manager and determining if authentication succeeded Allowing or denying the user access to the resource
Developing the AccessGate

The Access SDK APIs enable developers to write code that performs functions needed to achieve single sign-on and to protect HTTP and other resources. Developers typically write API calls that perform functions such as the following: Initializing Access SDK, which establishes connectivity between the AccessGate and Oracle Access Manager Determining whether resources are protected and, if so, by which authentication scheme. Developers can determine whether they need to force users to authenticate. Collecting credentials according to the necessary authentication scheme Passing the credentials to Oracle Access Manager for validation Determining whether the user is authorized to access the requested resource Allowing or denying the user access to the resource
Example of Access SDK API Usage in an AccessGate

Defines a resource that
. . . users want to access public static final String ms_resource = "//example.com:80/secrets/index.html"; public static final String ms_protocol = "http"; public static final String ms_method = "GET"; public static void main(String argv[]) try { Initializes Access SDK ObConfig.initialize(); Calls OAM to see if the resource is protected ObResourceRequest rrq = new ObResourceRequest(ms_protocol, ms_resource, ms_method); if (rrq.isProtected()) { System.out.println("Resource is protected."); ObAuthenticationScheme authnScheme = new ObAuthenticationScheme(rrq); If not, asks user to authenticate . . .

The slide shows the first part of a segment of an example AccessGate that forces end users to authenticate to Oracle Access Manager from the command line. This code segment is from the JAccessGate example, which is fully documented and annotated in the Oracle Access Manager Developer Guide 10g. For complete information about the Access SDK APIs, refer to the Oracle Access Manager documentation.
Creates a user session . . . object with the resource ObUserSession session = request and credentials new ObUserSession(rrq,creds); if (session.getStatus() == ObUserSession.LOGGEDIN) { Calls OAM to see if the user is authorized to access the resource
if (session.isAuthorized(rrq)) { System.out.println("User is logged in and authorized for the request at level " + session.getLevel()); } else { System.out.println("User is logged in but NOT authorized"); } } else { System.out.println("User is NOT logged in"); } . . .
Example of Access SDK API Usage in an AccessGate (continued)

The slide shows the second part of the JAccessGate example. In this code example, a session object is created, then called in order to determine if a user who has authenticated has permission to access a protected resource.
Configuring Oracle Access Manager to Support AccessGates

If necessary, transfer the AccessGate application to the production system on which it will run. Deploy the AccessGate. Using the Oracle Access Manager console, create an AccessGate entry. Run the configureAccessGate utility to create the ObAccessClient.xml file.
Configuring Oracle Access Manager to Support AccessGates

After a developer has completed developing an AccessGate, an administrator needs to deploy the AccessGate and configure Oracle Access Manager for the AccessGate. Transferring the AccessGate to the Production System Start by copying the AccessGate binary to the system on which it will run. Deploying the AccessGate Next, deploy the AccessGate. The steps you perform to deploy the AccessGate vary, depending on the platform on which the AccessGate will run and the resource the AccessGate will protect. For example: If you were deploying an AccessGate that users ran from the command line, you would need to install the AccessGate executable so that it was available from users command-line prompts. If you were installing an AccessGate that ran as a servlet in a servlet-compliant Web container, you might deploy a Web archive (WAR) file.
Configuring Oracle Access Manager to Support AccessGates (continued)

Creating an Entry for the AccessGate in the Oracle Access Manager Console Next, you define an entry for the AccessGate as a 10g WebGate in the Oracle Access Manager console. You supply a unique name and a password for the AccessGate. Running the configureAccessGate Utility Finally, you run the configureAccessGate utility. This utility, located in the oblix/tools/configureAccessGate subdirectory of the Access SDK installation directory, takes arguments that provide information about the Oracle Access Manager host. For example: The Oracle Access Manager host name The port number on which Oracle Access Manager runs The AccessGate password, which must be the same password that you specified when you created the entry for the AccessGate in Oracle Access Manager When an AccessGate initializes the Access SDK by using the initialize method of the ObConfig class, it uses the information that you provided when you ran the configureAccessGate utility to reach the Oracle Access Manager host.
Road Map
Access SDK Support in Oracle Access Manager 11g

Access SDK Feature
Authentication API Authorization API Policy Manager API Authentication and authorization plug-in SDK Identity XML, identity Web services, and identity event plug-in API
Oracle Access Manager 11g Support

Supported Supported Not supported Not supported Refer to the Oracle Identity Manager 11g documentation for information about identity management features in the OAM 10g Access SDK
Comparing the Oracle Access Manager 10g and Oracle Access Manager 11g Access SDK
The table illustrates support for Access SDK features in Oracle Access Manager 11g. Authentication and authorization APIs are supported. The release 10g Policy Manager API is not supported in release 11g. Because Oracle Access Manager 10g supported identity management, Access SDK provides identity and access management customization capabilities. Because identity management functionality has been removed from Oracle Access Manager with release 11g, the portion of the Access SDK that supported identity management functionality is not supported for Oracle Access Manager 11g. Refer to the Oracle Identity Manager 11g documentation for information about identity management customization capabilities.
Quiz
Which of the following four programming languages can programmers use to code AccessGates? a. C b. C++ c. Perl d. Ruby e. COBOL f. Java g. C#
Answer: a, b, f, g
Quiz
You want your company's packaged applications that are written in the C programming language to use Oracle Access Manager for authentication. Which feature of Oracle Access Manager should you use? a. Oracle-provided WebGate b. Oracle-provided AccessGate c. Custom-developed AccessGate
Answer: c
Summary
In this lesson, you should have learned how to: Identify custom requirements for authentication and authorization services Describe the Access SDK Describe AccessGates Support the development and deployment of AccessGates Describe the differences between the Oracle Access Manager 10g and 11g Access SDK
Single Sign-On and Session Management
Intranet Single Sign-On: End-User Experience

http://www.example.com/ EmployeePortal.jsp
http://www.example.com/ MyDepartment.jsp
1. A user attempts to access an employee portal page. 2. The system challenges the user to enter a user ID and a password (or other credentials). 3. The user enters the correct user ID and password, and the system grants the user access to the portal page. 4. The user then attempts to access his or her department's portal. 5. Single sign-on is achieved when the system grants the user access to the page without forcing the user to authenticate a second time.
Intranet Single Sign-On: End-User Experience

The simple example on the slide demonstrates how single sign-on appears to end users. Users are forced to authenticate the first time they access password-protected pages in a Web site. When subsequent accesses to other password-protected pages are attempted, users are granted access to those pages without being forced to enter passwords a second time.
Oracle Access Manager 11g: Administration G - 2
Internet Single Sign-On: End-User Experience
http://www.partssupplier.com
http://www.manufacturer.com/ ViewCurrentInventory.jsp

Single sign-on is not limited to sites in a single intranet, or sites in a single domain. The example on the slide demonstrates single sign-on between sites maintained by two different companies.

1. A useran employee at an auto parts supplierattempts to access the parts suppliers Web site. 2. The parts suppliers Web site challenges the user to enter a user ID and a password (or other credentials). 3. The user enters the correct user ID and password, and the system grants the user access to the parts suppliers Web site. 4. The user clicks a link on one of the pages in the suppliers Web site that takes the user to the Web site of the manufacturer and shows the current inventory of parts. 5. The manufacturers Web site grants access to the employee of the parts supplier without challenging the employee for authentication credentials.
Internet Single Sign-On: End-User Experience (continued)

The example in the slide demonstrates how internet single sign-on appears to end users. Users are forced to authenticate the first time they access password-protected pages in a Web site. When subsequent accesses to other password-protected pages are attempted, users are granted access to those pages without being forced to enter passwords a second time.
Oracle Fusion Middleware 11g R1 Products for Single Sign-On

Covered in this course: Oracle Access Manager Not covered in this course:
Oracle Identity Federation Enables business partners to access each other's applications by using standard federated identity protocols Oracle Adaptive Access Manager Augments Oracle Access Manager, providing strong authentication mechanisms and fraud detection capabilities
Oracle Fusion Middleware 11g R1 Software Solutions for Single Sign-On

Oracle Fusion Middleware 11g R1 provides several products that enable single sign-on, including the following: Oracle Access Manager, which is the product described in this course. Oracle Identity Federation, which enables business partners to access each other's applications transparently by using standard federated identity protocols. Oracle Adaptive Access Manager, which augments Oracle Access Manager, providing strong authentication mechanisms and fraud detection capabilities. This course describes Oracle Access Manager only.
Oracle Fusion Middleware 11g R1 Software Solutions for Single Sign-On (continued)
Single and Cross-Domain Single Sign-On In many (but not all) cases, including the examples on the previous slides, intranet access occurs in a single DNS domain, while Internet access crosses DNS domains. As defined on Wikipedia, a security domain is an application or collection of applications that all trust a common security token for authentication, authorization, or session management. Generally speaking, a security token is issued to a user after the user has actively authenticated with a user ID and password to the security domain. Both Oracle Access Manager and Oracle Identity Federation support both single DNS domain and cross-DNS domain single sign-on scenarios. Typically, Oracle Access Manager is used for single sign-on across a security domain, while Oracle Identity Federation is used for single sign-on across multiple security domains. In deployments in which all resources can be protected by a single server trusted by all parties, Oracle Access Manager is the most common solution. In deployments in which trust relationships between the parties responsible for the protected resources require the use of federated identity protocolsfor example, the SAML 2 protocolOracle Identity Federation is the most common solution.

D63114GC10 sg2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

D63114GC10 sg2

Uploaded by

Copyright:

Available Formats

Oracle Access Manager 11g: Administration

Volume II Student Guide

D63114GC10 Edition 1.0 December 2010 D71611

Technical Contr ibutors and Reviewer s

In-Band Registration Using oamreg Tool 4-54

Auditing and Logging

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle Access Manager 11g: Administration 8 - 2

Oracle Access Manager 11g: Administration 8 - 3

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle Access Manager 11g: Administration 8 - 4

Auditing and Logging: Overview

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Auditing and Logging: Overview

Oracle Access Manager 11g: Administration 8 - 5

Auditing and Logging Overview (continued)

Oracle Access Manager 11g: Administration 8 - 6

Auditing and Logging: Overview

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Auditing and Logging: Overview (continued)

Oracle Access Manager 11g: Administration 8 - 7

Auditing and Logging: Overview (continued)

Oracle Access Manager 11g: Administration 8 - 8

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle Access Manager 11g: Administration 8 - 9

The Fusion Middleware Audit Framework

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

The Fusion Middleware Audit Framework

Oracle Access Manager 11g: Administration 8 - 10

The Fusion Middleware Audit Framework (continued)

Oracle Access Manager 11g: Administration 8 - 11

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle Access Manager 11g: Administration 8 - 12

Audit Output Options

Default OAM Server Auditing Configuration Flat File

OAM Server Auditing to Oracle DB Oracle DB

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Audit Output Options

Oracle Access Manager 11g: Administration 8 - 13

Audit Architecture Using a Database as the Audit Store

Oracle Access Manager Server

Repository Creation Utility

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Audit Architecture Using a Database as the Audit Store

Oracle Access Manager 11g: Administration 8 - 14

Deploying Auditing by Using a Database as the Audit Store

Run Repository Creation Utility

Create database Oracle BI Publisher

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Deploying Auditing by Using a Database as the Audit Store

Oracle Access Manager 11g: Administration 8 - 15

Deploying Auditing by Using a Database as the Audit Store (continued)

Oracle Access Manager 11g: Administration 8 - 16

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle Access Manager 11g: Administration 8 - 17

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle Access Manager 11g: Administration 8 - 18

Audit Settings (continued)

Oracle Access Manager 11g: Administration 8 - 19

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Oracle Access Manager 11g: Administration 8 - 20

Examples of Audited Events