ca api management under the xml security ... the ca api gateway policy ... installing the ca single...

CA API Management

CA API Gateway Custom Assertions Installation Manual

Revision 3.8

Copyright © 2015 CA. All rights reserved.

This documentation and any related computer software help programs (hereinafter referred to as the “Documentation”) are for your informational purposes only and are subject to change or withdrawal by CA at any time.

This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. This Documentation is confidential and proprietary information of CA and may not be disclosed by you or used for any purpose other than as may be permitted in a separate confidentiality agreement between you and CA.

Notwithstanding the foregoing, if you are a licensed user of the software product(s) addressed in the Documentation, you may print a reasonable number of copies of the Documentation for internal use by you and your employees in connection with that software, provided that all CA copyright notices and legends are affixed to each reproduced copy.

The right to print copies of the Documentation is limited to the period during which the applicable license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed.

TO THE EXTENT PERMITTED BY APPLICABLE LAW OR AS AGREED BY CA IN ITS APPLICABLE LICENSE AGREEMENT, CA PROVIDES THIS DOCUMENTATION “AS IS” WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF M6ERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO THE END USER OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE.

The use of any software product referenced in the Documentation is governed by the applicable license agreement and such license agreement is not modified in any way by the terms of this notice.

The manufacturer of this Documentation is CA.

Provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government is subject to the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.227-7014(b)(3), as applicable, or their successors.

Contents List of Tables ....................................................................................................................... ii

Chapter One: Overview ........................................................................................................1 About This Guide ............................................................................................................................. 1 About Custom Assertions................................................................................................................ 1

Compatibility ............................................................................................................................. 1 Available Custom Assertions ................................................................................................... 2

Upgrading a Gateway with Custom Assertions .............................................................................. 3 Audience Assumptions ................................................................................................................... 3 Technical Assumptions ................................................................................................................... 3 User Documentation for Custom Assertions ................................................................................. 3

Chapter Two: Installing the CA Single Sign-On R12 Assertion .............................................5 Gateway Agent Settings .................................................................................................................. 5 Requirement .................................................................................................................................... 5 Configure the Gateway .................................................................................................................... 5

Step 1: Install the CA Single Sign-On R12 Custom Assertion ................................................ 6 Step 2: Register a Trusted Host .............................................................................................. 6 Step 3: Configure the Gateway Agent ..................................................................................... 7

Chapter Three: Installing the Tivoli Access Manager Assertion ........................................ 11 Requirements ................................................................................................................................ 11 Install Prerequisite Files ............................................................................................................... 12 Install Policy Director .................................................................................................................... 12 Configure TAM Runtime Environment (Single Gateway Instance) ............................................. 13

Register TAM Client ................................................................................................................ 14 Install TAM Custom Assertion................................................................................................ 15

Configure TAM Runtime Environment (Multiple Gateway Instances) ........................................ 16 Install Multiple TAM Instances .............................................................................................. 16 Install TAM Custom Assertion................................................................................................ 18 Update TAM Agent Properties ............................................................................................... 18

Chapter Four: Installing the Symantec Virus Scanning Assertion .................................... 21 Requirements ................................................................................................................................ 21 Configure Symantec Antivirus Engine .......................................................................................... 21 Configure the Gateway .................................................................................................................. 22

Install the Custom Assertion ................................................................................................. 22 Configure the Custom Assertion ........................................................................................... 22

Chapter Five: Installing the Sun Java System Access Manager Assertion ....................... 23 Requirements ................................................................................................................................ 23 Configure the Gateway .................................................................................................................. 23

Install the Custom Assertion ................................................................................................. 24 Edit the Properties Files......................................................................................................... 24

Chapter Six: Installing the Sophos Antivirus Assertion ..................................................... 27 Requirements ................................................................................................................................ 27 Install the Assertion ...................................................................................................................... 27

i

Chapter Seven: Installing the Oracle Access Manager Assertion .................................... 29

Requirements ................................................................................................................................ 29 Install the Assertion ...................................................................................................................... 29

Configure System Property for OAM 10g Server .................................................................. 30 Configure 10g Webgate for OAM 11g Server ....................................................................... 30

Configure Connection with OAM 11g Server ............................................................................... 31 Step 1: Register a Webgate ................................................................................................... 31 Step 2: Set File Permissions ................................................................................................. 32 Step 3: Restart Gateway and ORS Service ........................................................................... 32

Configure Connection with OAM 10g Server ............................................................................... 33 Run the OAM RMI Service............................................................................................................. 33

Chapter Eight: Installing the Execute Salesforce Operation Assertion ............................. 35 Requirements ................................................................................................................................ 35 Install the Assertion ...................................................................................................................... 35

Appendix A: Contacting CA Technologies.......................................................................... 37 Technical Support ......................................................................................................................... 37 Contact Information ...................................................................................................................... 37

List of Tables Table 1: Agent configuration - new installation .................................................................................... 7 Table 2: Editing the sun-jsam-client.properties file ............................................................................ 24 Table 3: Configuration files for registering a 10g Webgate ............................................................... 31 Table 4: CA Technical Support contact numbers ............................................................................... 37 Table 5: CA Technologies contact information ................................................................................... 37

ii

Custom Assertion Installation Manual, Rev3.8

Chapter One: Overview

About This Guide This Guide provides:

• General information about the custom assertions available for the Gateway.

• Installation and configuration requirements and instructions for each custom assertion.

This Guide does not provide detailed information about the custom assertions. For more information and user instructions, please refer to the CA API Gateway online documentation located at: wiki.ca.com/Gateway.

About Custom Assertions Custom assertions are optional additions to the standard assertions available from CA Technologies. A custom assertion integrates the Gateway with a third-party application or authentication system, allowing clients to utilize existing infrastructure for particular Web service security tasks.

Note: CA Technologies develops new custom assertions in response to client or industry needs. Please contact CA Technologies if you have a custom assertion request or to verify whether a custom assertion is compatible with your Gateway installation.

Compatibility The Custom Assertion SDK, which is used to create all custom assertions, is compatible with all form factors of the CA API Gateway.

The custom assertions described in this Manual are compatible with all hardware and virtual appliances, as well as Software Gateways running on RPM-based Linux platforms. However, these assertions are not compatible with Software Gateways running on the Oracle Solaris platform.

All other custom assertions created by CA Technologies or other third parties should be compatible with all Gateway form factors, unless there are platform-specific actions required by the assertions.

Chapter One: Overview 1


Available Custom Assertions The following custom assertions are currently available:

• CA Single Sign-On Protected Resource

This assertion instructs the Gateway to delegate the authentication and authorization tasks required to gain access to a protected Web service to the CA Single Sign-On Policy Server. Only CA Single Sign-On version 12.0 is supported in this assertion.

In the Policy Manager, this appears as the Authenticate with CA Single Sign-On R12 Protected Resource assertion under the Access Control category.

• Tivoli Access Manager (TAM) Protected Resource

This assertion instructs the Gateway to delegate the authentication and authorization tasks required to gain access to a protected Web service to the IBM Tivoli Access Manager Server. TAM 5.1 and 6.0 are both supported with this assertion.

In the Policy Manager, this appears as the Authenticate using Tivoli Access Manager assertion under the Access Control category.

• Symantec Virus Scanning

This assertion allows the Gateway to send a message or attachment to an internal Symantec AntiVirus Engine server for virus checking.

In the Policy Manager, this appears as the Scan using Symantec Antivirus assertion under the XML Security category.

• Sun Java System Access Manager

This assertion allows a policy to use the Single Sign-On (SSO) and Policy Service from an existing Sun Java System Access Manager 7 version 7.0 or 7.1 deployment.

In the Policy Manager, this appears as the Access Resource Protected by JSAM assertion under the Access Control category.

• Sophos Virus Scanning

This assertion allows the Gateway to scan all message attachments using Sophos Antivirus running on a separate machine.

In the Policy Manager, this appears as the Scan using Sophos Antivirus assertion under the Threat Protection category.

• Execute Salesforce Operation

This assertion allows the Gateway to integrate with the SaaS data APIs provided by Salesforce.com.

2 Chapter One: Overview


In the Policy Manager, this appears as the Execute Salesforce Operation assertion under the Message Routing category.

Upgrading a Gateway with Custom Assertions Before upgrading a Gateway containing any custom assertion described in this manual, please verify with CA Technical Support that you are running the latest version of the custom assertion and that your particular assertion will not cause issues during the Gateway upgrade.

Audience Assumptions This Guide is intended for Gateway System Administrators. The documentation assumes a general knowledge of the applicable third-party application(s), client operating systems, Internet working terminology, HTTP security technologies, and Web services.

Technical Assumptions This Guide assumes that the applicable third-party application(s), the CA API Gateway, the CA API Gateway Policy Manager, and the SecureSpan XML VPN Client are properly installed and configured. Additional assumptions and/or installation and configuration requirements are discussed in the individual custom assertion chapters.

This guide also assumes that the custom assertions will be installed in the appliance form factor of the Gateway. The software and virtual appliance form factors of the Gateway are not supported. For more information on the various form factors of the Gateway, see “Form Factors” in the CA API Gateway Administrators Guide.

User Documentation for Custom Assertions Once a custom assertion is installed and configured on the Gateway, it is available under the appropriate category Assertions tab in the Policy Manager. Users with appropriate permissions can add the custom assertion to a policy like any other assertion.

For detailed information on how to use each custom assertion, refer to the CA API Gateway online documentation located at: wiki.ca.com/Gateway.

Chapter One: Overview 3


4 Chapter One: Overview


Chapter Two: Installing the CA Single Sign-On R12

Assertion

The Gateway allows authentication requests to be sent to a CA Single Sign-On server, for the purposes of authentication and authorization. CA Single Sign-On FIPS-only mode is supported.

This chapter describes how to configure the Gateway and how to install and configure the custom assertion. For information on using the assertion in a policy, see Authenticate with CA Single Sign-On R12 Protected Resource Assertion in the Policy Manager documentation.

When configuration is complete, the custom assertion provides support for:

• CA Single Sign-On 12.0 SP3 Policy Server integration

• Policy Server running in FIPS-only mode

• Usage of the CA Single Sign-On 5.x Agent API

Gateway Agent Settings In the CA Single Sign-On Policy Server, an agent setup must exist for the CA API Gateway to use. The Gateway will send authentication requests to the CA Single Sign-On server using the agent specified. Based on the security policies defined in the CA Single Sign-On Policy Server for that agent, the CA Single Sign-On Policy Server will either permit or deny access to the Web service.

Requirement Ensure that you have the CA Single Sign-On custom assertion RPM installation file before you configure the Gateway. For example, this is the appliance version:

ssg-sm12-<version>.x86_64.rpm

Configure the Gateway Two main steps are required to configure the CA API Gateway for the CA Single Sign-On R12 assertion:

• Install the CA Single Sign-On custom assertion onto the Gateway server.

• Configure the Gateway Agent properties.

Chapter Two: Installing the SiteMinder R12 Assertion 5


When completed, you will find the Authenticate with CA Single Sign-On R12 Protected Resource assertion in the Policy Manager, under the Access Control category. For information on using this assertion, refer to the CA API Gateway online documentation located at: wiki.ca.com/Gateway.

Step 1: Install the CA Single Sign-On R12 Custom Assertion

Note: To install the assertion in a cluster, repeat the following procedure for each Gateway node in the cluster.

To install the CA Single Sign-On R12 assertion on a Gateway:

1. Log in as ssgconfig and open a privileged command shell from the Gateway configuration menu.

2. Stop the Gateway:

# service ssg stop

3. Navigate to the location of the CA Single Sign-On installation file.

4. Install the custom assertion RPM:

# rpm -Uvh ssg-sm12-<version>.x86_64.rpm

where <version> is the version number of the Gateway, plus an archive number.

5. Restart the Gateway:

# service ssg start

Step 2: Register a Trusted Host This section describes how to use the Registration Tool to create the CA Single Sign-On host configuration file that is required for the configuration of the Gateway (see the “<agent_id>.hostname” property in Table 1 on page 7).

To register a trusted host:

1. Make sure that the CA Single Sign-On R12 custom assertion is installed.

2. Log in as user ssgconfig and open a privileged command shell from the Gateway configuration menu.

3. Navigate to the CA Single Sign-On directory:

# cd /opt/SecureSpan/siteminder/bin

4. Run the Registration Tool with this command (entire command on one line):

# ./smreghost.sh -i policy_server_IP_address:port -u administrator_username - p administrator_password -hn hostname_for_registration -hc host_configuration_object –cf fips_mode

6 Chapter Two: Installing the SiteMinder R12 Assertion


The hostname will be placed in the trusted host list in the CA Single Sign-On Administrative UI and the host configuration file will be saved to the file SmHost.conf. This file contains the registered hostname, IP address, and shared secret of the CA Single Sign-On Policy Server.

Step 3: Configure the Gateway Agent Configure the siteminder12.agent.configuration cluster property with the following format:

# Agent configuration # ----------------------------- # multiple agent definitions are supported <agent_id>.name = name_of_the_agent <agent_id>.secret = shared_secret <agent_id>.address = 127.0.0.1 <agent_id>.ipcheck = false <agent_id>.hostname = name_of_the_registered_hostname <agent_id>.fipsmode = FIPS_mode # for non-cluster, define fail over (true) or round-robin load balancing (false) <agent_id>.noncluster_failover = false # for clusters, define threshold percentage for failing over to the next cluster sequence <agent_id>.cluster_threshold = 50 # Server Definitions # -------------------------- # cluster_seq = 0 : non-cluster deployment, there shouldn’t be any cluster sequence numbers other than 0 # cluster_seq >= 1 : cluster deployment, multiple cluster definitions supported <agent_id>.server.<cluster_seq>.<server_number>.address = 123.101.1.222 <agent_id>.server.<cluster_seq>.<server_number>.authentication.port = 44442 <agent_id>.server.<cluster_seq>.<server_number>.authorization.port = 44443 <agent_id>.server.<cluster_seq>.<server_number>.accounting.port = 44441 <agent_id>.server.<cluster_seq>.<server_number>.connection.min = 1 <agent_id>.server.<cluster_seq>.<server_number>.connection.max = 3 <agent_id>.server.<cluster_seq>.<server_number>.connection.step = 1 <agent_id>.server.<cluster_seq>.<server_number>.timeout = 75

For more information about defining cluster properties, see “Manage Cluster-Wide Properties” in the CA API Gateway online documentation located at wiki.ca.com/Gateway.

The following table describes the properties in the Agent configuration in more detail.

Table 1: Agent configuration - new installation

Property Description

<agent_id>.name The name used to identify the Agent to the CA Single Sign-On deployment. The




name may include any character, including spaces. Note the following limitations:

• The agent name may not begin with a space character.

• The backslash character must be “escaped” by adding a second backslash. For example: “\agentName” should be “\\agentName”.

The <agent_id> will be entered into the Authenticate with CA Single Sign-On R12 Protected Resource assertion.

<agent_id>.secret The negotiated shared secret for the trusted host in the CA Single Sign-On host registration process. This shared secret is obtained from the “sharedsecret” setting in the SmHost.conf file that is generated after the Registration Tool is run (see “Step 2: Register a Trusted Host” on page 6).

IMPORTANT: Passwords are stored in the clear in the cluster property and will also travel in the clear between the nodes and the database.

<agent_id>.address The IP address to which the Agent is bound. The client also connects to this IP address to ask the CA Single Sign-On deployment for authorization to access a resource. This property is required.

<agent_id>.ipcheck Indicates whether to provide the client’s IP address to the CA Single Sign-On deployment while requesting authorization. Value is a Boolean. Default is false if not specified.

<agent_id>.hostname The registered hostname. This value can be found in the trusted host list in the CA Single Sign-On Administrative UI or in the SmHost.conf file.

<agent_id>.fipsmode The CA Single Sign-On installation FIPS mode: COMPAT, MIGRATE or ONLY.

<agent_id>.noncluster_failover If the CA Single Sign-On deployment utilizes multiple servers in a non-cluster configuration, indicate the non-cluster strategy to be used. Value is a Boolean. The default is false if not specified.

• true = failover strategy is used

• false = round-robin strategy is used

<agent_id>.cluster_threshold If the CA Single Sign-On deployment utilizes multiple servers in a cluster configuration, indicate the percentage of servers within a cluster that must be available before failing over to the next cluster. Defaults to 50 percent if not specified.

Server Definitions An Agent configuration can have multiple server definitions, for both cluster and non-cluster deployments. Each of the servers defined for an Agent must be properly configured as part of the same CA Single Sign-On deployment. Complete the following set of properties for each server definition:

• cluster_seq: The cluster number to which the server belongs. Use 0 (zero) for non-cluster deployments. Start with 1 for cluster deployments.

Note: A “0” (non-cluster) sequence cannot be mixed with “non-0” (cluster) sequence—this will cause the Agent initialization to fail. However there can be any number of cluster sequences > 0.

• <server_number>: The server sequence number.




• address: The IP address of the server. This is required.

• authentication.port: The authentication port number. This is required.

• authorization.port: The authorization port number. This is required.

• accounting.port: The accounting port number. This is required.

• connection.min: The number of initial connections. Defaults to 1 if not specified.

• connection.max: The maximum number of connections at any one time. Defaults to 10 if not specified.

• connection.step: The connection increase step. Defaults to 1 if not specified.

• timeout: The connection timeout, in seconds. Defaults to 75 if not specified.



Chapter Three: Installing the Tivoli Access

Manager Assertion

The Tivoli Access Manager (TAM) custom assertion instructs the CA API Gateway to delegate the authentication and authorization tasks required to gain access to a protected service to the IBM® Tivoli® Access Manager server (version 5.1 or 6.0).

This chapter describes how to install and configure the TAM component and how to install and configure the custom assertion. For instructions on using the assertion in a policy, see “Authenticate using Tivoli Access Manager Assertion” in the Layer 7 Policy Manager documentation.

Requirements Verify that you have the following files before beginning:

• For RHEL 6 environments, the following files are required:

libXext-1.1-3.el6.x86_64.rpm libXi-1.3-3.el6.x86_64.rpm

• An IBM Java Runtime Environment:

ibm-java-x86_64-sdk-<version>.1.x86_64.rpm

(where “<version>” is version 6.0.9 or later)

• Tivoli Access Manager Policy Director packages:

PDJrte-PD-6.0.0-22.i386.rpm PDlic-PD-6.0.0-0.i386.rpm PDWPM-PD-6.0.0-22.i386.rpm

IMPORTANT: Due to licensing issues, you MUST contact your IBM representative for the Java Runtime Environment and the TAM Policy Director files. These files are NOT provided by CA Technologies.

• Tivoli Access Manager custom assertion package:

ssg-tam-<version>.noarch.rpm

(where “<version>” is the version number of the Gateway, with an archive number added as a suffix)

Chapter Three: Installing the Tivoli Access Manager Assertion 11


• Access to these prerequisite 64-bit files:

compat-libstdc++-33-3.2.3-47.3.x86_64.rpm libgcc-4.1.2-46.el5_4.2.i386.rpm libXp-1.0.0-8.1.el5.x86_64.rpm libXtst-1.0.1-3.1.x86_64.rpm xorg-x11-deprecated-libs-6.8.2-1.EL.13.20.x86_64.rpm

Install Prerequisite Files Begin by installing the following prerequisite 64-bit package files.

To install the prerequisite files:

1. Log in to the Gateway as ssgconfig and open a privileged command shell from the configuration menu.


# service ssg stop

3. If running Red Hat Enterprise Linux version 6, install these RPM files:

# rpm –ivh libXext-1.1-3.el6.x86_64.rpm

# rpm –ivh libXi-1.3-3.el6.x86_64.rpm

4. Navigate to the directory containing the prerequisite files and install them with the following commands (each command is on one line):

# rpm -ivh libX*

# rpm -ivh --force libgcc-4.1.2-46.el5_4.2.i386.rpm

# rpm -ivh --force compat-libstdc++-33-3.2.3-47.3.x86_64.rpm

# ln -sf /usr/lib64/libstdc++.so.6.0.8 /usr/lib64/libstdc++.so.5

5. If running Red Hat Enterprise Linux, install this RPM file:

# rpm -ivh xorg-x11-deprecated-libs-6.8.2-1.EL.13.20.x86_64.rpm

6. Install IBM Java with this command:

# rpm -ivh --nodeps ibm-java-x86_64-sdk-<version>.1.x86_64.rpm

By default, IBM Java is installed in the “/opt” directory.

Install Policy Director To install the TAM 6.0 Policy Director component:

1. Navigate to the directory containing the Policy Director files and run the following commands:

# rpm -ivh PDlic-PD-6.0.0-0.i386.rpm

# rpm -ivh PDJrte-PD-6.0.0-22.i386.rpm

# rpm -ivh PDWPM-PD-6.0.0-22.i386.rpm

12 Chapter Three: Installing the Tivoli Access Manager Assertion


2. Verify that the PolicyDirector folder is created in “/opt” after installation is finished.

Configure TAM Runtime Environment (Single Gateway Instance)

This section describes how to configure a single instance of the TAM runtime environment on the CA API Gateway. For multiple instance configuration, please refer to “Configure TAM Runtime Environment (Multiple Gateway Instances)” on page 16.

Tip: If you only need a single Gateway instance but would like flexibility for the future, choose the multiple Gateway option and configure only a single instance for now.

IMPORTANT: For the TAM access control to function properly, ensure that the Java Virtual Machine on the client machines point to the correct Access Manager Policy server.

To configure the TAM runtime environment for a single instance:

1. Run the following commands (each command is on one line):

# export PATH=$PATH:/opt/ibm/java-x86_64-60/jre/bin

# export CLASSPATH=/opt/PolicyDirector/java/export/pdjrte/PD.jar

# java -Dfile.encoding=ISO8859-1 -Xnoargsconversion -cp $CLASSPATH -Dpd.home=/opt/PolicyDirector com.tivoli.pd.jcfg.PDJrteCfg -action status

You will see the following message:

HPDBF0030W The JRE (/opt/ibm/java-x86_64-60/jre) is not configured for the Tivoli Access Manager Runtime for Java.

2. Run the following command:

# java -Dfile.encoding=ISO8859-1 -Xnoargsconversion -cp $CLASSPATH -Dpd.home=/opt/PolicyDirector com.tivoli.pd.jcfg.PDJrteCfg -action config -interactive

3. Enter the appropriate values for your environment at the following configuration prompts:

Specify the full path of the Java Runtime Environment (JRE) to configure for Tivoli Access Manager [/opt/ibm/java-x86_64-60/jre]:

Enter 'full' or 'standalone' for the configuration type [full]:

Enter the hostname of the Access Manager policy server [<ssg>.l7tech.com]:

Enter the port number of the Access Manager policy server [7135]:

Enter the Access Manager policy server domain [null]:




Tivoli Common Directory logging is not configured. If you want to use Tivoli Common Directory logging, you must enable logging and specify a directory for log files. The directory will be created if it does not exist.

Enter the appropriate values for your environment at the following logging configuration prompts:

Do you want to use Tivoli Common Directory logging (y/n) [n]?

• If you entered “y” you will see the following message:

The default location of the Tivoli Common Directory is [/var/ibm/tivoli/common].

When prompted, configure the log file location:

Press enter to accept the default location, or type a different location and press enter:


Log files for this application will be created in directory: /var/ibm/tivoli/common

You will see the following messages:

Configuration of Access Manager Runtime for Java is in progress.

This might take several minutes.

Configuration of Access Manager Runtime for Java completed successfully.

4. Run the following commands (all commands on one line):

# java -Dfile.encoding=ISO8859-1 -Xnoargsconversion -cp $CLASSPATH -Dpd.home=/opt/PolicyDirector com.tivoli.pd.jcfg.PDJrteCfg -action status

# chmod -R 755 /opt/ibm/java-x86_64-60/jre/PolicyDirector


HPDBF0031E This Java Runtime Environment has already been configured.

You are now ready to register the TAM client.

Register TAM Client To register the TAM client to the Policy Server:

1. Run the following command to register the TAM client (there are two commands; the second command is a single line):

# export JAVA_HOME=/opt/ibm/java-x86_64-60/jre

# $JAVA_HOME/bin/java -Dpd.cfg.home=$JAVA_HOME com.tivoli.pd.jcfg.SvrSslCfg -action config -domain $TAM_DOMAIN -mode $TAM_MODE -port 12347 -admin_id $TAM_ADMIN_ID -admin_pwd $TAM_ADMIN_PASSWORD -cfg_file $CFG_FILE -key_file $KEY_FILE -appsvr_id $APP_SVR_ID -policysvr $TAM_POLICY_SERVER_IP:1 -authzsvr $TAM_POLICY_SERVER_IP:1



Where:

• “$TAM_DOMAIN” is always Default

• “$TAM_MODE” is always remote

• “$TAM_ADMIN_ID” is the username of the TAM administrator

• “$TAM_ADMIN_PASSWORD” is the password from the TAM administrator

• “$CFG_FILE” is $JAVA_HOME/PdPerm.properties

• “$KEY_FILE” is $JAVA_HOME/pdperm.ks

• “$APP_SVR_ID” is the unique name for your Gateway

• “$TAM_POLICY_SERVER_IP” is the IP address of your TAM policy server

2. Run the following commands to set the correct permissions:

# chmod 644 /opt/ibm/java-x86_64-60/jre/PdPerm.properties

# chmod 644 /opt/ibm/java-x86_64-60/jre/pdperm.ks

At this point, you may now install the Tivoli Access Manager custom assertion on the Gateway.

Install TAM Custom Assertion To install the Tivoli Access Manager custom assertion:

1. Open a privileged shell on the Gateway and stop these services:

# service ras stop

# service ssg stop

2. Navigate to the directory containing the custom assertion RPM file and run this command:

# rpm –ivh ssg-tam-<version>.noarch.rpm

The Tivoli Access Manager custom assertion is available under the Access Control category the next time the Policy Manager is started.

For more information on using this assertion in a policy, please see “Authenticate using Tivoli Access Manager Assertion” in the CA API Gateway online documentation located at wiki.ca.com/Gateway.

3. Next, run the following commands:

# touch /opt/SecureSpan/Gateway/runtime/ras/remote-asertions.log

# chown layer7.gateway /opt/SecureSpan/Gateway/runtime/ras/ remote-asertions.log

# chmod g+w /opt/SecureSpan/Gateway/runtime/ras/ remote-asertions.log

4. Restart the “ras” and “ssg” services:



# service ras start

# service ssg start

You can verify that a service has correctly started with the command:

service <service_name> status

Configure TAM Runtime Environment (Multiple Gateway Instances)

This section describes how to configure multiple instance of the TAM runtime environment on the CA API Gateway. Multiple TAM instances allow clients to communicate with multiple TAM policy servers at the same time. For single instance configuration, please refer to “Configure TAM Runtime Environment (Single Gateway Instance)” on page 13.

IMPORTANT: For the TAM access control to function properly, ensure that the Java Virtual Machine on the client machines point to the correct Access Manager Policy server.

Install Multiple TAM Instances To install multiple TAM instances:

1. Make sure all TAM servers are running.

2. Create your instance folders under the following directory.

/opt/ibm/java-x86_64-60/jre

For example, “/opt/ibm/java-x86_64-60/jre/inst1” and “/opt/ibm/java-x86_64-60/jre/inst2”. You will need to set the appropriate permissions for these folders, for example:

# chmod -R 755 /opt/ibm/java-x86_64-60/jre/inst1

# chmod -R 755 /opt/ibm/java-x86_64-60/jre/inst2

3. Run the following commands:

# cp /opt/PolicyDirector/java/export/pdjrte/PD.jar /opt/ibm/java-x86_64-60/jre/lib/ext/

# chmod 444 /opt/ibm/java-x86_64-60/jre/lib/ext/PD.jar

# export PATH=$PATH:/opt/ibm/java-x86_64-60/jre/bin

4. Run the following command for each instance against the target TAM server (entire command on one line):

# java -Dfile.encoding=ISO8859-1 -Xnoargsconversion -Dpd.home=/opt/ibm/java-x86_64-60/jre/<instance> com.tivoli.pd.jcfg.PDJrteCfg -action config -cfgfiles_path /opt/ibm/java-x86_64-60/jre/<instance> -host <instance_host_IP> -port <instance_port> -was

Where:



• “<instance>” is the instance label created above

• “<instance_host_ip>” is the hostname or IP address for the TAM server

• “<instance_port>” by default is 7135

For the inst1 and inst2 example above, the commands would be:

# java -Dfile.encoding=ISO8859-1 -Xnoargsconversion -Dpd.home=/opt/ibm/java-x86_64-60/jre/inst1 com.tivoli.pd.jcfg.PDJrteCfg -action config -cfgfiles_path /opt/ibm/java-x86_64-60/jre/inst1 -host 10.7.32.213 -port 7135 -was

# java -Dfile.encoding=ISO8859-1 -Xnoargsconversion -Dpd.home=/opt/ibm/java-x86_64-60/jre/inst2 com.tivoli.pd.jcfg.PDJrteCfg -action config -cfgfiles_path /opt/ibm/java-x86_64-60/jre/inst2 -host 10.7.32.126 -port 7135 -was

You should see a message notifying you the configuration was successful. At this point, set the correct permissions using these commands:

# chmod -R 755 /opt/ibm/java-x86_64-60/jre/inst1/PolicyDirector

# chmod -R 755 /opt/ibm/java-x86_64-60/jre/inst2/PolicyDirector

Tip: You may ignore this message if it appears: “Unable to create the PDJLog.properties file in the specified JRE. Ensure you have the correct permission to do so.”

5. Register the TAM client instance on the target TAM servers with this command (entire command one line):

# java -Dpd.cfg.home /opt/ibm/java-x86_64-60/jre/<instance> com.tivoli.pd.jcfg.SvrSslCfg -action config -domain $TAM_DOMAIN -mode $TAM_MODE -port 12347 -admin_id $TAM_ADMIN_ID -admin_pwd $TAM_ADMIN_PASSWORD -cfg_file $CFG_FILE -key_file $KEY_FILE -appsvr_id $APP_SVR_ID –policysvr $TAM_POLICY_SERVER_IP:<instance_port>:1 –authzsvr $TAM_POLICY_SERVER_IP:<instance_authzsvr_port>:1

Where:

• “<instance>” is the label/name for the TAM instance (required only when there are multiple instances; omit if only a single instance will exist)

• “<instance_port>” is a port number (default=7135)

• “<instance_authzsvr_port>” is a port number (default=7136)

• “$TAM_DOMAIN” is always Default

• “$TAM_MODE” is always remote

• “$TAM_ADMIN_ID” is the username of the TAM administrator

• “$TAM_ADMIN_PASSWORD” is the password from the TAM administrator

• “$CFG_FILE” is $JAVA_HOME/<instance>/PdPerm.properties

• “$KEY_FILE” is $JAVA_HOME/<instance>/pdperm.ks



• “$APP_SVR_ID” is the unique name for your Gateway

• “$TAM_POLICY_SERVER_IP” is the IP address of your TAM policy server

6. Set the correct permissions with these commands:

# chmod 644 /opt/ibm/java-x86_64-60/jre/<instance>/PdPerm.properties

# chmod 644 /opt/ibm/java-x86_64-60/jre/<instance>/pdperm.ks

Install TAM Custom Assertion To install the Tivoli Access Manager custom assertion:

1. Open a privileged shell on the Gateway and stop these services:

# service ras stop

# service ssg stop

2. Navigate to the directory containing the custom assertion RPM file and run this command:

# rpm –ivh ssg-tam-<version>.noarch.rpm

The Tivoli Access Manager custom assertion is available under the Access Control category the next time the Policy Manager is started.

For more information on using this assertion in a policy, please see “Authenticate using Tivoli Access Manager Assertion” in the CA API Gateway online documentation located at wiki.ca.com/Gateway.

3. Next, run the following commands:

# touch /opt/SecureSpan/Gateway/runtime/ras/remote-asertions.log

# chown layer7.gateway /opt/SecureSpan/Gateway/runtime/ras/ remote-asertions.log

# chmod g+w /opt/SecureSpan/Gateway/runtime/ras/ remote-asertions.log

After installing the custom assertion, modify the TAM Agent properties.

Update TAM Agent Properties After the TAM custom assertion is installed, edit the TAM Agent properties so that it recognizes the additional TAM instances.

To update the TAM Agent properties:

1. Open the properties file in a text editor:

/opt/SecureSpan/Gateway/node/default/etc/conf/tam_agent.properties

The following is an example of the tam_agent_properties file:



########################################################### # This is the properties file used by the TAM agent # # Change values as appropriate. # ########################################################### # The TAM Policy Director configuration file # Example: tam.pd.config.file.name=c:/ibm/wsdk_v51/appserver/java/jre/PdPerm.properties # tam.pd.config.file.name=/opt/ibm/java-x86_64-60/jre/PdPerm.properties tam.pd.config.file.name.inst1=/opt/ibm/java-x86_64-60/jre/inst1/PdPerm.properties tam.pd.config.file.name.inst2=/opt/ibm/java-x86_64-60/jre/inst2/PdPerm.properties # The time interval (ms) of updating the principal cache in RAS. # The expired principals are removed from the cache during the update. principal.cache.update.interval=5000 # Specify the duration (ms) the principal is stored in the cache. principal.expiry.duration=30000 # pdcontext.cache.expiry.duration=30000

2. Comment out the original configuration (shown in red in the above sample file):

#tam.pd.config.file.name=/opt/ibm/java-x86_64-60/jre/PdPerm.properties

3. Add a line for each TAM instance. For the inst1 and inst2 example above, the lines would be (each entry is on one line):

tam.pd.config.file.name.inst1=/opt/ibm/java-x86_64-60/jre/inst1/PdPerm.properties

tam.pd.config.file.name.inst2=/opt/ibm/java-x86_64-60/jre/inst2/PdPerm.properties

Tip: Make note of the instance names as they will be used in the Authenticate using Tivoli Access Manager custom assertion in the Policy Manager.

4. Save and close the file.

5. Restart the “ras” and “ssg” services:

# service ras start

# service ssg start

You can verify that a service has correctly started with the command:

service <service_name> status



Chapter Four: Installing the Symantec

Virus Scanning Assertion

The Gateway allows requests and attachments to be sent to a Symantec® Antivirus Engine (SAVE) server, for virus detection. Layer7 Technologies currently supports Symantec SAVE 5.2.

This chapter describes how to configure the Symantec Antivirus Engine and how to install and configure the Symantec Virus Scanning custom assertion. For instructions on using the assertion in a policy, see the Scan using Symantec Antivirus assertion in the Policy Manager documentation.

Requirements Ensure that you have the following before configuring the Gateway for Symantec:

• Valid installation of Symantec Antivirus Engine installed in your environment

• Gateway installed and configured

• The Symantec Virus Scanning custom assertion RPM installation file

Note: The Symantec Antivirus Engine should not be installed on the same machine as the Gateway, in order to ensure proper performance from the Gateway.

Configure Symantec Antivirus Engine The following configuration changes need to be made to the Symantec Antivirus Engine before it will work with the Gateway:

• Symantec Antivirus Engine must be configured for the ICAP protocol, as this is what the Gateway supports. To make this configuration, do the following:

a. Login to the Symantec server through your web browser, using http://<server>:8004.

b. Select the Configuration tab.

c. Select ICAP in the Protocol tab.

• Other configurations:

a. Click Blocking Policy.

a. Select the Antivirus tab and set heuristic scanning to High.

Chapter Four: Installing the Symantec Virus Scanning Assertion 21


b. Set file types to Scan all files regardless of extension.

Once the Symantec Antivirus Engine is configured, proceed to “Configure the Gateway” below.

Configure the Gateway Two main steps are required to configure the Gateway for the Symantec Virus Scanning custom assertion:

• Install the Symantec Virus Scanning assertion onto the Gateway server.

• Configure the assertion with your network settings.

When completed, the Scan using Symantec Antivirus assertion appears in the Policy Manager, under the XML Threats category.

Install the Custom Assertion To install the Symantec Virus Scanning assertion on a Gateway:


2. If the Gateway is running, stop it using this command:

# service ssg stop

3. Navigate to the location of the Symantec Virus Scanning installation file.

4. Type the following command to install the RPM:

# rpm -Uvh ssg-symantec-<version>.noarch.rpm


When completed, proceed to the next section below.

Configure the Custom Assertion To configure the custom assertion so that attachments and messages are sent to

the correct location:

1. Open the following file in a text editor:

<SSG>/node/default/etc/conf/symantec_scanengine_client.properties

where <SSG> is the home directory for the Gateway: /opt/SecureSpan/Gateway.

2. Set the two properties in that file to appropriate settings for your network and then save the file.

3. Restart the Gateway.

22 Chapter Four: Installing the Symantec Virus Scanning Assertion


Chapter Five: Installing the Sun Java System

Access Manager Assertion

The Sun Java System Access Manager assertion allows a policy to use the Single Sign-On (SSO) and Policy Service from an existing Sun® Java System Access Manager 7.0 or 7.1 deployment.

This chapter describes how to install and configure the assertion in the Gateway. For information on using the assertion in a policy, see the Access Resource Protected by JSAM assertion the Policy Manager documentation.

Requirements Ensure that the following has been installed:

• Gateway version 3.6 or higher

• Sun Java System Access Manager 7 version 7.0 or 7.1

• A Policy Agent profile defined under the realm

• The custom assertion RPM installation file

Configure the Gateway Note: To install and configure the assertion in a cluster, repeat the following procedures for each Gateway in the cluster.

Two main steps are required to configure the Gateway for this custom assertion:

• Install the custom assertion onto the Gateway server.

• Modify two properties files with information configured in the Sun Java System Access Manager Server.

When this process is completed, the Sun Java System Access Manager Protected Resource assertion appears in the Policy Manager, under the Access Control category. For information on using this assertion in a policy, refer to the CA API Gateway online documentation located at wiki.ca.com/Gateway.

Chapter Five: Installing the Sun Java System Access Manager Assertion 23


Install the Custom Assertion

Note: In the following steps, “<SSG_home>” is “/opt/SecureSpan/Gateway” by default.

To install the Sun Java System Access Manager assertion on a Gateway:


2. If the Gateway is running, stop it:

# service ssg stop

3. Navigate to the location of the custom assertion installation file.

4. Type the following command to install the RPM:

# rpm -Uvh ssg-jsam-<version>.noarch.rpm


When completed, proceed to Edit Properties Files below.

Edit the Properties Files Perform the following configuration after the installing the custom assertion package:

1. Open the following file in a text editor:

<SSG_home>/node/default/etc/conf/sun-jsam-client.properties

2. Review and update the properties shown below.

Table 2: Editing the sun-jsam-client.properties file


com.sun.identity.agents.app.username Name of Policy Agent profile created on the Access Manager server.

com.iplanet.am.service.password Plain text password of the Policy Agent profile.

If an encrypted password is used instead, enter it in the “com.iplanet.am.service.secret” property.

com.iplanet.am.service.secret The encrypted password of the Policy Agent profile. If a plain text password is used instead, enter it in the “com.iplanet.am.service.password” property.

am.encryption.pwd If an encrypted password is used, then this value must match AMConfig.properties.

com.iplanet.am.naming.url This value must match AMConfig.properties.

com.iplanet.am.notification.url This value must match AMConfig.properties.

com.iplanet.am.server.protocol This value must match AMConfig.properties.

24 Chapter Five: Installing the Sun Java System Access Manager Assertion



com.iplanet.am.server.host The fully qualified host name of the Access Manager server. This value must match AMConfig.properties.

com.iplanet.am.server.port This value must match AMConfig.properties.

com.iplanet.services.debug.level Controls the Access Manager Client SDK internal logging. Enter the minimum severity level to be logged:

off (logging disabled) error warning message

com.iplanet.services.debug.directory The directory to store the Access Manager Client SDK internal log files.

3. (Optional) Open the following file in a text editor:

<SSG_home>/node/default/etc/conf/sun-jsam-ca.properties

4. (Optional) Verify that the following entries match those in the Sun Java System Access Manager server (they will if the server uses the factory default values):

Property Default Value

com.l7tech.custom.sun.jsam.PolicyServiceName iPlanetAMWebAgentService

com.l7tech.custom.sun.jsam.SsoCookieName iPlanetDirectoryPro

Note: The default values are automatically used if the file or the properties are missing.


# service ssg start

The custom assertion is available the next time the Policy Manager is started as the Sun Java System Access Manager Protected Resource. For information on using this assertion in a policy, please refer to in the CA API Gateway online documentation located at wiki.ca.com/Gateway.

Chapter Five: Installing the Sun Java System Access Manager Assertion 25


26 Chapter Five: Installing the Sun Java System Access Manager Assertion


Chapter Six: Installing the Sophos

Antivirus Assertion

The Sophos Antivirus assertion allows the CA API Gateway to scan all message attachments using Sophos Antivirus running on a separate machine.

This chapter describes how to install the modular assertion on the Gateway so that it shows up in the Policy Manager interface. For information on using the assertion in a policy, see “Scan using Sophos Antivirus Assertion” in the CA API Gateway online documentation located at wiki.ca.com/Gateway.

Requirements Ensure that you have:

• A configured CA API Gateway, version 6.0 or higher

• A configured Sophos Antivirus server

• The SophosAssertion-6.0.aar installation file

Install the Assertion Note: To install the assertion in a cluster, repeat the following procedure for each Gateway in the cluster.

When this process is completed, the Sophos Antivirus assertion appears in the Policy Manager, under the Threat Protection category. For information on using this assertion, refer to the CA API Gateway online documentation located at wiki.ca.com/Gateway.


To install the Sophos Antivirus assertion on a Gateway:



# service ssg stop

Chapter Six: Installing the Sophos Antivirus Assertion 27


3. Copy the SophosAssertion-6.0.aar installation file to the following directory:

<SSG_home>/runtime/modules/assertions


# service ssg start

The assertion is now ready to use.

28 Chapter Six: Installing the Sophos Antivirus Assertion


Chapter Seven: Installing the Oracle

Access Manager Assertion

The Access Resource Protected by Oracle Access Manager assertion enables a CA API Gateway to delegate authentication and authorization to an Oracle Access Manager 10g or 11g server.

This chapter describes how to install and configure the custom assertion on the Gateway so that it shows up in the Policy Manager interface.



• A configured Oracle Access Manager

• Access to the installation files appropriate to your environment:

ssg-oracle-access-manager-<version>.i386.rpm (32-bit) ssg-oracle-access-manager-<version>.x86_64.rpm (64-bit)

• Access to the following compatibility library:

compat-libstdc++-33-3.2.3-61.x86_64.rpm (for 10g OAM Server only)

Install the Assertion When this process is completed, the Access Resource Protected by Oracle Access Manager assertion appears in the Policy Manager, under the Access Control category. For information on using this assertion, refer to the CA API Gateway online documentation located at wiki.ca.com/Gateway.


To install the Access Resource Protected by Oracle Access Manager assertion:



# service ssg stop

Chapter Seven: Installing the Oracle Access Manager Assertion 29


3. Navigate to the location of the Oracle Access Manager installation files.

4. If there is a previous version of the custom assertion installed, uninstall it first:

# rpm -e ssg-oracle-access-manager-<version>

5. Follow the appropriate instructions:

To connect to an OAM 11g server:

• For a 32-bit environment, run this command:

# rpm -Uvh ssg-oracle-access-manager-<version>.i386.rpm

• For a 64-bit environment, run this command:

# rpm -Uvh ssg-oracle-access-manager-<version>.x86_64.rpm

To connect to an OAM 10g server:

The Oracle Access Manager custom assertion can only be installed on 64-bit Linux systems, as the configuration requires 64-bit native libraries.

a. Run the following command to first install the compatibility file:

# rpm -Uvh compat-libstdc++-33-3.2.3-61.x86_64.rpm

b. Run the following command to install the assertion:

# rpm -Uvh ssg-oracle-access-manager-<version>.x86_64.rpm


# service ssg start

The custom assertion will now appear in the Policy Manager.

Configure System Property for OAM 10g Server When installing the Oracle Access Manager custom assertion for OAM 10g, you must configure the following system property (not required for OAM 11g).

To configure the system property for OAM 10g:

1. Locate and open the following file in a text editor:

/opt/SecureSpan/Gateway/node/default/etc/conf/system.properties

2. Add the following line:

org.apache.tomcat.util.http.ServerCookie.ALLOW_EQUALS_IN_VALUE = true

3. Save and exit the file, then stop and restart the Gateway.

Configure 10g Webgate for OAM 11g Server

Note: This section applies only to OAM 11g servers, which can work with 10g/11g Webgates. Disregard this section if you are connecting to an OAM 10g server.

30 Chapter Seven: Installing the Oracle Access Manager Assertion


By default, the Oracle Access Manager custom assertion is configured to use the OAM 11g server running the 11g Webgate (all security modes supported: Open/Simple/Cert). If you are using a 10g Webgate instead, make the change described below.

To configure the assertion for OAM 10g Webgate:

1. Locate and open the following file in a text editor:

/opt/SecureSpan/Gateway/node/default/etc/conf/system.properties

2. Add the following line:

com.l7tech.custom.oam.10g.webgate.used=true

If any value other than “true” is specified, then the 11g Webgate will be used.

3. Save and exit the file, then restart the Gateway.

Configure Connection with OAM 11g Server This section describes how to configure a Webgate for the access client (which is the Access Resource Protected by Oracle Access Manager custom assertion).

There are two types of Webgates (10g and 11g) that can be registered via the OAM 11g Admin Console. The CA API Gateway supports all security modes (Open, Simple, Cert) for each type of Webgate.

Step 1: Register a Webgate Copy the configuration files from Table 3 to the following directory on the Gateway:

/opt/SecureSpan/Gateway/runtime/modules/conf/oam11g

Note: The “oam11g” in the above path refers to the OAM 11g server and it applies regardless of whether a 10g or 11g Webgate is in use.

Table 3: Configuration files for registering a 10g Webgate

Webgate Security Mode

Required Configuration Files

10g Open ObAccessClient.xml

10g Simple ObAccessClient.xml password.xml oamclient-keystore.jks oamclient-truststore.jks

10g Cert ObAccessClient.xml password.xml oamclient-keystore.jks oamclient-truststore.jks



Webgate Security Mode

Required Configuration Files

11g Open cwallet.sso ObAccessClient.xml

11g Simple cwallet.sso ObAccessClient.xml password.xml oamclient-keystore.jks oamclient-truststore.jks

11g Cert cwallet.sso ObAccessClient.xml password.xml oamclient-keystore.jks oamclient-truststore.jks

You can acquire the configuration files as follows:

• The following files are obtained from the OAM 11g Server from this directory:

${ORACLE_MIDDLE_WARE}/user_projects/domains/<domain_name>/output/ <webgate_name>

ObAccessClient.xml cwallet.sso password.xml

• The following files are generated manually:

oamclient-keystore.jks oamclient-truststore.jks

For information on generating these files and creating keystores, refer “Configuring and Deploying Access Clients” the Oracle online documentation: http://docs.oracle.com/cd/E40329_01/admin.1112/e27239/keytool.htm#autoId1.

Step 2: Set File Permissions Once the files are copied over to the Gateway directory, run the following commands to set the files permissions:

# cd /opt/SecureSpan/Gateway/runtime/modules/conf/oam11g/

# chmod 600 *

# chown gateway.gateway *

Step 3: Restart Gateway and ORS Service Restart the Gateway with this command:


http://docs.oracle.com/cd/E40329_01/admin.1112/e27239/keytool.htm%23autoId1

http://docs.oracle.com/cd/E40329_01/admin.1112/e27239/keytool.htm%23autoId1


# service ssg restart

Restart the ORS Service with this command:

# service ors stop

# service ors start

Configure Connection with OAM 10g Server Use the configureAccessGate command to configure access client as shown below (each command is a single line):

1. First, change to the location of the command:

# cd /opt/SecureSpan/Gateway/runtime/modules/conf/oam10g/oblix/tools/ configureAccessGate

2. Run the command as follows:

# ./configureAccessGate -i /opt/SecureSpan/Gateway/runtime/modules/ conf/oam10g -t AccessGate -w <Access Gate Name> -m <Security Mode> -c request -P <Password> -h <Access Server Host> -p <Port> -a <Access Server ID> -r <Global Access Protocol Passphrase>

Example of the command in use:

# ./configureAccessGate -i /opt/SecureSpan/Gateway/runtime/modules/ conf/oam10g -t AccessGate -w ghssg-64 -m simple -c request -P 7layer -h oam10g.l7tech.com -p 6021 -a access-1 -r 7layer

Run the OAM RMI Service The OAM RMI Service (“ors”) must be run before the Access Resources Protected by Oracle Access Manager assertion is executed in a service policy. This applies regardless of the security mode in use or the OAM server version.

Prerequisite: Ensure that the Access Resources Protected by Oracle Access Manager custom assertion has been installed (see “Install the Assertion” on page 29).

How to use the OAM RMI Service:

• To run the OAM RMI Service, run this command from the Linux console: # service ors start

• To stop the OAM RMI Service, run this command: # service ors stop

• To restart the OAM RMI Service, run this command: # service ors restart

Tip: It does not matter whether the OAM RMI Service is run before or after the Gateway service.



When the OAM RMI Service is run, it produces a log file that contains OAM ASDK runtime details, which is useful for debugging purposes. The log file is located here:

/opt/SecureSpan/Gateway/node/default/var/logs/ors.log



Chapter Eight: Installing the Execute Salesforce

Operation Assertion

The Execute Salesforce Operation assertion allows the CA API Gateway to integrate with the SaaS data APIs provided by Salesforce.com.

This chapter describes how to install the Execute Salesforce Operation assertion on the Gateway. For information on using the assertion in a policy, see “Execute Salesforce Operation Assertion” in the CA API Gateway online documentation located at wiki.ca.com/Gateway.



• The CA API Gateway - Policy Manager (the same version as the Gateway)

• The Execute Salesforce Operation assertion’s RPM installation file (for example, “ssg-sf-<version>.noarch.rpm” where <version> is the version number of the Gateway, plus an archive number)

• A Salesforce.com account with appropriate permissions

• Installed the Salesforce license as per the Salesforce documentation

Install the Assertion Note: To install the assertion in a cluster, repeat the following procedure for each Gateway in the cluster.

After installing the Execute Salesforce Operation assertion, it will appear in the Policy Manager under the Custom Assertions category.

To install the Execute Salesforce Operation assertion on a Gateway:

1. Log in to the Gateway as ssgconfig and open a privileged command shell from the Gateway configuration menu.


# service ssg stop

3. Navigate to the directory containing the assertion’s RPM installation file.

Chapter Eight: Installing the Execute Salesforce Operation Assertion 35


4. Install the RPM file:

# rpm –Uvh ssg-sf-<version>.noarch.rpm



# service ssg start

The assertion is now ready to use. Tip: If the assertion does not appear, ensure that the Salesforce license has been installed.

36 Chapter Eight: Installing the Execute Salesforce Operation Assertion


Appendix A: Contacting CA Technologies

Technical Support At CA Technologies, our commitment to exceptional service culminates in the advanced level of technical support that we provide for our products.

You can email support at [email protected] or call the number near your region.

Table 4: CA Technical Support contact numbers

Area Phone

North America 1-800-225-5224

Federal 1-800-225-5224 (press option ‘7’)

UK 0845 161 0038

France 081 102 5146

Germany 0800 101 4666

Italy 84032 0057

Spain 90188 8125

Switzerland 084 400 0092

Australia 1800 023 386

For more details, please refer to your Service Level Agreement.

Contact Information CA Technologies welcomes your questions, comments, enhancement requests, and general feedback.

Table 5: CA Technologies contact information

Phone 1-800-225-5224 (North America toll free)

Web www.ca.com/api

Email [email protected]

Appendix B: Access Resource Protected by Oracle Access Manager Assertion 37

mailto:[email protected]


38 Appendix A: Contacting CA Technologies

ca api management under the xml security ... the ca api gateway policy ... installing the ca single...

Documents