AM Integrating with IG on OAuth

Tagged: ,

This topic has 6 replies, 2 voices, and was last updated 1 week ago by Jatinder Singh.

  • Author
    Posts
  • #28117
     ray.deng83
    Participant

    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!

    Best,
    Le

    #28119
     Jatinder Singh
    Participant

    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/am as 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 Alias for your realm and have IG add a Host header 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_token as opposed to
    https://am.example.com/am/oauth2/realms/root/realms/EIAM/access_token.

    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 Reverse Proxy handlers.

    Hope this information helps!

    #28121
     ray.deng83
    Participant

    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?

    Best,
    Le

    #28122
     Jatinder Singh
    Participant

    You can use one IG or IG Cluster to serve various realms or RPs. You can do the following:

    * Have client authentication done using JWT Profiles;

    * When IG receives a request, JWT will be included for client authentication. You can use the domain included in the aud parameter to set the Host header. 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-Host passed on to IG by your front facing LB. When you receive that header you could simply use it to set Host header or attempt to do some validation like comparing it with the aud domain and so on. On the contrary side, you could delegate such verification entirely to AM by simply reading the aud field and setting it as-is without making any changes.

    * For other OAuth2 or OpenID endpoints, you can rely on the issuer field of Access Token or ID Token to set your Host header;

    * Now since the HOST header is read from the JWT Profile, you can support multiple RPs or Realms.

    Hope this helps!

    #28125
     ray.deng83
    Participant

    That’s cool. Let me try that out. I’ll post back.

    Best,
    Le

    • This reply was modified 2 weeks, 1 day ago by ray.deng83.
    #28157
     ray.deng83
    Participant

    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.

    Best,
    Le

    #28161
     Jatinder Singh
    Participant

    Howdy!

    Sure, that works too. IMHO, once you try the DNS Alias path, you will notice you won’t have to mention or maintain realm information 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.

    Thanks,
    Jatinder

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

You must be logged in to reply to this topic.

©2020 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?