Uploaded image for project: 'OpenAM Agents'
  1. OpenAM Agents
  2. AMAGENTS-2369

JASPA does not handle token expiry if notifications are disabled, not working, or slow

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5.5.1.0, 5.6.0.0, 5.1.0.0, 5.5.0.0
    • Fix Version/s: 5.6.0.0, 5.5.2.0
    • Component/s: J2EE Agents
    • Labels:
    • Target Version/s:
    • Verified Version/s:
    • Sprint:
      2018.16 - Tin
    • Support Ticket IDs:

      Description

      JASPA relies solely on the notification mechanism to be told when a session has expired.  This is as opposed to the Agents 3 mechanism where every request caused the agent to re-validate the token with AM (causing much network traffic). When things work as normal, the following takes place:

      1. A user with a valid session accesses a resource
      2. The session is not known by the agent
      3. The agent validates the session by requesting profile attributes/session properties from AM
      4. As the session is valid, AM returns the results and the agent caches the information
      5. Policy evaluation request is made, access is either granted or denied based on the results of the evaluation
      6. The session expires, firing the notification mechanism
      7. Notification mechanism clears the cache of session information
      8. A resource request comes in
      9. The session is no longer cached and is thus unknown to the agent
      10. The agent validates the session by requesting profile attributes/session properties from AM
      11. The response from AM is that the session is not valid
      12. The agent redirects the user to the authn endpoint

      Contrast this with the behaviour when either the notification mechanism is not working, or there is some delay in sending or processing the notification:

      1. A user with a valid session accesses a resource
      2. The session is not known by the agent
      3. The agent validates the session by requesting profile attributes/session properties from AM
      4. As the session is valid, the agent caches information returned in 3
      5. Policy evaluation request is made, access is either granted or denied based on the results of the evaluation
      6. The session expires, but due to problems with notifications, the cache is not cleared
      7. A resource request comes in using the existing (now expired) session
      8. As the session is cached, the agent proceeds to policy evaluation
      9. AM fails the evaluation with code 400 and message "Invalid value subject"
      10. The agent panics as this response is unexpected
      11. The agent returns 404, access denied, rather than redirecting to the authn endpoint.

      The end result is the agent does not redirect to the authn endpoint, whereas this is expected.

      Steps to reproduce:

      1. For Agent 6, in the config for the agent, set the property org.forgerock.agents.session.change.notifications.enabled to false (most easily done via custom properties)
      2. For Agent 5.x, set the property com.iplanet.am.session.client.polling.enable to true
      3. Attempt to access a resource, doesn't matter whether you should or shouldn't be able to access it
      4. Log in and either access the resource or not.
      5. Kill your session in AM
      6. Attempt to access a different resource.
      7. If all goes well, you will be invited to log in, if all goes badly, you'll see a 404.

        Attachments

          Activity

            People

            Assignee:
            tony.bamford Tony Bamford
            Reporter:
            tony.bamford Tony Bamford
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: