OpenText™ Access Manager

Administration guide
Version : 25.2
PDF Generated on : July 27, 2025

© Copyright 2025 Open Text

Table of Contents
1. Administration guide 1

1.1. Configuring OpenText Access Manager 2

1.1.1. Configuring Administration Console 3

1.1.1.1. Managing Administration Console session timeout 4

1.1.1.2. Managing administrators 5

1.1.1.3. Performing administrative tasks 6

1.1.1.3.1. Creating multiple administrator accounts 7

1.1.1.3.2. Managing policy view administrators 8

1.1.1.3.3. Managing delegated administrators 9

1.1.1.3.3.1. Access Gateway administrators 11

1.1.1.3.3.2. Policy container administrators 12

1.1.1.3.3.3. Delegated administrators of Identity Servers 13

1.1.1.3.3.4. Creating users 14

1.1.1.4. Changing the IP address of OpenText Access Manager devices 15

1.1.1.4.1. Changing the IP address of Administration Console 16

1.1.1.4.2. Changing the IP address of Identity Server 17

1.1.1.4.3. Changing the IP address of Access Gateway Appliance 18

1.1.1.4.4. Changing the IP address of Access Gateway service 19

1.1.1.4.5. Changing the IP address of audit server 20

1.1.1.5. Mapping the private IP address to public IP address 21

1.1.1.5.1. Creating a new NAT IP address mapping 22

1.1.1.5.2. Removing a NAT IP address mapping 23

1.1.1.5.3. Viewing the NAT IP address mapping 24

1.1.1.5.4. Editing a NAT IP address mapping 25

1.1.2. Setting up a basic Identity Server cluster 26

1.1.2.1. Prerequisites for a basic OpenText Access Manager setup 27

1.1.2.2. Configuring identity user stores 28

1.1.2.2.1. Using more than one LDAP user store 29

1.1.2.2.2. Configuring the user store 30

1.1.2.2.3. Configuring an administrator user for the user store 33

1.1.2.2.4. Configuring a user store for secrets 34

1.1.2.2.4.1. Configuring the configuration datastore to store secrets 35

1.1.2.2.4.2. Configuring an LDAP directory to store the secrets 36

1.1.2.3. Configuring Identity Servers clusters 37

1.1.2.3.1. Configuration notes 38

1.1.2.3.1.1. Services of the real server 39

1.1.2.3.1.2. A note about service configuration 40

1.1.2.3.1.3. A note about Radware Alteon switches 41

1.1.2.3.2. Prerequisites for configuring an Identity Servers cluster 42

1.1.2.3.3. Managing a cluster of Identity Servers 43

1.1.2.3.3.1. Creating a cluster configuration 44

1.1.2.3.3.2. Assigning an Identity Server to a cluster configuration 49

1.1.2.3.3.3. Configuring a cluster with multiple Identity Servers 50

1.1.2.3.3.4. Configuring session failover 51

1.1.2.3.3.5. Editing cluster details 52

1.1.2.3.3.6. Removing an Identity Server from a cluster configuration 53

1.1.2.3.3.7. Enabling and disabling protocols 54

1.1.2.3.3.8. Modifying the base URL 55

1.1.2.3.3.9. Identity Server authentication APIs 56

1.1.2.3.3.10. Configuring Identity Server global properties 58

1.1.2.4. Configuring IDP global settings 68

1.1.2.4.1. Configuring attribute sets 69

1.1.2.4.2. Editing attribute sets 73

1.1.2.4.3. Adding custom attributes 74

1.1.2.4.3.1. Creating shared secret names 75

1.1.2.4.3.2. Creating LDAP attribute names 76

1.1.2.4.4. User attribute retrieval and transformation 78

1.1.2.4.4.1. How user attribute retrieval and transformation helps 79

1.1.2.4.4.2. Managing a data source 80

1.1.2.4.4.3. Managing an attribute source 87

1.1.2.4.4.4. Managing a virtual attribute 96

1.1.2.4.4.5. Retrieving attributes from a REST web service 101

1.1.2.4.4.6. Sample JavaScripts with examples 109

1.1.2.4.4.7. Troubleshooting user attribute retrieval and transformation 114

1.1.2.4.4.8. User attribute retrieval and transformation limitations 115

1.1.2.4.5. Adding authentication card images 116

1.1.2.4.6. Creating an image set 117

1.1.2.4.7. Metadata repositories 118

1.1.2.4.7.1. Creating metadata repositories 119

1.1.2.4.7.2. Reimporting metadata repositories 120

1.1.2.4.8. Configuring user matching expressions 121

1.1.2.4.9. Configuring the OpenText Advanced Authentication server 122

1.1.2.4.10. Configuring Self Service Password Reset server details in Identity Server 125

1.1.2.5. Configuring Access Gateway 127

1.1.2.5.1. Configuring a reverse proxy 128

1.1.2.5.2. Configuring a public protected resource 131

1.1.2.5.3. Configuring Access Gateway for authentication 132

1.1.2.5.3.1. Verifying time synchronization 133

1.1.2.5.3.2. Enabling trusted authentication 134

1.1.2.5.4. Setting up policies 135

1.1.2.6. Access Gateways clusters 137

1.1.2.6.1. Prerequisites for configuring an Access Gateways cluster 138

1.1.2.6.2. Designing the membership type for a cluster 139

1.1.2.6.3. Creating a new cluster 140

1.1.2.6.4. Managing Access Gateway servers in the cluster 141

1.1.2.6.5. Managing cluster details 142

1.1.2.6.6. Changing the primary cluster server 143

1.1.2.6.7. Applying changes to Access Gateway cluster members 144

1.1.2.6.7.1. Reverting to a previous configuration 145

1.1.2.6.7.2. Modifications requiring an update all 146

1.1.2.7. Protecting web resources through Access Gateway 147

1.1.2.7.1. Configuration options 148

1.1.2.7.2. WebSocket support 149

1.1.2.7.2.1. Scaling websocket 150

1.1.2.7.2.2. Accessing websocket resources 152

1.1.2.7.2.3. Verifying a websocket connection 153

1.1.2.7.3. Managing reverse proxies and authentication 154

1.1.2.7.3.1. Creating a proxy service 157

1.1.2.7.3.2. Configuring a proxy service 158

1.1.2.7.3.3. Modifying the DNS setting for a proxy service 161

1.1.2.7.3.4. Configuring ESP global options 162

1.1.2.7.4. Configuring web servers of a proxy service 166

1.1.2.7.5. Configuring protected resources 168

1.1.2.7.5.1. Setting up a protected resource 170

1.1.2.7.5.2. Configuring an authentication procedure for non-redirected login 173

1.1.2.7.5.3. Assigning an authorization policy to a protected resource 175

1.1.2.7.5.4. Assigning an identity injection policy to a protected resource 176

1.1.2.7.5.5. Assigning a form fill policy to a protected resource 177

1.1.2.7.5.6. Assigning a timeout per protected resource 179

1.1.2.7.5.7. Assigning a policy to multiple protected resources 181

1.1.2.7.6. Configuring HTML rewriting 182

1.1.2.7.6.1. Understanding the rewriting process 183

1.1.2.7.6.2. Specifying DNS names to rewrite 185

1.1.2.7.6.3. Defining the requirements for the rewriter profile 188

1.1.2.7.6.4. Configuring the HTML rewriter and profile 195

1.1.2.7.6.5. Creating or modifying a rewriter profile 197

1.1.2.7.6.6. Deactivating the rewriter 199

1.1.2.7.7. Configuring connection and session limits 200

1.1.2.7.7.1. Configuring TCP listen options for clients 201

1.1.2.7.7.2. Configuring TCP connect options for web servers 202

1.1.2.7.7.3. Configuring connection and session persistence 203

1.1.2.7.7.4. Configuring web servers 204

1.1.2.7.8. Protecting multiple resources 206

1.1.2.7.8.1. Using multi-homing to access multiple resources 207

1.1.2.7.8.2. Setting up a group of web servers 213

1.1.2.7.8.3. Managing multiple reverse proxies 215

1.1.2.8. Configuring trusted providers for single sign-on 217

1.1.2.8.1. Understanding the trust model 218

1.1.2.8.1.1. Identity providers and consumers 219

1.1.2.8.1.2. Embedded service providers 220

1.1.2.8.1.3. Configuration overview 221

1.1.2.8.2. Configuring general provider settings 222

1.1.2.8.2.1. Configuring the general identity provider settings 223

1.1.2.8.2.2. Configuring the general identity consumer settings 225

1.1.2.8.2.3. Configuring introductions (Class) 226

1.1.2.8.2.4. Configuring IDP select (Class) 227

1.1.2.8.2.5. Configuring trust levels (Class) 228

1.1.2.8.3. Managing trusted providers 229

1.1.2.8.3.1. Creating a trusted identity provider 230

1.1.2.8.3.2. Creating a trusted service provider 232

1.1.2.8.4. Modifying a trusted provider 234

1.1.2.8.5. Communication security 235

1.1.2.8.6. Selecting attributes for a trusted provider 236

1.1.2.8.6.1. Configuring the attributes obtained at authentication 237

1.1.2.8.6.2. Configuring the attributes set with authentication 238

1.1.2.8.6.3. Sending attributes to the embedded service provider 239

1.1.2.8.7. Managing metadata 240

1.1.2.8.7.2. Viewing trusted provider certificates 242

1.1.2.8.8. Configuring user identification methods for federation 244

1.1.2.8.8.1. Defining user identification for SAML 2.0 245

1.1.2.8.8.2. Defining the user provisioning method 247

1.1.2.8.8.3. User provisioning error messages 249

1.1.2.8.9. Configuring an authentication response for a service provider 250

1.1.2.8.10. Routing to an external identity provider automatically 251

1.1.2.8.11. Configuring options for trusted service providers 252

1.1.2.8.12. Using the intersite transfer service 253

1.1.2.8.12.1. Understanding the intersite transfer service URL 254

1.1.2.8.12.2. Using intersite transfer service links on web pages 256

1.1.2.8.12.3. Configuring an intersite transfer service target for a service provider 257

1.1.2.8.12.4. Configuring allowed list of target URLs 258

1.1.2.8.12.5. Validating incoming authentication request for assertion consumer service 259
URL

1.1.2.8.12.6. Federation entries management 260

1.1.2.8.12.7. Step up authentication example for an identity provider initiated single sign- 261
on request

1.1.2.8.12.8. URL query string parameters 263

1.1.2.9. Configuring single sign-on to specific applications 264

1.1.2.9.1. Configuring SSO to Sharepoint server 265

1.1.2.9.1.1. Configuring WS Federation claims-based authentication between OpenText 266
Access Manager and Sharepoint server

1.1.2.9.1.2. Configuring Sharepoint server as a protected resource 273

1.1.2.9.1.3. Enabling advanced options for the proxy service 274

1.1.2.9.1.4. Enabling global advanced options 275

1.1.2.9.1.5. Modifying the WS Federation assertion validity time 276

1.1.2.9.1.6. Configuring the trusted site in Internet Explorer 277

1.1.2.9.1.7. Configuring logout 278

1.1.2.9.2. Configuring a protected resource for outlook web access 279

1.1.2.9.2.1. Configuring a protected resource for outlook web access 280

1.1.2.9.2.2. Configuring an authentication procedure 281

1.1.2.9.2.3. Configuring a rewriter profile 282

1.1.2.9.2.4. Configuring identity injection 283

1.1.2.9.2.5. Configuring form fill 284

1.1.2.9.3. Configuring a protected resource for a Novell vibe 3.3 server 285

1.1.2.9.3.1. Configuring the Novell vibe server to trust Access Gateway 286

1.1.2.9.3.2. Configuring a domain-based multi-homing service for Novell vibe 287

1.1.2.9.3.3. Creating a pin list 290

1.1.2.9.4. Configuring access to the filr site through OpenText Access Manager 291

1.1.2.10. Configuring a protected Identity Server through Access Gateways 292

1.1.3. Setting up an advanced OpenText Access Manager configuration 297

1.1.3.1. Identity Server advanced configuration 298

1.1.3.1.1. Managing an Identity Server 299

1.1.3.1.1.1. Updating Identity Server configuration 303

1.1.3.1.1.2. Restarting Identity Server 304

1.1.3.1.2. Editing server details 305

1.1.3.1.3. Configuring a custom response header for an Identity Server cluster 306

1.1.3.2. Access Gateway server advanced configuration 309

1.1.3.2.1. Configuration overview 310

1.1.3.2.2. Saving, applying, or canceling configuration changes 313

1.1.3.2.3. Managing Access Gateways settings 315

1.1.3.2.3.1. Viewing and modifying gateway settings 316

1.1.3.2.3.2. Status options 321

1.1.3.2.3.3. Impact of configuration changes 325

1.1.3.2.3.4. Scheduling a command 327

1.1.3.2.4. Managing general details of Access Gateway 328

1.1.3.2.4.1. Changing the name of Access Gateway and modifying other details 329

1.1.3.2.4.2. Exporting and importing an Access Gateway configuration 330

1.1.3.2.5. Setting up a tunnel 334

1.1.3.2.6. Setting the date and time 336

1.1.3.2.7. Configuring network settings 337

1.1.3.2.7.1. Viewing and modifying adapter settings 338

1.1.3.2.7.2. (Access Gateway Appliance) viewing and modifying gateway settings 339

1.1.3.2.7.3. (Access Gateway Appliance) viewing and modifying DNS settings 342

1.1.3.2.7.4. (Access Gateway Appliance) configuring hosts 343

1.1.3.2.7.5. Adding a new IP address to Access Gateway 344

1.1.3.2.7.6. Adding new network interfaces to Access Gateway Appliance 345

1.1.3.2.8. Enabling Access Gateway to display post-authentication message 346

1.1.3.3. Access Gateway content settings 347

1.1.3.3.1. Configuring cache options 348

1.1.3.3.2. Controlling browser caching 351

1.1.3.3.3. Configuring a pin list 352

1.1.3.3.4. Configuring a purge list 356

1.1.3.3.5. Purging cached content 357

1.1.3.3.6. Apache htcacheclean tool 358

1.1.3.4. Access Gateway advanced options 359

1.1.3.4.1. Configuring global advanced options 360

1.1.3.4.2. Configuring advanced options for a domain-based and path-based multi-homing 374
proxy service

1.1.3.5. Cookie mangling 383

1.1.3.6. Configuring the HTTP/2 protocol 384

1.1.3.7. URL attribute filter 385

1.1.3.8. Email Server Configuration 386

1.1.3.9. Managing User Portal 387

1.1.3.9.1. Logging in to the default User Portal 388

1.1.3.9.2. Logging in with the legacy customized Portal 389

1.1.3.9.3. Logging in to User Portal from a web application 390

1.1.3.9.4. Managing authentication cards 391

1.1.3.9.5. Specifying a target 392

1.1.3.9.6. Blocking access to the legacy User Portal page 393

1.1.3.9.7. Blocking access to the WSDL services page 394

1.1.4. Customizing OpenText Access Manager 395

1.1.4.1. Customizing User Portal 396

1.1.4.1.1. Getting started 397

1.1.4.1.1.1. Understanding JSP files 398

1.1.4.1.1.2. Types of JSP files 399

1.1.4.1.1.3. Detecting the correct mode for Java and JavaScript 402

1.1.4.1.1.4. Enabling impersonation in the login page 403

1.1.4.1.2. Customizing the Identity Server login page 404

1.1.4.1.2.1. Customizing the User Portal page title 405

1.1.4.1.2.2. Customizing the default login page to prompt for different credentials 406

1.1.4.1.2.3. Modifying the login.jsp file 408

1.1.4.1.2.4. Customizing JSP files 409

1.1.4.1.2.5. Customizing the nidp_latest.jsp file 410

1.1.4.1.2.6. Configuring Identity Server to use custom login pages 416

1.1.4.1.2.7. Troubleshooting tips for custom login pages 422

1.1.4.1.3. Customizing the Identity Server logout page 423

1.1.4.1.3.1. Rebranding the logout page 424

1.1.4.1.3.2. Replacing the logout page with a custom page 425

1.1.4.1.3.3. Configuring for local rather than global logout 426

1.1.4.1.3.4. Customizing logout pages to redirect based on parameters 427

1.1.4.1.4. Customizing Identity Server messages 428

1.1.4.1.4.1. To customize Identity Server messages 429

1.1.4.1.4.2. Customizing the branding of the error page 431

1.1.4.1.4.3. Customizing tooltip text for authentication contracts 433

1.1.4.1.5. Maintaining customized Identity Server 434

1.1.4.1.6. Examples for customizing the User Portal page using configuration files 435

1.1.4.1.6.1. Example 1 436

1.1.4.1.6.2. Example 2 437

1.1.4.1.6.3. Example 3 438

1.1.4.1.6.4. Example 4 439

1.1.4.2. Customizing Access Gateway 440

1.1.4.2.1. Maintaining a customized Access Gateway 441

1.1.4.2.2. Customizing error messages and error pages on Access Gateway 442

1.1.4.2.2.1. Customizing and localizing Access Gateway error messages 443

1.1.4.2.2.2. Customizing the error pages 444

1.1.4.2.3. Customizing logout requests 445

1.1.4.2.3.1. Customizing applications to use Access Gateway logout page 446

1.1.4.2.3.2. Customizing Access Gateway logout page 447

1.1.4.2.3.3. Configuring the logout disconnect interval 449

1.1.5. Advanced file configurator 450

1.1.5.1. Managing files: older approach versus using advanced file configurator 452

1.1.5.2. Managing configuration files 453

1.1.5.2.1. Adding configurations to a cluster 454

1.1.5.2.2. Exporting and importing configurations 457

1.1.5.2.2.1. Exporting configurations from a cluster 458

1.1.5.2.2.2. Importing configurations 459

1.1.5.2.3. Comparing configuration files 460

1.1.5.2.4. Modifying configurations 463

1.1.5.2.5. Applying configurations to devices 466

1.1.5.2.6. Downloading files from a server 467

1.1.5.2.7. Untracking configurations 468

1.1.5.2.8. Removing configurations 469

1.1.5.2.9. Post-Upgrade considerations 470

1.1.5.3. Access Manager configuration files and folders 471

1.1.5.4. Example configuration: modifying web.xml to manage Administration Console 502

session timeout

1.1.5.5. Example: modifying server.xml to configure the encryption level 505

1.1.5.6. Configuring rate limit on Administration Console APIs 507

1.1.6. Configuring authentication 508

1.1.6.1. Authentication framework 509

1.1.6.1.1. Creating authentication classes 510

1.1.6.1.2. Creating a custom authentication class to obtain unstored transitional data 511

1.1.6.1.3. Configuring authentication methods 513

1.1.6.1.4. Configuring authentication contracts 516

1.1.6.1.4.1. Configuring options for an authentication contract 523

1.1.6.1.4.2. Using a password expiration service 524

1.1.6.1.4.3. Using login redirect URL parameters 526

1.1.6.1.4.4. Using activity realms 527

1.1.6.1.5. Specifying authentication defaults 528

1.1.6.1.5.1. Specifying authentication types 529

1.1.6.1.5.2. Creating a contract for a specific authentication type 530

1.1.6.2. Basic or form-based authentication 531

1.1.6.2.1. Configuring basic or form-based authentication 532

1.1.6.2.2. Specifying common class properties 535

1.1.6.2.2.1. Query property 536

1.1.6.2.2.2. JSP property 537

1.1.6.2.2.3. MainJSP property 538

1.1.6.2.2.4. Enabling reCAPTCHA 539

1.1.6.3. Kerberos authentication 541

1.1.6.3.1. Kerberos privileged attribute certificate 543

1.1.6.3.2. Prerequisites for configuring kerberos authentication 544

1.1.6.3.3. Configuring Active Directory 545

1.1.6.3.3.1. Creating and configuring the user account for Identity Server 546

1.1.6.3.3.2. Configuring the keytab file 548

1.1.6.3.3.3. Adding Identity Server to the forward lookup zone 549

1.1.6.3.4. Configuring Identity Server 550

1.1.6.3.4.1. Enabling logging for kerberos transactions 551

1.1.6.3.4.2. Configuring Identity Server for active directory 552

1.1.6.3.4.3. Creating the authentication class, method, and contract 554

1.1.6.3.4.4. Creating the bcslogin configuration file 557

1.1.6.3.4.5. Verifying the kerberos configuration 558

1.1.6.3.4.6. (Optional) excluding kerberos authentication for specific IP addresses 559

1.1.6.3.4.7. (Optional) configuring the fall back authentication class 560

1.1.6.3.4.8. (Optional) modifying the LDAP query parameter of the kerberos method 561

1.1.6.3.5. Configuring the clients 562

1.1.6.3.6. Configuring Access Gateway for kerberos authentication 564

1.1.6.4. RADIUS authentication 565

1.1.6.5. Mutual SSL (X.509) authentication 567

1.1.6.5.1. Configuring X.509 authentication 568

1.1.6.5.2. Configuring attribute mappings 571

1.1.6.5.3. Restricting the X.509 authentication to a specific certificate authority 575

1.1.6.5.4. Regular expression for extracting the partial string from DN 576

1.1.6.5.5. Setting up mutual SSL authentication 577

1.1.6.5.5.1. Customizing certificate errors 578

1.1.6.5.6. Configuring X.509 authentication to display the OpenText Access Manager error 579
message

1.1.6.5.6.1. Configuring a dual connector setup in a single-node Identity Server 580

environment

1.1.6.5.6.2. Configuring a dual connector setup in a multi-node Identity Server 582

environment

1.1.6.6. Passwordless authentication 585

1.1.6.7. Social authentication 586

1.1.6.7.1. Why and when to use social authentication 587

1.1.6.7.2. Prerequisites for social authentication 588

1.1.6.7.3. Configuring the social authentication class 589

1.1.6.7.4. How social authentication works with OpenText Access Manager 595

1.1.6.7.5. Adding images for social authentication providers 596

1.1.6.7.6. Changing the default icons of social authentication providers 597

1.1.6.7.7. Configuring supported social authentication providers for API keys and API 598
secrets

1.1.6.7.7.1. Integrating OpenText Access Manager with Facebook 599

1.1.6.7.7.2. Integrating OpenText Access Manager with Linkedin 601

1.1.6.7.7.3. Integrating OpenText Access Manager with X 602

1.1.6.7.7.4. Integrating OpenText Access Manager with Google+ 603

1.1.6.7.7.5. Integrating OpenText Access Manager with itsme 604

1.1.6.8. Risk-based authentication 605

1.1.6.8.1. Introduction to risk-based authentication 606

1.1.6.8.1.1. Why risk-based authentication 607

1.1.6.8.1.2. Features of risk-based authentication 608

1.1.6.8.1.3. Risk-Based authentication key terms 611

1.1.6.8.1.4. How risk-based authentication works 614

1.1.6.8.1.5. Understanding risk score calculation 617

1.1.6.8.2. Setting up localhost for risk service 620

1.1.6.8.3. Configuring risk-based authentication 621

1.1.6.8.3.1. Configuring a risk policy 622

1.1.6.8.3.2. Configuring a method for the risk-based authentication class 627

1.1.6.8.3.3. Configuring a contract for the risk-based authentication class 628

1.1.6.8.3.4. Configuring rules 629

1.1.6.8.4. Configuring user history 639

1.1.6.8.4.1. Configuring an external database to store user history 640

1.1.6.8.4.2. Enabling user history 644

1.1.6.8.5. Configuring geolocation profiling 645

1.1.6.8.6. Configuring behavioral analytics 646

1.1.6.8.7. Configuring NAT settings 649

1.1.6.8.8. Configuring an authorization policy to protect a resource 650

1.1.6.8.9. Understanding risk-based authentication through scenarios 651

1.1.6.8.9.1. Scenario: calculating risk based on the device type 652

1.1.6.8.9.2. Scenario: calculating risk based on the location from where an access request 653
originates

1.1.6.8.9.3. Scenario: calculating risk based on the HTTP header value 655

1.1.6.8.9.4. Scenario: evaluating the grant permissions using the historical access data 658

1.1.6.8.9.5. Scenario: calculating risk using device fingerprinting 659

1.1.6.8.9.6. Scenario: determining an improbable travel event 660

1.1.6.8.10. Risk-Based authentication: sample configuration 662

1.1.6.8.11. Troubleshooting risk-based authentication 666

1.1.6.8.11.1. Enabling logging for risk-based authentication 667

1.1.6.8.11.2. Enabling auditing for risk-based authentication events 668

1.1.6.8.11.3. Troubleshooting risk rule configuration 669

1.1.6.8.11.4. Audit events supported for behavioral analytics 674

1.1.6.9. SecureCredentialsAuthClass 675

1.1.6.9.1. Configuring class, method, and contract for securecredentialsauthclass 676

1.1.6.9.2. Verifying the securecredentialsauthclass configuration 677

1.1.6.10. Device fingerprinting 678

1.1.6.10.1. How it works 679

1.1.6.10.2. Understanding device fingerprint parameters 681

1.1.6.10.3. Configuring a device fingerprint rule 684

1.1.6.10.4. Configuring an example device fingerprint policy 686

1.1.6.11. Advanced Authentication 690

1.1.6.11.1. Prerequisites 698

1.1.6.11.2. Configuring Advanced Authentication 699

1.1.6.12. SAML 2.0 701

1.1.6.12.1. Understanding how OpenText Access Manager uses SAML 702

1.1.6.12.1.1. Attribute mapping with liberty 703

1.1.6.12.1.2. Trusted provider reference metadata 704

1.1.6.12.1.3. Authorization services 705

1.1.6.12.1.4. Identity provider process flow 706

1.1.6.12.1.5. SAML service provider process flow 707

1.1.6.12.2. Configuring a SAML 2.0 profile 708

1.1.6.12.3. Managing a SAML 2.0 service provider 712

1.1.6.12.3.1. Creating a SAML 2.0 service provider 713

1.1.6.12.3.2. Configuring multiple instances of a SAML 2.0 service provider in an Identity 714
Server cluster

1.1.6.12.3.3. Minimizing service interruption of SAML 2.0 service providers 715

1.1.6.12.3.4. Contracts assigned to a SAML 2.0 service provider 716

1.1.6.12.3.5. Configuring a SAML 2.0 authentication response 718

1.1.6.12.3.6. Executing an authorization-based role policy during SAML 2.0 service provider 720
initiated request

1.1.6.12.3.8. Configuring communication security for a SAML 2.0 service provider 722
1.1.6.12.4. Managing a SAML 2.0 identity provider 725

1.1.6.12.4.1. Creating a SAML 2.0 identity provider 726

1.1.6.12.4.2. Configuring a SAML 2.0 authentication request 727

1.1.6.12.4.3. Configuring communication security for a SAML 2.0 identity provider 733

1.1.6.12.4.4. Defining session synchronization for A-Select SAML 2.0 identity provider 734

1.1.6.12.5. Defining options for SAML 2.0 735

1.1.6.12.5.1. Defining options for a SAML 2.0 identity provider 736

1.1.6.12.5.2. Defining options for a SAML 2.0 identity provider 737

1.1.6.12.5.3. Defining options for a SAML 2.0 service provider 741

1.1.6.12.6. Configuring SAML 2.0 session timeout 744

1.1.6.12.7. OIOSAML 3 compliance 745

1.1.6.12.7.1. OIOSAML 3 metadata samples 748

1.1.6.12.7.2. Enabling OIOSAML compliance 756

1.1.6.12.8. Modifying an authentication card for SAML 2.0 757

1.1.6.12.9. Configuring multiple SAML 2.0 service providers on the same host for a single 759
SAML identity provider

1.1.6.12.10. Configuring active directory federation services with SAML 2.0 for single sign- 760
on

1.1.6.12.10.1. Prerequisites for configuring AD FS with SAML 2.0 761

1.1.6.12.10.2. Configuring OpenText Access Manager as a claims or identity provider and 762
AD FS 2.0 as a relying party or service provider

1.1.6.12.10.3. Configuring AD FS 2.0 as the claims or identity provider and OpenText 769
Access Manager as the relying party or service provider

1.1.6.12.10.4. AD FS 2.0 basics 773

1.1.6.12.10.5. Debugging AD FS 2.0 774

1.1.6.13. WS Federation 775

1.1.6.13.1. Using Identity Server as an identity provider for ADFS 776

1.1.6.13.1.1. Configuring Identity Server as an identity provider for ADFS 777

1.1.6.13.1.2. Configuring the ADFS server 783

1.1.6.13.1.3. Logging in 785

1.1.6.13.1.4. Troubleshooting 786

1.1.6.13.2. Using the ADFS server as an identity provider for an OpenText Access Manager 787
protected resource

1.1.6.13.2.1. Configuring Identity Server as a service provider 788

1.1.6.13.2.2. Configuring the ADFS server as an identity provider 792

1.1.6.13.2.3. Logging in 794

1.1.6.13.2.4. Additional WS federation configuration options 795

1.1.6.13.3. Managing WS Federation providers 796

1.1.6.13.3.1. Creating an identity provider for WS Federation 797

1.1.6.13.3.2. Creating a service provider for WS Federation 799

1.1.6.13.3.3. Contracts assigned to a WS Federation service provider 801

1.1.6.13.4. Modifying a WS Federation identity provider 802

1.1.6.13.4.1. Renaming the trusted provider 803

1.1.6.13.4.2. Configuring the attributes obtained at authentication 804

1.1.6.13.4.3. Modifying the user identification method 805

1.1.6.13.4.4. Viewing the WS identity provider metadata 806

1.1.6.13.4.5. Editing the WS identity provider metadata 807

1.1.6.13.4.6. Modifying the authentication card 808

1.1.6.13.4.7. Assertion validity window 809

1.1.6.13.5. Defining options for WS Federation service provider service provider 810

1.1.6.13.6. Modifying a WS Federation service provider 811

1.1.6.13.6.1. Renaming the service provider 812

1.1.6.13.6.2. Configuring the attributes set with authentication 813

1.1.6.13.6.3. Modifying the authentication response 814

1.1.6.13.6.4. Viewing the WS Federation service provider metadata 815

1.1.6.13.6.5. Editing the WS Federation service provider metadata 816

1.1.6.13.7. Configuring STS attribute sets 817

1.1.6.13.8. Configuring STS authentication methods 818

1.1.6.13.9. Configuring STS authentication request 819

1.1.6.14. WS-Trust security token service 820

1.1.6.14.1. Basic scenarios supported by WS-Trust STS 822

1.1.6.14.1.1. Web service client communicating with token protected web service provider 823

1.1.6.14.1.2. Web single sign-on and STS 824

1.1.6.14.1.3. Identity delegation and impersonation 825

1.1.6.14.1.4. Renewing a token 827

1.1.6.14.1.5. Authentication by using SAML tokens 828

1.1.6.14.2. Configuring WS-Trust STS 829

1.1.6.14.2.1. Enabling WS-Trust 830

1.1.6.14.2.2. Configuring OpenText Access Manager for WS-Trust STS 831

1.1.6.14.2.3. Viewing STS service details 832

1.1.6.14.3. Configuring service providers 833

1.1.6.14.3.1. Adding a domain and assigning WS-Trust operations 834

1.1.6.14.3.2. Adding web service providers 835

1.1.6.14.3.3. Managing service provider domains 837

1.1.6.14.3.4. Managing service providers 838

1.1.6.14.3.5. Modifying service providers 839

1.1.6.14.3.6. A sample WS-Policy for web service providers 840

1.1.6.14.4. Configuring web service clients 843

1.1.6.14.4.1. Configuring apache CXF-based web service clients 844

1.1.6.14.4.2. Configuring metro-based web service clients 845

1.1.6.14.5. Renew token - sample request and response 846

1.1.6.14.5.1. Renew token - sample request 847

1.1.6.14.5.2. Renew token - sample response 851

1.1.6.15. OAuth and OpenID Connect 855

1.1.6.15.1. How OAuth and OpenID Connect helps 856

1.1.6.15.2. OAuth keywords and their usage in OpenText Access Manager 857

1.1.6.15.3. Implementing OAuth in OpenText Access Manager 860

1.1.6.15.4. OIDC front-channel logout 861

1.1.6.15.5. Configuring OAuth and OpenID Connect 864

1.1.6.15.5.1. Enabling OAuth and OpenID Connect 865

1.1.6.15.5.2. Extending a user store for OAuth 2.0 authorization grant information 866

1.1.6.15.5.3. Defining global settings 868

1.1.6.15.5.4. Configuring a resource server 873

1.1.6.15.5.5. Defining scopes for a resource server 877

1.1.6.15.5.6. Managing OAuth client applications 882

1.1.6.15.6. Using Access Gateway in the OAuth flow 890

1.1.6.15.7. Configuring Access Gateway for OAuth 891

1.1.6.15.7.1. Enabling OAuth in Access Gateway 892

1.1.6.15.7.2. Configuring an authorization policy based on OAuth scopes 893

1.1.6.15.7.3. Configuring an identity injection policy for OAuth claims 895

1.1.6.15.7.4. Configuring an identity injection policy for user passwords 897

1.1.6.15.7.5. Configuring Access Gateway to inject OAuth tokens 898

1.1.6.15.8. OAuth scenarios 899

1.1.6.15.8.1. Web applications (Resource server) validate an access token before allowing a 900
client application to access resources

1.1.6.15.8.2. Access Gateway validates the access token on behalf of web applications 902

1.1.6.15.8.3. Access Gateway injects the access token on behalf of web applications 903

1.1.6.15.9. Mobile authentication 904

1.1.6.15.10. Exchanging SAML 2.0 assertions with access token 905

1.1.6.15.10.1. Configuring assertion issuers 906

1.1.6.15.11. Encrypting access token 907

1.1.6.15.11.1. Encrypting the token with the OpenText Access Manager key 908

1.1.6.15.11.2. Encrypting the token with the resource server key 909

1.1.6.15.12. Configuring multi-factor authentication for resource owner credentials grant 910

1.1.6.15.13. Viewing endpoint details 911

1.1.6.15.14. OAuth and OpenID Connect audit events 912

1.1.6.15.15. Enabling logging for OAuth and OpenID Connect 913

1.1.6.15.16. Managing client applications by using REST API 914

1.1.6.15.17. Managing OAuth 2.0 resource server and scope by using REST API 915

1.1.6.15.18. Revoking refresh tokens and the associated access tokens 916

1.1.6.15.19. Configuring the demo OAuth application 917

1.1.6.16. Federated authentication for specific providers 918

1.1.6.16.1. Setting up Google applications 919

1.1.6.16.2. Integrating Amazon web services with OpenText Access Manager 920

1.1.6.16.2.1. Enabling web single sign-on in the AWS console 921

1.1.6.16.2.2. Configuring AWS as a service provider in OpenText Access Manager 922

1.1.6.16.2.3. Integrating Amazon cloudtrail with OpenText Access Manager 924

1.1.6.16.3. Configuring single sign-on for Microsoft 365 services 925

1.1.6.16.3.1. Passive and active authentication 926

1.1.6.16.3.2. Configuring active and passive authentication through WS-Trust and WS- 927
Federation

1.1.6.16.3.3. Configuring federation with Microsoft 365 services for multiple domains 929

1.1.6.16.3.4. Configuring a Microsoft 365 domain that supports passive federation by 932
using SAML 2.0

1.1.6.16.3.5. Troubleshooting scenarios 936

1.1.6.16.3.6. Sample tokens 937

1.1.6.16.4. Integrating salesforce with OpenText Access Manager by using SAML 2.0 938

1.1.6.16.5. Integrating shibboleth identity provider with OpenText Access Manager 940

1.1.6.17. Other authentication types 941

1.1.6.17.1. Persistent authentication 942

1.1.6.17.1.1. Frequent re-authentication using password 943

1.1.6.17.1.2. Persistence auth class properties 944

1.1.6.17.1.3. Customizing the login page for persistent authentication 945

1.1.6.17.1.4. Configuring the persistent authenticator class 946

1.1.6.17.1.5. Logging out of the persistent sessions 947

1.1.6.17.1.6. Limitations of using persistent authentication class 948

1.1.6.17.2. ORed credential class 949

1.1.6.17.3. OpenID authentication 950

1.1.6.17.4. Password retrieval 953

1.1.6.17.5. Smart card authentication with NMAS 956

1.1.6.17.5.1. Prerequisites for configuring smart card authentication with NMAS 957

1.1.6.17.5.2. Creating a user store for the NESCM method 958

1.1.6.17.5.3. Creating a contract for the smart card 960

1.1.6.17.5.4. Assigning the NESCM contract to a protected resource 962

1.1.6.17.5.6. Troubleshooting 964

1.1.6.17.6. Two-factor authentication using time-based one-time password 965

1.1.6.17.6.1. Why two-factor authentication 966

1.1.6.17.6.2. Prerequisites for TOTP 967

1.1.6.17.6.3. Configuring TOTP class, method, and contract 968

1.1.6.17.6.4. Registering with TOTP 970

1.1.6.17.6.5. Verifying the TOTP configuration 971

1.1.6.17.7. Service provider brokering 972

1.1.6.17.7.1. SP brokering functionalities 974

1.1.6.17.7.2. Brokering flow 975

1.1.6.17.7.3. SP brokering deployment scenarios 976

1.1.6.17.7.4. Configuring a SP broker 977

1.1.6.17.7.5. Configuring a brokering for authorization of service providers 979

1.1.6.17.7.6. Creating and viewing brokering groups 980

1.1.6.17.7.7. Generating the brokering URLs by using an ID and target in the intersite 986
transfer service

1.1.6.17.7.8. Transient federation within SAML 2.0 987

1.1.6.17.7.9. Assigning the roles for the origin IDP users in SP broker using the transient 988
federation attributes

1.1.6.17.7.10. Assigning the local roles based on remote roles and attributes 989
1.1.6.17.7.11. SP brokering example 990

1.1.6.17.8. Configuring liberty 992

1.1.6.17.8.1. Configuring a liberty profile 993

1.1.6.17.8.2. Creating a liberty service provider 994

1.1.6.17.8.3. Creating a liberty identity provider 995

1.1.6.17.8.4. Configuring communication security for liberty 996

1.1.6.17.8.5. Configuring a liberty authentication request 997

1.1.6.17.8.6. Configuring the liberty authentication response 999

1.1.6.17.8.7. Defining options for liberty service provider 1000

1.1.6.17.8.8. Defining options for liberty identity provider 1001

1.1.6.17.8.9. Configuring the session timeout 1002

1.1.6.17.8.10. Modifying the authentication card 1003

1.1.6.17.9. Configuring liberty web services 1004

1.1.6.17.9.1. Web services framework 1005

1.1.6.17.9.2. Managing web services and profiles 1006

1.1.6.17.9.3. Configuring credential profile security and display settings 1011

1.1.6.17.9.4. Customizing attribute names 1013

1.1.6.17.9.5. Configuring the web service consumer 1014

1.1.6.17.9.6. Mapping LDAP and liberty attributes 1015

1.1.7. OpenText Access Manager policies 1020

1.1.7.1. Understanding policies 1021

1.1.7.1.1. Selecting a policy type 1022

1.1.7.1.2. Tuning the policy performance 1023

1.1.7.1.3. Managing policies 1024

1.1.7.1.3.1. Creating policies 1025

1.1.7.1.3.2. Sorting policies 1026

1.1.7.1.3.3. Deleting policies 1027

1.1.7.1.3.4. Renaming or copying a policy 1028

1.1.7.1.3.5. Importing and exporting policies 1029

1.1.7.1.3.6. Refreshing policy assignments 1030

1.1.7.1.3.7. Viewing policy information 1031

1.1.7.1.4. Managing policy containers 1032

1.1.7.1.5. Managing a rule list 1033

1.1.7.1.5.1. Rule evaluation for role policies 1034

1.1.7.1.5.2. Rule evaluation for authorization policies 1035

1.1.7.1.5.3. Rule evaluation for identity injection and form fill policies 1036

1.1.7.1.5.4. Viewing rules 1037

1.1.7.1.6. Adding policy extensions 1038

1.1.7.1.6.1. Installing the extension on Administration Console 1039

1.1.7.1.6.2. Distributing a policy extension 1041

1.1.7.1.6.3. Managing a policy extension configuration 1042

1.1.7.1.6.4. Viewing extension details 1043

1.1.7.1.7. Enabling policy logging 1044

1.1.7.2. Role policies 1045

1.1.7.2.1. Understanding RBAC in OpenText Access Manager 1046

1.1.7.2.1.1. Assigning all authenticated users to a role 1047

1.1.7.2.1.2. Using a role to create an authorization 1048

1.1.7.2.1.3. Using prioritized rules in an authorization policy 1049

1.1.7.2.2. Enabling role-based access control 1050

1.1.7.2.3. Creating roles 1051

1.1.7.2.3.1. Selecting conditions 1053

1.1.7.2.3.2. Using multiple conditions 1064

1.1.7.2.3.3. Selecting an action 1066

1.1.7.2.4. Example role policies 1068

1.1.7.2.4.1. Creating an employee role 1069

1.1.7.2.4.2. Creating a manager role 1070

1.1.7.2.4.3. Creating a rule for a contract with ORed credentials 1071

1.1.7.2.5. Creating OpenText Access Manager roles in an existing role-based policy 1072
system

1.1.7.2.5.1. Activating roles from external sources 1073

1.1.7.2.5.2. Using conditions to assign roles 1075

1.1.7.2.6. Mapping roles between trusted providers 1081

1.1.7.2.6.1. Prerequisites for mapping roles between trusted providers 1082

1.1.7.2.6.2. To map roles between trusted providers 1083

1.1.7.2.7. Enabling and disabling role policies 1084

1.1.7.2.8. Importing and exporting role policies 1085

1.1.7.3. Authorization policies 1086

1.1.7.3.1. Designing an authorization policy 1087

1.1.7.3.1.1. Controlling access with a deny rule and a negative condition 1088

1.1.7.3.1.2. Configuring the result on condition error option 1089

1.1.7.3.1.3. Many rules or many conditions 1090

1.1.7.3.1.4. Using multiple conditions 1091

1.1.7.3.1.5. Controlling access with multiple conditions 1093

1.1.7.3.1.6. Using permit rules with a deny rule 1094

1.1.7.3.1.7. Using deny rules with a general permit rule 1096

1.1.7.3.1.8. Public policies 1098

1.1.7.3.1.9. General design principles 1099

1.1.7.3.1.10. Using the refresh data option 1100

1.1.7.3.1.11. Assigning policies to resources 1101

1.1.7.3.2. Creating Access Gateway authorization policies 1102

1.1.7.3.3. Sample Access Gateway authorization policies 1104

1.1.7.3.3.1. Sample policies based on organizational rules 1105

1.1.7.3.3.2. Sample workflow policy 1108

1.1.7.3.4. Conditions 1111

1.1.7.3.4.1. Authentication contract condition 1113

1.1.7.3.4.2. Client IP condition 1115

1.1.7.3.4.3. Credential profile condition 1116

1.1.7.3.4.4. Current date condition 1118

1.1.7.3.4.5. Day of week condition 1119

1.1.7.3.4.6. Current day of month condition 1120

1.1.7.3.4.7. Current time of day condition 1121

1.1.7.3.4.8. HTTP request method condition 1122

1.1.7.3.4.9. LDAP attribute condition 1123

1.1.7.3.4.10. LDAP OU condition 1126

1.1.7.3.4.11. Liberty user profile condition 1128

1.1.7.3.4.12. Roles condition 1129

1.1.7.3.4.13. Risk score 1130

1.1.7.3.4.14. OAuth scopes 1131

1.1.7.3.4.15. URL condition 1132

1.1.7.3.4.16. URL scheme condition 1134

1.1.7.3.4.17. URL host condition 1135

1.1.7.3.4.18. URL path condition 1136

1.1.7.3.4.19. URL file name condition 1138

1.1.7.3.4.20. URL file extension condition 1139

1.1.7.3.4.21. Virtual attribute condition 1140

1.1.7.3.4.22. X-Forwarded-For IP condition 1141

1.1.7.3.4.23. Condition extension 1143

1.1.7.3.4.24. Data extension 1144

1.1.7.3.4.25. Using the URL dredge option 1145

1.1.7.3.4.26. Edit button 1146

1.1.7.3.5. Importing and exporting authorization policies 1147

1.1.7.4. Identity injection policies 1148

1.1.7.4.1. Designing an identity injection policy 1149

1.1.7.4.1.1. Using the refresh data option 1150

1.1.7.4.2. Configuring an identity injection policy 1151

1.1.7.4.3. Configuring an authentication header policy 1152

1.1.7.4.4. Configuring a custom header policy 1156

1.1.7.4.5. Configuring a custom header with tags 1159

1.1.7.4.6. Specifying a query string for injection 1162

1.1.7.4.7. Injecting into the cookie header 1165

1.1.7.4.8. Configuring an inject kerberos ticket policy 1166

1.1.7.4.9. Configuring an OAuth token inject policy 1169

1.1.7.4.10. Importing and exporting identity injection policies 1171

1.1.7.5. Form fill policies 1172

1.1.7.5.1. Understanding an HTML form 1173

1.1.7.5.2. Implementing form fill policies 1176

1.1.7.5.2.1. Designing a form fill policy 1177

1.1.7.5.2.2. Creating a form fill policy 1182

1.1.7.5.2.3. Creating a login failure policy 1187

1.1.7.5.2.4. Creating an inject JavaScript policy 1188

1.1.7.5.2.5. Troubleshooting a form fill policy 1191

1.1.7.5.3. Creating and managing shared secrets 1193

1.1.7.5.3.1. Naming conventions for shared secrets 1194

1.1.7.5.3.2. Creating a shared secret independent of a policy 1195

1.1.7.5.3.3. Modifying and deleting a shared secret 1196

1.1.7.5.4. Importing and exporting form fill policies 1197

1.1.7.5.5. Configuring a form fill policy for forms with scripts 1198

1.1.7.5.5.1. Why does form fill fail with the default policy? 1199

1.1.7.5.5.2. Understanding how a form is submitted 1202

1.1.7.5.5.3. Creating a form fill policy for autosubmission 1203

1.1.7.5.5.4. Configuring the advanced options for autosubmission 1204

1.1.7.6. External attribute source policies 1205

1.1.7.6.1. Enabling external attributes policy 1206

1.1.7.6.2. Creating an external attribute source policy 1207

1.1.7.6.3. External attribute source policy examples 1208

1.1.7.6.3.1. Scenario 1 1209

1.1.7.6.3.2. Scenario 2 1210

1.1.7.7. Risk-based policies 1212

1.1.8. Integrating OpenText Access Manager with Microsoft Azure 1213

1.1.8.1. Automatic Microsoft Entra hybrid join for Windows devices 1214

1.1.8.1.1. How automatic Microsoft Entra hybrid join works 1215

1.1.8.1.2. Setting up automatic Microsoft Entra hybrid join for windows devices 1217

1.1.8.1.2.1. Prerequisites for automatic Microsoft Entra hybrid join 1218

1.1.8.1.2.2. Preparing Microsoft Entra ID for automatic Microsoft Entra hybrid join 1219

1.1.8.1.2.3. Configuring OpenText Access Manager for automatic Entra hybrid join 1221

1.1.8.1.2.4. Validating Entra hybrid join 1222

1.1.8.1.2.5. Verifying device registration status 1223

1.1.8.1.3. Automatic Entra hybrid join for windows downlevel devices 1225

1.1.8.1.4. How SSO to Microsoft Azure applications work 1226

1.1.8.1.5. Troubleshooting automatic Entra hybrid join 1227

1.1.8.2. Microsoft Entra ID conditional access with OpenText Access Manager 1228

1.1.8.3. Registering devices to Microsoft Intune mobile device management 1231

1.1.8.4. Enabling OpenText Access Manager with Microsoft Windows Autopilot 1232

1.1.9. Appmarks 1234

1.1.9.1. Creating an appmark 1235

1.1.9.2. Creating multiple appmarks for an application 1239

1.1.9.3. Managing icons 1240

1.1.10. Enabling MobileAccess 1241

1.1.10.1. Requirements for the mobileaccess app 1242

1.1.10.2. Configuring the mobileaccess app 1243

1.1.10.3. Helping users register their mobile devices 1244

1.1.10.3.1. Registering ios devices 1245

1.1.10.3.2. Registering android devices 1246

1.1.10.3.2.1. Manual 1247

1.1.10.3.2.2. HTML page with anchor link 1248

1.1.10.4. Installing mobileaccess on a mobile device 1249

1.1.10.5. Understanding the mobileaccess PIN 1250

1.1.10.6. Managing mobile devices 1251

1.1.10.6.1. Deregistering mobile devices as an administrator 1252

1.1.10.6.2. Deregistering a mobile device as a user 1253

1.1.10.6.3. Deleting and reinstalling the mobileaccess app on a device 1254

1.1.11. OpenText Access Manager branding 1255

1.1.11.1. User Portal branding 1256

1.1.11.1.1. To customize the title of the user Portal 1257

1.1.11.2. Administration Console branding 1258

1.1.12. High availability and fault tolerance 1259

1.1.12.1. Installing secondary Administration Console Installing secondary OpenText 1260

Access Manager Appliance

1.1.12.1.1. Prerequisites for Installing secondary OpenText Access Manager 1261

ApplianceInstalling secondary Administration Console

1.1.12.1.1.1. Configuration notes 1262

1.1.12.1.1.2. Installing secondary Access Manager Appliance 1263

1.1.12.1.1.3. Managing Administration Consoles installed with clustered Identity Servers 1264

1.1.12.1.2. Installing second console 1265

1.1.12.1.3. Understanding how consoles interact with each other and with Access 1266
Manager devices

1.1.12.1.3.1. Tasks requiring the primary console 1267

1.1.12.1.3.2. Tasks available from the secondary console 1268

1.1.12.2. Configuration tips for the L4 switch 1269

1.1.12.2.1. Sticky bit 1270

1.1.12.2.2. Network configuration requirements 1271

1.1.12.2.3. Health checks 1272

1.1.12.2.3.1. Health checks for Identity Server 1273

1.1.12.2.3.2. Health checks for Access Gateway 1274

1.1.12.2.4. Real server settings example 1276

1.1.12.2.5. Virtual server settings example 1277

1.1.12.3. Setting up L4 switch for IPv6 support 1278

1.1.12.3.1. Web SSO over IPv6 1279

1.1.12.3.2. Federated SSO over IPv6 1280

1.1.12.3.2.1. Federated SSO over IPv6 using artifact binding 1281

1.1.12.3.2.2. Federated SSO over IPv6 using post binding 1282

1.1.12.3.3. Limitations 1283

1.1.12.4. Using a software load balancer 1284

1.1.13. Sample configuration for protecting an application 1286

1.1.13.1. Installation overview and prerequisites 1287

1.1.13.1.1. Installation architecture 1288

1.1.13.1.2. Installation architecture 1289

1.1.13.1.3. Deployment overview 1290

1.1.13.1.3.1. Prerequisite tasks 1291

1.1.13.1.3.2. Deployment tasks 1292

1.1.13.2. Setting up the web server 1293

1.1.13.2.1. Installing the Apache web server and PHP components 1294

1.1.13.2.2. Installing Digital Airlines components 1295

1.1.13.2.3. Configuring name resolution 1296

1.1.13.3. Configuring public access to Digital Airlines 1297

1.1.13.4. Implementing access restrictions 1300

1.1.13.4.1. Enabling an authentication procedure 1301

1.1.13.4.1.1. Common authentication problems 1302

1.1.13.4.2. Configuring a role-based policy 1303

1.1.13.4.2.1. Adding an LDAP attribute to your configuration 1304

1.1.13.4.2.2. Creating a sales role 1305

1.1.13.4.2.3. Creating a new user with a sales role 1307

1.1.13.4.2.4. Creating the identity injection policy for a custom header 1308

1.1.13.4.3. Assigning an authorization policy to protect a resource 1310

1.1.13.4.4. Configuring an identity injection policy for basic authentication 1313

1.1.13.4.4.1. Configuring the web server for basic authentication 1314

1.1.13.4.4.2. Creating an identity injection policy for basic authentication 1316

1.2. Security and certificates 1318

1.2.1. Securing OpenText Access Manager 1319

1.2.1.1. Configuring secure communication on Identity Server 1320

1.2.1.1.1. Configuring enhanced security for service provider communications 1321

1.2.1.1.2. Viewing the services that use the Signing key pairsigning 1322

1.2.1.1.2.1. Protocols 1323

1.2.1.1.2.2. SOAP backchannel 1324

1.2.1.1.2.3. Profiles 1325

1.2.1.1.3. Viewing services that use the Encryption key pairencryption 1326

1.2.1.1.4. Managing the keys, certificates, and trust stores 1327

1.2.1.2. Security considerations for Identity Server 1329

1.2.1.2.1. Federation options 1330

1.2.1.2.2. Authentication contracts 1331

1.2.1.2.3. Forcing 128-bit encryption 1332

1.2.1.2.4. Configuring the encryption method for the SAML assertion 1333

1.2.1.2.5. Blocking access to Identity Server pages 1334

1.2.1.2.6. Using nethsm for the signing key pair 1335

1.2.1.2.6.1. How Access Manager uses signing and interacts with the nethsm server 1336

1.2.1.2.6.2. Configuring Identity Server for nethsm 1338

1.2.2. Setting up session assurance 1351

1.2.3. Understanding OpenText Access Manager certificates 1360

1.2.3.1. Process flow 1361

1.2.3.2. OpenText Access Manager trust stores 1362

1.2.3.3. OpenText Access Manager keystores 1363

1.2.3.3.1. Identity Server keystores 1364

1.2.3.3.2. Access Gateway keystores 1365

1.2.3.3.3. Keystores when multiple devices are installed on Administration Console 1366

1.2.4. Creating certificates 1367

1.2.4.1. Creating a locally signed certificate 1368

1.2.4.2. Editing the subject name 1370

1.2.4.3. Assigning alternate subject names 1372

1.2.4.4. Generating a certificate signing request 1373

1.2.4.5. Importing a signed certificate 1374

1.2.5. Managing certificates and keystores 1375

1.2.5.1. Viewing certificate details 1376

1.2.5.2. Adding a certificate to a keystore 1380

1.2.5.3. Renewing a certificate 1381

1.2.5.4. Exporting a private/public key pair 1382

1.2.5.5. Exporting a public certificate 1383

1.2.5.6. Importing a private/public key pair 1384

1.2.5.7. Managing certificates in a keystore 1385

1.2.5.8. Using multiple external signing certificates 1387

1.2.6. Assigning certificates to OpenText Access Manager devices 1390

1.2.6.1. Importing a trusted root to the LDAP user store 1391

1.2.6.2. Managing Identity Server certificates 1392

1.2.6.3. Assigning certificates to an Access Gateway 1394

1.2.6.3.1. Managing embedded service provider certificates 1395

1.2.6.3.2. Managing reverse proxy and web server certificates 1396

1.2.6.4. Changing a non-secure (HTTP) environment to a secure (HTTPS) environment 1397

1.2.7. Managing trusted roots and trust stores 1398

1.2.7.1. Managing trusted roots and trust stores 1399

1.2.7.1.1. Importing public key certificates (Trusted roots) 1400

1.2.7.1.2. Adding trusted roots to trust stores 1401

1.2.7.1.3. Auto-Importing certificates from servers 1402

1.2.7.1.4. Exporting a public certificate of a trusted root 1403

1.2.7.1.5. Viewing trust store details 1404

1.2.7.1.6. Viewing trusted root details 1405

1.2.7.2. Viewing external trusted roots 1407

1.2.8. Enabling SSL communication 1408

1.2.8.1. Enabling SSL communication 1409

1.2.8.1.1. Identifying the SSL communication channels 1410

1.2.8.1.2. Using OpenText Access Manager certificates 1411

1.2.8.1.2.1. Configuring secure communication on Identity Server 1412

1.2.8.1.2.2. Configuring Access Gateway for SSL 1414

1.2.8.1.3. Using externally signed certificates 1415

1.2.8.1.3.1. Obtaining externally signed certificates 1416

1.2.8.1.3.2. Configuring Identity Server to use an externally signed certificate 1419

1.2.8.1.3.3. Configuring Access Gateway to use an externally signed certificate 1420

1.2.8.1.4. Using an SSL terminator 1421

1.2.8.1.4.1. Required setup 1422

1.2.8.1.4.2. Configuring the SSL terminator 1423

1.2.8.1.4.3. Configuring Access Gateway 1425

1.2.8.1.5. SSL renegotiation 1427

1.2.8.2. Using SSL on communication channels 1428

1.2.8.3. Configuring SSL for authentication between Identity Server and OpenText Access 1429
Manager components

1.2.8.4. Prerequisites for SSL 1430

1.2.8.4.1. Prerequisites for SSL communication between Identity Server and Access 1431
GatewayAccess Manager Appliance

1.2.8.4.2. Prerequisites for SSL communication between Access Gateway and web servers 1432

1.2.8.5. Configuring SSL communication with browsers and Access Gateway 1433

1.2.8.6. Configuring SSL between the proxy service and the web servers 1435

1.2.8.7. Configuring the SSL communication 1436

1.3. Maintaining OpenText Access Manager 1437

1.3.1. Auditing 1438

1.3.1.1. Setting up logging server and console events 1439

1.3.1.2. Important points to consider when using syslog 1443

1.3.1.2.1. Limitations of syslog 1444

1.3.1.2.2. Caching audit events 1445

1.3.1.2.3. Debugging syslog 1446

1.3.1.3. Configuring syslog for auditing over UDP and TLS 1447

1.3.1.3.1. Auditing using UDP 1448

1.3.1.3.2. Auditing using TLS over TCP 1449

1.3.1.3.3. Configuring Administration Console as a remote audit server 1451

1.3.1.4. Enabling Identity Server audit events 1453

1.3.1.5. Enabling Access Gateway audit events 1460

1.3.2. Logging 1462

1.3.2.1. Understanding the types of logging 1463

1.3.2.1.1. Component logging for troubleshooting configuration or network problems 1464

1.3.2.1.2. HTTP transaction logging for proxy services 1465

1.3.2.2. Understanding the log format 1466

1.3.2.2.1. Understanding the correlation tags in the log files 1468

1.3.2.2.2. Sample scenario 1471

1.3.2.3. Identity Server logging 1472

1.3.2.3.1. Configuring logging for Identity Server 1473

1.3.2.3.1.1. Enabling component logging 1474

1.3.2.3.1.2. Managing log file size 1477

1.3.2.3.2. Configuring session-based logging 1478

1.3.2.3.2.1. Creating class, method, and contract for administrator and logging session 1479

1.3.2.3.2.2. Enabling basic logging 1484

1.3.2.3.2.3. Responding to an incident 1485

1.3.2.3.3. Capturing stack traces of exceptions 1488

1.3.2.4. Access Gateway logging 1490

1.3.2.4.1. Managing Access Gateway logs 1491

1.3.2.4.1.1. Configuring the log level 1492

1.3.2.4.1.2. Configuring the log file 1494

1.3.2.4.2. Configuring logging of HTTP headers 1495

1.3.2.4.2.1. Configuring logging headers in request from client to proxy 1496

1.3.2.4.2.2. Configuring logging headers in response from proxy to client 1497

1.3.2.4.3. Configuring logging of SOAP messages 1498

1.3.2.4.4. Configuring logging for a proxy service 1499

1.3.2.4.4.1. Determining logging requirements 1500

1.3.2.4.4.2. Calculating rollover requirements 1501

1.3.2.4.4.3. Enabling logging 1503

1.3.2.4.4.4. Configuring common log options 1504

1.3.2.4.4.5. Configuring extended log options 1505

1.3.2.4.4.6. Configuring the size of the log partition 1510

1.3.2.5. Downloading log files 1511

1.3.2.5.1. Administration Console logs 1512

1.3.2.5.2. Identity Server logs 1513

1.3.2.5.3. Access Gateway Appliance and Access Gateway service logs 1514

1.3.2.6. Turning on logging for policy evaluation 1515

1.3.3. Monitoring component statistics 1516

1.3.3.1. Identity Server statistics 1517

1.3.3.1.1. Monitoring Identity Server statistics 1518

1.3.3.1.1.1. Application 1519

1.3.3.1.1.2. Authentications 1520

1.3.3.1.1.3. Incoming HTTP requests 1523

1.3.3.1.1.4. Outgoing HTTP requests 1524

1.3.3.1.1.5. SAML 2 1525

1.3.3.1.1.6. WSF (Web services framework) 1526

1.3.3.1.1.7. Clustering 1530

1.3.3.1.1.8. LDAP 1532

1.3.3.1.1.9. SP brokering 1533

1.3.3.1.1.10. Risk-based authentication 1534

1.3.3.1.1.11. OAuth 1535

1.3.3.1.2. Monitoring Identity Server cluster statistics 1536

1.3.3.2. Access Gateway statistics 1537

1.3.3.2.1. Monitoring Access Gateway statistics 1538

1.3.3.2.1.1. Server activity statistics 1539

1.3.3.2.1.2. Server benefits statistics 1547

1.3.3.2.1.3. Service provider activity statistics 1548

1.3.3.2.2. Monitoring Access Gateway cluster statistics 1554

1.3.3.3. Component statistics through REST APIs 1556

1.3.4. OpenText Access Manager licensing 1557

1.3.4.1. How licensing works 1558

1.3.4.2. Viewing license details 1559

1.3.4.3. Applying a license 1560

1.3.4.4. Renewing a subscription license 1561

1.3.4.5. OpenText Access Manager licensing API 1562

1.3.5. Monitoring component command status 1563

1.3.5.1. Viewing the Identity Server command status 1564

1.3.5.1.1. Viewing the Identity Server current commands status 1565

1.3.5.1.2. Viewing the Identity Server detailed command information 1566

1.3.5.2. Viewing the Access Gateway command status 1567

1.3.5.2.1. Viewing the Access Gateway current commands status 1568

1.3.5.2.2. Viewing the Access Gateway detailed command information 1569

1.3.6. Monitoring server health 1570

1.3.6.1. Health status 1571

1.3.6.2. Monitoring the health using the hardware IP address 1572

1.3.6.3. Monitoring the health of Identity Servers 1573

1.3.6.3.1. Monitoring the health of an Identity Server 1574

1.3.6.3.2. Monitoring the health of a cluster 1577

1.3.6.4. Monitoring the health of Access Gateways 1578

1.3.6.4.1. Monitoring the health of an Access Gateway 1579

1.3.6.4.1.1. Service categories of Access Gateway Appliance 1580

1.3.6.4.1.2. Service categories of Access Gateway service 1583

1.3.6.4.2. Monitoring the health of an Access Gateway cluster 1586

1.3.7. Monitoring alerts 1587

1.3.7.1. Monitoring Identity Server alerts 1588

1.3.7.2. Monitoring Access Gateway alerts 1590

1.3.7.2.1. Viewing Access Gateway alerts 1591

1.3.7.2.2. Viewing Access Gateway cluster alerts 1592

1.3.7.2.3. Managing Access Gateway alert profiles 1593

1.3.7.2.4. Configuring Access Gateways alert profile 1594

1.3.7.2.5. SNMP profile 1597

1.3.7.2.6. Configuring a log profile 1598

1.3.7.2.7. Configuring an email profile 1599

1.3.7.2.8. Configuring a syslog profile 1600

1.3.8. Monitoring OpenText Access Manager by using simple network management 1601
protocol

1.3.8.1. SNMP architecture in OpenText Access Manager 1602

1.3.8.2. Features of monitoring using SNMP 1603

1.3.8.3. Using the default MIB file with external SNMP systems 1604

1.3.8.4. Querying for SNMP attributes 1606

1.3.8.5. Enabling monitoring for OpenText Access Manager components 1607

1.3.9. Impersonation 1608

1.3.9.1. Impersonation terminology 1609

1.3.9.2. Prerequisites for creating an impersonated session 1610

1.3.9.3. Enabling impersonation 1611

1.3.9.4. Impersonation flow 1612

1.3.9.5. Implementing impersonation in custom portal pages 1613

1.3.9.5.1. Understanding the impersonation-specific JSP files 1614

1.3.9.5.2. Determining when to show the specific JSP files 1615

1.3.9.6. Audit event for impersonation 1616

1.3.9.7. Troubleshooting 1617

1.3.10. Back up and restore 1618

1.3.10.1. How the backup and restore process works 1619

1.3.10.1.1. The default parameters for backup and restore 1620

1.3.10.1.2. The process for backup and restore 1621

1.3.10.2. Backing up the OpenText Access Manager configuration 1622

1.3.10.3. Restoring the OpenText Access Manager configuration 1623

1.3.10.3.1. Restoring the configuration on a standalone Administration Console 1624

1.3.10.3.2. Restoring the configuration with an Identity Server on the same machine 1625

1.3.10.4. Restoring Identity Server 1626

1.3.10.5. Restoring an Access Gateway 1627

1.3.10.5.1. Restoring an Access Gateway cluster 1628

1.3.10.5.2. Restoring a single Access Gateway 1629

1.3.11. Code promotion 1630

1.3.11.1. How code promotion helps 1631

1.3.11.2. Sequence of promoting the configuration data 1632

1.3.11.3. Prerequisites for performing code promotion 1633

1.3.11.4. Exporting the configuration data 1634

1.3.11.5. Importing the configuration data 1635

1.3.11.5.1. Uploading the configuration file to import 1636

1.3.11.5.2. Selecting a component to import the configuration data 1637

1.3.11.5.3. Importing the Identity Server configuration data 1638

1.3.11.5.3.1. Importing Identity Server clusters 1639

1.3.11.5.4. Importing the Access Gateway configuration data 1640

1.3.11.5.4.1. Selecting proxy services and protected resources to import 1641

1.3.11.5.4.2. Verifying the component-specific configuration changes 1642

1.3.11.5.4.3. Updating Identity Server user store references 1643

1.3.11.5.4.4. Setting up new proxy services in the target system after the import 1644

1.3.11.5.5. Post-import configuration tasks 1645

1.3.11.6. Troubleshooting code promotion 1647

1.3.11.7. Code promotion limitations 1648

1.3.12. Upgrade assistant 1649

1.3.13. Troubleshooting OpenText Access Manager 1656

1.3.13.1. Troubleshooting Administration Console 1657

1.3.13.1.1. Global troubleshooting options 1658

1.3.13.1.1.1. Checking for potential configuration problems 1659

1.3.13.1.1.2. Checking for version conflicts 1662

1.3.13.1.1.3. Checking and terminating user sessions 1663

1.3.13.1.1.4. Checking for invalid policies 1664

1.3.13.1.1.5. Viewing system alerts 1665

1.3.13.1.2. Diagnostic configuration export utility 1666

1.3.13.1.3. Restoring a failed secondary console 1667

1.3.13.1.4. Moving the primary Administration Console to a new hardware 1668

1.3.13.1.5. Converting a secondary Administration Console or Access Manager Appliance 1669

into a primary Console or Appliance

1.3.13.1.5.1. Shutting down primary Administration ConsoleAccess Manager Appliance 1670

1.3.13.1.5.2. Changing the master replica 1671

1.3.13.1.5.3. Restoring CA certificates 1672

1.3.13.1.5.4. Verifying the vcdn.conf file 1673

1.3.13.1.5.5. Deleting objects from the eDirectory configuration store 1674

1.3.13.1.5.6. Performing component-specific procedures 1675

1.3.13.1.6. Repairing the configuration datastore 1678

1.3.13.1.7. Session conflicts 1679

1.3.13.1.8. Unable to log in to Administration Console 1680

1.3.13.1.9. Exception processing identityservice_serverpage.jsp 1681

1.3.13.1.10. Backup and restore fail because of special characters in passwords 1682

1.3.13.1.11. Unable to install the NMAS SAML method 1683

1.3.13.1.12. Incorrect audit configuration 1684

1.3.13.1.13. Unable to update Access Gateway listening IP address in Administration 1685

Console reverse proxy

1.3.13.1.14. During installation any error message should not display successful status 1686

1.3.13.1.15. Incorrect health is reported on Access Gateway 1687

1.3.13.1.16. Administration Console does not refresh the command status automatically 1688

1.3.13.1.17. SSL communication with weak ciphers fails 1689

1.3.13.1.18. Error: tomcat did not stop in time. PID file was not removed 1690

1.3.13.1.19. An IP address for the other known device manager list is missing in the 1691
troubleshooting page
1.3.13.1.20. (OpenText Access Manager on cloud) metadata under system setup of SAML 1692
2 applications is displayed after a delay of 5 to 10 seconds

1.3.13.1.21. Administration Console shows the malformed request error 1693

1.3.13.1.22. Identity provider cluster options are not completely displayed on screen sizes 1694
13.3 inches or lesser

1.3.13.1.23. Application connectors page is unable to retrieve Identity Server clusters 1695
intermittently

1.3.13.1.24. Accessing a direct link might display forbidden access error 1696

1.3.13.2. Troubleshooting Access Gateway 1697

1.3.13.2.1. Useful troubleshooting files 1698

1.3.13.2.1.1. Apache logging options for gateway service 1699

1.3.13.2.1.2. Access Gateway service log files 1700

1.3.13.2.2. Verifying that all services are running 1701

1.3.13.2.3. Microsoft office documents do not open when SharePoint is accelerated by 1703
Access Gateway Appliance

1.3.13.2.4. Troubleshooting SSL connection issues 1704

1.3.13.2.5. Enabling debug mode and core dumps 1705

1.3.13.2.5.1. Starting apache in the debug mode 1707

1.3.13.2.5.2. Examining the debug information 1708

1.3.13.2.5.3. Disabling the debug mode 1709

1.3.13.2.5.4. Enabling the core dumps in RHEL 1710

1.3.13.2.6. useful troubleshooting tools for access gateway service 1711

1.3.13.2.7. Solving apache restart issues 1712

1.3.13.2.7.1. Removing an advanced configuration settings 1713

1.3.13.2.7.2. Viewing the logged apache errors 1714

1.3.13.2.7.3. Viewing the errors as apache generates them 1715

1.3.13.2.7.4. The activemq module fails to start 1716

1.3.13.2.8. Understanding the authentication process of Access Gateway service 1717

1.3.13.2.9. Issue while accelerating the ajax applications 1721

1.3.13.2.10. Accessing lotus-inotes through Access Gateway asks for authentication 1722
1.3.13.2.11. Configuration issues 1723

1.3.13.2.12. Embedded service provider does not start 1724

1.3.13.2.13. Cannot inject a photo into HTTP headers 1725

1.3.13.2.14. Access Gateway caching issues 1726

1.3.13.2.15. Issues while changing the management IP address in Access Gateway 1727

1.3.13.2.16. Issue while adding Access Gateway in a cluster 1728

1.3.13.2.17. Clustered nodes looping due to JGroup issues 1729

1.3.13.2.18. Issue with memory leak by apache httpd child process 1730

1.3.13.3. Troubleshooting Identity Server and authentication 1731

1.3.13.3.1. Useful networking tools for Identity Server 1732

1.3.13.3.2. Troubleshooting 100101043 and 100101044 liberty metadata load errors 1733

1.3.13.3.2.1. Metadata 1734

1.3.13.3.2.2. DNS name resolution 1735

1.3.13.3.2.3. Certificate names 1736

1.3.13.3.2.4. Certificates in the required trust stores 1737

1.3.13.3.2.5. Enabling debug logging 1739

1.3.13.3.2.6. Testing whether a provider can access the metadata 1741

1.3.13.3.2.7. Manually creating any auto-generated certificates 1742

1.3.13.3.3. Authentication issues 1743

1.3.13.3.3.1. Authentication classes and duplicate common names 1744

1.3.13.3.3.2. General authentication troubleshooting tips 1745

1.3.13.3.3.3. Slow authentication 1746

1.3.13.3.3.4. Federation errors 1747

1.3.13.3.3.5. Mutual authentication troubleshooting tips 1748

1.3.13.3.3.6. Browser hangs in an authentication redirect 1749

1.3.13.3.3.7. Duplicate set-cookie headers 1750

1.3.13.3.4. Problems in reading keystores after reinstalling Identity Server 1752

1.3.13.3.5. After setting up the user store to use secretstore, users report 500 errors 1753
1.3.13.3.6. When the multiple browser logout option is enabled, a user does not get 1754
logged out from different sessions

1.3.13.3.7. After consuming a SAML response, the browser is redirected to an incorrect 1755
URL

1.3.13.3.8. Attributes are not available through form fill when OIOSAML is enabled 1756

1.3.13.3.9. An issue in importing metadata while configuring identity provider or service 1757
provider using the metadata URL

1.3.13.3.10. Enabling secure or HTTPOnly flags for cluster cookies 1758

1.3.13.3.11. Apache Portable runtime native library does not get loaded in tomcat 1759

1.3.13.3.12. Metadata mentions triple des as encryption method 1760

1.3.13.3.13. An issue in accessing protected resources with external identity provider 1761
when both providers use same cookie domain

1.3.13.3.14. SAML intersite transfer URL setup does not work for non-brokered setups 1762
after enabling SP brokering

1.3.13.3.15. Orphaned identity objects 1763

1.3.13.3.16. Users cannot log in to Identity Server when they access protected resources 1764
with any contract assigned

1.3.13.3.17. An attribute query from OIOSAML.SP java service provider fails with null 1765
pointer

1.3.13.3.18. Disabling the certificate revocation list checking 1766

1.3.13.3.19. Step up authentication for Identity Server initiated SSO to external provider 1767
does not work unless it contains a matching local contract

1.3.13.3.20. Metadata cannot be retrieved from the URL 1768

1.3.13.3.21. Authentication request to a service provider fails 1769

1.3.13.3.22. SAML 2.0 POST compression failure does not throw a specific error code 1770

1.3.13.3.23. Identity Server statistics logs do not get written in less than one minute 1771

1.3.13.3.24. No error message is written in the log file when an expired certificate is used 1772
for the X509 authentication

1.3.13.3.25. Terminating an existing authenticated user from Identity Server 1773

1.3.13.3.26. X.509 authentication lists the entire list of certificates imported to the 1774
browser

1.3.13.3.27. Authentication with aliases fails 1775

1.3.13.3.28. nidp/app does not redirect to nidp/portal after authentication 1776

1.3.13.3.29. Login to Microsoft 365 fails when WS-Trust MEX metadata is larger than 65 1777
KB

1.3.13.3.30. Unsafe server certificate change in SSL/TLS renegotiations is not allowed 1778

1.3.13.3.31. Viewing request and response headers of all protocols in a log file 1779

1.3.13.3.32. Provisioning of an LDAP attribute for social authentication user failed 1780

1.3.13.3.33. User authentication fails when the Advanced Authentication generic class is 1781
used

1.3.13.3.34. Cannot create an authentication class with OpenText Advanced 1782

Authentication generic class

1.3.13.3.35. A CORS request to the token introspection endpoint fails 1784

1.3.13.3.36. The user Portal page does not display the branding 1785

1.3.13.3.37. The SAML authentication fails when an unsigned request contains an ACS 1786
URL

1.3.13.3.38. Unable to perform single sign-on when Microsoft Entra ID is the identity 1787
provider

1.3.13.3.39. Debug logs suppression for WS-Trust authentication failure 1788

1.3.13.3.40. Troubleshooting issuing of PRT tokens 1789

1.3.13.4. Troubleshooting certificate issues 1790

1.3.13.4.1. Resolving the JCC communication between devices and Administration 1791
Console

1.3.13.4.2. Resolving certificate import issues 1792

1.3.13.4.2.1. Importing an external certificate key pair 1793

1.3.13.4.2.2. Resolving a -1226 PKI error 1794

1.3.13.4.2.3. When the full certificate chain is not returned during an automatic import of 1795
the trusted root

1.3.13.4.2.4. Using internet explorer to add a trusted root chain 1796

1.3.13.4.3. Mutual SSL with X.509 produces untrusted chain messages 1797

1.3.13.4.4. Certificate command failure 1798

1.3.13.4.5. Cannot log in with certificate error messages 1799

1.3.13.4.6. When a user accesses a resource, the browser displays certificate errors 1800
1.3.13.4.7. Canceling certificates modification results in errors 1801

1.3.13.4.8. A device reports certificate errors 1802

1.3.13.4.9. Renewing the expired eDirectory certificates 1803

1.3.13.4.10. Certificate trust store objects of the Identity Server clusters are deleted 1804
randomly

1.3.13.4.11. Secondary Administration Console does not reflect the replaced certificate 1805

1.3.13.5. Troubleshooting OpenText Access Manager policies 1806

1.3.13.5.1. Turning on logging for policy evaluation 1807

1.3.13.5.2. Common configuration problems that prevent a policy from being applied as 1808
expected

1.3.13.5.2.1. Enabling roles for authorization policies 1809

1.3.13.5.2.2. LDAP attribute condition 1810

1.3.13.5.2.3. Result on condition error value 1811

1.3.13.5.2.4. An external secret store and form fill 1812

1.3.13.5.3. The policy is using old user data 1813

1.3.13.5.4. Form fill and identity injection silently fail 1816

1.3.13.5.5. Checking for corrupted policies 1817

1.3.13.5.6. Policy page timeout 1818

1.3.13.5.7. Policy creation and storage 1819

1.3.13.5.8. Policy distribution 1820

1.3.13.5.9. Policy evaluation: Access Gateway devices 1821

1.3.13.5.9.1. Successful policy configuration example 1822

1.3.13.5.9.2. No policy defined configuration example 1823

1.3.13.5.9.3. Deny access configuration/evaluation example 1824

1.3.13.6. Troubleshooting mobileaccess 1826

1.3.13.6.1. Using the same mobile device for different users causes the expired session 1827
error

1.3.13.6.2. Simple authentication with a pop-up browser window does not work for 1828
mobileaccess
1.3.13.6.3. Users fail to authenticate to mobileaccess when appmarks are launched in the 1829
chrome browser

1.3.13.6.4. Changes to mobileaccess do not appear in Administration Console 1830

1.3.13.6.5. Facebook basic SSO connector does not work from mobileaccess 1831

1.3.13.7. Troubleshooting code promotion 1832

1.3.13.7.1. Troubleshooting Identity Server code promotion 1833

1.3.13.7.1.1. Exporting Identity Server configuration data fails 1834

1.3.13.7.1.2. Importing Identity Server configuration data fails 1835

1.3.13.7.2. Troubleshooting Access Gateway code promotion 1836

1.3.13.7.2.1. Exporting Access Gateway configuration data fails 1837

1.3.13.7.2.2. Importing Access Gateway configuration data fails 1838

1.3.13.7.2.3. Policy configuration is locked 1839

1.3.13.7.2.4. Access Gateway configuration is locked 1840

1.3.13.7.2.5. Access Gateway cluster is not associated with any Identity Server 1841

1.3.13.7.2.6. Proxy service type does not match 1842

1.3.13.7.2.7. Policy type does not match 1843

1.3.13.7.2.8. Cannot import a virtual proxy service to SSL enabled master proxy 1844

1.3.13.7.2.9. Cookie domain and published DNS name do not match 1845

1.3.13.7.2.10. SSL enabled web server configuration is imported to a non-ssl proxy service1846

1.3.13.7.2.11. Names of master proxy service are different 1847

1.3.13.7.2.12. Reverse proxy and master proxy service do not exist 1848

1.3.13.7.2.13. Proxy service does not exist in the target setup 1849

1.3.13.7.2.14. DNS name is not unique 1850

1.3.13.7.2.15. Revert process fails for Access Gateway 1851

1.3.13.7.3. Troubleshooting device customization code promotion 1852

1.3.13.7.3.1. Custom files are not imported 1853

1.3.13.8. Troubleshooting the device fingerprint rule 1854

1.3.13.8.1. Enabling the debug option for the device fingerprint rule 1855

1.3.13.8.2. Using logs to understand how the device fingerprint rule is evaluated 1856
1.3.13.8.2.1. A fingerprint does not exist 1857

1.3.13.8.2.2. Fingerprint matches 1858

1.3.13.8.2.3. Fingerprint does not match 1859

1.3.13.8.2.4. When fingerprint matches though some parameters in the group do not 1860
match

1.3.13.8.2.5. When fingerprint does not match as the evaluation of group parameters 1861
fails

1.3.13.9. Troubleshooting session assurance 1862

1.3.13.9.1. Troubleshooting using the log files 1863

1.3.13.9.1.1. Using logs 1864

1.3.13.9.1.2. Using debug logs 1866

1.3.13.9.2. Important error messages 1869

1.3.13.9.2.1. Cookie mismatch. the session might have been hijacked. logging out session 1870

1.3.13.9.2.2. Nonce has been used already. possible replay attack. logging out the session1871

1.3.13.9.2.3. Fingerprint evaluation failed. the session might have been hijacked. logging 1872
out the session

1.3.13.9.3. Checking session assurance configuration details 1873

1.3.13.9.4. The advanced session assurance page does not display the Access Gateway 1875
cluster

1.3.13.10. Troubleshooting XML validation errors on Access Gateway Appliance 1876

1.3.13.10.1. Modifying a configuration that references a removed object 1877

1.3.13.10.2. Configuration UI writes incorrect information to the local configuration store 1879

1.3.13.11. Troubleshooting OAuth and OpenID Connect 1883

1.3.13.11.1. The token endpoint returns an invalid code error message 1884

1.3.13.11.2. OAuth tokens are in binary format instead of JWT format 1885

1.3.13.11.3. Users cannot register a client application 1886

1.3.13.11.4. Token exchanges show redirect URI invalid error 1887

1.3.13.11.5. Users cannot register or modify a client application with specific options 1888

1.3.13.11.6. A specific claim does not come to the userinfo endpoint during claims 1889
request
1.3.13.11.7. Access Gateway OAuth fails 1890

1.3.13.11.8. After allowing consent, 500 internal server error occurs 1891

1.3.13.11.9. The access token does not get exchanged with authorization code when 1892
using a multi-node Identity Server cluster

1.3.13.11.10. No error message when a token request contains repetitive parameters 1893

1.3.13.11.11. OAuth token encryption/signing key is compromised or corrupted 1894

1.3.13.11.12. Tracing OAuth requests 1895

1.3.13.11.13. OAuth client registration fails if a role policy contains a condition other than 1896
LDAP attribute, LDAP group, or LDAP OU

1.3.13.11.14. The identity injection policy does not inject passwords 1897

1.3.13.11.15. OAuth apps fail after upgrading OpenText Access Manager 1898

1.3.13.11.16. Authorization server responds with the service unavailable message for a 1899
revocation request

1.3.13.11.17. Unable to delete scopes that contain special characters 1900

1.3.13.11.18. OAuth client application returns an error message 1901

1.3.13.12. Troubleshooting user attribute retrieval and transformation 1902

1.3.13.12.1. No value is fetched from attribute source in Identity Server 1903

1.3.13.12.2. Error message while testing a database connection 1904

1.3.13.12.3. Regex replace error message 1905

1.3.13.13. Troubleshooting impersonation 1906

1.3.13.13.1. Internet explorer caching error 1907

1.3.13.14. Troubleshooting rebranding 1908

1.3.13.14.1. Changes to masthead does not appear after upgrade 1909

1.3.13.15. Troubleshooting licensing 1910

1.3.13.15.1. Access Manager continues to display the old license although a new license is1911
applied

1.3.13.16. Using log files for troubleshooting 1912

1.3.13.16.1. Sample authentication traces 1913

1.3.13.16.1.1. Direct authentication request to Identity Server 1914

1.3.13.16.1.2. Protected resource authentication trace 1917

1.3.13.16.2. Understanding policy evaluation traces 1919

1.3.13.16.2.1. Format 1920

1.3.13.16.2.2. Policy result values 1928

1.3.13.16.2.3. Role assignment traces 1931

1.3.13.16.2.4. Identity injection traces 1933

1.3.13.16.2.5. Authorization traces 1935

1.3.13.16.2.6. Form fill traces 1937

1.3.13.16.3. Adding hashed cookies into browsers 1941

1.3.13.16.3.1. Adding hashed Identity Server cookies into browsers 1942

1.3.13.16.3.2. Adding hashed Access Gateway cookies into browsers 1943

1.3.13.16.3.3. Adding hashed ESP cookies into browsers 1944

1.3.13.17. Troubleshooting social authentication 1945

1.3.13.17.1. Cases of alphabets in the consumer key fails to update 1946

1.3.14. OpenText Access Manager audit events and data 1947

1.3.14.1. JavaScript object notation (JSON) event format 1951

1.3.14.2. NIDS: sent a federate request (002e0001) 1954

1.3.14.3. NIDS: received a federate request (002e0002) 1955

1.3.14.4. NIDS: sent a defederate request (002e0003) 1956

1.3.14.5. NIDS: received a defederate request (002e0004) 1957

1.3.14.6. NIDS: sent a register name request (002e0005) 1958

1.3.14.7. NIDS: received a register name request (002e0006) 1959

1.3.14.8. NIDS: logged out an authentication that was provided to a remote consumer 1960
(002e0007)

1.3.14.9. NIDS: logged out a local authentication (002e0008) 1961

1.3.14.10. NIDS: provided an authentication to a remote consumer (002e0009) 1962

1.3.14.11. NIDS: user session was authenticated (002e000a) 1963

1.3.14.12. NIDS: failed to provide an authentication to a remote consumer (002e000b) 1964

1.3.14.13. NIDS: user session authentication failed (002e000c) 1965

1.3.14.14. NIDS: received an attribute query request (002e000d) 1966

1.3.14.15. NIDS: user account provisioned (002e000e) 1967

1.3.14.16. NIDS: failed to provision a user account (002e000f) 1968

1.3.14.17. NIDS: web service query (002e0010) 1969

1.3.14.18. NIDS: web service modify (002e0011) 1970

1.3.14.19. NIDS: connection to user store replica lost (002e0012) 1971

1.3.14.20. NIDS: connection to user store replica reestablished (002e0013) 1972

1.3.14.21. NIDS: server started (002e0014) 1973

1.3.14.22. NIDS: server stopped (002e0015) 1974

1.3.14.23. NIDS: server refreshed (002e0016) 1975

1.3.14.24. NIDS: intruder lockout (002e0017) 1976

1.3.14.25. NIDS: severe component log entry (002e0018) 1977

1.3.14.26. NIDS: warning component log entry (002e0019) 1978

1.3.14.27. NIDS: failed to broker an authentication from identity provider to service 1979
provider as identity provider and service provider are not in same group (002e001a)

1.3.14.28. NIDS: failed to broker an authentication from identity provider to service 1980
provider because a policy evaluated to deny (002e001b)

1.3.14.29. NIDS: brokered an authentication from identity provider to service provider 1981
(002e001c)

1.3.14.30. NIDS: web service request was authenticated (002e001d) 1982

1.3.14.31. NIDS: web service request for authentication failed (002e001e) 1983

1.3.14.32. NIDS: OAuth2 authorization code issued (002e0028) 1984

1.3.14.33. NIDS: OAuth2 token issued (002e0029) 1985

1.3.14.34. NIDS: OAuth2 authorization code issue failed (002e0030) 1986

1.3.14.35. NIDS: openid token issued (002e0031) 1987

1.3.14.36. NIDS: OAuth2 refresh token issued (002e0032) 1988

1.3.14.37. NIDS: OAuth2 token issue failed (002e0033) 1989

1.3.14.38. NIDS: openid token issue failed (002e0034) 1990

1.3.14.39. NIDS: OAuth2 refresh token issue failed (002e0035) 1991

1.3.14.40. NIDS: OAuth2 client has been registered successfully (002e0036) 1992
1.3.14.41. NIDS: OAuth2 client has been modified successfully (002e0037) 1993

1.3.14.42. NIDS: OAuth2 client has been deleted successfully (002e0038) 1994

1.3.14.43. NIDS: OAuth2 user has provided consent (002e0039) 1995

1.3.14.44. NIDS: OAuth2 user has revoked consent (002e0040) 1996

1.3.14.45. NIDS: OAuth2 token validation success (002e0041) 1997

1.3.14.46. NIDS: OAuth2 token validation failed (002e0042) 1998

1.3.14.47. NIDS: OAuth2 client registration failed (002e0043) 1999

1.3.14.48. NIDS: OAuth2 refresh token revoked success (002e0055) 2000

1.3.14.49. NIDS: OAuth2 refresh token revocation failed (002e0056) 2001

1.3.14.50. NIDS: OAuth2 authorization none issued (002e0057) 2002

1.3.14.51. NIDS: OAuth2 OIDC front-channel logout success (002e0058) 2003

1.3.14.52. NIDS: OAuth2 AA authorization code exchange (002e0071) 2004

1.3.14.53. NIDS: OAuth2 AA access token exchange (002e0072) 2005

1.3.14.54. NIDS: step-up authentication (002e0719) 2006

1.3.14.55. NIDS: roles PEP configured (002e0300) 2007

1.3.14.56. NIDS: risk-based authentication action for user (002e0045) 2008

1.3.14.57. NIDS: risk-based authentication action for user (002e0046) 2009

1.3.14.58. NIDS: risk-based authentication action for user (002e0047) 2010

1.3.14.59. NIDS: token was issued to web service (002e001f) 2011

1.3.14.60. NIDS: issued a federation assertion (002e0102) 2012

1.3.14.61. NIDS: received a federation assertion (002e0103) 2013

1.3.14.62. NIDS: assertion information (002e0104) 2014

1.3.14.63. NIDS: sent a federation request (002e0105) 2015

1.3.14.64. Access Gateway: PEP configured (002e0301) 2016

1.3.14.65. Roles assignment policy evaluation (002e0320) 2017

1.3.14.66. Access Gateway: authorization policy evaluation (002e0321) 2018

1.3.14.67. Access Gateway: form fill policy evaluation (002e0322) 2019

1.3.14.68. Access Gateway: identity injection policy evaluation (002e0323) 2020

1.3.14.69. Access Gateway: access denied (0x002e0505) 2021

1.3.14.70. Access Gateway: URL not found (0x002e0508) 2022

1.3.14.71. Access Gateway: system started (0x002e0509) 2023

1.3.14.72. Access Gateway: system shutdown (0x002e050a) 2024

1.3.14.73. Access Gateway: identity injection parameters (0x002e050c) 2025

1.3.14.74. Access Gateway: identity injection failed (0x002e050d) 2026

1.3.14.75. Access Gateway: form fill authentication (0x002e050e) 2027

1.3.14.76. Access Gateway: form fill authentication failed (0x002e050f) 2028

1.3.14.77. Access Gateway: URL accessed (0x002e0512) 2029

1.3.14.78. Access Gateway: IP access attempted (0x002e0513) 2030

1.3.14.79. Access Gateway: webserver down (0x002e0515) 2031

1.3.14.80. Access Gateway: all webservers for a service is down (0x002e0516) 2032

1.3.14.81. Access Gateway: application accessed (002e0514) 2033

1.3.14.82. Access Gateway: session created (002e0525) 2034

1.3.14.83. Management communication channel: health change (0x002e0601) 2035

1.3.14.84. Management communication channel: device imported (0x002e0602) 2036

1.3.14.85. Management communication channel: device deleted (0x002e0603) 2037

1.3.14.86. Management communication channel: device configuration changed 2038

(0x002e0604)

1.3.14.87. Management communication channel: device alert (0x002e0605) 2039

1.3.14.88. Management communication channel: statistics (002e0606) 2040

1.3.14.89. Risk-Based authentication successful (002e0025) 2041

1.3.14.90. Risk-Based authentication failed (002e0026) 2042

1.3.14.91. Risk-Based authentication for user (002e0027) 2043

1.3.14.92. Impersonation sign in (002e0048) 2044

1.3.14.93. Impersonation: impersonator logs out (002e0049) 2045

1.3.14.94. Impersonation: session started (002e0050) 2046

1.3.14.95. Impersonation: impersonatee denies (002e0051) 2047

1.3.14.96. Impersonation: impersonatee approves (002e0052) 2048

1.3.14.97. Impersonation: impersonator cancels (002e0053) 2049

1.3.14.98. Impersonation: authorization policy fails (002e0054) 2050

1.3.15. Event codes 2051

1.3.15.1. Administration Console (009) 2052

1.3.15.2. Identity Server (001) 2099

1.3.15.3. Linux Access Gateway Appliance(045) 2154

1.3.15.4. Access Gateway service (046) 2157

1.3.15.5. Server communications (JCC) (007) 2164

1.3.15.6. Policy engine (008) 2189

1.3.15.7. SOAP policy enforcement point (011) 2195

1.3.15.8. Backup and restore (010) 2202

1.3.15.9. Modular authentication class (012) 2211

1.4. Appendix 2213

1.4.1. What is federated authentication 2214

1.4.1.1. Understanding a simple federation scenario 2215

1.4.1.2. Configuring federation 2216

1.4.1.2.1. Prerequisites for configuring federation 2217

1.4.1.2.2. Establishing trust between providers 2218

1.4.1.2.2.1. Configuring site A to trust site B as a service provider 2219

1.4.1.2.2.2. Configuring site B to trust site A as an identity provider 2221

1.4.1.2.2.3. Verifying the trust relationship 2224

1.4.1.2.2.4. Configuring user authentication 2225

1.4.1.3. Sharing roles 2227

1.4.1.3.1. Configuring role sharing 2229

1.4.1.3.1.1. Defining a shared attribute set 2230

1.4.1.3.1.2. Obtaining the role assignments 2231

1.4.1.3.1.3. Configuring policies to process received roles 2232

1.4.1.3.2. Verifying the configuration 2234

1.4.1.4. Setting up federation with third-party providers 2236

1.4.2. Understanding liberty 2237

1.4.3. Data model extension XML 2238

1.4.3.1. Elements 2239

1.4.3.2. Writing data model extension XML 2241

1.4.4. SOAP versus REST API 2244

1.4.5. OAuth versus other protocols 2245

1.4.6. OAuth concepts 2246

1.4.6.1. OAuth terminology 2247

1.4.6.2. Why OpenID connect 2249

1.4.6.3. OAuth authorization grant 2250

1.4.6.3.1. Authorization code grant (Web server) 2251

1.4.6.3.2. Implicit grant 2252

1.4.6.3.3. Resource owner credential grant 2253

1.4.6.3.4. Client credential grant 2254

1.4.6.3.5. Security assertion markup language (SAML) 2.0 bearer grant 2255

1.4.6.4. Authentication flows 2256

1.4.6.4.1. Authentication by using the authorization code flow 2257

1.4.6.4.2. Authentication by using the implicit flow 2258

1.4.6.4.3. Authentication by using hybrid flow 2259

1.4.6.5. End user operations 2260

1.4.6.5.1. User authorization 2261

1.4.6.5.2. Revoking authorizations 2262

1.4.7. OpenText Access Manager reports samples 2263

1.4.7.1. Application access summary report 2264

1.4.7.2. User application access summary report 2265

1.4.7.3. Application specific user access report 2266

1.4.7.4. Federation summary report 2267

1.4.7.5. User login contract summary report 2268

1.4.7.6. User login failure report 2269

1.4.7.7. Application specific risk based authentication report 2270

 Access Manager 25.2

1. Administration guide
This guide provides an introduction to OpenText Access Manager and details about how to configure and maintain OpenText
Access Manager features.
This book is intended for administrators. It is assumed that the administrators know about 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)
To know more about OpenText Access Manager, see Product overview.

Note
Contact [email protected] for any query related to Access Manager SDK

This PDF was generated on July 27, 2025 Page 1 of 2270

 Access Manager 25.2

1.1. Configuring OpenText Access Manager

This section describes how to set up a basic OpenText Access Manager configuration, perform common administration tasks,
and manage configuration of the components. For configuring OpenText Access Manager, you can use the latest version of
Internet Explorer, Google Chrome, or Firefox browsers.
Topics include:
Configuring Administration Console
Setting up a basic Identity Server cluster
Setting up an advanced OpenText Access Manager configuration
Customizing OpenText Access Manager
Advanced file configurator
Configuring authentication
OpenText Access Manager policies
Integrating OpenText Access Manager with Microsoft Azure
Appmarks
Enabling mobile access
OpenText Access Manager branding
High availability and fault tolerance
Sample configuration for protecting an application

This PDF was generated on July 27, 2025 Page 2 of 2270

 Access Manager 25.2

1.1.1. Configuring Administration Console

Managing Administration Console session timeout
Managing administrators
Performing administrative tasks
Changing the IP address of OpenText Access Manager devices
Mapping the private IP address to public IP address

This PDF was generated on July 27, 2025 Page 3 of 2270

 Access Manager 25.2

1.1.1.1. Managing Administration Console session timeout

The web.xml file for Tomcat specifies how long an Administration Console session can remain inactive before the session
times out. The administrators must authenticate again if they are inactive for more than the specified time. The default value is
30 minutes.
Perform the following steps to change this value:
1. Open the web.xml 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 July 27, 2025 Page 4 of 2270

 Access Manager 25.2

1.1.1.2. Managing administrators

You can create administrators with different access controls and manage them in Administration Console.
Administration Console notifies you when another administrator makes changes to a policy container or to an OpenText Access
Manager device. The person who is currently editing the configuration is listed at the top of the page with an option to unlock
and with the person’s distinguished name and IP address. Unlocking destroys all changes done by the other administrator.

Caution
Locking is not available the Identity Server pages. In case of multiple administrators, they need to coordinate with
each other and only one administrator modifies an Identity Server cluster at any given time.

Multiple sessions: Do not start multiple sessions of Administration Console in the same browser on a workstation. Browser
sessions share settings that can result in problems when you apply changes to configuration settings. However, if you are
using two different brands of browsers simultaneously, such as Internet Explorer and Firefox, it is possible to avoid the session
conflicts.
Multiple Administration Consoles: All configuration changes must be made in the primary console. If you make changes in
both primary and secondary consoles, the configuration might become invalid due to browser caching.
To know how to create additional administrator accounts, how to delegate rights to administrators, and how to manage policy
view administrators, see Identity Console Installation Guide and Identity Console Administration Guide.

This PDF was generated on July 27, 2025 Page 5 of 2270

 Access Manager 25.2

1.1.1.3. Performing administrative tasks

You can perform the following administrative tasks using Identity Console.
Creating Multiple Administrator Accounts
Managing Policy View Administrators
Managing Delegated Administrators
To install Identity Console and perform the above-mentioned administrative tasks, see Identity Console Installation Guide and
Identity Console Administration Guide.

This PDF was generated on July 27, 2025 Page 6 of 2270

 Access Manager 25.2

1.1.1.3.1. Creating multiple administrator accounts

Administration Console is installed with one administrator user account. If you have multiple administrators, you might want to
create a user account for each one so that log files reflect the modifications done by each administrator. To do this, create a
new user as a trustee of the tree root with [Entry Rights] for Supervisor and inheritable rights assignment. This ensures that
you have more than one user who has full access to Administration Console. If you have only one administrator user and the
user forgets the password, you cannot access Administration Console.
To create a new user as a trustee of the tree root, see Identity Console Installation Guide and Identity Console Administration
Guide.
You can also create delegated administrators and grant them rights to specific components of OpenText Access Manager. For
information, see Managing delegated administrators.

This PDF was generated on July 27, 2025 Page 7 of 2270

 Access Manager 25.2

1.1.1.3.2. Managing policy view administrators

Super administrators can create policy view administrators. Policy view administrators can log in to OpenText Access Manager
with their credentials and can only view the policy containers assigned to them.
Policy view administrators are created same as creating users. For more information, see Creating users. In Step 6.b, select
“ou=policyviewusers, o=novell” option in Context.
After creating a user, assign rights to the newly created user. See Policy container administrators.

This PDF was generated on July 27, 2025 Page 8 of 2270

 Access Manager 25.2

1.1.1.3.3. Managing delegated administrators

As an OpenText Access Manager administrator, you can create delegated administrators to manage the following components
of the product:
Individual Access Gateways or an Access Gateway cluster
Identity Servers
Policy containers

Important
Delegated administrators are granted sufficient rights to compromise the security of the system. Hence, they must
be trustworthy. For example, delegated administrators with view/modify rights to policy containers can implement a
cross-site scripting attack by using the Deny Message in an Access Gateway authorization policy.
Delegated administrators are also granted rights to the LDAP server. They can access the configuration datastore
with an LDAP browser. OpenText Access Manager does not log any modifications made with the LDAP browser.

By default, all users except the administrator are assigned no rights to the policy containers and the devices. The administrator
has all rights and cannot be configured to have less than all rights. The administrator is the only user who has the rights to
delegate rights to other users, and the only user who can modify keystores, create certificates, and import certificates.
Configuration pages for delegated administrators control access to the product pages. They do not control access to the tasks
available for the Manage Roles & Tasks view. If you want your delegated administrators to have rights to any of these tasks
such as Directory Administration or Groups, you must use eDirectory methods to grant the user rights to these tasks .
To create a delegated administrator, see Identity Console Installation Guide and Identity Console Administration Guide.
Upon creating a user, perform the following:
1. On the Home page, click [user name] > Administrators.
2. Select the component you want to assign a user to manage.
For information about the types of rights you can assign for each component, see the following:
Access Gateway administrators
Policy container administrators
Delegated administrators of Identity Servers

Note
While creating delegated administrators, specify the following value for Context , which is a mandatory
field:
delegatedusers.novell for delegated administrators
policyviewusers.novell for policy view administrators

3. To assign all delegated administrators the same rights to a component, configure the All Users option. Available options
include None, View Only, or View/Modify.
By default, All Users is configured for None. All Users is a quick way to assign View Only rights to a component when
you want your delegated administrators to have only the view rights.
4. To select one or more users to assign rights, click Add, then specify the following details:
Name filter: Specify a string that you want the user’s cn attribute to match. The default value is an asterisk, which
matches all cn values.
Search from context: Specify the context you want used for the search. Click the down-arrow to select from a list of
available contexts.
Include subcontainers: Specifies whether subcontainers must be searched for users.
5. Click Query.

This PDF was generated on July 27, 2025 Page 9 of 2270

 Access Manager 25.2

6. In User, select users to whom you want to grant the same rights.
7. In Access, select one of the following values:
View/Modify: Grants full configuration rights to the device. View/Modify rights do not grant the rights to manage
keystores, to create certificates, or to import certificates from other servers or certificate authorities. View/Modify rights
allow the delegated administrator to perform actions such as stop, start, and update the device.
If the assignment is to a policy container, this option grants the rights to create policies of any type and to modify any
existing policies in the container
View only: Grants the rights to view all the configuration options of the device or all rules and conditions of the policies in
a container.
None: Prevents the user from seeing the device or the policy container.
8. In Device or Policy Containers, select the devices, clusters, or policy containers that you want to assign for delegated
administration.
9. Click Apply.
The rights are immediately assigned to the selected users. This assignment overwrites any previous assignments.
10. After assigning rights to a user, check the user’s effective rights.
A user’s effective rights and assigned rights do not always match. For example, if Kim is granted View Only rights, but All
Users have been granted View/Modify rights, Kim’s effective rights are View/Modify.

This PDF was generated on July 27, 2025 Page 10 of 2270

 Access Manager 25.2

1.1.1.3.3.1. Access Gateway administrators

You can assign a user to be a delegated administrator of an Access Gateway cluster or a single Access Gateway that does not
belong to a cluster. You cannot assign a user to manage a single member of a cluster.
When a delegated administrator of an Access Gateway cluster is granted View/Modify rights, the administrator has sufficient
rights to change the cluster configuration, to stop and start (or reboot and shut down), and to update Access Gateways in the
cluster. However, to configure Access Gateway to use SSL, you need to be the administrator user, rather than a delegated
administrator.
When the user is assigned View/Modify rights to manage a cluster or an Access Gateway, the user is automatically granted
View Only rights to the master policy container. If you have created other policy containers, these containers are hidden until
you grant the delegated administrator rights to them. View Only rights allows the delegated administrator to view the policies
and assign them to protected resources. It does not allow them to modify the policies. If you want the delegated administrator
to modify or create policies, you need to grant View/Modify rights to a policy container.
View/Modify rights to an Access Gateway or a cluster allows the delegated administrator to modify which Identity Server
cluster Access Gateway uses for authentication. It does not allow delegated administrators to update Identity Server
configuration, which is required whenever Access Gateway is configured to trust an Identity Server. To update Identity Server,
the delegated administrator needs View/Modify rights to Identity Server configuration.

This PDF was generated on July 27, 2025 Page 11 of 2270

 Access Manager 25.2

1.1.1.3.3.2. Policy container administrators

The policy container administrators are of two types:
Delegated Administrators
Policy View Administrators
Delegated Administrators
All delegated administrators with View/Modify rights to a device have read rights to the master policy container. To create or
modify policies, a delegated administrator needs View/Modify rights to a policy container. When a delegated administrator has
View/Modify rights to any policy container, the delegated administrator is also granted enough rights to allow the administrator
to select shared secret values, attributes, LDAP groups, and LDAP OUs to policies.
If you want your delegated administrators to have full control over a device and its policies, you might want to create a
separate policy container for each delegated administrator or for each device that is managed by a group of delegated
administrators.
Policy View Administrators
A policy view administrator has rights only to view policy containers. The super administrators can create a special type of
delegated administrators called policy view administrators. The policy view administrators can log in to OpenText Access
Manager with their credentials and they are allowed to view only the policy containers assigned to them.
Using Policy Container option, the super administrators can add and remove the delegated and policy view administrators.
Adding Administrators
Removing Administrators

Adding policy container administrators

The administrator can assign the rights to the delegated administrators and the users based on the policy containers.
1. On the Home page, click <user name> at the top right of the page > Administrators > Policy Containers > Add
Administrators.
2. (Optional) Specify the filter.
3. Select Access Rights from the list for the type of administrator. For Example, View/Modify, View Only, and None. The
policy view administrators have only View Only rights.
4. Select the search from context in the list. For example, “ou=delegated users, o=novell, ou=policyviewusers, o=novell”.
Based on the user selected, the delegated or policy view administrators are created.
5. (Optional) Select Include Subcontainers, if you want to add it.
6. Click Query.
7. Select User and Policy Container. The users and policy containers list are displayed based on the association with query.
8. Click Apply > Close.

Removing policy container administrators

1. On the Home page, click <[user name]> at the top right of the page > Administrators > Policy Containers > Remove
Administrators.
2. Select the check box of the user assigned to the administrator and click Remove.
3. Click Close.

This PDF was generated on July 27, 2025 Page 12 of 2270

 Access Manager 25.2

1.1.1.3.3.3. Delegated administrators of Identity Servers

You cannot assign a delegated administrator to an individual Identity Server. You can only assign a delegated administrator to a
cluster configuration, which gives the delegated administrator rights to all the cluster members.
When a delegated administrator of an Identity Server cluster is granted the View/Modify rights, the administrator has sufficient
rights to change the cluster configuration and to stop, start, and update Identity Servers in that cluster. The administrator is
granted view rights to the keystores for each Identity Server in the cluster. To change any of the certificates, the administrator
needs to be the admin user rather than a delegated administrator.
The delegated administrator of an Identity Server cluster is granted View Only rights to the master policy container. If you want
the delegated administrator with View/Modify rights to have sufficient rights to manage policies, grant the following rights:
To have sufficient rights to create Role policies, grant View/Modify rights to a policy container.
To have sufficient rights to enable Role policies, grant View Only rights to the policy containers with Role policies.

This PDF was generated on July 27, 2025 Page 13 of 2270

 Access Manager 25.2

1.1.1.3.3.4. Creating users

After creating users, you can assign the role of a delegated administrator or policy view administrator.
To assign the role, see Identity Console Installation Guide and Identity Console Administration Guide.

This PDF was generated on July 27, 2025 Page 14 of 2270

 Access Manager 25.2

1.1.1.4. Changing the IP address of OpenText Access Manager

devices
Changing the IP address of Administration Console
Changing the IP address of Identity Server
Changing the IP address of Access Gateway Appliance
Changing the IP address of Access Gateway service
Changing the IP address of audit server

This PDF was generated on July 27, 2025 Page 15 of 2270

 Access Manager 25.2

1.1.1.4.1. Changing the IP address of Administration Console

Install Administration Console with the IP address that it will always use. All devices imported into Administration Console use
this IP address to establish a secure communication with Administration Console.
The only tested method of changing the IP address so that all other devices trust Administration Console is to install a
secondary console with the new IP address and then promote the secondary console to be the primary console.

Note
You must upload a full product license in secondary Administration Console while installing, upgrading, or
promoting secondary Administration Console in upgrade and fresh install scenarios.

See the following sections:

Installing secondary Administration Console Installing secondary Access Manager Appliance
Converting a secondary Administration ConsoleAccess Manager Appliance into a primary ConsoleAppliance
Converting a secondary console into a primary console is designed as a disaster recovery solution when the primary console is
no longer available.

Note
To access the Administration Console with Fully Qualified Domain Name (FQDN), the FQDN must be reachable from
the Administration console.

This PDF was generated on July 27, 2025 Page 16 of 2270

 Access Manager 25.2

1.1.1.4.2. Changing the IP address of Identity Server

These instructions assume that your Identity Server and Administration Console are not on the same machine. If they are on
the same machine, see Changing the IP address of Administration Console.
Perform the following steps to move a machine or change the IP address for Identity Server:
1. On the Home page, click Identity Servers > Server actions > Stop the Server for which you require to change the IP
address.
2. Click Server actions > Remove from this Cluster.
3. Click Unassigned Servers and then select the same Identity Server. Click Cluster actions > Delete this Cluster.
4. On the Identity Server machine, stop the server communication service by using the following command:
/etc/init.d/novell-jcc stop OR systemctl stop -jcc
5. Change the IP address by using an operating system utility:
Click YaST > Network Devices > Network Card, select a method, select the card, and click Edit.
6. Change to the /opt/novell/devman/jcc directory:
7. Run the conf/Configure.sh command.
The command must be run from the jcc directory because it needs access to files that are available from this directory.
8. When prompted for the local listener IP address, specify the new IP address.
9. When prompted for the administration server IP, specify the IP address of Administration Console.
10. Follow the prompts and accept the defaults for ports and administrator user.
11. Replace all references of the old IP address in the server.xml file with the new IP address.
For information about how to edit a file, see Modifying configurations.
12. Re-import Identity Server with the new IP address into Administration Console.
1. On the Identity Server machine, change to the /opt/novell/devman/jcc directory:
2. Run the ./conf/reimport_nidp.sh jcc script for jcc.
3. Run the ./conf/reimport_nidp.sh nidp script for Administration Console.
4. Replace <admin> with the name of your Administration Console administrator.

Note
If these steps do not work, see Troubleshooting Identity Server import and installation.

5. Add reimported Identity Server to the cluster.

This PDF was generated on July 27, 2025 Page 17 of 2270

 Access Manager 25.2

1.1.1.4.3. Changing the IP address of Access Gateway

Appliance
To change the IP address of Access Gateway, you need to configure Access Gateway for this change. This is especially
significant when Access Gateway Appliance has only one IP address.

Important
The new IP address must be configured in Administration Console before you change it on Access Gateway. If you
change the address on Access Gateway first, Administration Console does not trust Access Gateway and cannot
establish the communication.

1. On the Home page, click Access Gateways > Edit > Adapter List.
2. (Conditional) If the machine belongs to a cluster, select Access Gateway from Cluster Member.
3. From the Adapter List, select the subnet mask that contains the IP address you want to change.
4. Select the old IP address, click Change IP Address, specify the new IP address, then click OK.
This option changes all configuration instances of the old IP address to the new IP address. For example, any reverse
proxies that have been assigned the old IP address as a listening address are modified to use the new IP address as the
listening address.
5. Click OK.
6. To apply your changes, click the Access Gateways link, then click Update > OK.
7. If you are physically moving the machine, move it before completing the rest of these steps.
8. Check the IP address that Administration Console uses for managing Access Gateway. Click Access Gateways > [access
gateway name] > Edit.
9. If the old IP address is listed as the Management IP Address, select the new IP address. If your Access Gateway has
multiple IP addresses, select the one that you want Administration Console to use for communication with Access
Gateway.
The port must only be modified if there is another device on Access Gateway that is using the default port of 1443.
10. If the name of Access Gateway is the old IP address, modify the Name option.
11. Click OK.
Administration Console uses the configured IP address to find Access Gateway.
12. On the Access Gateway server, restart Tomcat:
/etc/init.d/novell-mag restart OR systemctl restart -mag
For the Docker deployment, perform the following steps:
1. Run the kubectl get pods command to view the OpenText Access Manager pods.
2. Go to the Access Gateway pod by running the kubectl exec --namespace <name-of-the-namespace> -it
pod/<name-of-the-access-gateway-pod> -- sh command.
3. Run the /etc/init.d/novell-mag restart or systemctl restart -mag command.
If your Access Gateway stops reporting to Administration Console after completing these steps, trigger an auto-import. See
Triggering an import retry.

This PDF was generated on July 27, 2025 Page 18 of 2270

 Access Manager 25.2

1.1.1.4.4. Changing the IP address of Access Gateway service

1. On Access Gateway Service, use a system utility to add the new IP address.
Do not delete the old IP address at this time.
Start YaST, click Network Devices > Network Card, then select the Traditional Method.
2. On the Home page, click Access Gateways > [access gateway name] > New IP.
3. Click OK. Wait for the command to complete.
4. Change the management IP address:
1. On the Server Details page, click Edit.
2. If the old IP address is listed as the Management IP Address, select the new IP address.
If your Access Gateway has multiple IP addresses, select the one that you want Administration Console to use for
communication with Access Gateway.
3. (Conditional) Modify the port if there is another device on Access Gateway that is using the default port of 1443.
4. If the name of Access Gateway is the old IP address, modify the Name option.
5. Click OK.
Administration Console uses the configured IP address to find Access Gateway.
5. To verify that the new IP address is being used, check the health of Access Gateway.
6. Edit Access Gateway configuration so that the reverse proxies use the new IP address:
You need to complete these steps for each reverse proxy.
1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy].
2. (Conditional) If a member of a cluster, select the cluster member that has a new IP address.
3. For the listening address, deselect the old IP address and select the new IP address.
4. Apply the settings and update Access Gateway.
5. Verify that everything is working correctly by accessing a resource protected by this reverse proxy.
7. On Access Gateway Service machine, use a system utility to remove the old IP address.
8. Remove the old IP address from Administration Console:
1. On the Home page, click Access Gateways> [access gateway name]> New IP.
2. Click OK.
Wait for the command to complete.
3. To verify that the old address has been removed, click Edit and verify that the old address is not an option for the
Management IP Address.

This PDF was generated on July 27, 2025 Page 19 of 2270

 Access Manager 25.2

1.1.1.4.5. Changing the IP address of audit server

1. On the Home page, click Auditing.
2. Change the IP address for the server and, if necessary, the port.
3. Click OK.
4. Update all Access Gateways.

This PDF was generated on July 27, 2025 Page 20 of 2270

 Access Manager 25.2

1.1.1.5. Mapping the private IP address to public IP address

Use NAT Settings on the Home page to configure mapping of Administration Console private IP address to public NAT IP
address.
Devices that cannot reach the private Administration Console IP address use the NAT IP address. You must specify the NAT IP
addresses prior to importing devices.
You can perform the following activities by using Global Settings:
Creating a new NAT IP address mapping
Removing a NAT IP address mapping
Viewing the NAT IP address mapping
Editing a NAT IP address mapping

This PDF was generated on July 27, 2025 Page 21 of 2270

 Access Manager 25.2

1.1.1.5.1. Creating a new NAT IP address mapping

1. On the Home page, click NAT Settings > New.
2. Select an IP address from the Administration Console Listening IP Address list.
3. Specify the Public NAT IP Address.

Note
If NAT IP address is not provided or if a mapping already exists for the selected Administration Console IP, this
message is displayed:

IP Address is not valid

4. To continue, click OK, then click Apply Changes.

This PDF was generated on July 27, 2025 Page 22 of 2270

 Access Manager 25.2

1.1.1.5.2. Removing a NAT IP address mapping

1. On the Home page, click NAT Settings.
2. Select the IP address you want to delete.
3. Click Delete > OK.

This PDF was generated on July 27, 2025 Page 23 of 2270

 Access Manager 25.2

1.1.1.5.3. Viewing the NAT IP address mapping

1. On the Home page, click NAT Settings. You can see the list of already configured physical IP addresses and NAT IP
addresses.
2. Click New if the list does not contain any Physical IP Address and NAT IP Address entries.
Listening IP address: Specifies the physical private IP Address for Administration Console.
Public NAT IP address: Specifies the Public NAT IP Address. You can configure or map NAT IP Address.
3. Click Close.

This PDF was generated on July 27, 2025 Page 24 of 2270

 Access Manager 25.2

1.1.1.5.4. Editing a NAT IP address mapping

1. On the Home page, click NAT Settings.
2. Click Public NAT IP Address.
3. Specify the new Public NAT IP Address.
4. Click OK.

This PDF was generated on July 27, 2025 Page 25 of 2270

 Access Manager 25.2

1.1.2. Setting up a basic Identity Server cluster

The initial setup for OpenText Access Manager consists of setting up Identity Server and Access Gateway to protect resources
running on an HTTP web server. You must set up user stores for Identity Server and configure Access Gateway to protect
resources running on an HTTP web server.
Configuring identity user stores
Configuring Identity Servers clusters
Configuring IDP global settings
Access Gateways clusters
Protecting web resources through Access Gateway
Configuring trusted providers for single sign-on
Configuring single sign-on to specific applications
Configuring a protected Identity Server through Access Gateways

This PDF was generated on July 27, 2025 Page 26 of 2270

 Access Manager 25.2

1.1.2.1. Prerequisites for a basic OpenText Access Manager

setup
Administration Console is installed.
Identity Server is installed.
Access Gateway is installed.
An LDAP directory store with a test user added. This store can be eDirectory or Active Directory.
A DNS server or modified host files to resolve DNS names and provide reverse lookups. For information about the host
files that need to be modified, see Configuring name resolution.
A web server (IIS or Apache). The web server must have three directories with three HTML pages. The first directory
( public ) must contain a page (such as index.html) for public access. This page needs to provide two links:
A link to a page in the protected directory. You will configure Access Gateway to require authentication before
allowing access to this page. You do not need to configure the web server to protect this page.
A link to a page in the basic directory. You must already have configured your web server to require basic
authentication before allowing access to this page. See your web server documentation for instructions on setting
up basic authentication. (This type of access is optional, but explained because it is fairly common.)
A client workstation with a browser with browser pop-ups enabled.

This PDF was generated on July 27, 2025 Page 27 of 2270

 Access Manager 25.2

1.1.2.2. Configuring identity user stores

User stores are LDAP directory servers to which end users authenticate. You must specify an initial user store when
configuring Identity Server. The procedure for setting up the initial user store, adding a user store, or modifying an existing
user store is same.
See the following sections for specific configuration tasks:
Using more than one LDAP user store
Configuring the user store
Configuring an administrator user for the user store
Configuring a user store for secrets

This PDF was generated on July 27, 2025 Page 28 of 2270

 Access Manager 25.2

1.1.2.2.1. Using more than one LDAP user store

You can configure Identity Server to search for more than one user store during authentication.

Multiple LDAP directories

It is assumed that each LDAP directory contains different users. Ensure that the users have unique names across all LDAP
directories.
If both directories contain a user with an identical name, the name and password information discovered in the search of the
first directory is always used for authentication. You can specify the search order when configuring the authentication method.
When users are added to the configuration store, objects are created for OpenText Access Manager profiles. If you delete a
user from the LDAP directory, orphaned objects for that user remain in the configuration store.
If you add a secondary Administration Console and you have added replicas to the user store of the primary Administration
Console, ensure to add the replicas to the secondary Administration Console.
All user stores that you add are included in health checks. If health problems occur, the system displays the user store on the
Health page and in the trace log file.

This PDF was generated on July 27, 2025 Page 29 of 2270

 Access Manager 25.2

1.1.2.2.2. Configuring the user store

1. On the Home page, click Identity Servers > [cluster name] > User Stores > Plus icon.
2. Specify the following details:

Field Description

Name The name of the user store.

Administrator Name The distinguished name of the administrator user of the

LDAP directory, or a proxy user with specific LDAP rights
to perform searches. For the LDAP extension to work, the
proxy user requires write rights on the ACL.
Administrator-level rights are required for setting up a
user store. This ensures read/write access to all objects
used by the product. For more information about this
user, see Configuring an administrator user for the user
store.
Each directory type uses a slightly different format for
the DN:
eDirectory: cn=admin,ou=users,o=novell
Active Directory:
cn=Administrator,cn=users,dc=domeh,dc=test,dc=
com
or cn=john
smith,cn=users,dc=domeh,dc=test,dc=com

Administrator Password and Confirm Password Specify the password for the administrator user and
confirm it.

Directory Type You can select eDirectory or Active Directory. If you

have installed an LDAP server plug-in, you can select the
custom type that you have configured it to use. For more
information, see LDAP Server Plug-In.
If eDirectory has been configured to use Domain
Services for Windows, eDirectory behaves like Active
Directory. When you configure such a directory to be a
user store, its Directory Type must be set to Active
Directory for proper operation.

3. Under LDAP Timeout Settings, specify the following details:

This PDF was generated on July 27, 2025 Page 30 of 2270

 Access Manager 25.2

Field Description

LDAP Operation Specify how long a transaction can take before timing
out.

Idle Connection Specify how long before connections begin closing. If a

connection has been idle for the specified duration, the
system creates another connection.

4. Specify a server replica.

1. Under Server Replicas, specify the following details:
For an eDirectory server, you must use a replica of the partition where the users reside. Ensure that each LDAP
server in the cluster has a valid read/write replica. One option is to create a users partition (a partition that points to
the OU containing the user accounts) and reference this server replica.

Field Description

Name The display name for the LDAP directory server. If your
LDAP directory is replicated on multiple servers, use
this name to identify a specific replica.

IP Address/DNS Name The IP address and port of the LDAP directory server.
Specify 389 for the clear text port, and 636 for the
encrypted port.

Use secure LDAP connections Specifies that the LDAP directory server requires
secure (SSL) connections with Identity Server.
In a production environment, it is recommended to use
this option. When you use port 389, usernames and
passwords are sent in clear text on the wire.

Connection Limit The maximum number of pooled simultaneous

connections allowed to the replica. Valid values are
between 5 and 50. The value depends upon the speed
of your LDAP servers. If you modify the default value,
monitor the change in performance. Higher numbers
do not necessarily increase performance.

2. Click Auto import trusted root.

3. Click OK.
4. Select one of the certificates in the list.
To trust one certificate, choose Server Certificate. Choose Root CA Certificate to trust any certificate signed by
that certificate authority.
5. Specify an alias and click OK.
6. Click OK.
7. Click the Validate this Replica icon to test the connection between Identity Server and replica.

This PDF was generated on July 27, 2025 Page 31 of 2270

 Access Manager 25.2

8. (Optional) To add additional replicas for the same user store, click the + icon and repeat Step 4 through Step 3.g.
Adding multiple replicas adds load balancing and failover to the user store. Replicas must be exact copies of each
other.
For load balancing, a hash algorithm is used to map a user to a replica. All requests on behalf of that user are sent to
that replica. Users are moved from their replica to another replica only when their replica is no longer available.
5. Under Search Contexts, add a search context.
The search context is used to locate users in the directory when a contract is executed.
If a user exists outside of the specified search context (object, subtree, one level), Identity Server cannot find the
user, and the user cannot log in.
If the search context is too broad, Identity Server might find more than one match, in which case the contract fails,
and the user cannot log in.
For example, if you allow users to have the same username and these users exist in the specified search context, these
users cannot log in if you are using a simple username and password contract. The search for users matching this
contract would return more than one match. In this case, you need to create a contract that specifies additional attributes
so that the search returns only one match.

Important
For Active Directory, do not set the search context at the root level and set the scope to Subtree. This setting
can cause serious performance problems. It is recommended that you set multiple search contexts, one for
each top-level organizational unit.

6. Click Save.
7. If prompted to restart Tomcat, click OK. Otherwise, update Identity Server.

This PDF was generated on July 27, 2025 Page 32 of 2270

 Access Manager 25.2

1.1.2.2.3. Configuring an administrator user for the user store

Identity Server must log in to each configured user store. It searches for users, and when a user is found, it reads the user’s
attributes values. When you configure a user store, you must supply the distinguished name of the user you want Identity
Server to use for logging in. You can use the administrator user of your user store, or you can create a specialized
administrator user for the this purpose. When creating this administrator user, you need to grant the following rights:
The administrator user needs rights to browse the tree, so Identity Server can find the user who is trying to authenticate.
The administrator user needs browse rights to object class that defines the users and read and compare rights to the
attributes of that class. When looking for the user, Identity Server uses the GUID and naming attributes of the user class.

Directory Object Class GUID Attribute Naming Attribute

eDirectory User guid cn

Active Directory User objectGUID sAMAccountName

Administrators need read rights to any attributes used in policies (Role, Form Fill, Identity Injection).
If a secret store is used in Form Fill policies, the administrator needs write rights to the attributes storing the secrets.
If a password management servlet is enabled, the administrator needs read rights to the attributes controlling grace login
limits and remaining grace logins.
If you use an LDAP extension, the user must have write rights on ACL allowing the user to check for account locks,
password expiration, grace logins used, and so on.
To perform these operations, the user must have additional rights. The product uses NMAS that requires the user to have
write rights on ACL.
If you enable provisioning with the SAML protocols, the administrator needs write rights to create users in the user store.
If you use X.509 authentication, the administrator needs write rights to update the user’s login status attributes.
If you use OAuth and nidsOAuthGrant attribute, the administrator needs to have write access. For more information, see
Defining Global Settings.
If your user store is eDirectory, OpenText Access Manager verifies that the administrator has sufficient rights to browse for
users in the specified search contexts.

Important
This check is not performed for Active Directory. If your users cannot log in, verify that the user store administrator
has appropriate rights to the specified search contexts.

This PDF was generated on July 27, 2025 Page 33 of 2270

 Access Manager 25.2

1.1.2.2.4. Configuring a user store for secrets

OpenText Access Manager allows you to securely store user secrets. Secrets are a way to capture user input, such as login ID
and passwords. These input data can later be reused or injected using Form Fill and Identity Injection policies. This feature is
helpful when your OpenText Access Manager Credential Profile does not contain credentials for an application protected by
OpenText Access Manager yet a single sign-on experience is required. Where and how the secrets can be stored is
configurable and depends upon your user store:
Configuring the configuration datastore to store secrets.
Configuring an LDAP directory to store the secrets.

This PDF was generated on July 27, 2025 Page 34 of 2270

 Access Manager 25.2

1.1.2.2.4.1. Configuring the configuration datastore to store

secrets
If you want to do minimal configuration, use the configuration datastore on Administration Console to store the secrets. You
can use this option without changes, but is recommended only for use in small OpenText Access Manager environments. To
increase the security of the secrets, OpenText recommends that you change the default security options. When you use the
configuration datastore of Administration Console as the secret store, the nidswsfss attribute of the nidsLibertyUserProfile
object is used to store the secrets.

Important
Using this option adds additional load on Administration Console and introduces login delays compared to other
options. Therefore, it is recommended to use this option wisely. This option is used through Web Service Provider
API (https://<admin-console-host>:<admin-console-port>/nps/swagger-ui.html).

This PDF was generated on July 27, 2025 Page 35 of 2270

 Access Manager 25.2

1.1.2.2.4.2. Configuring an LDAP directory to store the secrets

This is the recommended option. You can use it with any LDAP directory. To use this option, extend the schema to add an
attribute to your user object on the LDAP directory that will encrypt and store the secrets.
When you use an LDAP directory to store the secrets, you need to enable the user store for the secrets. You select the LDAP
directory, then specify an attribute. The attribute you specify is used to store an XML document that contains encrypted secret
values. This attribute must be a single-valued case ignore string that you have defined and assigned to the user object in the
schema.
To use an LDAP directory to store secrets, your network environment must conform to the following requirements:
The user class object must contain an attribute that can be used to store the secrets. This attribute must be a string
attribute that is single valued and case ignore.
The user store must be configured to use secure connections. On the Home page, click Identity Servers > [cluster name]
> User Stores > [User Store Name]. Under Server Replicas, ensure that Port is 636 and that Use Secure LDAP
Connections is enabled.
To configure the LDAP directory use the Web Service Provider API (https://<admin-console-host>:<admin-console-
port>/nps/swagger-ui.html):
1. On the Home page, click Identity Servers > Update.
2. To create policies that use the stored secrets, see Creating and managing shared secrets.

This PDF was generated on July 27, 2025 Page 36 of 2270

 Access Manager 25.2

1.1.2.3. Configuring Identity Servers clusters

After you install Identity Server, you must create a cluster configuration to configure it. When you create a cluster, ensure that
the servers are installed on the same operating system.
Even if you have only one Identity Server, you must assign it to a cluster configuration to configure it. If you have multiple
Identity Servers, you can create multiple configurations and assign different Identity Servers to them as shown in Identity
Server configurations.

Identity Server configurations

A cluster of Identity Servers must reside behind a Layer 4 (L4) switch. Clients access the virtual IP address of the cluster
presented on the L4 switch, and the L4 switch alleviates server load by balancing traffic across the cluster.
Whenever a user accesses the virtual IP address (port 8080) assigned to the L4 switch, the system routes the user to one of
Identity Servers in the cluster, as traffic necessitates.
The system automatically enables clustering when multiple Identity Servers exist in a group. If only one Identity Server exists in
a group, clustering is disabled.
You must not use a DNS round robin setup instead of an L4 switch for load balancing. The DNS solution works only as long as
all members of the cluster are working and in a good state. If one of them goes down and traffic is still sent to that member, the
entire cluster is compromised and all devices using the cluster start generating errors.
This section describes how to set up and manage a cluster of Identity Servers:
Configuration notes
Prerequisites for configuring an Identity Servers cluster
Managing a cluster of Identity Servers

This PDF was generated on July 27, 2025 Page 37 of 2270

 Access Manager 25.2

1.1.2.3.1. Configuration notes

Services of the real server
A note about service configuration
A note about Radware Alteon switches

This PDF was generated on July 27, 2025 Page 38 of 2270

 Access Manager 25.2

1.1.2.3.1.1. Services of the real server

A user’s authentication remains on the real (authentication) server cluster member that originally handled the user’s
authentication. If this server malfunctions, all users whose authentication data resides on this cluster member must re-
authenticate unless you have enabled session failover. For more information about this feature, see Configuring session
failover.
Requests that require user authentication information are processed on this server. When the system identifies a server as not
being the real server, the HTTP request is forwarded to the appropriate cluster member, which processes the request and
returns it to the requesting server.

This PDF was generated on July 27, 2025 Page 39 of 2270

 Access Manager 25.2

1.1.2.3.1.2. A note about service configuration

If your L4 switch can perform both SSL and non-SSL health checks, you must configure the L4 switch only for the services
that you are using in your OpenText Access Manager configuration. For example, if you configure the SSL service and the non-
SSL service on the L4 and the base URL of your Identity Server configuration is using HTTP rather than HTTPS, the health
check for the SSL service fails. The L4 switch then assumes that all Identity Servers in the cluster are down. Therefore, ensure
that you enable only the services that are also enabled on Identity Server.

This PDF was generated on July 27, 2025 Page 40 of 2270

 Access Manager 25.2

1.1.2.3.1.3. A note about Radware Alteon switches

While configuring a Radware Alteon (formerly Alteon) switch for clustering, you must enable direct communication between
real servers. If not enabled, the connection fails and times out when one of the real servers tries to proxy another real server.
To enable direct communication on the Radware Alteon:
1. Go to cfg > slb > adv > direct.
2. Specify e to enable direct access mode.
With some L4 switches, you must configure only the services that you are using. For example, if you configure the SSL service
for the L4 switch and you have not configured SSL in OpenText Access Manager, then the HTTP service on the L4 switch does
not work. If the health check for the SSL service fails, the L4 switch assumes that all the services configured to use the same
virtual IP are down.

This PDF was generated on July 27, 2025 Page 41 of 2270

 Access Manager 25.2

1.1.2.3.2. Prerequisites for configuring an Identity Servers

cluster
An L4 server is installed. You can use the same server for Identity Server clustering and Access Gateway clustering,
provided that you use different virtual IPs. The LB algorithm can be anything (hash/sticky bit), defined at the Real server
level.
Persistence (sticky) sessions enabled on the L4 server. Define this at the virtual server level.
An Identity Server configuration created for the cluster. You assign all Identity Servers to this configuration. See
Configuring Identity Servers clusters and CreatingEditing a cluster configuration.
The base URL DNS name of this configuration must resolve via DNS to the IP address of the L4 virtual IP address. The L4
balances the load between Identity Servers in the cluster.
Ensure that the L4 administration server using port 8080 has the following ports open:
8443 (secure Administration Console)
7801 (TCP)
636 (for secure LDAP)
389 (for clear LDAP, loopback address)
524 (network control protocol on the L4 machine for server communication)
The identity provider ports must also be open:
8080 (non-secure login)
8443 (secure login)
1443 (server communication)

This PDF was generated on July 27, 2025 Page 42 of 2270

 Access Manager 25.2

1.1.2.3.3. Managing a cluster of Identity Servers

When you assign multiple Identity Servers to the same configuration, you need to install a load balancer that supports Layer 4
or Layer 7. This device is referred to as an L4 switch here. The L4 switch allows the work load to be balanced among the
machines.
In this Section
CreatingEditing a cluster configuration
Assigning an Identity Server to a cluster configuration
Configuring a cluster with multiple Identity Servers
Configuring session failover
Editing cluster details
Removing an Identity Server from a cluster configuration
Enabling and disabling protocols
Modifying the base URL
Identity Server authentication APIs
Configuring Identity Server global properties

This PDF was generated on July 27, 2025 Page 43 of 2270

 Access Manager 25.2

1.1.2.3.3.1. Creating a cluster configuration

Identity Server functions as an identity provider. You can configure it to run as an identity consumer (also known as a service
provider) by using federation protocols.
An Identity Server configuration consists of the following information:
The DNS name of Identity Server or clustered server site.
Certificates for Identity Server.
Organizational and contact information of the server that is published in the metadata of SAML protocols.
LDAP directories (user stores) to authenticate users, and trusted root for secure communication between Identity Server
and a user store.
To create an Identity Server cluster, perform the following steps:
1. On the Home page, click Identity Servers > Plus icon (New Cluster).
2. Specify the basic configuration details:

This PDF was generated on July 27, 2025 Page 44 of 2270

 Access Manager 25.2

Field Description

Name Specify a name for the cluster.

Determine your settings for the base URL, protocol, and
domain. After you configure trust relationships between
providers, changing these settings invalidates the trust
model and requires a reimport of the provider’s metadata.
Modifying the base URL also invalidates the trust
between Embedded Service Provider (ESP) of OpenText
Access Manager devices. To re-establish the trust after
modifying the base URL, you must restart ESP on each
device.

Base URL Specify the application path for Identity Server. Identity
Server protocols rely on this base URL to generate URL
endpoints for each protocol.
Protocol: Select the communication protocol.
Specify HTTPS to run securely (in the SSL mode)
and for provisioning. Use HTTP only if you do not
require security or have installed an SSL terminator
in front of Identity Server.
Domain: Specify the DNS name assigned to Identity
Server. When you are using an L4 switch, this DNS
name must resolve to the virtual IP address set up
on the L4 switch for Identity Servers. Using an IP
address is not recommended.
Port: Default ports are 8080 for HTTP or 8443 for
HTTPS. If you want to use port 80 or 443, specify
the port here.
Configure the operating system to translate the
port. See Translating Identity Server configuration
Port.
Application: Specify the Identity Server application.
The default value is nidp.

SSL Certificate Displays the assigned SSL certificate.

Identity Server comes with a test-connector certificate
that you must replace to use SSL in your production
environment. You can replace the test certificate now or
after you configure Identity Server. You must restart
Tomcat whenever you assign an Identity Server to a
configuration and whenever you update a certificate key
store.

Specify Session Limits:

LDAP Access Specify the maximum number of LDAP connections

Identity Server can create to access the configuration
store. You can adjust this value for system performance.

This PDF was generated on July 27, 2025 Page 45 of 2270

 Access Manager 25.2

Default Timeout Specify the session timeout that you want to be used as
a default value when you create a contract. This value is
also assigned to a session when Identity Server cannot
associate a contract with the authenticated session.
During federation, if the authentication request uses a
type rather than a contract, Identity Server cannot always
associate a contract with the request.

Limit User Sessions Specify whether user sessions are limited. If enabled,
you can specify the maximum number of concurrent
sessions a user is allowed to authenticate.
To limit user sessions, consider the session timeout value
(the default is 60 minutes). If the user closes the browser
without logging out (or an error causes the browser to
close), the session is not cleared until the session
timeout expires. If the user session limit is reached and
those sessions have not been cleared with a logout, the
user cannot log in again until the session timeout expires
for one of the sessions.

Note
When you enable this option, it affects
performance in a cluster containing multiple
Identity Servers. When a user is limited to a
specific number of sessions, Identity Servers
must check with the other servers before
establishing a new session.

You can configure Identity Server to delete the previous

user sessions if the number of open sessions reaches
the maximum limit of allowed sessions that you have
specified in Limit User Sessions. To do this, set the
DELETE OLD SESSIONS OF USER option to true. For
information about configuring this option, see
Configuring Identity Server global properties.
Previous sessions are cleared across Identity Servers
only when a fresh authentication request comes in. When
Identity Server deletes previous user sessions, it sends a
logout request to the service provider through the SOAP
backchannel.
For example, a user is accessing a protected resource
from a machine and wants to access the same protected
resource from another device. Identity Server will not
give access to the user if the Limit User Sessions has
reached a maximum limit. Identity Server must terminate
the old session of the user so that the user can access
the new session seamlessly.

This PDF was generated on July 27, 2025 Page 46 of 2270

 Access Manager 25.2

Allow Multiple Browser Session Logout Specify whether a user with more than one session to the
server can log out of all sessions. If you do not enable
this option, only the current session can be logged out.
Disable this option in instances where multiple users log
in as guests. Then, when one user logs out, none of the
other guests are logged out.
When you enable this option, restart all ESP that use this
Identity Server configuration.

Specify TCP Timeouts details:

LDAP Request Specify the duration that an LDAP request to the user
store can take before timing out.

Proxy Request Specify the duration that a request to another cluster

member can take before timing out. When a member of a
cluster receives a request from a user who has
authenticated with another cluster member, the member
sends a request to the authenticating member for
information about the user.

HTTP Request Specify the duration that an HTTP request to an

application can take before timing out.

Select Enabled Protocols:

Liberty Uses a structured version of SAML to exchange

authentication and data between trusted identity
providers and service providers and provides the
framework for user federation.

Note
Liberty is enabled by default.

SAML 2.0 Uses XML for exchanging encrypted authentication and

data between trusted identity providers and service
providers and provides the framework for user
federation.

WS Federation Allows disparate security mechanisms to exchange

information about identities, attributes, and
authentication.

WS-Trust Allows secure communication and integration between

services by using security tokens.

This PDF was generated on July 27, 2025 Page 47 of 2270

 Access Manager 25.2

OAuth & OpenID Connect Allows Identity Server to act as an authorization server to
issue access token to a client application based on user’s
grant.

3. Click Next.
4. Specify the organization details.
This information is published in the metadata for SAML. The metadata is traded with federation partners and supplies
various information regarding contact and organization information located at Identity Server.

Field Description

Name The name of the organization.

Display Name The display name for the organization.

URL The URL of the organization.

Company, First Name, Last Name, Email Address, Telephone Number, and Contact Type are optional fields.
5. Click Next.
6. Specify the user store details.
For information, see Configuring identity user stores.
The status icons for the configuration and Identity Server must turn green. It might take several seconds for Identity
Server to start and for the system to display a green icon. If not, it is likely that Identity Server is not communicating with
the user store you set up. Ensure that you have entered the user store information correctly and imported the SSL
certificate to the user store.
7. Click Next.
8. Select servers from the list that you want to assign to the cluster.
9. Click Finish.

This PDF was generated on July 27, 2025 Page 48 of 2270

 Access Manager 25.2

1.1.2.3.3.2. Assigning an Identity Server to a cluster

configuration
After you create a cluster, you can assign an Identity Server to it. You can assign more than one Identity Server to the cluster
configuration. A configuration uses any IDP Global settings you have specified, such as attribute sets, user matching
expressions, and custom attributes that are defined for the server.
1. On the Home page, click Identity Servers.
2. Click Unassigned Servers.
3. Select the server(s) that you want to assign to a cluster and click Assign to a cluster.
4. Select the cluster.
5. Click OK.
6. Restart Tomcat on each Identity Server in the configuration:
Specify one of the following commands:
/etc/init.d/novell-idp restart
systemctl restart -idp
For the Docker deployment, perform the following steps:
1. Run the kubectl get pods command to view the OpenText Access Manager pods.
2. Go to the Identity Server pod by running the kubectl exec --namespace <name-of-the-namespace> -it pod/<name-
of-the-identity-server-pod> -- sh command.
3. Run the /etc/init.d/novell-idp restart or systemctl restart -idp command.
The status icon for Identity Server must turn green. It might take several seconds for Identity Server to start and for the
system to display the green icon.

This PDF was generated on July 27, 2025 Page 49 of 2270

 Access Manager 25.2

1.1.2.3.3.3. Configuring a cluster with multiple Identity Servers

To enable system failover, you can cluster a group of Identity Servers and configure them to act as a single server. When
session failover is enabled, users do not need to reauthenticate when an Identity Server goes down.
A cluster of Identity Servers must reside behind an L4 switch. Clients access the virtual IP (VIP) address of the cluster
presented on the L4 switch, and the L4 switch alleviates server load by balancing traffic across the cluster. Whenever a user
accesses VIP address assigned to the L4 switch, the system routes the user to one of Identity Servers in the cluster, as traffic
necessitates.
To set up a cluster, complete the following tasks:
Install an L4 switch. You can use the same switch for Identity Server cluster and Access Gateway cluster if you use
different VIPs. The LB algorithm can be anything (hash/sticky bit), defined at the Real server level.
Enable persistence (sticky) sessions on the L4 switch. You can define this at the virtual server level.
Create an Identity Server configuration for the cluster and assign all Identity Servers to this configuration.
Ensure that DNS of the base URL of the cluster configuration resolves via DNS to the IP address of the L4 virtual IP
address. The L4 switch balances the load among Identity Servers in a cluster.
Ensure that the L4 administration server using port 8080 has the following TCP ports open:
8443 (secure Administration Console)
7801 (for back-channel communication with cluster members).
636 (for secure LDAP)
389 (for clear LDAP)
524 (network control protocol on the L4 switch for server communication)
The identity provider ports must also be open:
8080 (non-secure login)
8443 (secure login)
1443 (server communication)
If you are using introductions , you must configure the L4 switch to load balance on ports 8445 (identity provider) and
8446 (identity consumer).
Enable session failover so users do not need to re-authenticate when an Identity Server goes down. See Configuring
session failover.
Modify the name of the cluster or edit communication details. See Editing cluster details.

This PDF was generated on July 27, 2025 Page 50 of 2270

 Access Manager 25.2

1.1.2.3.3.4. Configuring session failover

When you configure an Identity Server cluster and add more than one Identity Server to the cluster, you set up fault tolerance.
This ensures that if one of Identity Servers goes down, users still have access to your site because the other Identity Server
can be used for authentication. However, it does not provide session failover. If a user has authenticated to the failed Identity
Server, the user is prompted to authenticate and the session information is lost.
When you enable session failover and an Identity Server goes down, the user’s session information is preserved. Another peer
server in the cluster re-creates the authoritative session information in the background. The user is not required to log in again
and experiences no interruption of services.
Prerequisites for configuring session failover
An Identity Server cluster with two or more Identity Servers.
Sufficient memory on Identity Servers to store additional authentication information. When an Identity Server is selected
to be a failover peer, it stores about 1 KB of session information for each user authenticated on the other machine.
Sufficient network bandwidth for the increased login traffic. Identity Server sends the session information to all Identity
Servers that have been selected to be its failover peers.
All trusted Embedded Service Providers are configured to send the attributes used in Form Fill and Identity Injection
policies at authentication. If you use any attributes other than the standard credential attributes in your contracts, send
these attributes also. To send attributes, use the Web Service Provider API (https://<admin-console-host>:<admin-
console-port>/nps/swagger-ui.html).
Configuring session failover
1. On the Home page, click Identity Servers > [cluster name] > Cluster Actions > Cluster Details.
2. In Failover Peer Servers, select the number of failover peers for each Identity Server.
To disable this feature, select 0.
To enable this feature, select one or two less than the number of servers in your cluster. For example, if you have
four servers in your cluster and you want to allow for one server being down for maintenance, select 3 (4-1=3). If
you want to allow for the possibility of two servers being down, select 2 (4-2=2).
If you have eight or more servers in your cluster, the formula 8-2=6 gives each server 6 peers. In a larger cluster,
you must limit the number of peers to 2 or 3. If you select too many peers, your machines require more memory to
hold the session data and slow down your network with the additional traffic for the session information.
3. Click Done.
How failover peers are selected
The failover peers for Identity Server are selected according to their proximity. OpenText Access Manager sorts the members
of the cluster by their IP addresses and ranks them according to how close their IP addresses are to the server who needs to
be assigned as failover peers. It selects the closest peers for the assignment. For example, if a cluster member exists on the
same subnet, that member is selected to be a failover peer before a peer that exists on a different subnet.

This PDF was generated on July 27, 2025 Page 51 of 2270

 Access Manager 25.2

1.1.2.3.3.5. Editing cluster details

1. On the Home page, click Identity Servers > [cluster name] > Cluster Actions > Cluster Details.
The Cluster Details page contains the following tabs:
General: To modify the cluster name or its settings, continue with Step 2.
Health: Click to view the health of the cluster.
Alerts: Click to view the alerts generated by members of the cluster.
2. Modify the following details as required:

Field Description

Back Channel Communication Specify a communications channel over which the

cluster members maintain the integrity of the cluster. For
example, this TCP channel is used to detect members
when they join or leave the cluster. A small percentage of
this TCP traffic is used to help cluster members
determine which cluster member can handle a request
more efficiently. This backchannel must not be confused
with IP address/port over which cluster members provide
proxy requests to peer cluster members.
Port: Specify the TCP port of the backchannel on all
Identity Servers in the cluster. 7801 is the default
TCP port.
Encrypt: Encrypts the content of the messages sent
between cluster members.

Level 4 Switch Port Translation Configure the L4 switch to translate the port of the
incoming request to a new port when the request is sent
to a cluster member. Because the cluster members
communicate with each other over the same IP
address/port as the L4 switch, the cluster implementation
needs to know what that port is. The translated port is
the port on the cluster members where other cluster
members can contact it. This is the IP address and port
where cluster members provide proxy requests to other
cluster members.
Enable cluster server translation: Select to specify
whether the port of the L4 switch is different from
the port of the cluster member. For example, enable
this option when the L4 switch is using port 443
and Identity Server is using port 8443.
Port: Specify the port of the cluster member.

Failover Peer Server For information, see Configuring session failover.

3. Click Done.
4. Update Identity Server when prompted.

This PDF was generated on July 27, 2025 Page 52 of 2270

 Access Manager 25.2

1.1.2.3.3.6. Removing an Identity Server from a cluster

configuration
Removing an Identity Server from a configuration disassociates it from the cluster. The configuration, however, remains intact
and it can be reassigned or assigned to another server.
1. On the Home page, click Identity Servers.
2. Click Server actions > Stop the Server. Wait for Health to turn red.
3. Click Cluster actions > Remove from the Cluster.

Important
When a cluster contains only two Identity Servers, introduce a new Identity Server to the cluster before removing
the other Identity Server.

This PDF was generated on July 27, 2025 Page 53 of 2270

 Access Manager 25.2

1.1.2.3.3.7. Enabling and disabling protocols

You must enable a protocol and configure it before users can use the protocol for authentication. For security purposes, you
must enable only the required protocols that you will use for authentication.
1. On the Home page, click Identity Servers > [cluster name].
2. In the Enabled Protocols section, select the required protocols to enable.
3. To disable a protocol, turn it off.
4. Click Save.
5. (Conditional) If you have enabled a protocol, update Identity Server.
6. (Conditional) If you have disabled a protocol, stop and start Identity Servers in the cluster.
1. Click the dot menu of the server and click Stop the Server.
2. When the health turns red, click the dot menu of the server, and click Start the Server.
3. Repeat the process for each Identity Server in the cluster.

This PDF was generated on July 27, 2025 Page 54 of 2270

 Access Manager 25.2

1.1.2.3.3.8. Modifying the base URL

When you configure an Identity Server, you must carefully determine your settings for the base URL, protocol, and domain.
Changing the base URL invalidates the trust model and requires a re-import of the provider’s metadata, and a restart of the
affected Embedded Service Providers (ESP). It also changes the ID of the provider and the URLs that others use for access.
When you change the base URL of Identity Server, you invalidate the following trusted relationships:
The trusted relationships that Identity Server has established with each OpenText Access Manager device that has been
configured to use Identity Server for authentication
The trusted relationship that each OpenText Access Manager device has established with Identity Server when Identity
Server configuration was selected.
The trusted relationships that Identity Server has established with other service providers.
The sessions of any logged-in users are destroyed and no user can log in and access protected resources until the trust
relationships are reestablished.
Perform the following steps to modify the base URL and reestablish trust relationships:
1. On the Home page, click Identity Servers > [cluster name].
2. Change the protocol, domain, port, and application settings as necessary.
3. Click OK.
4. Click the Update All icon associated with the cluster.
This re-creates the trusted Identity Server configuration to use the new base URL and metadata.
5. Restart Tomcat on each Identity Server in the configuration:
Specify one of the following commands:
/etc/init.d/novell-idp restart
systemctl restart -idp
For the Docker deployment, perform the following steps:
1. Run the kubectl get pods command to view the OpenText Access Manager pods.
2. Go to the Identity Server pod by running the kubectl exec --namespace <name-of-the-namespace> -it pod/<name-
of-the-identity-server-pod> -- sh command.
3. Run the /etc/init.d/novell-idp restart or systemctl restart -idp command.
6. For each OpenText Access Manager device configured to trust the configuration of this modified base URL, update the
device so that the ESP trusts the new Identity Server configuration:
Click Access Gateways, then click Update for any servers with a Status of Update.
7. For each service provider you have configured to trust the configuration of this modified base URL, you must send them
the new metadata and have them re-import it.
For information about setting up SSL and changing an Identity Server from HTTP to HTTPS, see Enabling SSL communication.

This PDF was generated on July 27, 2025 Page 55 of 2270

 Access Manager 25.2

1.1.2.3.3.9. Identity Server authentication APIs

The Identity Server authentication APIs are login APIs for user authentications. Using these APIs, you can build your own end-
to-end login experience replacing the built-in user portal login experience.
The following are the available authentication APIs:

API Description

End-user authentication API End-users can authenticate using this endpoint.

Get authentication status Use this API to check the authentication status when a user
has performed multi-factor authentication (smartphone,
voice call).

Exchange session token for session cookie Use this API to create the JSESSIONID cookie for the
session and redirect the browser to the target URL.

Log out the user from Identity Server Use this API to log out a user from Identity Server.

Fetch all the configured contracts Use this API to retrieve all contracts configured in OpenText
Access Manager.

The authentication request and response are in the JSON format. OpenText Access Manager also provides an option to
configure user attributes that you want in the response sent by the authentication API. If you do not configure any attributes,
the response contains given_name , family_name , and email by default. For information about how to configure attributes
for the authentication API response, see Configuring user attributes.
For more information about these APIs, see Identity Server Authentication API.
Authentication API key scenarios
You can use the Authentication APIs in the following scenarios:
End-to-End Login Experience:You can build your own end-to-end user login experience instead of the standard login
experience provided by OpenText Access Manager.
Login Page Customization: You can use these APIs for high-level customization of the login page and user portal.
Mobile Application Authentication: You can use these APIs to authenticate users with OpenText Access Manager
through mobile applications.
Supported authentication methods
Primary Authentication: You can use these APIs to verify the credentials of end-users using one of the following
methods:
Name/Password - Basic (com.novell.nidp.authentication.local.PasswordClass)
Name/Password - Form (com.novell.nidp.authentication.local.BasicClass)
Secure Name/Password - Basic (com.novell.nidp.authentication.local.ProtectedBasicClass)
Secure Name/Password - Form (com.novell.nidp.authentication.local.ProtectedPasswordClass)
Multi-Factor Authentication:When OpenText Access Manager is integrated with Advanced Authentication through the
plug-in approach (using Smartphone class or Voice Call class), the APIs support multi-factor authentication for the
following methods:
Smartphone (com.authasas.aucore.nam.method.smartphone.SmartphoneClass)

This PDF was generated on July 27, 2025 Page 56 of 2270

 Access Manager 25.2

Voice Call (com.authasas.aucore.nam.method.voicecall.VoiceCallClass)

Configuring user attributes
After successful user authentication using authentication APIs, the response contains the user-specific attributes that are
configured on the Authentication API page.
If you do not configure any attributes, the response contains given_name , family_name , and email attributes by default.
Perform the following steps to configure user attributes:
1. On the Home page, click Identity Servers > [cluster name] > Authentication API.
2. In Attribute Set, select the required attribute set.
For information about attribute set, see Configuring attribute sets.
3. Select the required attributes.
4. Click Save.
Security considerations for authentication APIs
Configure rate limits for authentication requests: In the Identity Server tomcat.conf file, restrict the number of requests per
second by setting the appropriate value for the number of requests in the com.novell.authn.threshold.maxrequestsallowed
parameter. The default value is 500. That means 500 requests per second are allowed for these APIs.
For information about how to modify a file, see Modifying Configurations.

This PDF was generated on July 27, 2025 Page 57 of 2270

 Access Manager 25.2

1.1.2.3.3.10. Configuring Identity Server global properties

These properties are applicable for all Identity Servers in a cluster.
Perform the following steps to configure Identity Server global properties:
1. On the Home page, click Identity Servers > [cluster name] > Configuration > Properties.
2. Click the Plus icon and set the following properties based on your requirement:

This PDF was generated on July 27, 2025 Page 58 of 2270

 Access Manager 25.2

Property Value

ALLOW AUTH POLICY EXECUTION Select false to disable Identity Server to execute
authorization policies. The default value is true.
For example, see Executing an authorization-based role
policy during SAML 2.0 service provider initiated request.

ALLOW GRACE LOGIN FOR EXPIRING PASSWORD When the value is set to true, users get grace logins
when their password is about to expire. By default, the
property is set to true on all Identity Servers.
Select false if you do not want users to get a grace login
for an expiring password.
In case of Active Directory, this option works when the
pwdlastset attribute has a zero value (pwdlastset=0) in
the user store. This means users must change their
password at the next login.
If you set this option to false, the user will not be
redirected to Password Management Servlet (if
configured).

CHECK ACTIVE CLUSTER MEMBERS FOR PROXY Select true to enable verifying whether the incoming
cluster cookie for Identity Server refers to an active node
of the cluster. By default, this option is set to false.

CLUSTER COOKIE DOMAIN Set this property to change the domain attribute of
Identity Server cluster cookie.
For example, see Configuring X.509 authentication to
display the Access Manager error message.

CLUSTER COOKIE PATH Set this property to change the Path attribute for Identity
Server cluster cookie. The default value is /nidp.
For example, see Configuring X.509 authentication to
display the Access Manager error message.

CRL REFRESH INTERVAL DAYS OpenText Access Manager caches the Certificate
Revocation Lists (CRL) used in X.509 Authentication.
Specify the duration in days after that you want the CRL
to be refreshed in the CRL cache.

DECODE RELAY STATE PARAM Select true to enable the relay state URL decoding. The
default value is false.

DELETE OLD SESSIONS OF USER Select true to enable Identity Server to delete the
previous user sessions if the number of open sessions
reaches the maximum limit of allowed sessions that you
have specified in Limit User Sessions. The default value
is false.

This PDF was generated on July 27, 2025 Page 59 of 2270

 Access Manager 25.2

HTTP ONLY CLUSTER COOKIE Select false to disable the HTTPOnly flags for Identity
Server cluster cookies. The default value is true.
For example, see Enabling secure or HTTPOnly flags for
cluster cookies.

HTTP POPULATE LOGINNAME FROM SAML AUTH Select true to auto-populate the email ID on the Identity
REQUEST Server login page for a SAML 2.0 authentication. The
default value is false.
For more information, see Auto-Populating the username
on the Identity Server login page.

HTTP POPULATE PARSED LOGINNAME FROM SAML Select true to auto-populate the username instead of the
AUTH REQUEST entire email ID on the Identity Server login page for a
SAML 2.0 authentication. For example, to populate
steve.smith instead of [email protected] . The
default value is false.
For more information, see Auto-Populating the username
on the Identity Server login page.

HTTP POPULATE LOGINNAME FROM WSFED AUTH Select true to auto-populate the email ID on the Identity
REQUEST Server login page for a WS-Fed authentication request.
The default value is false.

HTTP POPULATE PARSED LOGINNAME FROM WSFED Select true to auto-populate the username instead of the
AUTH REQUEST entire email ID on the Identity Server login page for a
WS-Fed authentication.
For example, to populate steve.smith instead of
[email protected] . The default value is false.

IS SAML2 POST INFLATE Select true to enable Identity Server to receive deflated
SAML 2.0 POST messages from its trusted providers.
The default value is false.
You can configure post binding to be sent as a
compressed option by configuring this property. For
example, see the note in Step 4.

IS SAML2 POST SIGN RESPONSE Select true to enable the identity provider to sign the
entire SAML 2.0 response for all service providers.

SAML2 ISSUER FORMAT Select true to add the Format attribute in saml:Issuer
element. Add /opt/novell/nids/lib/webapp/WEB-
INF/classes/nidpconfig.properties file on each Identity
Server in the cluster.

This PDF was generated on July 27, 2025 Page 60 of 2270

 Access Manager 25.2

SAML2 ISSUER NAME QUALIFIER Select true to add the Name Qualifier attribute in
saml:Issuer element.Add
/opt/novell/nids/lib/webapp/WEB-
INF/classes/nidpconfig.properties file on each Identity
Server in the cluster.

LOGIN CSRF CHECK Select true to enable Cross-Site Request Forgery (CSRF)
check for the Password Class and TOTP Class. This is
applicable for OpenText Access Manager default pages.
If you have modified any page, you must add the CSRF
token to the page. To add the CSRF token, add the
following:
JAVA:

<%
String sid =
request.getParameter("sid")!=null ?
request.getParameter(NIDPConstants.SID) :
(String)request.getAttribute(NIDPConstants
.SID);
NIDPSessionData sData =
NIDPContext.getNIDPContext().getSession(re
quest).getSessionData(sid);
boolean csrfCheckRequired =
NIDPEdirConfigUtil.isConfigured(NIDPConfig
Keys.LOGIN_CSRF_CHECK.name()) ?
NIDPEdirConfigUtil.getValueAsBoolean(NIDPC
onfigKeys.LOGIN_CSRF_CHECK.name()) :
false;
%>

HTML:

<% if (csrfCheckRequired) { %>

<input type="hidden"
name="AntiCSRFToken" value="
<%=sData.getAntiCSRFToken()%>">
<% } %>

OAUTH TOKENS IN BINARY FORMAT Select true to send tokens in the binary format.
By default, the value is set to false and tokens are sent in
the JWT format.
It is recommended to not use this property unless you
have an existing client application that cannot manage a
token larger than the existing binary token.

Note
: When set to true, few features, such as
token encryption using resource server keys
and token revocation, will not be available.

RENAME SESSION ID Select false to prevent changing the session ID

automatically. The default value is true.

This PDF was generated on July 27, 2025 Page 61 of 2270

 Access Manager 25.2

SAML2 ATTRIBUTE CONSUMING INDEX This option can be used to identify globally the value of
AttributeConsumingServiceIndex of SAML 2
authentication requests. If SAML2 ATTRIBUTE
CONSUMING INDEX is not configured in SAML 2.0
options, OpenText Access Manager considers the
SAML2 ATTRIBUTE CONSUMING INDEX configuration in
Identity Server global options. If you require to assign the
property values for multiple entries, you can use comma
(,) as separator.
Provide the value in the format specified in the following
example:
For protected resource URL:
https://www.example.com:446/test/Test/test.php->2
In this example, the “2” is assigned to
AttributeConsumingServiceIndex of SAML 2
authentication request coming from the protected
resource.
For default value: default->10
If the SAML 2 authentication request comes from the
protected resource that is not configured, the default
value 10 is assigned to
AttributeConsumingServiceIndex .
For multiple protected resource URLs:
https://www.example.com:446/test/Test/test.php-
>2,https://www.example.com:446/test/Test/view.php->3

SECURE CLUSTER COOKIE Select false to disable the secure flags for cluster
cookies. The default value is true.
For example, see Enabling secure or HTTPOnly flags for
cluster cookies.

STS CHANGE ISSUER Specify the value in this format: SPentityID:UPNDomain

-> new IssuerID. For example,
urn:federation:MicrosoftOnline:support.namnetiq.in ->
https://namnetiq.in/nidp/wsfed/
In case of multiple children domains, add each parent
domain and child domain separated by a comma. For
example, if namnetiq.in is the parent domain and
support.namnetiq.in and engineering.namnetiq.in are
children domains, specify the following entries:

urn:federation:MicrosoftOnline:namnetiq.in
-> https://namnetiq.in/nidp/wsfed/,
urn:federation:MicrosoftOnline:support.nam
netiq.in ->
https://namnetiq.in/nidp/wsfed/,
urn:federation:MicrosoftOnline:engineering
.namnetiq.in ->
https://namnetiq.com/nidp/wsfed/

For example, see Configuring federation for multiple

domains.

This PDF was generated on July 27, 2025 Page 62 of 2270

 Access Manager 25.2

STS OFFICE365 MULTI DOMAIN SUPPORT AUTO Select true to enable users to access Microsoft 365
services by using the Issuer URI specific to the domain
they belong to. The default value is false.
For example, see Creating multiple domains in Microsoft
365 and establishing federation with Access Manager.

USE DEVICE ID IN 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, enable this property to use hashing
for the cookie value.
false: The default setting.
true: Enables this property for both Identity Server
and ESP.
IDP: Enables this property for Identity Server.
To set up this property only for ESP, see
“USE_DEVICE_ID_IN_URN_COOKIE” in Configuring ESP
global options.

Select full to enable users to access the Services

WSF SERVICES LIST
page.
Select 404 to return an HTTP 404 status code: Not
Found.
Select 403 to return an HTTP 403 status code:
Forbidden.
Select empty to return an empty services list.
The default value is full.

WSFED ASSERTION VALIDITY Specify the assertion validity time in second for WS
Federation Provider (SP) to accommodate clock skew
between the service provider and SAML identity provider.
The default value is 1800 seconds.
For example, see Assertion validity window.

Note
You can set the WSFED assertion validity
time for each WS-Federation Service
Provider where the default is 300.

This PDF was generated on July 27, 2025 Page 63 of 2270

 Access Manager 25.2

WSTRUST AUTHORIZATION ALLOWED ACTAS VALUES Specify the user names who can perform ActAs
operations. Allowed user names are the user accounts
that the intermediate web service provider uses to
authenticate with STS when sending a request with
ActAs elements.
You can specify more than one user name separated by
a comma.
For example, see Adding policy for actas and onbehalfof.

WSTRUST AUTHORIZATION ALLOWED ONBEHALF Specify the user names who can perform OnBehalfOf
VALUES operations. Allowed user names are the user accounts
that the intermediate web service provider uses to
authenticate with STS when sending a request with
OnBehalfOf elements.
You can specify more than one user name separated by
a comma.
For example, see Adding policy for actas and onbehalfof.

WSTRUST AUTHORIZATION ALLOWED VALUES Specify the user names who can perform both ActAs and
OnBehalfOf operations. You can specify more than one
user name separated by a comma.
For example, see Adding policy for actas and onbehalfof.

SESSION ASSURANCE USER AGENT EXCLUDE LIST Specify the user-agent string for that you want to disable
the session validation.
For example, see Disabling session assurance for Identity
Server.

SESSION ASSURANCE USER AGENT REGEX EXCLUDE Specify the user-agent REGEX for that you want to
LIST disable the session validation.
For example, see Disabling session assurance for Identity
Server.

SESSION ASSURANCE URL EXCLUDE LIST Specify the URL for that you want to disable the session
validation.
For example, see Disabling session assurance for Identity
Server.

SESSION ASSURANCE URL REGEX EXCLUDE LIST Specify the URL REGEX for that you want to disable the
session validation.
For example, see Disabling session assurance for Identity
Server.

SESSION ASSURANCE IDC COOKIE GRACEPERIOD Specify the time in second till which Identity Server will
accept the old IDC cookie after issuing a new cookie. The
default value is 15 second.

This PDF was generated on July 27, 2025 Page 64 of 2270

 Access Manager 25.2

OTHER Specify Property Name and Property Value if you want

to configure any other property.

NAM_DFP_KEYS_ENFORCE_STRICT Click OTHER to configure this property.

When Advanced Session Assurance is enabled, specify
true to send session keys only the first time when the
device information is fetched. Specify false to send
session keys each time the device information is fetched.
The default value is false.

ENCODE_TARGET_URL_QUERY Click OTHER to configure this property.

When this option is set to true, the target URL query
(SAML Request) is URL encoded. This option is set to
true by default. When you set this option to false, the
following will happen after authentication:
The target URL query is not URL encoded
The user is not redirected to the service provider
The following message is displayed:

<amLogEntry> 2018-08-20T17:00:18Z
WARNING NIDS Application: Error during
Inflate.
Exception message: "It should be
divisible by four"

NMAS_SAML_SIGN_METHODDIGEST_SHA256 Click OTHER to configure this property.

Set this option to true while using the NMAS SAML
method. When set to true, it uses SHA265 algorithm for
SAML 2 assertion. If this property is not configured or the
value is set to false, SHA1 algorithm is used. The default
value is false.

persist_caches_on_reconfigure Click OTHER to configure this property.

After you update a configuration or reconfigure it, the
user session details and read attributes get deleted from
the cache. Set this option to true to retain the details after
a configuration update.

This PDF was generated on July 27, 2025 Page 65 of 2270

 Access Manager 25.2

OAUTH_CLAIMS_TO_USE_LDAP_ATTR_FORMAT Click OTHER to configure this property.

Set this option to true to configure the OAuth claims data
type according to the schema data type of the LDAP
attribute. If the LDAP attribute data type is single-valued,
the claims data is returned as a string. If the LDAP
attribute data type is multi-valued, the claims data is
returned as a string array irrespective of the value count.
For example, let us assume that a client application uses
the Authorization Code flow and sends the access token
to the userinfo endpoint. Then you can choose the
format of the token's attribute data type that will be
returned.
The following is an example of attributes when this
property is not configured or set to false:

"family_name": "Lastname"

The following is an example of attributes when this

property is set to true:

"family_name": [
"Lastname"
]

This option is set to false by default.

OAUTH_REDIRECT_URL_EXACT_MATCH Click OTHER to configure this property.

Set this option to true. When set to true, it validates query
parameters in the redirect URI registered with the OAuth
client applications.

OAUTH_PARAMETERS_ENCODE_BASE64 Click OTHER to configure this property.

Set this option to true. When set to true, and state
parameter is passed with “&” and redirect URI as URL
encoded values in the request, the state parameter
parses the “&” and gets decoded state value.

ENCODE_AUTHZ_STATE_PARAMETER Click OTHER to configure this property.

Set this option to true. When set to true, and state
parameter is passed with JSON value as URL encoded
values in the request, the same state encoded JSON
state value is received in the response.

OIDC_PROTOCOL_COMPLIANCE Click OTHER to configure this property.

Set this option to true. When set to true, the attribute
values in the token is received as Boolean.
The following is an example of attributes when this
property is set to true:

email_verifed : true

This PDF was generated on July 27, 2025 Page 66 of 2270

 Access Manager 25.2

3. Click Save.

This PDF was generated on July 27, 2025 Page 67 of 2270

 Access Manager 25.2

1.1.2.4. Configuring IDP global settings

You can use IDP Global Settings in any Identity Server cluster configuration. You can define the following IDP Global Settings:

Setting See

Attribute sets Configuring attribute sets and Editing attribute sets

Custom Attributes Adding custom attributes

Data Sources User attribute retrieval and transformation

Virtual Attributes User attribute retrieval and transformation

Authentication Card Images Adding authentication card images and Creating an image
set

Metadata Repositories Metadata repositories

User Matching Expressions Configuring user matching expressions

Session Assurance See Setting up session assurance

The IDP Global Settings page also contains tabs for configuring the server details for OpenText Advanced Authentication and
Self Service Password Reset products.
You need to configure these details when integrating the product with other products.
Configuring the Advanced Authentication server
Configuring Self Service Password Reset server details in Identity Server

This PDF was generated on July 27, 2025 Page 68 of 2270

 Access Manager 25.2

1.1.2.4.1. Configuring attribute sets

The attributes you specify on Identity Server are used in attribute requests and responses, depending on whether you are
configuring a service provider (request) or identity provider (response). Attribute sets provide a common naming scheme for
the exchange.
For example, an attribute set can map an LDAP attribute, such as givenName to the equivalent remote name used at the service
provider, which might be firstName. You can use these shared attributes for policy enforcement, user identification, and data
injection.
Example 1:Attribute sets provide the centrally configurable means to map identity attributes between federation partners.
When OpenText Access Manager Identity Server provides authenticated user information to a federated service provider such
as Microsoft 365, the attribute set determines what identity information is sent and available to Microsoft 365 during and after
authentication. The source of the identity data being sent can be the user's local LDAP directory or can be calculated
dynamically. The identity data from external databases and secondary LDAP directories is achieved through virtual attributes.
Virtual attributes are dynamically calculated attributes populated by the Attribute Retrieval and Transformation feature. See
User attribute retrieval and transformation.
Example 2: You could have a web server application that requires a user’s e-mail address. You configure the web server to be
a protected resource of Access Gateway, and you configure an Identity Injection policy to add the user’s email address to a
custom HTTP header. When the user accesses the protected resource, the value of the email attribute is retrieved. However, if
you create an attribute set with this attribute and assign it to be sent with the authentication response of Access Gateway ESP,
the value is cached at authentication and is immediately available. If you have multiple attributes that you are using in policies,
obtaining the values in one LDAP request at authentication time can reduce the amount of LDAP traffic to your user store.
You can define multiple attribute sets and assign them to different trusted relationships. You can also use the same attribute set
for multiple trusted relationships.
Perform the following steps to create and configure an attribute set:
1. On the Home page, click Identity Servers > IDP Global Settings and select Attribute Sets.
2. Click the Plus icon to create an attribute set.
3. Specify the following details:

Field Description

Set Name Specify a name for identifying the attribute set.

Supports WSTrust and OAuth Select this option if you require to add the LDAP
attributes and the virtual attributes to an attribute set.
For the OAuth scope, you can add LDAP attributes or
only the virtual attributes that are LDAP attributes or are
constants.

Select Set to use as Template Select an existing attribute set that you have created,
which you can use as a template for the new set, or
select None. To modify an existing attribute set, select
that set as a template.

4. Click Next.
5. To add an attribute to the set, click Plus icon.
6. Specify the following details:

This PDF was generated on July 27, 2025 Page 69 of 2270

 Access Manager 25.2

Field Description

Local Attribute Select an attribute from the list of all server profile, LDAP,
shared secret attributes and virtual attributes.
For example, you can select All Roles to use in role
policies, which enables trusted providers to send role
information in authentication assertions. Share secret
attributes must be created before they can be added to
an attribute set. For instructions, see Creating shared
secret names.

Constant Specify a value that is constant for all users of this

attribute set. The name of the attribute that is associated
with this value is specified in Remote Attribute.

This PDF was generated on July 27, 2025 Page 70 of 2270

 Access Manager 25.2

Remote Attribute Specify the name of the attribute defined at the external
provider. The text for this field is case-sensitive.
A value is optional if you are mapping a local
attribute. If you leave this field blank, the system
sends an internal value that is recognized between
Identity Servers.
For SAML 2.0 identity consumer (service provider),
a name identifier received in an assertion is
automatically given a remote attribute name of
saml:NameIdentifier. This allows the name identifier
to be mapped to a profile attribute that can then be
used in policy definitions.
A value is required if you are mapping a constant.
An attribute set with a constant is usually set up
when Identity Server is acting as an identity
provider for a SAML service provider. The name
must match the attribute name that the service
provider is using.
To configure the FriendlyName attribute, use the
delimiter $$ to separate attribute name and
FriendlyName.
For example, configuring the Remote attribute as
urn:oid:0.9.2342.19200300.100.1.2$$email,
urn:oid:0.9.2342.19200300.100.1.2 is considered as
value for SAML2 Attribute Name and email is
considered as value for FriendlyName attribute.
The SAML assertion will contain the below SAML
attribute:
<saml:Attribute FriendlyName="email"
Name="urn:oid:0.9.2342.19200300.100.1.2"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-
format:uri"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance"> <saml:AttributeValue
xsi:type="xs:string">[email protected]</saml:AttributeValue>
</saml:Attribute>

This PDF was generated on July 27, 2025 Page 71 of 2270

 Access Manager 25.2

Remote Namespace Specify the namespace defined for the attribute by the
remote system:
If you are defining an attribute set for LDAP, select
none. If you want a service provider to accept any
namespace specified by an identity provider, select
none. If you want an identity provider to use a
default namespace, select none. The
urn:oasis:names:tc:SAML:1.0:assertion value is
sent as the default.
If you are defining an attribute set for WS
Federation, select the radio button and specify the
following name:

http://schemas.xmlsoap.org/claims

If you want to specify a new namespace, select the

radio button and specify the name.

Remote Format Select one of the following formats:

unspecified: Indicates that the interpretation of the
content is implementation-specific.
uri: Indicates that the interpretation of the content is
application-specific.
basic: Indicates that the content conforms to the
xs:Name format as defined for attribute profiles.

Attribute Value Encoding Select one of the following encoding options:

Special characters encoded: Encodes only the
special characters in the attribute value.
Not encoded: Does not encode the attribute value.
Entire value encoded: Encodes the entire attribute
value.

7. Click Save.
8. Click Finish.
The system displays the map on the Attribute Sets page and indicates whether it is in use by a provider.
9. (Conditional) To configure a provider to use the attribute set, see Selecting attributes for a trusted provider.

This PDF was generated on July 27, 2025 Page 72 of 2270

 Access Manager 25.2

1.1.2.4.2. Editing attribute sets

1. On the Home page, click Identity Servers > IDP Global Settings.
2. Click the name of the attribute set that you want to edit.
3. The system displays an attribute set page with the following details:
Display name: Click to edit the name of the attribute set.
Attribute mapping: Click to edit the attribute map.

Note
After editing the attribute mapping, verify the attribute set again in the trusted provider's list. Select the
attributes from the Available list, and move them to the left side of the page. Update Identity Server.

Usage: Displays where the attribute set is used. Informational only.

4. Click Save.

This PDF was generated on July 27, 2025 Page 73 of 2270

 Access Manager 25.2

1.1.2.4.3. Adding custom attributes

You can add custom shared secret names or LDAP attribute names that you want to make available for selection when setting
up policies.
Creating shared secret names
Creating LDAP attribute names

This PDF was generated on July 27, 2025 Page 74 of 2270

 Access Manager 25.2

1.1.2.4.3.1. Creating shared secret names

The shared secret consists of a secret name and one or more secret entry names. You can create only a secret name, or a
secret name and an entry name. For ease of use, the entry name must match the policy that uses it:
For a Form Fill policy, the entry name must match a form field name.
For an Identity Injection policy, the entry name must match the Custom Header Name.
For an External Attributes policy, Secret Name must match the policy name and Secret Entry Name must match the
attribute name configured while creating the policy.
For example, if the policy name is fetchattr and attribute name configured in the policy is address , then Secret Name
must be fetchattr and Secret Entry Name must be address .
Shared secret names can be created on the Custom Attributes page or in the associated policy that consumes them.
1. On the Home page, click Identity Servers > IDP Global Settings > Custom Attributes > Shared Secrets > Plus icon.
2. Specify a new shared secret name and, optionally, a secret entry name.
3. Click Save.
4. (Optional) To create additional entries for the secret, click the Plus icon and click Save.

Caution
Identity Server cannot determine whether a policy is using a secret. Before you delete a shared secret, you must
ensure that it is not in use.

This PDF was generated on July 27, 2025 Page 75 of 2270

 Access Manager 25.2

1.1.2.4.3.2. Creating LDAP attribute names

LDAP attributes are available for all policies. LDAP attribute names can be created on the Custom Attributes page or in the
associated policy that consumes them. The attribute names that you specify must match the name of an attribute of the user
class in your LDAP user store.
1. On the Home page, click Identity Servers > IDP Global Settings > Custom Attributes > LDAP Attributes.
This list contains the attributes for the inetOrgPerson class. It is customizable.
audio: Uses a u-law encoded sound file that is stored in the directory.
businessCategory: Describes the kind of business performed by an organization.
carLicense: Vehicle license or registration plate.
cn: The X.500 commonName attribute, which contains a name of an object. If the object corresponds to a person, it
is typically the person’s full name.
departmentNumber: Identifies a department within an organization.
displayName: The preferred name of a person to be used when displaying entries. When displaying an entry,
especially within a one-line summary list, it is useful to use this value. Because other attribute types such as cn are
multivalued, an additional attribute type is needed.
employeeNumber: Numerically identifies a person within an organization.
employeeType: Identifies the type of employee.
givenName: Identifies the person’s name that is not his or her surname or middle name.
homePhone: Identifies a person by home phone.
homePostalAddress: Identifies a person by home address.
initials: Identifies a person by his or her initials. This attribute contains the initials of an individual, but not the
surname.
jpegPhoto: Stores one or more images of a person, in JPEG format.
labeledURI: Uniform Resource Identifier with an optional label. The label describes the resource to which the URI
points.
mail: A user’s e-mail address.
manager: Identifies a person as a manager.
mobile: Specifies a mobile telephone number associated with a person.
o: The name of an organization.
pager: The pager telephone number for an object.
photo: Specifies a photograph for an object.
preferredLanguage: Indicates an individual’s preferred written or spoken language.
roomNumber: The room number of an object.
secretary: Specifies the secretary of a person.
sn: The X.500 surname attribute, which contains the family name of a person.
uid: User ID.
userCertificate: An attribute stored and requested in the binary form.
userPKCS12: A format to exchange personal identity information. Use this attribute when information is stored in a
directory service.
userSMIMECertificate: PKCS#7 SignedData used to support S/MIME. This value indicates that the content that is
signed is ignored by consumers of userSMIMECertificate values.

This PDF was generated on July 27, 2025 Page 76 of 2270

 Access Manager 25.2

x500uniqueIdentifier: Distinguishes between objects when a distinguished name has been reused. This is a
different attribute type from both the uid and the uniqueIdentifier type.
2. Add a name:
1. Click Plus icon and specify a name.
2. If you want the attribute to return raw data instead of binary data, select 64-bit Encode Attribute Data.
3. Click Save.
3. To modify the 64-bit attribute data encoding, select an attribute, and click one of the following options:
Enable 64-bit encode: Specifies that LDAP returns a raw format of the attribute rather than binary format. OpenText
Access Manager encodes to base64, so that the protected resource understands the attribute. Use the base64
encoding if certificates require raw bites rather than the binary string format.
Disable 64-bit encode: Deletes the 64-bit data encoding setting.

This PDF was generated on July 27, 2025 Page 77 of 2270

 Access Manager 25.2

1.1.2.4.4. User attribute retrieval and transformation

The User Attribute Retrieval and Transformation feature enables you to retrieve an attribute from an external data source and
transform it before sending it in an assertion. The data source can be any database, REST web service, or LDAP repositories.
You can transform a user’s local attributes, LDAP attributes, Shared Secrets, and various profiles, such as Personal Profile and
Employee Profile.
You can use virtual attributes to generate dynamic data at runtime from the current values of the user attributes. The
transformed attribute values are not stored in any persistent data stores. They are in the memory as part of user’s session.
How user attribute retrieval and transformation helps
Managing a data source
Managing an attribute source
Managing a virtual attribute
Retrieving attributes from a REST web service
Sample JavaScripts with examples
User attribute retrieval and transformation limitations
Prerequisites for user attributes retrieval transformation
To perform complex user attribute transformations, you must have a basic understanding of JavaScript. To see sample
JavaScripts with examples, see Sample JavaScripts with examples.

This PDF was generated on July 27, 2025 Page 78 of 2270

 Access Manager 25.2

1.1.2.4.4.1. How user attribute retrieval and transformation

helps
User Attribute Retrieval and Transformation helps you to perform the following activities:
Retrieve attribute values from external sources other than the configured user stores. The sources can be external REST
web service, external database, or any external LDAP repository.
Transform attribute values before they are sent as part of an assertion to a federated provider. For example, you can edit
an attribute value before it is sent from identity provider to a service provider in a SAML 2.0 federation. You can also edit
an attribute value sent from identity provider to Access Gateway used in policies.
Transform the attribute value used in policies. For example, you can transform Identity Server role-based policies.
User Attribute Retrieval and Transformation introduces the following configuration settings in Identity Server:
Data Source: An entity that holds configuration properties that help in connecting to an external data source. The
properties of the data source can be defined in the data source user interface. A data source can be a REST web service,
an LDAP repository, or an SQL database.
Attribute Source:Represents queries that fetch attributes from a data source. You can define an LDAP search filter or an
SQL query. You can also define requests and configure the response to retrieve attributes from a REST web service
resource endpoint.
Virtual Attribute: Helps you specify the attributes that must be transformed and in the way the transformations happen. A
virtual attribute can transform multi-valued attributes.

This PDF was generated on July 27, 2025 Page 79 of 2270

 Access Manager 25.2

1.1.2.4.4.2. Managing a data source

You can create, edit, or delete a data source.

Note
You cannot delete a data source that is in use by an attribute source.

Creating a data source

To create a data source, perform the following steps:
1. On the Home page, click Identity Servers > IDP Global Settings > Data Sources.
2. Click Plus to add a data source.
3. Select one of the following data sources:
Database: Continue with Step 5.
Supported databases include Oracle and Microsoft SQL.
LDAP: Continue with Step 6.
eDirectory and Active Directory are supported. You can create multiple search context and LDAP replicas.
Rest Web Service: Continue with Step 4.
The data source of REST web service contains only the common information that is required by the endpoints, such
as base URL, setting trusted root, and authentication. If you require to retrieve attributes by using REST API calls
from an external REST web service, you must add the REST web service data source.
4. (For Database) Specify the following details:

This PDF was generated on July 27, 2025 Page 80 of 2270

 Access Manager 25.2

Field Description

Database Name Specify the name of the database.

Database Driver Select a driver from the list. The associated driver name
is auto-populated. If you select Others (Unsupported),
specify the driver name.

Max Connections Specify the maximum number of connections. The

default value 20.

Idle Timeout Specify the idle timeout. The default value is 600000
milliseconds. Set this value based on the server setting.
For example, if the server timeout value is 600000, then
the timeout value must not exceed 600000.

Connection Timeout Specify the connection timeout. The default value is

10000 milliseconds. Set this value based on the server
setting.

Username Specify the username used to read from the database.

Password Specify the password used to read from the database.

Confirm Password Specify the password again.

URL Specify the database URL based on the database driver

selected.

Based on the database type, you need to add the corresponding jars.
For oracle:
1. Download the JDBC connector for the Oracle database from Oracle.com.
2. Copy the JDBC connector jar to the following folder:
Administration Console: /opt/novell/nam/adminconsole/webapps/nps/WEB-INF/lib
Identity Server: /opt/novell/nam/idp/webapps/nidp/WEB-INF/lib
3. Restart Administration Console and Identity Server.
For microsoft SQL server:
1. Download the JDBC connector for the SQL Server database from Microsoft.
2. Copy the JDBC connector jar file to the following folder:
Administration Console: /opt/novell/nam/adminconsole/webapps/nps/WEB-INF/lib
Identity Provider: /opt/novell/nam/idp/webapps/nidp/WEB-INF/lib
3. Restart Administration Console and Identity Server.
5. (For LDAP) Specify the following details:

This PDF was generated on July 27, 2025 Page 81 of 2270

 Access Manager 25.2

1. Specify LDAP Connection Properties:

Field Description

LDAP Name Specify a display name for the LDAP database.

Directory Type Select the type of directory. If you select Others

(Unsupported), specify a directory name in the
adjacent field: sunonedir, custom1, custom2, custom3,
custom4, others.

Username Specify the username used to read from the database.

Password Specify the password used to read from the database.

Confirm Password Specify the password again.

LDAP Operation TimeOut Specify the LDAP operation timeout. The default value
is 15000 milliseconds. You can set this value based on
the server setting.

Idle Connection TimeOut Specify the connection timeout. The default value is
10000 milliseconds. Set this value based on the server
setting. For example, if the server timeout is 15000
milliseconds, then the LDAP timeout value must not
exceed 15000.

2. Specify required number of contexts under Search Contexts.

1. Specify Search context to locate users in the directory.
2. Select the scope such as One level, Object, or Subtree in Scope.
If a user exists outside of the specified search context and its scope (One level, Object or Subtree), Identity
Server cannot find the user and the search fails.
3. Click Add to search the context.
3. Specify required number of LDAP replicas under Server Replicas.
1. Click Add.
2. Specify the following details to add a LDAP replica:

This PDF was generated on July 27, 2025 Page 82 of 2270

 Access Manager 25.2

Field Description

Name Specify a name to represent the LDAP replica.

IP Address/DNS Name Specify the IP address of the LDAP directory.

Port Specify the port number. By default, it is 389.

For a secure connection, select Use Secure LDAP
Connection. The port number changes to 636.
You must import the trusted root if you select a
secure connection. To import the trusted root, click
Auto Import Trusted Root. The trusted certificate of
the server will be imported to the Identity provider
trust store. Update the Identity provider each time.

Connection Limit Specify the maximum number of connections. By

default, it is set to 20.

3. Click Done.
6. (For REST Web Services) Specify the following details:

This PDF was generated on July 27, 2025 Page 83 of 2270

 Access Manager 25.2

Field Description

Web Service Name Specify a display name for the web service.
This can be any alpha-numeric name.

Description (Optional) Specify the description for the web service.

Base URL Specify the base URL in the <protocol>://<host>:<port >

format. For example: http://172.16.0.0:80
Here, protocol can be HTTP or HTTPS.
This is a common URL that can be used for the endpoints
that use the same host and port. A common URL is used
because the authentication and data connection
properties will be common for all endpoints.
For example, you can use the base URL as
www.abc.com/rest if you want to retrieve user attributes
from the following REST endpoints:
www.abc.com/rest/getUserDepartmentInfo
www.abc.com/rest/getUserInfo
You can add getUserDepartmentInfo and getUserInfo in
Resource/API Path in the attribute source page. The
attribute source page is used for retrieving attributes that
are specific to each web service endpoint.

Trusted Root Select one of the following options:

Verify from IDP trust store: Select this option if
Identity Server must verify the SSL certificate of the
web service.
To import the trusted root from a specific web
service, click Manage Web Service Trust Store.
The trusted certificate of the server will be imported
to the Identity Server trust store. Update the Identity
Server each time.
Do not verify: Select this option if you do not
require Identity Server to verify the SSL certificate
of the web server.

Connection Timeout Specify the duration until which OpenText Access

Manager must try connecting to the REST web server in
milliseconds. The default value is 15000 milliseconds. If
the host is not reachable, clicking Test will give the
timeout error after the specified duration.

This PDF was generated on July 27, 2025 Page 84 of 2270

 Access Manager 25.2

Authentication Properties Select the type of authentication that will be required for
connecting to the required web service.
If you select Basic Auth, the Authorization header with
the specified username and password gets added
automatically to the request header, which is used for
retrieving data from a REST endpoint.
This ensures that the Authorization header gets added
under the request header in the attribute source page.

Credentials This field is displayed only when you select

Authentication Type as Basic Auth.
You can select any one of the following options:
Admin: Specify the username and password for
accessing the REST endpoints. Select this option if the
REST web server requires a common credential to
access all endpoints.
Custom: Specify required LDAP attribute of users for
accessing the REST endpoints. Use this option if the
access to REST web server endpoints require specific
user credentials.
You must specify the credentials that authorizes a user to
retrieve the information from the REST web server.

7. To test the data source connection after specifying the details, click Test under Test Connectivity.
You can also view the error logs at the following location:
/opt/novell/nam/adminconsole/logs/catalina.out

Note
For a REST web service, clicking Test checks the connection to the web service irrespective of the endpoint's
resource path and credentials. It checks the connection based on the IP address and port.

Editing a data source

1. On the Home page, click Identity Servers > IDP Global Settings > Data Sources.
2. Click the data source you want to modify.
3. On the Edit Data Source page, modify the details as required.

Note
If you change the IP address of the LDAP or REST web service data source, then, you must import the trusted
root of the updated server to the Identity Server trust store.

For more information about the fields on this page, see Creating a data source.
4. Click Save.
5. Update Identity Server.

This PDF was generated on July 27, 2025 Page 85 of 2270

 Access Manager 25.2

Important
You must update Identity Server when you edit properties of a data source that is in use by an attribute source and
the attribute source in turn, being used by the virtual attribute.

This PDF was generated on July 27, 2025 Page 86 of 2270

 Access Manager 25.2

1.1.2.4.4.3. Managing an attribute source

You can create, edit, or delete an attribute source.

Note
You cannot delete an attribute source that is being used by a virtual attribute.

Creating an attribute source

1. On the Home page, click Identity Servers > IDP Global Settings > Virtual Attributes > Attribute Source.
2. Click Plus icon to add an attribute source.
3. Specify a name and description for the attribute source.
4. Select the data source.
5. Specify the following details in Step 1: Provide Input Parameters:

Field Description

Name The default value is %P1% or {P1} based on the selection

of data source.
Specify the same name in Query or in fields that use the
value of the attribute.

Parameter Value Select an attribute from the list.

Show / Add Test Values Click this to display the test value, and specify a value in
Test value.
This value is used later when testing the query string or
the web service.
For REST web service, the input parameters can be used
in creating resource API path, request headers, request
body and the Advanced: Javascript response parsing
functions. These can be tested using the test values. To
use the Input Parameters, you must provide the
parameter in the {<parameter name>} format, such as
{P1} .
When you click Test, the Test Results pane displays the
status of the request and response based on the
specified values.

Note
For LDAP and database, the attribute source does not support multi-valued inputs. If you input multiple
values, only one value is picked for the calculation.
For REST web service, the attribute source supports multi-valued inputs for a parameter.

6. (Conditional) For LDAP or database, specify the following details in Step 2: Provide Query and Output parameters:

This PDF was generated on July 27, 2025 Page 87 of 2270

 Access Manager 25.2

Field Description

Query Specify an LDAP filter or a database query.

The query must use the value specified in Step 1: Provide
Input Parameters.

Query Output Parameters Specify a name for the query output.

To add multiple output parameters, click Plus icon.
For an LDAP filter, specify the exact name of the
attribute that you want to fetch.
For a database query, specify an alias for the
attribute fetched. The order of the output
parameters must match the sequence in which they
are specified in the database query.

Sample configuration
See A sample LDAP scenario and A sample database scenario.
7. Click Test to test the input values based on the filter and output parameters.
For security reasons, you are prompted to enter the data source credentials. Test Result displays the status along with
the test results. You can also view the error logs at the following location:
/opt/novell/nam/adminconsole/logs/catalina.out
8. (Conditional) For REST web service, specify the following details in Step 2: Configure Request and Response:

This PDF was generated on July 27, 2025 Page 88 of 2270

 Access Manager 25.2

Field Description

Base URL Auto-populated based on the details specified for the

data source.

Resource/API Path Specify the path of resource or API to be used along with
the base URL to send a request to the REST web service.
For example, if you require to fetch attributes from the
www.abc.com/rest/getUserInfo endpoint and the base
URL is www.abc.com/rest/ , then specify Resource/API
Path as getUserInfo .
If REST web service requires the input parameters
defined in Provide Input Parameters, select Plain Text or
Javascript and use the parameter within Resource/ API
Path.

Plain Text Select this when you need to add simple values, such as
a constant value and unmodified input parameter values.
You can use Plain Text in the following scenarios:
If the REST web server requires a constant value,
such as user1 , to be available in the resource/ API
path, select Plain Text and specify Resource/ API
Path as /getuserinfo/user1 .
If the REST web server requires a user name to be
available in Resource/ API Path for different users,
use the input parameter {P1} with the givenName
value to specify Resource/ API Path, such as
/getuserinfo/{P1} .

This PDF was generated on July 27, 2025 Page 89 of 2270

 Access Manager 25.2

Javascript Select this when you need to add and modify complex
values in Resource/ API Path. For example, if in the
endpoint URL, REST web server requires the user’s name
in lower case along with the last name in lowercase, you
can specify the following in Resource/ API Path:

function main({P1},{P2})
var ret='/getuserinfo/'+
{P1}.toLowerCase()+"/"+{P2}.toLowerCase();
return ret;
}

The return type of JavaScript can be string or array.

Note
The input parameter can include multiple
values, such as email (it can have values
[email protected] and [email protected]).
The multi-valued input parameter in the
JavaScript main function are sent as a
JavaScript array. If this attribute contains a
single value for a specific user, this attribute
is sent as a string to the JavaScript main
function. So, ensure to check whether a
parameter is sent as a string (single value) or
as an array (multiple values) before
processing it in the JavaScript main function.

Method Select the request method that is accepted by the REST

web server.
GET and POST are the supported methods.

Request Headers and Body Add request headers based on the REST endpoint
configuration. By default, the Authorization header gets
generated if you have selected Basic Auth during the
creation of the REST web service Data source.
You can add multiple headers for specific endpoints
when configuring request headers. You can use the input
parameter in the header value such as, {P1} .
Specify the body message in plain text or JSON format.
To specify the message using JavaScript, select
Javascript.
When you write a script, ensure that you request for the
values that are either in string or in JSON format.

This PDF was generated on July 27, 2025 Page 90 of 2270

 Access Manager 25.2

Plain Text Select to include a constant input value or any input

parameter value in the request body.The following
example helps in understanding how to use the values in
request body using plain text format:
If the body request should contain the constant
values such as, john123 (userid), and abc
(department) then you can specify Request > Body
as {"userid": "john123", "department" : "abc"}
If the body request should contain some specific
value that is variable and is not modified, then you
can specify Request > Body as { "userid": {P1},
"department" : {P2}}

Javascript: Select to include a complex request body that requires

modified input parameter values.The following example
helps in understanding how to use the values in request
body using the JavaScript format:

function main({P1}, {P2}){

var ret = '{ "userid":"'+ {P1} +
'","department" : "'+ {P2}+'"}';
return ret;
}

Response Parsing Function and Parameters To extract a specific response portion from the REST
web server response, select the required response
parsing function from the list.
When a response is returned, you can use response
parsing function to retrieve specific parameters that get
mapped to the response parameters. This helps in
retrieving the required values from the response. The
Advanced: Javascript response parsing function can
return single value (string, number, JSON) or multi-
valued (array of strings, array of JSON) that get mapped
to response parameters.
Choose the required response parsing function along
with its inputs under Response Parsing Function and
Parameters. If you do not require to use the functions,
you can choose No Response Parsing Function.
For more information about each function, see Response
parsing functions.

This PDF was generated on July 27, 2025 Page 91 of 2270

 Access Manager 25.2

Add Output Parameter or Plus icon Click Add Output Parameter or Plus icon to add
parameter names to map to the values retrieved from the
analyzed response.
Response_As_Is is the default parameter that includes
the complete response as it is received from the web
server. You cannot delete Response_As_Is.
Sample JSON Response:

{
attribute1: "abc"
attribute2: "pqr"
}

You get Response_As_Is under Response

Parameters and you can specify attribute1 and
attribute2 under Response Parameters. This maps
the Response Parameters to the attribute values in
the JSON response. Hence, attribute1 is mapped
to abc and attribute2 is mapped to pqr .
Sample Array Response:

result[0]
result[1]

You get Response_As_Is under Response

Parameters and you can specify param1 and
param2 under Response Parameters. This maps
the Response Parameters to the attribute values in
the array response. Hence, param1 is mapped to
result[0] and param2 is mapped to result[1].
For more information about mapping the parameters
with the required attribute, see Retrieving attributes
from a REST web service.

Sample configuration
See A sample REST service scenario.
9. To test this configuration:
1. In Step 1: Provide Input Parameters, select Show / Add Test Values, and provide a test value that is available as an
attribute in the REST web server endpoint.
2. In Step 2: Configure Request and Response, click Test. Specify the credentials that is defined while creating the
data source. (See Creating a data source)
Test results display the status for request and response. You can view the request URL, Headers, and Body under
Request and view response parameters and headers under Response. The value of the parameters as retrieved
from the response parsing function gets displayed in the test result window.
The test result window displays the error message when the test result fails. For more information about the error
you can check the logs at the following location:
/opt/novell/nam/adminconsole/logs/catalina.out
A sample LDAP scenario
You want to fetch an email address from an external LDAP directory for which a user’s LDAP attribute (from the external LDAP
directory) UID matches with the local LDAP attribute cn.
To achieve this, perform the following steps:

This PDF was generated on July 27, 2025 Page 92 of 2270

 Access Manager 25.2

1. In Step 1: Provide Input Parameters, select LDAP attribute: cn as a parameter value. Add input parameter %P1% and
map it to the LDAP attribute.
2. In Step 2: Provide Filter and Output Parameters:
1. Specify (&(objectclass=*)(uid=%P1%)) .
2. Specify the filter output name as email . email is the alias name given for the column email.
3. Test this configuration.
1. In Step 1: Provide Input Parameters, select Show / Add Test Values and provide the test value as admin .
2. In Step 2: Provide Filter and Output Parameters: Click Test. Enter the data source credentials.
The test result returns the email address stored in the directory: [email protected] .
A sample database scenario
You want to fetch an email address from the database for which a user’s name matches with the local LDAP attribute cn.
To achieve this, perform the following steps:
1. In Step 1: Provide Input Parameters, select LDAP attribute: cn as the parameter value.
2. In Step 2: Provide Query and Output Parameters:
1. Specify select email from Emp where name = '%P1%' (email and name are the column name and Emp is the table
name)
2. Specify the filter output name as mail (mail is the alias name given for the column email).
3. Test this configuration.
1. In Step 1: Provide Input Parameters, select Show / Add Test Values?, and provide a test value that represents a
record in the column of the table.
2. In Step 2: Provide Query and Output Parameters: Click Test. Specify the data source credentials.
The test results return the email address stored in the database: [email protected] .

Note
Access manager also supports stored procedure queries in Database attribute sources.
For example: exec proc
exec proc @mail = '[email protected]'

A sample REST service scenario

You have a web service that returns the roles of a user and you require to retrieve the designation of the user from the
response received.
The endpoint of the REST web service: https://10.10.10.1:8543/rest/catalog/user1/roles/role
Base URL: https://10.10.10.1:8543/rest/catalog/
Request body:

"roles": [
{
"id": "cn=user1,cn=system,cn=usrapplication,ou=abc,ou=example,o=com"
}
]
}

Response from REST web server (Response_As_Is):

This PDF was generated on July 27, 2025 Page 93 of 2270

 Access Manager 25.2

{
"roles": [
{
"id": "cn=user1,cn=system,cn=usrapplication,ou=abc,ou=example,o=com",
"name": "user1",
"designation": "Provisioning Administrator",
"department": "Engineering",
"level": 20,
"subContainer": "system",
"status": 50
}
]
}

To retrieve the designation of user1 and map to Response Parameter, perform the following steps:
The response parameter mapped to the designation attribute value is used in virtual attribute.
1. In Step1: Provide Input Parameters, specify {P1} with the givenName value.
This input parameter is required because web server requires the user’s cn information in the request.
2. In Step 2: Configure Request and Response:
1. Select Plain Text and specify Resource/ API Path as {P1}/roles/role .
Base URL is auto-populated from the value specified in the Data Source page, https://10.10.10.1:8543/rest/catalog/ .
2. Select Method as Post.
In this scenario, the REST web service uses the POST method.
3. In the Headers tab, Authorization is auto-populated. This header is retrieved from the REST Data Source page.
4. Select Plain Text and specify the request body message:

{
"roles":
{"id":"cn={P1},cn=system,cn=usrapplication,ou=abc,ou=example,o=com"}
]
}

5. Select JSON Parse with Match Conditions.

6. Specify the following Inputs:
JSON Array Parse String: roles
Match Conditions:
Name : name
Value: user1
3. Test this configuration.
1. In Step 2: Configure Request and Response, click Test. Specify the data source credentials.
The Response_As_Is parameter is added by default.
2. Click the edit icon next to the Response_As_Is parameter to view the complete response.
To map designation attribute value to an output parameter, you must add designation as output parameter under
Response Parameters.
When the condition ( name as user1 ) finds a match in the response, the designation value is retrieved and gets
mapped to the designation parameter.

This PDF was generated on July 27, 2025 Page 94 of 2270

 Access Manager 25.2

For information about retrieving response parameters, see Retrieving attributes from a REST web service.

Editing an attribute source

1. On the Home page, click Identity Servers > IDP Global Settings > Virtual Attributes > Attribute Source.
2. Click the attribute source you want to modify.
3. On the Edit Attribute Source page, modify the details as required.
For more information about the fields on this page, see Creating an attribute source.
4. Click Save. Update Identity Server.

Important
If the attribute source is being used by a virtual attribute, you need to update Identity Server every time you edit the
properties of an attribute source.

This PDF was generated on July 27, 2025 Page 95 of 2270

 Access Manager 25.2

1.1.2.4.4.4. Managing a virtual attribute

You can create, edit, or delete a virtual attribute.

Note
You cannot delete a virtual attribute that is being used by an attribute set. Before deleting a virtual attribute, ensure
that it is not being used by a policy.

Creating a virtual attribute

You can create a virtual attribute from an attribute source and from an external data source.
1. On the Home page, click Identity Servers > IDP Global Settings > Virtual Attributes.
2. Click Plus icon to create a virtual attribute.
3. Specify a name and description for the virtual attribute.
4. Click Provide Input Parameters and specify the following details:

Field Description

Name Specify a name for the attribute. If you use advanced

JavaScript option, specify the same name in Advanced
JavaScript. The default value is P1.

Parameter Value Select an attribute from the list. To specify additional

values, click +.

Note
If an attribute source returns a null or an
empty value, the corresponding input
parameter takes an empty string value.

Show / Add Test Values You can add, edit, and delete a test value.

5. Click Provide a Modification Function and specify the following details:

Select a Modification Function: Select a function. The corresponding JavaScript is displayed in Script. You can
further customize these scripts and use them in Advanced JavaScript.
The following table lists the pre-defined JavaScript functions with examples:

This PDF was generated on July 27, 2025 Page 96 of 2270

 Access Manager 25.2

Function Description Example: Pre-Defined Functions

No Modification Use this function if you do not

require any modification to the
input parameters.

To UpperCase Converts the input value to upper If P1=alice, then the result displays
case. This function works on ALICE.
arrays and single-valued input. It
uses the toUpperCase()
JavaScript function.
Works only on one input parameter
that is selected in Input
Parameters.

To LowerCase Converts the input value to lower If P1=ALICE, then the result
case. This function works on displays alice.
arrays and single-valued input. It
uses the toLowerCase()
JavaScript function.
Works only on one input parameter
that is selected in Input
Parameters.

Remove Substring Removes a substring from all If [email protected]

instances of the input value. This
Remove=@opentext, then the
function does not remove a
result is a.com.
substring from the global option.
This function works on arrays and
single-valued input. It uses the
following JavaScript function:
split() and join() .
Works only on one input parameter
that is selected in Input
Parameters.

Find And Replace Finds and replaces a string from all If P1=abcde
instances of the input value.
Find=e
Works only on one input parameter
Replace=a, then the result displays
that is selected in Input
abcda.
Parameters.

This PDF was generated on July 27, 2025 Page 97 of 2270

 Access Manager 25.2

Regex Replace Finds and replaces a substring If [email protected]

from all instances of the input
[email protected]
value by using a regular
expression. [email protected]
For example, to search /, you must The result displays:
escape it first using \. Use the [email protected]
following syntax: /\//
This function works on arrays and
single-valued input. It uses the
following JavaScript functions:
replace()
Works only on one input parameter
that is selected in Input
Parameters.

Find Subset by Regex Use this function if it is a multivalue If

input and you want a subset of
P1='’[email protected], [email protected],c
values from it, satisfying a
@opentext.com,
particular condition by using a
[email protected]”
regular expression. This function
works on arrays and single-valued regex= /opentext/
input. It uses the following
JavaScript function: replace() Then, the result displays:

Works only on one input parameter [email protected],

that is selected in Input [email protected]
Parameters.

Concatenate Values in a Parameter Concatenates multiple values of a If P1=abc, def

multivalue input. You must add a
Separator=+
separator between the values that
you want to concatenate. Then, the result displays:
Works only on one input parameter abc+ def
that is selected in Input
Parameters.

Concatenate Multiple Parameters Concatenates multiple input If P1=abc, def

parameter values, where each
and P2=123, 456
input parameter can be multivalue
input. You must add a separator Parameter Separator=+
between the values that you want
to concatenate. Multivalue Separator=:
Then, the result displays
abc:def+123:456

This PDF was generated on July 27, 2025 Page 98 of 2270

 Access Manager 25.2

Advanced JavaScript: Specify a customized JavaScript in See Sample JavaScripts with

this field. You need to create a examples.
JavaScript function with name
“main” and specify the code in it.
You can do the following:
Write your custom code
Paste a pre-defined code
Call multiple functions

Important
After JavaScript processing, if the output is a null value, the value of the virtual attribute is empty.
The pre-defined function can handle both single-valued and multivalue inputs. If the input is
multivalue, the pre-defined function is applied on each values.

Advanced JavaScript:
Sample JavaScript:

function main(P1, P2)

{
//some logic
//you can call yourFunction(name) and use its return value
return some value;
}
function yourFunction(name)
{
//some code
//return some value;
}

For advanced JavaScript, the input parameter name in the main function of the JavaScript must match the input
parameter name specified in Input Parameters. The return value can be a single value or an array.
When it is a multivalue input, it is sent as an array to the main function.
When the Identity Server computes the value of a virtual attribute, it calls a function named main that is available in
the script provided for it. The value (single value or array) returned by main is the value of the virtual attribute.
For example: Consider a scenario where P1 contains bmw and nissan , you can use the JavaScript instanceof
function to check if the input is single-valued or multivalue. If it is multivalue, then JavaScript iterates over the values
P1=['bmw', 'nissan']

function main (P1){

if( P1 instanceof Array) {
var a =P1[0] //will assign 'bmw' value to variable a
//do something
}
else{
// if the P1 is single value not a array
//do something
}
}

The following code checks if an input parameter is empty, contains a value, or undefined:

This PDF was generated on July 27, 2025 Page 99 of 2270

 Access Manager 25.2

function main(P1){
if(hasNoValue(P1))
// do something
return something;
}
function hasNoValue(P1){
if(P1 == null || (typeof P1 == 'undefined') || P1.trim().length == 0)
return true;
else
return false;
}

Test: Click this to test the input values based on the modification function. To test multivalue inputs, click the + icon.
For example, if an attribute mail has two values: [email protected] and [email protected] , click the + icon
twice. In each field, add the values separately.
The test result displays the status with the test results. You can view the error logs at the following location:
/opt/novell/nam/adminconsole/logs/catalina.out
Base64 Encode: (Conditional) Select this if you want to encode the modified attribute with Base64.
6. Click Save and update the Identity Server.

Editing a virtual attribute

1. On the Home page, click Identity Servers > IDP Global Settings > Virtual Attributes.
2. Click the virtual attribute you want to modify.
3. On the Edit Virtual Attribute page, modify the details as required.
For more information about the fields on this page, see Creating a virtual attribute.
4. Click Save and update the Identity Server.

Important
You must update Identity Server each time you edit the properties of a virtual attribute.

This PDF was generated on July 27, 2025 Page 100 of 2270
 Access Manager 25.2

1.1.2.4.4.5. Retrieving attributes from a REST web service

This section illustrates examples for the following tasks:
Sending requests and retrieving responses from a REST web service
Using Response parsing functions
Using test values

Example for using input parameter

You can use the input parameter in the JavaScript format in the request body.
In this example, the endpoint is https://abc.example.com:8543/users/rest/asset/roles/user . This endpoint uses the POST
method for a HTTP request and the following body content:

{
"users": [
{"id":"cn= user1,cn=system,cn=userapplication,cn=app1,ou=example,o=com"}
]
}

To change the body content to JavaScript and provide cn from defined input parameters, perform the following steps:
1. In Step1: Provide Input Parameters, specify {P1} as input parameter with parameter value cn.
Add the test values for {P1} as user and system .
2. In step 2: Configure Request and Response, change the request body message as follows:

function main({P1}) {
var cnValues = "cn=" + {P1}[0] + ",cn=" + {P1}[1]+
",cn=userapplication,cn=app1,ou=example,o=com";
var json = {
"users": [
{"id":cnValues}
]
};
return json;
}

You can provide multiple test values to a parameter {P1} and use the values as array in the JavaScript function for Resource/
API Path and Body.

Note
If {P1} has only one input value, OpenText Access Manager interprets {P1} in JavaScript as a string and not as an
array. Hence, for a single input value use {P1} instead of using {P1}[0].
If multiple values are available for {P1}, JavaScript returns all elements that are separated by a comma (,). For
example, test1 , test2 . Whereas, {P1} in plain text returns only the first value. For example, test1 .

Response parsing functions

When a REST web service receives a request, it returns a response. The response body is added as the Response_As_Is
parameter under Response Parameters. This parameter gets added by default. This function is used to get the specific data
from a response. Most of the REST web services return responses in the JSON format. The response can be sent in any other
format, such as xml and plain text. The response parsing functions is included for JSON and XML. For any response that uses
other formats, use the advanced JavaScript option.
You can add test values and click Test to test the result of the request.

This PDF was generated on July 27, 2025 Page 101 of 2270
 Access Manager 25.2

The following example explains the response parsing functions:

Sample response returned from REST endpoint (Response_As_Is):
The REST web server returns the data of all students in an array of JSON format as mentioned in the following sample
response:

{
"students": [
{
"name": "xyz",
"id": 1234,
"subjects": [
"English", "French"
],
"department": "dept1",
"branch": "IND"
},

{
"name": "abc",
"id": 124,
"subjects": [
"French"
],
"department": "dept2",
"branch": "IND"
}, { "name": "pqr",
"id": 223,
"subjects": [
"Spanish"
],
"department": "Dept1",
"branch": "IND"
}]
}

This sample response is used as an example for JSON Parse, JSON Parse with Match Conditions, JSON Parse with Match
Regex, and Advanced: Javascript.
The following is the list of functions:
JSON parse: Parse the data with JSON Parse() to retrieve the data from JSON. This modification function uses the
JavaScript’s JSON.Parse function. On selecting this response parsing function, you must specify JSON Parse String.
Use the following inputs to retrieve specific attributes. You can provide the JSON Parse String value with standard
JavaScript’s JSON.Parse function.

This PDF was generated on July 27, 2025 Page 102 of 2270
 Access Manager 25.2

JSON Parse String (input Scenario Response Parameter Test Result

value)

students[0].name The value of the name param1 param1=xyz

attribute is retrieved from
The output is xyz as the
the first JSON in the
value of the name
response. This value must
attribute is xyz in the first
be mapped to param1 .
array of JSON. The
specified Response
Parameter is param1 , so
the test result displays it
as the parameter in
response.

students[1].name The value of the name name name=abc

attribute is retrieved from
Here, the output is abc
the second JSON in the
because the value of the
response. This value must
name attribute is abc in
be mapped to name .
the second array of JSON.
The specified Response
Parameter is name, so
the test result displays it
as the parameter in
response.

students[0].subjects[0] In this scenario, we are param1 param1=English

retrieving the first value of
Here, the output is
the subjects attribute
English because the first
from the first JSON of the
value of the subjects
response.
attribute in the first array
of JSON is English . The
value for the subjects
attribute is in an array
format, so specifying
subjects[0] in JSON
Parsing String retrieves
the first value in the array.

students[0].subjects[1] The second value of the param1 param1=French

subjects attribute is
The output for param1 is
retrieved from the first
French as it is the second
JSON of the response.
value of the subjects
This value must map to
attribute in the first array
param1 .
of JSON. The value for the
subjects attribute is in an
array format, so specifying
subjects[1] in JSON
Parsing String retrieves
the second value in the
array.

This PDF was generated on July 27, 2025 Page 103 of 2270
 Access Manager 25.2

students[0] The values of students is name name=xyz

retrieved from the first
id id=1234
JSON of the response.
These values must map param1 param1= <no value
with name , id and gets displayed>
param1 in the same order.
The output is based on the
number of values available
for the students attribute.
In the first array of JSON,
only two values are
available for students .
The third parameter
param1 is not mapped to
any value.
You can change the order
of Response Parameter by
using up and down arrow.
The values are mapped
based on the order
specified for Response
Parameter. For example, if
the order of Response
Parameter is as follows:
name
param1
id
The output in the Results
window displays:
name=xyz
param1=<no value
gets displayed>
id = 1234

JSON parse with match conditions: This function finds an array from the response and then apply match conditions on
the array elements to find the attribute that matches all the conditions. The following table includes the sample input value
and its result when the data of a student whose department is dept1 is retrieved:
Scenario: The value of students attribute that includes the attribute name department with value dept1 is retrieved.

This PDF was generated on July 27, 2025 Page 104 of 2270
 Access Manager 25.2

JSON Array Parse String (input Response Parameter Test Result

value)

students name name = xyz

Match Conditions id id = 1234
Name: department param1 param1 =<no value gets
displayed>
Value: dept1
When the condition is applied on the
students JSON of array, the name
parameter matches with name
attribute of the response and the id
parameter matches with the id
attribute of the response. However,
no param1 attribute is available in
the response. Therefore, no value
gets mapped to param1 .

JSON parse with match regex: This is the same as JSON Parse with Match Conditions except that you can specify
regex in the match condition. The following are examples of using regex:
Scenario: Attribute values is retrieved from the students JSON of array that includes the attribute name as department
and the value as dept1 . The value dept1 is case-insensitive.

JSON Array Parse String (input Response Parameter Test Result

value)

students name name ={ "name": "xyz", "id":

1234, "subjects": [ "English",
Match Regex: id
"French" ], "department":
Name: department "dept1", "branch": "IND" }
Regex: /dept1/i id ={ "name": "pqr", "id": 223,
"subjects": [ "Spanish" ],
"department": "Dept1",
"branch": "IND" }
The full JSON response is displayed
for name and id as the specified
regex condition is true for both
dept1 and Dept1 . As two matches
are available for the specified
condition, the parameters are
mapped to two separate JSONs.

Scenario: Attribute values of the attributes are retrieved from the students JSON of array that includes the attribute
name as department and the value must be only dept1 .

This PDF was generated on July 27, 2025 Page 105 of 2270
 Access Manager 25.2

JSON Array Parse String (input Response Parameters Test Result

value)

Match Regex: name name=xyz

Name: department id id=1234
Regex: /dept1/ The exact match for both response
parameters are displayed as one
match is available for name and
one match for id in the response
that meets the mentioned condition.

Advanced JavaScript: Use this if you require any custom JavaScript to parse any kind of data returned by a web service.
If a function is an array, the order of the parameters under Response Parameters is significant. However, the order is not
significant for JSON as it maps to the same name. The following is an example script for parsing the response with
Advanced: Javascript:
Scenario: A JavaScript is written to retrieve the attribute and customize it based on the requirement. For adding the email
parameter value, {P1} as input parameter is specified. A test value for {P1} as example is added.

This PDF was generated on July 27, 2025 Page 106 of 2270
 Access Manager 25.2

Script Response Parameters Test result

function Param1 Param1 : {

main(Response_As_Is, {P1}) "id": 123,
{ Param2 "mail": "
var jsonRes = [email protected]"
JSON.parse(Response_As_Is) }
;
var p1Val = ""; Param2: {
if({P1} instanceof "id": 124,
Array) { "mail":
var arrElem = {P1}[1]; "[email protected]"
if(arrElem != }
undefined) {
p1Val = arrElem;
The response from the REST web
}
} else {
service is modified to return the
p1Val = {P1};
array of students JSON that contains
} id and mail . The mail attribute is
var arrResult = []; modified with the input parameter
for(i = 0;i< values. In this scenario, the result of
jsonRes["students"].length the JavaScript is an array of JSONs.
-1; i ++) { Hence, the response parameters
var jsonTemp = {}; param1 and param2 are mapped
jsonTemp.id = with each JSON (in the same order).
jsonRes["students"][i]
["id"]; You can change the order of
jsonTemp.mail = Response Parameters by using up
jsonRes["students"][i] and down arrow. The values are
["students"] + p1Val; mapped based on the order you
specify. For example, the order of
arrResult.push(jsonTemp); Response Parameters is as follows:
}
return arrResult; param2
}
param1
The output in the Results window
displays:

param2 : {"id": 1234,

"mail": "
[email protected]"
}

param1: {id": 124,"mail":

"[email protected]"
}

XML parse with XPath: You can use this if the web service response is in the form of XML, and you require to provide the
XPath to extract the attribute from the xml based on the standard XPath format.
Sample Response in xml format(Response_As_Is): The following is a sample response that is sent by a REST web
service:

This PDF was generated on July 27, 2025 Page 107 of 2270
 Access Manager 25.2

<bookstore>
<book>
<title lang="en">
Harry Potter
</title>
<price>
29.99
</price>
</book>
<book>
<title lang="sp">
Learning XML
</title>
<price>
40
</price>
</book>
<book>
<title lang="dt">
ABCD
</title>
<price>
100
</price>
</book>
</bookstore>

XPath Scenario Response Parameter Test Result

/bookstore/book/title/text() All values are retrieved test test=[Harry Potter,

from title nodes in the xml Learning XML, ABCD]
response.

/bookstore/book[1]/title/te The value is retrieved from test test=Harry Potter

xt() title nodes within the first
book node in the xml
response.

/bookstore/book[1]/title The complete title node is test <title lang="en">

retrieved within the first Harry Potter
book node in the xml </title>
response.

Response parameters: When you select a response parsing function, you require to specify an output parameter under
Response Parameters to get the required parameter mapped to the output parameter. You can use the parameter name
specified under Response Parameters while configuring virtual attributes.

This PDF was generated on July 27, 2025 Page 108 of 2270
 Access Manager 25.2

1.1.2.4.4.6. Sample JavaScripts with examples

The following section provides sample JavaScripts with examples. These are used in the Virtual Attributes section.
Example 1:
Consider a scenario where a service provider wants to append PID with an attribute partnerId. For example: PID: P1.
To achieve this, fetch a user’s partnerId by using their existing “givenName” LDAP attribute (available from the logged in user
store) from the external LDAP repository. Now, add a string “PID:” to it. Later, send the value in web servers through the Identity
injection policy.
Solution: The solution is as follow:
Creating a Data Source:
1. Configure an LDAP data source with name “ dsLdap ”. Specify the connection properties. Test the connection.
2. Import the secure LDAP certificate to Identity Server trust store using the create Data Source screen.
3. Click Update All to update Identity Servers.
Creating an Attribute Source:
1. On the Home page, click Identity Servers > IDP Global Settings > Virtual Attributes > Attribute Source. Create an
attribute source with name “ dsLdapAttrSrc ”.
2. Select data source name “ dsLdap ”.
3. Add input parameter %P1% . Map it to the LDAP attribute: givenName .
4. Add a Filter: name= %P1% .
5. Add output parameter: partnerID
6. Test Filter: Test the input values.
Creating a Virtual Attribute:
1. On the Home page, click Identity Servers > IDP Global Settings > Virtual Attributes> Plus icon. Create a virtual
attribute with name “ partnerID ”.
2. Add input parameter P1. Map it to dsLdapAttrSrc:partnerID (the attribute source that you created in Step 1 of the creating
an Attribute Source section).
3. In Step 2: Provide query and output parameters, specify the following script:

function main(P1){
return "PID:"+P1;
}

4. Test the script. The results return: PID: P1. For example, if partnerID=part123, then, the test result is PID:part123.
5. Update Identity Server.
6. Use it in the Identity injection policy.
Example 2:
Consider a scenario where the authenticated user, named Carlos, is a manager and has administrator rights to a protected
human resource application. When Carlos accesses this application, his roles must be passed to the application.
In this scenario, Carlos has a local LDAP attribute isManager and has roles of a recruiter and an employee. He also has a local
LDAP attribute groupmembership , which contains the string admins (for example, adminsRecruitmentDep,
adminsPoliciesDep).
Solution: Create a virtual attribute, App1Admin .
1. In Step1: Provide Input Parameters, select the following input parameters:

This PDF was generated on July 27, 2025 Page 109 of 2270
 Access Manager 25.2

P1: is mapped to LDAP attribute isManager

P2: is mapped to LDAP attribute groupmembership
P3: is mapped to LDAP attribute role value
2. Use the following code in Step 2: Provide a Modification Function > Advanced Javascript:

function main(P1, P2, P3){

if(P1 == 'true' && (/admins/i.test(P2) == true)){
return P3;
}else{
return 'NA';
}
}

3. To test JavaScript, click + and add multiple test values. Specify the following test values:
P1: true
P2: adminsRecruitmentDep
P3: recruiter,employee
Output: The output is a multi-valued virtual attribute recruiter,employee.
In the function, /admins/i.test(P2) == true, /admins/i is a regular expression and test is a JavaScript in-built function. This
function tests the regular expression in the string passed as the input parameter. The function returns true if the string contains
the required pattern.
Example 3:
Consider a scenario where the product user wants to access Amazon Web Services (AWS). AWS has multiple roles and each
AWS role can have various access rights or policies assigned to it. Based on the level of access, you can access authorized
Amazon services. This information about roles must be sent dynamically by the product to AWS to provide single sign-on to
the OpenText Access Manager user.
For more information about AWS configuration, see Integrating amazon web services with Access Manager.
In this scenario, you have a constant value created using <Role ARN, Trusted SAML Provider ARN> mapped to Remote AWS
attribute Role (this value is the AWS format).
Suppose you have configured the admin and finance roles in AWS. The following are role ARNs:
For admin: arn:aws:iam::638116851885:role/admin
For finance: arn:aws:iam::638116851885:role/finance
For admin role, send the following: arn:aws:iam::638116851885:role/admin,arn:aws:iam::638116851885:saml-provider/NAMIDP
For finance role, send the following: arn:aws:iam::638116851885:role/finance,arn:aws:iam::638116851885:saml-
provider/NAMIDP
In this example, to dynamically generate the AWS role, use the LDAP attribute Department Name in the user store. For the
admin user, the department name is admin. For the finance user, the department name is finance. To make department name
available as an LDAP attribute, ensure that you enable personal profile through API (https://<admin-console-host>:<admin-
console-port>/nps/swagger-ui.html) .
Solution: Create a virtual attribute with the following information:
When the user logs in, the department name (finance) is fetched for the respective user and appended with the constant value
of the role ARN. This value is then concatenated with the trusted SAML provider ARN in the following format:
arn:aws:iam::638116851885:role/admin,arn:aws:iam::638116851885:saml-provider/NAMIDP
Map this virtual attribute with the AWS Remote Attribute role.
1. In Step1: Provide Input Parameters, select P1 parameter value as Department Name (Personal Profile).
2. Use the following code in Step 2: Provide a Modification Function > Advanced Javascript:

This PDF was generated on July 27, 2025 Page 110 of 2270
 Access Manager 25.2

function main(P1){
var role_arn='arn:aws:iam::638116851885:role/'
var provider_arn=',arn:aws:iam::638116851885:saml-provider/MyIDP_184-142';
var aws_role;
aws_role = role_arn+P1+provider_arn;
return aws_role;
}

3. To test JavaScript, click the + and add multiple test values. Specify the test value of P1: finance.
Output: arn:aws:iam::638116851885:role/finance,arn:aws:iam::638116851885:saml-provider/NAMIDP.
Example 4:
You want to send the groups associated with the user to a service provider named cloudsp. However, you want to send only
the groups relevant to that service, and not the complete group DN. Check for a function that checks if the group cn starts with
“cloudsp”. If available, send it to the group cn.
In this scenario, the cn of the groups relevant to cloudsp start with “cloudsp”. For example,
"cn=cloudspa,ou=group,o=mycompany". So, when a cloudsp user authenticates at Identity Server, you need to extract all cn
values from the local LDAP attribute groupMembership and filter only those names starting with cloudsp and send it in
assertion to cloudsp.
Solution:
1. In Step1: Provide Input Parameters, select P1 as an attribute which has the groups.
2. Use the following code in Step 2: Provide a Modification Function > Advanced Javascript:

function main( P1 ){
return mapGroups(P1);
}function mapGroups(attribute){
var result = [];
if(attribute instanceof Array){
var j =0;
for(var i=0; i<attribute.length; i++){
var grp = checkGroup(attribute[i]);
if( grp != 'NA')
result[j++] = grp;
}
}else{
var grp = checkGroup(attribute);
if( grp != 'NA')
result[0] = grp;
}
return result;
}function checkGroup(group){
if(/^cn=cloudsp.*,/.test(group) == true){
var startindex = 3;// it starts with cn
var endindex = group.indexOf(",");
return group.substring( startindex, endindex);
}else
return 'NA';
}

3. To test JavaScript, click the + and add multiple test values. Specify the test values:
cn=cloudspgroupa,ou=group,o=mycompany cn=cloudspgroupb,ou=group,o=mycompany
cn=cloudspgroupk,ou=group,o=mycompany
cn=testgroupa,ou=group,o=mycompany
Output:

This PDF was generated on July 27, 2025 Page 111 of 2270
 Access Manager 25.2

cloudspgroupa
cloudspgroupb
cloudspgroupk

Explanation:
The JavaScript in-built string function substring is used to extract the cn value from the group./^cn=cloudsp.*,/.test(group) is a
regular expression which matches a string that starts with cloudsp. It has 0 or more characters followed by a comma (,).
Example 5:
(Utility Function Reuse) Consider a scenario where the Identity Server roles are in the format companyX:rolename. A service
provider abc wants the roles in the rolename format and in upper case.
To achieve this, remove 'companyX:' from each role and convert each of them into upper case for sending them to the
protected web server. Each role is specified as companyX:rolename.
For example, companyX:admin, companyX:guest.
Solution:
1. In Step 1: Provide Input Parameters, select P1: All Roles.
2. Use the following code in the Step 2: Provide a Modification Function > Advanced Javascript:
Copy the JavaScript from the following pre-defined functions: Remove Substring and To upperCase.
Remove Substring function:

function findReplace(attribute, findString, replaceString){

var result;
if(attribute instanceof Array){
result = [];
for(var i=0; i<attribute.length; i++){
result[i] =attribute[i].split(findString).join(replaceString);
}
}else{
result = attribute.split(findString).join(replaceString);
}
return result;
}

To upperCase function:

function convertToUpperCase (attribute){

var result ;
if(attribute instanceof Array){
result = [];
for(var i=0; i<attribute.length; i++)
result[i] = attribute[i].toUpperCase();
}else{
result = attribute.toUpperCase();
}
return result;
}

Now, customize the code. In Substring to remove for findReplace (), specify companyX:

This PDF was generated on July 27, 2025 Page 112 of 2270
 Access Manager 25.2

function main(P1){
return convertToUpperCase(findReplace (P1, 'CompanyX:'));
}function findReplace(attribute, findString, replaceString){
var result ;
if(attribute instanceof Array){
result = [];
for(var i=0; i<attribute.length; i++){
result[i] =attribute[i].split(findString).join(replaceString);
}
}else{
result = attribute.split(findString).join(replaceString);
}
return result;
}function convertToUpperCase (attribute){
var result;
if(attribute instanceof Array){
result = [];
for(var i=0; i<attribute.length; i++)
result[i] = attribute[i].toUpperCase();
}else{
result = attribute.toUpperCase();
}
return result;
}

3. To test JavaScript, add the test values in P1: 'companyX:admin', 'companyX:guest'.Output: ADMIN, GUEST .
Example 6:
Consider a scenario where you do not want to modify an attribute value that is retrieved from an external source. To send the
same attribute value in the assertion to a federated provider or in a policies, perform the following steps:
1. On the Home page, click Identity Servers > IDP Global Settings > Virtual Attributes > Virtual Attribute.
2. In Step1: Provide Input Parameters, select P1, and map it to an attribute retrieved from an external source.
3. In Step 2: Provide a Modification Function, select Advanced JavaScript, and specify the following script:

function main(P1){
return P1;
}

4. Test the script. The results returns the value of the attribute source specified as P1.
5. Update Identity Server.

This PDF was generated on July 27, 2025 Page 113 of 2270
 Access Manager 25.2

1.1.2.4.4.7. Troubleshooting user attribute retrieval and

transformation

This PDF was generated on July 27, 2025 Page 114 of 2270
 Access Manager 25.2

1.1.2.4.4.8. User attribute retrieval and transformation

limitations
For LDAP and database sources, the multi-valued input parameters are not supported in the attribute source. If you input
a multi-valued parameter, only one value is picked for the calculation.
You cannot use the existing Identity server user stores directly as an attribute source. You must create a separate data
source to use the user stores.
You cannot edit or store any attribute value permanently in the existing LDAP attributes, shared secret attributes, or
external database by using virtual attributes.
SSL communication with SQL and Oracle databases that are used by virtual attributes (data sources) is not supported.

This PDF was generated on July 27, 2025 Page 115 of 2270
 Access Manager 25.2

1.1.2.4.5. Adding authentication card images

Each authentication contract and managed card template must have a card associated with it.
To add new images, the image files must be available from the workstation where you are authenticated to Administration
Console. Images must fall within the size bounds of 60 pixels wide by 45 pixels high through 200 pixels wide by 150 pixels
high. To add a card image:
1. On the Home page, click Identity Servers > IDP Global Settings > Authentication Card Images.
2. Click Plus icon and specify the following details:
Name: Specify a name for the image.
Description: Describe the image and its purpose.
File: Click Choose File, locate the image file, and click Open.
Locale: Select the language for the card or select All Locales if the card can be used with all languages.
3. Click Save.
4. If you did not specify All Locales in Locale, continue with Creating an image set.

This PDF was generated on July 27, 2025 Page 116 of 2270
 Access Manager 25.2

1.1.2.4.6. Creating an image set

You can create card images for specific locales and a default image for all locales. The images need to be placed in an image
set that allows the browser to display the image associated with the requested locale. If the browser requests a locale for
which you have not defined an image, the All Locales image is displayed. If an All Locales image is not available, the browser
displays the Image not Available card.
To add an image to the set, perform the following steps:
1. On the Home page, Identity Servers > IDP Global Settings > Authentication Card Images.
2. Click the card image.
3. Click Plus icon and specify the following details:
File: Click Choose File, then browse to the location of the file.
Locale: Select the locale from the list.
4. Click Add.

This PDF was generated on July 27, 2025 Page 117 of 2270
 Access Manager 25.2

1.1.2.4.7. Metadata repositories

Large scale federations have more than 100+ identity and or service providers and it is a tedious task to establish bi-lateral
relationships with OpenText Access Manager. You as an identity provider can now configure several identity providers and
service providers by using a multi-entity metadata file available in a central repository.
The identity and service providers can maintain a single metadata file containing metadata of all the approved partners.
Identity providers and service providers submit their metadata that includes specifications of services offered (SAML 2.0) and
any other information. This feature is available for SAML 2.0.
For example, XYZ is an e-book store and several e-book stores, which are identity providers or service providers, are partners
of XYZ. Hence, XYZ maintains a single metadata file that contains metadata of all other stores. ABC an e-book identity provider
wants to establish a federation with many other e-book stores. Hence, ABC partners with XYZ by sharing its metadata and XYZ
in turn shares the metadata XML file. ABC imports the XML file available publicly on the internet (for example,
http://xyz.commonfederation.org/xyz-metadata.xml) and establishes trusts with others in the federation, which includes XYZ’s
trusted provider sites.

This PDF was generated on July 27, 2025 Page 118 of 2270
 Access Manager 25.2

1.1.2.4.7.1. Creating metadata repositories

1. On the Home page, click Identity Servers > IDP Global Settings > Metadata Repositories.
2. Click Plus icon and specify the following details:
Name: Specify a name for the metadata repository.
Description: Specify the description of the metadata repository.
Source: Select the source from which you want to import the metadata file.
To specify the URL location of the XML file in URL, select Metadata URL.
To specify the path of the XML file in File, select Metadata File.
3. Click Save.
The details of the metadata such as the number of identity providers and service providers available in the metadata and
expiry date of the metadata are displayed.
You can select the metadata repository and click Delete Metadata Repository to delete the repository. If the metadata file
is in use, you cannot delete it. Delete the trusted provider and then delete the metadata file.
When the metadata repositories are imported, the entities available in the metadata repository can be assigned as trusted
provider to any of the Identity Servers. To create trusted providers, see Managing trusted providers.

This PDF was generated on July 27, 2025 Page 119 of 2270
 Access Manager 25.2

1.1.2.4.7.2. Reimporting metadata repositories

Reimport the metadata repository to get the updated XML.
1. On the Home page, click Identity Servers > IDP Global Settings > Metadata Repositories.
2. Click the metadata repository you created and enable Reimport.
3. Specify the URL location of the XML file in URL and click Next.
The page displays the following information:
New entities added to the repositories: If the entities are updated or deleted and are assigned as trusted providers to an
Identity Server cluster, the Identity Server cluster name is displayed in brackets next to the entity ID.
Entities deleted from the repositories: If the entity is updated and is assigned as a trusted provider to an Identity Server
cluster, that trusted provider will be updated. You must update Identity Server cluster for the changes to take effect.
Entities updated in the repositories: If an entity is deleted and was assigned as trusted provider to an Identity Server
cluster, the link between the trusted provider and the metadata repository entity is deleted.

Note
The corresponding trusted provider is not deleted. Delete the trusted provider manually.

4. Click Finish to apply the changes.

This PDF was generated on July 27, 2025 Page 120 of 2270
 Access Manager 25.2

1.1.2.4.8. Configuring user matching expressions

When a service provider receives an assertion from a trusted identity provider, the service provider tries to identify the user.
You can configure a service provider to perform one of the following actions:
Accept that the assertion contains a valid user and authenticate the user locally with a temporary identity and account.
When a user logs out, the account and identity are destroyed.
Use the attributes in the assertion to match a user in the local user store. When you want the service provider to take this
action, you need to create a user matching expression.
Use the attributes in the assertion to match a user in the local user store and when the match fails, create an account
(provisioning) for the user in the local user store of the service provider. When you want the service provider to take this
action, you need to create a user matching expression.
The user matching expression is used to format a query to the user store based on attributes received in the assertion from the
identity provider. This query must return a match for one user.
If the query returns a match for multiple users, the request fails and the user is denied access.
If the query fails to find a match and you have selected provisioning, the service provider uses the attributes to create an
account for this user in its user store. If you have not selected provisioning, the request fails and the user is denied
access.
The user matching expression defines the logic of the query. You must know the LDAP attributes that are used to name the
users in the user store in order to create the user’s distinguished name and uniquely identify the users.
For example, if the service provider user store uses the email attribute to identify users, the identity provider must be
configured to send the email attribute. The service provider uses this attribute in a user matching expression to find the user in
the user store. If a match is found, the user is granted access. If the user is not found, that attribute can be used to create an
account for the user. The assertion must contain all the attributes that the user store requires to create an account.
To create a user matching expression, perform the following steps:
1. On the Home page, click Identity Servers > IDP Global Settings > User Matching Expressions.
2. Click New or click the name of an existing user matching expression.
3. Specify a name for the user lookup expression.
4. Click Add Attribute icon and select attributes to add to the logic group.
5. Click Save.
6. To add logic groups, click Add Attribute Group.
Type (AND or OR) applies only between groups. Attributes within a group are always the opposite of the type selection.
For example, if Type is AND, the attributes within the group are OR.
7. Click the Add Attribute icon to add attributes to the next logic group and click Save.
8. Click Save.
9. (Conditional) If you selected attributes from the Custom, Employee, or Personal profile, enable the profile so that the
attribute can be shared through API (https://<admin-console-host>:<admin-console-port>/nps/swagger-ui.html).

This PDF was generated on July 27, 2025 Page 121 of 2270
 Access Manager 25.2

1.1.2.4.9. Configuring the OpenText Advanced Authentication

server
To integrate OpenText Advanced Authentication with OpenText Access Manager, you must configure the Advanced
Authentication server details in OpenText Access Manager.
For step-by-step details for integrating the product with Advanced Authentication, see Multi-Factor Authentication Using
Advanced Authentication.
Perform the following steps to configure Advanced Authentication server:
1. On the Home page, click Identity Servers > IDP Global Settings > Advanced Authentication.
2. Specify the following details:

Field Description

Service Domain Specify the scheme, domain name or IP address, and

port of the Advanced Authentication server.

Tenant Name Specify the name of the tenant that you want to use.
This field populates the TOP tenant of Advanced
Authentication by default. You can specify another tenant
name that you want to use.

Note
When using the Plug-in-based methods, skip to Step 5.

3. (Required only for OAuth-based approach) Select Integrate using OAuth under OAuth Event Configuration.
4. (Required only for OAuth-based approach) Specify the following details:

This PDF was generated on July 27, 2025 Page 122 of 2270
 Access Manager 25.2

Field Description

Event Name Specify an event name. This event name must be

identical to the event name specified in the Advanced
Authentication administration portal.

Client ID Specify the client ID that was generated while creating

the OAuth 2.0 event in the Advanced Authentication
administration portal.

Client Secret Specify the client secret that was generated while
creating the OAuth 2.0 event in the Advanced
Authentication administration portal.

Webauth Domain To use the Virtual Smartcard method, select Use the
Advanced Authentication Virtual Smartcard. This
populates the Webauth Domain URL.
For example, if aaserver.domain.com is the DNS name
of your web server then webauth.domain.com is
populated in the Webauth Domain field.
When you enable this option, all the requests from
Identity Server to OSP are redirected to
webauth.domain.com instead of
aaserver.domain.com .

Note
The Virtual Smartcard method must be
configured in the Advanced Authentication
server.

OpenText Access Manager uses the endpoint links to retrieve token and user details from the Advanced Authentication
server. These are default endpoint links. If the values of the URIs change because of modification of the Advanced
Authentication authorization server, then you can change the values here.

This PDF was generated on July 27, 2025 Page 123 of 2270
 Access Manager 25.2

Field Default Value Description

Authorization URL /osp/a/TOP/auth/oauth2/grant OpenText Access Manager uses this

URL to retrieve the authorization
code from the Advanced
Authentication server.

Token URL /osp/a/TOP/auth/oauth2/authcodere OpenText Access Manager uses this

solve URL to exchange the authorization
code with the access token.

User Info URL /osp/a/TOP/auth/oauth2/getattribute OpenText Access Manager sends

s the access token to this URL to get
the user details from the Advanced
Authentication server.

The fields under Integration URLs are auto-populated after you specify the server domain address.

Important
If the values are not auto-populated then specify the default values as mentioned in the following table.

Field Default Value Description

Enrollment Page URL /account/basic If a user is not enrolled in Advanced

Authentication server, OpenText
Access Manager uses this URL to
redirect the user to the enrollment
page.

Sign Data URL /osp/a/TOP/auth/oauth2/sign OpenText Access Manager uses this

URL to retrieve the signed data from
Advanced Authentication.

5. Click Save.
6. Proceed with Advanced Authentication to create Advanced Authentication classes.

This PDF was generated on July 27, 2025 Page 124 of 2270
 Access Manager 25.2

1.1.2.4.10. Configuring Self Service Password Reset server

details in Identity Server
1. On the Home page, click Identity Servers > IDP Global Settings > Self Service Password Reset.
2. Select Integrate with Self Service Password Reset (SSPR).
3. Specify the following details under Server Configuration:
Published SSPR URL: Select http or https and specify the Self Service Password Reset server’s IP address or DNS name
with the port number. If Self Service Password Reset is configured behind Access Gateway, then specify Access
Gateway's Published URL for Self Service Password Reset. For example, specify https://www.b2c.com/sspr/ .
API user name: Protected web services that require authentication through a user name and password use the secret
name as user name. The secret name is generated while configuring the Self Service Password Reset server. For
example, specify NAMSECRET in API User Name.
API password: Protected web services that require authentication through a user name and password use a secret key as
password. The secret key is generated while configuring the Self Service Password Reset server. For example, specify
pass@123 in API Password.
4. SSPR Portal Links and REST API Links show the URLs associated with the specified Self Service Password Reset server.

Important
SSPR Portal Links and REST API Links displays default URLs. These URLs must be modified to match the
URLs specified on the Self Service Password Reset server.

If you modify the integration links in the Self Service Password Reset server then you must specify the same integration
links in SSPR Portal Links and REST API Links. The values specified in SSPR Portal Links and REST API Links come after
Published SSPR URL to form a destination path.

Important
In some of the default URLs, forwardURLs are appended to ensure that the user is forwarded to correct URLs
after performing the corresponding tasks.

User profile URL: If a forwardURL is provided, the user is redirected to that URL after updating user profile in user portal
page. For example, if User Profile URL is set to /private?forwardURL=https://idp.b2c.com:8443/nidp/portal , then the
user is directed to that URL after profile update.
User registration URL: If a forwardURL is provided, the user is redirected to that URL after registering as a new user on
B2C portal page. For example, if User Registration URL is set to /private?
forwardURL=https://idp.b2c.com:8443/nidp/portal , then the user is directed to that URL after registration.
Auto registration URL: It automatically registers users when users log in using social authentication. It compares the user
specified attributes to the stored attributes. Specify /public/newuser/profile/Social .
Forgot password URL: If a forwardURL is provided, the user is redirected to that URL after password reset. For example, if
Forgot Password URL is set to /private?forwardURL=https://idp.b2c.com:8443/AGLogout , then the user is directed to
that URL after the user resets password.

Note
Forgot Password URL is not accessible if the Logout after password change option is enabled in Change
Password module of Self Service Password Reset.

Health API: It is used to obtain the health status of the Service Password Reset server. The default URL is
/public/rest/health .
Back channel request signing API: Access Manger uses this API to obtain information from Self Service Password Reset
server. The default URL is /public/rest/signing/form .

This PDF was generated on July 27, 2025 Page 125 of 2270
 Access Manager 25.2

Connection timeout: It is the time specified to establish the connection with Self Service Password Reset server. The
connection must establish within the specified time.
Read timeout: It is the time specified to obtain information from the Self Service Password Reset server after establishing
the connection. OpenText Access Manager must obtain information within the specified time.

Important
Ensure that these URLs are specified in the Self Service Password Reset allowable list. To specify these
URLs in allowable list navigate to Self Service Password Reset > Settings > Security > Web Security.
If a forwardURL is not provided then the default URLs are used. To see default URLs, navigate to Self
Service Password Reset > Settings > Application > Forward URL.

5. Click Apply Changes.

This PDF was generated on July 27, 2025 Page 126 of 2270
 Access Manager 25.2

1.1.2.5. Configuring Access Gateway

This PDF was generated on July 27, 2025 Page 127 of 2270
 Access Manager 25.2

1.1.2.5.1. Configuring a reverse proxy

You can protect your web services by creating a reverse proxy. A reverse proxy acts as the front end to your web servers in
your DMZ or on your intranet. It off-loads frequent requests, thereby freeing up bandwidth and web server connections. It also
increases security because the IP addresses and DNS names of your web servers are hidden from the Internet. A reverse
proxy can be configured to protect one or more proxy services.
To create a reverse proxy, you must create at least one proxy service with a protected resource. You must supply a name for
each of these components. Reverse proxy names and proxy service names must be unique to Access Gateway because they
are configured for global services such as IP addresses and TCP ports. For example, if you have a reverse proxy named
products and another reverse proxy named library , only one of these reverse proxies can have a proxy service named
corporate .
Protected resource names need to be unique to the proxy service, but they don’t need to be unique to Access Gateway
because they are always accessed through their proxy service. For example, if you have a proxy service named account and
a proxy service named sales , they both can have a protected resource named public .

What You Need To Know Example Your Value

Name of Identity Server cluster idp-corporate _______________________

DNS name of Access Gateway mytest.com ______________________

Web server information

IP address 10.15.70.21 ______________________

DNS name mywebserver.com ______________________

Names you need to create

Reverse proxy name mycompany ________________________

Proxy service name company ________________________

Protected resource name public ________________________

This first reverse proxy is used for authentication. You need to configure the proxy service to use the DNS name of Access
Gateway as its Published DNS Name, and the web server and the resource on that web server need to point to the page you
want displayed to the users when they first access your website. You can use Access Gateway configuration options to allow
this first page to be a public site with no authentication required until the users access the links on the page, or you can require
authentication on this first page.

This PDF was generated on July 27, 2025 Page 128 of 2270
 Access Manager 25.2

Basic configuration
Complete the following steps to first configure a protected resource as a public resource and then to modify the configuration
to require authentication:
1. On the Home page, click Access Gateways > Edit > Reverse Proxy / Authentication.
2. In Identity Server Cluster, select the configuration you have assigned to Identity Server.
This sets up the trust relationship between Access Gateway and Identity Server that is used for authentication.
3. In Reverse Proxy List, click New, specify a display name for the reverse proxy, then click OK.
4. Enable a listening address.
Listening address(es): A list of available IP addresses. If the server has only one IP address, only one is displayed and it
is automatically selected. If the server has multiple addresses, you can select one or more IP addresses to enable. You
must enable at least one address.
TCP listen options: Options for configuring how requests are handled. You cannot set up listening options until you create
a proxy service.
5. Ignore the SSL configuration options.
This basic configuration does not set up SSL. See Enabling SSL communication.
6. Configure a listening port.
Non-Secure Port: Select 80 that is the default port for HTTP.
Secure Port: This is the HTTPS listening port. This port is unused and cannot be configured until you enable SSL.
7. In Proxy Service List, click New.
8. Specify the following details:

This PDF was generated on July 27, 2025 Page 129 of 2270
 Access Manager 25.2

Field Description

Proxy Service Name A display name for the proxy service.

Published DNS Name The DNS name you want the public to use to access your
site. For this first proxy server, the DNS name must
resolve to Access Gateway IP address that you selected
as the listening address. For example, in Basic
configuration, this name would be www.mytest.com.

Web Server IP Address The IP address of your web server. This is the web server
with content that you want to share with authorized users
and protect from others. In Basic configuration, this is
Server 4, whose IP address is 10.15.70.21.

Host Header The name you want to send in the HTTP header to the
web server. This can either be the published DNS Name
(the Forward Received Host Name option) or the DNS
name of the web Server (Web Server Host Name).

Web Server Host Name The DNS name that Access Gateway must forward to the
web server. This option is not available if you select
Forward Received Host Name for the Host Header
option. The name you use depends upon how you have
set up the web server. If your web server has been
configured to verify that the host name in the header
matches its name, you need to specify that name here. In
Basic configuration, the Web Server Host Name is
mywebserver.com.

9. Click OK.
10. Continue with Configuring a public protected resource.

This PDF was generated on July 27, 2025 Page 130 of 2270
 Access Manager 25.2

1.1.2.5.2. Configuring a public protected resource

The first protected resource in discussed in this configuration is configured to be a public resource. For information about how
to set up authentication for a protected resource, see Configuring Access Gateway for authentication.
1. In Proxy Service List, click [Name of Proxy Service] > Protected Resources.
2. In Protected Resource List, click New, specify a name for the resource, and click OK.
3. In the Contract field, select None.
The Contract field must be set to None. This is makes this resource a public resource.
4. Configure URL Path List.
The default path is /* , which allows access to everything on the web server. Modify this if you need to restrict access to
a specific directory on your web server.
To delete the default path, select the check box next to the path, then click Delete.
To edit a path in the list, click the path, modify it, then click OK.
To add a path, click New, specify the path, then click OK. For example, to allow access to the pages in the public
directory on the web server, specify the following path:

/public/*

5. Click OK.
6. In the Protected Resource List, verify that the protected resource you created is enabled, then click OK.
7. On the Home page, click Access Gateways.
8. Click Update > OK.
The system sends configuration changes to the server and writes the configuration to the configuration data store. When
the update has completed successfully, the server returns the status of Current.
To save the changes to the configuration store without applying them, do not click Update. Instead, click Edit. If you have
pending configuration settings, the OK button is active, and the configuration page indicates which services will be
updated. Click OK to save these changes to the configuration store. The changes are not applied until you Update on
Access Gateways page.
9. To update Identity Server to establish the trust relationship with Access Gateway, on the Home page, click Identity
Servers and click Update All for that cluster
Wait until the Command status is Complete and the Health status is green.
10. (Optional) To test this configuration from a client browser, specify the published DNS name as the URL in the browser. In
the example illustrated in Basic configuration, specify the following URL:

http://www.mytest.com

This must resolve to the published DNS name you specified in Step 8, and the user must be connected to the web server
through Access Gateway.
11. Continue with Configuring Access Gateway for authentication.

Important
You must not modify the default NAM-Service proxy service.

This PDF was generated on July 27, 2025 Page 131 of 2270
 Access Manager 25.2

1.1.2.5.3. Configuring Access Gateway for authentication

The procedures in Configuring a reverse proxy and Configuring a public protected resource set up Access Gateway to protect
your web server by hiding its IP address and DNS name from Internet users. The procedure does not require the user to log in
before accessing resources on the web server. This configuration consists of two parts:
Verifying time synchronization
Enabling trusted authentication

This PDF was generated on July 27, 2025 Page 132 of 2270
 Access Manager 25.2

1.1.2.5.3.1. Verifying time synchronization

The time must be synchronized between Identity Server and Access Gateway or set so the time difference is within one minute
of each other for trusted authentication to work.
For Identity Server or Access Gateway Service, use YaST to verify the time settings. If you have a Network Time Protocol
server, configure the OpenText Access Manager machines to use it.
For an Access Gateway Appliance, complete the following steps:
1. On the Home page, click Access Gateways > Edit > Date & Time.
2. Select a method you want to use for time:
Set date & time manually: Allows you to select the current time. Click this option to select year, month, day, hour, and
minute in your current time zone, then click OK.
Set up NTP: Allows you to specify the IP address of an NTP server. Click Set Up NTP. Use the public pool.ntp.org server
or click New, then specify the IP address of an NTP server. To accept the configuration, click OK.
If the time on the machine is wrong by more than an hour, use both methods to set the time. Set it manually first, and then
configure it to use NTP.
3. In the Time Zone section, select your time zone, then click OK.
Regardless of the method you used to set the time, you must select a time zone.
4. Click OK.
5. On the Home page, click Access Gateways > Update > OK.
Continue with Enabling trusted authentication.

This PDF was generated on July 27, 2025 Page 133 of 2270
 Access Manager 25.2

1.1.2.5.3.2. Enabling trusted authentication

Trusted authentication requires an authentication contract that specifies the type of authentication credentials. Identity Server
and Access Gateway control these authentication requirements. You do not need to configure your web server to require
authentication. The product enforces the requirements for you.
In this example, you set up an authentication contract that requires a username and a password to access a directory on a web
server.
1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Protected
Resources > New.
2. Specify a display name for the protected resource and click OK.
3. In Authentication Procedure, select one of the following options:
Name/Password - Basic: Basic authentication over HTTP using a standard login page provided by the web browser.
Name/Password - Form: Form-based authentication over HTTP.
Others are available, but for this basic setup, which does not enable SSL, select one of these contracts. The contract
needs to match the protocol.
If these default authentication contracts are not available, you have not configured a relationship between Access
Gateway and Identity Server. See Configuring a reverse proxy and select a value for the Identity Server Cluster
field.
4. In URL Path List, configure the URL path to the page that this authentication contract will protect. For the web server
configuration described in Prerequisites for a basic OpenText Access Manager setup, click the /* path and modify it to
specify the following path:

/protected/*

5. Click OK > OK.

6. On the Home page, click Access Gateways > Update > OK.
7. (Optional) To test this configuration from a client browser, log in to Access Gateway.
1. Specify the published DNS name to this resource in the browser. For example, as per Basic configuration, specify
the following URL:

http://www.mytest.com

2. Click the link to the protected page. This must be a link to the same page you configured in Step 4.
Your browser must prompt you with a login page. If you selected Name/Password - Basic as the contract, the
standard login page issued by your browser is displayed. If you selected Name/Password - Form, the default
product login page is displayed.
3. Log in to Identity Server with a username and password that is stored in your LDAP directory (Server 3 in Basic
configuration).
You must have access to the information you have placed in the protected directory on your web server.
If you have set up your web server to require basic authentication to access this directory, you are prompted again
for login credentials.
If you receive an error, see Common authentication problems.
8. Continue with Setting up policies.

This PDF was generated on July 27, 2025 Page 134 of 2270
 Access Manager 25.2

1.1.2.5.4. Setting up policies

Access Gateway lets you retrieve information from your LDAP directory and inject the information into HTML headers, query
strings, or basic authentication headers. Access Gateway can then send this information to the back-end web servers. This
process is called Identity Injection.
This is one of the features within OpenText Access Manager that enables single sign-on. Users are prompted for the login
credentials for one time, and then the users are supplied with the resources that are configured for Identity Injection.
This section explains how to set up an Identity Injection policy for basic authentication. This policy is assigned to the third
directory on your web server, which is the basic directory that your web server has been configured to require basic
authentication before allowing access.
1. On the Home page, click Access Gateways > Edit > [Reverse Proxy Name] > [Proxy Service Name] > Protected
Resources > New.
2. Configure the resource for the basic directory as described in Prerequisites for a basic OpenText Access Manager
setup.
1. For the contract, select Name/Password - Basic or Name/Password - Form.
2. For the URL path, specify the path to the basic directory ( /basic/* ).
3. Click OK.
3. Click [Protected Resource Name] > Identity Injection.
On a new installation, the list is empty because no policies have been created.
4. In the Identity Injection Policy List section, click Manage Policies.
5. In the Policy List section, click New, then specify the following details:
Name: Specify a name for the Identity Injection policy.
Type: Select Access Gateway: Identity Injection.
6. Click OK.
7. (Optional) Specify a description for the policy.
8. In the Actions section, click New > Inject into Authentication Header.
9. Set up the policy for User Name and Password.
For User Name, select Credential Profile and LDAP Credentials: LDAP User Name.
This injects the value of the cn attribute into the header.
For Password, select Credential Profile and LDAP Credentials: LDAP Password.
The policy must look similar to the following:

10. Click OK > OK > Apply Changes > Close.

11. Select the new Identity Injection policy and click Enable > OK.

This PDF was generated on July 27, 2025 Page 135 of 2270
 Access Manager 25.2

12. On the Homepage, click Access Gateways > Update > OK.
13. To test this configuration from a client browser, specify the published DNS name as the URL in the browser. Click the link
to the page that uses basic authentication.
You are prompted to log in. If you have set up web applications on your web server that require login, any additional login
prompts are hidden from the user and are handled by the identity injection system.

This PDF was generated on July 27, 2025 Page 136 of 2270
 Access Manager 25.2

1.1.2.6. Access Gateways clusters

A cluster of Access Gateways must reside behind a Layer 4 (L4) switch. Clients access the virtual IP on the L4, and the L4
alleviates server load by balancing traffic across the cluster of Access Gateways. Whenever a user enters the URL for an
Access Gateway resource, the request is routed to the L4 switch, and the switch routes the user to one of Access Gateways in
the cluster, as traffic necessitates.
Clustering Access Gateways illustrates the flow of a user request when Access Gateways clusters are behind an L4 switch.

Clustering Access Gateways

1. The user requests access to a protected resource by sending a request to the L4 switch. The request is sent to one of
Access Gateway servers in the cluster.
2. Access Gateway redirects the request to Identity Server for authentication. Identity Server presents the user with a login
page, requesting a user name and a password.
3. Identity Server verifies the user’s credentials with the directory.
4. The validated credentials are sent through the L4 switch to the same Access Gateway that first received the request.
5. Access Gateway verifies the user credentials with Identity Server.
6. If the credentials are valid, Access Gateway forwards the request to the web server.
If Access Gateway where the user's session was established goes down, the user’s request is sent to another Access Gateway
in the cluster. This Access Gateway pulls the user’s session information from Identity Server. This allows the user to continue
accessing resources, without having to re-authenticate.
You must not use a DNS round robin setup instead of an L4 switch for load balancing. The DNS solution works only as long as
all members of the cluster are working and in a good state. If one of them goes down and traffic is still sent to that member, the
entire cluster is compromised and starts generating errors.
The following sections describe how to set up and manage a cluster of Access Gateways:
Prerequisites for configuring an Access Gateways cluster
Designing the membership type for a cluster
Creating a new cluster
Managing Access Gateway servers in the cluster
Managing cluster details
Changing the primary cluster server
Applying changes to Access Gateway cluster members

This PDF was generated on July 27, 2025 Page 137 of 2270
 Access Manager 25.2

1.1.2.6.1. Prerequisites for configuring an Access Gateways

cluster
An L4 switch is installed. You can use the same switch for an Identity Server cluster and an Access Gateway cluster,
provided that you use different virtual IPs.
One or more Access Gateways is installed.
When you install a new Access Gateway, configure it to use the same Administration Console.
Your DNS server must to be configured to resolve the published DNS names that you specify for your proxy services to
the L4 switch.
Persistent (sticky) sessions on the L4 switch is enabled (highly recommended, but not mandatory).

Important
If you have created a configuration for one or more of Access Gateways you are going to put in a cluster, you need
to carefully select the primary cluster server. The current configuration of the primary cluster server is pushed to
the other servers in the cluster. If you have created configurations for the other servers in the cluster, these
configurations are overwritten.

This PDF was generated on July 27, 2025 Page 138 of 2270
 Access Manager 25.2

1.1.2.6.2. Designing the membership type for a cluster

You can create a cluster of all Gateway Appliances or of all Gateway Services.
Creating a cluster of Access Gateways of the same type ensures that the user experience is always the same, regardless of
which Access Gateway the user establishes a connection to. For a list of the differences between Access Gateway Appliance
and Access Gateway Service, see Feature comparison of different types of Access Gateways.

This PDF was generated on July 27, 2025 Page 139 of 2270
 Access Manager 25.2

1.1.2.6.3. Creating a new cluster

1. On the Home page, click Access Gateways > New Cluster.
2. Specify the following details:
cluster name: Specify a display name for the cluster.
Type: Select the type of cluster you want to create: Gateway Appliance or Gateway Service.
Primary Cluster Server: Select the server that is to be the primary server in the cluster. This field is empty until you
have selected one or more servers to be members of the cluster.
3. In the Server Name list, select the servers that you want to be members of the cluster.
You can create a cluster of one and add additional servers later.You cannot create a cluster that contains Access Gateway
Appliances and Access Gateway Services. The cluster can contain only one type of Access Gateway.
Each server you add to the cluster adds about 30 seconds to the time it takes to configure the cluster because
certificates must be synchronized and configuration options must be sent to that server. If you create a very large cluster
of twenty servers, it can take up to ten minutes to configure and create the cluster.
4. Click OK.
5. After the cluster is created, restart each server in the cluster. On the Home page, click Access Gateways page, click
Update All for the cluster.
For information about additional tasks, see Managing cluster details.
6. (Conditional) If Access Gateways in the cluster have multiple network adapters or IP addresses, you need to configure the
listening address for each reverse proxy.
When you create the cluster configuration for newly added servers, the listening address is always the IP address of eth0.
If this is not the address where you want the reverse proxy to listen for requests, on the Home page, click Access
Gateways > Edit > [Name of Reverse Proxy], select Access Gateway as the Cluster Member, then enable the Listening
Address you want to use.
7. To configure the cluster, click Access Gateways > Edit.
A cluster of Access Gateways has the same configuration options as a single Access Gateway. The only difference is that
for some options you need to select Access Gateway to configure. For example, you can set Date & Time separately for
each member of the cluster.
Applying the configuration to a cluster is slightly different. You can apply the changes to all servers in the cluster by
clicking Update All. To apply changes to one server at a time, click Update for each server. When you update the servers
one at time, your site remains up. For more information about Update and Update All, see Status options.
If you prefer to apply changes to the servers one at time, you must save the changes to the configuration datastore on the
Server Configuration page. The OK buttons on the other configuration pages save the changes to the browser cache. If
your session times out before you update all servers in the cluster and the changes have been saved only in the browser
cache, the changes are lost and are not applied to the servers that are still in an Update status.

This PDF was generated on July 27, 2025 Page 140 of 2270
 Access Manager 25.2

1.1.2.6.4. Managing Access Gateway servers in the cluster

To view the servers that are members of clusters:
1. On the Home page, click Access Gateways.
The members of a cluster are listed under the cluster name. The red double dagger symbol identifies the server that is the
primary cluster server.
2. To add a server to a cluster, select the server and click Actions > Assign to Cluster > [Name of Cluster].
A cluster cannot contain both Access Gateway Appliances and Access Gateway Services. The cluster can contain only
one type of Access Gateway.
3. To remove a server from a cluster, select the server and click Actions > Remove from Cluster.
Usually when you delete a server from a cluster, you have discovered that traffic is lighter than anticipated and that it can
be handled with fewer machines while another cluster is experiencing higher traffic and can benefit from having another
cluster member. When the server is removed, its configuration object maintains all the configuration settings from the
cluster. When it is added to a new cluster, its configuration object is updated with the configuration settings of the new
cluster. If your clusters are behind an L4 switch, you need to reconfigure the switch so that the server is assigned to the
correct cluster.
When a server is removed from a cluster, its Embedded Service Provider is stopped. If you are not going to assign it to
another cluster, you need to reconfigure the server so that it is protecting resources other than the ones it protected in the
cluster. When you apply the changes by clicking Update, the Embedded Service Provider is restarted.
You cannot remove the primary cluster server unless it is the only server in the cluster. If you need to remove the primary
cluster server from a multiple server cluster, you need to assign another the server to be the primary cluster server.
4. To modify which server is the primary cluster server, see Changing the primary cluster server.
5. To view detailed information about a server in the group, click the name of the server.
6. To view detailed health information about a server, click the health icon of the server.
7. Click Close.

This PDF was generated on July 27, 2025 Page 141 of 2270
 Access Manager 25.2

1.1.2.6.5. Managing cluster details

You can change the name of the cluster and assign a different server to be the primary cluster member.
1. On the Home page, click Access Gateways > [cluster name] > Edit.
2. Modify the following fields:
Name: Specify a name for the cluster.
Description: Specify the purpose of the cluster. This is optional, but useful if your network has multiple Access Gateway
clusters.
Primary server: Indicates which server in the cluster has been assigned to be the primary server. To change this
assignment, select the server from the list. For more information about this process, see Changing the primary cluster
server.
3. To modify details about a cluster member, click the server name in the Cluster member list.
4. Click OK.

This PDF was generated on July 27, 2025 Page 142 of 2270
 Access Manager 25.2

1.1.2.6.6. Changing the primary cluster server

If the current primary cluster server is down and will be down for an extended period of time, you must select another server to
be the primary cluster server.
1. On the Home page, click Access Gateways > [cluster name]> Edit.
2. In the Primary Server list, select the name of a server, then click OK.
Wait until this configuration change has completed, before doing any other configuration updates.
3. To update Identity Server, on the Home page, click Identity Servers > Update All for that cluster.

This PDF was generated on July 27, 2025 Page 143 of 2270
 Access Manager 25.2

1.1.2.6.7. Applying changes to Access Gateway cluster

members
When you are configuring services of Access Gateway, the OK button saves the change to browser cache except on the
Configuration page. The Configuration page (on the Home page, click Access Gateways > Edit) provides a summary of the
changes you have made. The Cancel Change column allows you to cancel changes to individual services. When you click OK,
the changes are saved to the configuration datastore, and you no longer have the option to cancel changes to individual
services.
If you don’t save the changes to the configuration datastore and your session times out or you log out, any configuration
changes that are saved to browser cache are flushed. These changes cannot be applied to other members of the cluster
because they are no longer available. To prevent this from happening, save the changes to the configuration datastore.
It is especially important to save the changes to the configuration datastore when you select to update individual members one
at a time rather than update all members of the cluster at the same time. Updating members one at a time has the following
benefits:
When you update all servers at the same time, the site goes down until one server has finished updating its configuration.
If you update the cluster members one at a time, only the member that is updating its configuration becomes unavailable.
If you update the servers one at time, you can verify that the changes are behaving as expected. After testing the
configuration on one server, you can then apply the saved changes to the other servers in the cluster. If you decide that
the configuration changes are not behaving as expected, you can revert to the previously applied configuration. See
Reverting to a previous configuration.
Some configuration changes cannot be applied to individual cluster members. For a list of these changes, see Modifications
requiring an update all.

This PDF was generated on July 27, 2025 Page 144 of 2270
 Access Manager 25.2

1.1.2.6.7.1. Reverting to a previous configuration

If you have updated only one server in the cluster, you can use the following procedure to revert back to the previous
configuration.
1. Remove the server that you have applied the configuration changes from the cluster.
2. Access the Configuration page for the cluster, then click Revert.
The servers in the cluster revert to the last applied configuration.
3. Add the removed server to the cluster.
The server is configured to use the same configuration as the other cluster members.

This PDF was generated on July 27, 2025 Page 145 of 2270
 Access Manager 25.2

1.1.2.6.7.2. Modifications requiring an update all

When you make the following configuration changes, the Update All option is the only option available and your site is
unavailable while the update occurs:
If you change Identity Server configuration that is used for authentication (on the Home page, click Access Gateways >
Edit > Reverse Proxy/Authentication), then select a different value for the Identity Servers option.
If you select a different reverse proxy to use for authentication (on the Home page, click Access Gateways > Edit >
Reverse Proxy/Authentication), then select a different value for the Reverse Proxy option.
If you modify the protocol or port of the authenticating reverse proxy (Access Gateways > Edit > Reverse
Proxy/Authentication > [Name of Reverse Proxy], then change the SSL options or the port options).
If you modify the published DNS name of the authentication proxy service (on the Home page, click Access Gateways >
Edit > Reverse Proxy/Authentication > [Name of Reverse Proxy] > [Name of First Proxy Service], then modify the
Published DNS Name option).

This PDF was generated on July 27, 2025 Page 146 of 2270
 Access Manager 25.2

1.1.2.7. Protecting web resources through Access Gateway

Access Gateway is a reverse proxy server (protected site server) that restricts access to web-based content, portals, and web
applications that employ authentication and access control policies. It also provides single sign-on to multiple web servers and
web applications by securely providing the credential information of authenticated users to the protected servers and
applications. Access Gateway lets you simplify, secure, and accelerate your Internet business initiatives.
This section describes the following tasks:
Configuration options
WebSocket support
Managing reverse proxies and authentication
Configuring web servers of a proxy service
Configuring protected resources
Configuring HTML rewriting
Configuring connection and session limits
Protecting multiple resources

This PDF was generated on July 27, 2025 Page 147 of 2270
 Access Manager 25.2

1.1.2.7.1. Configuration options

A typical OpenText Access Manager configuration includes an Identity Server with LDAP directories and an Access Gateway
with a protected web server. Accessing a web resource illustrates the process flow that allows an authorized user to access
the protected resource on the web server.

Accessing a web resource

1. The user requests access to a resource protected by Access Gateway.
2. Access Gateway redirects the user to Identity Server, which prompts the user for a username and password.
3. Identity Server verifies the username and password against an LDAP directory (eDirectory, Active Directory, or Sun ONE).
4. Identity Server returns an authentication success to the browser and the browser forwards the resource request to
Access Gateway.
5. Access Gateway verifies that the user is authenticated and retrieves the user’s credentials from Identity Server.
6. Access Gateway uses an Identity Injection policy to insert the basic authentication credentials in the HTTP header of the
request and sends it to the web server.
7. The web server grants access and sends the requested page to the user.
When you set up Access Gateway to protect web resources, you need to create and configure reverse proxies, proxy services,
and protected resources. The following figure illustrates the hierarchy of these modules and the major configuration tasks you
perform on each module.

Access Gateway modules and their configuration options

This hierarchy allows you to have precise control over what is required to access a particular resource, and also allows you to
provide a single sign-on solution for all the resources protected by Access Gateway. The authentication contract,
authentication procedure, Authorization policy, Identity Injection policy, and Form Fill policy are configured at the resource level
so that you can enable exactly what the resource requires. This allows you to decide where access decisions are made:
You can configure Access Gateway to control access to the resource.
You can configure the web server for access control and configure Access Gateway to supply the required information.
You can use the first method for some resources and the second method for other resources or use both methods on the
same resource.

This PDF was generated on July 27, 2025 Page 148 of 2270
 Access Manager 25.2

1.1.2.7.2. WebSocket support

The WebSocket protocol is an extension to the HTTP 1.1 protocol to enable two-way communication between a client and a
server. It is an independent TCP-based protocol. It has two parts: handshake and data transfer. HTTP servers interpret its
handshake as an upgrade request. By default, it uses port 80 for regular WebSocket connections and port 443 for WebSocket
connections tunneled over Transport Layer Security (TLS).
Workflow:
1. A client sends an HTTP upgrade request to the server through Access Gateway to establish a communication channel
between the client and the server. (WebSocket protocol handshake)
2. The server sends an HTTP 101 response to the requesting client through Access Gateway. When the client receives the
response, the HTTP connection is upgraded to WebSocket.
3. Bidirectional data exchange happens between the server and the client over the WebSocket connection.
4. Any participants in the data exchange can request to terminate the WebSocket connection. When a participant sends a
close request to other, the connection is terminated.
WebSocket enables Access Gateway to accept an HTTP upgrade request from a client.
WebSocket communication illustrates the flow of messages among the client, Access Gateway, and the server in a WebSocket
communication.

WebSocket communication
Scaling websocket
Accessing websocket resources
Verifying a websocket connection

This PDF was generated on July 27, 2025 Page 149 of 2270
 Access Manager 25.2

1.1.2.7.2.1. Scaling websocket

When you deploy Access Gateway for a large scale WebSocket environment and the expected concurrent users accessing the
WebSocket application is more than normal, it is recommended to tune Access Gateway to handle large scale requests.
To tune Access Gateway, edit the following files:
1. httpd-mpm.conf: Modify mpm_worker_module based on the number of expected concurrent users. This tunes the
number of threads of Access Gateway.
2. novell-apache2: To increase the number of open files for apache, increase the value of ulimit . Use the command ulimit
-n [new limit] .
To set a temporary value, run the command using a terminal window. To set a permanent value, make the changes in the
/etc/init.d/novell-apache2 file. If the server uses systemd, then you need to make changes in
/etc/systemd/system/novell-apache2.service .
For example, you can scale WebSocket connections up to 25000 connections by performing the following steps:
1. In the httpd-mpm.conf file, make the following changes to mpm_worker_module :

<IfModule mpm_worker_module>
ThreadLimit 3000
StartServers 9
ServerLimit 10
MaxClients 30000
MinSpareThreads 9000
MaxSpareThreads 9000
ThreadsPerChild 3000
MaxRequestsPerChild 0
</IfModule>

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

2. In the /etc/init.d/novell-apache2 file, set the ulimit value to 8192 by using the command ulimit -n 8192 .

Note
If the server uses systemd, make the required changes under the Service section in the
/etc/systemd/system/novell-apache2.service file.
The following is an example snippet:

[Service]
LimitNOFILE=20000
Type=oneshot
EnvironmentFile=/etc/opt/novell/apache2/conf/.arg_file
Environment="LD_LIBRARY_PATH=/opt/novell/ssllib:/opt/novell/openssl/lib"
ExecStart=/opt/novell/apache2/sbin/httpd $ARGL
ExecStop=/opt/novell/apache2/sbin/httpd -k stop
ExecReload=/opt/novell/apache2/sbin/httpd -k graceful
RemainAfterExit=yes
TasksMax=28000

3. Restart Apache.
If you have modified the /etc/init.d/novell-apache2 file, run the following command:
/etc/init.d/novell-apache2 restart OR systemctl restart novell-apache2.service
If you have modified the /etc/systemd/system/novell-apache2.service file, run the following commands:
systemctl daemon-reload

This PDF was generated on July 27, 2025 Page 150 of 2270
 Access Manager 25.2

systemctl restart novell-apache2.service

For the Docker deployment, perform the following steps:
1. Run the kubectl get pods command to view the OpenText Access Manager pods.
2. Go to the Access Gateway pod by running the kubectl exec --namespace <name-of-the-namespace> -it
pod/<name-of-the-access-gateway-pod> -- sh command.
3. Run the /etc/init.d/novell-mag restart or systemctl restart novell-mag.service command.

This PDF was generated on July 27, 2025 Page 151 of 2270
 Access Manager 25.2

1.1.2.7.2.2. Accessing websocket resources

Most of the modern browsers support WebSocket. You can access and verify the connection by using the developer tools
window.
Perform the following steps to access WebSocket resources:
1. Open a browser, then press F12 to launch Developer Tools.
2. Click Network > WS.
3. Open the link https://< published dns name >/< port > and specify the credentials.

This PDF was generated on July 27, 2025 Page 152 of 2270
 Access Manager 25.2

1.1.2.7.2.3. Verifying a websocket connection

You can verify if a WebSocket connection between a client and its resources is protected through Access Gateway by verifying
the following information in the Developer Tools:
Headers: Displays the initial WebSocket protocol upgrade and the 101 Switching protocols response.
Frames: After upgrading to the WebSocket protocol, Access Gateway establishes a WebSocket connection. After establishing
the connection, data transmission between a client and resources happens through Frames.

This PDF was generated on July 27, 2025 Page 153 of 2270
 Access Manager 25.2

1.1.2.7.3. Managing reverse proxies and authentication

A reverse proxy acts as the front end to your web servers on your Internet or intranet and off-loads frequent requests, thereby
freeing up bandwidth. The proxy also increases security because the IP addresses of your web servers are hidden from the
Internet.
To create a reverse proxy, you must create at least one proxy service with a protected resource. You must supply a name for
each of these components. Reverse proxy names and proxy service names must be unique to Access Gateway because they
are configured for global services such as IP addresses and TCP ports. For example, if you have a reverse proxy named
products and another reverse proxy named library , only one of these reverse proxies can have a proxy service named
corporate .
Protected resource names need to be unique to the proxy service, but they don’t need to be unique to Access Gateway
because they are always accessed through their proxy service. For example, if you have a proxy service named account and
a proxy service named sales , they both can have a protected resource named public .
The first reverse proxy and proxy service you create are automatically assigned to be the authenticating proxy.
1. On the Home page, click Access Gateways > Edit.
2. Click Reverse Proxy / Authentication.
3. Configure the authentication settings:
Identity Server cluster: Specifies Identity Server you want Access Gateway to trust for authentication. Select the
configuration you have assigned to Identity Server.
When an Identity Server is assigned to a new trust relationship, you must restart it. See Step 5 and Step 6.
4. (Conditional) If you have created at least one reverse proxy, you can view the Embedded Service Provider options and
configure some of them.

This PDF was generated on July 27, 2025 Page 154 of 2270
 Access Manager 25.2

Field Description

Reverse Proxy Specifies the proxy service used for authentication. If

you have configured only one proxy service, it is selected
by default. If you change the reverse proxy that is used
for authentication, certificates must be updated to match
this new configuration.

Metadata URL Displays the location of the metadata.

Health-Check URL Displays the location of the health check.

Logout URL Displays the URL that you need to use for logging users
out of protected resources. This value is empty until you
have created at least one reverse proxy and it has been
assigned to be used for authentication. If you create two
or more reverse proxies, you can select which one is
used for authentication, and the logout URL changes to
match the assigned reverse proxy.
If any of your protected resources has a logout page or
button, you need to redirect the user’s logout request to
the page specified by this URL. Access Gateway clears
the user’s session and log the user out of any other
resources that have been enabled for single sign-on. If
you do not redirect the user’s logout request, the user is
logged out of one resource, but the user’s session
remains active until inactivity closes the session. If the
user accesses the resource again before the session is
closed, single sign-on re-authenticates the user to the
resource, and it appears that the logout did nothing.

ESP Global Options Allows you to configure global options for Embedded
Service Provider (ESP). For more information, see
Configuring ESP global options.

Auto-Import Identity Server Configuration Trusted Root Allows you to import the public key from an Identity
Server cluster into the trust store of ESP. This sets up a
trusted SSL relationship between ESP and Identity
Server. This option is not available until you select an
Identity Server Cluster and configure the use of SSL on
ESP the reverse proxy that is performing authentication
(see the Enable SSL with Embedded Service Provider
option on the Reverse Proxy page).
If an Identity Server cluster is using a certificate created
by the OpenText Access Manager certificate authority
(CA), the public key is automatically added to this trust
store, so you do not need to use this option. If the
Identity Server cluster is using a certificate created by an
external CA, use this option to import the public key into
the trust store.

5. (Optional) Configure the proxy settings:

This PDF was generated on July 27, 2025 Page 155 of 2270
 Access Manager 25.2

Behind third party SSL terminator: Enable this option if you have installed an SSL terminator between the users and
Access Gateway. This allows the terminator to handle the SSL traffic between the browsers and the terminator. The
terminator and Access Gateway can use HTTP for their communication. For configuration tips, see Using an SSL
terminator.
Enable via header: Enables the sending of the Via header to the web server. The Via header contains the DNS name of
Access Gateway and a device ID. It has the following format:

Via: 1.1 www.mymag.com (Access Gateway-ag-BFBA9849520DB63B-5)

Deselect this option when your web server does not need this information or does not know what to do with it.
6. (Optional) Configure the cookie settings:
For more information, see Enabling Secure Cookies.
Enable secure cookies: Enabling this option sets secure keyword on HTTPS request. If you have enabled the Behind
Third Party SSL Terminator option and also enabled the Enable Secure Cookies option, the secure keyword on HTTP and
HTTPS requests are set.

Important
Do not enable Enable Secure Cookies if you have both HTTP and HTTPS reverse proxies. The HTTP services
become unavailable because authentication requests to the non-HTTP services fail.

Force HTTP-Only cookie: Forces Access Gateway to set the HttpOnly keyword, which prevent scripts from accessing the
cookie. This helps protect browsers from cross-site scripting vulnerabilities that allow malicious sites to grab cookies
from a vulnerable site. The goal of such attacks might be to perform session fixation or to impersonate the valid user.

Important
The HttpOnly keyword can prevent applets from loading and can interfere with JavaScript. Do not enable this
option if you have Access Gateway protecting applications that download applets or use JavaScript.

7. To create a proxy service, continue with Creating a proxy service.

This PDF was generated on July 27, 2025 Page 156 of 2270
 Access Manager 25.2

1.1.2.7.3.1. Creating a proxy service

1. On the Home page, click Access Gateways > Edit > Reverse Proxy / Authentication.
2. In the Reverse Proxy List, click New, specify a display name for the reverse proxy, then click OK.
3. Enable a listening address.
Cluster member: (Available only if Access Gateway is a member of a cluster.) Select the server you want to configure
from the list of servers. The Listening Address(es) and TCP Listen Options modifications apply to the selected server.
Modifications made to any other options on the page apply to all servers in the cluster.
Listening address(es): Displays a list of available IP addresses. If the server has only one IP address, only one is
displayed and it is automatically selected. If the server has multiple addresses, you can select one or more IP addresses
to enable. You must select at least one address.
If Access Gateway is in a cluster, you must select a listening address for each cluster member.
TCP listen options: Provides options for configuring how requests are handled between the reverse proxy and the client
browsers. You cannot set up the listening options until you create and configure a proxy service. For information about
these options, see Configuring TCP listen options for clients.
4. Configure the listening ports:
Non-Secure Port: Specifies the port on which to listen for HTTP requests; the default port for HTTP is 80. Depending
upon your configuration, this port might also handle other tasks. These tasks are listed to the right of the text box.
Secure Port: Specifies the port on which to listen for HTTPS requests; the default port for HTTPS is 443. For information
about the SSL options, see Enabling SSL communication.
5. In the Proxy Service List section, click New.
The first proxy service of a reverse proxy is considered the master (or parent) proxy. Subsequent proxy services can use
domain-based, path-based, or virtual multi-homing, relative to the published DNS name of the master proxy service. If
you are creating a second proxy service for a reverse proxy, see Using multi-homing to access multiple resources.
6. Specify the following details:
Proxy service name: Specify a display name for the proxy service, which Administration Console uses for its interfaces.
Published DNS name: Specify the DNS name you want the public to use to access your site. This DNS name must resolve
to the IP address you set up as the listening address.
Web server IP address: Specify the IP address of the web server you want this proxy service to manage. You can specify
additional web server IP addresses by clicking the Web Server Addresses link when you have finished creating the proxy
service.
Host header: Specify whether the HTTP header must contain the name of the back-end web server (Web Server Host
Name option) or whether the HTTP header must contain the published DNS name (the Forward Received Host Name
option).
Web server host name: Specify the DNS name of the web server that Access Gateway must forward to the web server. If
you have set up a DNS name for the web server and it requires its DNS name in the HTTP header, specify that name in
this field. If the web server has absolute links referencing its DNS name, include this name in this field. If you selected
Forward Received Host Name, this option is not available.

Note
For iChain administrators, Web Server Host Name is the alternate hostname when configuring a web server
accelerator.

7. Click OK.
8. Continue with Configuring a proxy service or select one of the following tasks:
Create multiple reverse proxies. See Managing multiple reverse proxies.
Create multiple proxy services for a reverse proxy. See Using multi-homing to access multiple resources.

This PDF was generated on July 27, 2025 Page 157 of 2270
 Access Manager 25.2

1.1.2.7.3.2. Configuring a proxy service

A reverse proxy can have multiple proxy services, and each proxy service can protect multiple resources. You can modify the
following features of the proxy service:
Web servers
HTML rewriting
Logging
Protected resources
Caching
To configure a proxy service:
1. On the Home page, click Access Gateways > Edit > [name of the reverse proxy] > [name of the proxy service].
2. Specify the following details:

This PDF was generated on July 27, 2025 Page 158 of 2270
 Access Manager 25.2

Field Description

Published DNS Name Displays the value that users are currently using to
access this proxy service. This name must resolve to the
IP address you set up as a listening address on Access
Gateway. Modify this field only if you have modified the
DNS name you want users to use to access this resource.
This name determines the possible values of the Cookie
Domain.

Description (Optional) Provides a field where you can describe the

purpose of this proxy service or specify any other
pertinent information.

Cookie Domain Specifies the domain for which the cookie is valid.
If one proxy service has a DNS name of
www.support.novell.com and the second proxy service
has a DNS name of www.developernet.novell.com, the
cookie domains are support.novell.com for the first proxy
service and developernet.novell.com for the second
proxy service. You can configure them to share the same
cookie domain by selecting novell.com for each proxy
service. Single sign-on between the proxy services is
simplified when the proxy services share the same
cookie domain.

Enable Advanced Session Assurance Select this option to enable Advanced Session Assurance
at the proxy service level. This configuration works only
when the cluster-level Session Assurance is enabled. For
more information, see Enabling session assurance at the
proxy service resource level.

HTTP Options Allows you to set up custom caching options for this
proxy service. See Controlling browser caching.

Advanced Options Specifies how the proxy service handles specific

conditions, such as web server error pages. If similar
options are configured globally, the proxy service
configuration overwrites the global setting. For
information about the proxy service options, see
Configuring advanced options for a domain-based and
path-based multi-homing proxy service.

3. Click OK to save your changes to browser cache.

4. On the Home page, click Access Gateways.
5. To apply your changes, click Update > OK.
Until this step, nothing has been permanently saved or applied. The Update status pushes the configuration to the server
and writes the configuration to the configuration data store. When the update has completed successfully, the server
returns the status of Current.

This PDF was generated on July 27, 2025 Page 159 of 2270
 Access Manager 25.2

To save the changes to the configuration store without applying them, do not click Update. Instead, click Edit. On the
Configuration page, click OK. The OK button on this pages saves the cached changes to the configuration store. The
changes are not applied until you click Update on Access Gateways page.
6. Update Identity Server to accept the new trusted relationship. On the Home page, click Identity Servers > Update.
7. Continue with one of the following.
If a web server that contains the resources you want to protect does not use the standard HTML port 80, configure
the web server. See Configuring web servers of a proxy service.
Until you configure a protected resource, the proxy service blocks access to all services on the web server. To
configure a protected resource, see Configuring protected resources.

This PDF was generated on July 27, 2025 Page 160 of 2270
 Access Manager 25.2

1.1.2.7.3.3. Modifying the DNS setting for a proxy service

1. Get the SSL certificate for the new DNS name.
For information, see Creating certificates.
2. On the Home page, click Access Gateways.
3. Edit AG-Cluster and click any reverse proxy listed under Reverse Proxy/Authentication.
4. Change the Server Certificate to the new one for your new DNS name.
Ignore any warning displayed about CN name mismatch because the proxy service is not yet updated.
5. Under the Proxy Service List tab, click the proxy which DNS name you want to modify.
6. Change the Published DNS Name for the proxy service.

Note
Changing the published DNS name of the master proxy changes Identity Server’s base URL also.

7. Click OK > OK.

8. Click Network Settings > Hosts > IP address of your system.
9. Add the new DNS name in the list of host names.
10. Click OK.
11. On the Home page, click Access Gateways and click Update All.
12. When Access Gateway Health turns green, check Identity Server Health and ensure that it is green as well.

This PDF was generated on July 27, 2025 Page 161 of 2270
 Access Manager 25.2

1.1.2.7.3.4. Configuring ESP global options

When you configure an ESP global option, it gets applied to all Access Gateway ESPs in an Access Gateway cluster.
By default, these options are disabled. To enable these options, you need to remove the pound (#) symbol before it and set a
value. After you configure an option, you cannot delete it. However, you can disable it again by adding the pound (#) symbol
before it. If you have set a value for an option and want to disable the option, you need to add # before the configured option.
After saving the changes, the value for the option is set to the default value. For example, if you have set the value for
CLUSTER_COOKIE_DOMAIN as CLUSTER_COOKIE_DOMAIN .example.com , add # before CLUSTER_COOKIE_DOMAIN
.example.com. After the changes are applied, the option is set to the default value as #CLUSTER_COOKIE_DOMAIN.
Perform the following steps to configure ESP global options:
1. On the Home page, click Access Gateways > Edit > Reverse Proxy / Authentication > ESP Global Options.
2. To activate an ESP global option, remove the # symbol before it, configure the value, save it, and then update Access
Gateway. By default, seven options are displayed. You can configure any other options also, if required.
The following table lists the default ESP global options:

This PDF was generated on July 27, 2025 Page 162 of 2270
 Access Manager 25.2

ESP Global Option Description

forceESPSLOHTTP Set true to enable the front channel logout for Access
Gateway initiated logout.
The default value is false.
For more information enabling front channel logout for
Access Gateway, see Defining options for liberty identity
provider.

httponlyClusterCookie Set false to disable the HTTPOnly flags for ESP cluster
cookies.
The default value is true.
For example, see Enabling secure or HTTPOnly flags for
cluster cookies.

CACHE_CONTROL_RESPONSE_HEADER_VALUE no- To enable this option, you need to remove the pound (#)
cache,no-store symbol before it and set a value and the server requires you
to Update All. If you have set a value for an option and want
to disable the option, you need to add # before the
configured option and this does not require any update to
the server.
OpenText Access Manager by default sets Cache-Control
header on some URLs. In this scenario, this configuration
will not override the default behavior.

CLUSTER_COOKIE_DOMAIN Set this property to change the Domain attribute for the ESP
custer cookie in this format: CLUSTER_COOKIE_DOMAIN
.example.com

CLUSTER_COOKIE_PATH Set this property to change the Path attribute for the ESP
custer cookie.
The default value is /nesp.

notifysessionTimetoIDP Set false to disable sending session timeout message to the

remote identity provider.
The default value is true.
For example, see Configuring SAML 2.0 session timeout.

RENAME_SESSIONID Set false to prevent changing Access Gateway session ID

automatically.
The default value is true.
For example, see “Preventing Automatically Changing
Session ID” under Securing the Embedded Service Provider
Session Cookie.

This PDF was generated on July 27, 2025 Page 163 of 2270
 Access Manager 25.2

IS_DISPLAY_AUTH_DONE_PAGE Set true to enable Access Gateway to display post-

authentication message.
The default value is false.
For example, see Enabling Access Gateway to display post-
authentication message.

SESSION_ASSURANCE_USER AGENT_EXCLUDE_LIST Specify the user-agent string for that you want to disable
the session validation.
For example, see Disabling session assurance for Access
Gateway ESP.

SESSION_ASSURANCE_USER_AGENT_REGEX_EXCLUDE_LI Specify the user-agent REGEX for that you want to disable
ST the session validation.
For example, see Disabling session assurance for Access
Gateway ESP.

SESSION_ASSURANCE_URL_EXCLUDE_LIST Specify the URL for that you want to disable the session
validation.
For example, see Disabling session assurance for Access
Gateway ESP.

SESSION_ASSURANCE_URL_REGEX_EXCLUDE_LIST Specify the URL REGEX for that you want to disable the
session validation.
For example, see Disabling session assurance for Access
Gateway ESP.

SESSION_ASSURANCE_IDC_COOKIE_GRACEPERIOD Specify the time in second till which Identity Server accepts
the old IDC cookie, after issuing a new cookie. The default
value is 15 second.

USE_DEVICE_ID_IN_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, enable this property to use hashing for
the cookie value.
false: The default setting.
true: Enables this property for both Identity Server and
ESP.
ESP: Enables this property for ESP.
To set up this property only for Identity Server, see “USE
DEVICE ID IN URN COOKIE” in Configuring Identity Server
global properties.

This PDF was generated on July 27, 2025 Page 164 of 2270
 Access Manager 25.2

cacheFetchOauth2TokenInfo Set false to enable the OAuth access token validation used
for authentication of Access Gateway resource. The default
is true.

Note
After configuring an ESP option, you cannot revert it to the previous configuration by clicking Revert in the Cluster
Configuration page (on the Home page, click Access Gateways > Edit > Revert).

This PDF was generated on July 27, 2025 Page 165 of 2270
 Access Manager 25.2

1.1.2.7.4. Configuring web servers of a proxy service

The web server configuration determines how Access Gateway handles connections and packets between itself and the web
servers.

Important
For caching to work correctly, the web servers must be configured to maintain a valid time. They must be
configured to use an NTP server.

1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Web
Servers.
2. Specify the hostname that is placed in the HTTP header of the packets being sent to the web servers. In the Host Header
field, select one of the following:
Forward received host name: Indicates that you want the HTTP header to contain the published DNS name that the
user sent in the request.
Web server host name: Indicates that you want the published DNS name that the user sent in the request to be
replaced by the DNS name of the web server. Use the Web Server Host Name field to specify this name. You can
also append the port number to the Web Server Host Name field. For example, <web server hostname>:<web
server port number>.
3. Select Error on DNS Mismatch to have the proxy determine whether the proxy service must compare the hostname in the
DNS header that came from the browser with the DNS name specified in the Web Server Host Name option. The value in
the parentheses is the value that comes in the header from the browser.
If you enable this option and the names don't match, the request is not forwarded to the web server. Instead, the proxy
service returns an error to the requesting browser. This option is only available when you select to send the Web Server
Host Name in the HTTP header.

Note
The Error on DNS Mismatch option does not work in the following scenarios:
If the option is enabled in a protected resource.
If the option is enabled in a master host based service, and disabled in a path-based child services, then
Access Gateway does a strict check of DNS match for path-based child.

4. If your browsers are capable of sending HTTP 1.1 requests, configure the following fields to match your web servers:
Enable force HTTP 1.0 to origin: Indicates whether HTTP 1.1 requests from browsers are translated to HTTP 1.0 requests
before sending them to the web server. If your browsers are sending HTTP 1.1 requests and your web server can only
handle HTTP 1.0 requests, you must enable this option.
When the option is enabled, Access Gateway translates an HTTP 1.1 request to an HTTP 1.0 request.
Enable session stickiness: Selecting this option makes the proxy server to use the same web server for all fills during a
session.
5. To enable SSL connections between the proxy service and its web servers, select Connect Using SSL. For configuration
information for this option, Web Server Trusted Root, and SSL Mutual Certificate, see Configuring SSL between the
proxy service and the web servers.
6. In Connect Port, specify the port that Access Gateway must use to communicate with the web servers. The following
table lists default port values for common types of web servers:

This PDF was generated on July 27, 2025 Page 166 of 2270
 Access Manager 25.2

Server Type Non-Secure Port Secure Port

Web server with HTML content 80 443

WebSphere 9080 9443

JBoss 8080 8443

7. To control how idle and unresponsive web server connections are handled and to optimize these processes for your
network, select TCP Connect Options. For more information, see Configuring TCP connect options for web servers.
8. To add a web server, click New in the Web Server List and specify the IP address or the fully qualified DNS name of the
web server.
The web servers added to this list must contain identical web content. Configuring your system with multiple servers with
the same content adds fault tolerance and increases the speed for processing requests. For more information about this
process, see Configuring web servers.
9. To delete a web server, select the web server, then click Delete.
This deletes the web server from the list so that Access Gateway no longer sends requests to the deleted web server. At
least one web server must remain in the list. You must delete the proxy service to remove the last server in the list.

Note
Do not remove all configured web servers to the cluster if any of the cluster member does not have at least
one web server configured.

10. To save your changes to browser cache, click OK.

11. To apply your changes, on the Home page, click Access Gateways link, then click Update > OK.

This PDF was generated on July 27, 2025 Page 167 of 2270
 Access Manager 25.2

1.1.2.7.5. Configuring protected resources

A protected resource configuration specifies the directory (or directories) on the web server that you want to protect. The
protected resource configuration specifies the authorization procedures and the policies that must be used to enforce
protection. The authentication procedures and the policies (Authorization, Identity Injection, and Form Fill) enable the single
sign-on environment for the user. The type of protection a resource requires depends upon the resource, the web server, and
the conditions you define for the resource.
You can select from the following types of protection:
Authentication procedures: Specifies the type of credentials the user must use to log in (such as name and password or
secure name and password). You can select None for the procedure, which allows the resource to be a public resource, with
no login required.
In addition to selecting the contract, you can also configure how the authentication procedure handles subsequent
authentication requests from an application.
Authorization policy: Specifies the conditions a user must meet to be allowed access to a protected resource. You define the
conditions, and Access Gateway enforces the Authorization policies. For example, you can assign roles to your users, and use
these roles to grant and deny access to resources.
Identity injection policy: Specifies the information that must be injected into the HTTP header. If the web application has been
configured to look for certain fields in the header and the information cannot be found, the web application determines
whether the user is denied access or redirected. The web application defines the requirements for Identity Injection. The
Identity Injection policies allow you to inject the required information into the header.
Form fill policy: Allows you to manage forms that web servers return in response to client requests. Form fill allows you to
prepopulate fields in a form on first login and then securely save the information in the completed form to a secret store for
subsequent logins. The user is prompted to reenter the information only when something changes, such as a password.
These policies allow you to design a custom access policy for each protected resource:
Resources that share the same protection requirements can be configured as a group. You set up the policies, and then
add the URLs of each resource that requires these policies.
A resource that has specialized protection requirements can be set up as a single protected resource. For example, a
page that uses Form Fill is usually set up as a single protected resource.
After configuring a protected resource, you can bookmark it. You cannot bookmark a login page that is used in a federation
setup.
To configure a protected resource:
1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Domain-Based Proxy Service
or Primary Proxy Service] > Protected Resources.
The Resource View of the Protected Resource List is used to create new protected resources or manage existing
protected resources. The Policy View is used to see which policies are being used by multiple protected resources. For
more information about the Policy View, see Assigning a policy to multiple protected resources.
2. Select one of the following actions:
New: To create a new protected resource, click this option and specify a display name for the resource. For configuration
information, see Setting up a protected resource.
Delete: To delete a protected resource, select a protected resource, then click Delete.
Enable: To enable a resource so that Access Gateway protects it, select a protected resource, then click Enable.
Disable: To disable protection for a resource, select a protected resource, then click Disable. After a resource is disabled,
its path no longer has special protection. For example, you can set up a resource that allows access to all pages (for
example /*) and another resource with special protection for a subpath. If you disable the subpath, make sure the security
requirements of the /* resource are sufficient for the subpath.
Also, when a protected resource is disabled, the resource no longer shows up in the Path List for a path-based multi-
homing proxy.
3. Select the name of a protected resource to perform the following tasks:

This PDF was generated on July 27, 2025 Page 168 of 2270
 Access Manager 25.2

Configuring an authentication procedure for non-redirected login

Assigning an authorization policy to a protected resource
Assigning an identity injection policy to a protected resource
Assigning a form fill policy to a protected resource
Assigning a timeout per protected resource

This PDF was generated on July 27, 2025 Page 169 of 2270
 Access Manager 25.2

1.1.2.7.5.1. Setting up a protected resource

1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Protected
Resources.
2. Click the name of an existing resource or click New and specify a display name for the resource.
3. (Optional) Specify a description for the protected resource. You can use it to briefly describe the purpose for protecting
this resource.
4. Select the type of contract to use for the authentication procedure. The contract determines the information a user must
supply for authentication. By default, Administration Console allows you to select from the following contracts and options
when specifying whether a resource requires an authentication contract:
None: If you want to allow public access to the resource and not require an authentication contract, select None.
Any contract: If the user has authenticated, this option allows any contract defined for Identity Server to be valid, or if the
user has not authenticated, it prompts the user to authenticate, using the default contract assigned to Identity Server
configuration.
Name/Password - basic: Specifies basic authentication over HTTP, using a standard login pop-up provided by the web
browser.
Name/Password - form: Specifies a form-based authentication over HTTP or HTTPS, using the OpenText Access
Manager login form.
Secure name/password - basic: Specifies basic authentication over HTTPS, using a standard login pop-up provided by
the web browser.
Secure name/password - form: Specifies a form-based authentication over HTTPS, using the OpenText Access Manager
login form.
The contract also determines the session timeout for inactive connections. If you have some resources that need to time
out quickly to protect sensitive data and other resources that don’t need this kind of protection, you need to configure
contracts for these resources. For more information about this feature, see Assigning a timeout per protected resource.
If no contracts are available, you have not configured a relationship between Access Gateway and Identity Server. See
Managing reverse proxies and authentication.
5. (Conditional) To modify how the authentication procedures are handled for a specific resource and contract, click the Edit
Authentication Procedures icon.
For more information, see Configuring an authentication procedure for non-redirected login.
6. Configure the URL Path.
The default path is /*, which indicates everything on the web server. Modify this if you need to restrict access to a
specific directory on your web server.
If you have multiple directories on your web server that require the same authentication contract and access control, add
each directory as a URL path.
New: To add a path, click New, specify the path, then click OK. For example, to allow access to all the pages in the public
directory on the web server, specify the following path:

/public/*

To allow access to all the files in a directory, but not to the subdirectories and their files, specify the following:

/?

/public/?

The /? allows access to the root directory, but not the subdirectories. The /public/? allows access to the files in the
public directory, but not the subdirectories.

This PDF was generated on July 27, 2025 Page 170 of 2270
 Access Manager 25.2

To allow access to files of a specific type, specify the following:

/public/*.pdf

This allows access to all the files in the public directory that have a PDF extension. Access to other file types and
subdirectories is denied.
To use this protected resource to protect a single page, specify the path and the filename. For example, to protect the
login.html page in the /login directory, specify the following:

/login/login.html

This is the type of URL path you want to specify when you create a Form Fill policy for a protected resource. The URL
Path List normally contains only this one entry. If you have multiple pages that the Form Fill policy applies to, list each one
separately in the list. For optimum speed, you want Access Gateway to be able to quickly identify the page and not search
other pages to see if the policy applies to them.
For more information about how a user’s request is matched to a protected resource, see Understanding URL path
matching.
For information about using a query string, see Using a query string in the URL path.
Modify: To modify a path, click the path link, then modify the URL Path.
Delete: To delete a path, select the path, then click Delete.
7. Click OK.
8. In the Protected Resource List, ensure that the protected resource you created is enabled.
9. (Optional) To add policies for protecting this resource, continue with one of the following:
Assigning an authorization policy to a protected resource
Assigning an identity injection policy to a protected resource
Assigning a form fill policy to a protected resource
Assigning a policy to multiple protected resources
10. To apply your changes, click the Access Gateways link, then click Update > OK.

Workaround if URL rewriting fails

The format and protocols in a WebSocket connection are not visible to OpenText Access Manager and hence it cannot change
the protocols.
Some WebSocket applications dynamically frame the WebSocket URI, such as or from the previous response (other than
HTML) and interrupts the connection. In such cases, rewriting the URL might not function properly.
For example, if you have configured a proxy service that protects the backend WebSocket application as a Path Based Multi-
Homing service and if you have selected the Remove Path on Fill option, the WebSocket application can fail.
Perform the following steps if URL rewriting fails:
1. Create a character profile to replace the path (the path used to frame the next request) in the response with the
configured path appended before.
2. Delete the text/html content-type under the And Document Content-Type Header Is section.
For example, If the path configured in proxy service is /test and Remove Path on Fill is selected, the ws URI will be similar to
In this scenario, you must create a character rewriter profile to Search for the string /socket.io and replace with
/test/socket.io .
In case of request framing from the HTML response, the character profile is not required.

This PDF was generated on July 27, 2025 Page 171 of 2270
 Access Manager 25.2

Note
Content rewriting is not supported after a WebSocket connection is established.

Understanding URL path matching

The URL path determines which protected resource is used for a user request. Suppose you create one protected resource
with the following URL paths:

/*
/test/*
/test/

You create a second protected resource with the following path:

/test/*.php

Users then send the following paths in their access requests:

/test/
/test/1/2/3/file.php
/file.php
/test/file.php
/test/file.php?param1=1234

The first three requests ( /test/ , /test/1/2/3/file.php , and /file.php ) match the first protected resource, and the last two
requests ( /test/file.php and / test/file.php?param1=1234 ) match the second protected resource.
You then add the following URL path to the first protected resource:

/test/?

This URL path in the first protected resource causes all the requests to match the first protected resource, and the second
protected resource is ignored. The ? wildcard, which matches all content in the current directory, takes precedence over the
more specific wildcard (*.php).

Using a query string in the URL path

You can specify a query string in the URL path of a protected resource. For example:
URL path: /test/index.html?test=test
When the requested URL has a query string, Access Gateway searches for a protected resource with a matching URL path and
query string. If it can’t find a match, the request returns a resource not found error.
Access Gateway Appliance allows you to configure the URL matching process so that it ignores the query string in the URL
path. Access Gateway Service does not have this option. If you want the query string ignored, you must remove it from the URL
path of the protected resource.

This PDF was generated on July 27, 2025 Page 172 of 2270
 Access Manager 25.2

1.1.2.7.5.2. Configuring an authentication procedure for non-

redirected login
When a contract is created, it is assigned an authentication procedure that allows the user to be redirected to Identity Server
for authentication. Some applications, such as AJAX and WebDAV applications, do not support redirection for authentication.
You can change the authentication behavior of a contract so that redirection does not occur.
When non-redirected login is enabled, Access Gateway prompts the user to supply basic authentication credentials. The SOAP
backchannel between Access Gateway and Identity Server is used to complete the authentication on the user's behalf rather
than a redirect. The SOAP backchannel is also used for the session renewals.
Non-redirected login has the following restrictions:
Password expiration services: When you modify the authentication procedures to use non-redirected login, you cannot
also use a password expiration service. Even when the Password expiration servlet and Allow user interaction options
are configured, users are not redirected when their passwords are expiring and they are not prompted to change their
passwords.
Locked shared secrets: When non-redirected login is enabled, users are not prompted for their passphrase for locked
shared secrets.
Session limits: Non-redirected login can cause the user to create more than one session with Identity Server because the
SOAP backchannel uses a different process than authentication requests that are directed to Identity Server. Therefore,
do not limit your users to one session. Session limits are set by clicking Home > Identity Servers > [cluster name].
If the contract for non-redirected login is also assigned to protected resources that do not require non-redirected login, you
must create a new authentication procedure for the resource requiring non-redirected login. You can configure multiple
authentication procedures using the same contract.
To configure an authentication procedure:
1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Protected
Resources > [Name of Protected Resource].
2. On the Authentication Procedure line, click the Edit Authentication Procedure icon.
The Authentication Procedure List displays all available contracts, the name of the authentication procedure they are
assigned to, the protected resources that the authentication procedure has been assigned to, and whether the procedure
has been enabled for non-redirected login.
3. Select one of the following actions:
To create an new authentication procedure, click New, specify a name, then click OK. Continue with Step 4.
To modify an existing authentication procedure, click the name of the procedure. Continue with Step 4.
To delete an existing authentication procedure, select the procedure, then click Delete. Continue with Step 7.
If the procedure is used by a resource, it cannot be deleted until it is not being used to protect resources. An
authentication procedure must exist for each contract. If you delete an authentication procedure for a contract
without also deleting the contract, the system automatically re-creates an authentication procedure for the contract.
4. To specify the method for obtaining the credentials, fill in the following fields:
Contract: Select the contract that you want to use for this protected resource. This needs to be a contract that supports
basic authentication credentials such as Name/Password- Basic or Secure Name/Password-Basic. You can also configure
Non-Redirected Login with a Kerberos contract.
Non-Redirected login: Select this option to use the SOAP backchannel to verify the user’s credentials rather than a
redirected request to Identity Server.
Realm: Specify a name that your users can use to identify the site that they are authenticating to. This could be your
company name or the name of the application. The realm is displayed as a heading when the application requests a basic
authentication.
Redirect to Identity Server when no authentication header is provided: The response must provide an authentication
header. If the first request does not contain the authentication header, you can select this option to allow the first request

This PDF was generated on July 27, 2025 Page 173 of 2270
 Access Manager 25.2

to be redirected to Identity Server.

5. Click OK.
6. Select the authentication procedure you created or modified in Step 4.
7. Click OK.
8. On the Homepage, click Access Gateways and update Access Gateway.
For scenarios that use this feature, see Configuring single sign-on to specific applications.

This PDF was generated on July 27, 2025 Page 174 of 2270
 Access Manager 25.2

1.1.2.7.5.3. Assigning an authorization policy to a protected

resource
An authorization policy specifies conditions that a user must meet to access a resource. Access Gateway enforces these
conditions. The policy can specify the criteria a user must meet to allow access or to deny access.
1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Protected
Resources > [Name of Protected Resource] > Authorization.
The Authorization Policy List contains all Access Gateway Authorization policies that have been created on this
Administration Console for the selected policy container.
2. Select one of the following:
To enable an existing policy, select the policy, then click Enable. Continue with Step 4.
To disable an existing policy, select the policy, then click Disable. Continue with Step 4.
To edit an existing policy, click the name of the policy. Remember that policies can be assigned to multiple protected
resources. If you modify the policy, you are also affecting how this policy protects those resources.
When you have completed your policy modifications, continue with Step 4.
To create a new policy, click Manage Policies. On the Policies page, click New, specify a display name, select
Access Gateway: Authorization as the type, then click OK.
After creating the policy, continue with Step 3.
3. To enable the policy, select the policy, then click Enable.
Only the policies that are enabled are applied to this resource. All available Authorization policies are listed. If you use the
same policy for multiple protected resources, use the policy description field to indicate this.
4. Click OK.
5. To apply the changes, on the Home page, click the Access Gateways link, then click Update > OK.

This PDF was generated on July 27, 2025 Page 175 of 2270
 Access Manager 25.2

1.1.2.7.5.4. Assigning an identity injection policy to a protected

resource
The web application defines the requirements for Identity Injection. If a web application has been configured to look for certain
fields in the header and the information cannot be found, the web application determines whether the user is denied access,
granted access, or redirected. Configure an Identity Injection policy to inject the required information into the HTTP header.
1. On the Home page, click Access Gateways > Edit > [Reverse Proxy Name] > [Name of Proxy Service] > Protected
Resources > [Name of Protected Resource] > Identity Injection.
The Identity Injection Policy List contains all the Identity Injection policies that have been created on this Administration
Console for the selected policy container.
2. Select one of the following:
To enable an existing policy, select the policy, then click Enable. Only the policies that are enabled are applied to this
resource. Continue with Step 4.
To disable an existing policy, select the policy, then click Disable. Continue with Step 4.
To edit an existing policy, click the name of the policy. Remember that policies can be assigned to multiple protected
resources.
Continue with Step 4.
To create a new policy, click Manage Policies. On the Policies page, click New, specify a display name, select
Access Gateway: Identity Injection as the type, then click OK.
Continue with Step 3.
3. To enable the policy you just created, select the policy, then click Enable.
Only the policies that are enabled are applied to this resource. If you use the same policy for multiple protected resources,
use the policy description field to indicate this.
4. To save your changes to the browser cache, click OK.
5. To apply your changes, on the Home page, click the Access Gateways link, then click Update > OK.

Important
If you enable an Identity Injection policy for a protected resource that has been assigned to use a contract that
does not prompt the user for a password and the Identity Injection policy injects the user’s password, single sign-
on cannot be enabled because the password is not available. However, you can create a contract that retrieves the
user’s password when the user is not prompted for a password when authenticating.

This PDF was generated on July 27, 2025 Page 176 of 2270
 Access Manager 25.2

1.1.2.7.5.5. Assigning a form fill policy to a protected resource

Some client requests cause the web server to return a form. Sometimes this form contains a request to log in. If you create a
Form Fill policy, you can have Access Gateway fill in the form. When a user first logs in, Access Gateway prepopulates some
fields and prompts the users for the others. Access Gateway securely saves the information, so that on subsequent logins,
Access Gateway can fill in the form. The user is only prompted to fill in the form when something changes, such as a password
expiring.
Form Fill uses two components: the HTML form and the Form Fill policy. The HTML form is created with HTML tags and
consists of form elements such as fields, menus, check boxes, and buttons. The Form Fill policy is created by specifying the
following:
Which information is entered automatically and not displayed to the user.
Which information is displayed so that the user, at least the first time, can enter the information.
What is done with the information (for example, whether it is saved so that the user does not need to enter it when
accessing the form again).
To assign a Form Fill policy to a protected resource:
1. On the Home page, click Access Gateways > Edit > [Reverse Proxy Name] > [Name of Proxy Service] > Protected
Resources > [Name of Protected Resource].
2. Review the entries in the URL Path List.
The URL to which you are assigning a Form Fill policy must be a single HTML page or a few HTML pages. It must not be a
URL that ends in a wildcard (for example, an asterisk) and therefore matches many pages.

Important
When the URL ends in a wildcard, Access Gateway must search each page that matches the URL and check
to see if it contains the form. This adds extra processing overhead for all the pages that match the URL, but
do not contain the form.

3. (Conditional) If the URL is not specific, click the name of the path and modify it.
4. Click Form Fill.
The Form Fill Policy List contains all the Form Fill policies that have been created on this Administration Console for the
selected policy container.
5. Select one of the following:
To enable an existing policy, select the policy, then click Enable. Only the policies that are enabled are applied to this
resource. Continue with Step 7.
To disable an existing policy, select the policy, then click Disable. Continue with Step 7.
To edit an existing policy, click the name of the policy. Remember that policies can be assigned to multiple protected
resources.
When you have finished the policy modifications, continue with Step 7.
To create a new policy, click Manage Policies. On the Policies page, click New, specify a display name, select
Access Gateway: Form Fill as the type, then click OK.
When you have created your new policy, continue with Step 6.
6. To enable the policy you just created, select the policy, then click Enable.
Only the policies that are enabled are applied to this resource. If you use the same policy for multiple protected resources,
use the policy description field to indicate this.
7. To save your changes to the browser cache, click OK.
8. To apply your changes, on the Home page, click the Access Gateways link, then click Update > OK.

This PDF was generated on July 27, 2025 Page 177 of 2270
 Access Manager 25.2

Important
If you enable a Form Fill policy for a protected resource that has been assigned to use a contract that does not
prompt the user for a password and the Form Fill policy contains a field for the user’s password, single sign-on
cannot be enabled because the password is not available. To enable single sign-on, use an Authentication class
that retrieves the user’s password and injects it into the user’s credentials when the user authenticates using a non-
password method such as X.509, RADIUS, smart card, or Kerberos.

This PDF was generated on July 27, 2025 Page 178 of 2270
 Access Manager 25.2

1.1.2.7.5.6. Assigning a timeout per protected resource

If all your resources are using the same contract and you want them all to have the same timeout for inactivity, you set the
Authentication Timeout option on the contract to the required limit and leave the Activity Realm option blank. The user logs
in, and activity by the user on any resource keeps the user’s session active. The user is prompted to reauthenticate only when
the user has no activity on any resources for longer than the authentication timeout value.
If you have some resources that require a shorter timeout than other resources, you need to balance the need for single sign-
on with the timeout requirements:
To strictly enforce a timeout, the resource needs to be assigned to a custom contract.
To preserve single sign-on, resources need to be assigned to the same contract.
The protected resource is assigned to use a contract, and the timeout is assigned to the contract.
The following sections describe configuration scenarios and the user experience that they create.
Scenario 1: If strictly adhering to the timeout value is more important than preserving the session or single sign-on, configure
your resources as follows:
Protected resource 1 (PR1) is configured to use contract 1 (C1), which has been created from method 1 (M1) and placed in
its own activity realm (AR1). For this scenario you set the authentication timeout to 30 minutes.
Protected resource 2 (PR2) is configured to use contract 2 (C2), which has been created from method 2 (M2) and placed
in its own activity realm (AR2). For this scenario, you set the authentication timeout to 15 minutes.
With this scenario, the user is prompted to log in when accessing PR1 and when accessing PR2. Each resource has its own
time line, because each resource belongs to its own activity realm. Login requirements with separate methods and separate
activity realms The figure below illustrates this scenario.

Login requirements with separate methods and separate activity realms

After authenticating to both resources and remaining active on both resources for the first 10 minutes, the sessions remain
active. The user then stays active on PR1 without accessing PR2 for over 15 minutes. The AR1 time line is updated with this
activity. The AR2 time line is not updated. When the user accesses PR2 after more than 15 minutes of inactivity on the AR2 time
line, the user is prompted to authenticate. The user then returns to PR1 after over 20 minutes of inactivity, but AR1 time line
shows activity within the 30-minute timeout. The user is granted access and does not need to log in again to access PR1.
In this scenario, the resources are independent of each other and do not influence each other’s timeout limits.
Scenario 2: If you are willing to allow a resource to influence the timeout of another resource, configure your resources as
follows:
Protected resource 1 (PR1) is configured to use contract 1 (C1), which has been created from method 1 (M1) and placed in
a shared activity realm (shared1). For this scenario you set the authentication timeout to 30 minutes.
Protected resource 2 (PR2) is configured to use contract 2 (C2), which has been created from method 2 (M2) and placed
in a shared activity realm (shared1). For this scenario, you set the authentication timeout to 15 minutes.
With this scenario, the user is prompted to log in when accessing PR1 and when accessing PR2. Activity at either resource
updates the shared1 time line. Login requirements for separate methods with a shared activity realm illustrates this scenario.

Login requirements for separate methods with a shared activity realm

As long as the user is active on PR1, the user’s session to PR2 remains active. After 20 minutes of activity on PR1, the user
returns to PR2. The user is allowed access and does not need to log in because the shared1 time line shows activity within the
last 5 minutes. The user remains active on PR2 for over 30 minutes, then accesses PR1. Again, the shared1 time line shows
activity within the last 5 minutes, so the user is granted access to PR1 without logging in again.

This PDF was generated on July 27, 2025 Page 179 of 2270
 Access Manager 25.2

With this configuration, activity at other resources influences the time limits so that they are not strictly enforced.
Scenario 3: If single sign-on is more important than strictly enforcing a timeout value, OpenText recommends that you
configure all contracts to have the same authentication timeout value.
If you configure your resources as follows, you might not get the behavior you require:
Protected resource 1 (PR1) is configured to use contract 1 (C1), which has been created from method 1 (M1) and placed in
a shared activity realm (shared1). For this scenario you set the authentication timeout to 30 minutes.
Protected resource 2 (PR2) is configured to use contract 2 (C2), which has been created from method 1 (M1) and placed
in a shared activity realm (shared1). For this scenario, you set the authentication timeout to 15 minutes.
Because C1 and C2 are created from the same method (M1), the user does not need to log in twice to access both resources.
Logging in to one resource allows them access to the other resource. Login requirements for shared methods and shared
realms illustrates this scenario.

Login requirements for shared methods and shared realms

The user first logs in to PR2 and is active for 10 minutes. The shared1 time line gets updated with this activity. When the user
requests access to PR1, the user is granted access without being prompted for credentials. The user is then active on PR1 for
over 20 minutes. When the user requests access to PR2, even though the user has been inactive on this resource for over 20
minutes, the user is granted access because the time line shows activity within the last five minutes.
With this configuration, PR2 does not time out as long as the user remains active on PR1. However, when the user goes inactive
on both PR2 and PR1 for over 15 minutes and the user requests access to PR1, the time line shows no activity within the time
limit specified for PR2 and the user is prompted to log in.
Scenario 4: It is not recommended to set different authentication timeouts on contracts and then use the Any contract option
for protected resources. If you want to use the Any contract, then you must set the authentication timeout to the same value on
all contracts. If the timeouts are not the same, you cannot consistently predict what timeouts are being applied to the various
protected resources. For example, the user requests access to a resource that is protected with a contract with a short timeout.
The user logs in, then accesses resources that use the Any contract option. All of these resources are assigned a short
timeout.The user then goes inactive and the session times out. The user then requests access to a resource with a contract
with a long timeout. The user logs in, and after a few minutes, accesses same resources protected with the Any contract
option. These resources are now assigned the long timeout value.

This PDF was generated on July 27, 2025 Page 180 of 2270
 Access Manager 25.2

1.1.2.7.5.7. Assigning a policy to multiple protected resources

If you have created multiple protected resources that need to be protected by the same policy or policies, you can use the
policy view to assign a policy to multiple protected resources. However, the protected resources must belong to the same
proxy service.
1. On the Home page, click Access Gateways > Edit > [Reverse Proxy Name] > [Name of Proxy Service] > Protected
Resources.
2. Select the Policy View.
3. Select the Used By link of the policy you want to assign to multiple resources.
The Policy and Policy Container fields identify the policy. The Protected Resource Policy Usage List displays the
protected resources defined for this proxy service and indicates which resources the policy has been enabled on.
4. To enable the policy for multiple resources, either select them one by one or click Name to select all of them, then click
Enable. To disable a policy for a resource, select the resource, then click Disable.
5. To save your changes to browser cache, click OK.
6. To apply your changes, on the Home page, click the Access Gateways link, then click Update > OK.

This PDF was generated on July 27, 2025 Page 181 of 2270
 Access Manager 25.2

1.1.2.7.6. Configuring HTML rewriting

Access Gateway configurations generally require HTML rewriting because the web servers are not aware that Access Gateway
machine is obfuscating their DNS names. URLs contained in their pages must be checked to ensure that these references
contain the DNS names that the client browser understands. The client browsers are not aware that Access Gateway is
obfuscating the DNS names of the resources they are accessing.
The URL requests coming from the client browsers that use published DNS names must be rewritten to the DNS names that the
web servers expect.

HTML rewriting
Understanding the rewriting process
Specifying DNS names to rewrite
Defining the requirements for the rewriter profile
Configuring the HTML rewriter and profile
Creating or modifying a rewriter profile

This PDF was generated on July 27, 2025 Page 182 of 2270
 Access Manager 25.2

1.1.2.7.6.1. Understanding the rewriting process

Access Gateway rewrites the URL references under the following conditions:
To ensure that URL references contain the proper scheme (HTTP or HTTPS).
If your web servers and Access Gateway machines are behind a secure firewall, you might not require SSL sessions
between them, and only require SSL between the client browser and Access Gateway. For example, an HTML file being
accessed through Access Gateway for the website example.com might have a URL reference to
http://example.com/path/image1.jpg . If the reverse proxy for example.com/path is using SSL sessions between the
browser and Access Gateway, the URL reference http://example.com/path/image1.jpg must be rewritten to
https://example.com/path/image1.jpg . Else, when the user clicks the HTTP link, the browser must change from HTTP to
HTTPS and establish a new SSL session.
To ensure that URL references containing private IP addresses or private DNS names are changed to the published DNS
name of Access Gateway or hosts.
For example, suppose that a company has an internal website named data.com , and wants to expose this site to Internet
users through Access Gateway by using a published DNS name of example.com . Many of the HTML pages of this
website have URL references that contain the private DNS name, such as http://data.com/imagel.jpg . Because Internet
users are unable to resolve data.com/imagel.jpg , links using this URL reference would return DNS errors in the browser.
The HTML rewriter can resolve this issue. The DNS name field in Access Gateway configuration is set to example.com ,
which users can resolve through a public DNS server to Access Gateway. The rewriter parses the web page, and any URL
references matching the private DNS name or private IP address listed in the web server address field of Access Gateway
configuration are rewritten to the published DNS name example.com and the port number of Access Gateway.
Rewriting URL references addresses two issues: 1) URL references that are unreachable because of the use of private
DNS names or IP addresses are now made accessible and 2) prevents the exposure of private IP addresses and DNS
names that might be sensitive information.
To ensure that the Host header in incoming HTTP packets contains the name understood by the internal web server.
Using the example in HTML rewriting, suppose that the internal web server expects all HTTP or HTTPS requests to have
the Host field set to data.com . When users send requests using the published DNS name example.com/path , the Host
field of the packets in those requests received by Access Gateway is set to example.com . Access Gateway can be
configured to rewrite this public name to the private name expected by the web server by setting the Web Server Host
Name option to data.com . Before Access Gateway forwards packets to the web server, the Host field is changed
(rewritten) from example.com to data.com . For more information, see Configuring web servers of a proxy service.
By default, Access Gateway performs the following actions when the hyperlinks in a page include published DNS name
references:
The rewriter tries to match the scheme, domain, and port of the hyperlink with the scheme, domain, and port in the
available proxy services.
If the entries are matched and the exact path match is found, then no rewriting happens.
If no exact path match is found, then the path is appended with the Remove Path on Fill option enabled.
If the scheme, domain, and port of the hyperlink do not match with the scheme, domain, and port in the available proxy
services, the rewriting does not happen.
If the published DNS name is used as a reference, then the hyperlink URLs are rewritten. To avoid rewriting the links, set the
NAGGlobalOptions NAGDisableExternalRewrite option to on.
The rewriter searches for URLs in the following HTML contexts. They must meet the following criteria to be rewritten:

This PDF was generated on July 27, 2025 Page 183 of 2270
 Access Manager 25.2

Context Criteria

HTTP Headers Qualified URL references occurring within certain types of

HTTP response headers such as Location and Content-
Location are rewritten. The Location header is used to
redirect the browser to where the resource can be found.
The Content-Location header is used to provide an
alternate location where the resource can be found.

JavaScript Within JavaScript, absolute references are always evaluated

for rewriting. Relative references (such as index.html) are
not attempted. Absolute paths (such as /docs/file.html ) are
evaluated if the page is read from a path-based multi-
homing web server and the reference follows an HTML tag.
For example, the string href='/docs/file.html' is rewritten if
/docs is a multi-homing path that is configured to be
removed.

HTML Tags URL references within the following HTML tag attributes are
evaluated for rewriting:

action archive
background
cite code
codebase
data dynscr
filterLink
href longdesc
lowsrc
o:WebQuerySourceHref onclick
onmenuclick
pluginspage src
usemap
usermapborderimage

References An absolute reference is a reference that has all the

information needed to locate a resource, including the
hostname, such as http://internal.web.site.com/index.html .
The rewriter always attempts to rewrite absolute references.
The rewriter attempts to rewrite an absolute path when it is
the multi-homing path of a path-based multi-homing
service. For example, /docs/file1.html is rewritten if /docs
is a multi-homing path that has been configured to be
removed.
Relative references are not rewritten.

Query Strings URL references contained within query strings can be

configured for rewriting by enabling Rewrite Inbound Query
String Data.

Post Data URL references specified in Post Data can be configured for
rewriting by enabling Rewrite Inbound Post Data.

This PDF was generated on July 27, 2025 Page 184 of 2270
 Access Manager 25.2

1.1.2.7.6.2. Specifying DNS names to rewrite

The rewriter parses and searches the web content that passes through Access Gateway for URL references that qualify to be
rewritten. URL references are rewritten when they meet the following conditions:
URL references containing DNS names or IP addresses matching those in the web server address list are rewritten with
the Published DNS Name.
URL references matching Web Server Host Name are rewritten with the Published DNS Name.
URL references matching entries in the Additional DNS Name List of the host are rewritten with the Published DNS
Name. The Web Server Host Name does not need to be included in this list.
DNS names in Exclude DNS Name List specify the names the rewriter must skip and not rewrite.

Important
Excludes in the Exclude DNS Name List are processed first, then the includes in the Additional DNS Name List. If
you put the same DNS name in both lists, the DNS name is rewritten.

The following sections describe the conditions to consider when adding DNS names to the lists:
Determining whether you need to specify additional DNS names
Determining whether you need to exclude DNS names from rewriting

Determining whether you need to specify additional DNS names

Sometimes web pages contain URL references to a hostname that does not meet the default criteria for being rewritten. That
is, the URL reference does not match Web Server Host Name or any value (IP address) in Web Server List. If these names are
sent back to the client, they are not resolvable. Rewriting a URLs for web servers illustrates a scenario that requires an entry in
the Additional DNS Name List.

Rewriting a URLs for web servers

The page on the data.com web server contains two links, one to an image on the data.com server and one to an image on
the graphics.com server. The link to the data.com server is automatically rewritten to example.com , when rewriting is
enabled. The link to the image on graphics.com is not rewritten, until you add this URL to the Additional DNS Name List.
When the link is rewritten, the browser knows how to request it, and Access Gateway knows how to resolve it.
You need to include names in this list if your web servers have the following configurations:
If you have a cluster of web servers that are not sharing the same DNS name, you need to add their DNS names to this
list.
If your web server obtains content from another web server, the DNS name for this additional web server needs to be
added to the list.
If the web server listens on one port (for example, 80), and redirects the request to a secure port (for example, 443), the
DNS name needs to be added to the list. The response to the user comes back on https://<DNS_name>:443 . This does

This PDF was generated on July 27, 2025 Page 185 of 2270
 Access Manager 25.2

not match the request that was sent on http://<DNS_name>:80 . If you add the DNS name to the list, the response can be
sent in the format that the user expects.
If an application is written to use a private hostname, add the private hostname to the list. For example, assume that an
application URL reference contains the hostname of home ( http://home/index.html ). This hostname needs to be added
to the Additional DNS Name List.
If you enable Forward Received Host Name on your path-based multi-homing service and your web server is configured
to use a different port, you need to add the DNS name with the port to the Additional DNS Name List.
For example, if the public DNS name of the proxy service is www.myag.com , the path for the path-based multi-homing
service is /sales , and the web server port is 801, the following DNS name needs to be added to the Additional DNS
Name List of the /sales service:

http://www.myag.com:801

When you enter a name in the list, it can use any of the following formats:

DNS_name
host_name
IP_address
scheme://DNS_name
scheme://IP_address
scheme://DNS_name:port
scheme://IP_address:port

For example:

HOME
https://www.backend.com
https://10.10.15.206:444

These entries are not case-sensitive.

Determining whether you need to exclude DNS names from rewriting

If you have two reverse proxies protecting the same web server, the rewriter correctly rewrites the references to the web
server so that browser always uses the same reverse proxy. If the browser requests a resource using example.com.uk , the
response is returned with references to example.com.uk and not example.com.usa .
If you have a third reverse proxy protecting a web server, the rewriting rules can become ambiguous. For example, consider
the configuration illustrated in Excluding URLs.

Excluding URLs
A user accesses data.com through the published DNS name of example.com.mx . The data.com server has references to
product.com. The example.com.mx proxy has two ways to get to the product.com server because this web server has two
published DNS names ( example.com.uk and example.com.usa ). The rewriter can use any of these to rewrite references to
product.com .
If you want all users coming through example.com.mx to use the example.com.usa proxy, you need to block the
rewriting of product.com to example.com.uk . On the HTML Rewriting page of the reverse proxy for example.com.uk ,

This PDF was generated on July 27, 2025 Page 186 of 2270
 Access Manager 25.2

add product.com and any aliases to the Exclude DNS Name List.
If you do not need to know which proxy is returned in the reference, do not add anything to the Exclude DNS Names List.

This PDF was generated on July 27, 2025 Page 187 of 2270
 Access Manager 25.2

1.1.2.7.6.3. Defining the requirements for the rewriter profile

An HTML rewriter profile allows you to customize the rewriting process and specify the profile that is selected to rewrite
content on a page.​​

Types of rewriter profiles

Access Gateway has the following types of profiles:
Default word profile
Custom word profile
Custom character profile
Default word profile
The default Word profile, named default , is not specific to a reverse proxy or its proxy services.
If you enable HTML rewriting and do not define a custom Word profile for the proxy service, the default Word profile is used.
This profile is preconfigured to rewrite Web Server Host Name and any other names listed in Additional DNS Name List. The
preconfigured profile matches all URLs with the following content-types:

text/html text/javascript

text/xml application/javascript

text/css application/x-javascript

When you modify the behavior of a default profile, remember its scope. If the default profile does not match your requirements,
create your own custom Word profile or custom Character profile.
Custom word profile
A Word profile searches for matches on words. For example, “get” matches the word “get” and words that begin with “get”
such as “getaway”. It does not match the “get” in “together” or “beget.”
For information about how strings are replaced in a Word profile, see the following:
String replacement rules for word profiles
Using $path to rewrite paths in JavaScript methods or variables
You must create a custom Word profile when an application requires rewrites of paths in JavaScript. If the application needs
strings replaced or new content-types, these can also be added to the custom profile.
In a custom Word profile, you can also configure the match criteria so that the profile matches specific URLs. For more
information, see Page matching criteria for rewriter profiles.
When you create a custom Word profile, you need to position it before the default profile in the list of profiles. Only one Word
profile is applied per page. The first Word profile that matches the page is applied. Profiles lower in the list are ignored.
Custom character profile
A custom Character profile searches for matches on a specified set of characters. For example, “top” matches the word “top”
and the “top” in “tabletop,” “stopwatch,” and “topic.” If you need to replace strings that require this type of search, you must
create a custom Character profile.
For information about how strings are replaced in a Character profile, see String replacement rules for character profiles.
In a custom Character profile, you can also configure the match criteria so that the profile matches specific URLs. For more
information, see Page matching criteria for rewriter profiles.
After the rewriter finds and applies the Word profile that matches the page, it finds and applies one Character profile. The first
Character profile that matches the page is applied. Character profiles lower in the list are ignored.

This PDF was generated on July 27, 2025 Page 188 of 2270
 Access Manager 25.2

Page matching criteria for rewriter profiles

You specify the following matching criteria for selecting the profile:
The URLs to match
The URLs that cannot match
The content types to match
Use Requested URLs to Search of the profile to set up the matching policy. The first Word profile and the first Character profile
that matches the page is applied. Profiles lower in the list are ignored.
URLs: The URLs specified in the policy must use the following formats:

Sample URL Description

http://www.a.com/content Matches pages only if the requested URL does not contain
a trailing slash.

http://www.a.com/content/ Matches pages only if the requested URL does contain a

trailing slash.

http://www.a.com/content/index.html Matches only this specific file.

http://www.a.com/content/* Matches the requested URL whether it has a trailing slash

and matches all files in the directory.

http://www.a.com/* Matches the proxy service and everything it is protecting.

You can specify two types of URLs. In the If Requested URL Is list, you specify the URLs of the pages you want this profile to
match. In the And Requested URL Is Not list, you specify the URLs you do not want this profile to match. You can use the
asterisk wildcard for a URL in the If Requested URL Is list to match pages you really don’t want this profile to match, then use a
URL in the And Requested URL Is Not list to exclude them from matching.
If a page matches both a URL in the If Requested URL Is list and in the And Requested URL Is Not list, the profile does not
match the page.
For example, you could specify the following URL in the If Requested URL Is list:

http://www.a.com/*

You could then specify the following URL in the And Requested URL Is Not list:

http://www.a.com/content/*

These two entries cause the profile to match all pages on the www.a.com web server except for the pages in the /content
directory and its subdirectories.

Important
If nothing is specified in either of the two lists, the profile skips the URL matching requirements and uses the
content-type to determine if a page matches.

Content-Type: In the And Document Content-Type Is section, you specify the content-types you want this profile to match. To
add a new content-type, click New and specify the name, such as text/dns . Search your web pages for content-types to

This PDF was generated on July 27, 2025 Page 189 of 2270
 Access Manager 25.2

determine if you need to add new types. To add multiple values, enter each value on a separate line.
Regardless of content-types you specify, the page matches the profile if the file extension is html, htm, shtml, jhtml, asp, or
jsp and you have not specified any URL matching criteria.

Possible actions for rewriter profiles

The rewriter action section of the profile determines the actions a rewriter performs when a page matches the profile.
Inbound Actions
Enabling or Disabling Rewriting
Additional Names to Search for URL Strings to Rewrite with Host Name
String Replacement
Inbound actions: A profile might require these options if the proxy service has the following characteristics:
URLs appear in query strings, Post Data, or headers.
The web server uses WebDAV methods.
If your profile needs to match pages from this type of proxy service, you might need to enable the options listed below. They
control the rewriting of query strings, Post Data, and headers from Access Gateway to the web server.
Rewrite inbound query string data: To rewrite the domain and URL in the query string to match the web server
configuration or to remove the path from the query string on a path-based multi-homing proxy with the Remove Path on
Fill option enabled.
Rewrite inbound post data: To rewrite the domain and URL in the Post Data to match the web server configuration or to
remove the path from the Post Data on a path-based multi-homing proxy with the Remove Path on Fill option enabled.
Rewrite inbound headers: To rewrite the following headers:
Call-Back
Destination
If
Notification-Type
Referer
The inbound options are not available for a Character profile.
Enabling or disabling rewriting: The Enable Rewriter Actions option determines whether the rewriter performs any actions:
Select the option to have the rewriter rewrite the references and data on the page.
Leave the option deselected to disable rewriting. This allows you to create a profile for the pages you do not want
rewritten.
Additional names to search for URL strings to rewrite with host name: Use this section to specify the name of the variable,
attribute, or method in which the hostname might appear. These options are not available for a Character profile.
Variable and attribute name to search for is: Use this section to specify the HTML attributes or JavaScript variables that
you want searched for DNS names that needs to be rewritten. For the list of HTML attribute names that are automatically
searched, see HTML Tags. Add the following attributes as needed:
value: This attribute enables the rewriter to search the <param> elements on the HTML page for value attributes
and rewrite the value attributes that are URL strings.
formvalue: This attribute enables the rewriter to search the <form> element on the HTML page for <input> ,
<button> , and <option> elements and rewrite the value attributes that are URL strings. For example, if your multi-
homing path is /test and the form line is <input name="navUrl" type="hidden"
value="/IDM/portal/cn/GuestContainerPage/656gwmail">, this line would be rewritten to the following value before
sending the response to the client:

<input name="navUrl" type="hidden"

value="/test/IDM/portal/cn/GuestContainerPage/656gwmail">

This PDF was generated on July 27, 2025 Page 190 of 2270
 Access Manager 25.2

The formvalue attribute enables rewriting of all URLs in the <input> , <button> , and <option> elements in the
form.
Replacing URLs in java methods: The JavaScript Method to Search for Is list allows you to specify the Java methods to
search to see if their parameters contain a URL string.
String replacement: The Additional Strings to Replace list allows you to search for a string and replace it. The search
boundary (word or character) that you specified when creating the profile is used when searching for the string.
Word profile search and replace actions take precedence over character profile actions.
For the rules and tokens that can be used in the search strings, see the following:
String replacement rules for word profiles
String tokens
String replacement rules for character profiles
For information about how the Additional Strings to Replace list can be used to reduce the number of Java methods you need
to list, see Using $path to rewrite paths in JavaScript methods or variables.

String replacement rules for word profiles

In a Word profile, a string matches all paths that start with the characters in the specified string. For example:

Search String Matches This String Does not’ Match This String

/path /path /mypath

/pathother
/path/other
/path.html

String tokens
On Access Gateway Service, you can use the following special tokens to modify the default matching rules. Access Gateway
Appliance does not support these tokens.
[w] to match one white space character
[ow] to match 0 or more white space characters
[ep] to match a path element in a URL path, excluding words that end in a period
[ew] to match a word element in a URL path, including words that end in a period
[oa] to match one or more alphanumeric characters
White space tokens: You use the [w] and the [ow] tokens to specify where white space might occur in the string. For example:

[ow]my[w]string[w]to[w]replace[ow]

If you don’t know, or don’t care, whether the string has zero or more white characters at the beginning and at the end, use [ow]
to specify this. The [w] specifies exactly one white character.
Path tokens: You use the [ep] and [ew] tokens to match path strings. The [ep] token can be used to match the following types
of paths:

This PDF was generated on July 27, 2025 Page 191 of 2270
 Access Manager 25.2

Search String Matches This String Does not’ Match This String

/path[ep] /path /path.html

/home/path/other /home/pathother

The [ew] token can be used to match the following types of paths:

Search String Matches This String Does not Match This String

/path[ew] /path.html /paths

/home/path

Name tokens: You use the [oa] token to match function or parameter names that have a set string to start the name and end
the name, but the middle part of the name is a computer-generated alphanumeric string. For example, the [oa] token can be
used to match the following types of names:

Search String Matches This String Does not’ Match This String

javaFunction-[oa]( javaFunction-1234a56() javaFunction()

javaFunction-a()

String replacement rules for character profiles

When you configure multiple strings for replacement, the rewriter uses the following rules for determining how characters are
replaced in strings:
String replacement is done as a single pass.
String replacement is not performed recursively. Suppose you have listed the following search and replacement strings:

DOG to be replaced with CAT

A to be replaced with O

All occurrences of the string DOG are replaced with CAT, regardless of whether it is the word DOG or the word DOGMA.
Only one replacement pass occurs. The rewritten CAT is not replaced with COT.
Because string replacement is done in one pass, the string that matches first takes precedence. Suppose you have listed
the following search and replacement strings:

ABC to be replaced with XYZ

BCDEF to be replaced with PQRSTUVWXYZ

If the original string is ABCDEFGH, the replaced string is XYZDEFGH.

If two specified search strings match the data portion, the search string of longer length is used for the replacement
except for the case detailed above. Suppose you have listed the following search and replacement strings:

ABC to be replaced with XYZ

ABCDEF to be replaced with PQRSTUVWXYZ

If the original string is ABCDEFGH, the replaced string is PQRSTUVWXYZGH.

This PDF was generated on July 27, 2025 Page 192 of 2270
 Access Manager 25.2

Using $path to rewrite paths in JavaScript methods or variables

You can use the $path token to rewrite paths on a path-based multi-homing service that has the Remove Path on Fill option
enabled. This token is useful for web applications that require a dedicated web server and are therefore installed in the root
directory of the web server. If you protect this type of application with OpenText Access Manager using a path-based multi-
homing service, your clients access the application with a URL that contains a /path value. The proxy service uses the path to
determine which web server a request is sent to, and the path must be removed from the URL before sending the request to
the web server.
The application responds to the requests. If it uses JavaScript methods or variables to generate paths to resources, these
paths are sent to client without prepending the path for the proxy service. When the client tries to access the resource
specified by the web server path, the proxy service cannot locate the resource because the multi-homing path is missing. The
figure below illustrates this flow with the rewriter adding the multi-homing path in the reply.

Rewriting with a multi-homing path

To ensure that all paths generated by JavaScript are rewritten, you must search the web pages of the application. You can then
either list all the JavaScript methods and variables in the Additional Names to Search for URL Strings to Rewrite with Host
Name section of the rewriter profile, or you can use the $path token in the Additional Strings to Replace section. The $path
token reduces the number of JavaScript methods and variables that you otherwise need to list individually.
To use the $path token, you add a search string and a replace string that uses the token. For example, if the
/prices/pricelist.html page is generated by JavaScript and the multi-homing path for the proxy service is /inner , you would
specify the following strings:

Search String Replacement String

/prices $path/prices

This configuration allows the following paths to be rewritten before the web server sends the information to the browser.

Web Server String Rewritten String for the Browser

/prices/pricelist.html /inner/prices/pricelist.html

/prices /inner/prices

This token can cause strings that should not be changed to be rewritten. If you enable Rewrite Inbound Query String Data,
Rewrite Inbound Post Data, and Rewrite Inbound Header, the rewriter checks these strings and ensures that they contain the
information the web server expects. For example, when these options are enabled, the following paths and domain names are
rewritten when found in query strings, Post Data, Call-Back, Destination, If, Notification-Type, or Referer headers.

This PDF was generated on July 27, 2025 Page 193 of 2270
 Access Manager 25.2

Browser String Rewritten String for the Web Server

/inner/prices/pricelist.html /prices/pricelist.html

/inner/prices /prices

example.com/inner/prices inner.com/prices

This PDF was generated on July 27, 2025 Page 194 of 2270
 Access Manager 25.2

1.1.2.7.6.4. Configuring the HTML rewriter and profile

Configure the HTML rewriter for a proxy service. These values are applied to all web servers that are protected by this proxy
service.
1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > HTML
Rewriting.
The HTML Rewriting page specifies which DNS names are to be rewritten. The HTML Rewriter Profile specifies which
pages to search for DNS names that need to be rewritten.
2. Select Enable HTML Rewriting.
When it is disabled, no rewriting occurs. This option is enabled by default. This option activates the internal HTML
rewriter. This rewriter replaces the name of the web server with the published DNS name when sending data to the
browsers. It replaces the published DNS name with Web Server Host Name when sending data to the web server. It
ensure that the proper scheme (HTTP or HTTPS) is included in the URL. You can configure Access Gateway to use
HTTPS between itself and client browsers and to use HTTP between itself and the web servers.
3. In Additional DNS Name List, click New, specify a DNS that appears on the web pages of your server (for example a DNS
name other than the web server’s DNS name), then click OK.
For more information, see Determining whether you need to specify additional DNS names.
4. In the Exclude DNS Name List section, click New, specify a DNS name that appears on the web pages of your server that
you do not want rewritten, then click OK.
See Determining whether you need to exclude DNS names from rewriting.
5. Use the HTML Rewriter Profile List to configure a profile. Select one of the following actions:
New: To create a profile, click New, specify a name for the profile and select a Word or Character for the Search
Boundary. Continue with Creating or modifying a rewriter profile.
Word: A Word profile searches for matches on words. For example, “get” matches the word “get” and any word
that begins with “get” such as “getaway” but it does not match the “get” in “together” or “beget.”
If you create multiple Word profiles, order is important. The first Word profile that matches the page is applied.
Word profiles lower in the list are ignored.
Character: A Character profile searches for matches on a specified set of characters. For example, “top”
matches the word “top” and the “top” in “tabletop,” “stopwatch,” and “topic.”
To add functionality to the default profile, create a Character profile. It has all the functionality of a Word
profile, except searching for attribute names and Java variables and methods. If you create multiple Character
profiles, order is important. The first Character profile that matches the page is applied. Character profiles
lower in the list are ignored.
Delete: To delete a profile, select the profile, then click Delete.
Enable: To enable a profile, select the profile, then click Enable.
Disable: To disable a profile, select the profile, then click Disable.
Modify: To view or modify the current configuration for a profile, click the name of the profile. Continue with
Creating or modifying a rewriter profile.
The default profile is applied to all pages protected by Access Gateway. It is not specific to a reverse proxy or its
proxy services. If you modify its behavior, remember its scope. Rather than modify the default profile, create your
own custom Word profile and enable it.
6. If you have more than one profile in the HTML Rewriter Profile List, use the up-arrow and down-arrow buttons to order
the profiles.
If you create more than one profile, order becomes important. For example if you want to rewrite all pages with a general
rewriter profile (with a URL such as /* ) and one specific set of pages with another rewriter profile (with a URL such as
/doc/100506/* ), you need to have the specific rewriter profile listed before the general rewriter profile.

This PDF was generated on July 27, 2025 Page 195 of 2270
 Access Manager 25.2

Even if multiple Word or Character profiles are enabled, a maximum of one Word profile and one Character profile is
executed per page. The first Word profile and Character profile in the list that matches a page are executed, and the
others are ignored.
7. Select the profiles you want to use for this protected resource, and click Enable.
The default profile cannot be disabled. However, it is not executed if you have enabled another Word profile that
matches your pages, and this profile comes before the default profile in the list.
8. To save your changes to browser cache, click OK.
9. To apply your changes, on the Home page, click Access Gateways link, then click Update > OK.
10. The cached pages affected by the rewriter changes must be updated on Access Gateway. Do one of the following:
If the changes affect numerous pages, on the Home page, click Access Gateways, select the name of the server,
then click Actions > Purge All Cache.
If the changes affect only a few pages, you can refresh or reload the pages within the browser.

This PDF was generated on July 27, 2025 Page 196 of 2270
 Access Manager 25.2

1.1.2.7.6.5. Creating or modifying a rewriter profile

1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > HTML
Rewriting.
2. Select one of the following:
To create a new profile, click New, specify a name, select a profile type, then click OK.
To modify a profile, click the name of the profile.
3. Use the Requested URLs to Search section to set up a policy for specifying the URLs you want this profile to match.
If requested URL is: Specify the URLs of the pages you want this profile to match. Click New to add a URL to the text box.
To add multiple values, enter each value on a separate line.
And requested URL is not: Specify the URLs of pages that this profile must not match. If a page matches the URL in both
the If Requested URL Is list and And Requested URL Is Not list, the profile does not match the page. Click New to add a
URL to the text box. To add multiple values, enter each value on a separate line.
And document content-type is: Select the content-types you want this profile to match. To add a new content-type, click
New and specify the name such as text/dns . Search your web pages for content-types to determine if you need to add
new types. To add multiple values, enter each value on a separate line.
For more information, see Page matching criteria for rewriter profiles.
4. Use the Actions section to specify the actions the rewriter must perform if the page matches the criteria in the Requested
URLs to Search section.
Rewrite inbound query string data: (Not available for Character profiles) Select this option to rewrite the domain and URL
in the query string to match the web server. To use this option, your proxy service must meet the conditions listed in
Possible actions for rewriter profiles.
Rewrite inbound post data: (Not available for Character profiles) Select this option to rewrite the domain and URL in the
Post Data to match the web server. To use this option, your proxy service must meet the conditions listed in Possible
actions for rewriter profiles.
Rewrite inbound headers: Select this option to rewrite the following headers:
Call-Back
Destination
If
Notification-Type
Referer
Enable rewriter actions: Select this action to enable the rewriter to perform any actions:
Select it to have the rewriter use the profile to rewrite references and data on the page. If this option is not selected,
you cannot configure the action options.
Leave it unselected to disable rewriting. This allows you to create a profile for the pages you do not want rewritten.
5. (Not available for Character profiles) If your pages contain JavaScript, use the Additional Names to Search for URL
Strings to Rewrite with Host Name section to specify JavaScript variables or methods. You can also add HTML attribute
names. (For the list of attribute names that are automatically searched, see HTML Tags.)
Variable or attribute name to search for is: Lists the name of an HTML attribute or JavaScript variable to search to see if
its value contains a URL string. Click New to add a name to the text box. To add multiple values, enter each value on a
separate line.
JavaScript method to search for is: Lists the names of Java methods to search to see if their parameters contain a URL
string. Click New to add a method to the text box. To add multiple values, enter each value on a separate line.
6. Use the Additional Strings to Replace section to specify a string to search for and specify the text it must be replaced
with. The search boundary (word or character) that you specified when creating the profile is used when searching for
the string.
To add a string, click New, and specify the following details:

This PDF was generated on July 27, 2025 Page 197 of 2270
 Access Manager 25.2

Search: Specify the string you want to search for. The profile type controls the matching and replacement rules. For more
information, see one of the following:
String replacement rules for character profiles
String replacement rules for word profiles
Using $path to rewrite paths in JavaScript methods or variables
Replace with: Specify the string you want to use in place of the search string.
7. Click OK.
8. If you have more than one profile in the HTML Rewriter Profile List, use the up-arrow and down-arrow buttons to order
the profiles.
If you create more than one profile, order becomes important. For example if you want to rewrite all pages with a general
rewriter profile (with a URL such as /*) and one specific set of pages with another rewriter profile (with a URL such as
/doc/100506/*), you need to have the specific rewriter profile listed before the general rewriter profile.
Even if multiple Word or Character profiles are enabled, a maximum of one Word profile and one Character profile is
executed per page. The first Word profile and Character profile in the list that matches a page are executed, and the
others are ignored.
9. Select the profiles you want to use for this protected resource and click Enable.
The default profile cannot be disabled. However, it is not executed if you have enabled another Word profile that matches
your pages. This profile comes before the default profile in the list.
10. To save your changes to browser cache, click OK.
11. To apply your changes, on the Home page, click the Access Gateways link, then click Update > OK.
12. The cached pages affected by the rewriter changes must be updated on Access Gateway. Do one of the following:
If the changes affect numerous pages, click Access Gateways, select the name of the server, and click Actions >
Purge All Cache.
If the changes affect only a few pages, refresh or reload the page within the browser.

This PDF was generated on July 27, 2025 Page 198 of 2270
 Access Manager 25.2

1.1.2.7.6.6. Deactivating the rewriter

This PDF was generated on July 27, 2025 Page 199 of 2270
 Access Manager 25.2

1.1.2.7.7. Configuring connection and session limits

Access Gateway establishes connections with clients and with web servers. For most networks, the default values for
unresponsive connections and sessions provide adequate performance, but you can fine-tune the options for your network, its
performance requirements, and your users:
Configuring TCP listen options for clients
Configuring TCP connect options for web servers
Configuring connection and session persistence
Configuring web servers
Authentication time limits for inactivity sessions are configured on the contract and enforced by Identity Server. For
information, see Assigning a timeout per protected resource.

This PDF was generated on July 27, 2025 Page 200 of 2270
 Access Manager 25.2

1.1.2.7.7.1. Configuring TCP listen options for clients

The TCP listen options allow you to control how idle and unresponsive browser connections are handled and to optimize these
processes for your network. For most networks, the default values provide adequate performance. If your network is
congested and slow, you might want to increase some of the limits.
1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] > TCP Listen Options.
2. Select Enable Persistent Connections to allow Access Gateway to establish a persistent HTTP connection between
Access Gateway and the browser. Usually, HTTP connections service only one request and response sequence. A
persistent connection allows multiple requests to be serviced before the connection is closed.
This option is enabled by default.
3. Specify values for the TCP Listen Options:
Keep alive interval: Determines when an idle connection is closed. If no application data is exchanged over a connection
for this amount of time, the connection is closed. This value limits how long an idle persistent connection is kept open.
This setting is a compromise between freeing resources to allow additional inbound connections, and keeping
connections established so that new connections from the same device do not need to be re-established. The value can
be set from 1 to 1440 seconds (24 minutes). The default is 300 seconds.
Data read timeout: Determines when an unresponsive connection is closed. When exchanging data, if an expected
response from the connected device is not received within this amount of time, the connection is closed. This value might
need to be increased for slow or congested network links. The value can be set from 1 to 3600 seconds (1 hour). The
default is 120 seconds.

Note
WebSocket connection implements ping pong communication for continuous connectivity. If your application
supports WebSocket but ping pong communication is not implemented, it is recommended to set the value to
3600 seconds to avoid frequent disconnection. If a connection is idle for more than the value specified in
Data Read Timeout, it is terminated.

4. To configure the encryption key, select one or more of the following:

Enforce 128-bit encryption between browser and Access Gateway: When this option is selected, Access Gateway
requires all its server connections with client browsers to use 128-bit encryption. If the encryption key is less than 128,
regardless of the cipher suite, the connection is denied.
Enforce 128-bit encryption between Access Gateway and web server: When this option is selected, Access Gateway
requires all its client connections to web servers to use 128-bit encryption. If the encryption key is less than 128,
regardless of the cipher suite, the connection is denied.

Note
These SSL listening options appear disabled if you are configuring the tunneling services.

5. To save your changes to browser cache, click OK.

6. To apply your changes, on the Home page, click the Access Gateways link, and click Update > OK.

This PDF was generated on July 27, 2025 Page 201 of 2270
 Access Manager 25.2

1.1.2.7.7.2. Configuring TCP connect options for web servers

Connect options are specific to the group of web servers configured for a proxy service. They allow you to control how idle
and unresponsive web server connections are handled and to optimize these processes for your network. For most networks,
the default values provide adequate performance. If your network is congested and slow, you might want to increase some of
the limits.
1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Web
Servers > TCP Connect Options.
2. Configure the IP address to use when establishing connections with web servers:
Cluster member: (Available only if Access Gateway is a member of a cluster.) Select the server you want to configure
from the list of servers. Only the value of the Make Outbound Connection Using option applies to the selected server.
Make outbound connection using: (Access Gateway Appliance) Specifies which IP address the proxy service must use
when establishing connections with the back-end web servers.
3. Select how the web servers must be contacted when multiple web servers are available. Select one of the following for
the Policy for Multiple Destination IP Addresses option:
Simple failover: Allows the next available web server in the group to be contacted when the first server in the list is
no longer available.
Round robin: Moves in order through the list of web servers, allowing each to service requests before starting at the
beginning of the list for a second group of requests.
The Make Outbound Connection Using and Policy for Multiple Destination IP Addresses options are available only in
Access Gateway Appliance not in Access Gateway Services.
4. Select Enable Persistent Connections to allow Access Gateway to establish a persistent HTTP connection between
Access Gateway and the web server. Usually, HTTP connections service only one request and response sequence. A
persistent connection allows multiple requests to be serviced before the connection is closed.
This option is enabled by default.
5. Specify the following details:
Data read timeout: Determines when an unresponsive connection is closed. When exchanging data, if an expected
response from the connected device is not received within this amount of time, the connection is closed. This value might
need to be increased for slow or congested network links. The value can be set from 1 to 3600 seconds (1 hour). The
default is 120 seconds.

Note
WebSocket connection implements the ping pong communication for continuous connectivity. If your
application supports WebSocket, but ping pong communication is not implemented, it is recommended to set
this value to 3600 seconds to avoid frequent disconnection. If a WebSocket connection is idle for more than
the value specified in Data Read Timeout, it is terminated.

Idle timeout: Determines when an idle connection is closed. If no application data is exchanged over a connection for this
amount of time, the connection is closed. This value limits how long an idle persistent connection is kept open. This
setting is a compromise between freeing resources to allow additional inbound connections, and keeping connections
established so that new connections from the same device do not need to be re-established. The value can be set from 1
to 1800 seconds (30 minutes). The default is 180 seconds (3 minutes).
6. To save your changes to browser cache, click OK.
7. To apply your changes, click the Access Gateways link, then click Update > OK.

This PDF was generated on July 27, 2025 Page 202 of 2270
 Access Manager 25.2

1.1.2.7.7.3. Configuring connection and session persistence

Access Gateway establishes the following connections:
Access Gateway to browser
Access Gateway to web server
Access Gateway connections to the browser and Access Gateway connections to the web server involve setting up a TCP
connection for an HTTP request. HTTP connections usually service only one request and response sequence, and the TCP
connection is opened and closed during the sequence.
A persistent connection allows multiple requests to be serviced before the connection is closed. It saves a significant amount
of processing time. To configure this type of connection, perform the following actions:
Access Gateway to browser: On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] > TCP
Listen Options and select Enable Persistent Connections.
Access Gateway to web server: On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] > [Name
of Proxy Service] > Web Servers > TCP Connect Options and select Enable Persistent Connections.

This PDF was generated on July 27, 2025 Page 203 of 2270
 Access Manager 25.2

1.1.2.7.7.4. Configuring web servers

The web server configuration determines how Access Gateway handles connections and packets between itself and the web
servers. For more information about web Server configuration, see Configuring web servers of a proxy service
1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Web
Servers.
2. The session stickiness provides information about the web server session connection details.
Enable session stickiness: By default this option is selected. This option makes the proxy server to use the same web
server for all fills during a session.
3. If your browsers are capable of sending HTTP 1.1 requests, configure the following field to match your web servers:
Enable force HTTP 1.0 to origin: Indicates whether HTTP 1.1 requests from browsers are translated to HTTP 1.0 requests
before sending them to a web server. If your browsers are sending HTTP 1.1 requests and your web server can only
handle HTTP 1.0 requests, you must enable this option.
When enabled, Access Gateway translates an HTTP 1.1 request to an HTTP 1.0 request.
4. To enable SSL connections between a proxy service and its web servers, select Connect Using SSL. For configuration
information for this option, Web Server Trusted Root, and SSL Mutual Certificate, see Configuring SSL between the
proxy service and the web servers.
5. In Connect Port, specify the port that Access Gateway must use to communicate with the web servers. The following
table lists some default port values for common types of web servers.

Server Type Non-Secure Port Secure Port

Web server with HTML content 80 443

WebSphere 9080 9443

JBoss 8080 8443

6. To control how idle and unresponsive web server connections are handled and to optimize these processes for your
network, select TCP Connect Options. For more information, see Configuring TCP connect options for web servers.
7. To add a web server, click New in the Web Server List and specify the IP address or the fully qualified DNS name of the
web server.
The web servers added to this list must contain identical web content. Configuring your system with multiple servers with
the same content adds fault tolerance and increases the speed for processing requests. For more information, see Setting
up a group of web servers.
New: Click to create a new web server. Specify the web Server IP Address or DNS.
After creating the web server in the list, you can configure it as primary server and prioritize the list of web servers
based on your requirement.
Delete: Click to delete the selected web server.
If you delete a web server, all web servers which are corresponding to the device in the cluster get deleted.
8. For Simple failover policy, the web server list is ordered allowing selection of the primary web server.
The common use case is having the same list of web servers and primary designate in all Gateway Appliances in a
cluster. However, is some scenarios, you might want Gateway Appliances in a cluster to have different configuration for
the above, one of them being locations separated geographically, each hosting Gateway Appliances, as well as some of
the web servers. For such cases, select the individual member from Cluster/Cluster Member, and configure the primary
and other web servers for each.

This PDF was generated on July 27, 2025 Page 204 of 2270
 Access Manager 25.2

Note
When an administrator opts for member change, the administrator cannot change the priority of web servers
from the cluster. Other operations such as add, delete can be performed.

Primary web server: The web server that serves all the requests for this service. Only applicable for simple failover.
Group web servers: The web servers that are added at the cluster level will be common and displayed in all cluster
member groups. For more information, see Configuring web servers at the cluster level and Configuring web servers at
the member level.
9. To save your changes to the browser cache, click OK.
10. To apply your changes, on the Home page, click the Access Gateways link, and click Update > OK.

This PDF was generated on July 27, 2025 Page 205 of 2270
 Access Manager 25.2

1.1.2.7.8. Protecting multiple resources

Hierarchical view of Access Gateway configured objects

In Hierarchical view of Access Gateway configured objects, Access Gateway 1 and Access Gateway 2 have the same
configuration except the reverse proxy listening address. They share the other configuration settings because they are
members of an Access Gateway cluster.

This PDF was generated on July 27, 2025 Page 206 of 2270
 Access Manager 25.2

1.1.2.7.8.1. Using multi-homing to access multiple resources

You can configure an Access Gateway to use one public IP address to protect multiple types of web resources. This is one of
the major benefits of Access Gateway, because it conserves valuable resources such as IP addresses. This feature also makes
an Access Gateway a multi-homing device because it becomes a single endpoint supporting multiple back-end resources.
You can use one or multiple multi-homing methods. Select methods that meet the needs of your network and resources you
are protecting. The first proxy service configured for a reverse proxy is always configured to use the DNS name of Access
Gateway. You can configure subsequent proxy services domain-based multi-homing, path-based multi-homing, or virtual
multi-homing.

Domain-Based multi-homing
Domain-based multi-homing is based on the cookie domain. For example, if you have a cookie domain company.com , you
can prefix hostnames to a cookie domain name. For a test resource, you can prefix test to company.com and have
test.company.com resolve to the IP address of Access Gateway. Access Gateway configuration for the test.company.com
proxy service contains the information for accessing its web servers ( test1.com ).

Using a base domain name with host names

Domain-based multi-homing has the following characteristics If you are using SSL:
Back-end servers can all listen on the same SSL port (the default for HTTPS is 443).
Back-end servers can share the same SSL certificate. Instead of using a specific hostname in the SSL certificate, the
certificate can use a wildcard name such as *.company.com , which matches all the servers.
Before configuring Access Gateway, you need to complete the following:
Create the published DNS names with a common domain name for public access to the back-end resources. For example,
the table below lists three DNS names that use company.com as a common domain name, lists the IP address that these
DNS names resolve to, and the web servers they protect.

Published DNS Name Access Gateway IP Web Server Host Name Web Server IP Address
Address

test.company.com 10.10.195.90:80 test.internal.com 10.10.15.10

sales.company.com 10.10.195.90:80 sales.internal.com 10.10.15.20

apps.company.com 10.10.195.90:80 apps.internal.com 10.10.15.30

This PDF was generated on July 27, 2025 Page 207 of 2270
 Access Manager 25.2

Configure your DNS server to resolve the published DNS names to the IP address of Access Gateway.
Set up the back-end web servers.
Create three proxy services for these published DNS names.
To create a domain-based multi-homing proxy service, see Creating a second proxy service, and select domain-based
for the multi-homing type.

Path-Based multi-homing
Path-based multi-homing uses the same DNS name for all resources, but each resource or resource group must have a unique
path appended to the DNS name. For example, if the DNS name is test.com , append /sales to test.com . When the user
enters www.test.com/sales , Access Gateway resolves the URL to the sales resource group.

Using a domain name with path elements

Path-based multi-homing has the following characteristics:
It is considered to be more secure than domain-based multi-homing, because some security experts consider wildcard
certificates less secure than a certificate with a specific hostname.
Each resource or group of resources must have a unique starting path.
JavaScript applications might not work as designed if they obscure the URL path. Access Gateway needs access to the
URL path, and if it is obscured, the path cannot be resolved to the correct back-end resource.
The protected resources for each path-based child come from the parent proxy service.
The following sections explain how to configure path-based proxy services and your network so that Access Gateway can find
the correct protected resources:
Configuring the remove the path on fill option
Configuring the host header option
Configuring the host header option
Preparing for path-based multi-homing
Configuring the remove the path on fill option
If the path that is part of the published DNS name ( /sales or /apps ) is used to identify a resource but is not part of directory
configuration on the web server, the path needs to be removed from the URL before the request is sent to the web server. For
example, suppose you use the following configuration:

Browser URL Using the Published DNS Name Web Server URL

http://www.test.com/sales http://sales4.internal.com/

This PDF was generated on July 27, 2025 Page 208 of 2270
 Access Manager 25.2

In this case, the path needs to be removed from the URL that Access Gateway sends to the web server. Access Gateway does
not allow you to set up multiple paths to this type of web server, so all pages must have the same authentication requirements.
If the path in the published DNS name is a path on the web server, the path needs to be passed to the web server as part of the
URL. For example, suppose you use the following configuration:

Browser URL Using the Published DNS Name Web Server URL

http://www.test.com/sales http://sales4.internal.com/sales

Because the path component specifies a directory on the web server where the content begins, you need to select to include
the path. Access Gateway then includes the path as part of the URL it sends to the web server. This configuration allows you to
set up multiple paths to the web server, such as
sales/payroll
sales/reports
sales/products
Such a configuration also allows you to set up different authentication and authorization requirements for each path.
Configuring the host header option
When you create path-based proxy services and enable the Remove Path on Fill option, you need to know what types of links
exist on the web servers. For example, you need to know if the sales web servers in Using a domain name with path elements
have links to the app web servers or to the test web servers. If they don’t, you can set the Host Header option to Forward
Received Host Name or to Web Server Host Name. However, if they contain links to each other, you need to set the Host
Header option to Web Server Host Name and specify a DNS name for the web server in the Web Server Host Name option.
Access Gateway needs a method to distinguish between the web servers other than the path, because after the path is
removed, all the web servers in Using a domain name with path elements have the same name: www.test.com .
If you select to use the Forward Received Host Name option for a path-based service, you might also need to add entries to
the Additional DNS Name List for the rewriter. For more information, see Determining whether you need to specify additional
DNS names.
Preparing for path-based multi-homing
Before configuring Access Gateway, you need to complete the following:
Create the published DNS names with paths for public access to the back-end resources. For example, the table below
uses test.com as the domain name. It lists three published DNS names (two with paths), the IP address these names
resolve to, and the web servers that they are going to protect:

Published DNS Name Access Gateway IP Web Server Host Name Web Server IP Address
Address

test.com 10.10.195.90:80 test.internal.com 10.10.15.10

test.com/sales 10.10.195.90:80 sales.internal.com 10.10.15.20

test.com/apps 10.10.195.90:80 apps.internal.com 10.10.15.30

Configure your DNS server to resolve the published DNS names to the IP address of Access Gateway.
Set up the backend web servers. If they have links to each other, set up DNS names for the web servers.
Create one proxy service that uses test.com as its published DNS name and two path-based proxy services.

This PDF was generated on July 27, 2025 Page 209 of 2270
 Access Manager 25.2

To create a path-based multi-homing proxy service, see Creating a second proxy service, and select path-based for the
multi-homing type.

Virtual multi-homing
Virtual multi-homing allows you to use DNS names from different domains (for example test.com and sales.com ). Each of
these domain names must resolve to Access Gateway host.

Using multiple DNS names

Virtual multi-homing cannot be used with SSL. You must use this configuration with resources that need to be protected, but
the information exchanged must be public information that does not need to be secure. For example, you could use this
configuration to protect your web servers that contain the catalog of your shipping products. It isn’t until the user selects to
order a product that you need to switch the user to a secure site.
Whether a client can use one DNS name or multiple DNS names to access Access Gateway depends upon the configuration of
your DNS server. After you have configured your DNS server to allow multiple names to resolve to the same IP address, you are
ready to configure Access Gateway.
To create a virtual multi-homing proxy service, see Creating a second proxy service, and select Virtual for the multi-homing
type.

Creating a second proxy service

1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy].
2. In the Proxy Service List, select New.
3. Specify the following details:
Proxy service name: Specify a display name for the proxy service. For the sales group, you might use sales. For the
group of application servers, you might use apps.
Multi-Homing type: Specify the multi-homing method that Access Gateway must use to identify this proxy service. Select
one of the following:
Domain-Based: Uses the published DNS name ( www.test.com ) with a hostname ( www.newsite.test.com ). For
more information, see Domain-Based multi-homing.
Path-Based: Uses the published DNS name ( www.test.com ) with a path ( www.test.com/path ). For more
information, see Path-Based multi-homing.
Virtual: Uses a unique DNS name ( www.newsite.newcompany.com ). Virtual multi-homing cannot be used with
SSL. For information, see Virtual multi-homing. If you need a unique DNS name and SSL, create a reverse proxy
rather than a proxy service. For information about creating a second reverse proxy, see Managing multiple reverse
proxies.
Published DNS name: Specify the DNS name you want the public to use to access your site. This DNS name must resolve
to the IP address you set up as the listening address. This option is not available when path-based multi-homing is
selected.

This PDF was generated on July 27, 2025 Page 210 of 2270
 Access Manager 25.2

Path: Specify the path to use for this proxy service. This option is available only when path-based multi-homing is
selected.
Web server IP address: Specify the IP address of the web server you want this proxy service to manage.
Host header: Specify whether the HTTP header must contain the name of the back-end web server (Web Server Host
Name option) or whether the HTTP header must contain the published DNS name (the Forward Received Host Name
option).
For a path-based multi-homing service, it is usually best to select the Web Server Host Name option. For more
information, see Configuring the host header option.
Web server host name: Specify the DNS name of the web server that Access Gateway must forward to the web server. If
you have set up a DNS name for the web server and the web server requires its DNS name in the HTTP header, specify
that name in this field. If you selected Forward Received Host Name, this option is not available.
For iChain administrators, the Web Server Host Name is the alternate hostname when configuring a web server
accelerator.
4. Click OK.
5. To continue, select one of the following:
To configure a virtual or domain-based proxy service, see Configuring a proxy service.
To configure a path-based proxy service, see Configuring a path-based multi-homing proxy service.

Configuring a path-based multi-homing proxy service

To configure a path-based proxy service:
1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Path-Based Multi-Homing
Proxy Service].
The following fields display information that must be configured on the parent proxy service (the first proxy service
created for this reverse proxy).
Published DNS name: Displays the value that users are currently using to access this proxy service. This DNS name must
resolve to the IP address you set up as a listening address on Access Gateway.
Cookie domain: Displays the domain for which the cookie is valid. The web server that the user is accessing must be
configured to be part of this domain.
2. Configure the following options:
Description: (Optional) Provide a description of the purpose of this proxy service or specify any other pertinent
information.
HTTP options: Determines how the proxy service handles HTTP headers and caching. For more information, see
Controlling browser caching.
Advanced options: (Access Gateway Service) See Configuring advanced options for a domain-based and path-based
multi-homing proxy service.
3. Configure the path options:
Remove path on fill: Determines whether the multi-homing path is removed from the URL before forwarding it to the web
server. If the path is not a directory at the root of the web server, the path must be removed. If this option is selected, the
path is stripped from the request before the request is sent to the web server.
If you enable this option, this proxy service can protect only one path. If you have configured multiple paths in the Path
List, you cannot enable this option until you have deleted all but one path.
Reinsert path in “set-cookie” header: Determines whether the path is inserted into the Set-Cookie header. This option is
only available if you enable the Remove Path on Fill option.
4. Determine whether you need to create a protected resource for your path.
In the Path List, the path you specified is listed along with the protected resource that best matches its path.

This PDF was generated on July 27, 2025 Page 211 of 2270
 Access Manager 25.2

Access Gateway automatically selects the protected resource that is used with the specified path. It selects the current
protected resource whose URL path most closely matches the specified path.
If you have a protected resource with a URL path of /*, Access Gateway selects that resource unless you have
configured a protected resource that has a URL path that more closely matches the path specified on this page.
If you add a protected resource at a future time and its URL path more closely matches the path specified on this
page, Access Gateway automatically reconfigures to use this new protected resource.
If you disable a protected resource that Access Gateway has assigned to a path-based service, Access Gateway
automatically reconfigures and selects the next protected resource that most closely matches the path specified on
this page.
1. In the Path List section, click the Protected Resource link.
2. Examine the contract, Authorization, Identity Injection, and Form Fill policies assigned to this protected resource to
ensure that they meet the requirements for your path-based service.
3. To return to the Path-Based Multi-Homing page, click the Overview tab, then click OK.
If the protected resource meets your needs, continue with Step 5.
If the protected resource does not meet your needs, you must create a protected resource for the path-based
proxy service. Continue with Step 4.d.
4. Click OK, select the name of the parent proxy service, then click Protected Resources.
5. In the Protected Resource List, click New, specify a name, then click OK.
6. Select an Authentication Procedure.
7. In the URL Path List, specify the path you used when creating the path-based proxy service. For example, if your
path was /apps , specify /apps/* or /apps in the URL Path List.

Important
If you create multiple protected resources that exactly match the path-based multi-homing service,
there is no guarantee that a specific protected resource will be used. For example, if you create
protected resources for both of the paths specified above ( /apps and /apps/* ) and you have a path-
based service with a path of /apps , either of these protected resources could be assigned to this path-
based service in Administration Console or used when access is requested.

8. Make sure the protected resource you created is enabled. If the resource is disabled, it does not appear in the Path
List for the path-based proxy service.
9. (Optional) Enable the policies the path-based proxy service requires. Click Authorization, Identity Injection, or
Form Fill and enable the appropriate policies.
10. Click OK.
5. Click OK.
6. To apply the changes, on the Home page, click the Access Gateways link, then click Update > OK.

This PDF was generated on July 27, 2025 Page 212 of 2270
 Access Manager 25.2

1.1.2.7.8.2. Setting up a group of web servers

You can configure a proxy service to service a “virtual” group of web servers, which adds load balancing and redundancy.
Each web server in the group must contain the same material. When you create the proxy service, you set up the first server by
specifying the URLs you want users to access and the rights the users need for each URL. When you add additional web
servers to the proxy service, these servers automatically inherit everything you have configured for the first web server.

Adding redundant web servers

For this configuration, you use a single reverse proxy and proxy service. To add multiple web servers to a host:
1. On the Home page, click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Web
Servers.
2. In the Web Server List section, click New.
3. Specify the IP address or the fully qualified DNS name of another web server for the “virtual” group, then click OK.
4. Repeat Step2 and Step3 to add additional web servers to the group.
5. Click OK.
6. To apply the changes, on the Home page, click the Access Gateways link, then click Update > OK.
Access Gateway uses the round robin algorithm by default. You can configure it to use the simple failover algorithm.
Simple failover sends all the traffic to the first web server as long as it is available. Traffic is sent to another web server in the
list only when the first web server is no longer available. To configure this option, see Configuring TCP connect options for web
servers.
Connection persistence is enabled by default. This allows Access Gateway to send multiple HTTP requests to the web server
to be serviced before the connection is closed. To configure this option, see Configuring TCP connect options for web servers.
Session stickiness option is used if multiple web Servers are configured for a service. Selecting this option makes the proxy
server to use the same web server for all fills during a session. This option is enabled by default. For more information about
persistent connections, see Configuring connection and session persistence.

Configuring web servers at the cluster level

You can configure web servers at the cluster level and view web servers at the cluster level in the lag-cluster list. You can use
this option when you want to create web servers at the cluster level.
You can sort the web servers in a cluster, add the web servers to it, delete the web servers in it, and prioritize the web server
list.
1. Select the group device from the Cluster list to change the web server ordering.
2. Click New to add a web server to the cluster or cluster member in the web server List.
3. Specify the IP address or the fully qualified DNS name of the web server in the Web Server IP Address or DNS number.
4. Click Delete to delete the web servers at the cluster/cluster member level. The following message is displayed:
If you delete a web server from the cluster, then it will be deleted from all cluster members.
5. Click OK.

Note
If Access Gateway is configured to use Simple Failover, you can prioritize the web server list at the cluster
level and this will reflect the changes in the all the cluster members list. When the web server is configured
from cluster member, order cannot be changed from cluster because the order would be different from each
cluster member.

This PDF was generated on July 27, 2025 Page 213 of 2270
 Access Manager 25.2

Configuring web servers at the member level

You can configure web servers at the member level by adding and deleting web servers. You can move up or down web
servers as the primary web server. You can add a new web server at the cluster member level.
1. Click New and specify Web Server IP Address or DNS number. A confirmation dialog displays the following message”.
The web server addition makes this service's web server configuration as member specific. Henceforth the web server
ordering must be changed from each cluster member”.
2. Click OK.
3. Select the specific web server you want to delete and click Delete.
4. Click OK.
5. If Access Gateway is configured to use Simple Failover, you can move up or down the web servers as primary web
server. To configure Simple Failover, see Configuring TCP connect options for web servers.
When the web server is deleted, a message is displayed as "Web Server Address Changed. All cached content on this Server
must be purged. Purge All Cache? " The system will purge the details of the deleted server. Using the arrow key you can
configure the web servers as primary web server.

Note
The primary web server at the member level is not the same at the cluster level. The web server list sorting will be
different at both cluster and member level.

This PDF was generated on July 27, 2025 Page 214 of 2270
 Access Manager 25.2

1.1.2.7.8.3. Managing multiple reverse proxies

Each reverse proxy must have a unique IP address and port combination. If your Access Gateway has only one IP address, you
must select unique port numbers for each additional reverse proxy that you create. You can configure Access Gateway to use
multiple IP addresses. These addresses can be configured to use the same network interface card, or if you have installed
multiple network cards, you can assign the IP addresses to different cards.
Access Gateway Appliance: To configure IP addresses and network interface cards, see Viewing and modifying adapter
settings.
Access Gateway service: You need to use system utilities to configure network interface cards and new IP addresses.
After they are configured, you can use the New IP option to make them available for Gateway Service configuration. See
Adding a new IP address to Access Gateway.
If you are creating more than one reverse proxy, you must select one to be used for authentication. By default, the first reverse
proxy you create is assigned this task. Depending upon your Access Gateway configuration, you might want to set up one
reverse proxy specifically for handling authentication. The authentication reverse proxy is also used for logout. If you have web
applications that contain logout options, these options need to be redirected to the Logout URL of the authentication proxy.
Managing entries in the reverse proxy list
Changing the authentication proxy service

Managing entries in the reverse proxy list

1. On the Home page, click Access Gateways > Edit > Reverse Proxy / Authentication.
2. In Reverse Proxy List, select one of the following actions:
New: To create a new reverse proxy. For configuration information, see Managing reverse proxies and
authentication.
Reverse proxy names and proxy service names must be unique to Access Gateway. Protected resource names need
to be unique to the proxy service, but they don’t need to be unique to Access Gateway.
Delete: To delete a reverse proxy. To delete all reverse proxies, select the option next to the Name column, then
click Delete.
Enable: To enable a reverse proxy. To enable all reverse proxies, select the option next to the Name column, then
click Enable.
Disable: To disable a reverse proxy. To enable all reverse proxies, select the check option next to the Name column,
then click Disable.
3. Click OK.
4. To apply the changes, on the Home page, click the Access Gateways link, and click Update > OK.

Changing the authentication proxy service

If you have multiple reverse proxies, you can select the reverse proxy that users are redirected to for login and logout.

Important
Changing the reverse proxy that is used for authentication is not a trivial task. For example, if you have customized
the logout options on your web servers to redirect the logout request to the Logout URL of the current
authentication reverse proxy, you need to modify these options to point to a new Logout URL.
If you have set up SSL connections, you need to change your certificate configurations.

To select the reverse proxy to use for authentication:

1. On the Home page, click Access Gateways > Reverse Proxy / Authentication.
2. In the Embedded Service Provider section, select a value for the Reverse Proxy option. This is the reverse proxy that is
used for authentication.

This PDF was generated on July 27, 2025 Page 215 of 2270
 Access Manager 25.2

The screen is refreshed and the Metadata URL, Health-Check URL, and Logout URL are rewritten to use the selected
reverse proxy.
3. (Conditional) If your Access Gateway certificates were generated by a different certificate authority than your Identity
Server certificates, you need to import the trusted root of Identity Server into the trusted root keystore of the Embedded
Service Provider. Click Auto-Import Identity Server Configuration Trusted Root, click OK, specify an alias, click OK, then
click Close.
If you don’t know whether you need to import the trusted root, click the option. If the trusted root is already in the
keystore, the duplicate key is not imported and you are informed of this condition.
4. In the Reverse Proxy List, click the name of the reverse proxy that you have selected for authentication.
5. If you have enabled SSL between the Embedded Service Provider and Identity Server, you need to import the trusted root
of the Embedded Service Provider into the trusted root keystore of Identity Server. Click Auto-Import Embedded Service
Provider Trusted Root, click OK, specify an alias, click OK, then click Close.
If you don’t know whether you need to import the trusted root, click the option. If the trusted root is already in the
keystore, the duplicate key is not imported and you are informed of this condition.
6. If you have enabled SSL between the browser and Access Gateway, you need to configure this reverse proxy for SSL.
Use the Select Certificate icon to browse for the certificate that matches the DNS name of the proxy service or use the
Auto-generate Key option to create a certificate that matches the DNS name of the proxy service.
7. To save your changes to the browser cache, click OK.
8. To apply the changes, click the Access Gateways link, and click Update > OK.
9. (Conditional) For customized web logout pages, update them to use the new Logout URL.

This PDF was generated on July 27, 2025 Page 216 of 2270
 Access Manager 25.2

1.1.2.8. Configuring trusted providers for single sign-on

This section discusses configuring trust so that two user accounts can be associated with each other without the sites
exchanging user data. Topics include:
Understanding the trust model
Configuring general provider settings
Managing trusted providers
Modifying a trusted provider
Communication security
Selecting attributes for a trusted provider
Managing metadata
Configuring user identification methods for federation
Configuring an authentication response for a service provider
Routing to an external identity provider automatically
Using the intersite transfer service

This PDF was generated on July 27, 2025 Page 217 of 2270
 Access Manager 25.2

1.1.2.8.1. Understanding the trust model

Setting up trust involves system administrators agreeing on how to establish a secure method for providing and consuming
authentication assertions between their Identity Servers. An Identity Server is always installed as an identity provider, which is
used to provide authentication to trusted service providers and ESPs. It can also be configured to be a service provider and
trust the authentication of an identity provider.
Identity providers and consumers
Embedded service providers
Configuration overview

This PDF was generated on July 27, 2025 Page 218 of 2270
 Access Manager 25.2

1.1.2.8.1.1. Identity providers and consumers

An Identity Server can be configured as an identity provider, which allows other service providers to trust it for authentication.
It can also be configured as a service provider, which enables Identity Server to consume authentication assertions from
trusted identity providers. Identity Server trust depicts two Identity Servers. Identity Server at the top of the figure is configured
as an identity provider for SAML 2.0 authentication. Identity Server in the middle of the figure is configured as a service
provider, consuming the authentication credentials of the top Identity Server. This second Identity Server is also configured as
an identity provider, providing authentication for the Embedded Service Provider of Access Gateway.

Identity Server trust

As an administrator, you determine whether your server is to be used as the identity provider or service provider in the trust
relationship. You and the trusted partner agree to exchange identity provider metadata, and then you create references to the
trusted partner’s identity provider or service provider in your Identity Server configuration. You can obtain metadata via a URL
or an XML document, then enter it in the system when you create the reference.

This PDF was generated on July 27, 2025 Page 219 of 2270
 Access Manager 25.2

1.1.2.8.1.2. Embedded service providers

In addition to setting up trust with internal or external service providers, you can reference ESPs in your enterprise. An ESP
uses the Liberty protocol and does not require metadata entry, because this exchange happens automatically. The ESP comes
with the product and is embedded in Access Gateways. The ESP facilitates authentication between Identity Server and the
resource protected by the device, as shown in as shown in Embedded service provider.

Embedded service provider

This PDF was generated on July 27, 2025 Page 220 of 2270
 Access Manager 25.2

1.1.2.8.1.3. Configuration overview

The following high-level tasks describe the process required to set up the trust model between an identity provider and a
service provider. Although these tasks assume that both providers are Identity Servers provided with the product, similar tasks
must be performed when one of the providers is a third-party application.
1. Administrators at each company install and configure Identity Server.
For information about installation, see Installing Identity Server.
For information about configuration, see CreatingEditing a cluster configuration.
2. Administrators at each company must import the trusted root certificate of the other Identity Server into the NIDP trust
store.
On the Home page, click Identity Servers > [cluster name] > Security > NIDP Trust Store, then auto import the
certificate. Use the SSL port (8443) even if you haven’t set up the base URL of Identity Server to use HTTPS.
3. Administrators must exchange Identity Server metadata with the trusted partner.
Metadata is generated by Identity Server and can be obtained via a URL or an XML document, then entered in the system
when you create the reference. This step is not applicable if you are referencing an ESP. When you reference an ESP, the
system lists the installed ESPs for you to choose, and no metadata entry is required.
4. Create the reference to the trusted identity provider and the service provider.
This procedure associates the metadata with the new provider. See Creating a trusted service provider.
5. Configure user authentication.
This procedure defines how your Identity Server interacts with the trusted provider during user authentication. The
product comes with default basic authentication settings already enabled.
See Configuring user identification methods for federation.
Additional important steps for enabling authentication between trusted providers include:
Setting up the necessary authentication contracts. See Configuring authentication contracts.
Enabling the profiles that you are using. See Managing web services and profiles.
Select Always Allow Interaction on the Web Service Consumer page. See Configuring the web service consumer.
For information about setting up federation between two OpenText Identity Servers, see What is federated authentication.

This PDF was generated on July 27, 2025 Page 221 of 2270
 Access Manager 25.2

1.1.2.8.2. Configuring general provider settings

The following settings are global. These affect any identity providers or identity consumers (service providers) that Identity
Server has been configured to trust:
Configuring the general identity provider settings
Configuring the general identity consumer settings
Configuring introductions (Class)
Configuring IDP select (Class)
Configuring trust levels (Class)

This PDF was generated on July 27, 2025 Page 222 of 2270
 Access Manager 25.2

1.1.2.8.2.1. Configuring the general identity provider settings

The following settings are applicable for all identity providers that Identity Server has been configured to trust.
1. On the Home page, click Identity Servers > cluster name > Identity Provider.
2. Specify the following details:
Show logged out providers: Displays logged-out providers on the identity provider’s logout confirmation page.
Require signed authentication requests: Specifies that for the SAML 2.0 protocols, authentication requests from service
providers must be signed. When you enable this option for the identity provider, you must also enable the Sign
Authentication Requests option under the Identity Consumer heading on this page for the external trusted service
provider.
Use introductions (Publish authentications): Enables single sign-on from the service provider to the identity provider.
The service provider determines the identity providers that users are already logged into, and then selectively and
automatically asks for authentication from one of the identity providers. Introductions are enabled only between service
and identity providers that have agreed to a circle of trust, which means that they have agreed upon a common domain
name for this purpose.
After authenticating a user, the identity provider accesses a service at the service domain and writes a cookie to the
common part of the service domain, publishing that the authentication has occurred.
Service domain (Local and common): Enables a service provider to access a service at the service domain prior to
authenticating a user. This service reads cookies obtained at this domain and discovers if any identity providers have
provided authentication to the user. The service provider determines whether any of these identity providers can
authenticate a user without credentials. The service domain must resolve to the same IP address as the base URL domain.
For example, if an agreed-upon common domain is xyz.com, the service provider can specify a service domain of
sp.xyz.com, and the identity provider can specify a service domain of idp.xyz.com. For the identity provider, xyz.com is
the common value entered, and idp is the local value.
Port: The port to use for identity provider introductions. Port 8445 for HTTPS is the default and must be opened on your
firewall. If you specify a different port, you must edit the Tomcat server.xml file.
SSL certificate: Displays the Keystore page that you use to locate and replace the test-provider SSL certificate for this
configuration.
Identity Server comes with a test-provider certificate that you must replace for your production environment. This
certificate is used for identity provider introductions. You can replace the test certificate now or after you have configured
Identity Server. You must restart Tomcat whenever you assign an Identity Server to a configuration and whenever you
update a certificate key store. See Managing the keys, certificates, and trust stores.
3. Click Save and update Identity Server.
Configuring a global allowable list of target URLs

Many applications and services require URL redirection, which can cause 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 these configured domains.
1. On the Home page, click Identity Servers > [cluster name] >Identity Provider.
2. Under Allowable Redirection Domains, click 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 *.example.com as a domain allows redirection to all children domain under examle.com including
example.com . The WWW prefix is not required. You can specify the asterisk (*) wildcard only at the lowest level of the
subtree.
For example:
Valid domain name: *.example.com
Invalid domain name: innerweb.*.com .

This PDF was generated on July 27, 2025 Page 223 of 2270
 Access Manager 25.2

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, 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.
SAML2: For idpsend, the target parameter is filtered using this list. This list is not applicable for spsend.

This PDF was generated on July 27, 2025 Page 224 of 2270
 Access Manager 25.2

1.1.2.8.2.2. Configuring the general identity consumer settings

The following settings are applicable for all identity consumers (service providers) that Identity Server has been configured to
trust.
1. On the Home page, click Identity Servers > [cluster name] > Identity Consumer.
2. Specify whether Identity Server can run as an identity consumer.
When Identity Server is configured to run as an identity consumer, Identity Server can receive (consume) authentication
assertions from other identity providers.
Enable identity consumer: Enables this site to function as service provider. This setting is enabled by default.
If this option is disabled, Identity Server cannot trust or consume authentication assertions from other identity providers.
You can create and enable identity providers for the various protocols, but they are not loaded or used until this option is
enabled.
Require signed assertions: Specifies that all SAML assertions received by the service provider are signed by the issuing
SAML authority. The signing authority uses a key pair to sign SAML data sent to this trusted provider.
Sign authentication requests: Specifies that the service provider signs authentication requests sent to an identity
provider when using the SAML 2.0 protocols.
Use introductions (Discover IDP authentications): Enables a service provider to discover whether a user has
authenticated to a trusted identity provider, so the user can use single sign-on without requiring authentication
credentials.
Service domain: The shared, common domain for all providers in the circle of trust. This domain must resolve to the
same IP address as the base URL domain. You must enable the Identity Consumer option to enable this field.
Port: The port to use for identity consumer introductions. Port 8446 for HTTPS is the default and must be opened on
your firewall. If you specify a different port, you must edit the Tomcat server.xml file.

Important
If you enable the Use Introductions option and you want to allow your users to select which identity provider
to use for authentication rather than use single sign-on, you need to configure the Introductions class. See
Configuring introductions (Class).

SSL certificate: Displays the Keystore page that you use to locate and replace the test-consumer SSL certificate for this
configuration.
Identity Server comes with a test-consumer certificate that you must replace for your production environment. This
certificate is used for identity consumer introductions. You can replace the test certificate now or after you have
configured Identity Server. You must restart Tomcat whenever you assign an Identity Server to a configuration and
whenever you update a certificate key store. See Managing the keys, certificates, and trust stores.
3. Click OK, then update Identity Server.

This PDF was generated on July 27, 2025 Page 225 of 2270
 Access Manager 25.2

1.1.2.8.2.3. Configuring introductions (Class)

The Introductions determines whether the user can select an identity provider to trust when Identity Server is acting as a
service provider. The default behavior is for introductions to happen automatically, thus allowing single sign-on. Identity Server
passively checks with the identity providers, one at a time, to see if they can authenticate the service provider. If the identity
provider can authenticate the user and the Introductions class is enabled, the user is presented with one or more cards that
look similar to the following:

The small check mark indicates to the user that this is a possible card. When the user hovers over the card, the description
appears. If the user selects one of these cards, the user is automatically authenticated.
Perform the following steps to configure Introductions:
1. On the Home page, click Identity Servers > [cluster name] >Authentication > Classes > Plus icon.
2. Under General, select Introductions. Click Plus icon.
3. Specify the following details:

Field Description

Class Name The name of the authentication class.

Property Name The name of the property. For example, ShowUser .

Property Value The value of the property. For example, True .

4. Click Save.
5. Return to the Servers page, then update Identity Server.
6. When configuring this class, you must enable the Use Introductions option. Continue with Configuring the general
identity consumer settings.

This PDF was generated on July 27, 2025 Page 226 of 2270
 Access Manager 25.2

1.1.2.8.2.4. Configuring IDP select (Class)

OpenText Access Manager helps your service provider in selecting the identity provider for authenticating a user. You can
accomplish this by configuring the Introductions. This configuration enables users to select an identity provider from a list of
available identity providers. However, when a common domain is not available, the Introductions class might not authenticate.
In such cases, you can configure the IDP Select. When this class is configured, a user can authenticate by using an identity
provider contract from a list of identity providers and save this selection. To save this selection, select the Remember Me
option. Next time onwards, when the user logs in, the user is automatically redirected to the specific identity provider for
authentication. The contract selection is stored in the browser cookie until the cookie expires or someone clears the cookie.

Important
The Remember Me option does not work when running the application in the incognito or private mode.

Perform the following steps to configure IDP Select:

1. On the Home page, click Identity Servers > [cluster name] > Authentication > Classes > Plus icon.
2. Under General, select IDP Select. Click Plus icon.
3. Specify the following details:

Field Description

Class Name The name of the authentication class.

Property Name The name of the property. For example, ShowUser .

Property Value The value of the property. For example, True .

4. Click Save.
5. Continue with creating a method for this class. For configuration information, see Configuring authentication methods.

Important
Do not select the Identifies User option.

6. Create a contract for this class. For configuration information, see Configuring authentication contracts.
7. After the contract is configured, it appears in the list of contracts on the login page.

Important
Do not assign this contract as the default identity provider contract.

This PDF was generated on July 27, 2025 Page 227 of 2270
 Access Manager 25.2

1.1.2.8.2.5. Configuring trust levels (Class)

The Trust Levels allows you to specify an authentication level or rank for class types that do not appear on the Defaults page
and for which you have not defined a contract. The level is used to rank the requested type. Using the authentication level and
the comparison context, Identity Server can determine whether any contracts meet the requirements of the request. If one or
more contracts match the request, the user is presented with the appropriate authentication prompts. For more information and
other configuration options, see Specifying authentication defaults and Specifying authentication types
1. On the Home page, click Identity Servers > [cluster name] >Authentication > Classes > Plus icon.
2. Under General, select Trust Levels. Click Plus icon.
3. Specify the following details:

Field Description

Property Name The name of the property. For example,

SetClassTrustLevels .

Property Value The value of the property. For example, True .

4. For each class type for which you want to set a level, create a property for that class.
1. Set the Property Name to the name of the class. For example, use one of the following:

urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession
urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol

For additional values, see the SAML2 Authentication Context Specifications.

2. Set the Property Value to the security level or rank you want for the class. A level of 2 is higher than a level of 1.
5. Click Save, then update the Identity Server.

This PDF was generated on July 27, 2025 Page 228 of 2270
 Access Manager 25.2

1.1.2.8.3. Managing trusted providers

The procedure for establishing trust between providers begins with obtaining metadata for the trusted provider. If you are
using the Identity Server, protocol-specific metadata is available via a URL.
1. On the Home page, click Identity Servers > Servers > Edit > [Protocol].
For the protocol, select SAML 2.0.
2. Select one of the following actions:
New: Launches the Create Trusted Identity Provider Wizard or the Create Trusted Service Provider Wizard, depending on
your selection. See one of the following for more information:.
Creating a trusted service provider
Creating a trusted identity provider
Delete: Allows you to delete the selected identity or service provider.
Enable: Enables the selected identity or service provider.
Disable: Disables the selected identity or service provider. When a provider is disabled, the server does not load the
definition. The definition is not deleted, and at a future time, the provider can be enabled.

Important
SAML 2.0 defines a logout mechanism whereby the service provider sends a logout command to the trusted
identity provider when a user logs out at a service provider.

This PDF was generated on July 27, 2025 Page 229 of 2270
 Access Manager 25.2

1.1.2.8.3.1. Creating a trusted identity provider

Before you can create a trusted identity provider, you must complete the following tasks:
Imported the trusted root of the provider’s SSL certificate into the NIDP trust store.
Shared the trusted root of the SSL certificate of your Identity Server with the identity provider so that the administrator
can imported it into the identity provider’s trust store.
Obtained the metadata URL from the identity provider, an XML file with the metadata, or the information required for
manual entry.
Shared the metadata URL of your Identity Server with the identity provider or an XML file with the metadata.
Enabled the protocol. On the Home page, click Identity Servers > [cluster name], and verify that the required protocol in
the Enabled Protocols section has been enabled.
To create an identity provider:
1. On the Home page, click Applications > Select a Cluster > New Application > SAML v2.0 Identity Provider.
2. In Name, specify a name by which you want to refer to the provider.
3. Select one of the following sources for the metadata:
Metadata URL: Specify the metadata URL for a trusted provider. The system retrieves protocol metadata using the
specified URL. Examples of metadata URLs for an Identity Server acting as an identity provider with an IP address of
10.1.1.1:
SAML:
http://10.1.1.1:8080/nidp/saml2/metadata
https://10.1.1.1:8443/nidp/saml2/metadata
OIOSAML:
http://10.1.1.1/nidp/saml2/metadata_oiosaml
https://10.1.1.1/nidp/saml2/metadata_oiosaml
The default values nidp and 8080 are established during product installation; nidp is the Tomcat application name. If you
have set up SSL, you can use https and port 8443.
If your Identity Server and Administration Console are on different machines, use HTTP to import the metadata. If you are
required to use HTTPS with this configuration, you must import the trusted root certificate of the provider into the trust
store of Administration Console. You need to use the Java keytool to import the certificate into the cacerts file in the
security directory of Administration Console.
If your Identity Server and Administration Console are on different machines, use HTTP to import the metadata. If you are
required to use HTTPS with this configuration, you must import the trusted root certificate of the provider into the trust
store of Administration Console. You need to use the Java keytool to import the certificate into the cacerts file in the
security directory of Administration Console.
The cacerts file is located in /opt/novell/java/jre/lib/security .
If you do not want to use HTTP and you do not want to import a certificate into Administration Console, you can use the
Metadata Text option. In a browser, enter the HTTP URL of the metadata.
View the text from the source page, save the source metadata, then paste it into the Metadata Text option.
Metadata text: An editable field in which you can paste copied metadata text from an XML document, assuming you
obtained the metadata via e-mail or disk and are not using a URL. If you copy metadata text from a web browser, you
must copy the text from the page source.
Manual entry: Allows you to enter metadata values manually. When you select this option, the system displays the Enter
Metadata Values page.
Metadata repositories: (SAML 2.0) Allows you to configure several identity and/or service providers using a multi-entity
metadata file available in a central repository.

This PDF was generated on July 27, 2025 Page 230 of 2270
 Access Manager 25.2

4. Click Next.
5. Review the metadata certificates, then click OK.
6. Configure an authentication card to use with this identity provider. Fill in the following fields:
Authentication image: Specify the image to be displayed on the card. Select the image from the list. To add an image to
the list, click <Select local image>.
ID: (Optional) Specify an alphanumeric value that identifies the card. If you need to reference this card outside of
Administration Console, you need to specify a value here. If you do not assign a value, Identity Server creates one for its
internal use
Label: Specify the text that is displayed on the card to the user.
Show card: Determine whether the card is shown to the user, which allows the user to select and use the card for
authentication. If this option is not selected, the card is only used when a service provider makes a request for the card.
7. Click Finish. The system displays the trusted provider on the protocol page.
8. Update Identity Server.
The wizard allows you to configure the required options and relies upon the default settings for the other options. For
information about how to configure the default settings and how to configure the other available options, see Modifying a
trusted provider.

This PDF was generated on July 27, 2025 Page 231 of 2270
 Access Manager 25.2

1.1.2.8.3.2. Creating a trusted service provider

You can configure Identity Server to trust a service provider or an identity provider.
When you create a trusted identity provider, you are allowing that identity provider to authenticate the user and Identity
Server acts as a service provider.
When you create a trusted service provider, you are configuring Identity Server to provide authentication for the service
provider and Identity Server acts as an identity provider.
Both of these types of trust relationships require the identity provider to establish a trusted relationship with the service
provider and the service provider to establish a trusted relationship with the identity provider.
The default settings of identity and service providers when you import the metadata repository are as follows:
SAML 2.0 Identity Provider
Persistent Federation as the Name Identifier
Post Binding
No contracts associated to Satisfiable list of IDP
No image selected for the IDP card
No Attribute set associated
SAML 2.0 Service Provider
No contracts associated to Satisfiable list of SP
Post Binding
No Attribute set associated
Prerequisites
Before you can create a trusted provider, you must complete the following tasks:
Imported the trusted root of the provider’s SSL certificate into the NIDP trust store.
Shared the trusted root of the SSL certificate of your Identity Server with the other provider so that the administrator can
imported it into the provider’s trust store.
Obtained the metadata URL from the other provider or an XML file with the metadata.
Shared the metadata URL of your Identity Server with the other provider or sent an XML file with the metadata.
Enabled the protocol. On the Home page, click Identity Servers > [cluster name] and verify that the required protocol in
the Enabled Protocols section has been enabled.
Procedure
1. On the Home page, click Applications > Select a Cluster > New Application > SAML 2.0 Service Provider.

Note
By default, the Provider Type > General is selected. You can configure an Identity Server to trust a service
provider to establish federation with external service providers. For more information about pre-configured
metadata for Google Applications, Microsoft 365, and Salesforce.com, see Federated authentication for
specific providers.

2. Select one of the following sources for the metadata:

URL: Specify the metadata URL for a trusted provider. The system retrieves protocol metadata by using the specified
URL.
Examples of metadata URLs for an Identity Server acting as a trusted provider with an IP address 10.1.1.1:
SAML:

This PDF was generated on July 27, 2025 Page 232 of 2270
 Access Manager 25.2

http://10.1.1.1:8080/nidp/saml2/metadata
https://10.1.1.1:8443/nidp/saml2/metadata
OIOSAML:
http://10.1.1.1/nidp/saml2/metadata_oiosaml
https://10.1.1.1/nidp/saml2/metadata_oiosaml
The default values nidp and 8080 are established during product installation; nidp is the Tomcat application name. If you
have set up SSL, you can use https and port 8443.
If your Identity Server and Administration Console are on different machines, use HTTP to import the metadata. If you are
required to use HTTPS with this configuration, you must import the trusted root certificate of the provider into the trust
store of Administration Console. You need to use the Java keytool to import the certificate into the cacerts file in the
security directory of Administration Console.
/opt/novell/java/jre/lib/security
If you do not want to use HTTP and you do not want to import a certificate into Administration Console, you can use the
Metadata Text option. In a browser, enter the HTTP URL of the metadata. View the text from the source page, save the
source metadata, then paste it into the Text option.
Text: An editable field in which you can paste copied metadata text from an XML document, assuming you obtained the
metadata via e-mail or disk and are not using a URL. If you copy metadata text from a web browser, you must copy the
text from the page source.
Manual entry: Allows you to enter metadata values manually. When you select this option, the system displays the page
to enter the required details.
Repository: Allows you to configure several identity and/or service providers using a multi-entity metadata file available
in a central repository.
3. In the Name option, specify a name by which you want to refer to the provider.
4. Specify the metadata source details based on the selection of Source.
5. (Conditional) If you are specifying the same metadata for a different instance of the same service provider, you will be
prompted for specifying a value in the Unique ID field. For information about unique ID, see Configuring multiple instances
of a SAML 2.0 service provider in an Identity Server cluster.
You can use numbers, alphabets, special characters or combination of all without using spaces. The value of Unique ID
must not be uniqueid or naminstance .
Also, Unique Id has to be unique among all the unique ids present for different SAML 2 service providers in Identity Server
cluster.

Note
Provide Unique Id when the trust relationship is duplicate.

6. Click Next.
7. Review the metadata certificates and click Save or Save & Edit. Clicking Save & Edit directs you to the configuration page.
The system displays the trusted provider on the protocol page.
8. Update Identity Server.
The wizard allows you to configure the required options and relies upon the default settings for the other federation
options. For information about how to configure the default settings and how to configure the other available options, see
Modifying a trusted provider.

This PDF was generated on July 27, 2025 Page 233 of 2270
 Access Manager 25.2

1.1.2.8.4. Modifying a trusted provider

The following sections describe the configuration options available for identity providers and service providers:
You can modify the following features of an identity provider:
Communication security: See Communication security.
Attributes to obtain at authentication: See Configuring the attributes obtained at authentication.
Metadata: See Managing metadata.
Authentication request: See Configuring a SAML 2.0 authentication request and Configuring a liberty authentication
request.
User identification: See Configuring user identification methods for federation.
Authentication card: See Modifying an authentication card for SAML 2.0.
You can modify the following features of a service provider:
Communication security: See Communication security.
Attributes to send in the response: See Configuring the attributes set with authentication.
Intersite transfer service: See Configuring an intersite transfer service target for a service provider.
Metadata: See Managing metadata.
Authentication response: See Configuring an authentication response for a service provider.

This PDF was generated on July 27, 2025 Page 234 of 2270
 Access Manager 25.2

1.1.2.8.5. Communication security

The communication security settings control the direct communication between Identity Server and a trusted provider across
the SOAP backchannel. You can secure this channel with one of three methods:
Message signing: This is the default method, and Identity Server comes with a test signing certificate that is used to sign the
back-channel messages. We recommend replacing this test signing certificate with a certificate from a well-known certificate
authority. This method is secure, but it is CPU intensive. For information about replacing the default certificate, see Managing
the keys, certificates, and trust stores.
Mutual SSL: This method is probably the fastest method, and if you are fine-tuning your system for performance, you must
select this method. However, it requires the exchange of trusted root certificates between Identity Server and the trusted
provider. This exchange of certificates is a requirement for setting up the trust relationship between the two providers. To
verify that you have exchanged certificates, see Managing the keys, certificates, and trust stores.
Basic authentication: This method is as fast as mutual SSL and the least expensive because it does not’ require any
certificates. However, it does require the exchange of usernames and passwords with the administrator of the trusted provider,
which might or might not compromise the security of the trusted relationship.
If your trusted provider is another Identity Server, you can use any of these methods, as long as your Identity Server and the
trusted Identity Server use the same method. If you are setting up a trusted relationship with a third-party provider, you need to
select a method supported by that provider.
For configuration information, see the following sections:
Configuring communication security for a SAML 2.0 identity provider
Configuring communication security for a SAML 2.0 service provider
Configuring communication security for liberty

This PDF was generated on July 27, 2025 Page 235 of 2270
 Access Manager 25.2

1.1.2.8.6. Selecting attributes for a trusted provider

You can select attributes that an identity provider sends in an authentication request or that a service provider receives in an
authentication response. The attributes are selected from an attribute set, which you can create or select from a list of already
defined sets (see Configuring attribute sets).
For best performance, you must configure the trusted providers to use attribute sets, especially for attributes that have static
values such as a user’s e-mail address, employee ID, or phone number. It reduces the traffic between the provider and the
LDAP server, because the attribute information can be gathered in one request at authentication rather than in a separate
request for each attribute when a policy or protected resource needs the attribute information.
Configuring the attributes obtained at authentication
Configuring the attributes set with authentication
Sending attributes to the embedded service provider

This PDF was generated on July 27, 2025 Page 236 of 2270
 Access Manager 25.2

1.1.2.8.6.1. Configuring the attributes obtained at

authentication
When Identity Server creates its request to send to the identity provider, it uses the attributes that you have selected. The
request asks the identity provider to provide values for these attributes. You can then use these attributes to create policies, to
match user accounts, or if you allow provisioning, to create a user account on the service provider.
1. On the Home page, click Applications > Select a Cluster > [Identity Provider] > Attributes.
2. (Conditional) To create an attribute set, select New Attribute Set from the Attribute Set list.
An attribute set is a group of attributes that can be exchanged with the trusted provider. For example, you can specify that
the local attribute of any attribute in the Liberty profile (such as Informal Name) matches the remote attribute specified at
the service provider.
1. Specify a set name, then click Next.
2. On the Define Attribute Set page, click Plus icon.
3. Select a local attribute.
4. Optionally, provide the name of the remote attribute and a namespace.
For more information about this process, see Configuring attribute sets.
5. To add other attributes to the set, repeat Step 2.b through Step 2.d.
6. Click Save.
3. Select an attribute set
4. Select attributes from the Obtain at authentication list.
5. Click Done > Save.
6. Update Identity Server.

This PDF was generated on July 27, 2025 Page 237 of 2270
 Access Manager 25.2

1.1.2.8.6.2. Configuring the attributes set with authentication

When Identity Server creates its response for the service provider, it uses the attributes listed on the Attributes page. The
response needs to contain the attributes that the service provider requires. If you do not own the service provider, you need to
contact the administrator of the service provider and negotiate which attributes you need to send in the response. The service
provider can then use these attributes to identify the user, to create policies, to match user accounts, or if it allows
provisioning, to create a user accounts on the service provider.
1. On the Home page, click Applications > Select a Cluster > [Service Provider] > Attributes.
2. (Conditional) To create an attribute set, select New Attribute Set from Attribute Set.
An attribute set is a group of attributes that can be exchanged with the trusted provider. For example, you can specify that
the local attribute of any attribute in the Liberty profile (such as Informal Name) matches the remote attribute specified at
the service provider.
1. Specify a set name, then click Next.
2. On the Define Attributes Set page, click Plus icon.
3. Select a local attribute.
4. Optionally, you can provide the name of the remote attribute and a namespace.
For more information about this process, see Configuring attribute sets.
5. To add other attributes to the set, repeat Step 2.b through Step 2.d.
6. Click Save.
3. Select an attribute set
4. Select attributes from the Obtain at authentication list.
5. Click Done > Save.
6. Update Identity Server.

This PDF was generated on July 27, 2025 Page 238 of 2270
 Access Manager 25.2

1.1.2.8.6.3. Sending attributes to the embedded service

provider
You can configure the Embedded Service Provider (ESP) of Access Gateway to receive attributes when the user authenticates.
LDAP traffic is reduced and performance is improved when the required LDAP attribute values are retrieved during
authentication. This improvement is easily seen when you have many users and you have configured Identity Injection or
Authorization policies to protect resources and these policies use LDAP attributes or Identity Server roles.
When the authentication process does not gather the LDAP attribute values, each user access can generate a new LDAP
query, depending upon how the user accesses the resources and how the policies are defined. However, if the LDAP values
are gathered at authentication, one LDAP query can retrieve all the needed values for the user.
1. On the Home page, click Identity Servers > IDP Global Settings > Attribute Sets.
2. On the Attributes page, click Plus icon, specify a name, then click Next.
3. For each attribute you need to add because it is used in a policy:
1. Click Plus icon.
2. In Local attribute, scroll to LDAP Attribute section, then select the attribute.
3. Click Save.
The other fields do not need to be configured.
4. If you use Identity Server roles in your policies, click Plus icon, select the All Roles attribute, then click Save.
5. Update Identity Server.

This PDF was generated on July 27, 2025 Page 239 of 2270
 Access Manager 25.2

1.1.2.8.7. Managing metadata

The SAML 2.0 protocols contain pages for viewing and reimporting the metadata of the trusted providers.
Viewing and reimporting a trusted provider’s metadata
Viewing trusted provider certificates
Editing a SAML 2.0 service provider’s metadata

This PDF was generated on July 27, 2025 Page 240 of 2270
 Access Manager 25.2

1.1.2.8.7.1. Viewing and reimporting a trusted provider’s

metadata
You might need to reimport a trusted provider’s metadata if you learn that it has changed. The metadata changes when you
change the provider to use HTTPS rather than HTTP and when you change the certificate that it is using for SSL. The steps for
reimporting the metadata are similar for SAML protocols.

Note
The trusted providers that are from the metadata repository cannot be reimported from this option. On the Home
page, click Identity Servers > IDP Global Settings > Metadata Repositories and click on the metadata repository
created to reimport the trusted provider.

1. On the Home page, click Applications > Select a Cluster > [provider name].
2. Click the trusted provider, then click the Metadata tab.
This page displays the current metadata the trusted provider is using.
3. To reimport the metadata:
1. Copy the URL in the entityID (SAML).
2. Click Reimport metadata.
3. Follow the prompts to import the metadata.
For the metadata URL, paste in the value you copied.
If your Administration Console is installed with your Identity Server, you need to change the protocol from HTTPS to
HTTP and the port from 8443 to 8080.
4. Confirm metadata certificates, then click Finish, or for an identity provider, click Next.
5. (Identity Provider) Configure the card, then click Finish.
6. Update Identity Server.

Note
Reimport support is not available for SAML 2.0 protocols.

This PDF was generated on July 27, 2025 Page 241 of 2270
 Access Manager 25.2

1.1.2.8.7.2. Viewing trusted provider certificates

You can review and confirm the certificate information for identity and service providers.
1. On the Home page, click Applications > Select a Cluster > [Name of Provider] > Metadata > Certificates.
2. View the following information is displayed for the certificates:
Algorithm: The name of the algorithm that was used to create the certificate.
Issuer DN: The distinguished name of the Certificate Authority (CA) that created the certificate.
Serial number: The serial number that the CA assigned to the certificate.
Subject: The subject name assigned to the certificate.
Validity: The first date the certificate was valid, and the date the certificate expires.
3. Click Done.

This PDF was generated on July 27, 2025 Page 242 of 2270
 Access Manager 25.2

1.1.2.8.7.3. Editing a SAML 2.0 service provider’s metadata

You can obtain metadata for SAML 2.0 providers. However, metadata for SAML 2.0 might not be available for some service
providers, and you need to enter the metadata manually.

Note
You can obtain metadata for SAML 2.0 providers either by the service provider or by the pre-built catalog
connector configuration. See Custom connectors.

You must click Manual Entry option when you create a trusted provider to be able to enter the metadata manually.
1. On the Home page, click Applications > Select a Cluster > [SAML2 SP application] > Metadata.
You can reimport the metadata (see Step 2) or edit it (see Step 3).
2. To reimport the metadata, click Reimport metadata.
Follow the on-screen instructions to complete the steps through the wizard.
3. To edit the metadata manually, click Edit Metadata.
4. Specify the following details:
Provider ID: (Required) Specifies the SAML 2.0 metadata unique identifier for the provider. For example,
https://<dns>:8443/nidp/saml2/metadata . Replace <dns> with the DNS name of the provider.
In the metadata, this is the entityID value.
Metadata expiration: Specifies the date upon which the metadata is no longer valid.
Sign assertion: Specifies that authentication assertions from the trusted provider must be signed.
Artifact consumer URL: Specifies where the partner receives incoming SAML artifacts. For example,
https://<dns>:8443/nidp/saml2/spassertion_consumer . Replace <dns> with the DNS name of the provider.
In the metadata, this URL value is found in the AssertionConsumerService section.
Post consumer URL: Specifies where the partner receives incoming SAML POST data. For example,
https://<dns>:8443/nidp/saml2/spassertion_consumer . Replace <dns> with the DNS name of the provider.
In the metadata, this URL value is found in the AssertionConsumerService section of the metadata.
Signing certificates: Specifies the public key certificate used to sign SAML data. You can browse to locate the service
provider certificate.
You can add two signing certificates that is used by the service provider. To add a second certificate that is used by the
service provider, click the Add icon (+), then browse to locate the required service provider certificate. OpenText Access
Manager validates the service provider’s signed messages by using these signing certificates. Based on the certificate
mentioned by the service provider in the SAML 2 messages, OpenText Access Manager picks the signing certificate from
this list.
5. Click Save.

This PDF was generated on July 27, 2025 Page 243 of 2270
 Access Manager 25.2

1.1.2.8.8. Configuring user identification methods for

federation
Configuring authentication involves determining how the service provider interacts with the identity provider during user
authentication and federation. Three methods exist for you to identify users from a trusted identity provider:
You can identify users by matching their authentication credentials
You can match selected attributes and then prompt for a password to verify the match, or you can use just the attributes
for the match.
You can assume that the user does not have an account and create new accounts with user provisioning. You can also
allow for provisioning when the matching methods fail. If there are problems during provisioning, you see error messages
with more information.
In this Section
Defining user identification for SAML 2.0
Defining the user provisioning method
User provisioning error messages

This PDF was generated on July 27, 2025 Page 244 of 2270
 Access Manager 25.2

1.1.2.8.8.1. Defining user identification for SAML 2.0

Selecting a user identification method for SAML 2.0
User identification determines how an account at the identity provider is matched with an account at the service provider. If
federation is enabled between two, the user can set up a permanent relationship between the two accounts. If federation is not
enabled (see Configuring a SAML 2.0 authentication request and Configuring a liberty authentication request), you cannot set
up a user identification method.
1. On the Home page, click Applications > Select a Cluster > [SAML2 IDP application] > User Identification.
2. Specify how users are identified on the SAML 2.0 provider. Select one of the following methods:
Authenticate: Select this option when you want to use login credentials. This option prompts the user to log in at
both the identity provider and the service provider on first access. If the user selects to federate, the user is
prompted, on subsequent logins, to authenticate only to the identity provider.
Allow ‘Provisioning’: Select this option to allow users to create an account when they have no account on the
service provider. This option requires that you specify a user provisioning method.
Provision account: Select this option when the users on the identity provider do not have accounts on the service
provider. This option allows the service provider to trust any user that has authenticated to the trusted identity
provider
This option requires that you specify a user provisioning method.
Attribute matching: Select this option when you want to use attributes to match an identity server account with a
service provider account. This option requires that you specify a user matching method.
Prompt for password on successful match: Select this option to prompt the user for a password when the
username is matched to an account, to ensure that the account matches.
If you have selected Transient user mapping while configuring the name identifier format, the Authenticate and Provision
account options are not displayed for SAML 2.0.
3. Select one of the following:
If you selected Attribute matching, select a method and click Save. If you did not create a matching method,
continue with Configuring the attribute matching method for SAML 2.0.
If you selected the Provision account option, select a method, then click Save. If you have not created a
provisioning method, continue with Defining the user provisioning method.
If you selected the Authenticate option with the Allow Provisioning option, select a method, then click Save. If you
have not created a provisioning method, continue with Defining the user provisioning method.
If you selected the Authenticate option without the Allow Provisioning option, click Save.
4. Configure the authentication methods that must be used before authenticating the users.
Step up authentication methods: These are the existing configured authentication methods that you can use for
secondary authentication. Select the required methods. The selected methods are used in the same order as listed for the
step up authentication. The step up authentication does not require to identify the user because identity provider already
authenticates the user. The step up authentication is used for additional authentication to access the services. Hence, the
selected methods must not have Identifies User selected in its configuration. After an identity provider authenticates, the
Identity Server (service provider) prompts for step up authentication for additional security. If the step up authentication
method is not satisfied, authentication fails.

Note
To enable audit events for step-up authentication, select the Federation Step-up event.

5. Post authentication methods: These are the existing methods that can be used after the authentication is successful.
These are not used for authenticating a user but to perform custom tasks post authentication, such as password fetch. If
the post authentication method fails, the session will remain valid.

This PDF was generated on July 27, 2025 Page 245 of 2270
 Access Manager 25.2

The selected method is executed when post remote authentication completes: For example if you select the
passwordfetch method, this method is executed at the service provider after the identity provider authentication and
federation completes. For more information about passwordfetch method, see Password retrieval.
6. Configure the session options.
Allow IDP to set session timeout: Select Allow Identity Provider to set session time-out between the principal identified
by the subject and the SAML authority based on SessionNotOnOrAfter attribute in SAML assertion of authnStatement.
Overwrite temporary user: If you select this option, then the temporary user credentials profile got from previous
authentication method in the same session will be overwritten with real user credentials profile got from this
authentication method.
Overwrite real user: If you select this option, the real user credentials profile got from the previous authentication method
in the same session will be overwritten with real user credentials profile got from this authentication method
Assertion validity window: You can manually set the assertion validity time for a SAML service provider (SP) to
accommodate clock skew between SP and a SAML Identity Server (IDP).
7. Click Save, then update Identity Server.

Configuring the attribute matching method for SAML 2.0

If you selected Attribute matching while selecting a user identification method, you must configure a matching method.
The Liberty Personal Profile is enabled by default. If you have disabled it, you need to enable it. See Managing web services
and profiles.
1. On the Home page, click Applications > Select a Cluster > [application name] > SAML v2.0 Identity Provider > User
Identification.
2. Click Attribute Matching settings.
3. Select and arrange the user stores you want to use.
Order is important. The user store at the top of the list is searched first. If a match is found, the other user stores are not
searched.
4. Select a matching expression, or click New to create a look-up expression. For information about creating a look-up
expression, see Configuring user matching expressions.
5. Specify what action to take if no match is found.
Do nothing: Specifies that an identity provider account is not matched with a service provider account. This option
allows the user to authenticate the session without identifying a user account on the service provider.

Important
Do not select this option if the expected name format identifier is persistent. A persistent name format
identifier requires the user to be identified so that information can be stored with that user. To support
Do nothing and allow anonymous access, you must configure the authentication response for a transient
identifier format. To view the service provider configuration, see Configuring an authentication response
for a service provider.

Prompt user for authentication: Allows a user to specify the credentials that exists on the service provider.
Sometimes users have accounts at both the identity provider and the service provider, but the accounts were
created independently, use different names (for example, joe.smith and jsmith) and different passwords, and share
no common attributes except for the credentials known by the user.
Provision account: Assumes that the user does not have an account at the service provider and creates one for the
user. You must create a provisioning method.
6. Click OK.
7. (Conditional) If you selected Provision account when no match is found, select the Provision settings icon. For
information about this process, see Defining the user provisioning method.
8. Click OK > OK, then update Identity Server.

This PDF was generated on July 27, 2025 Page 246 of 2270
 Access Manager 25.2

1.1.2.8.8.2. Defining the user provisioning method

If you have selected Provision account as the user identification method or have created an attribute matching setting that
allows for provisioning when no match is found, you need to create a provision method. This procedure involves selecting
required and optional attributes that the service provider requests from the identity provider during provisioning.

Important
When a user object is created in the directory, some attributes are initially created with the value of NAM
Generated. Afterwards, an attempt is made to write the required and optional attributes to the new user object.
Because required and optional attributes are profile attributes, the system checks the write policy for the profile’s
Data Location Settings (specified in Web Service Provider API (https://<admin-console-host>:<admin-console-
port>/nps/swagger-ui.html)) and writes the attribute in either LDAP or the configuration store. For the LDAP write to
succeed, each attribute must be properly mapped as an LDAP Attribute. Additionally, you must enable the
read/write permissions for each attribute in the Liberty/LDAP attribute maps. See Mapping LDAP and liberty
attributes.

To configure user provisioning:

1. On the Home page, click Applications > Select a Cluster > [application name] > SAML v2.0 Identity Provider > User
Identification.
2. Click the Provisioning Settings icon.
3. Select the required attributes from Available Attributes and move them to Attributes.
Required attributes are required in the creation of a user name or account.
4. Click Next.
5. Select optional attributes from the Available Optional Attributes list.
This step is similar to selecting required attributes. However, the user provisioning request creates the user account
whether the optional attributes exist on the service provider.
6. Click Next.
7. Define how to create the username.
You can specify whether users are prompted to create their own usernames or whether the system automatically creates
usernames. Selecting an attribute for the username segments from the required attributes list improves the chances to
create a new username successfully.
Maximum length: The maximum length of the user name. This value must be between 1 and 50.
Prompt for user name: Enables users to create their own usernames.
Automatically create user name: Specifies that the system creates usernames. You can configure the segments for the
system to use when creating usernames and configure how the names are displayed.
For example, if you are using the required attributes of Common First Name and Common Last Name, a username for
Adam Smith might be generated as A.Smith_02 as follows:

Use the following settings to specify how this is accomplished:

Segment 1: The required attribute to use as the first segment for the user name. The values displayed in this list
correspond to the required attributes you selected. For example, you might select Common First Name to use for
Segment 1.
Length: The length of the first attribute segment. For example, if you selected Common First Name for the Segment
1 value, setting the length to 1 specifies that the system uses the first letter of the Common First Name attribute.

This PDF was generated on July 27, 2025 Page 247 of 2270
 Access Manager 25.2

Therefore, Adam Smith would be ASmith.

Junction: The type of junction to use between the attributes of the user name. If a period is selected, Adam Smith
would display as A.Smith.
Segment 2: The required attribute to use as the second segment for the user name. The values displayed in this list
correspond to the required attributes you selected. For example, you might select Common Last Name to use for
Segment 2.
Length: The length of the second attribute segment. For example, if you selected Common Last Name for the
Segment 2 value, you might set the length to All, so that the full last name is displayed. However, the system does
not allow more than 20 characters for the length of segment 2.
Ensure name is unique: Applies a suffix to the colliding name until a unique name is found, if using attributes causes
a collision with an existing name. If no attributes are provided, or the lengths for them are 0, and this option is
selected, the system creates a unique name.
8. Click Next.
9. Specify password settings.
Use this page to specify whether to prompt the user for a password or to create a password automatically.
Minimum password length: The minimum length of the password.
Maximum password length: The maximum length of the password.
Prompt for password: Prompts the user for a password.
Automatically create password: Specifies whether to automatically create passwords.
10. Click Next.
11. Specify the user store and context in which to create the account.
User store: The user store in which to create the new user account.
Context: The context in the user store you want accounts created.
The system creates the user within a specific context; however, uniqueness is not guaranteed across the directory.
Delete user provisioning accounts if federation is terminated: Specifies whether to automatically delete the provisioned
user account at the service provider if the user terminates his or her federation between the identity provider and service
provider.
12. Click Finish.
13. Click Save, then update Identity Server.

This PDF was generated on July 27, 2025 Page 248 of 2270
 Access Manager 25.2

1.1.2.8.8.3. User provisioning error messages

The following error messages are displayed to users when they face problems during provisioning:
Provisioning error messages

Error Message Cause

Username length cannot exceed (?) The user entered more characters for a user name than is
characters. allowed, as specified by the administrator.

Username is not available. The user entered a name that already exists in the directory.

Passwords don't match. The user provided two password values that do not match.

Passwords must be between (x) and (y) The user provided password values that are too short or too
characters in length. long.

Username unavailable. The provisioned user account was deleted without first
defederating the user. Remove orphaned identity objects
from the configuration datastore.

Important
Experienced LDAP users must remove
orphaned identity objects from the
configuration datastore. Ensure that you remove
only the orphaned objects. Else, you create
orphaned objects by mistake.

Unable to complete authentication request. The password provided does not conform to the Windows
password complexity policy in Active Directory. Ensure that
Active Directory is configured to use a secure port, such as
636, and that the user’s password conforms to the
complexity policy. If you encounter this error, you must
reset the password on the Windows machine.
Can occur when users are allowed to create accounts from
a service provider’s login page, when the service provider
uses Active Directory as the user store.

This PDF was generated on July 27, 2025 Page 249 of 2270
 Access Manager 25.2

1.1.2.8.9. Configuring an authentication response for a service

provider
SAML 2.0 protocols support slightly different options for configuring how you want Identity Server to respond to an
authentication request from a service provider.
When Identity Server receives an authentication request from a trusted service provider, the request contains the conditions
that Identity Server needs to fulfill. You can configure how you want Identity Server to fulfill the binding and name identifier
conditions of the request. For configuration information, refer to one of the following:
Configuring the liberty authentication response
Configuring a SAML 2.0 authentication response
You can specify which contract to be used when the authentication request specifies a class or type rather than a contract. For
more information, see Specifying authentication defaults.
When the service provider sends an authentication request that specifies a specific contract, ensure that Identity Server has a
the contract matches the expected URI. For information about how to configure such a contract, see Creating a contract for a
specific authentication type.

This PDF was generated on July 27, 2025 Page 250 of 2270
 Access Manager 25.2

1.1.2.8.10. Routing to an external identity provider

automatically
When Identity Server is configured to federate with multiple external identity providers, you can specify the list of
authentication contracts that an external provider can execute. This configuration allows Identity Server (acting as service
provider) to automatically select the external identity provider without the user having to click on the external provider's card.
Authentication contracts in Identity Servers can be configured with an authentication class reference. This reference can be
used in federating with external identity or service providers that only respond to AuthnContextClassRef in the authentication
request and response. For information about setting up the contract mapping and adding contracts to the satisfiable list, see
Modifying an authentication card for SAML 2.0 and Configuring authentication contracts.

This PDF was generated on July 27, 2025 Page 251 of 2270
 Access Manager 25.2

1.1.2.8.11. Configuring options for trusted service providers

This PDF was generated on July 27, 2025 Page 252 of 2270
 Access Manager 25.2

1.1.2.8.12. Using the intersite transfer service

In this Section
Understanding the intersite transfer service URL
Using intersite transfer service links on web pages
Configuring an intersite transfer service target for a service provider
Configuring allowed list of target URLs
Validating incoming authentication request for assertion consumer service URL
Federation entries management
Step up authentication example for an identity provider initiated single sign-on request
URL query string parameters

This PDF was generated on July 27, 2025 Page 253 of 2270
 Access Manager 25.2

1.1.2.8.12.1. Understanding the intersite transfer service URL

The Intersite Transfer Service is used by an identity provider to provide authentication to occur at a service provider that it
trusts. URLs for accessing the Intersite Transfer Service differ for each supported protocol (SAML 2.0). The OpenText Access
Manager identity and service provider components use the following format of the Intersite Transfer Service URL:

<identity provider URL>?PID=<entityID>&TARGET=<final_destination_URL>

The <identity provider URL> is the location where the authentication request can be processed. For an Identity Server, the URL
is the Base URL of the server that provides authentication, followed by the path to the protocol application being used for
federation.
For example:
SAML 2.0: https://idp.sitea.novell.com:8443/nidp/saml2/idpsend
If a third-party server provides the authentication, see the documentation for the format of this URL.
The <entityID> is the URL to the location of the metadata of the service provider. The scheme (http or https) in the <entityID>
must match what is configured for the <identity provider URL>.
For SAML 2.0, search the metadata for its entityID value. OpenText Access Manager Identity Servers acting as service
providers have the following types of values:
SAML 2.0: https://idp.siteb.novell.com:8443/nidp/saml2/metadata
If you are setting up federations with a third-party service provider, refer the documentation for the URL or location of its
metadata.
The <final_destination_URL> is the URL to which the browser is redirected following a successful authentication at the identity
provider. If this target URL contains parameters (for example, TARGET=https://login.provo.novell.com:8443/nidp/app?
function_id=22166& amp;Resp_Id=55321 &amp;Resp_App_Id=810&amp;security_id=0 ), the URL must be encoded to prevent it
from being truncated.
For example:
SAML 2.0: https://idp.sitea.novell.com:8443/nidp/saml2/idpsend?
PID=https://idp.siteb.novell.com:8443/nidp/saml2/metadata&TARGET=https://eng.provo.novell.com/saml2/myapp
For more information, see Configuring an intersite transfer service target for a service provider.
If you configure an Intersite Transfer Service URL for an Identity Server that is the OpenText Access Manager Identity Server
and the service provider is either another Identity Server or a third-party server, you can simplify the Intersite Transfer Service
URL to the following format:

<identity provider URL>?id=<user_definedID>

For example:
SAML 2.0: https://test.blr.novell.com:8443/nidp/saml2/idpsend?id=testsaml2&TARGET=https://eng.provo.novell.com
If the Allow any target option is enabled and if the Intersite Transfer Service URL has a target value, then the user is redirected
to target URL.
The Intersite Transfer Service URL for SAML 2.0 will be https://testsb.blr.novell.com:8443/nidp/saml2/idpsend?
id=testsaml2&TARGET=http://www.google.com where http://www.google.com is the target URL.

Note
Depending on the usage, the target paramete