July 27, 2020 at 3:14 pm #28117
I have an OAuth use case where ForgeRock AM can’t be directly accessed. If I use IG as a proxy for AM to receive the incoming requests, IG can act as a pure gateway which just routes the traffic to AM. On the other hand, IG possesses capabilities to interact with AM, such as validate access token, check scope and etc. I’m wondering which integration pattern I should use.
For example, when validating an access token, in case IG is a pure gateway, an Access Token Validation request will come to IG and then routed to AM’s introspect endpoint to validate the token. The result will be returned as JSON response. On the other hand, in case we want to leverage IG’s capability interacting with AM, when the Access Token Validation request comes to IG, instead of routing it to AM, IG will communicate at back channel to get the token validity information and then send a response back with that information.
Those are two different integration patterns. Not sure which one I should go for. If we use the second pattern, that is leveraging IG’s capability interacting with AM, will all the OAuth flow be supported? For example, will IG return an Access Token on AM’s behalf if a client is requesting an Access Token using Auth Code flow?
Any comments are welcome. Thanks!
LeJuly 27, 2020 at 4:43 pm #28119
You can most certainly put IG in front of AM to proxy OAuth2 + OpenID communication between the RP and AS. You will need to do couple of things:
P.S My assumption for this answer is you are also using OpenID. If not, you can ignore OpenID specific info and the approach is still valid for OAuth2 flows.
* Have the well-known OpenID configuration document reference the domain which is used to access individual endpoints. For example,
https://ig.example.com/amas opposed to
https://am.example.com/am. I personally like to maintain a separate very slim down version (hosted within IG) of the OpenID configuration document as opposed to the one AM publishes by default. And that’s because, the one generated by AM reveals a lot of information which may not be need for most scenarios;
* You will need to configure a Base URL Source service to tell AM how it is accessed;
* You need to configure a
DNS Aliasfor your realm and have IG add a
Hostheader to all incoming requests from your RP. A very nice side-effect of utilizing this feature is – the URLs in the custom OpenID configuration document don’t have to explicitly reveal realm information and stay neutral. E.g of how the AM endpoints from IG may look like:
https://am.example.com/am/oauth2/access_tokenas opposed to
Because the DNS Alias can connect request with the right realm, we don’t have to explicitly state that in the URLs.
* In terms of pattern, you could use either depending upon your use case. That said, if your case doesn’t require transforming the original request or creating a new request, I would suggest to keep it simple and have IG use
Hope this information helps!July 27, 2020 at 5:49 pm #28121
That’s very useful information. OpenID is considered in the Scope.
I’m just thinking that regarding DNS Alias config for AM, do I need separate IG for each realm or we can use just one IG? If one IG is fine, how should I configure the DNS alias?
LeJuly 27, 2020 at 6:10 pm #28122
You can use one IG or IG Cluster to serve various realms or RPs. You can do the following:
* Have client authentication done using
* When IG receives a request, JWT will be included for client authentication. You can use the domain included in the
audparameter to set the
Hostheader. You have to be a bit careful here as you cannot blindly trust the value included. Either you can verify the JWT signature which involves having access to the private key at the IG level which may not be desirable but is doable. Or you could also rely on the
X-Forwarded-Hostpassed on to IG by your front facing LB. When you receive that header you could simply use it to set
Hostheader or attempt to do some validation like comparing it with the
auddomain and so on. On the contrary side, you could delegate such verification entirely to AM by simply reading the
audfield and setting it as-is without making any changes.
* For other OAuth2 or OpenID endpoints, you can rely on the
issuerfield of Access Token or ID Token to set your
* Now since the HOST header is read from the JWT Profile, you can support multiple RPs or Realms.
Hope this helps!July 27, 2020 at 8:18 pm #28125
That’s cool. Let me try that out. I’ll post back.
August 3, 2020 at 3:27 pm #28157
- This reply was modified 2 weeks, 1 day ago by ray.deng83.
OK, the added Host header fixed the AM redirect to its own URL issue. In this case, the subrealm can be accessed through url path, which is /realms/subrealm. I just need to have the Host point to AM base URL and each subrealm can be accessed through IG through url path instead of DNS alias. This looks easier to me.
I haven’t tried the client authentication through JWT Profiles, which is great to know and will be a candidate option in my pocket.
LeAugust 4, 2020 at 7:13 pm #28161
Sure, that works too. IMHO, once you try the
DNS Aliaspath, you will notice you won’t have to mention or maintain
realminformation in your AM URLs on the IG side. I find that a bit easier and intuitive to work with. But both ways are correct and I am glad you got it working.
You must be logged in to reply to this topic.