AC operations in legacy SAML 2 UI show "waiting...." for two minutes before proceeding on AWS or Azure platforms

  • 7022723
  • 12-Mar-2018
  • 12-Mar-2018


Access Manager 4.4
Access Manager 4.3
Admin Console
Azure or Amazon Web Services platforms


When an Admin Console iManager, running in an AWS or Azure cloud, is accessed via its public IP address some operations such as modifying a SAML 2 service provider are problematic.

For example, if an admin logs into their Admin COnsole iManager in an AWS/RHEL setup using the public IP assigned to the VM where the AC is running (ex:, then go into the legacy SAML 2 UI and attempt to modify a setting on an existing SP, the browser will show "Waiting for <ip>" for two minutes before proceeding due to a socket timeout exception.

It appears that the AC always tries to connect to the /roma/rest/idpclusters/devices endpoint using the IP or DNS name that is used in the browser session instead of using its own, local ip.


Defect logged with engineering but can workaround the issue with following steps:

1. Use a URL with a DNS name instead of IP address when accessing the AC (ex: Workstations should resolve this DNS name to the public IP address of the AC vm.

2. Make an entry in the AC's /etc/hosts file so that it resolves this same DNS name to its own *internal* IP address. For example:


The call to the rest endpoint should be sent to the vm's local ip, not the ip or dns name in the browser session used to access the AC