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

Session Upgrade via REST is not consistent with LVB behaviour

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 12.0.0
    • Fix Version/s: 12.0.0
    • Component/s: session
    • Labels:
    • Sprint:
      Sprint 60, Sprint 61, Sprint 62, Sprint 63, Sprint 64 - Team Tesla, Sprint 65 - Team Tesla, Sprint 71 - Team Tesla
    • Support Ticket IDs:

      Description

      Behaviour of the session upgrade (SU) functionality via REST interface is not consistent with the way it behaves with LVB.

      When module is used

      The case where LVB behaviour of SU when module is specified differs from REST intraface is as follows:

      1. access to openam/UI/Login?module=DataStore
      2. log in screen is presented
      3. log in as demo/changeit
      4. user profile is presented
      5. Access openam/UI/Login?module=DataStore again
      6. user profile is presented
      7. session is not upgraded, the token remains the same

      Via REST:

      1. empty POST to openam/json/authenticate?authIndexType=module&authIndexValue=DataStore
      2. a callback is returned
      3. POST to openam/json/authenticate?authIndexType=module&authIndexValue=DataStore with the callback containing demo/changeit cedentials
      4. SSO token is returned
      5. empty POST to openam/json/authenticate?authIndexType=module&authIndexValue=DataStore&sessionUpgradeSSOTokenId=TOKEN (the same URL as before just with sessionUpgradeSSOTokenId parameter containing the original session token)
      6. a callback is returned
      7. POST to openam/json/authenticate?authIndexType=module&authIndexValue=DataStore with the callback containing demo/changeit cedentials
      8. new SSO token is returned and the old one has been invalidated
      9. session upgrade occurs

      IMHO, when the second post is executed, it's misleading to reply with a callback since OpenAM should be able to reckognise this session as valid and should not upgrade the session.

      Cross realm SU

      In the case of cross realm session upgrade the LVB behaves like this:

      1. access openam/UI/Login?realm=realm1
      2. log in screen is presented
      3. log in as demo/changeit
      4. user profile is presented
      5. access openam/UI/Login?realm=realm1
      6. choice screen is presented asking if the user wants to log out
      7. answer YES
      8. logged out form realm1 and log in screen for realm2 is presented
      9. log in as demo/changeit
      10. user profile is presented
      11. original session is not valid, the new one is, but there was no session upgrade
      12. asnwer NO
      13. original session is intact, there is no other session, there is no session upgrade

      The way REST interface behaviour differs is:

      1. create a session with realm1
      2. make an empty POST to the second realm passing the session upgrade parameter: openam/json/realm2/authenticate?sessionUpgradeSSOTokenId=TOKEN
      3. a choice callback is expected, instead a name and password callback are returned

      If we continue from here, this is what happens:

      1. post the callback with credentials back to realm2
      2. new session is created
      3. old session is destroyed

      Although the result is the same, the process along the way is a bit different.

      Authentication level

      The same case is observed with the authentication level in the following case:

      1. authentication level 0 is requested
      2. choice callback is returned with the choice of all modules that satisfy the requirement including those with higher level
      3. select level 10 module
      4. login screen is presented
      5. log in as demo/change it
      6. user profile screen is presented
      7. request authentication for the level 10
      8. in LVB, user profile screen is presented because this has already been satisfied so no session upgrade occurs
      9. in REST, name and password callbacks are returned requiring new authentication

      Again, in the case of REST upon successful authentication, the old session is upgraded.

      Exactly the same case occurs when the initial authentication level is 10 and then next one 0.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                rich.riley Rich Riley [X] (Inactive)
                Reporter:
                n4al Nemanja Lukic
                QA Assignee:
                Nemanja Lukic
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: