Uploaded image for project: 'OpenIDM'
  1. OpenIDM
  2. OPENIDM-9624

Conflict between OAuth Datastore token usage for authentication and binding


    • Target Version/s:
    • Sprint:
      OpenIDM Sprint 87, OpenIDM Sprint 88, OpenIDM Sprint 89


      In a full-stack deployment, the AM id_token is submitted by the UI within a header named "X-OpenIDM-DataStoreToken" in every REST call. This is used for authentication and also for checking the continued validity of the AM session after the IDM session expires (default 5 seconds).

      In addition, this header is used when an end-user attempts to bind a new social provider to their account. Here is an example REST call used for such a purpose:

      curl -X POST /openidm/managed/user/b0e6a2b5-ec39-47cc-b9cf-488a73fbc2bd?_action=bind&provider=google -H 'X-OpenIDM-DataStoreToken: ${jwtToken}'

      These two uses of the header come into conflict in a full-stack deployment. It cannot be simultaneously used for both purposes.

      Steps to reproduce:

      1) Setup IDM and AM in a "full-stack" deployment
      2) Enable at least one social provider within IDM
      3) Login to IDM as an end-user through AM
      4) Bind the social provider to your account
      5) Review the JSON content of the user's profile

      Expected result: under "/openidm/managed/${provider}/${id}/rawProfile", the content of the object is expected to be the data from the social provider.

      Actual result: the data within "rawProfile" is the content fetched from the AM profile, rather than the social provider.




            • Assignee:
              krismy.alfaro Krismy Alfaro
              jake.feasel Jake Feasel
              QA Assignee:
              Alexander Dracka
            • Votes:
              0 Vote for this issue
              6 Start watching this issue


              • Created: