glassfish
  1. glassfish
  2. GLASSFISH-20451

Authenticated user principal is not cached in the web session after initial successful authentication by a JASPIC ServerAuthModule (SAM)

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0_b86_RC2
    • Fix Version/s: 4.0
    • Component/s: security
    • Labels:
      None

      Description

      This is related to https://java.net/jira/browse/GLASSFISH-20317, which has more detail.
      First request to a protected resource gets authenticated successfully by the SAM.
      On the second request, the SAM tries to retrieve the user principal from request.getUserPrincipal() and gets null. However on the third request, request.getUserPrincipal() returns the correct principal in SAM's validateRequest() method!

        Activity

        Hide
        quang.dang added a comment -

        After the ServerAuthModule validates the request, a WebPrincipal is created. At this time the container tries to cache
        the principal in the session( AuthenticatorBase.register() ). However the session has not yet been created! The session will not be created until much later when the jsp's service method is invoked.
        When the second request comes in, the test SAM attemps to retrieve the user principal from the request/session(which wasn't saved in the first request). As a result the test SAM carries out the authentication again and this time it finds a session(thanks to the late session creation near the end of the first request) and the principal gets cached in the session as intended.
        On the third and subsequent requests, the principal is always there as long as the session has not expired. I think the fix is to properly create a session early enough so it is available when AuthenticatorBase.register() is called.

        Show
        quang.dang added a comment - After the ServerAuthModule validates the request, a WebPrincipal is created. At this time the container tries to cache the principal in the session( AuthenticatorBase.register() ). However the session has not yet been created! The session will not be created until much later when the jsp's service method is invoked. When the second request comes in, the test SAM attemps to retrieve the user principal from the request/session(which wasn't saved in the first request). As a result the test SAM carries out the authentication again and this time it finds a session(thanks to the late session creation near the end of the first request) and the principal gets cached in the session as intended. On the third and subsequent requests, the principal is always there as long as the session has not expired. I think the fix is to properly create a session early enough so it is available when AuthenticatorBase.register() is called.
        Hide
        Shing Wai Chan added a comment -

        With the latest code in trunk (with the fix GLASSFISH-20453), I see a different behavior for the test posted in https://java.net/jira/browse/GLASSFISH-20317 .

        In RealmAdapter#validate, we have the following code:

            if (shouldRegister(messageInfo.getMap())) {
                AuthenticatorProxy proxy = new AuthenticatorProxy(authenticator, wp, authType);
                proxy.authenticate(request, response, config);
            } else {
                request.setAuthType((authType == null) ? PROXY_AUTH_TYPE : authType);
                request.setUserPrincipal(wp);
            }
        

        In the first two accesses of protected/a.jsp, we are in the "if" case above and hence, we have "non-null" principal and #isUserInRole("architect") = true.
        In the third access of protected/a.jsp, we are in the "else" case above and have a "non-null" principal and #isUserInRole("architect") = false, hence 403.

        From the debugger, I notice the value of #isUserInRole will change after calling proxy.authenticate.

        I also find that if I access index.jsp first and then to protected/a.jsp, the result is the same.

        Assign the issue to security for further investigation.

        Show
        Shing Wai Chan added a comment - With the latest code in trunk (with the fix GLASSFISH-20453 ), I see a different behavior for the test posted in https://java.net/jira/browse/GLASSFISH-20317 . In RealmAdapter#validate, we have the following code: if (shouldRegister(messageInfo.getMap())) { AuthenticatorProxy proxy = new AuthenticatorProxy(authenticator, wp, authType); proxy.authenticate(request, response, config); } else { request.setAuthType((authType == null ) ? PROXY_AUTH_TYPE : authType); request.setUserPrincipal(wp); } In the first two accesses of protected/a.jsp, we are in the "if" case above and hence, we have "non-null" principal and #isUserInRole("architect") = true. In the third access of protected/a.jsp, we are in the "else" case above and have a "non-null" principal and #isUserInRole("architect") = false, hence 403. From the debugger, I notice the value of #isUserInRole will change after calling proxy.authenticate. I also find that if I access index.jsp first and then to protected/a.jsp, the result is the same. Assign the issue to security for further investigation.
        Hide
        quang.dang added a comment -

        What is the impact on the customer of the bug?
        This is related to https://java.net/jira/browse/GLASSFISH-20317.
        It is necessary to fix this first in order to fix GLASSFISH-20317.

        What is the cost/risk of fixing the bug?
        It's small change, low risk

        Is there an impact on documentation or message strings?
        No.

        Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
        JASPIC related and SQE web tests

        Which is the targeted build of 4.0 for this fix?
        4.0_b88

        If this an integration of a new version of a component from another project,
        what are the changes that are being brought in? This might be list of
        Jira issues from that project or a list of revision messages.
        N/A

        Show
        quang.dang added a comment - What is the impact on the customer of the bug? This is related to https://java.net/jira/browse/GLASSFISH-20317 . It is necessary to fix this first in order to fix GLASSFISH-20317 . What is the cost/risk of fixing the bug? It's small change, low risk Is there an impact on documentation or message strings? No. Which tests should QA (re)run to verify the fix did not destabilize GlassFish? JASPIC related and SQE web tests Which is the targeted build of 4.0 for this fix? 4.0_b88 If this an integration of a new version of a component from another project, what are the changes that are being brought in? This might be list of Jira issues from that project or a list of revision messages. N/A
        Hide
        quang.dang added a comment -

        /branches/4.0/appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java
        Rev. 61824

        Show
        quang.dang added a comment - /branches/4.0/appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java Rev. 61824
        Hide
        quang.dang added a comment -

        Sending appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java
        Transmitting file data .
        Committed revision 61828.
        (trunk)

        Show
        quang.dang added a comment - Sending appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java Transmitting file data . Committed revision 61828. (trunk)

          People

          • Assignee:
            quang.dang
            Reporter:
            quang.dang
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: