Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-6237

JASPI: Principal does not get registered with the session when request is forwarded/dispatched

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Won't Do
    • Icon: Major Major
    • None
    • 10.0.0.Final
    • Security
    • None

    • Java 8u74, OS X 10.11

    • Hide

      I've setup a sample project that you can find at https://github.com/roamingthings/jaspic-sample-test.
      After starting the project and navigating to index.xhtml you will find links to login with and without forwarding after a successful login. When using the Link to login without forwarding you will be able to access the protected resource and any other page as authorized user.
      In case you are using the link with forwarding you will not be able to access the protected resource. When opening the index.xhtml page you can see that there is no user principal associated with the request.

      Show
      I've setup a sample project that you can find at https://github.com/roamingthings/jaspic-sample-test . After starting the project and navigating to index.xhtml you will find links to login with and without forwarding after a successful login. When using the Link to login without forwarding you will be able to access the protected resource and any other page as authorized user. In case you are using the link with forwarding you will not be able to access the protected resource. When opening the index.xhtml page you can see that there is no user principal associated with the request.

      Up to WildFly 9 I had a working JASPI SAM that would register a successful authentication by using messageInfo.getMap().put("javax.servlet.http.registerSession", TRUE.toString()); and then forward the request using request.getRequestDispatcher(target).forward(request, response);.
      The Module stopped working in WildFly 10. The request is forwarded but the authenticated principal is not registered with the session or to be more precise a new session seems to be generated during the dispatch. As a matter of facts the dispatched request will be rejected as unauthorized.
      I'm providing a sample project to reproduce the problem (see below)

              darran.lofthouse@redhat.com Darran Lofthouse
              alxs_jira Alexander Sparkowsky (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: