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

API compatibility behaviour issue when calling with a DNS alias

    Details

      Description

      Bug description

      When I set up the REST API compatibility of Resource and Protocol by default to Latest and I call the API using a DNS alias on the session validation I have unexpected behaviour. 

      I tested the Authentication API and I get a slightly different unexpected behaviour.

      How to reproduce the issue

      1) AM 6.5.2.1 console (untested in other AM consoles) Create a realm with a DNS alias

      2) Set up the REST API compatibility (Configure > Global Services > REST APIs):
      Resource: Latest
      Protocol: Latest
      CSRF check: OFF

      Example 1) run command to check session using the root DNS (open-local.example.com):

      _curl --location --request POST 'http://openam-local.example.com:8080/am/json/sessions?_action=validate&realm=testrealm' _
      _--header 'Content-Type: application/json' _
      _--header 'Accept-API-Version: resource=2.1, protocol=1.0' _
      --data-raw '{"tokenId": "Fj_l..." }'

      Expected behaviour

      {    "valid": true,    "sessionUid": "5eb5dc30-52f0-439f-a635-06d7cf14f386-249854",    "uid": "demo",    "realm": "/testrealm"}
      Current behaviour
      {    "valid": true,    "sessionUid": "5eb5dc30-52f0-439f-a635-06d7cf14f386-249854",    "uid": "demo",    "realm": "/testrealm"}

       

       

      Example 2) Run command to check session using the alias DNS (test-local.example.com):
      _curl --location --request POST 'http://test-local.example.com:8080/am/json/sessions?_action=validate' _
      _--header 'Content-Type: application/json' _
      _--header 'Accept-API-Version: resource=2.1, protocol=1.0' _
      --data-raw '{"tokenId": "Fj_l..." }'

      Expected behaviour

      {    "valid": true,    "sessionUid": "5eb5dc30-52f0-439f-a635-06d7cf14f386-249854",    "uid": "demo",    "realm": "/testrealm"}
      Current behaviour
      {    "valid": false}

      Example 3)

      _curl --location --request POST 'http://test-local.example.com:8080/am/json/sessions?_action=validate' _
      _--header 'Content-Type: application/json' _
      --data-raw '{"tokenId": "Fj_l..." }'

      Expected behaviour

      {    "valid": true,    "sessionUid": "5eb5dc30-52f0-439f-a635-06d7cf14f386-249854",    "uid": "demo",    "realm": "/testrealm"}
      Current behaviour
      {    "valid": true,    "sessionUid": "5eb5dc30-52f0-439f-a635-06d7cf14f386-249854",    "uid": "demo",    "realm": "/testrealm"}

      Example 4)

      Resource: Latest
      Protocol: Latest
      CSRF check: ON

       

      _curl --location --request POST 'http://openam-local.example.com:8080/am/json/sessions?_action=validate&realm=testrealm' _
      _--header 'Content-Type: application/json' _
      _--header 'Accept-API-Version: resource=2.1, protocol=1.0' _
      --data-raw '{"tokenId": "Fj_l..." }'

      Expected behaviour

      {    "valid": true,    "sessionUid": "5eb5dc30-52f0-439f-a635-06d7cf14f386-249854",    "uid": "demo",    "realm": "/testrealm"}
      Current behaviour
      {    "valid": true,    "sessionUid": "5eb5dc30-52f0-439f-a635-06d7cf14f386-249854",    "uid": "demo",    "realm": "/testrealm"}

      Example 5) Run command to check session using the alias DNS (test-local.example.com):

      curl --location --request POST 'http://openam-local.example.com:8080/am/json/sessions?_action=validate&realm=testrealm' \
      --header 'Content-Type: application/json' \
      --header 'csrf: Fj_l...' \
      --data-raw '{"tokenId": "Fj_l..." }'

      Expected behaviour

      {    "valid": true,    "sessionUid": "5eb5dc30-52f0-439f-a635-06d7cf14f386-249854",    "uid": "demo",    "realm": "/testrealm"}
      Current behaviour
      403

      Example 6)

      curl --location --request POST 'http://test-local.example.com:8080/am/json/sessions?_action=validate' \
      --header 'Content-Type: application/json' \
      --header 'Accept-API-Version: resource=2.1, protocol=1.0' \
      --header 'csrf: Fj_l...' \
      --data-raw '{"tokenId": "Fj_l..." }'

      Expected behaviour

      {    "valid": true,    "sessionUid": "5eb5dc30-52f0-439f-a635-06d7cf14f386-249854",    "uid": "demo",    "realm": "/testrealm"}
      Current behaviour
      {    "valid": false}

      Therefore I think there are two issues:
      1) Setting Resource or Location to Latest or Oldest does not allow backward compatibility

      2) the CSRF setting is driving outcomes on the Resource and Protocol settings

      This creates an additional issue that "old" APIs and "new" APIs cannot co-exist.

       

      Work around

      Don't know
      NB: I checked another API (Authenticate) and I found a similar behaviour where setting the CSRF value affects the outcome of the Resource and Protocol calls.

        Attachments

          Activity

            People

            • Assignee:
              peter.major Peter Major [X] (Inactive)
              Reporter:
              gery.ducatel Gery Ducatel
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: