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

Realm associated with OAuth2 tokens is not normalised

    Details

    • Sprint:
      Sprint 82 - Sustaining, Sprint 83 - Sustaining, Sprint 84 - Sustaining, Sustaining Sprint 10
    • Support Ticket IDs:

      Description

      This may also occur during other methods of OAuth2 token creation, but for the purposes here I've only tested using password grant and the initial refresh and access tokens created at this point.

      curl --request POST --user "oauth2client:password" --data "grant_type=password&username=demo&password=changeit"  "http://openam.example.com:8080/openam/oauth2/access_token?realm=/test/"
      

      When making the initial request you can pass in the realm with or without extra slashes and it will still normalise and find the right realm and OAuth2Provider. e.g. /test, test and /test/ all result in successful login/access_token.

      However, when the tokens are created/saved, the original 'passed in' realm value is stored, e.g:

          coreTokenString08 = test
          coreTokenString08 = /test/
          coreTokenString08 = /test
      

      If this value is ever read back out and compared against the realm again, results may be inconsistent.

      An example within OpenAM of where this doesn't work is when a user requests their tokens via /frrest/oauth2/token/?_queryId=access_token

      OpenAM uses the version of the realm from the users session which in this case is '/test' and uses it in the LDAP search:

      [16/Apr/2015:03:49:46 +0100] SEARCH REQ conn=8 op=244 msgID=245 base="ou=famrecords,ou=openam-session,ou=tokens,dc=openam,dc=forgerock,dc=org" scope=wholeSubtree filter="(&(objectClass=frCoreToken)(&(coreTokenString03=demo)(coreTokenString08=/test)))" attrs="ALL"
      

      Therefore if the initial token was not created with exactly this string then it won't match the token on retrieval even though it was 'valid' at grant/auth time.

      I think the most desirable solution to this would be to use a normalised or looked up version of the realm name when writing it to the new token. This will then be predictable/consistent when retrieved by something else later.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                sachiko Sachiko Wallace
                Reporter:
                ian.packer Ian Packer [X] (Inactive)
              • Votes:
                2 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 4h
                  4h
                  Remaining:
                  Remaining Estimate - 4h
                  4h
                  Logged:
                  Time Spent - Not Specified
                  Not Specified