OpenText™ Access Manager Appliance

Security guide
Version : 25.2
PDF Generated on : October 23, 2025

© Copyright 2025 Open Text

Table of Contents
1. Security guide 1

1.1. Deployment Considerations 2

1.1.1. Protecting OpenText Access Manager through Firewall 3

1.1.2. Protecting OpenText Access Manager Setup behind NAT 5

1.1.3. Protecting Identity Server behind Access Gateway 6

1.1.4. Configuring Identity Server to listen on Port 443 7

1.2. Securing Administration Console 8

1.2.1. Restricting Administration Console Access to only Private Network 9

1.2.2. Managing Administration Console Session Timeout 10

1.2.3. Securing Administrator Accounts 11

1.2.4. Protecting the Configuration Store 13

1.2.5. Securing Configuration Store Using TLS Port 14

1.2.6. Running the DHost HTTP Server on localhost 16

1.2.7. Preventing the SWEET32 Attack 17

1.2.8. Default Security Settings in Configuration Files 18

1.2.9. Configuring ciphers for the Upgrade Assistant agent and the internal 22
communication

1.3. Securing Identity Server 24

1.3.1. Disabling Unused Authentication Protocols 25

1.3.2. Configuring SSL Communication between Browsers and Identity Server 26

1.3.3. Configuring SSL Communication with Identity Server and a Service Provider 27

1.3.4. Securing Authentication by Using Strong and Multi-Factor Authentication 28

Methods

1.3.5. Securing Federation 30

1.3.6. Configuring the allowed list of Target URL 33

1.3.7. Blocking Access to Identity Server Pages 37

1.3.8. Enabling Advanced Session Assurance 38

1.3.9. Securing Identity Server Web Service Interface 39

1.3.10. Enabling reCAPTCHA 42

1.3.11. Preventing the SWEET32 Attack 43

1.3.12. Detecting the Brute Force Attack 44

1.3.13. Restricting the Direct Access to Files in the nidp Folder 45

1.3.14. Preventing Cross-Site Request Forgery Attacks 46

1.3.15. Using the Device ID in the URN Cookie 50

1.3.16. Handling Query Parameters in an Authentication Request 51

1.3.17. Configuring the Cookie Secure Flag 52

1.3.18. Default Security Settings in Configuration Files 53

1.4. Securing Access Gateway 56

1.4.1. Enabling SSL Communication between Access Gateway and Identity Server 57

1.4.2. Enabling Secure Cookies 58

1.4.3. Disabling Phishing 61

1.4.4. Disabling Weak Protocols between Access Gateway and Web Servers 62

1.4.5. Configuring Stronger Ciphers for SSL Communication between Access Gateway 63
and Web Servers

1.4.6. Enabling Perfect Forward Secrecy 65

1.4.7. Preventing Error Messages to Show the Failure Reason on Browsers 66

1.4.8. Enabling Advanced Session Assurance 67

1.4.9. Preventing the Slowloris Attack 68

1.4.10. AJP Communication Setting for Access Gateway 70

1.4.11. Using the Device ID in the URN Cookie 74

1.4.12. Default Security Settings in Configuration Files 75

1.5. Securing OpenText Access Manager on Docker 77

1.5.1. Deployment considerations for Kubernetes 78

1.5.2. Securing Access to Access Manager Services in a Kubernetes Cluster 79

1.5.3. YAML Best Practices 80

1.5.4. Protecting Access Manager Secrets on Kubernetes 81

1.6. Configuring Secure Communication 82

1.6.1. Configuring SSL in Identity Server 83

1.6.2. Configuring SSL in Access Gateway 85

1.6.3. Configuring SSL for Authentication between Identity Server and Access 88
Gateway

1.6.4. Using Trusted Certificates Authority 89

1.7. Strengthening TLS/SSL Settings 90

1.7.1. Disabling SSLv2 and SSLv3 Protocols 92

1.7.2. Optimizing SSL Configuration with Ciphers 93

1.7.3. Enabling Perfect Forward Secrecy 94

1.7.4. Adding HTTP Strict Transport Security 95

1.7.5. Customizing the Size of Ephemeral Diffie-Hellman Keys 96

1.8. Strengthening Certificates 97

1.8.1. Key Size and Signature Algorithm Considerations 98

1.8.2. Trusted Certificate Authorities 99

1.8.3. Certificate Renewal 100

1.9. XSS, XFS, and Clickjacking Attacks 101

1.9.1. Cross-site Scripting Attacks 102

1.9.2. Cross-Frame Scripting Attacks 107

1.9.3. Clickjacking Attacks 108

1.10. Getting the Latest Security Patches 109

1.11. Securing OpenText Access Manager Components on Cloud 110

1.11.1. Prerequisite 111

1.11.2. Protecting Administration Console on Cloud 112

1.12. Restoring Previous Security Level After Upgrading OpenText Access Manager 113
Appliance

1.12.1. Restoring Previous Security Settings for Administration Console 115

1.12.2. Restoring Previous Security Settings for Identity Server 118

1.12.3. Restoring Previous Security Settings for Access Gateway 122

1.13. Appendix 124

1.13.1. Default Ciphers for Identity Server 125

1.13.2. Default Ciphers for Administration Console 126

1.13.3. Default Ciphers for Access Gateway 127

 Access Manager Appliance 25.2

1. Security guide
This guide is intended for OpenText Access Manager administrators, designers, and
implementers with several configuration guidelines. These guidelines can be used for
enhancing the security of an OpenText Access Manager environment. The first half of
the guide focuses on tasks for configuring the product components along with
examples and references. The remaining part of the guide provides additional
information about the important concepts described in prior sections.
It is recommended that the administrators frequently consult the product
documentation, OpenText Access Manager TIDS, Cool Solutions, and keep up to date
on patches and versions of both OpenText Access Manager and the host operating
system.
This book is intended for OpenText Access Manager administrators. It is assumed that
you have knowledge of evolving Internet protocols, such as:
Extensible Markup Language (XML)
Simple Object Access Protocol (SOAP)
Security Assertion Markup Language (SAML)
Public Key Infrastructure (PKI) digital signature concepts and Internet security
Secure Socket Layer/Transport Layer Security (SSL/TLS)
Hypertext Transfer Protocol (HTTP and HTTPS)
Uniform Resource Identifiers (URIs)
Domain Name System (DNS)
Web Services Description Language (WSDL)

This PDF was generated on October 23, 2025 Page 1 of 127

 Access Manager Appliance 25.2

1.1. Deployment Considerations

In this Section
Protecting Access ManagerAccess Manager Appliance through Firewall

This PDF was generated on October 23, 2025 Page 2 of 127

 Access Manager Appliance 25.2

1.1.1. Protecting OpenText Access

Manager through Firewall
Access Manager Appliance with firewalls. Access Manager Appliance and Firewall
illustrates a firewall setup for a basic OpenText Access Manager Appliance
configuration .

OpenText Access Manager Components between Firewalls

OpenText Access Manager Appliance and Firewall

OpenText Access Manager Appliance in DMZ

First Firewall: If you place a firewall between browsers and OpenText Access
Manager Appliance, you need to open ports so that browsers can communicate with
Access Gateway and Identity Server and Identity Server can communicate with other
identity providers.
For information about ports required to open in the first firewall, see First firewall.

This PDF was generated on October 23, 2025 Page 3 of 127

 Access Manager Appliance 25.2

Second Firewall: The second firewall separates web servers, LDAP servers, and
Administration Console from Identity Server and Access Gateway.
For information about ports required to open in the second firewall, see Second
firewall.
You need to open ports on the second firewall according to the offered services.

This PDF was generated on October 23, 2025 Page 4 of 127

 Access Manager Appliance 25.2

1.1.2. Protecting OpenText Access

Manager Setup behind NAT

This PDF was generated on October 23, 2025 Page 5 of 127

 Access Manager Appliance 25.2

1.1.3. Protecting Identity Server behind

Access Gateway

This PDF was generated on October 23, 2025 Page 6 of 127

 Access Manager Appliance 25.2

1.1.4. Configuring Identity Server to listen

on Port 443

This PDF was generated on October 23, 2025 Page 7 of 127

 Access Manager Appliance 25.2

1.2. Securing Administration Console

Administration Console contains configuration information for the product
components. If you federate your users with other servers, it stores configuration
information about these users. You need to protect Administration Console so that
unauthorized users cannot change configuration settings or gain access to the
information in the configuration store.
When you develop a security plan for OpenText Access Manager, consider the
following considerations:
Managing Administration Console Session Timeout
Securing Administrator Accounts
Protecting the Configuration Store
Securing Configuration Store Using TLS Port
Running the DHost HTTP Server on localhost
Preventing the SWEET32 Attack
Default Security Settings in Configuration Files

This PDF was generated on October 23, 2025 Page 8 of 127

 Access Manager Appliance 25.2

1.2.1. Restricting Administration Console

Access to only Private Network

This PDF was generated on October 23, 2025 Page 9 of 127

 Access Manager Appliance 25.2

1.2.2. Managing Administration Console

Session Timeout
The default Administration Console session timeout value is 30 minutes. You can
modify this value in the [Link] file for a longer or a shorter period based on your
security needs.
1. Open the Administration Console [Link] file.
2. Search for the <session-timeout> parameter.
3. Modify the value and save the file.
For information about how to edit a file, see Modifying configurations.

This PDF was generated on October 23, 2025 Page 10 of 127

 Access Manager Appliance 25.2

1.2.3. Securing Administrator Accounts

The admin user you create while installing Administration Console has all rights to
OpenText Access Manager Appliance components. We recommend that you secure
this account through the following configuration:
Password Restrictions: When the admin user is created, no password
restrictions are set. To ensure that the password meets your minimum security
requirements, configure the standard eDirectory password restrictions for this
account. In Administration Console, select the Roles and Tasks view in the
iManager header, then click Users. Browse to the admin user (found in the novell
container), then click Restrictions.
The password is not case-sensitive by default. To make your password case-
sensitive, see Enforcing Case-Sensitive Universal Password For OpenText
Access Manager.
Intruder Detection: The admin user is created in the novell container. You
should set up an intruder detection policy for this container. In Administration
Console, select the Roles and Tasks view in the iManager header, then click
Directory Administration > Modify Object. Select novell, then click OK. Click
Intruder Detection.
Backup Admin User Creation: Only one admin user is created when you install
Access Manager Appliance. If you forget the username or password, you cannot
access Administration Console. It is recommended that you create a backup
user who has the required privileges of an admin user. For more information, see
Managing administrators.
Delegated Administrators: If you create delegated administrators for policy
containers, ensure that they have sufficient rights to implement a cross-site
scripting attack using the Deny Message in an Access Gateway Authorization
policy.
They are also granted rights to the LDAP server, which gives them sufficient
rights to access the configuration datastore with an LDAP browser. Modifications
done with an LDAP browser are not logged by Access Manager.

Enforcing Case-Sensitive Universal Password For

OpenText Access Manager

This PDF was generated on October 23, 2025 Page 11 of 127

 Access Manager Appliance 25.2

Making the passwords case-sensitive adds to the security of the login to OpenText
Access Manager. For example, if you have a password aBc that is case-sensitive, all
the trials of login with the combinations like abc or Abc or ABC would fail.
Procedure for Setting Your Password Case-Sensitive
1. Log into Administration Console.
2. Click username on the top right corner of the page.
3. Installing Plug-in:
1. Click Plug-in Installation > Available netiq Plug-in Modules.
2. Select Password Management.
3. Click Install.
4. Click I agree and click OK.
5. Restart Administration Console after the installation is complete.
6. Log into Administration Console.
7. Click <username> from the top right corner of the page.
4. Assigning a Policy to an Object:
1. Click Manage Roles & Tasks.
2. Select Passwords > Password Policies.
3. Click None from Assignments column entry.
4. Browse to select an object.
5. Click Apply. You can see that novell is reflecting in the Assignments
columns now.

Note
When you log into Administration Console for the first time after
setting the password policy and specify a new case-sensitive
password, that password becomes your new password.

This PDF was generated on October 23, 2025 Page 12 of 127

 Access Manager Appliance 25.2

1.2.4. Protecting the Configuration Store

The configuration store is an embedded, modified version of eDirectory. It is backed
up and restored with command line options, which back up and restore the Access
Manager Appliance configuration objects in the
ou=accessManagerContainer.o=novell object.
You should back up the configuration store on a regular schedule, and store the ZIP
file created in a secure place.
In addition to backing up the configuration store, you should also install at least two
Administration Consoles (a primary and a secondary). If the primary console goes
down, the secondary console can keep the communication channels open between
the various components. You can install up to three Administration Consoles.
It is not recommended to use the configuration store as a user store.

This PDF was generated on October 23, 2025 Page 13 of 127

 Access Manager Appliance 25.2

1.2.5. Securing Configuration Store Using

TLS Port
By default the OpenText Access Manager config store has FIPS mode enabled and an
RSA certificate associated with it. This disables SSLv3 and allows only TLS 1.0, 1.1 and
1.2 clients to connect.
To allow Administration Console to connect with config store on TLSv1.1 and TLSv1.2,
perform the following steps:
1. Install the LDAP plug-in to list it in the default iManager page (Roles and Tasks).
2. Ensure FIPS mode is enabled.
Ensure the line [Link].fips_tls=1 is in the
/etc/opt/novell/eDirectory/conf/[Link] file.

Note
After enabling FIPS mode, you must restart eDirectory (ndsd)
daemon.

3. Click Admin > Manage Roles and Tasks.

4. Navigate to LDAP > LDAP Options > View LDAP Servers.

Note
To access LDAP Options, you have to use the iManager from a
differenct eDirectory server of the standalone version. Install the
edirectory90 Plugins from the iManager Plug-in repository.

5. Select the OpenText Access Manager server, then click the Connections tab.
6. Under the SSL Configuration section select only TLSv1.1 and TLSv1.2. The
settings for other sections on the page do not require any change.
7. Save the configuration and restart the LDAP server from Administration Console
using the following commands:
ndstrace -c "unload nldap"

This PDF was generated on October 23, 2025 Page 14 of 127

 Access Manager Appliance 25.2

ndstrace -c "load nldap"

8. Restart Tomcat by running the /etc/init.d/novell-ac restart command.

This PDF was generated on October 23, 2025 Page 15 of 127

 Access Manager Appliance 25.2

1.2.6. Running the DHost HTTP Server on

localhost
The DHost HTTP server running on HTTP port 8028 and HTTPS port 8030 does not
set the X-Frame-Options HTTP Response Header. Therefore, it is prone to
clickjacking attacks. To prevent the vulnerabilities, it is recommended to restrict the
DHost HTTP Server to localhost.
Perform the following steps to configure the DHost server to run on localhost:
1. In Administration Console, open /etc/opt/novell/eDirectory/conf/[Link] .
2. Search for the following lines and then replace the IP address (for example,
[Link]) with [Link]:

[Link]=[Link]@8028

[Link]=[Link]@8030

After the change these lines will look as follows:

[Link]=[Link]@8028

[Link]=[Link]@8030

3. Restart the eDirectory services:

/etc/init.d/ndsd restart

This PDF was generated on October 23, 2025 Page 16 of 127

 Access Manager Appliance 25.2

1.2.7. Preventing the SWEET32 Attack

In the SWEET32 attack, a remote attacker can obtain sensitive information by
recovering portions of the plaintext data when encrypted with 64-bit block ciphers
(such as Triple-DES).
To prevent this attack, you need to modify the cipher list in the [Link] files of
Administration Console and Identity Server as follows:

ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-
ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-
CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-
GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

For information about how to modify a configuration file, see Modifying

configurations.

This PDF was generated on October 23, 2025 Page 17 of 127

 Access Manager Appliance 25.2

1.2.8. Default Security Settings in

Configuration Files
[Link]
These settings are configured in NIDP_Name="devman" and
NIDP_Name="connector" attributes inside the Connector element.
For the list of all default ciphers supported by OpenText Access Manager
Administration Console, see Default Ciphers for Administration Console

<Connector NIDP_Name="connector" SSLEnabled="true"

URIEncoding="utf-8
"acceptCount="100" address="[Link]"
ciphers="TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256" clientAuth="false"
disableUploadTimeout="true" enableLookups="false"
keystoreFile="/opt/novell/
devman/jcc/certs/idp/[Link]"
keystorePass="xxxxxxxxxxxxxxx"
maxThreads="200" minSpareThreads="5" port="8443" scheme="https"
secure="true"
sslImplementationName="[Link]
" useServerCipherSuitesOrder="true" sslProtocol="TLSv1.2"
sslEnabledProtocols="SSLv2Hello,TLSv1.1,TLSv1.2" />

For more information about connector attributes, see Apache Tomcat Configuration
Reference.

This PDF was generated on October 23, 2025 Page 18 of 127

 Access Manager Appliance 25.2

You can modify this file using Advanced File Configurator. See Advanced file
configurator.

Note
When you install OpenText Access Manager 5.0 and the value of
sslProtocol is TLS instead of TLSv1.2 , change the value from TLS to
TLSv1.2 .

Important
OpenText Access Manager supports and recommends TLSv1.2. You can
reconfigure to use the earlier versions of TLS if required. However, due to
cipher block chaining (CBC), using TLSv1.0 or earlier makes the
environment vulnerable to the BEAST attack. This attack exploits the
vulnerability at the client-side. TLS 1.1, TLS 1.2, and other cipher suites
that do not use the CBC mode are not vulnerable to this attack.
OpenText Access Manager supports and enforces TLSv1.2 for all port.

[Link]

This PDF was generated on October 23, 2025 Page 19 of 127

 Access Manager Appliance 25.2

<filter> <filter-name>
httpHeaderSecurity
</filter-name> <filter-class>
[Link]
</filter-class> <async-supported>
true
</async-supported> <init-param>
<param-name>hstsMaxAgeSeconds</param-name>
<param-value>31536000</param-value>
</init-param>

<init-param>
<param-name>antiClickJackingOption</param-name>
<param-value>SAMEORIGIN</param-value>
</init-param></filter>
<filter-mapping>
<filter-name>httpHeaderSecurity</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>

You can modify this file using Advanced File Configurator. See Advanced file
configurator.

Note
You can add these filters at any location in [Link] as long as it is not
within any existing tag.

[Link]
JAVA_OPTS="${JAVA_OPTS} -
[Link]=false"

JAVA_OPTS="${JAVA_OPTS} -
[Link]=true"

This PDF was generated on October 23, 2025 Page 20 of 127

 Access Manager Appliance 25.2

JAVA_OPTS="${JAVA_OPTS} -[Link]=2048"

You can modify this file using Advanced File Configurator. See Advanced file
configurator.

This PDF was generated on October 23, 2025 Page 21 of 127

 Access Manager Appliance 25.2

1.2.9. Configuring ciphers for the Upgrade

Assistant agent and the internal
communication
You can configure the ciphers to each device's Identity Provider (IDP),
Administration Console (AC), and Access Gateway (AG).
Perform the following to configure the ciphers:
1. Add the TLS_DHE_RSA_WITH_AES_128_CBC_SHA ciphers
to /opt/netiq/common/jre/conf/security/[Link] file. See the following:

[Link]=MD2, MD5, SHA1 jdkCA & usage

TLSServer, \
RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, \
SHA1 usage SignedJAR & denyAfter 2019-01-01, \
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, \
include [Link]

2. Add the strong ciphers to the /opt/novell/nam/ua_agent/secure/[Link]

file.

[Link]=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS
_ECDHE_RSA_WITH_AES_256_GCM_SHA384
[Link]-protocols=TLSv1.2,TLSv1.3

Note
Remove any weak ciphers configured from the [Link] file ,
if required.

3. Restart the services in each device using the following commands:

AC
systemctl restart [Link]
/etc/init.d/novell-ac restart

This PDF was generated on October 23, 2025 Page 22 of 127

 Access Manager Appliance 25.2

IDP
systemctl restart [Link]
rcnovell-jcc restart
rcnovell-idp restart

MAG
systemctl restart [Link]
rcnovell-jcc restart
rcnovell-mag restart

This PDF was generated on October 23, 2025 Page 23 of 127

 Access Manager Appliance 25.2

1.3. Securing Identity Server

In this Section
Disabling Unused Authentication Protocols
Configuring SSL Communication between Browsers and Identity Server
Configuring SSL Communication with Identity Server and a Service Provider
Securing Authentication by Using Strong and Multi-Factor Authentication
Methods
Securing Federation
Configuring the allowed list of Target URL
Blocking Access to Identity Server Pages
Enabling Advanced Session Assurance
Securing Identity Server Web Service Interface
Enabling reCAPTCHA
Preventing the SWEET32 Attack
Detecting the Brute Force Attack
Restricting the Direct Access to Files in the nidp Folder
Preventing Cross-Site Request Forgery Attacks
Using the Device ID in the URN Cookie
Configuring the Cookie Secure Flag
Default Security Settings in Configuration Files

This PDF was generated on October 23, 2025 Page 24 of 127

 Access Manager Appliance 25.2

1.3.1. Disabling Unused Authentication

Protocols
You must disable any authentication protocol that is not in use. Enabling additional
protocols increases the attack surface area.
Go to Identity Servers > [cluster name] > Configuration > General and ensure to
deselect unused protocols in Enabled Protocols.

This PDF was generated on October 23, 2025 Page 25 of 127

 Access Manager Appliance 25.2

1.3.2. Configuring SSL Communication

between Browsers and Identity Server
See Enabling SSL between Browsers and Identity Server.

This PDF was generated on October 23, 2025 Page 26 of 127

 Access Manager Appliance 25.2

1.3.3. Configuring SSL Communication

with Identity Server and a Service
Provider
See Enabling SSL between Identity Server and a Service Provider.

This PDF was generated on October 23, 2025 Page 27 of 127

 Access Manager Appliance 25.2

1.3.4. Securing Authentication by Using

Strong and Multi-Factor Authentication
Methods
One of the strengths of OpenText Access Manager is its wide range of support for
various means of authentication that goes beyond simple and commonly used
username/password methods including multi-factor and step-up scenarios. OpenText
Access Manager includes many built-in preconfigured schemes via the combination
of classes, methods, and contracts that can be used as is or can be configured to
meet your needs. You can assign a contract directly to specific protected resources
or federation partners. For more sophisticated security needs, the contract can also
be dynamically chosen by Access Manager risk policies. Risk policies can allow
access, ask for step-up authentication, or deny access based on the risk calculated at
the time of the access request.
For more information about the OpenText Access Manager's risk-based
authentication feature, see Risk-based authentication.
The authentication contract, assigned directly or determined by risk policies, can
come from a variety of sources. Many are included with Access Manager itself. An
example of the third-party provider is RADIUS. If you need advance security or you
want to focus on both security and mobile users convenience, a variety of single and
multi-factor contracts of the Advanced Authentication solution integrated with
OpenText Access Manager is an ideal option.
For more information about configuring authentication methods, see Configuring
authentication.

Note
You must not use persistent authentication or social authentication for
applications that require high security. When using persistent
authentication, associate the persistent cookie with the client IP address.
For securing cookies to prevent session replay attacks, enable Advanced
session Assurance. For information, see Setting up session assurance.

Authentication Contracts
If you have set up OpenText Access Manager to require SSL connections among all of
its components, delete the Name/Password - Form and Name/Password - Basic

This PDF was generated on October 23, 2025 Page 28 of 127

 Access Manager Appliance 25.2

contracts. Deleting the contracts removes them from the list of available contracts to
be assigned to protected resources. If these contracts are assigned, the user’s
password can be sent across the wire in the clear text format. You can re-create
these when required. To delete these contracts, go to Administration Console and
click Identity Servers > [cluster name] > Authentication > Contracts.
If you use password-based authentication, you can make it more secure by using
second-factor authentication methods such as TOTP method or Advanced
Authentication methods in the contract.
You can configure advanced authentication by using Advanced Authentication
methods. For information, see Multi-Factor Authentication Using Advanced
Authentication.

This PDF was generated on October 23, 2025 Page 29 of 127

 Access Manager Appliance 25.2

1.3.5. Securing Federation

You can secure your federation relationships in numerous ways. The methods
available are defined within federation protocols themselves. The method you want to
use must be agreed upon by both members of a federation relationship. Specifically,
this agreement is required between the identity provider (most often OpenText
Access Manager’s role) and the service provider (for example, a SaaS service).
The most commonly used means of security includes using HTTPS for
communication between parties secured by well-known CA certificates. For
information about how to enable HTTPS in OpenText Access Manager Identity Server,
see Enabling SSL between Identity Server and a Service Provider.
Another way for SAML is the signing and/or encryption of assertions. For more
information, see Configuring the Encryption Method for the SAML Assertion. SAML
also has options for communicating the assertion data between parties known as
protocol bindings. Protocol bindings include Post and Artifact. The Post binding is
currently simplest and most popular among SaaS vendors and is typically secured
using HTTPS, assertion signing, and encryption. The Artifact binding is considered
more secure, but its level of security is not always required for a federation
relationship.
Post method versus exchange artifacts: When you set up a federation between an
identity provider and a service provider, you can select either to exchange assertions
with a post method or to exchange artifacts.
An assertion in a post method might contain the user’s password or other sensitive
data, which can make it less secure than an artifact when the assertion is sent to the
browser.
An artifact is a randomly generated ID, it contains no sensitive data. Only the intended
receiver can use it to retrieve assertion data.
If both providers support artifacts, you should select this method because it is more
secure. For more details, see the Response protocol binding option in Configuring a
SAML 2.0 authentication request and Configuring a SAML 2.0 authentication
response.

Note
To use exchange artifact, the service provider needs to establish a direct
communication channel with the identity provider.

This PDF was generated on October 23, 2025 Page 30 of 127

 Access Manager Appliance 25.2

Additional SAML protocol options might also need to be configured and matched
between the identity provider and service provider. Common options are covered
later in this section.

Setting Options
Go to Identity Servers > Servers > Edit > SAML 2.0 > Service Provider > Options
and set up the following options for a service provider:
SAML2 SIGN METHODDIGEST SHA256: By default, this option is enabled.
Assertions use the SHA 256 algorithm as a hashing algorithm for the service
provider. You can disable this option by selecting false.
SAML2 POST SIGN RESPONSE TRUSTEDPROVIDERS:Select true. The identity
provider will sign the entire SAML 2.0 response for the service provider.
SAML2 AVOID AUDIENCE RESTRICTION: Select true to avoid sending the
audience restriction information with assertion to this service provider.
IS SAML2 POST SIGN RESPONSE: Select true to enable the identity provider to
send signed SAML 2.0 post responses to all its trusted providers.

Note
Configuring IS SAML2 POST SIGN RESPONSE is same as
configuring the SignPost in [Link] . However, configuring it
through Administration Console is recommended because it
provides more options. You can combine these options with IS
SAML2 POST SIGN RESPONSE to avoid OpenText Access
Manager's restart.

Configuring the Encryption Method for the SAML

Assertion
By default, AES128 (Advanced Standard Encryption, 128-bit) is used to encrypt SAML
assertions. If you require a different encryption method, such as AES256 (Advanced
Standard Encryption, 256-bit), you can modify the Tomcat [Link] file, and specify
the required method.
1. Open the Identity Server [Link] file.
2. Add the following lines to the file:

This PDF was generated on October 23, 2025 Page 31 of 127

 Access Manager Appliance 25.2

<context-param>
<param-name>EncryptionMethod</param-name>
<param-value>AES256</param-value>
</context-param>

You can set the <param-value> element to AES128 or AES256. Because

AES128 is the default, specifying this value in the [Link] file does not change
any behavior.
For information about how to edit a file, see Modifying configurations.
The following algorithms for encryption method are supported:
<md:EncryptionMethod Algorithm="[Link]
cbc"/><md:EncryptionMethod
Algorithm="[Link]
<md:EncryptionMethod Algorithm="[Link]
<md:EncryptionMethod Algorithm="[Link]
mgf1p"/>

This PDF was generated on October 23, 2025 Page 32 of 127

 Access Manager Appliance 25.2

1.3.6. Configuring the allowed list of

Target URL
URL redirection, which many applications and services require, inherently brings in
security risks. While redirecting, the request can be tampered to redirect users to an
external, malicious site. To prevent such issues, you can configure a list of
permissible domains. Redirection is allowed only to the configured domains.

Configuring the global allowed list of Target URL

1. On the Home page, click Identity Servers > Edit > Identity Providers.
2. Under Allowable Redirection Domains, click the Plus icon.
3. Specify Domain.
You can specify a domain name with an asterisk wildcard character (*) that
represents the entire DNS subtree. For example, specifying *.[Link]
as a domain will allow redirection to all children domain under
[Link] including [Link] . The WWW prefix is not
required. You can specify the * wildcard only at the lowest level of the subtree.
For example: Valid domain name: *.[Link]
Invalid domain name: innerweb.*. com You must configure at least one domain
to prevent open redirection.
WS-Fed: The wreply parameter is filtered. If the requested wreply is not in the
white list, the Identity Server does not login. However, if wreply is same as the
provider's single logout or single sign-on URL domain, the request is accepted.
SAML 2.0: For idpsend, the target parameter is filtered using this list. This list is
not applicable for spsend.

Configuring the allowed list of Intersite Transfer

Service Target URL
1. On the Home page, click Identity Servers > Edit > [SAML1.1, or SAML 2.0] >
[Service Provider] > Intersite Transfer Service.
2. In the Domain List, click New.
3. Specify the domain name.

This PDF was generated on October 23, 2025 Page 33 of 127

 Access Manager Appliance 25.2

The domain name must be a full domain name, such as

[Link] . Wildcard domain names, such as
[Link].*.com , do not work.

Configuring the allowed list of Assertion Consumer

Service URL
When an authentication request from a service provider is not signed, Identity Server
cannot validate the authenticity and integrity of the request. So, any intruder can
intercept the request and change the Assertion Consumer Service URL in the request
and make the Identity Server to send the assertion to malicious sites.
To secure and validate the authentication request from a service provider, you can
use the following options in the service provider configuration of Identity Server:
SAML2_ACS_URL_RESTRICT: This option ensures that Identity Server must
validate the Assertion Consumer Service URL in the request against the trusted
metadata URL before sending the assertion. If the Assertion Consumer URL in
the authentication request is tampered by any malicious user, Identity Server
terminates the request and assertion is not sent.
SAML2_ACS_DOMAIN_WHITELIST:This option ensures that Identity Server
must validate the Assertion Consumer URL in the request against a whitelist of
domains. If the Assertion Consumer Service URL does not match with any of the
domain URLs in the whitelist, Identity Server terminates the request.
You must define the SAML2_ACS_DOMAIN_WHITELIST along with
SAML2_ACS_URL_RESTRICT for a service provider in Identity Server.
SAML2_ACS_DOMAIN_WHITELIST does not work if
SAML2_ACS_URL_RESTRICT is not enabled.
To define these options, perform the following steps:
1. On the Home page, click Identity Servers > <Cluster> > Edit > SAML 2.0.
2. Select the required service provider.
3. Click Options > New.
4. Select OTHER and specify the following properties:

This PDF was generated on October 23, 2025 Page 34 of 127

 Access Manager Appliance 25.2

Property Name Property Value Description

SAML2_ACS_URL_RES True Identity Server allows

TRICT authentication only to
the trusted ACS URLs.

SAML2_ACS_DOMAIN_ Domain names Identity Server

WHITELIST separated with semi- performs additional
colon (;) validation of the
authentication request
with the ACS domain
whitelist.

Configuring the allowed list of URLs for RelayState

URL
Enabling the Use Introductions option for an identity provider might result in the Open
Redirect vulnerability. To prevent this vulnerability, perform the following steps:
1. Create the [Link] file and add the exact URLs for which you
want to allow redirection.
For example, if you specify [Link] , all sub-domains
under this domain. Such as:
[Link]
[Link]
[Link]
If you specify [Link] , then any child
URL of this URL will be allowed. For example, [Link]
<domainname>.com/en-us/home/resources . However, [Link]
<domainname>.com will not be allowed.
2. Place [Link] to the /opt/novell/nids/lib/webapp/WEB-INF
folder by using Advanced File Configurator.
For information about how to add a file, see Adding configurations to a cluster.

This PDF was generated on October 23, 2025 Page 35 of 127

 Access Manager Appliance 25.2

3. Open the Identity Server [Link] file.

For information about how to edit a file, see Modifying configurations.
4. Uncomment the ‘RelayStateWhiteListFilter’ snippet:

<filter-name>RelayStateWhiteListFilter</filter-name>
<filter-
class>[Link]<
/filter-class>
<Description>This filter is used to whitelist relaystate
parameter for introductions. </description>
<init-param>
<param-name>configFile</param-name>
<param-value>[Link]</param-value>
</init-param>
<init-param>
<param-name>blackListRedirectPath</param-name>
<param-value>/nidp/app/logout</param-value>
</init-param>

5. Save the file.

This PDF was generated on October 23, 2025 Page 36 of 127

 Access Manager Appliance 25.2

1.3.7. Blocking Access to Identity Server

Pages
Authenticated users can access a few Identity Server pages. These pages contain
information about the user and Identity Server that can cause security issues.

This PDF was generated on October 23, 2025 Page 37 of 127

 Access Manager Appliance 25.2

1.3.8. Enabling Advanced Session

Assurance
Advanced Session Assurance enables you to prevent session replay attacks by
adding an additional layer of security to your sessions. When a session is established,
OpenText Access ManagerAppliance creates a unique fingerprint of the device from
which the session is established. During the session, at a configurable time interval,
OpenText Access Manager Appliance validates the session to ensure that the
fingerprint matches with that the device it originated from.
By default, in a fresh installation, Advanced Session Assurance is enabled for all
clusters.
However, in an upgraded setup, it is disabled by default. You must upgrade all nodes
in the cluster before enabling Advance Session Assurance.
For more information, see Setting up session assurance.

This PDF was generated on October 23, 2025 Page 38 of 127

 Access Manager Appliance 25.2

1.3.9. Securing Identity Server Web

Service Interface
By default, the web service interface of Identity Server
( /nidp/services/IDSISCredentialProfile?wsdl ) is accessible by everyone. Both
Identity Server and Access Gateway use this interface for updating credential profile
information. An attacker can use this information to bring down Identity Server.
You can prevent such issues by configuring the WSInterfaceFilter filter in the
[Link] file. You can modify the filter values, if required.
For information about how to edit a file, see Modifying configurations.
The following table lists parameters associated with the WSInterfaceFilter filter:

This PDF was generated on October 23, 2025 Page 39 of 127

 Access Manager Appliance 25.2

Parameter Description

activateWSFFirewall This activates the WSFFirewall filter.

Specify True to activate the filter.

shieldAllServices This specifies whether to shield all web

services at /nidp/services or only
selected services by using values
True and False respectively.

wsfAcceptedDevicesIPList This is a comma separated list of IP

addresses that can access the
/nidp/services interface. No white
space is allowed.

wsURIList This is a comma separated list of web

services who can access to the web
service when shieldAllServices is set
to False . No whitespace is allowed.
For example, to filter requests for the
<host>/nidp/services/IDSISAuthentica
tionProfile service, specify
IDSISAuthenticationProfile as param-
value for wsURIList . Both WSDL and
the actual service will be placed behind
the firewall.

Note
For certain web services, administrators can also specify a policy from
Administration Console. If a policy is defined for a service that is in the
wsURIList list, the policy is executed after passing this filter. For more
information, see Blocking access to the WSDL services page.

This PDF was generated on October 23, 2025 Page 40 of 127

 Access Manager Appliance 25.2

Once you configure the filters, restart Tomcat by running the following commands:
/etc/init.d/novell-idp restart
or
systemctl restart [Link]

This PDF was generated on October 23, 2025 Page 41 of 127

 Access Manager Appliance 25.2

1.3.10. Enabling reCAPTCHA

OpenText Access Manager supports only the invisible reCAPTCHA version of
reCAPTCHA. reCAPTCHA works on both Name/Password – Form and Secure
Name/Password – Form authentication.
reCAPTCHA provides an additional layer of security by requesting users to confirm
that they are not a robot. It displays images that users must select based on a
matching criteria. If a response succeeds, OpenText Access Manager authenticates
the user’s authentication credentials. If a response fails, OpenText Access Manager
does not authenticate the user credentials, and redirects to the login page.

Note
By default, reCAPTCHA is disabled. Before enabling this feature, verify
your privacy statement. Some regions may consider it a privacy issue.

For more information, see Specifying common class properties > Enabling
reCAPTCHA ” in Enabling reCAPTCHA.

This PDF was generated on October 23, 2025 Page 42 of 127

 Access Manager Appliance 25.2

1.3.11. Preventing the SWEET32 Attack

See Preventing the SWEET32 Attack.

This PDF was generated on October 23, 2025 Page 43 of 127

 Access Manager Appliance 25.2

1.3.12. Detecting the Brute Force Attack

When you enable the RequestLogger filter in the [Link] file, the debug information
for each request, including the source IP address is recorded. You can check log
messages and identify the IP address of the attacker and block these IP addresses.
This filter logs the client IP addresses of WS Trust, WS-Fed request. This filter is not
required for logging client IP addresses of SAML requests.
Perform the following steps to enable the RequestLogger filter:
1. Modify Identity Server’s [Link].
2. Uncomment the following snippet:

<filter>
<filter-name>RequestLogger</filter-name>
<filter-
class>[Link]</
filter-class>
</filter>
<filter-mapping>
<filter-name>RequestLogger</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

For information about how to modify a configuration file, see Modifying

configurations.

This PDF was generated on October 23, 2025 Page 44 of 127

 Access Manager Appliance 25.2

1.3.13. Restricting the Direct Access to

Files in the nidp Folder
For security purposes, direct access to [Link] and extern/dist/lib/ files
available in the nidp folder is restricted by default. You can remove the restriction by
commenting the <security-constraint> tag in the [Link] file.
If you want to restrict access to any other file in the nidp folder, perform the
following steps:
1. Open the Identity Server [Link] file.
For information about how to edit a file, see Modifying configurations.
2. Under the <security-constraint> tag, add <url-pattern> or <path of the file>
that you want to hide from the direct access.
The following is an example snippet:

<security-constraint>
<web-resource-collection>
<web-resource-name>Include files</web-resource-name>
<description>No direct access to include files.
</description>
<url-pattern>/[Link]</url-pattern>
<url-pattern>/extern/dist/lib/*</url-pattern>
<http-method>POST</http-method>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint />
</security-constraint>

3. Save the file.

This PDF was generated on October 23, 2025 Page 45 of 127

 Access Manager Appliance 25.2

1.3.14. Preventing Cross-Site Request

Forgery Attacks
The CSRFDetectionFilter filter verifies all requests to detect and mitigate any Cross-
Site Request Forgery (CSRF) attempts. By default, this filter is disabled.
This filter verifies for a session-wide anti-CSRF token that is expected in each request
as a form parameter or a query parameter. If the token is not found, the filter matches
the referrer header in the request with the server host and any configured exclusions.
When CSRF is detected in the request, Identity Server throws the HTTP 400 Bad
Request error. When logging is enabled, you can check the reasons in the log file
([Link]).
Perform the following steps to enable this filter:
1. Open the Identity Server [Link] file.
For information about how to edit a file, see Modifying configurations.
2. Locate and uncomment the following snippet:

This PDF was generated on October 23, 2025 Page 46 of 127

 Access Manager Appliance 25.2

<!--<filter>
<filter-name>CSRFDetectionFilter</filter-name>
<filter-
class>[Link]
ter</filter-class>
<description> This filter is used to detect CSRF attacks
in NIDS, for an authenticated session</description>
<init-param>
<param-name>active</param-name>
<param-value>False</param-value>
</init-param>
<init-param>
<param-name>exclude</param-name>
<param-value>metadata</param-value>
</init-param>
<init-param>
<param-name>RefererWhitelist</param-name>
<param-value></param-value>
</init-param>
<init-param>
<param-name>RequestWhitelist</param-name>
<param-value>GET</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CSRFDetectionFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
-->

The following table lists parameters required for this filter:

This PDF was generated on October 23, 2025 Page 47 of 127

 Access Manager Appliance 25.2

Parameter Description

active You must set this to True to enable

the filter. By default, this is set to
False.

exclude Specify the coma-separated paths

you want to exclude in the
verification by the
CSRFDetectionFilter filter.
For example,

<init-param>
<param-
name>exclude</param-name>
<param-
value>metadata,saml2</para
m-value>
</init-param>

RefererWhitelist Specify the coma-separated domain

or hostname that you want to
exclude in the verification by the
CSRFDetectionFilter filter.
For example,

<init-param>
<param-
name>RefererWhitelist
</param-name>
<param-
value>[Link],[Link]
.com</param-value>
</init-param>

This PDF was generated on October 23, 2025 Page 48 of 127

 Access Manager Appliance 25.2

RequestWhitelist Specify the coma-separated REST

methods that you want to exclude in
the verification by the
CSRFDetectionFilter filter. By
default, GET is included in the filter.
For example,

<init-param>
<param-
name>RequestWhitelist
</param-name>
<param-
value>GET,POST</param-
value>
</init-param>

3. Save the file.

To Enable the CSRF Verification for the Password Class and TOTP Class
OpenText Access Manager provides an option LOGIN CSRF CHECK to verify CSRF
attempts for the Password class and TOTP class. This is applicable for default pages.
If you have modified any page, you must add the anti-CSRF token to the page.
For information about how to enable this property, see “Managing a cluster of Identity
Servers > Configuring Identity Server Global Properties .

This PDF was generated on October 23, 2025 Page 49 of 127

 Access Manager Appliance 25.2

1.3.15. Using the Device ID in the URN

Cookie
In an OpenText Access Manager environment with multiple Identity Servers and
Access Gateways, a cluster cookie (UrnNovellNidpClusterMemberId) is automatically
set for the serving node of the cluster. When requests come to Identity Server or
Embedded Service Provider (ESP), this cookie is used by all nodes of the cluster to
perform the proxying, if necessary.
For higher security, it is recommended to enable the USE DEVICE ID IN URN COOKIE
property in Identity Server and Access Gateway. When this property is enabled,
instead of obfuscation, hashing is used for the cookie value.
For information about how to enable this property, see Managing a cluster of Identity
Servers > Configuring Identity Server Global Properties and Managing reverse
proxies and authentication > Configuring ESP Global Options”.

This PDF was generated on October 23, 2025 Page 50 of 127

 Access Manager Appliance 25.2

1.3.16. Handling Query Parameters in an

Authentication Request

This PDF was generated on October 23, 2025 Page 51 of 127

 Access Manager Appliance 25.2

1.3.17. Configuring the Cookie Secure Flag

Identity Server sets the cookie Secure flag by default. In some cases, the cookie
Secure flag is not set because of which the cookie can be transmitted over an
insecure connection. This leads to a risk where others can access the cookie
information. This scenario occurs when Tomcat automatically sets the JSESSIONID
cookie multiple times.
To mitigate the risk, you must configure the cookie Secure flag. Configuring the
Secure flag ensures that the cookie is transmitted over a secure HTTPS connection.
1. Open the Identity Server [Link] file.
For information about how to edit a file, see Modifying configurations.
2. Add the following entry:

<session-config>
<cookie-config>
<secure>true</secure>
</cookie-config>
</session-config>

This PDF was generated on October 23, 2025 Page 52 of 127

 Access Manager Appliance 25.2

1.3.18. Default Security Settings in

Configuration Files
[Link]
These settings are configured in NIDP_Name="devman" and
NIDP_Name="connector" attributes inside the Connector element.
For the list of all default ciphers supported by Access Manager Identity Server, see
Default Ciphers for Identity Server
You can modify this file using Advanced File Configurator. See Advanced file
configurator.

<Connector NIDP_Name="connector" SSLEnabled="true"

URIEncoding="utf-8"
acceptCount="100" address="[Link]"
ciphers="TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_1
28_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_2
56_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_S
HA256,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC
_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_DHE_RSA_WITH_AES_128_CBC_SHA
256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256" clientAuth="false"
disableUploadTimeout="true" enableLookups="false"
keystoreFile="/opt/novell/
devman/jcc/certs/idp/[Link]"
keystorePass="xxxxxxxxxxxxxxx"
maxThreads="600" minSpareThreads="5" port="8443" scheme="https"
secure="true"
sslImplementationName="[Link].N
IDPSSLImplementati
on" useServerCipherSuitesOrder="true" sslProtocol="TLSv1.2"
sslEnabledProtocols="SSLv2Hello,TLSv1.1,TLSv1.2" />

This PDF was generated on October 23, 2025 Page 53 of 127

 Access Manager Appliance 25.2

For information about connector attributes, see Apache Tomcat Configuration

Reference.

[Link]
<filter>
<filter-name>
httpHeaderSecurity
</filter-name>
<filter-class>
[Link]
</filter-class>
<async-supported>
true
</async-supported>
<init-param>
<param-name>hstsMaxAgeSeconds</param-name>
<param-value>31536000</param-value>
</init-param>
<init-param>
<param-name>antiClickJackingOption</param-name>
<param-value>SAMEORIGIN</param-value>
</init-param></filter>
<filter-mapping>
<filter-name>httpHeaderSecurity</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>

Note
You can add these filters at any location in the [Link] if it is not within
any existing tag.

You can modify this file using Advanced File Configurator. See Advanced file
configurator.

[Link]

This PDF was generated on October 23, 2025 Page 54 of 127

 Access Manager Appliance 25.2

JAVA_OPTS="${JAVA_OPTS} -
[Link]=false"
JAVA_OPTS="${JAVA_OPTS} -
[Link]=true"
JAVA_OPTS="${JAVA_OPTS} -[Link]=2048"

You can modify this file using Advanced File Configurator. See Advanced file
configurator.

This PDF was generated on October 23, 2025 Page 55 of 127

 Access Manager Appliance 25.2

1.4. Securing Access Gateway

In this Section
Enabling Secure Cookies
Disabling Phishing
Disabling Weak Protocols between Access Gateway and Web Servers
Configuring Stronger Ciphers for SSL Communication between Access Gateway
and Web Servers
Enabling Perfect Forward Secrecy
Preventing Error Messages to Show the Failure Reason on Browsers
Enabling Advanced Session Assurance
Preventing the Slowloris Attack
AJP Communication Setting for Access Gateway
Using the Device ID in the URN Cookie
Default Security Settings in Configuration Files

This PDF was generated on October 23, 2025 Page 56 of 127

 Access Manager Appliance 25.2

1.4.1. Enabling SSL Communication

between Access Gateway and Identity
Server

This PDF was generated on October 23, 2025 Page 57 of 127

 Access Manager Appliance 25.2

1.4.2. Enabling Secure Cookies

Access Gateway and Embedded Service Provider (ESP) of Access Gateway both use
session cookies in their communication with the browser. You must protect these
session cookies to prevent from being intercepted by hackers.

Note
You can enable secure Access Gateway session cookies when only SSL
resources exist. If a mix of HTTP and HTTPS proxy services exist, you
cannot enable it as it is a global setting.

Securing the Embedded Service Provider Session

Cookie
An attacker can spoof a non-secure browser into sending a JSESSION cookie that
contains a valid user session. This might happen because Access Gateway
communicates with its ESP on port 9009, which is a non-secure connection. Because
ESP does not know whether Access Gateway is using SSL to communicate with the
browsers, ESP does not mark the JSESSION cookie as secure when it creates the
cookie. Access Gateway receives the Set-Cookie header from ESP and passes it to
the browser as a non-secure clear-text cookie. If an attacker spoofs the domain of
Access Gateway, the browser sends the non-secure JSESSION cookie over a non-
secure channel where the cookie might be sniffed.
To stop this, you must first configure Access Gateway to use SSL. See Enabling SSL
between Browsers and Access Gateway.
After configuring SSL, you must perform the following steps to configure Tomcat to
secure the cookie:
1. Open the Access Gateway [Link] file.
2. Search for the connector on port 9009.
3. Add the following parameter within the Connector element:

secure="true"

For information about how to edit a file, see Modifying configurations.

This PDF was generated on October 23, 2025 Page 58 of 127

 Access Manager Appliance 25.2

Note
This file is specific to each cluster. Therefore, while applying the changes
from this file, the keystore password is retained in each cluster.

Preventing Automatically Changing Session ID

1. On the Home page, click Access Gateways > Edit > Reverse Proxy /
Authentication > ESP Global Options.
2. Set RENAME_SESSIONID to false. By default, this is set to true.
3. Restart Tomcat on each Identity Server in the cluster.

Securing the Proxy Session Cookie

Proxy session cookies store authentication information and other information in the
temporary memory that is shared between the browser and the proxy. These cookies
are deleted when the browser is closed. However if these cookies are sent through a
non-secure channel, hackers might intercept the cookies and impersonate a user on
websites. you can use the following configuration options:
Setting an Authentication Cookie with a Secure Keyword for HTTP
Preventing Cross-Site Scripting Vulnerabilities

Setting an Authentication Cookie with a Secure Keyword for

HTTP
You can configure Access Gateway to force the HTTP services to authenticate the
cookie set with the keyword secure.
To enable this option, perform the following steps:
1. On the Home page, click Access Gateways > Edit > Reverse Proxy /
Authentication.
2. Select Enable Secure Cookies.
This option is used to secure a cookie when Access Gateway is placed behind an SSL
accelerator, such as the Cisco SSL accelerator, and Access Gateway is configured to
communicate by using only HTTP.
Preventing Cross-Site Scripting Vulnerabilities

This PDF was generated on October 23, 2025 Page 59 of 127

 Access Manager Appliance 25.2

Cross-site scripting vulnerabilities in web browsers allow malicious sites to grab

cookies from a vulnerable site. Intruders might perform session fixation or
impersonate the valid user. You can configure Access Gateway to set its
authentication cookie with the HttpOnly keyword to prevent scripts from accessing
the cookie.
To enable this option, perform the following steps:
1. On the Home page, click Access Gateways > Edit > Reverse Proxy /
Authentication.
2. Select Force HTTP-Only Cookies.

This PDF was generated on October 23, 2025 Page 60 of 127

 Access Manager Appliance 25.2

1.4.3. Disabling Phishing

You can configure Access Gateway ESP to disable the ESP phishing by implementing
a context parameter in the [Link] file for ESP.
1. Open the ESP [Link] file.
2. Add the following entry:

<context-param>
<param-name>phishingCheck</param-name>
<param-value>standard</param-value>
</context-param>

You can set the parameter value as standard or off .

For information about how to edit a file, see Modifying configurations.

This PDF was generated on October 23, 2025 Page 61 of 127

 Access Manager Appliance 25.2

1.4.4. Disabling Weak Protocols between

Access Gateway and Web Servers
See the overview of Strengthening TLS/SSL Settings for information about weak
protocols.
To restrict Access Gateway to communicate with backend web servers only using
TLS 1.1 and TLS 1.2 protocols, set the following advanced options:
On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] >
[Name of Proxy Service] > Advanced Options and set SSLProxyProtocol
TLSv1.1 +TLSv1.2
While setting the protocol, ensure that the web server supports the configured
protocol. For example, if Access Manager supports TLS1.1, but the web server
does not support that, the connection will fail.
On the Home page, click Access Gateways > Edit > Advanced Options, and set
SSLProtocol -SSLV2 -SSLV3 -TLSv1 -TLSv1.1 +TLSv1.2
For more information about SSLProxyProtocol directives, see SSLProxyProtocol
Directive documentation.

This PDF was generated on October 23, 2025 Page 62 of 127

 Access Manager Appliance 25.2

1.4.5. Configuring Stronger Ciphers for

SSL Communication between Access
Gateway and Web Servers
See the overview of Strengthening TLS/SSL Settings for information about strong
ciphers.
1. On the Home page, click Access Gateways > Edit > Advanced Options.
2. Set the following advanced options:
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-RSA-AES256-SHA384:AES256-
SHA256:HIGH:MEDIUM:!LOW:!EXP:!SSLv2:!aNULL:!EDH:!ECDH:!ECDSA:!AE
SGCM:!eNULL:!NULL
While setting the cipher suite, ensure that the web server supports the
cipher suite. For example, if Access Manager supports ECDH ciphers, but
the web server does not support it, the connection fails.
You can configure SSLCipherSuite option as follows to get the A+ rating while
validating with SSLLabs. However, this setting might affect performance.

SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-
AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-
AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-
CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-
GCM-SHA384

To suppress the Sweet32 vulnerability, modify the Access Gateway configuration and
disable 3DES. For example:

SSLCipherSuite !3DES:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-
AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-
AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-
CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-
SHA384

OR

This PDF was generated on October 23, 2025 Page 63 of 127

 Access Manager Appliance 25.2

SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-
GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-
SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-
POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-
SHA384:!3DES

For the list of all default ciphers supported by Access Manager Access Gateway, see
Default Ciphers for Access Gateway

This PDF was generated on October 23, 2025 Page 64 of 127

 Access Manager Appliance 25.2

1.4.6. Enabling Perfect Forward Secrecy

Apache simplifies the process with the SSLHonorCipherOrder directive. This directive
indicates that Apache must respect the sequence of the encryption processes in
SSLCipherSuite that is the first match found must be used. With the SSLCipherSuite
list above and the SSLHonorCipherOrder on directive in place, Perfect Forward
Secrecy (PFS) is enabled.
On the Home page, click Access Gateways > Edit > Advanced Options and set the
following advanced options:

SSLHonorCipherOrder On
SSLCipherSuite
ECDH+AESGCM:ECDH+AES256:ECDH+AES128:ECDH+3DES:RSA+AESGCM:RSA+AES
:!aNULL:!DES:!MD5:!DSS

For information about PFS and prerequisites for enabling it, see Enabling Perfect
Forward Secrecy.

This PDF was generated on October 23, 2025 Page 65 of 127

 Access Manager Appliance 25.2

1.4.7. Preventing Error Messages to Show

the Failure Reason on Browsers
Whenever Identity Server reports a 500 internal error due to an invalid input, the
reason for failure is included in the response and visible on the browser.
This might cause a security issue as intruders can use this information to attack
against Identity Server and ESP.
Configure the [Link] file for ESP as follows:
1. Open the [Link] file.
2. Update the file as follows:

<welcome-file-list>
<welcome-file>[Link]</welcome-file>
</welcome-file-list>
<error-page>
<error-code>500</error-code>
<location>/[Link]</location>
</error-page>

[Link] can be any custom page. Similarly, you can configure [Link] for
error-code 404 by adding one more <error-page> tag. For information about
how to edit a file, see Modifying configurations.

This PDF was generated on October 23, 2025 Page 66 of 127

 Access Manager Appliance 25.2

1.4.8. Enabling Advanced Session

Assurance
Advanced Session Assurance enables you to prevent session replay attacks by
adding an additional layer of security to your sessions. When a session is established,
OpenText Access ManagerAppliancecreates a unique fingerprint of the device from
which the session is established. During the session, at a configurable time interval,
OpenText Access Manager Appliance validates the session to ensure that the
fingerprint matches with that the device it originated from.
By default, in a fresh installation, Advanced Session Assurance is enabled for all
clusters.
However, in an upgraded setup, it is disabled by default. You must upgrade all nodes
in the cluster to version 4.3 or later before enabling Advance Session Assurance.
Enable Advanced Session Assurance on the need basis. See Best practices for
enabling session assurance at the proxy service resource level.
For more information about Advanced Session Assurance and how to enable it, see
Setting up session assurance.

This PDF was generated on October 23, 2025 Page 67 of 127

 Access Manager Appliance 25.2

1.4.9. Preventing the Slowloris Attack

To secure your environment from the Slowloris attack, you can configure the
RequestReadTimeout option at the global and proxy service levels. This option sets
timeout values for the following actions:
Completing the TLS handshake
Receiving the request headers
Receiving the request body
Perform the following steps to configure the RequestReadTimeout option:
1. (Conditional) Modify the [Link] file using the Advanced File Configurator
and add the following in the LoadModule section:
LoadModule reqtimeout_module libexec/mod_reqtimeout.so
For more information about how to manage configuration files using Advanced
File Configurator, see Managing configuration files.
2. To configure the option at the global level, on the Home page, click Access
Gateways > Edit > Advanced Options.
3. To configure the option for a proxy service, on the Home page, click Access
Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] >
Advanced Options.
4. Add the option in the following format:

RequestReadTimeout [handshake=timeout[-maxtimeout]
[,MinRate=rate] [header=timeout[-maxtimeout][,MinRate=rate]
[body=timeout[-maxtimeout][,MinRate=rate]

For example, configure the option as follows to allow for 10 seconds to complete
the TLS handshake, 15 seconds to receive the request headers, and 30 seconds
for receiving the request body:

RequestReadTimeout handshake=10 header=15 body=30

5. Click OK.

This PDF was generated on October 23, 2025 Page 68 of 127

 Access Manager Appliance 25.2

For more information about this option, see RequestReadTimeout Directive.

Note
This option is not supported for path-based multi-homing proxy services.

This PDF was generated on October 23, 2025 Page 69 of 127

 Access Manager Appliance 25.2

1.4.10. AJP Communication Setting for

Access Gateway
By default, a constant passcode is used to communicate between HTTPD and
Tomcat. For higher security, you can change this passcode. You must change the
passcode in the httpd proxy service configuration file and the secret in
/opt/novell/nam/mag/conf/[Link] and /opt/novell/nam/idp/conf/[Link] .
To change the passcode in the HTTPD configuration file, perform the following steps:
1. On the Home page, click Access Gateways > Edit > Advanced Options.
2. Set the AJPToken <passcode> option and specify the passcode. For example,

AJPToken <new-passcode>

The following list includes the supported special characters:

&
[
]
|
{
}
^
\
`
"
<
>
3. Click OK.
To change the secret in the [Link] file, perform the following steps:
1. In /opt/novell/nam/mag/conf/[Link] and
/opt/novell/nam/idp/conf/[Link] , modify the value of secret in the AJP
protocol section.
The value must be the same as the passcode specified in the AJPToken <new-
passcode> option that you specified in Step 2.

This PDF was generated on October 23, 2025 Page 70 of 127

 Access Manager Appliance 25.2

<Connector port="9009" enableLookups="false"

redirectPort="8443" protocol="AJP/1.3" address="[Link]"
minSpareThreads="25" maxThreads="600" backlog="0"
connectionTimeout="20000" packetSize="65536"
maxPostSize="65536" secret="value" />

Note
Due to the tomcat restriction, special characters need to be
specified in a specific format. For example, to include & , specify
&amp;

To specify a special character in the value, refer to the following list:

This PDF was generated on October 23, 2025 Page 71 of 127

 Access Manager Appliance 25.2

To Use Specify

& &amp;

[ &#x5B;

] &#x5D;

| &#x7C;

{ &#x7B;

} &#x7D;

^ &#x5E;

\ &#x5C;

` &#x60;

" &#x22;

< &#x3C;

> &#x3E;

2. Save the file.

This PDF was generated on October 23, 2025 Page 72 of 127

 Access Manager Appliance 25.2

3. Restart Access Gateway and Identity Server.

Access Gateway: /etc/init.d/novell-mag restart
Identity Server: /etc/init.d/novell-idp restart

This PDF was generated on October 23, 2025 Page 73 of 127

 Access Manager Appliance 25.2

1.4.11. Using the Device ID in the URN

Cookie
See Using the Device ID in the URN Cookie.

This PDF was generated on October 23, 2025 Page 74 of 127

 Access Manager Appliance 25.2

1.4.12. Default Security Settings in

Configuration Files
ESP [Link]
<context-param>
<param-name>phishingCheck</param-name>
<param-value>standard</param-value>
</context-param>

<welcome-file-list>
<welcome-file>[Link]</welcome-file>
</welcome-file-list>

<error-page>
<error-code>500</error-code>
<location>/[Link]</location>
</error-page><filter>
<filter-name>TomcatSameOriginFilter</filter-name>
<filter-
class>[Link]
</filter-class>

<init-param>
<param-name>antiClickJackingOption</param-name>
<param-value>SAMEORIGIN</param-value>
</init-param>
</filter><filter-mapping>
<filter-name>TomcatSameOriginFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

You can modify this file using Advanced File Configurator. See Advanced file
configurator.

Access Gateway Advanced Options

This PDF was generated on October 23, 2025 Page 75 of 127

 Access Manager Appliance 25.2

SSLProtocol TLSv1.1 +TLSv1.2

SSLCipherSuite !aNULL:!eNULL:!EXPORT:!DSS:!DES:!RC4:ALL:!EDH

[Link]
The mod_headers library is enabled.
LoadModule headers_module libexec/mod_headers.so
You can modify this file using Advanced File Configurator. See Advanced file
configurator.

[Link]
The header set directive for the HSTS header is added at the bottom of the file:

Header always set Strict-Transport-Security "max-age=31536000;

includeSubDomains"

You can modify this file using Advanced File Configurator. See Advanced file
configurator.

This PDF was generated on October 23, 2025 Page 76 of 127

 Access Manager Appliance 25.2

1.5. Securing OpenText Access Manager

on Docker

This PDF was generated on October 23, 2025 Page 77 of 127

 Access Manager Appliance 25.2

1.5.1. Deployment considerations for

Kubernetes
See Deployment considerations.
Ensure that you have secured the Kubernetes cluster from any accidental or malicious
access. For more information, see Securing a Cluster.

This PDF was generated on October 23, 2025 Page 78 of 127

 Access Manager Appliance 25.2

1.5.2. Securing Access to Access

Manager Services in a Kubernetes Cluster
Ingress manages external access to OpenText Access Manager services in a
Kubernetes cluster. Configuring Ingress is mandatory while deploying OpenText
Access Manager on Azure. However, configuring Ingress is optional on AWS if the
worker nodes are on the public IP address.
Configure the following ports:

Component Value

Administration Console 2443

Identity Server 8443

Access Gateway 8000

9099
Depending on the ports that Access
Gateway needs to open, you can
specify more port numbers.

Analytics Dashboard 8445

1468

For information about how to configure Ingress, see Configuring ingress.

This PDF was generated on October 23, 2025 Page 79 of 127

 Access Manager Appliance 25.2

1.5.3. YAML Best Practices

You must clear the sensitive information, such as password from [Link] after
the deployment is complete.
When inputs (password) are sent by using the --set command, it is visible when you
run the helm get values <release name> command.

This PDF was generated on October 23, 2025 Page 80 of 127

 Access Manager Appliance 25.2

1.5.4. Protecting Access Manager Secrets

on Kubernetes
If the secrets are decoded with Base64, Kubernetes does not hide the secrets while
encrypting, managing, and sharing secrets across a Kubernetes cluster by default.
Therefore, OpenText Access Manager Secrets could be visible.
For information about how to protect Access Manager secrets, see Protecting Access
Manager secrets.

This PDF was generated on October 23, 2025 Page 81 of 127

 Access Manager Appliance 25.2

1.6. Configuring Secure Communication

OpenText Access Manager has six communication channels that you can configure
for SSL. The following diagram illustrates potential SSL Communication channels:

SSL Communication Channels

The first channel is set between Identity Server and LDAP servers when you
configure user stores. The other channels are configured according to their numeric
values. SSL must be configured between Identity Server and browsers before you
configure the channel between Access Gateway and Identity Server for SSL.
This section discusses the following topics:
Configuring SSL in Identity Server
Configuring SSL in Access Gateway

This PDF was generated on October 23, 2025 Page 82 of 127

 Access Manager Appliance 25.2

1.6.1. Configuring SSL in Identity Server

An attacker can spoof a non-secure browser and send a JSESSION cookie that
contains a valid user session. You can prevent this by configuring Identity Server to
use a SSL channel for communications.

Enabling SSL between Browsers and Identity Server

Channel 2 in SSL Communication Channels.
1. On the Home page, click Identity Servers > [cluster name] > General.
2. Change the protocol to HTTPS. The system changes the port to 8443.
3. In the SSL Certificate line, click Browse and select the Identity Server
certificate.
4. Restart Tomcat.
If your Identity Server and Administration Console are on the same machine, log
in to Administration Console again.
5. After the Identity Server health turns green, on the Home page, click Access
Gateways > Edit > Service Provider Certificates > Trusted Roots.
6. Click Add to select the trusted root certificate of the certificate authority that
signed Identity Server certificate.
(Conditional) If you imported intermediate certificates for the CA, select them
also.

Important
If the external certificate authority writes the DN in reverse order
(the cn element is displayed first), you receive an error message that
the certificate names do not match. You can ignore this warning, if
the order of the DN elements is the cause.

7. Update Access Gateway.

Enabling SSL between Identity Server and a Service

Provider
Channel 6 in SSL Communication Channels.

This PDF was generated on October 23, 2025 Page 83 of 127

 Access Manager Appliance 25.2

To make the communication between Identity Server and a service provider more
secure, you must consider the following settings:
Identity Provider Signing Certificate: Select a certificate from the keystore and
assign it to the service provider.
Identity Provider Encryption Certificate:Select a certificate from the keystore and
assign it to the service provider.
Signing certificate per service provider:When you assign custom certificates to each
service provider while configuring Identity Server, ensure that you export these
certificates and custom metadata to the service provider. To retrieve the metadata,
click the metadata link (available in the note on the Trust page).
For more information, see Configuring communication security for a SAML 2.0 service
provider.

Note
These security considerations are also valid when Identity Server acts as
a service provider.

This PDF was generated on October 23, 2025 Page 84 of 127

 Access Manager Appliance 25.2

1.6.2. Configuring SSL in Access Gateway

You can configure Access Gateway to use SSL in its connections to Embedded
Service Provider (ESP), browsers, and its web servers.
Enable SSL with ESP: To encrypt the data exchanged for authentication (a
communication channel between Identity Server and Access Gateway). This option is
available only for the reverse proxy that has been assigned to perform authentication.
If you enable SSL between browsers and Access Gateway, this option is automatically
selected. You can enable SSL with the ESP without enabling SSL between Access
Gateway and browsers. This allows the authentication and identity information that
Access Gateway and Identity Server exchange to use a secure channel. However, it
allows the data, that Access Gateways retrieves from the back-end web servers and
sends to users, to use a non-secure channel. This saves processing overhead if the
data on web servers is not sensitive.
Enable SSL between Browser and Access Gateway: To configure SSL connections
between your clients and Access Gateway. SSL must be configured between
browsers and Access Gateway before you can configure SSL between Access
Gateway and web servers.
Redirect Requests from Non-Secure Port to Secure Port: To determine whether
browsers are redirected to a secure port and allowed to establish an SSL connection.
If this option is not selected, browsers that connect to the non-secure port are denied
service.
This option is only available if you have selected Enable SSL with Embedded Service
Provider.
For information about how to enable SSL between SSL with ESP and how to redirect
requests from a non-secure port to a secure port, see Enabling SSL between
Browsers and Access Gateway.

Enabling SSL between Browsers and Access

Gateway
This section explains how to enable SSL communication between Access Gateway
and browsers (channel 4 in SSL Communication Channels).
1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy].
2. Select the following options based on your requirement:

This PDF was generated on October 23, 2025 Page 85 of 127

 Access Manager Appliance 25.2

Enable SSL with Embedded Service Provider

Enable SSL between Browser and Access Gateway
Redirect Requests from Non-Secure Port to Secure Port
3. Select the certificate to use for SSL between Access Gateway and browsers.
4. Configure the ports for SSL:
Non-Secure Port: Indicates a specific port to listen to HTTP requests. The
default port for HTTP is 80.
If you selected the Redirect Requests from Non-Secure Port to Secure
Port option, requests sent to this port are redirected to the secure port. If
the browser can establish an SSL connection, the session continues on the
secure port. If the browser cannot establish an SSL connection, the session
is terminated.
If you do not select the Redirect Requests from Non-Secure Port to
Secure Port option, this port is not used when SSL is enabled.
Secure Port: Indicates a specific port to listen to HTTPS requests (usually 443).
This port needs to match the configuration for SSL. If SSL is enabled, this port is
used for all communication with the browsers. The listening address and port
combination must not match any combination you have configured for another
reverse proxy or tunnel.
5. Click OK > Reverse Proxy / Authentication.

Enabling SSL between Access Gateway and Web

Servers
Channel 5 in SSL Communication Channels.
SSL must be enabled between Access Gateway and browsers before you can enable
it between Access Gateway and its web servers. See Enabling SSL between Browsers
and Access Gateway.
1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] >
[Name of Proxy Service] > Web Servers.
2. Select Connect Using SSL.
3. (Optional) Set up mutual authentication so that the web server can verify the
proxy service certificate. Click Select Certificate to select the certificate you
created for the reverse proxy.

This PDF was generated on October 23, 2025 Page 86 of 127

 Access Manager Appliance 25.2

Import the trusted root certificate of the CA that signed the proxy service’s
certificate to the web servers assigned to this proxy service. For instructions,
see the web server documentation.
4. In Connect Port, specify the port that your web server uses for SSL
communication.

This PDF was generated on October 23, 2025 Page 87 of 127

 Access Manager Appliance 25.2

1.6.3. Configuring SSL for Authentication

between Identity Server and Access
Gateway
1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy].
2. In the Server Certificate line, click the Browse icon to select the Access
Gateway certificate.

Important
If the external certificate authority writes the DN in reverse order
(the cn element comes first rather than last), you receive an error
message that the subject name does not contain the cn of the
device. You can ignore this warning, if the order of the DN elements
is the cause.

3. Specify an Alias for the certificate.

4. On the Server Configuration page, click Reverse Proxy / Authentication.
5. Update Access Gateway and Identity Server on respective pages.

This PDF was generated on October 23, 2025 Page 88 of 127

 Access Manager Appliance 25.2

1.6.4. Using Trusted Certificates Authority

This PDF was generated on October 23, 2025 Page 89 of 127

 Access Manager Appliance 25.2

1.7. Strengthening TLS/SSL Settings

Securing TLS/SSL settings have the following three aspects:
Protocol: SSL v2, SSL v3, and TLS1.0 contain known vulnerabilities. Starting with
JDK 8u31, SSL v3 has been deactivated and is not available by default. If SSLv3
is required, you can reactivate the protocol at the JRE level. For more
information, see The SunJSSE Provider.
By default, OpenText Access Manager is configured with only TLS1.1 and TLS1.2.
Encryption: In the encryption algorithms, you need to look at two aspects:
Key Exchange Algorithm: In these algorithms, DH is vulnerable. By default,
OpenText Access Manager 4.3 and later include only RSA, DHE, or ECDHE.
Bulk Encryption Algorithm: In these algorithms, cipher suites that contain
NULL, DES, 3DES, and RC4 encryptions are vulnerable. By default,
OpenText Access Manager supports cypher suites only with AES.
Message Authentication Code (MAC) Algorithm:In these algorithms, MD5 and
SHA1 are vulnerable. By default, OpenText Access Manager supports cypher
suites only with SHA 256 or higher.
In OpenText Access Manager 4.3 and later, security is strengthened. These security
measures can impact performance. For example, DHE and ECDHE ciphers are more
secure, but they need more computation and therefore impacts performance.
Between DHE and ECDHE, ECDHE reduces some computational cost comparatively
and in turn it is better than DHE ciphers in terms of performance. You can configure
the cipher optimally based on your security and performance requirements by
referring to The Sun JSSE Provider.
If you want to restore the previous security settings, see Restoring Previous Security
Level After Upgrading OpenText Access Manager Appliance.
In this Section
Disabling SSLv2 and SSLv3 Protocols
Optimizing SSL Configuration with Ciphers
Enabling Perfect Forward Secrecy
Adding HTTP Strict Transport Security

This PDF was generated on October 23, 2025 Page 90 of 127

 Access Manager Appliance 25.2

Customizing the Size of Ephemeral Diffie-Hellman Keys

This PDF was generated on October 23, 2025 Page 91 of 127

 Access Manager Appliance 25.2

1.7.1. Disabling SSLv2 and SSLv3 Protocols

In OpenText Access Manager 4.3 and later versions, SSL v2 and SSL v3 protocols are
disabled by default for Administration Console, Identity Server, and between browsers
and Access Gateway.
To disable SSL v2 and SSL v3 between Access Gateway and web servers, see
Disabling Weak Protocols between Access Gateway and Web Servers.

This PDF was generated on October 23, 2025 Page 92 of 127

 Access Manager Appliance 25.2

1.7.2. Optimizing SSL Configuration with

Ciphers
In addition to setting up Transport Level Security (TLS), using a cipher suite provides
additional security to client-server communications from Identity Server, Access
Gateway to the web browsers.

Important
The settings specified in this section indicate an SSL configuration that
provides an optimal level of security. If you plan to make any changes in
the cipher information, ensure that you test the configuration before you
deploy it in the production setup.

In OpenText Access Manager 4.3 and later, stronger ciphers for SSL communications
have been configured for Administration Console, Identity Server, and communication
between browsers and Access Gateway.
For information about how to specify SSL Configuration for communication between
Access Gateway and web servers, see Configuring Stronger Ciphers for SSL
Communication between Access Gateway and Web Servers

This PDF was generated on October 23, 2025 Page 93 of 127

 Access Manager Appliance 25.2

1.7.3. Enabling Perfect Forward Secrecy

When an SSL handshake is performed, SSL information regarding the capabilities of
browser/client and server is exchanged and validated. An SSL session key that meets
both the client’s and server’s criteria is established. After the session key is
established, all subsequent communication between the client and the site is
encrypted and thus secured.
The most common method for negotiating the session key is the RSA public-key
cryptosystem. The RSA approach uses the server’s public key to protect the session
key parameters created by the client after the key parameters are sent to the server.
The server decrypts this handshake with its corresponding private key. If an attacker
ever steals the server’s private key, they can decrypt your SSL session and any saved
SSL sessions. This approach allows Wireshark or ssldump tools to decrypt the saved
SSL communication by using an exported server certificate with private key.
Perfect Forward Secrecy (PFS) removes this shortcoming of the RSA approach. When
PFS is enabled, no link between the server’s private key and each session key is
established. If an attacker ever gets access to your server’s private key, the attacker
cannot use the private key to decrypt any of your archived sessions.
In OpenText Access Manager 4.3 and later, PFS are enabled by default for
Administration Console and Identity Server. For information about how to enable PFS
in Access Gateway, see Enabling Perfect Forward Secrecy.

This PDF was generated on October 23, 2025 Page 94 of 127

 Access Manager Appliance 25.2

1.7.4. Adding HTTP Strict Transport

Security
HTTP Strict Transport Security (HSTS) is a web security policy mechanism that
protects HTTPS websites against downgrade attacks. Downgrade attacks are often
implemented as part of a man-in-the-middle attack such as Poodle. HSTS also
protects against cookie hijacking. It enables web servers to mandate that web
browsers (or other complying user agents) should interact with it by using only secure
HTTPS connections, and never through the insecure HTTP protocol.
HSTS are enabled by default for the product components.

This PDF was generated on October 23, 2025 Page 95 of 127

 Access Manager Appliance 25.2

1.7.5. Customizing the Size of Ephemeral

Diffie-Hellman Keys
It is recommended not to use keys of sizes less than 1024 bits because of their
insufficient strength. In OpenText Access Manager 4.3 and later, the default EDH key
size in Administration Console and Identity Server is 2048.

This PDF was generated on October 23, 2025 Page 96 of 127

 Access Manager Appliance 25.2

1.8. Strengthening Certificates

This section discusses the following topics:
Key Size and Signature Algorithm Considerations
Certificate Renewal

This PDF was generated on October 23, 2025 Page 97 of 127

 Access Manager Appliance 25.2

1.8.1. Key Size and Signature Algorithm

Considerations
OpenText Access Manager Appliance ships with a CA that can create certificates with
a key size of 512, 1024, 2048, or 4096. Select the maximum size supported by the
applications that you are protecting with OpenText Access Manager Appliance.
Security increases with the increase in key size length. The default certificates
created by OpenText Access Manager 4.2 and later are of 2048 key size. If you are
upgrading Access Manager from a version older than 4.2, ensure that certificates with
small key sizes are replaced with 2048 or above.
In signature algorithms, SHA1 is no longer considered secure. OpenText Access
Manager supports creation of a certificate only with SHA-256 and SHA-512. When
you are importing external certificates signed by a well-known third-party CA into
OpenText Access Manager, ensure that they are of SHA-256 or above.

This PDF was generated on October 23, 2025 Page 98 of 127

 Access Manager Appliance 25.2

1.8.2. Trusted Certificate Authorities

This PDF was generated on October 23, 2025 Page 99 of 127

 Access Manager Appliance 25.2

1.8.3. Certificate Renewal

Ensure that you renew certificates before it gets expired. Your security needs might
allow for a longer or shorter period. You can configure to get certificate expiration
notifications.
For more information, see Getting the Certificate Expiration Notification.
When you install Administration Console, the NAM-RP certificate is automatically
generated and associated with NAM-RP Reverse Proxy (Devices > Access Gateways
> [AG-Cluster] > [NAM-RP]).
OpenText Access Manager renews test-* certificate for both primary and secondary
Administration Console including the eDirectory certificate on secondary
Administration Console automatically.
Certificates created manually by using OpenText Access Manager CA does not get
renewed automatically.
Perform the following steps to renew manually created certificates. Lets assume that
a certificate with the alias signing in the Identity Server signing keystore is about to
expire.
1. Create a new certificate. (Security > Certificates > New)
2. Add the new certificate to the keystore with the alias of the certificate that will
expire (signing). (Actions > Add Certificate to Keystores)
3. Select the option to overwrite.

This PDF was generated on October 23, 2025 Page 100 of 127
 Access Manager Appliance 25.2

1.9. XSS, XFS, and Clickjacking Attacks

This section included the following topics:
Cross-site Scripting Attacks
Cross-Frame Scripting Attacks
Clickjacking Attacks

This PDF was generated on October 23, 2025 Page 101 of 127
 Access Manager Appliance 25.2

1.9.1. Cross-site Scripting Attacks

By default, OpenText Access Manager performs extensive checks to prevent Cross-
site Scripting (XSS) attacks. However, OpenText Access Manager does not validate a
JSP file if you have customized it. If you modify JSP files to customize the login,
logout, error pages, and so forth, you must sanitize the respective JSP file to prevent
XSS attacks.
Perform either one of the following options to sanitize the customized JSP file:

Option 1: HTML Escaping

Perform the following XSS checks for the customized JSP file to protect it from
possible XSS attacks. For more information about XSS prevention techniques, see
XSS (Cross Site Scripting) Prevention Cheat Sheet.
Perform the following steps:
1. Verify if the [Link] class is available in
the JSP file.
For information about how to edit a file, see Modifying configurations.
For example, the following import statement should be available in the import
section of the JSP file:
<%@ page import="[Link]"%>

This PDF was generated on October 23, 2025 Page 102 of 127
 Access Manager Appliance 25.2

Note
The escapeHtml function supports all known HTML 4.0 entities but
does not escape the character "'","&apos;" as it is not a legal entity.
Refer to the example below:
Refer to the file: err_latest.jsp
Add the below import statement in the JSPs
<%@ page
import="[Link]" %>
Example of using the StringEscapeUtils
strUIComponentsToHide = (String)
[Link]([Link](NIDPCon
stants.HTTP_REQUEST_PARAM_NAME_UICOMPONENTS_TOHI
DE))
When the getAttribute and getPrameter methods are invoked
on request, these strings should be passed to this String
Escape Utility class by using escapeHtml method.
Handling HTML 4.0 entities while using StringEscapeUtils:
For Example "&apos;" that the commonly used apostrophe
escape character (&apos;) is not a legal entity and so is not
supported.
strUIComponentsToHide =
[Link]("'","&apos;")
See [Link]
lang/apidocs/org/apache/commons/lang3/[Link]
ml and [Link]
text/javadocs/api-
release/org/apache/commons/text/[Link].

2. Verify if all URL query parameter values are sanitized.

The following code snippet sample shows how URL query parameter values
(uname and target) can be sanitized:

This PDF was generated on October 23, 2025 Page 103 of 127
 Access Manager Appliance 25.2

<%//Fetch the values from URL query parametersString target = (String)

[Link]("target");String uname = (String)
[Link]("username"); String sanitizedUName = ""; if (uname != null)
{//Sanitize the value assigned to uname sanitizedUName =
[Link](uname); } String sanitizedTarget = ""; if (target !=
null){ //Sanitize the value assigned to target query param sanitizedTarget =
[Link](target);}%>
3. Add double quotes (ʺʺ) in value attribute (or any attribute that is dynamically
assigned) for any HTML element that get assigned with above URL query param
value.
<!-- The last 2 double quotes are mandatory to prevent XSS attacks --><input
type="text" class="smalltext" name="Ecom_User_ID" size="30" value="
<%=sanitizedUName%>">......<!-- The last 2 double quotes are mandatory to
prevent XSS attacks --><input type="hidden" name="target" value="
<%=sanitizedTarget%>">

Option 2: Filtering
By default, the XSS detection filter is enabled in Identity Server’s [Link] file.
For information about how to edit a file, see Modifying configurations.
The filter is as follows:

This PDF was generated on October 23, 2025 Page 104 of 127
 Access Manager Appliance 25.2

<filter>
<filter-name>XSSDetectionFilter</filter-name>
<filter-
class>[Link]</f
ilter-class>
<description>This filter is used to detect XSS
attacks in NIDS</description>
<init-param>
<param-name>active</param-name>
<param-value>True</param-value>
</init-param>
<init-param>
<param-name>level</param-name>
<param-value>SCRIPT_TAGS</param-value>
</init-param>
<init-param>
<param-name>exclude</param-name>
<param-
value>soap,wstrust,metadata,oauth</param-value>
</init-param>
</filter>

Note
You can scan JavaScript directives along with the script directive by using
the param-value SCRIPT_TAGS_AND_JS_DIRECTIVES instead of
SCRIPT_TAGS .
To improve the XSS Detection with Strict checking of the attacks, use the
ALL_PARAMETERS value for the XSSDetectionFilter, which includes
SCRIPT_TAGS_AND_JS_DIRECTIVES and SCRIPT_TAGS .

To disable it, set the <param-value> True to False as follows:

<init-param>
<param-name>active</param-name>
<param-value>False</param-value>
</init-param>

This PDF was generated on October 23, 2025 Page 105 of 127
 Access Manager Appliance 25.2

To exclude it from a specific request, add a URL string from that request in the
<param-name>exclude</param-name> tag that contains the default excluded
request path name.
For example: If wsfed request fails due to some reason, add wsfed in the exclude
list. Now, Identity Provider will not filter wsfed specific [Link] exclude init-
param is as follows:

<init-param>
<param-name>exclude</param-name>
<param-value>soap,wstrust,metadata,oauth,wsfed</param-value>
</init-param>

Note
It is recommended to use the above option as it overrides the following
approach:

This approach might have a minor performance impact due to the checks it performs.
If you perform HTML escaping in customized JSP pages, you do not need to perform
this additional filtering.
Perform the followings steps to sanitize Identity Server’s customized JSP file:
1. The eMFrame_xss.jar library prevents XSS based attacks.
2. Add a filter in Identity Server’s [Link] file.
<filter><filter-name>XSS</filter-name><display-name>XSS</display-name>
<description>Filters XSS injections.</description> <filter-
class>[Link]</filter-class></filter>
<filter-mapping><filter-name>XSS</filter-name><url-pattern>/*</url-pattern>
</filter-mapping>
For information about how to edit a file, see Modifying configurations.

Option 3: Understanding Relaxed Query Parameters

For more information to understand the Relaxed Query Characters, see Apache
Tomcat 9 Configuration Reference(relaxedQueryChars).

This PDF was generated on October 23, 2025 Page 106 of 127
 Access Manager Appliance 25.2

1.9.2. Cross-Frame Scripting Attacks

Any intruder can call Identity Server portal login pages or the pages delivered by
Access Gateway ESP with the default Identity Server configuration from an HTML
iFrame. To prevent this vulnerability, Cross-Frame Scripting (XFS) has been disabled
for both Identity Server and Access Gateway ESP in OpenText Access Manager 4.3
and later.

This PDF was generated on October 23, 2025 Page 107 of 127
 Access Manager Appliance 25.2

1.9.3. Clickjacking Attacks

Web applications allow external sites to include content by using IFrame. This enables
an attacker to embed the malicious code beneath legitimate clickable content. An
attacker can trick a web user into clicking the malicious content that the attacker can
control.
The configuration to prevent this attack is enabled by default in OpenText Access
Manager 4.3 and later.

This PDF was generated on October 23, 2025 Page 108 of 127
 Access Manager Appliance 25.2

1.10. Getting the Latest Security Patches

The OpenSSL open source project team regularly releases updates to known
OpenSSL vulnerabilities. Access Manager Appliance uses the OpenSSL library for
cryptographic functions. It is recommended to update Access Manager Appliance
with the latest OpenSSL patch.
See Getting the latest openssl updates for OpenText Access Manager Appliance.

This PDF was generated on October 23, 2025 Page 109 of 127
 Access Manager Appliance 25.2

1.11. Securing OpenText Access Manager

Components on Cloud

This PDF was generated on October 23, 2025 Page 110 of 127
 Access Manager Appliance 25.2

1.11.1. Prerequisite
The operating system packages must be updated. If you are using SUSE or Red
Hat, ensure that the operating system is updated with the latest patch update.
It is recommended to not use keys of sizes less than 1024 bits on port 22.

This PDF was generated on October 23, 2025 Page 111 of 127
 Access Manager Appliance 25.2

1.11.2. Protecting Administration Console

on Cloud
It is recommended to install Administration Console on a private subnet to restrict the
access to Config data store. To protect Administration Console in a cloud
environment, see Deploying Access Manager on public cloud.

This PDF was generated on October 23, 2025 Page 112 of 127
 Access Manager Appliance 25.2

1.12. Restoring Previous Security Level

After Upgrading OpenText Access
Manager Appliance
All protocols, ciphers, and filter configurations in all components are made highly
secure by default in OpenText Access Manager Appliance 4.3 and later. If your setup
is configured with less secure settings, upgrading it to 4.3 or later may result in
communications issues. The following are few example scenarios when you may
need to restore your previous security settings:
When browsers do not support TLS1.1 or TLS1.2 protocol or secure ciphers
suites.
When third-party service provider does not support TLS1.1 or TLS1.2 protocol or
secure cipher suites along with the following configuration:
A SAML or Liberty federation with artifact binding between OpenText
Access Manager and third-party service provider.
WS-Trust federation between OpenText Access Manager and third-party
service provider.
When OAuth clients or OAuth resource servers do not support TLS1.1 or TLS1.2
protocol or secure cipher suites.
Backed Up Configuration Files
When you upgrade OpenText Access Manager, the upgrade script backs up the
following files to enable you restoring the previous configuration:
Administration Console: [Link], [Link], [Link]
Identity Server: [Link], [Link], [Link]
Access Gateway:[Link], [Link], [Link], [Link],
[Link]
The backup files are located in /root/nambkup (separate folders for Administration
Console, Identity Server, and Access Gateway).

This PDF was generated on October 23, 2025 Page 113 of 127
 Access Manager Appliance 25.2

Note
Compare each upgraded configuration file with the corresponding backup
file. If the backup file includes the similar configuration as it is in the
upgraded file, you do not need to make any changes.

In this Section
Restoring Previous Security Settings for Administration Console
Restoring Previous Security Settings for Identity Server
Restoring Previous Security Settings for Access Gateway

This PDF was generated on October 23, 2025 Page 114 of 127
 Access Manager Appliance 25.2

1.12.1. Restoring Previous Security

Settings for Administration Console
Restoring the previous protocols' settings
1. Download backup files from the /root/nambkup/ac <time stamp of upgrade>
folder.
For information about how to download backup files, see Downloading files from
a server.
2. Open the backup [Link] file from the backup folder and search for the
sslProtocol attribute in NIDP_Name="devman" and NIDP_Name="connector"
inside the Connector element and copy the attribute values.
3. Open Administration Console’s new [Link].
For information about how to open and modify a file, see Modifying
configurations.
4. Search for the sslProtocol attribute in the NIDP_Name="devman" and
NIDP_Name="connector" inside the Connector element. You will see the
following value:

sslProtocol="TLSv1.2"
sslEnabledProtocols="SSLv2Hello,TLSv1.1,TLSv1.2"

5. Replace this attribute value with the previous value that you copied in step 4.

Restoring the Previous Settings of Ciphers for SSL

Communication
1. Download backup files from the /root/nambkup/ac <time stamp of upgrade>
folder.
For information about how to download backup files, see Downloading files from
a server.
2. Open the backup [Link] file from the backup folder and search for the
cipher attribute in NIDP_Name="devman" and NIDP_Name="connector"
inside the Connector element and copy the list of ciphers.

This PDF was generated on October 23, 2025 Page 115 of 127
 Access Manager Appliance 25.2

3. Open the new [Link] of Administration Console.

For information about how to open and modify a file, see Modifying
configurations.
4. Search for the cipher attribute in NIDP_Name="devman" and
NIDP_Name="connector" inside the Connector element.
5. Replace this list of ciphers with the list copied in step 2.

Disabling Perfect Forward Secrecy

1. Download backup files from the /root/nambkup/ac <time stamp of upgrade>
folder.
For information about how to download backup files, see Downloading files from
a server.
2. Open the backup [Link] from the backup folder and search for the cipher
attribute in NIDP_Name="devman" and NIDP_Name="connector" inside the
<Connectors> element and copy the list of ciphers.
3. Open the new [Link] file of Administration Console.
For information about how to open and modify a file, see Modifying
configurations.
4. Search for the cipher attribute in NIDP_Name="devman" and
NIDP_Name="connector" inside the <Connectors> element.
5. Replace the list of ciphers with the value you copied in step 2.
6. Remove the useServerCipherSuitesOrder attribute.

Restoring the Previous Size of EDH Keys

1. Open the [Link] ([Link]) file.
2. Remove the following line:

JAVA_OPTS="${JAVA_OPTS} -[Link]=2048"

For information about how to modify a file, see Modifying configurations.

Removing HTTP Strict Transport Security

This PDF was generated on October 23, 2025 Page 116 of 127
 Access Manager Appliance 25.2

1. Open the Administration Console [Link] file and comment out the
httpHeaderSecurity filter definition.

<filter>
<filter-name>httpHeaderSecurity</filter-name>
<filter-
class>[Link]</
filter-class>
<async-supported>true</async-supported>
</filter>

2. Comment out the following parameter that sets up an appropriate maximum age
value:

<init-param>
<param-name>hstsMaxAgeSeconds</param-name>
<param-value>31536000</param-value>
</init-param>

3. Comment out the filter mapping.

<filter-mapping>
<filter-name>httpHeaderSecurity</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>

For information about how to modify a file, see Modifying configurations.

This PDF was generated on October 23, 2025 Page 117 of 127
 Access Manager Appliance 25.2

1.12.2. Restoring Previous Security

Settings for Identity Server
Restoring the Previous Protocols' Settings
1. Download backup files from the /root/nambkup/idp <time stamp of upgrade>
folder.
For information about how to download backup files, see Downloading files from
a server.
2. Open the backup [Link] file from the backup folder, search for the
sslProtocol attribute, and copy the value.
3. Open Identity Server’s new [Link] file and search for the sslProtocol
attribute.
For information about how to open and modify a file, see Modifying
configurations.
You will see the following value:

sslProtocol="TLSv1.2"
sslEnabledProtocols="SSLv2Hello,TLSv1.1,TLSv1.2"

4. Replace this attribute value with the value that you copied in step 2.

Restoring the Previous Settings of Ciphers for SSL

Communication
1. Download backup files from the /root/nambkup/idp <time stamp of upgrade>
folder.
For information about how to download backup files, see “Downloading files
from a server”.
2. Open the backup [Link] from the backup folder, search for the cipher
attribute in NIDP_Name="connector" inside the <Connectors> element, and
copy the list of ciphers.
3. Open Identity Server’s new [Link] and search for the cipher attribute in
NIDP_Name="connector" in the <Connector> element.

This PDF was generated on October 23, 2025 Page 118 of 127
 Access Manager Appliance 25.2

For information about how to open and modify a file, see Modifying
configurations.
4. Replace this list of ciphers with the list copied in step 2.

Disabling Perfect Forward Secrecy

1. Download backup files from the /root/nambkup/idp <time stamp of upgrade>
folder.
For information about how to download backup files, see Downloading files from
a server.
2. Open the backed up [Link] from the backup folder, search for the cipher
attribute in NIDP_Name="connector" inside the <Connectors> element, and
copy the list of ciphers.
3. Open Identity Server’s new [Link] file. Search for the cipher attribute in
NIDP_Name="connector" in the <Connectors> element.
For information about how to open and modify a file, see Modifying
configurations.
4. Replace the list of ciphers with the value you copied in step 2.

Restoring the Previous Settings of the Size of EDH

Keys
1. Open Identity Server’s [Link].
2. Remove the following line:

JAVA_OPTS="${JAVA_OPTS} -[Link]=2048"

For information about how to open and modify a file, see “Modifying configurations”.

Removing HTTP Strict Transport Security

1. Open Identity Server’s [Link] file and comment out the httpHeaderSecurity
filter definition.

This PDF was generated on October 23, 2025 Page 119 of 127
 Access Manager Appliance 25.2

<filter>
<filter-name>httpHeaderSecurity</filter-name>
<filter-
class>[Link]</
filter-class>
<async-supported>true</async-supported>
</filter>

2. Comment out the hstsMaxAgeSeconds parameter:

<init-param>
<param-name>hstsMaxAgeSeconds</param-name>
<param-value>31536000</param-value>
</init-param>

3. Comment out the filter mapping.

<filter-mapping>
<filter-name>httpHeaderSecurity</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>

For information about how to open and modify a file, see “Modifying configurations”.

Removing the Clickjacking Filter

1. Open Identity Server’s [Link] file.
2. Comment out the following Tomcat filter configuration:

This PDF was generated on October 23, 2025 Page 120 of 127
 Access Manager Appliance 25.2

<filter>
<filter-name>TomcatSameOriginFilter</filter-name>
<filter-
class>[Link]</
filter-class>
<init-param>
<param-name>antiClickJackingOption</param-name>
<param-value>SAMEORIGIN</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>TomcatSameOriginFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

For information about how to open and modify a file, see Modifying configurations.

This PDF was generated on October 23, 2025 Page 121 of 127
 Access Manager Appliance 25.2

1.12.3. Restoring Previous Security

Settings for Access Gateway
Restoring the Previous Protocol Settings
between Browsers and Access Gateway
1. Download backup files from the /root/nambkup/mag <time stamp of
upgrade>/conf folder.
For information about how to download backup files, see Downloading files from
a server.
2. Open the [Link] file, search for SSL Protocol , and copy the
value associated with it.
For information about how to open and modify a file, see Modifying
configurations.
3. On the Home page, click Access Gateways > Edit > Advanced Options and
replace the following configuration with the value copied in
[Link] in step 2:

SSLProtocol TLSv1.1 +TLSv1.2

Restoring the Previous Ciphers Settings between

Browsers and Access Gateway
1. Download the backup files from the /root/nambkup/mag <time stamp of
upgrade>/conf folder.
For information about how to download backup files, see Downloading files from
a server.
2. Open the [Link] file, search for SSL, and copy the value.
For information about how to open and modify a file, see Modifying
configurations.
3. On the Home page, click Access Gateways > Edit > Advanced Options and
replace the following configuration with the value copied from
[Link] in step 2:

This PDF was generated on October 23, 2025 Page 122 of 127
 Access Manager Appliance 25.2

SSLCipherSuite !aNULL:!eNULL:!EXPORT:!DSS:!DES:!RC4:ALL:!EDH

If [Link] does not contain this line, delete this line in Access
Gateway Advanced Options.

Removing the Clickjacking Filter

In Access Gateway’s [Link], comment out the following Tomcat filter configuration:

<filter>
<filter-name>TomcatSameOriginFilter</filter-name>
<filter-
class>[Link]</filt
er-class>
<init-param>
<param-name>antiClickJackingOption</param-name>
<param-value>SAMEORIGIN</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>TomcatSameOriginFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

For information about how to open and modify a file, see Modifying configurations.

Removing HTTP Strict Transport Security

1. On the Home page, click Access Gateways > Edit > Advanced Options.
2. Set the following option:
SetStrictTransportSecurity off
3. Restart Apache.
/etc/init.d/novell-apache2 restart OR rcnovell-apache2 restart

This PDF was generated on October 23, 2025 Page 123 of 127
 Access Manager Appliance 25.2

1.13. Appendix
The following lists the default ciphers for the Identity Server, Administration Console,
and Access Gateway.
Default Ciphers for Identity Server
Default Ciphers for Administration Console
Default Ciphers for Access Gateway

This PDF was generated on October 23, 2025 Page 124 of 127
 Access Manager Appliance 25.2

1.13.1. Default Ciphers for Identity Server

The following is the list of default ciphers supported by Access Manager Identity
Server:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

This PDF was generated on October 23, 2025 Page 125 of 127
 Access Manager Appliance 25.2

1.13.2. Default Ciphers for Administration

Console
The following is the list of default ciphers supported by OpenText Access Manager
Administration Console:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

This PDF was generated on October 23, 2025 Page 126 of 127
 Access Manager Appliance 25.2

1.13.3. Default Ciphers for Access

Gateway
The following is the list of default ciphers supported by OpenText Access Manager
Access Gateway:
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384

This PDF was generated on October 23, 2025 Page 127 of 127
 © Copyright 2025 Open Text

For more info, visit [Link]