Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Access Management
11g Release 2 (11.1.2.1)

Part Number E27239-13
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

23 Registering and Managing 10g Webgates with Access Manager 11g

The Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management describes initial deployment of Access Manager 11g with the Oracle HTTP Server. However, when your enterprise includes Web server types other than Oracle HTTP Server you might want to use existing 10g Webgates or install fresh 10g Webgates for use with Access Manager. Also, you might want to switch from using the pre-registered IAMSuiteAgent to using a 10g Webgate to protect Oracle Identity Management Consoles.

The following sections describe how to install fresh instances of 10g Webgates for use with Access Manager:

23.1 Prerequisites

Review the latest certification matrix from Oracle Technology Network to locate the latest Webgates for your deployment:

http://www.oracle.com/technology/products/id_mgmt/coreid_acc/pdf/oracle_access_manager_certification_10.1.4_r3_matrix.xls

Ensure that your Oracle Access Management Console is running and get familiar with:

23.2 Introduction to 10g OAM Agents for Access Manager 11g

This section provides the following topics:

23.2.1 About IAMSuiteAgent: A Pre-Configured 10g Webgate Registered with Access Manager

IAMSuiteAgent is a Java agent filter that is pre-registered with Access Manager 11.1.2 out of the box. This agent and the companion Application Domain are installed pre-configured with Access Manager.

The IAMSuiteAgent is a domain-wide agent:

  • Once Access Manager is deployed, the IAMSuiteAgent is installed on every server in the domain

  • Unless disabled, every request coming into the WebLogic Application Server is evaluated and processed by the IAMSuiteAgent

  • Certain IAMSuiteAgent configuration elements are available in the WebLogic Administration Console (in the Security Provider section) and others in the Oracle Access Management Console.

IAMSuiteAgent and related policies provide SSO protection for the IDM Administration Console, Oracle Identity Console, Oracle Access Management Console, and specific resources in the Identity Management domain.

You can replace the IAMSuiteAgent with a 10g Webgate to protect Oracle Identity Management Consoles and resources in the Identity Management domain, if you choose.

23.2.2 About Legacy Oracle Access Manager 10g Deployments and Webgates

11g OAM Servers support 10g Webgates that are registered to operate with Access Manager 11.1.2. Such Webgates might include:

  • Legacy 10g Webgates currently operating with Oracle Access Manager 10g.

  • Legacy 10g Webgates configured as the Identity Assertion Provider (IAP) for SSO (for applications using IAP WebLogic container-based security with Oracle Access Manager 10g, as described in the Oracle Fusion Middleware Application Security Guide).

  • Legacy 10g Webgates currently operating with Web Applications coded for Oracle ADF Security and the OPSS SSO Framework

You can register these agents to use Access Manager SSO using either the Oracle Access Management Console or the remote registration tool. After registration, 10g Webgates directly communicate with Access Manager through a JAVA-based OAM Proxy that acts as a bridge.

The following overview outlines the tasks that must be performed to set up an existing 10g Webgate to operate with Access Manager.

Task overview: Setting up a legacy 10g Webgate to operate with Access Manager

  1. Registering a 10g Webgate with Access Manager 11g Remotely

  2. Configuring Centralized Logout for 10g Webgate with 11g OAM Servers

  3. Optional: Deploying Applications in a WebLogic Container as described in the Oracle Fusion Middleware Application Security Guide.

23.2.3 About Installing Fresh 10g Webgates to Use With Access Manager 11.1.2

You can install fresh 10g Webgates for use with Access Manager 11g as described in this chapter. 10g Webgates are available for a number of Web server platforms.

After installation and registration, 10g Webgates directly communicate with Access Manager through a JAVA-based OAM proxy that acts as a bridge.

Note:

When installing fresh 10g Webgates for Access Manager, Oracle recommends that you use the latest Webgates. Oracle also recommends that you install multiple Webgates for failover and load balancing.

There are several differences between installing a 10g Webgate to operate in an 11g Access Manager deployment versus installing the 10g Webgate in an 10g Oracle Access Manager deployment. Table 23-1 outlines these differences.

Table 23-1 Installation Comparison with 10g Webgates

10g Webgates in 11g Deployments 10g Webgates in 10g Deployments
  1. Packages: 10g Webgate installation packages are found on media and virtual media that is separate from the core components.

  2. Provisioning: Before installation, provision Webgate with Access Manager 11g as described in "Registering a 10g Webgate with Access Manager 11g Remotely".

  3. Associating with OAM Server: Occurs during Webgate registration (task 2 of this sequence).

  4. Installing: Install the 10g Webgate in front of the application (or for Fusion Middleware, in front of the WebLogic Server).

  5. Language Packs: 10g Webgate Language Packs are supported with Access Manager.

  6. Web Server Configuration: Copy Access Manager generated files to the Webgate installation directory path to update the Web server configuration.

  7. Certificate Installation: Copy files to the Webgate installation directory path.

  8. Forms: 10g forms provided with 10g Webgates cannot be used with 11g OAM Servers.

    Using 10g Webgates with 11g OAM Servers is similar in operation and scope to a resource Webgate (one that redirects in contrast to the Authentication Webgate). With a 10g Webgate and 11g OAM Server, the 10g Webgate always redirects to the 11g credential collector which acts like the authenticating Webgate.

  9. Single Log Out: Configure using information in Chapter 20, "Configuring Centralized Logout for Sessions Involving 11g Webgates".

  10. Multi-Domain Support: Does not apply with Access Manager 11g.

  1. Packages: 10g Webgate installation packages are found on media and virtual media that is separate from the core components.

  2. Provisioning: Before installation, you create a Webgate instance in the Access System Console.

  3. Associating with AAA: Before installation, you associated the Webgate with an Access Server in the Access System Console.

  4. Installing: Using 10g Webgate packages.

  5. Language Packs: 10g Webgate Language Packs could be installed during Webgate installation (or later).

  6. Web Server Configuration: Automatic during Webgate installation (or manually after Webgate installation).

  7. Certificate Installation: You copied files to the Webgate installation directory path.

  8. Forms: Were provided for use in 10g deployments.

  9. Centralized Log Out for Oracle Access Manager 10g.

  10. Multi-Domain Support: Could be configured for Oracle Access Manager 10g.


The following overview lists the topics in this chapter that describe 10g Webgate installation and registration tasks for Access Manager 11g in detail. You must complete all procedures for successful operation with Access Manager 11g.

Task overview: Registering and installing a 10g Webgate for Access Manager 11g

  1. Registering a 10g Webgate:

  2. Locating and Downloading 10g Webgates for Use with Access Manager 11g

  3. Configuring Centralized Logout for 10g Webgate with 11g OAM Servers

  4. Optional: Deploying Applications in a WebLogic Container as described in Oracle Fusion Middleware Application Security Guide.

23.2.4 About Centralized Logout with 10g OAM Agents and 11g OAM Servers

Logout is initiated when an application causes the invocation of the logout.html file configured for any registered 10g Webgate.

Generally speaking, during centralized logout with 10g Webgates the SSO Engine receives a user-session-exists request. The Session Management Engine looks up the session and responds that the session exists. The SSO engine sends a Clear Session request. The Session management engine clears the token and session context. The SSO engine sends a Session Cleared response.

Clearing the user token and the session context clears the server-side state, which includes clearing the OAM_ID cookie set on the server side. When the agent is notified, the agent clears the client-side state of the application. For more information, see "Configuring Centralized Logout for 10g Webgate with 11g OAM Servers".

23.3 Comparing Access Manager 11.1.2 and 10g

This topic provides a comparison against the 10g architecture for Access Manager and OSSO. Included are the following topics:

23.3.1 Comparing Access Manager 11g versus 10g

Access Manager 11g differs from 10g in that the identity administration features have been transferred to Oracle Identity Manager 11g (including user self-service and self registration, workflow functionality, dynamic group management, and delegated identity administration).

Access Manager 10g supported Single Sign-on using a single session cookie (the ObSSOCookie) that contained the user identity and session information required to access target resources that had the same or lower authentication level. The ObSSOCookie was encrypted and decrypted using a global shared secret key, the value of which was stored in the directory server. The ObSSOCookie was consumed by Access System components to verify the user identity and allow or disallow access to protected resources.

To close any possible security gaps, Access Manager 11g provides new server-side components that maintain backward compatibility with existing Access Manager 10g policy-enforcement agents (Webgates) and OSSO 10g agents (mod_osso). New Access Manager 11g Webgates are enhanced versions of 10g Webgates, that support a per-agent secret key for the Single Sign-on (SSO) solution. Thus, cookie-replay type of attack are prevented. The 11g Webgates are all trusted at the same level; a cookie specific for the Webgate is set and cannot be used to access any other Webgate-protected applications on a user's behalf.

Unless explicitly stated, the term "Webgate" refers to both an out of the box Webgate or a custom Access Client.

Access Manager 11g uses technology from Oracle Coherence to provide centralized, distributed, and reliable session management.

Table 23-2 provides a comparison of Access Manager 11g versus 10g. For a list of names that have changed with Access Manager 11g, see "Product and Component Name Changes with 11.1.2".

Table 23-2 Comparison: Access Manager 11g versus 10g


Access Manager 11g 10g

Agents

  • Agents: Webgate, Access Client, OpenSSO, OSSO (mod_osso), IAMSuiteAgent

Note: Eight Administrator languages are supported.

  • Resource Webgate (RWG)

  • Authentication Webgate (AWG)

  • AccessGate

  • Access Server

  • Policy Manager

  • Identity System

Note: Eight Administrator languages are supported.

Server-side components

  • OAM Server (installed on a WebLogic Managed Sever)

    Security Token Service and Identity Federation run on OAM Server

  • Access Server

  • Policy Manager

  • Identity Server

Console

Oracle Access Management Console

Access System Console

Identity System Console

Protocols that secure information exchange on the Internet

Front channel protocols exchanged between Agent and Server: HTTP/HTTPS.

11g Webgate secures information exchange using the Agent key.

-See Also: Cryptographic keys.

10g Agent information exchange is unsecured, in plain text.

Cryptographic keys

  • One per-agent secret key shared between 11g Webgate and OAM Server

  • One OAM Server key, generated during Server registration

Note: One key is generated and used per registered mod_osso agent.

One global shared secret key per Access Manager deployment which is used by all the 10g Webgates

Keys storage

  • Agent side: A per-agent key is stored locally in the Oracle Secret Store in a wallet file

  • OAM Server side: A per- agent key, and server key, are stored in the credential store on the server side

  • Security Token Service

Global shared secret stored in the directory server only (not accessible to Webgate)

Cookies

Host-based authentication cookie, described in Table 1-3, "Introduction: Access Manager 11.1.2"

  • One domain-based ObSSOCookie for all Webgates (including the AWG), for both authentication and session management

Encryption / Decryption (The process of converting encrypted data back into its original form)

Introduces client-side cryptography and ensures that cryptography is performed at both the agent and server ends:

  1. Webgate encrypts obrareq.cgi using the agent key.

    Note: obrareq.cgi is the authentication request in the form of a query string redirected from Webgate to OAM Server.

  2. OAM Server decrypts the request, authenticates, creates the session, and sets the server cookie.

  3. OAM Server also generates the authentication token for the agent (encrypted using the agent key), packs it in obrar.cgi with a session token (if using cookie-based session management), authentication token and other parameters, then encrypts obrar.cgi using the agent key.

    Note: obrar.cgi is the authentication response string redirected from the OAM Server to Webgate.

  4. Webgate decrypts obrar.cgi, extracts the authentication token, and sets a host-based cookie.

  • Token generation/ encryption, and validation/ decryption are delegated to the Access Server.

  • Both obrareq.cgi and obrar.cgi are sent unencrypted, relying on the underlying HTTP(S) transport for security.

Session Management

  • Single domain supported.

    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.

Client IP

  • Maintain this Client IP, and include it in the host- based OAMAuthnCookie.

  • Include the original client IP inside the ObSSOCookie.

    If IP validation is configured, when cookie presented in later authentication or authorization requests this original client IP is compared with the presenter's IP.

    Rejection occurs if there is no match

Response token replay prevention

  • Include RequestTime (the timestamp just before redirect) in obrareq.cgi and copy it to obrar.cgi to prevent response token replay.

N/A

Multiple network domain support

Cross-network-domain single sign-on out of the box.

Oracle recommends you use Oracle Federation for multiple network domain support.

A proprietary multiple network domain SSO capability predates Oracle Access Management Identity Federation. If this is implemented in your 10g deployment, register 10g Agents with Access Manager 11g to continue this support.

  • Single domain is supported.

    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.

Centralized log-out

  • The logOutUrls (10g Webgate configuration parameter) is preserved. 10g logout.html requires specific details for Access Manager 11g.

  • 11g Webgate parameters are new:

    Logout Redirect URL

    Logout Callback URL

    Logout Target URL

See Chapter 20.

logout.html requires specific details when using a 10g Webgate with Access Manager 11g. See Chapter 20.

  • Single domain is supported.

    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.


23.3.2 Comparing Access Manager 11g versus 10g Policy Model

Access Manager 11g default behavior is to deny access when a resource is not protected by a policy that explicitly allows access.

Access Manager 10g provides authentication and authorization based on policies within a policy domain. Access Manager 10g default behavior allowed access when a resource was not protected by a rule or policy that explicitly denied access to limit the number of Webgate queries to the Access Server.

Table 23-3 compares the Access Manager 11g policy model with the 10g model. Access Manager 11g default behavior is to deny access when a resource is not protected by a policy that explicitly allows access. In contrast, Access Manager 10g default behavior allowed access when a resource was not protected by a rule or policy that explicitly specified access.

Table 23-3 Comparing Access Manager 11g Policy Model versus 10g

Policy Elements 11g Policy Model 10g Policy Model

Policy Authoring

Oracle Access Management Console

Policy Manager

Policy Store

Database

LDAP directory server

Domain

Application Domain

Policy Domain

Resources

  1. No URL prefixes. Resource definitions are treated as complete URLs.

  2. Pattern matching (with limited features) for:

    ' * ' and '...' are supported

  3. Resources need not be unique across domains.

  4. Query-string protection for HTTP URLs.

  5. Each HTTP resource is defined as a URL path, and associated with a host identifier. However, resources of other types are associated with a specific name (not a host identifier).

  6. Non-HTTP resource types are supported, with definition of specific operations. Non-HTTP resource types are never associated with a host identifier.

  7. Resources can designated as either Protected, Unprotected, or Excluded.

  8. Custom resource types are allowed.

  1. URL prefixes are defined in domains

  2. Pattern matching for:

    { } * …

  3. Resources need not be unique across domains.

  4. http resources can be protected based on URL query string contents and/or HTTP operation.

  5. Non-HTTP resource types and operations can be defined.

Host identifiers

  1. Host Identifiers are defined outside of policies and are used while defining HTTP resources.

  2. Host Identifiers are mandatory for defining HTTP resources.

  1. Host Identifiers are defined outside of policies and are used while defining HTTP resources.

  2. Host Identifiers are not mandatory, for defining HTTP resources, till there are no Host Identifiers defined in the system.

