Internal OpenAM 13.5 server with SAML 2 redirection

This topic has 10 replies, 3 voices, and was last updated 4 years, 9 months ago by diedel.

  • Author
  • #20202


    I deployed an Open AM 13.5 instance in a internal server of my company.
    We configured a NAT to reach that internal server from external IP.

    At first it seems it works because the customer is able to access the OpenAM instance using the external IP:

    , but afterwards the customer is redirected to the internal IP:
    in.ter.nal.ip:8088/OpenAM-13.5.0/XUI/#login/&realm= ….

    Is it possible to readdress this redirection to the external IP, either configuring OpenAM, Tomcat or the firewall?

    Thanks in advance.


    You can change this in the web container, ie if you are using tomcat, then you can change the tomcat connector. Alternatively, you can also add a FQDN mapping in AM advanced config, ie com.sun.identity.server.fqdnMap[ex.ter.nal.ip]=ex.ter.nal.ip


    Thanks handat.

    I tried your two proposals:

    • I modified the Tomcat main connector by adding proxyname=””. And restarted Tomcat.
    • I configured the FQDN mapping in OpenAM. And restarted Tomcat.

    Unfortunately neither of the solutions worked. The customer still receives the internal IP in the browser redirection.

    • This reply was modified 4 years, 9 months ago by diedel.
     Peter Major

    You can either set the Auth URL setting in the IdP configuration to the hard-coded external address, or you can reconfigure your reverse proxy/load balancer so that it does not override the Host header’s value when forwarding the request to OpenAM. If you are using Apache Reverse Proxy for example this could be achieved by using the ProxyPreserveHost On directive.


    Thanks Peter.

    I modified the Auth URL setting, in the IdP configuration, with the value http://ex.ter.nal.ip:8088/OpenAM-13.5.0-SNAPSHOT/XUI/#login/.
    When I make the request with the curl tool it works and now the Location header of the HTTP Redirection shows that external IP.

    But this is a temporary workaround because I cannot make the request if I’m located in the LAN of the internal server as I get redirected to the harcoded external IP.

    I think a better solution is to avoid NATs and install a public proxy server which redirects customer requests to our internal OpenAM server. What do you think?


    Well, I tested it throughly and didn’t work neither.

    This time I called curl with the follow redirects option:
    curl -v -L "http://ex.ter.nal.ip:8088/OpenAM-13.5.0-SNAPSHOT/idpssoinit?metaAlias=%2Fidp&"

    At last OpenAM redirects the client to the internal IP:

    • This reply was modified 4 years, 9 months ago by diedel.

    In fact nothing has changed after setting the auth URL (with the harcoded external IP) in IdP config. I undid that change and launched curl again, I receive exactly the same redirections.

    Maybe the auth URL applies at the very last step?


    I made some progress :)

    I installed an Apache reverse proxy in a new public server. I set the directives ProxyPass and ProxyPassReverse accordingly.

    This time I tried to connect to the OpenAM main login, http://ex.ter.nal.ip:8088//OpenAM-13.5.0-SNAPSHOT/, and now the browser redirects to the external IP_ http://ex.ter.nal.ip:8088//OpenAM-13.5.0-SNAPSHOT/XUI/#login/, BUT…
    I receive the ERR_TOO_MANY_REDIRECTS error in the browser.

    I searched across internet looking for the solution but none worked in my case:

    • In WEB-INF/classes/, I set com.sun.identity.server.fqdnMap[ex.ter.nal.ip]=ex.ter.nal.ip
    • In the reverse proxy server I set ProxyPassReverseCookieDomain internal.ip external.ip

    Any idea?


    Finally I got it :) At least I can connect to the XUI login of OpenAM from my external PC.

    I reconfigured the OpenAM instance with a defined FQDN and now no more infinite redirections.

    Now I’ll configure again the SAML 2 SP and IdP, and I will test the /ispssoinit request. Crossing fingers…

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?