Using the OPENAM_SESSION module in IDM, can you embed IDM REST calls?

Tagged: , , ,

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

  • Author
  • #23502

    I’ve just got integration between IDM and AM going, and I wanted to be able to embed some REST calls to IDM in our company Intranet portal to pull back some JSON data from IDM and render it on the Intranet.

    I found this paragraph of the Integration guide:

    The use case is when you need to integrate IDM endpoints behind the scenes within other applications, such as with a company intranet portal. In that configuration, users would log into AM to access the portal; at that point, their sessions would use the AM SSO cookie, also known as iPlanetDirectoryPro. For more information, see the AM Authentication and Single Sign-On Guide to Session Cookies.

    When I first read it, I thought this is exactly my use case, integrating with a company intranet portal. But looking into it further it doesn’t look like you can just pass an AM session cookie to IDM and get a response, it looks like there is an elaborate OAuth 2 dance that has to take place.

    Does anyone know how feasible it is to embed calls to IDM on an intranet assuming that CORS is setup correctly? Are there any examples of what I’d need to do to be able to call IDM using an AM session?

     Bill Nelson

    IDM’s delegation of authentication uses OAuth2, not session cookies. I don’t know if I agree with it being an “elaborate OAuth 2 dance” as the flow that you go through is roughly the same as used with session cookies (what I call the ‘dance of the cookie fairies’).

    If you don’t want to embed usernames/passwords in your portal (smart man), then there are other options that can be used. See for a full list of authentication (“authn”) options.

    Assuming that you have already authenticated into your company portal, then one relatively easy option you could use is that of the TRUSTED_ATTRIBUTE authn module. You could pass a header attribute via the portal to IDM which can then be used to perform a lookup of the user in IDM for authn purposes. This works well when you force traffic through reverse proxies, OpenIG, or in your case, a portal. You should take care, however, to ensure that traffic cannot be intercepted and someone can inject their own headers. I have used this in a couple of use cases where the RP is installed with another vendor’s SSO solution (i.e. SiteMinder). The RP ensures that the user is authenticated and then populates a header with the identity of the user. One drawback to this option is that you need to build a new servlet filter bundle (instructions found here:, but ForgeRock gives you the sample code for this. If I can follow the instructions, then anyone can.

    If you want a tighter integration within the ForgeRock stack, then using the OAUTH_CLIENT authn module is the best bet. It really is not all that difficult to do, don’t let the instructions found at concern you as they include installation instructions for AM as well. If you already have AM up and running, then you simply need to configure OpenID connect for authn, configure the OAuth2 service in AM, and enable/configure the OAUTH_CLIENT in IDM. The entire process takes roughly 30 minutes to perform and is even a lab in the latest IDM-400 training class from ForgeRock.

    There are other “more creative” methods that can be used, but these are the two that I would start with.

    Hope this helps,


     Jake Feasel

    You might find it easier to make those REST calls if you setup IG to protect IDM, as I describe in this post:

    This way, you can use an access_token obtained from AM (using whichever flow is appropriate, possibly auth code or client credentials) to access your IDM endpoints.


    Hi Bill, I already have that full stack setup configured, it took about 3 days for me though because I had to upgrade from OpenAM 13.5 first, as it didn’t quite support OpenID Connect in the way that IDM 5.5/6 needed.

    IDM isn’t really behind the portal per-se, so the trusted authentication module is not really an option. I

    My problem is that I don’t know the steps required to convert the OpenAM session token into an OAuth token that can be used with IDM (I’ve used AM a lot, but quite new to OAuth2), but inside Javascript in a web browser.

    When I looked at how IDM authenticated with AM, in the Chrome Developer Console, I can see it redirecting from IDM to AM and back to IDM, which isn’t feasible in a XMLHttpRequest. I suppose that could in theory work in an iframe, but that seems a bit blah. So maybe in JavaScript I can manually call each part of the dance from getting a OIDC token from AM, then sending a request to the callback endpoint for IDM, and then being able to call the actual IDM REST service after that?

    Is there a different OAuth flow I should be using for my use case? Or would I just follow what it does to login to the IDM UI? One thing I can’t quite figure out is how the 5-second session timeout works with IDM. I’ve noticed when I open up the IDM console and click around it works fine, but if I call one of the REST endpoints via GET in the browser, then after 5 seconds it gives me an authentication error. So I guess that means there is something that needs to be done to keep the session active?

    But yes, I do agree that with Jake that putting IDM behind IG does seem a lot easier, however, unfortunately, the client hasn’t purchased IG just yet, there hasn’t been a use case for it until now.


    Jake, if I’m calling IDM from a single page app, should I be using the Implicit auth flow? Would it work or does the “Forgerock identity provider” integration not really let me do what I’m after?

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

You must be logged in to reply to this topic.

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