OpenIG RP to IDP Proxy (OpenAM) and SP (OpenAM)

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

  • Author
  • #8103


    While I understand that OpenIG is a “specialized” Reverse Proxy (RP) and there is documentation on how to set it up to RP an OpenAM instance (or OpenAM HA instance) how would one configure OpenIG such that:

    – RPs to an “IDP Proxy” Open AM LB’d instance at say
    – RPs to an “SP” OpenAM LB’d instance at say

    As OpenIG is being deployed in the DMZ all I need is for it to handle these 2 OpenAM endpoints.



    The simplest thing to do is actually to have 2 routes (routes/idpx.json and routes/spx.json), where the first one accepts only requests with their equals and second one only

      "condition": "${ == ''}"

    Obviously, your network should be configured such as goes to the OpenIG instance, not the real IDP (same for

    And then, you need to tell OpenIG to change the destination URI of each request accepted by the route:

      "baseURI": "" // You may change the scheme and port in addition to the host

    That’s the basis of the configuration.

    You may then need some additional filters, like a LocationHeaderFilter that would be responsible to rewrite/rebase Location header values returned by your OpenAM instances:

      "name": "LocationRewriter",
      "type": "LocationHeaderFilter",
      "config": {
        "baseURI": "" // client exposed hostname

    Somehow, you have to do some reverse engineering on the messages you get from your AM instances and fix inconsistencies (either in IG, or in AM configuration).


    Thank You for the thorough response. I know OpenIG is a specialized RP however your last comment leaves me a little perplexed as your answer seems to address most issue I can see (forward re-mapping and location re-mapping).

    Is OpenIG not capable of reverse proxying OpenAM without “doing some reverse engineering on the messages you get from your AM instances and fix inconsistencies (either in IG, or in AM configuration)”?



    OpenIG is a generic Identity Gateway that supports open standards and can be used with any standard compliant Identity Provider or Authorisation Server. It does have a good integration with OpenAM, leveraging some of the REST end-points to act as a PEP, STS…

    But it’s not been specifically pre-configured to address the protection of OpenAM. This is on our roadmap, and it’s mostly a configuration task (I don’t think there is much code to develop to get it to work).
    Afaik, the only thing that would need to be develop is the script to rewrite the protected OpenAM URI in the data that is sent to clients (although some of it could even be configured directly in OpenAM).

    I hope this helps.


    I think that you’ll find interesting bits in this post:

    In brief, they achieved IG proxying AM with a plain transparent proxy configuration on IG’s side, and a site configuration on AM’s side.

    Simple as abc :)


    Hi Ludo and Guillaume,

    The video is great and I have come across it before. Thank You for sharing it again.

    OpenIG definitely handles 2 of 3 aspects (the 3rd being mapping in the html response) that a full blown reverse proxy would handle and yes I am aware that I could configure the OpenAM Primary URL to use the FQDN of OpenIG vs. OpenAM.

    However, there is a beauty in full blown reverse proxies such as was the case with Sun Web Proxy Server / Sun Web Server (which later absorbed the reverse proxy features and is now something like Oracle iPlanet Web Server) that could offer a full blown reverse proxy with minimal configuration such that you could independently test/hit the server behind the RP and it wouldn’t even know it was behind an RP. I was hoping OpenIG could do this “easily”.

    With the suggested approach if the OpenIG is down you can not login to the OpenAM directly if say you were an internal network system admin that wanted to *OR* to quickly answer the question “Is OpenIG down OR is OpenAM down?” *AND* you couldn’t say block OpenAM admin URI endpoints in the OpenIG to make administering OpenAM more secure by needing to be an internal network system admin (that would have to go directly to OpenAM to admin it).

    It would be great if OpenIG could “easily” offer the ability to map URI prefixes in HTML responses from the OpenAM FQDN (or LB) to the OpenIG FQDN (or LB). I am told it can be done with Groovy scripting but have not been able to see how to do this exactly nor do I know how performant Groovy scripting would be vs. it being done in a Java filter native to the product.

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