[GLASSFISH-20451] Authenticated user principal is not cached in the web session after initial successful authentication by a JASPIC ServerAuthModule (SAM) Created: 01/May/13  Updated: 04/May/13  Resolved: 04/May/13

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: quang.dang Assignee: quang.dang
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved


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!

Comment by quang.dang [ 01/May/13 ]

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.

Comment by Shing Wai Chan [ 02/May/13 ]

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);

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.

Comment by quang.dang [ 02/May/13 ]

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?

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?

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.

Comment by quang.dang [ 04/May/13 ]

Rev. 61824

Comment by quang.dang [ 04/May/13 ]

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

Generated at Sun Feb 14 11:36:50 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.