|Oracle® Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service
11g Release 1 (11.1.1)
Part Number E15478-05
This chapter provides an introduction to this book and links to chapters where you can find more information. This chapter contains the following sections:
This book provides information to help administrators manage OAM 11g components and policies within one or more WebLogic administration domains.
Each WebLogic Server domain is a logically related group of Oracle WebLogic Server resources. WebLogic administration domains include a special Oracle WebLogic Server instance called the Administration Server. Usually, the domain includes additional Oracle WebLogic Server instances called Managed Servers, where Web applications and Web Services are deployed.
Following sections introduce each book part and chapter.
The first part of this book introduces the products described in this book, and system management tasks common to both Oracle Access Manager and Oracle Security Token Service. The following chapters are provided:
Oracle Access Manager administration tasks can be organized around daily and periodic system administration, policy creation and management, session management, diagnostics, and troubleshooting. Initially, the LDAP group used to define administrators is the same for Oracle Access Manager and WebLogic. Initially, the same credentials are used for log in to both the Oracle Access Manager and the WebLogic Server Administration Console. The LDAP group for Oracle Access Manager administrators can be changed.
This section introduces the information in Part II of this guide and includes the following topics:
Administrators use the:
Oracle Access Manager Console to register and manage Oracle Access Manager system configurations and security elements and policies.
For a quick tour of Oracle Access Manager Console and the most common functions and tasks, see Chapter 3, "Getting Started with Common Administration and Navigation".
Note:Custom Administrative command-line tools (WebLogic Scripting Tool, also known as WLST) provide an alternative to the Oracle Access Manager Console for a specific set of functions, as noted when appropriate in this guide
WebLogic Server Administration Console to view the Summary of Server Configuration (Cluster, Machine, State, Health, and Listening Port) of deployed OAM Servers within the WebLogic Server domain, and also to Start, Resume, Suspend, Shutdown, or Restart SSL on these servers.
For details about the WebLogic Server Administration Console, see Oracle Fusion Middleware Administrator's Guide.
Custom Oracle Access Manager WebLogic Scripting Tool for command-line input
Remote registration tool for registering agents and application domains
Chapter 4 explains how to navigate to and configure properties that are common to both Oracle Access Manager and Oracle Security Token Service. This chapter includes the following topics:
Introduction to Common Configuration Elements
Enabling or Disabling Available Services
Managing the Common Settings
Managing Global Certificate Validation and Revocation
The term "data source" is a Java Database Connectivity (JDBC) term that is used within Oracle Access Manager to refer to a collection of user identity stores or a database for policies.
Oracle Access Manager 11g supports several types of data sources that are typically installed for the enterprise. Each data source is a storage container for various types of information.
Note:Oracle Access Manager configuration data is stored in an XML file: oam_config.xml. Oracle recommends that you use only the Oracle Access Manager Console or WebLogic Scripting Tool (WLST) commands for changes; do not edit this file.
A data source must be registered with Oracle Access Manager 11g to enable authentication when a user attempts to access a protected resource (and during authorization, to ensure that only authorized users can access a resource).
The data source must be installed and registered for Oracle Access Manager 11g during the initial deployment process described in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
User Identity Store: Central LDAP storage in which an aggregation of user-oriented data is kept and maintained in an organized way.
Note:Oracle Access Manager 11g does not include identity services; there is no native user, group, or role store.
By default, Oracle Access Manager 11g uses the embedded LDAP in the WebLogic Server domain as the user identity store. However, a number of other external LDAP repositories can also be registered as user identity stores. In this case, one store must be designated as the System Store that contains Administrator roles and users.
Database: A collection of information that is organized and stored so that its content can be easily accessed, managed, and updated.
Policy Store: Oracle Access Manager 11g policy data must be stored in a database that is extended with the Oracle Access Manager-specific schema and registered with Oracle Access Manager 11g.
Session Store: By default, Oracle Access Manager session data is stored within in-memory caches that is migrated to the policy store (database). You can also have an independent database for session data, as described in Chapter 5. For information about sessions, see Chapter 7.
Audit Store: Audit data can be stored either in a file or in a separate database (not the policy store database). For information on auditing, see Chapter 24, "Auditing Administrative and Run-time Events".
A Java keystore is associated with Oracle Access Manager 11g and used to store security keys that are generated to encrypt agent traffic and session tokens. Every Oracle Access Manager and OSSO Agent has a secret key that other agents cannot read. There is also a key to encrypt Oracle Coherence-based session management traffic. However, the keystore is not visible and cannot be managed or modified.
Note:Passwords for keys are stored in a credential store.
Within Oracle Access Manager, User Identity Store details can be managed (registered, viewed, modified, or deleted) from the Oracle Access Manager Console. For more information, see Chapter 5, "Managing Common Data Sources".
See Also:Appendix F, "Introduction to Custom WLST Commands for Administrators" introduces custom WLST commands to create, edit, or display user identity store configuration.
OAM Servers were known as Access Servers in Oracle Access Manager release 10g. OAM Servers provide the Oracle Access Manager 11g runtime instance deployed on Oracle WebLogic Managed Servers. Registered agents communicate with the OAM Server.
Note:Administrators can extend the WebLogic Server domain and add more OAM Servers whenever needed, as described in theOracle Fusion Middleware Installation Guide for Oracle Identity Management.
The Oracle Access Manager Console was previously known as Policy Manager in OAM release 10g. The Oracle Access Manager Console is a Java EE application that must be installed and run on the same computer as the WebLogic Administration Server. Other key applications that run on the WebLogic Administration Server include the WebLogic Server Administration Console and Enterprise Manager for Fusion Middleware Control.
Note:The Oracle Access Manager Console might also be referred to as the OAM Administration Server. However, it is not a peer of the OAM Server deployed on a WebLogic Managed Server.
Several global settings are shared among all services, which can be managed using the Oracle Access Manager Console. See Chapter 4, "Managing Services, Certificate Validation, and Common Settings".
You can use the Oracle Access Manager Console to manage server registrations, as described in Chapter 6, "Managing Common OAM Server Registration".
Settings that are specific to Access Manager operations are described in Chapter 8, "Configuring Access Manager Settings".
Note:You can add a new managed server instance with the OAM Server runtime using either:
The WebLogic Server Administration Console, which requires that you manually register the OAM Server instance as described in Chapter 6, "Managing Common OAM Server Registration"
The WebLogic Configuration Wizard
Customized Oracle WebLogic Scripting Tool (WLST) commands for Oracle Access Manager
The last two methods automatically register the OAM Server instance, which appears in the Oracle Access Manager Console; no additional steps are required.
See Also:Appendix F, "Introduction to Custom WLST Commands for Administrators" introduces custom WLST commands to manage server configuration.
Oracle Access Manager 11g Servers are compatible with various policy enforcement Agents. For more information, see "Single Sign-on Agents".
With OAM 11g, session management refers to the process of managing user session information with support for user- or administrator-initiated events, and time-out based events.
Administrators can configure Oracle Access Manager 11g session lifecycle settings. The database for session storage is initially configured with Oracle Access Manager configuration.
In-memory Session Store: Uses embedded technology from Oracle Coherence to provide a distributed cache with low-data access latencies and to transparently move data between distributed caches (and the database policy store)
Database Session Store: Provides fault-tolerance and scaleability for very large deployments (hundreds of thousands of simultaneous logins). In this case, you must be using a database policy and session-data store that is extended with the OAM-specific schema.
For more information, see Chapter 7, "Managing Sessions".
This section describes the content of Part III of this book:
The Access Manager Setting section of the System Configuration tab provides a number of settings specific to Access Manager service operations.
Included in this chapter (Chapter 8) are the following Access Manager-specific settings:
Introduction to Access Manager Settings
Managing Access Manager Load Balancing Settings
Managing SSO Tokens and IP Validation
Managing the Access Protocol for OAM Proxy Simple and Cert Mode Security
Managing Run Time Policy Evaluation Caches
Managing Authentication modules
A single sign-on agent (also known as a policy-enforcement agent, or simply an agent) is any front-ending entity that acts as an access client to enable single sign-on across enterprise applications.
To secure access to protected resources, a Web server, Application Server, or third-party application must be associated with a registered policy enforcement agent. The agent acts as a filter for HTTP requests, and must be installed on the computer hosting the Web server where the application resides.
Individual agents must be registered with Oracle Access Manager 11g to set up the required trust mechanism between the agent and OAM Server. Registered agents delegate authentication tasks to the OAM Server.
Oracle Access Manager 11g supports the following types of agents in any combination:
OAM Agents: A Webgate is one type of agent. It is a Web server plug-in that acts as an access client. Webgate intercepts HTTP requests for Web resources and forwards them to the OAM Server for authentication and authorization).
Webgate 11g: Must be installed independently. After registration with Oracle Access Manager 11g, Webgates directly communicates with Oracle Access Manager 11g services. No proxy is used.
Webgate 10g: Must be installed independently. After registration with Oracle Access Manager 11g, registered 10g Webgates communicate with Oracle Access Manager 11g services through a Java EE-based OAM proxy that acts as a bridge.
IAMSuiteAgent: This Java agent is installed and registered out of the box to provide SSO protection for resources in the Identity Management domain. The agent's oamsso_logout application is also configured and deployed in the WebLogic (and OAM) AdminServer and all managed servers. The Agent performs as an OAM 10g Agent to enforce Oracle Access Manager 11g policies. This agent replaces the earlier IDMDomainAgent
IDMDomainAgent: This earlier Java agent is replaced by IAMSuiteAgent. After applying the Oracle Access Manager 11g patch set, IDMDomainAgent and its companion application domain are decommissioned.
Access Client: A custom programmatic access client created using the Access Manager software developer kit (SDK). Access Clients can protect Web and non-web resources.
OSSO Agent (mod_osso 10g): After registration with Oracle Access Manager, OSSO 10g Agents communicate directly with Oracle Access Manager 11g services through an OSSO proxy.
The OSSO proxy supports existing OSSO agents when upgrading to Oracle Access Manager 11g. The OSSO proxy handles requests from OSSO Agents and translates the OSSO protocol into a protocol for Oracle Access Manager 11g authentication services.
You can use the following methods and tools to register agents with Oracle Access Manager 11g:
Oracle Access Manager Console: Register and manage OAM and OSSO agents as described in Chapter 9
Remote Registration: Use the Oracle-provided command-line tool as described in Chapter 10.
From an existing 10g Oracle Access Manager or OSSO deployment you can:
Provision 10g Webgates with Oracle Access Manager 11g, as described in Chapter 27.
Upgrade OracleAS 10g SSO (OSSO) as described in the Oracle Fusion Middleware Upgrade Guide for Oracle Identity Management. Read about co-existence with Oracle Access Manager 11g Servers in Appendix A.
This section introduces the information in Part IV of this guide and includes the following topics:
Oracle Access Manager 11g converges SSO architectures such as Identity Federation for Partner Networks, and Service Oriented Architecture (SOA), to name a few. Oracle Access Manager 11g provides single sign-on (SSO) through a common SSO Engine that provides consistent service across multiple protocols.
To delegate authentication tasks to Oracle Access Manager 11g, agents must reside with the relying parties and must be registered with Oracle Access Manager 11g. Registering an agent sets up the required trust mechanism between the agent and Oracle Access Manager 11g SSO.
Note:Single Sign-on for the Oracle Access Manager Console, and other Oracle Identity Management consoles deployed in a WebLogic container, is enabled using the pre-registered IAMSuiteAgent and companion application domain (IAMSuite). No further configuration is needed for the consoles.
Single sign-on can be implemented in a variety of ways:
Single Network Domain SSO: You can set up Oracle Access Manager 11g single sign-on for resources within a single network domain (mycompany.com, for example). This includes protecting resources belonging to multiple WebLogic administration domains within a single network domain.
Multiple Network Domain SSO: With Oracle Access Manager 11g, this is a standard feature. When 11g Webgates are used exclusively all cookies in the system are host-based. However, you must have control over all the domains. If some domains are controlled by external entities (not part of the Oracle Access Manager deployment), Oracle recommends that you use Oracle Identity Federation. For details, see Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.
Multiple WebLogic Server Domain SSO: The basic administration unit for WebLogic Server instances is known as a domain. You can define multiple WebLogic administration domains based on different system administrators' responsibilities, application boundaries, or the geographical locations of WebLogic servers. However, all Managed Servers in a cluster must reside in the same WebLogic Server domain.
SSO with Mixed Release Agents: Oracle Access Manager 11g seamlessly supports registered Oracle Access Manager 11g and OAM 10g Agents (out of the box Webgates and programmatic access clients, and OSSO Agents (mod_osso 10g), which can be used in any combination.
The Oracle Access Manager 11g policy model provides both authentication and authorization services within the context of an application domain.
Note:Oracle Access Manager 10g provides authentication and authorization services within the context of a policy domain. OracleAS SSO 10g provides only authentication.
In the Oracle Access Manager 11g policy model, the following components are shared and can be configured for use within any application domain:
Resource Types: Defines the type of resource to be protected and the associated operations. The default resource type is HTTP. However, administrators can define non-http resource types that can be applied to specific resources in an application domain. The Access Tester can be used to evaluate policy enforcement for HTTP resources only.
Host Identifiers: Simplifies the identification of a Web server host by enabling administrators to include all possible hostname variations within a named definition. When adding resources to an application domain, administrators can choose one of the named definitions and then specify the resource URL.
Virtual Web Hosting: Enables support of multiple domain names and IP addresses that each resolve to their unique subdirectories on a single server. The same host can have multiple sites being served either based on multiple NIC cards (IP based) or multiple names (for example, abc.com and def.com) resolving to same IP.
Authentication Schemes: Identifies the authentication level, challenge method and redirect URL, and the underlying authentication module to perform user authentication. When adding authentication policies to an application domain, administrators can choose one of the named authentication schemes to use with specified resources, as well as the success and failure URLs.
For more information about the policy model and shared components, see Chapter 12, "Managing Policy Components".
Application domains are the top-level constructs of the Oracle Access Manager 11g policy model. Each application domain provides a logical container for resources or sets of resources, and the associated policies that dictate who can access specific resources. Certain shared components are used within each application domain.
Note:To enhance security, Oracle Access Manager 11g default behavior is to deny access when a resource is not protected by a policy that explicitly allows access. In contrast, Oracle Access Manager 10g default behavior allowed access when a resource was not protected by a rule or policy that explicitly denied access.
Oracle Access Manager 10g provided authentication and authorization within the context of a policy domain. In contrast, OracleAS SSO 10g provides only authentication.
Each Oracle Access Manager 11g application domain includes the following elements:
Each resource definition in an application domain requires a Resource Type, Host Identifier (only for HTTP resources), and a URL to the specific resource. You can have as many resource definitions as you need in an application domain.
Authentication Policies and Responses for Specific Resources
Each authentication policy includes a unique name, one authentication scheme, success and failure URLs, one or more resources to which this policy applies, and administrator-defined responses to be applied after successful authentication.
Authorization Policies, Constraints, and Responses for Specific Resources
Each authorization policy includes a unique name, success and failure URLs, and one or more resources to which this policy applies. In addition, administrators can define specific constraints (conditions) that must be fulfilled for a successful authorization and define responses to be applied after successful authorization.
Note:Oracle Access Manager 10g enables authorization actions to be taken depending on the evaluation of the administrator-defined authorization expression contained one or more authorization rules.
Token Issuance Policies and Constraints for Specific Resources
A Token Issuance Policy defines the rules under which a token can be issued for a resource (Relying Party Partner) based on the client's identity, with the client either being a Requester Partner or an end user.
For details, see Chapter 19, "Managing Templates, Endpoints, and Policies".
For more information about the policy model and application domains, see Chapter 13, "Managing Policies to Protect Resources and Enable SSO".
Oracle provides a portable, stand-alone Java application that replaces the Oracle Access Manager 10g Access Tester function. The Oracle Access Manager 11g Access Tester simulates registered Agents connecting to OAM Servers. The scripted execution allows for command-line processing. You can record and playback scripts and capture output for different functions. Encrypted and multiple-server connections are supported.
You can use the Access Tester to troubleshoot agent to server connections in addition to on-the-fly testing of request and response semantics and access policy designs.
Oracle Access Manager 11g provides single logout (also known as global log out) for user sessions. With Oracle Access Manager, single logout refers to the process of terminating an active user session.
For details, see Chapter 15, "Configuring Centralized Logout for OAM 11g".
This section provides information to help administrators manage the Oracle Security Token Services available with Oracle Access Manager
This section introduces the information in Part VI of this guide and includes the following topics:
Logging is the mechanism by which components write messages to a file to capture critical component events. Each Oracle Access Manager component instance writes process and state information to a log file.
You can configure logging to provide information at various levels of granularity. For instance, you can record errors, errors plus state information, or errors and states and other information to the level of a debug trace. You can also eliminate sensitive information from the logs. For more information, see Chapter 22, "Logging Component Event Messages".
You can also use a custom Oracle WebLogic Scripting Tool (WLST) command to change OAM logging levels.
See Also:Appendix F, "Introduction to Custom WLST Commands for Administrators" introduces custom WLST commands to change OAM logging levels
Each Webgate instance (both 10g and 11g Webgates) can write information about its processes and states to a log file. The logs can be configured to provide information at various levels of granularity. For example, you can record errors, errors plus state information, or errors, states, and other information to the level of a debug trace. You can also eliminate sensitive information from the logs.
For more information, see Chapter 23, "Logging Webgate Event Messages".
With Oracle Access Manager 11g, auditing refers to the process of collecting for review specific information related to administrative, authentication, and run-time events. Auditing can help you evaluate adherence to polices, user access controls, and risk management procedures.
Note:Auditing is not available for every Oracle Access Manager 11g component. However, logging is available for every OAM component.
Events are audited using the underlying Oracle Fusion Middleware Common Audit Framework. This framework uses a database audit store to provide scalability and high-availability for the audit framework. The database must include the audit schema.
Note:The Oracle Fusion Middleware Common Audit Framework database audit store does not include OAM policy or session-data and is not configured through the Oracle Access Manager Console.
Administrators can control and specify certain auditing parameters using the Oracle Access Manager Console. Oracle Access Manager auditing configuration is recorded in the file
oam-config.xml. Event configuration (mapping events to levels) occurs in the
component_events.xml. An audit record contains a sequence of items that can be configured to meet particular requirements.
Note:Oracle recommends that you use only the Oracle Access Manager Console or WebLogic Scripting Tool (WLST) commands for changes; do not edit oam_config.xml.
Out-of-the-box, there are several sample audit reports available with Oracle Access Manager and accessible with Oracle Business Intelligence Publisher. You can also use Oracle Business Intelligence Publisher to create your own custom audit reports.
For more information, see Chapter 24, "Auditing Administrative and Run-time Events".
Performance metrics can be collected in memory for components during the completion of particular events. You can monitor the time spent in a particular area or track particular occurrences or state changes.
Only administrators can monitor performance for Oracle Access Manager 11g using the Monitoring command in the Oracle Access Manager Console.
For more information, see Chapter 25, "Monitoring Performance by Using Oracle Access Manager Console".
Live, dynamic OAM performance metrics can be viewed in Fusion Middleware Control.
For more information, see Chapter 26, "Monitoring Performance and Logs with Fusion Middleware Control".
This section introduces the information in Part VII of this guide and includes the following topics:
Everything you need to know about installing and using OAM 10g Webgates with OAM 11g is provided in Chapter 27, "Managing OAM 10g Webgates with OAM 11g".
Details about installing and configuringApache v2-based Web Servers (OHS and IHS) for OAM 10g Webgates with OAM 11g is provided in Chapter 28, "Configuring Apache, OHS, IHS for 10g Webgates".
Details about installing and configuring IIS Web servers for OAM 10g Webgates with OAM 11g is provided in Chapter 29, "Configuring the IIS Web Server for 10g Webgates".
Everything you need to know about configuring the ISA Server for OAM 10g Webgates with OAM 11g is provided in Chapter 30, "Configuring the ISA Server for 10g Webgates".
Everything you need to know about installing and configuring Lotus Domino for use with OAM 10g Webgates and OAM 11g is provided in Chapter 31, "Configuring Lotus Domino Web Servers for 10g Webgates".
This section introduces the information in Part VIII of this guide and includes the following topics:
Table 2-1 outlines several ways to use OAM 11g when you have various starting points.
Table 2-1 OAM 11g Co-existence Summary
|If you have ...||To use OAM 11g SSO ...|
OAM 10g integrated with OSSO 10g
You can upgrade the OSSO deployment to OAM 11g as introduced in Appendix A.
Web Servers other than Oracle HTTP Server
See Chapter 27 for details on:
OracleAS 10g SSO (OSSO)
Use the Oracle-provided Upgrade Assistant, which scans the existing OracleAS 10g SSO server configuration, accepts as input the 10g OSSO policy properties file and schema information, and carries configured partner applications into the destination Oracle Access Manager 11g SSO.
After running the upgrade assistant and performing post-upgrade tasks, existing partner apps (including Portal, Forms, Reports, and Discoverer) would be using OAM instead of OSSO as their SSO provider.
Note: Existing mod_osso modules and OracleAS 10g SSO server partners can work seamlessly with OAM Servers and OAM 11g SSO. However, eventually all mod_osso modules should be replaced with OAM Agents to enable use of OAM 11g Authorization Policies.
See Appendix A for an introduction to post-upgrade co-existence between OAM 11g and OSSO 10g Servers.
OAM 11g streamlines the transfer of configuration data from one deployment to another. For instance, from a small test environment to a larger production deployment (and vice versa).
For more information, see Appendix B, "Transitioning OAM 11g from a Test to a Production Environment".
The Oracle Application Developer Framework (ADF) and applications that are coded to Oracle ADF standards interface with the OPSS SSO Framework. The Oracle Platform Security Services (OPSS) single sign-on framework provides a way to integrate applications in a domain with a single sign-on (SSO) solution.
You can integrate a Web application that uses Oracle ADF security and the OPSS SSO Framework with an Oracle Access Manager 11g SSO security provider for user authentication. For more information, see Appendix C, "Integrating Oracle ADF Applications with Oracle Access Manager 11g SSO".
Appendix D, "Internationalization and Multibyte Data Support for OAM 10g Webgates" provides information on internationalization and multibyte data support.
With Oracle Access Manager 11g, credential collection occurs using the HTTP(S) channel; authorization occurs over the NetPoint Access Protocol (NAP) channel (also referred to as the Oracle Access Manager Protocol (OAP) channel).
HTTP(S) Channel: Oracle recommends enabling the secure sockets layer (SSL) for communication across the HTTP(S) channel to transport credentials and to exchange security tokens. Both functions require signing or encryption with certificates.
Oracle Access Manager 11g provides a central component to manage certificates used across all Oracle Access Manager components, including Webgates.
NAP Channel: Also known as the OAP Channel. Oracle recommends using either Simple (Oracle-signed certificates) or Cert mode (outside certificate authority) to secure communication between Webgates and OAM Servers during authorization. Oracle provides a certificate import utility that you can use when you have signed certificates. For information, see Appendix E, "Securing Communication for Oracle Access Manager 11g". See also:
Note:Oracle Access Manager 11g does provide support for customers who use self-signed certificates.
Only administrators can use custom WebLogic Scripting Tool (WLST) commands to perform certain configuration tasks.
For more information, see Appendix F, "Introduction to Custom WLST Commands for Administrators".
Oracle Access Manager supports Internet Protocol Version 4 (IPv4). Oracle Fusion Middleware supports Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6). IPv6 is enabled with Oracle HTTP Server with the mod_wl_ohs plug-in.
For more information, see Appendix G, "Configuring OAM 11g for IPv6 Clients".
Oracle Application Server Single Sign-On provides a framework for integrating deployment-specific login, change password, and single sign-off pages with the single sign-on server. This means that you can tailor these pages to your UI look and feel and globalization requirements.
For more information, see Appendix H, "Creating Deployment-Specific Pages"
For tips and troubleshooting information, see Appendix I, "Troubleshooting".