Authentication Policies

  1. Authentication policies include resources, success responses, and an authentication scheme.

  2. Authorization policies can also contain success responses, and time based, IP based and user-based conditions.

  3. Only one authentication policy and one authorization policy can be associated with any resource.

  4. Authentication and Authorization policies can evaluate to Success or Failure.

  5. No Query Builder and no support for LDAP filters for (for retrieving matches based on an attribute of a certain display type, for example).

  6. There is no notion of a default policy in an Application Domain. However, you can define a policy for resource: /…/* which can be used as a default policy within a determined scope).

  7. Token Issuance Policies can be defined using resources and user- or partner-based conditions. See "About Token Issuance Policy Pages".

  1. Authentication policies are simple and contain only authentication-scheme-based rule.

  2. One resource can be associated with a set of Authorization policies. Evaluation of these policies can be based on an expression that combines the policies within the set using logical operators as desired.

    A resource can also be associated with multiple authentication policies and authorization policy sets. However, only one set applies.

  3. An Authorization policy can evaluate to Success or Failure, or Inconclusive.

  4. Users can be specified using LDAP filters.

  5. Default authentication policy and authorization policy set can be defined for a policy domain. This policy is only applicable if there are no other applicable policies for a runtime resource in that domain.

  6. There is no support for Token Issuance Policies.

Authentication Schemes

Authentication Schemes are defined globally and can be shared (referenced within authentication policies).

The trust level is expressed as an integer value between 0 (no trust) and 99 (highest level of trust).

Note: Level 0 is unprotected. Only unprotected resources can be added to an Authentication Policy that uses an authentication scheme at protection level 0.

See Also: Table 17-20, "Authentication Scheme Definition".

Authentication Schemes can be defined outside of policies and can be referenced within authentication policies.

Authorization Policy

Each resource assigned to an Application Domain can be protected by only one authorization policy. Each policy can include one or more conditions and a rule.

See Also: Rule, later in this table, and "Defining Authorization Policies for Specific Resources".

To protect resources, you define authorization rules that contain one or more conditions.You also configure authorization expressions using one or more authorization rules. A policy domain (and a policy) can each contain only one authorization expression.

Token Issuance Policy

By default, only a container for Token Issuance Policies is provided in a generated Application Domain. No Conditions or Rules are generated automatically. You must add these manually.

See Also: "About Token Issuance Policy Pages".

N/A

Responses

Available for all policy types:

  1. Authentication and Authorization success Responses can be defined within the policies. These are applied after evaluation of policies.

  2. Cookie, Header, and Session responses are supported.

  3. URL redirection can be set.

  4. Response definitions are part of each policy. Response values can be literal strings or can contain additional embedded expressions that derive values from request, user, and session attributes.

  1. Authentication and Authorization Responses can be defined within the policies for Success, Failure, and Inconclusive events. These are returned to the caller after evaluation of policies.

  2. HTTP_HEADER and Cookie based variables can be set.

  3. Redirect URLs can be set for Success and Failure events of authentication and authorization policy evaluations.

  4. Response values can contain literal strings and list of user attribute values.

Cookies

See Also: Table 16-8

and

"About Single Sign-On Cookies During User Login"

See Also: Table 16-8

and

"About Single Sign-On Cookies During User Login"

Query String-based HTTP Resource Definitions

Supported within Access Policies, as described in Table 18-1, "Resource Definition Elements"

This Policy Model supports query string-based HTTP resource definitions within Access Policies.

At run time, the OAM Proxy passes the Query String to the policy layer after URL encoding, just like for base resource URL. Only Query String that are part of HTTP GET requests are passed. Query String pattern does not apply to HTTP POST data.

Rule

Available for only Authorization and Token Issuance Policies.

Each Authorization policy includes a rule that defines whether the policy allows or denies access to resources protected by the policy.

The rule references Authorization conditions, described next.

See Also: "Introduction to Authorization Policy Rules and Conditions".

A policy is defined using authorization rules (among other policy elements). Authorization rules:

  • Are defined outside of policies (but scoped within a policy domain) and are referenced in policies.

  • Appear in two places: 1) as part of default rules for the domain and 2) in policy definitions.

Each rule specifies who (which users, groups or IP4 addresses) is allowed or denied access and the time period in which this rule applies.

There is also a provision to specify whether Allow takes precedence over Deny.

Condition

Available for only Authorization and Token Issuance Policies.

Each Authorization policy rule references conditions that define to whom the rule applies, if there is a time Condition, and how evaluation outcomes are to be applied.

Conditions are declared outside of rules and are referenced within a rule.

See Also: "Introduction to Authorization Policy Rules and Conditions".

N/A


23.4 Configuring Centralized Logout for IAMSuiteAgent

The IAMSuiteAgent is pre-configured with the logout parameters needed to perform central logout against the OAM Server. While similar to a 10g Webgate, the IAMSuiteAgent does not have a local logout.html page to be configured. Instead, the IAMSuiteAgent is delivered with a pre-deployed application oamsso_logout), that is used by the agent to perform the logout.

The logout functionality for the IAMSuiteAgent requires that the oamsso_logout application is deployed in the Server where the IAMSuiteAgent is used. The initial installation adds this application to AdminServer and to OAM Servers. However, you must update this application's Target servers to include all those that are using the IAMSuiteAgent.

To configure logout for the IAMSuiteAgent

  1. Log in to the WebLogic Server Administration Console.

  2. Navigate to Domain, Deployments, oamsso_logout, Targets.

  3. Select all the Servers where the IAMSuiteAgent is enabled and where logout is performed. For example, oim_server, oaam_admin, oaam_server, and so on.

  4. Click Save.

  5. Proceed to:

23.5 Registering a 10g Webgate with Access Manager 11g Remotely

Whether you have a legacy 10g Webgate installed, or you are installing a fresh 10g Webgate instance to use with Access Manager 11g, you must register Webgate to use Access Manager 11g authentication and authorization services.

You can use either the Oracle Access Management Console or the remote registration tool to perform this task. The remote registration tool enables you to specify all Webgate parameters before registration using a template.

The following procedure walks through provisioning using the remote registration tool, in-band mode. In this example, OAMRequest_short.xml is used as a template to create an agent named my-10g-agent1, protecting /.../*, and declaring a public resource, /public/index.html. Your values will be different. You can use a full registration template to specify public, private, and excluded resources.

See Also:

The following, if needed:

To use remote registration with a 10g Webgate for Access Manager 11g

  1. Acquire the remote registration tool and set up the script for your environment. For example:

    1. Locate RREG.tar.gz file in the following path:

      $ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz 
      
    2. Untar RREG.tar.gz file to any suitable location. For example: rreg/bin/oamreg.

    3. In the oamreg script (oamreg.bat or oamreg.sh), set the following environment variables based on your situation (client side or server side) and information in Table 14-5:


      OAM_REG_HOME = exploded_dir_for_RREG.tar/rreg
      JAVA_HOME = Java_location_on_the_computer
  2. Create the registration request:

    1. Locate OAMRequest_short.xml and copy it to a new file. For example:

      $OAM_REG_HOME/input/OAMRequest_short.xml/
      

      Copy: OAMRequest_short.xml

      To: my-10g-agent1.xml

    2. Edit my-10g-agent1.xml to include details for your environment. For example:

      <OAMRegRequest>
          <serverAddress>http://ruby.uk.example.com:7001</serverAddress>
          <hostIdentifier>my-10g</hostIdentifier>
          <agentName>my-10g-agent1</agentName>
          <autoCreatePolicy>true</autoCreatePolicy>
          <primaryCookieDomain>.uk.example.com</primaryCookieDomain>
          <logOutUrls>
            <url>/oamsso/logout.html</url>
          </logOutUrls>
      </OAMRegRequest>
      
  3. Register the agent. For example:

    1. Locate the remote registration script.


      Linux: rreg/bin/oamreg.sh

      Windows: rreg\bin\oamreg.bat

    2. From the directory containing the script, execute the script using inband mode. For example:

      $ ./bin/oamreg.sh inband input/my-10g-agent1.xml

      Welcome to OAM Remote Registration Tool!
      Parameters passed to the registration tool are:
      Mode: inband
      Filename: ...
      
    3. When prompted, enter the following information using values for your environment:

      Enter your agent username: userame
         Username:  userame
      Enter agent password: ********
      Do you want to enter a Webgate password?(y/n)
          n
      iv.     Do you want to import an URIs file?(y/n)
          n
      
    4. Review the final message to confirm that this was a successful registration:

      Inband registration process completed successfully! Output artifacts are 
      created in the output folder"
      
  4. Ignore the ObAccessClient.xml file created during registration for now.

  5. Log in to the Oracle Access Management Console and add resources the new registration:

    1. From the System Configuration tab, Access Manager section, expand the following nodes to reveal Search controls:


      System Configuration
      Access Manager
      SSO Agents
      OAM Agents
    2. Use the Search controls to locate your Webgate registration page, then click the name in the Results table to display the page.

    3. OAM Proxy Port—From the System Configuration tab, Common Configuration section, double click Server Instances and locate the port on which the OAM Proxy is running (Table 5-3).

  6. Add resources to the Application Domain (Table 18-1).

  7. Proceed as needed for your environment:

23.6 Managing 10g OAM Agents Remotely

This section describes how to update, validate, and delete OAM 10g Agents using remote registration templates and modes described in "Introduction to Updating Agents Remotely".

To remotely update OAM 10g Agent registration

  1. Set up the registration tool as described in, "Acquiring and Setting Up the Remote Registration Tool".

  2. Update Agent:

    1. Create your update request using the OAMUpdateAgentRequest.xml template.

    2. On the computer hosting the Agent, run the following command with agentUpdate mode specify your own *Request*.xml as the input file. For example:

      ./bin/oamreg.sh agentUpdate input/*OAMUpdateAgentRequest.xml
      
    3. Provide the registration Administrator user name and password when asked.

    4. Confirm success with on-screen messages.

    5. Relocate to the agent host ObAccessClient.xml:

      From the AdminServer (Console) host: /rreg/output/Agent_Name/

      To the Agent host: $10gWG_install_dir/oblix/lib. For example:


      $WebTier_MW_HOME/Oracle_WT1/instance1/ config/OHS/ohs1/oblix/lib
    6. Restart the OAM Server that is hosting this agent

  3. Validating Agent:

    1. On the Agent host, run the following command in agentValidate mode. For example:

      ./bin/oamreg.sh agentValidate agentname
      
    2. Provide the registration Administrator user name and password when asked.

    3. Confirm success with on-screen messages.

  4. Deleting an Agent:

    1. On the computer hosting the Agent, run the following agentDelete command. For example:

      ./bin/oamreg.sh agentDelete agentname
      
    2. Provide the registration Administrator user name and password when asked.

    3. Confirm success with on-screen messages.

      Success: On-screen message confirms

      AgentDelete process completed successfully!

23.7 Locating and Installing the Latest 10g Webgate for Access Manager 11g

Use the procedures in this section if you need to install a fresh 10g Webgate for use with Access Manager 11g. Otherwise, skip this section and proceed to "Configuring Centralized Logout for 10g Webgate with 11g OAM Servers".

Task overview: Installing the Webgate includes

  1. Preparing for a Fresh 10g Webgate Installation with Access Manager 11g

  2. Locating and Downloading 10g Webgates for Use with Access Manager 11g

  3. Starting Webgate 10g Installation

  4. Specifying a Transport Security Mode

  5. Specifying Webgate Configuration Details

  6. Requesting or Installing Certificates for Secure Communications

  7. Updating the Webgate Web Server Configuration

  8. Finishing Webgate Installation

  9. Installing Artifacts and Certificates

  10. Confirming Webgate Installation

23.7.1 Preparing for a Fresh 10g Webgate Installation with Access Manager 11g

Table 23-4 outlines the requirements that must be met before starting an 10g Webgate installation.

Table 23-4 Preparing for 10g Webgate Installation with Access Manager 11g

About the ... Description

Latest Supported Webgates

Always use the latest supported 10g (10.1.4.3) Webgates with Access Manager 11g. However, if the desired 10g (10.1.4.3) Webgate is not provided, use the next latest Webgate (10g (10.1.4.2.0).

See Also: "Locating and Downloading 10g Webgates for Use with Access Manager 11g"

Location for installation

Consider:

  • Webgate in front of the application server.

  • Applications using WebLogic Server container-managed security: In front of the WebLogic Application Server in which your application is deployed

User Accounts

The account that is used to install the Webgate is not the account that runs the Webgate:

  • The 10g Webgate should be installed using the same user and group as the Web server.

  • Unix: You can be logged in as root to install the Webgate. The Webgate can be installed using a non-root user if the Web server process runs as a non-root user

Root Level versus Site Level

  • The Webgate can be installed at the root level or the site level.

  • Installing Webgate on multiple virtual sites amounts to only one instance of Webgate.

Transport Security Mode

Ensure that at least one OAM Server is configured to use the same mode as the agent to be installed.

See Also Appendix C

Computer Level or Virtual Web Server Level

The Webgate can be configured to run at either the computer level or the virtual Web server level. Do not install at both the computer level and the virtual Web server levels.

Oracle HTTP Server Web Server:

The 10g Webgate for Oracle HTTP Server is based on open source Apache. Webgate package names include:

  • OHS (based on Apache v1.3)

  • OHS2 (based on Apache v2)

  • OHS11g (based on Apache v2.2 and is not the subject of this chapter)

Apache Web Servers

Access Manager 11g provides a single package for components that support Apache with or without SSL enabled:

  • The APACHE2_Webgate supports v2 with or without SSL (and with or without reverse proxy enabled on Solaris and Linux). See also Chapter 24

  • The APACHE22_Webgate supports v2.2 with or without SSL (and with or without reverse proxy enabled on Solaris and Linux). See also Chapter 24

Note: For SSL-enabled communication, Access Manager supports Apache with mod_ssl only, not Apache-SSL. mod_ssl is a derivative of, and alternative to, Apache-SSL.

IBM HTTP Server (IHS) v2 Web Servers:

IHS2_Webgate is powered by Apache v2 on IBM-AIX. Access Manager supports IHS v2 and IHS v2 Reverse Proxy servers with or without SSL enabled.

For details, see Chapter 24.

Domino Web Servers:

Before you install the 10g Webgate with a Domino Web server, you must have properly installed and set up the Domino Enterprise Server R5.

See Also: Chapter 27, "Configuring Lotus Domino Web Servers for 10g Webgates".

IIS Web Servers

Before installing Webgate, ensure that your IIS Web server is not in lock down mode. Otherwise things will appear to be working until the server is rebooted and the metabase re-initialized, at which time IIS will disregard activity that occurred after the lock down.

If you are using client certificate authentication, before enabling client certificates for the Webgate you must enable SSL on the IIS Web server hosting the Webgate.

Setting various permissions for the /access directory is required for IIS Webgates only when you are installing on a file system that supports NTFS. For example, suppose you install the ISAPI Webgate in Simple or Cert mode on a Windows 2000 computer running the FAT32 file system. The last installation panel provides instructions for manually setting various permissions that cannot be set on the FAT32 fleshiest. In this case, these instructions may be ignored.

Each IIS Virtual Web server can have it's own Webgate.dll file installed at the virtual level, or can have one Webgate affecting all sites installed at the site level. Either install the Webgate.dll at the site level to control all virtual hosts or install the Webgate.dll for one or all virtual hosts.

You may also need to install the postgate.dll file at the computer level. The postgate.dll is located in the \Webgate_install_dir, as described in "Installing the Postgate ISAPI Filter". If you perform multiple installations, multiple versions of this file may be created which may cause unusual Access Manager behavior. In this case, you should verify that only one webgate.dll and one postgate.dll exist.

See Also: Chapter 26, "Configuring the IIS Web Server for 10g Webgates"

Removal: To fully remove a Webgate and related filters from IIS, you must do more than simply remove the filters from the list in IIS. IIS retains all of its settings in a metabase file. On Windows 2000 and later, this is an XML file that can be modified by hand. There is also a tool available, MetaEdit, to edit the metabase. MetaEdit looks like Regedit and has a consistency checker and a browser/editor. To fully remove a Webgate from IIS, use MetaEdit to edit the metabase.

ISA Proxy Servers

On the ISA proxy server, all ISAPI filters must be installed within the ISA installation directory. They can be anywhere within the ISA installation directory structure:

  1. Before installing the Webgate on the ISA proxy server:

    Check for general ISAPI filter with ISA instructions on:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/isa/isaisapi_5cq8.asp
    

    Ensure that the internal and external communication layers are configured and working properly.

  2. During installation you will asked if this is an ISA installation; be sure to:

    Indicate that this is an ISA proxy server installation, when asked.

    Specify the ISA installation directory path as the Webgate installation path.

    Use the automatic Web server update feature to update the ISA proxy server during Webgate installation.

  3. After Webgate installation, locate the file configureISA4webgate.bat, which calls a number of scripts and the process to configure the ISA server filters that must be added programmatically.

See Also: Chapter 25, "Configuring the ISA Server for 10g Webgates"


23.7.2 Locating and Downloading 10g Webgates for Use with Access Manager 11g

Use the following procedure to obtain an 10g Webgate, if needed. Be sure to choose the appropriate installation package for your Web server.

To find and download 10g Webgates

  1. Review the latest Oracle Access Manager 10g certification information on the Oracle Technology Network at:

    http://www.oracle.com/technology/products/id_mgmt/coreid_acc/pdf/oracle_access_manager_certification_10.1.4_r3_matrix.xls
    
  2. Go to Oracle Fusion Middleware 11gR1 Software Downloads at:

    http://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html
    
  3. Click Accept License Agreement, at the top of the page.

  4. From the Access Manager Webgates (10.1.4.3.0) row, click the download link for the desired platform and follow on-screen instructions.

  5. Store the Webgate installer in the same directory with any 10g Access System Language Packs you want to install.

  6. Proceed to "Starting Webgate 10g Installation".

23.7.3 Starting Webgate 10g Installation

The following procedure walks through the steps, which are the same regardless of Web server type.

Installation options are identified and can be skipped if they do not apply to your environment. During Webgate installation, information is saved at specific points. You can cancel Webgate installation processing if needed. However, if you cancel Webgate installation after being informed that the Webgate is being installed, you must uninstall the component.

Note:

On HP-UX and AIX systems, you can direct an installation to a directory with sufficient space using the -is:tempdir path parameter. The path must be an absolute path to a file system with sufficient space.

To start Webgate 10g installation

  1. On the computer to host Webgate 10g, log in as a user with Web server Administrator privileges.

  2. Stop the Web server instance.

  3. Launch the Webgate installer for your preferred platform, installation mode, and Web server. For example:

    GUI Method:

    Windows— Oracle_Access_Manager10_1_4_3_0_Win32_API_Webgate.exe
    

    Console Method:

    Solaris—./ Oracle_Access_Manager10_1_4_3_0_sparc-s2_API_Webgate
    Linux—./ Oracle_Access_Manager10_1_4_3_0_linux_API_Webgate
    

    where API refers to the API used by your Web server (for example, ISAPI for IIS Web servers).

  4. Dismiss the Welcome screen; follow on-screen instructions with Administrator privileges.

  5. Specify the installation directory for the Webgate.

  6. Linux or Solaris: Specify the location of the GCC runtime libraries on this computer.

  7. Language Pack—Choose a Default Locale and any other Locales to install, then click Next.

  8. Record the installation directory name in the preparation worksheet if you haven't already, then click Next to continue.

    The Webgate installation begins, which may take a few seconds. On Windows systems, a screen informs you that the Microsoft Managed Interfaces are being configured.

    The installation process is not yet complete. You are asked to specify a transport security mode. At this point, you cannot go back to restate information.

  9. Specify the location where you unzipped the previously downloaded GCC libraries, if needed.

23.7.4 Specifying a Transport Security Mode

Transport security between at least one OAM Server must match.

See Also:

Appendix C

To specify a transport security mode

  1. Choose Open, Simple, or Cert for the Webgate.

  2. Proceed according to your specified transport security mode:

23.7.5 Requesting or Installing Certificates for Secure Communications

If your Access Manager 11g environment uses Open mode transport security, you can skip to "Updating the Webgate Web Server Configuration".

Webgate Certificate Request: Generates the request file (aaa_req.pem), which you must send to a root CA that is trusted by the OAM Server. The root CA returns signed certificates, which can then be installed for Webgate.

Requested certificates must be copied to the \Webgate_install_dir\access\oblix\config directory and then the Webgate Web server should be restarted.

See Also:

Appendix C

To request or install certificates for Webgate 10g

  1. Indicate whether you are requesting or installing a certificate, then click Next and continue. For example:

    • Requesting a certificate, proceed with step 2.

    • Installing a certificate, skip to step 3.

  2. Request a Certificate:

    • Enter the requested information, then click Next and issue your request for a certificate to your CA.

    • Record certificate file locations, if these are displayed.

    • Click Yes if your certificates are available and continue with step 3. Otherwise, skip to "Updating the Webgate Web Server Configuration".

  3. Install a Certificate During Installation: Specify the full paths to the following files, then click Next:

    Webgate_install_dir\access\oblix\config

    • cacert.pem the certificate request, signed by the Oracle-provided openSSL Certificate Authority

    • password.xml contains the random global passphrase that was designated during installation, in obfuscated format. This is used to prevent other customers from using the same CA. Access Manager performs an additional password check during the initial handshake between the OAM Agent and OAM Server.

    • aaa_key.pem contains your private key (generated by openSSL).

    • aaa_cert.pem signed certificates in PEM format.

    • Proceed to "Updating the Webgate Web Server Configuration".

23.7.6 Specifying Webgate Configuration Details

You perform the following task using information provided during Webgate provisioning and registration with Access Manager 11g.

To provide Webgate configuration details

  1. Provide the information requested for the Webgate as specified in the Access System Console.

    • Webgate ID—Enter the agent name that you supplied during registration.

    • Webgate password—Enter the password supplied during registration, if any. If no password was entered, leave the field blank.

    • Access Server ID—Enter the name of the OAM Server with which this Webgate is registered, if desired, or use any name you choose.

    • Access Server Host Name—Enter the DNS host name for the OAM Server with which this Webgate is registered

    • Port number—Enter the port on which the OAM Proxy is running. If a port was not entered during provisioning, the default port is 3004.

  2. Click Next to continue.

23.7.7 Updating the Webgate Web Server Configuration

Your Web server must be configured to operate with the Webgate. Oracle recommends automatically updating your Web server configuration during installation. However, procedures for both automatic and manual updates are included.

Note:

To manually update your Web server configuration

  1. Click No when asked if you want to proceed with the automatic update, then click Next.

  2. Review the screen that appears to assist you in manually setting up your Webgate Web server, and see "Manually Configuring Your Web Server".

  3. Return to the Webgate installation screen, click Next, and proceed to "Registering a 10g Webgate with Access Manager 11g Remotely".

To automatically update your Web server configuration

  1. Click Yes to automatically update your Web server then click Next (or click No and see "Manually Configuring Your Web Server"):

    • Most Web servers—Specify the absolute path of the directory containing the Web server configuration file.

    • IIS Web Servers—The process begins immediately and may take more than a minute. For more information, see Chapter 26, "Configuring the IIS Web Server for 10g Webgates".

      You might receive special instructions to perform before you continue. Setting various permissions for the /access directory is required for IIS Webgates only when you are installing on a file system that supports NTFS. The last installation panel provides instructions for manually setting various permissions that cannot be set on the FAT32 file system. In this case, these instructions may be ignored.

    • Sun Web Servers—Be sure to apply the changes in the Web server Administration console before you continue.

    A screen announces that the Web server configuration has been updated.

  2. Click Next and continue with "Finishing Webgate Installation".

23.7.7.1 Manually Configuring Your Web Server

If, during Webgate installation, you declined automatic Web server updates, you must perform the task manually.

Note:

If the manual configuration process was launched during Webgate installation, you can skip Step 1 in the following procedure.

To manually configure your Web server for the Webgate

  1. Launch your Web browser, and open the following file, if needed. For example:

    \Webgate_install_dir\access\oblix\lang\langTag\docs\config.htm

    where \Webgate_install_dir is the directory where you installed the Webgate.

    Note:

    If you choose manual IIS configuration during 64-bit Webgate installation, you can access details in the following path

    Webgate_install_dir\access\oblix\lang\en-us\docs\dotnet_isapi.htm

  2. Select from the supported Web servers and follow all instructions, which are specific to each Web server type, as you:

    • Make a back up copy of any file that you are required to modify during Webgate set up, so it is available if you need to start over.

    • Ensure that you return to and complete all original setup instructions to enable your Web server to recognize the appropriate Access Manager files.

      Note:

      If you accidentally closed the window, return to step 1 and click the appropriate link again. Some setups launch a new browser window or require you to launch a Command window to input information.

  3. Continue with "Finishing Webgate Installation".

23.7.8 Finishing Webgate Installation

The ReadMe information provides details about documentation and Oracle.

Note:

If you are installing a 64-bit IIS Webgate, see "Finishing 64-bit Webgate Installation".

To finish the Webgate installation

  1. Review the ReadMe information, then click Next to dismiss it.

  2. Click Finish to conclude the installation.

  3. Restart your Web server to enable configuration updates to take affect.

    • IIS Web Servers—Consider using net stop iisadmin and net start w3svc after installing the Webgate to help ensure that the Metabase does not become corrupted.

    • Security-Enhanced Linux: Run the chcon commands for the Webgate you just installed on this platform.

  4. Proceed with following topics before installing artifacts and certificates:

  5. Proceed to "Installing Artifacts and Certificates".

23.7.9 Installing Artifacts and Certificates

The ObAccessClient.xml file is one result of product of provisioning. After Webgate installation, you must copy the file to the Webgate installation directory path. If you received signed Webgate 10g certificates after installing Webgate, you can use the following procedure to install these as well.

Prerequisites

Configuring your Web server

To install artifacts (and certificates) for Webgate 10g

  1. Gather Webgate 10g provisioning artifacts (and certificate files, if needed). For example:

    • ObAccessClient.xml

    • password.xml (if needed)

    • aaa_key.pem (your private key generated by openSSL).

    • aaa_cert.pem (signed certificates in PEM format)

  2. Copy the files to the Webgate host: Webgate_install_dir\access\oblix\config.

  3. Restart the Webgate Web server.

23.7.10 Confirming Webgate Installation

After Webgate installation and Web server updates, you can enable Webgate diagnostics to confirm that your Webgate is running properly.

To review Webgate diagnostics

  1. Confirm Access Manager 11g components are running.

  2. Specify the following URL for Webgate diagnostics. For example:

    Most Web Servers—http(s)://hostname:port/access/oblix/apps/webgate/bin/webgate.cgi?progid=1

    IIS Web Servers—http(s)://hostname:port/access/oblix/apps/ webgate/bin/webgate.dll?progid=1

    where hostname refers to the name of the computer hosting the Webgate; port refers to the Web server instance port number.

  3. The Webgate diagnostic page should appear.

23.8 Configuring Centralized Logout for 10g Webgate with 11g OAM Servers

This section provides the following topics:

23.8.1 About Centralized Logout Processing for 10g Webgate with 11g OAM Server

The following process overview outlines the Access Manager centralized logout process that occurs when the application is deployed on the Web server for which the protecting 10g Webgate is configured.

Logout is initiated when an application causes the invocation of the logout.html file configured for the OAM agent (in this case, a 10g Webgate).

Process overview: Centralized logout for 10g Webgate with 11g OAM Server

  1. The application causes invocation of the logout.html file configured for the 10g Webgate.

    The application might also pass end_url as a query string to logout.html. The end_url parameter could either be a URI or a URL. For example:

    /oamsso/logout.html?end_url=/welcome.html
    or
    /oamsso/logout.html?end_url=http://my.site.com/welcome.html
    
  2. Webgate clears the ObSSOCookie for its domain and loads the logout.html script.

  3. If the end_url parameter does not include host:port, the logout.html script gets the host:port of the local server and constructs the end_url parameter as a URL. For example:

    http://serverhost:port/oam/server/logout?end_url=http://my.site.com/ 
    welcome.html
    
  4. Logic in logout.html redirect to the OAM Server. For example:

    http://myoamserverhost:port/oam/server/logout?end_url=http://my.site.com/
    welcome.html
    
  5. The OAM Server executes logout as follows:

    1. Cleans up the session information associated with the user at the server side.

    2. Validates the end_url and sends a page with callback URLs to the user's browser.

      Note:

      The Logout Callback URL is specified in the expanded OAM Agent registration page, as described in "About Create OAM Webgate Page and Parameters" (or remote registration template in Table 14-3, "Elements on Expanded 11g and 10g Webgate/Access Client Registration Pages").

    3. From the callback page, a new request is initiated to a specific URI on each Webgate. When this request reaches the specific Webgate in the specific domain, the ObSSOCookie for that domain is cleared.

    4. The user is redirected to the end_url in the logout script. However, if the end_url parameter is not present, an appropriate message is sent by the OAM Server.

For more information, see "About the Centralized Logout Script for 10g Webgates with 11g OAM Servers".

23.8.2 About the Centralized Logout Script for 10g Webgates with 11g OAM Servers

With an 10g Webgate, the logout.html script is required for both single- and multiple DNS-domain centralized logout processing. The logout.html activates JavaScripts that perform the actual logout.

Note:

11g Webgates do not use the logout.html script and instead require additional details in their Agent registration configuration, as described in "Configuring Centralized Logout for 10g Webgate with 11g OAM Servers".

Example 23-1 is a logout.html script that you can use as a template by editing certain lines for your own environment, which are described at the top of the script. For instance, SERVER_LOGOUTURL must be changed. Additional information is provided after the example.

Example 23-1 logout.html Script

<html>
<head>
<script language="javascript" type="text/javascript">
///////////////////////////////////////////////////////////////////////////////
//Before using, you need to change the values of:
//a. "oamserverhost" to point to the host where the OAM Server is running.
//b. "port" to point to the port where the OAM Server is running.
///////////////////////////////////////////////////////////////////////////////
var SERVER_LOGOUTURL = "http://oamserverhost:port/oam/server/logout";
///////////////////////////////////////////////////////////////////////////////

function handleLogout() {

    //get protocol used at the server (http/https)
    var webServerProtocol = window.location.protocol;
    //get server host:port
    var webServerHostPort = window.location.host;
    //get query string present in this URL
    var origQueryString = window.location.search.substring(1);
    var newQueryString = "";

    //vars to parse the querystring
    var params = new Array();
    var par = new Array();
    var val;

    if (origQueryString != null && origQueryString != "") {
        params = origQueryString.split("&");
        for (var i=0; i<params.length; i++) {
          if (i == 0)
            newQueryString = "?";

        if (i > 0)
            newQueryString = newQueryString + "&";

        par = params[i].split("=");

        //prepare a new query string, if the end_url value needs to be changed
        newQueryString = newQueryString + (par[0]);
        newQueryString = newQueryString + "=";
        val = par[1];

        if ("end_url" == par[0]) {
        //check if val (value of end_url) begins with "/" or "%2F" (is it an URI?)
        if (val.substring(0,1) == "/" || val.substring(0,1) == "%") {
                //modify the query string now
                val = webServerProtocol + "//" + webServerHostPort + val;
            }
        }  
        newQueryString = newQueryString + val;
    }
    }
    //redirect the user to this URL
    window.location.href = SERVER_LOGOUTURL + newQueryString;
}
</script>
</head>

<body onLoad="handleLogout();">

</body>
</html>

Process overview: Logic in logout.html

  1. Gets the host and port from the incoming request.

  2. Gets the end_url parameter from the query string.

    If the end_url parameter is not a URL, then the logout.html script constructs a URL using the host and port from task 1. See "Guidelines for the end_url parameter in logout.html".

  3. Redirects to the OAM Server logout URL (SERVER_LOGOUTURL). For example: http://myoamserver/host:port/oam/server/logout.

    • Use the end_url constructed in process 2 as the query string.

    • Preserve all other query string parameters in the query string

Guidelines for the end_url parameter in logout.html

The end_url parameter can be either a URI or an URL.

  • If the end_url query string is a URI, without host and port, then the logout.html must construct the URL by determining the host and port of the Web Server where logout.html is hosted. For example:

    http://myoamserverhost:port/oam/server/logout?end_url=http://my 
    .site.com/welcome.html
    
  • If the end_url parameter is a URL with the host and port, the logout.html script simply passes that on without reconstructing it.

Note:

An ADF application must pass the end_url parameter indicating where to redirect the user after logout, as described in "Configuring Centralized Logout for Oracle ADF-Coded Applications":

/<app context root>/adfAuthentication?logout=true&end_url=<any uri>

Table 23-5 illustrates how a logout link in the logout.html file might be specified:

Table 23-5 Sample end_url Parameter Specifications

As a ... Sample end_url Value

URI

/oamsso/logout.html?end_url=<someUri>

For example:

/oamsso/logout.html?end_url=/welcome.html

URL

/oamsso/logout.html?end_url=<someUrl>

For example:

/oamsso/logout.html?end_url=http://my.site.com/welcome.html

23.8.3 Configuring Centralized Logout for 10g Webgates with Access Manager

The following procedures describe how to configure centralized logout for 10g Webgates with Access Manager.

Note:

Optional tasks or those required for only multiple DNS domain logout are identified and can be skipped unless needed.

Oracle Fusion Middleware Application Security Guide includes a sample procedure that includes steps for deploying an application in a WebLogic Server domain.

Task overview: Configuring centralized logout for 10g Webgates

  1. Create a default logout page (logout.html) and make it available on the Webgate installation directory:

    1. Create and edit logout.html for the Webgate based on Example 23-1, "logout.html Script".

    2. Store your logout.html script in the following directory path:

      Webgate_install_dir/oamsso/logout.html
      

      Note:

      If the logout.html file is located elsewhere, ensure that the logout link is correctly specified in the agent registration to point to the correct location of the logout.html file.

    3. Proceed with following steps, as needed.

  2. Ensure that the logout.html (from Step 1) redirects the user to this central logout URI, "/oam/server/logout' on the 11g OAM Server.

  3. Optional: Allow the application to pass the end_url parameter indicating where to redirect the user after logout, as described in "Guidelines for the end_url parameter in logout.html".

  4. Check the Web server file for which the 10g Webgate is configured and perform the appropriate step:

    • OHS Web server, httpd.conf file: If the following lines exist, delete them:

      <LocationMatch "/oamsso/*">
      Satisfy any
      </LocationMatch>
      
    • Other Web servers, configuration file: Add the following line:

      Alias /oamsso "WebgateInstallationDirectory/oamsso"
      

23.9 Removing a 10g Webgate from the Access Manager 11g Deployment

Use the following procedure to remove the 10g Webgate from the Access Manager 11g deployment, if needed.

Note:

Deleting an agent registration does not remove the associated host identifier, Application Domain, resources, or the agent instance.

Considerations

Web Server Configuration Changes: Web server configuration changes must be manually reverted after uninstalling the Webgate). For more information about what is added, see the appropriate chapter for your Web server.

Webgate IIS Filters: To fully remove a Webgate and related filters from IIS, you must do more than simply remove the filters from the list in IIS. IIS retains all of its settings in a metabase file. On Windows 2000 and later, this is an XML file that can be modified by hand. For more information, see "Removing a 10g Webgate from the Access Manager 11g Deployment".

Prerequisites

Evaluate the Application Domain, resources, and policies associated with this agent and ensure that these are configured to use another agent or that they can be removed.

To uninstall the 10g Webgate

  1. Turn off the Web server for the Webgate you will remove.

    Note:

    If you don't turn off the Web server, uninstall might fail and the backup folder will not be removed. If this happens, you need to manually remove the backup folder.

  2. On the Webgate registration page in the Oracle Access Management Console, click the Disable box beside the State option to disable the Webgate.

  3. Language Packs: Remove installed Language Packs (except the one selected as the default Administrator language (locale)) as follows:

    • Locate the appropriate Language Pack file in the component's uninstall directory. For example:


      Webgate_install_dir\uninstIdentityLP_fr-fr
      \uninstaller.exe
    • Run the Language Pack Uninstaller program to remove the files.

    • Repeat this process to remove the same Language Pack from associated components.

    • Stop and restart Webgate Web server to re-initialize proper language support.

    • Repeat this process to remove each Language Pack (except the one selected as the default Administrator language (locale)).

  4. Perform the following steps to remove 10g Webgate configuration data:

    • If you have only one instance of an Access Manager component, complete step 4 to remove it.

    • If you have multiple instances of a component, see also step 5.

  5. Locate and run the Uninstaller program for the specific component to remove Access Manager files. For example:

    Webgate_install_dir\access\_uninstWebgate\uninstaller.exe

    Note:

    On UNIX systems, use uninstaller.bin

  6. Multiple Instances: If you have multiple Webgate instances and want to remove one or all of them, you must use a specific method for your platform:

    • Windows: The last component can be uninstalled from Add/Remove programs. Others can be uninstalled by running the uninstall program from the \access \uninstComponent directory.

    • UNIX: You must always run uninstaller.bin.

  7. Remove Access Manager-related updates to your Web server configuration. For details about specific Web servers, see Chapter 24, Chapter 26, Chapter 25, Chapter 27.

  8. Restart the Web server.

  9. Remove the Webgate_install_dir directory if it remains, especially if you plan to reinstall it.