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

Realm associated with OAuth2 tokens is not normalised


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


      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.


          Issue Links



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


                • Created:

                  Time Tracking

                  Original Estimate - 4h
                  Remaining Estimate - 4h
                  Time Spent - Not Specified
                  Not Specified