Install OpenAM in Tomcat root?

This topic has 8 replies, 6 voices, and was last updated 5 years, 6 months ago by nikolaosinlight.

  • Author
  • #7770

    Is it possible to install OpenAM to the Tomcat root? Eg, so it can be accessed at the website root, without the need for the “/openam” container?

     Bill Nelson

    while it may be “possible” (see, I am not so sure it is advisable or that it wouldn’t break something else in OpenAM (for instance URL params for services, realms, etc.).

    A question is why do you want to do this?

    We rename the openam war file to something like auth.war or sso.war, or something that doesn’t give away that this is an OpenAM deployment (as well as renaming cookies, etc.). This is more of a common practice (at least from my experience) than trying to remove the URI altogether.

     Peter Major

    Unfortunately it’s not possible at the moment. If you try it, you will get a StringIndexOutOfBoundsException from the configurator. We have this limitation since the OpenSSO days at least, it is really hard to tell how many components within OpenAM depends on this..


    From, one suggestion is: “When installing OpenAM, do not use /openam or /opensso as the deployment URI.”

    Any recommendation how to achieve the hardening suggestion?


     Peter Major

    Use /login or /sso or /auth or /foobar as a root context instead?

     Neil Madden

    Note that you can always rewrite URLs in a reverse proxy in front of OpenAM (e.g. Nginx) to make it look like OpenAM is installed in the root, if that is what you want.


    We use OpenIG heavily as a reverse proxy to front our OpenAM stack. As was mentioned a reverse proxy can easily handle this like Nginx. Essentially you create an FQDN whose root maps to /openam just behind it (in fact in such a case you don’t even need to worry about renaming /openam unless say for Intranet users).

    BTW if your Access Management is Internet facing then a reverse proxy is great to also keep operational components (e.g. OpenAM) out of your DMZ which just adds another security layer to your architecture.


    Thanks all, good advices.

    As for reverse proxy to OpenAM as an IdP, is there a list of endpoints that can be safely exposed through reverse proxy? I don’t want to accidentally expose endpoints (UI and/or API) with administrative functionality to the internet.


    I don’t know of a list offhand although IIRC the docs do talk to endpoints to restrict for security however I think what may be beneficial is how we deal with amadmin access since you mention a concern with exposing administrative functionality to the Internet.

    We have the RP(‘s) “only” reverse proxy to OpenAM “sub realms” (with DNS alias) that have their own LDAP User branch. Admins access the OpenAM directly from the Internal network and login to the root realm.

    The side benefit of the above setup is that one can no longer log in as amadmin from the Internet because amadmin does not exist in the sub realm data stores! Again – yet another security layer :-)

Viewing 9 posts - 1 through 9 (of 9 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?