Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-16723

OIDC Connect Nodes does not work on SubRealm with another AM OpenId Provider

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Not a defect
    • Affects Version/s: 6.5.2.3, 7.0.0
    • Fix Version/s: None
    • Component/s: authentication, trees
    • Labels:
      None
    • Environment:
      Non-DNS alias subrealm
    • Rank:
      1|i01ylz:

      Description

      Bug description

      When the AM social node is in a subrealm and using an external AM as the OIDC provider there is issues getting this to work due to fact that the redirect callback does not go back to the actual realm when the AM nodes

      How to reproduce the issue

      1. Setup 2 AM with different cookie domain (or use host cookies)
      2. For AM1, say the client, create a new realm /oidc and in this realm create a default authtree service oidcTree that test the OIDC Connect node. (see sample amtree attachment)
      3. The OIDC Connect with use a 2nd AM, which is a OpenID Provider (for simplity all these can be set on the root realm)
      4. Test authenticating to AM1 (for testing this OIDC connection to AM2)
      Expected behaviour

      There should be some way to make subrealm work such that this does not rely on DNS alias or some proxy to rewrite the redirect uri to provide the "realm" to continure the authentication.

      Current behaviour
      Fail to authenticate as it fails with some exceptions like
      
      [CONTINUED]org.forgerock.openam.auth.node.api.NodeProcessException: Node processing failed
              at org.forgerock.openam.auth.trees.engine.AuthTreeExecutor.process(AuthTreeExecutor.java:146)
              at org.forgerock.openam.core.rest.authn.trees.AuthTrees.processTree(AuthTrees.java:464)
              at org.forgerock.openam.core.rest.authn.trees.AuthTrees.evaluateTreeAndProcessResult(AuthTrees.java:280)
              at org.forgerock.openam.core.rest.authn.trees.AuthTrees.invokeTree(AuthTrees.java:272)
              at org.forgerock.openam.core.rest.authn.RestAuthenticationHandler.authenticate(RestAuthenticationHandler.java:228)
              at org.forgerock.openam.core.rest.authn.http.AuthenticationServiceV1.authenticate(AuthenticationServiceV1.java:157)
      Caused by: org.forgerock.json.JsonValueException: /state: Expecting a value
              at org.forgerock.json.JsonValue.required(JsonValue.java:1215)
              at org.forgerock.oauth.clients.oidc.OpenIDConnectClient.handlePostAuth(OpenIDConnectClient.java:262)
              at org.forgerock.openam.auth.nodes.oauth.AbstractSocialAuthLoginNode.getUserInfo(AbstractSocialAuthLoginNode.java:340)
              at org.forgerock.openam.auth.nodes.oauth.AbstractSocialAuthLoginNode.processOAuthTokenState(AbstractSocialAuthLoginNode.java:224)
              at org.forgerock.openam.auth.nodes.oauth.AbstractSocialAuthLoginNode.process(AbstractSocialAuthLoginNode.java:165)
              at org.forgerock.openam.auth.trees.engine.AuthTreeExecutor.process(AuthTreeExecutor.java:143)
              ... 118 common frames omitted
      

      Work around

      Use DNS Alias for subrealm (for the authentication URL) and the redirect URL used (otherwise it seems the state issue happens). Even if one set the DNS alias in the redirect url if the authenticationis not thru DNS alias this is still a problem

      Code analysis

      Q: How do the redirect know to go back to the right realm? (since the document for the RedirectURL state to put <AM_URL>/openam (and redirect url cannot have query parameter). It seems this is not possible even now

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            chee-weng.chea C-Weng C
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: