Issue Details (XML | Word | Printable)

Key: GLASSFISH-19879
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Tim Quinn
Reporter: sonialiu
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
glassfish

digest authentication security test failed in GF4.0

Created: 14/Mar/13 10:53 PM   Updated: 03/Apr/13 06:10 PM   Resolved: 03/Apr/13 06:10 PM
Component/s: security
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b84_RC1

Time Tracking:
Not Specified

Environment:

linux


Tags: 4_0-approved
Participants: sonialiu and Tim Quinn


 Description  « Hide

This test was blocked by bug 17578. After fixing the bug, I ran the test and it still failed. Here are the steps to reproduce the bug:

1. Install GF4.0, start domain
2. Checkout SQE workspace:
cvs co appserver-sqe/bootstrap.xml
(CVSROOT: :pserver:<your cvs user>@sunsw.us.oracle.com:/m/jws
cd appserver-sqe
ant -f bootstrap.xml co-security
3.set following env. variables
S1AS_HOME <GF install dir>, for example: /export/sonia/v4/glassfish4/glassfish
SPS_HOME <appserver-sqe>, for example: /export/sonia/appserver-sqe
ANT_HOME <ant location>, for example: /export/sonia/ant-1.7.1
JAVA_HOME <java location>, for example: /export/sonia/jdk1.7.0_04
4. cd <workspace dir>/appserver-sqe/, run "ant startDerby" to start derby database
5. cd <workspace dir>/appserver-sqe/pe/security/digestauth, run "ant all"
the test failed and the following exceptions displayed in server.log
[2013-03-14T15:34:52.490-0700] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core.security.com.sun.enterprise.security.auth.login] [tid: _ThreadID=29 _ThreadName=http-listener-1(4)] [timeMillis: 1363300492490] [levelValue: 800] [[
SEC5046: Audit: Authentication refused for [j2ee].]]

[2013-03-14T15:34:52.490-0700] [glassfish 4.0] [WARNING] [web.login.failed] [javax.enterprise.system.container.web.com.sun.web.security] [tid: _ThreadID=29 _ThreadName=http-listener-1(4)] [timeMillis: 1363300492490] [levelValue: 900] [[
WEB9102: Web Login Failed: com.sun.enterprise.security.auth.login.common.LoginException: Login failed: java.lang.NullPointerException
at com.sun.enterprise.security.ee.auth.login.DigestLoginModule.login(DigestLoginModule.java:104)
at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
at com.sun.enterprise.security.auth.login.LoginContextDriver.login(LoginContextDriver.java:992)
at com.sun.web.security.RealmAdapter.authenticate(RealmAdapter.java:523)
at org.apache.catalina.authenticator.DigestAuthenticator.authenticate(DigestAuthenticator.java:302)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1434)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:580)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:702)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:176)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)

-----------------



Tim Quinn added a comment - 03/Apr/13 05:32 AM - edited

I placed a null check in the DigestLoginModule to avoid the NPE, and now I see a different failure in the test. Still looking.

run:
     [echo] running httpdigest client - /scratch/tjquinn/gf/sqe/appserver-sqe/build/pe/i386_adc6140581_Linux/sec/classes
     [java] wait... 
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Entering username and password to digest
     [java] Exception in thread "main" java.net.ProtocolException: Server redirected too many  times (20)
     [java] 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1635)
     [java] 	at org.jvnet.glassfish.comms.test.sec.HttpDigestClient.main(HttpDigestClient.java:47)
     [java] Java Result: 1
     [echo] Waiting for 10 secs ...

Tim Quinn added a comment - 03/Apr/13 05:32 AM

Assigning this to me, at least for the moment.


Tim Quinn added a comment - 03/Apr/13 04:47 PM

In the failing test RealmAdapter.authenticate:581 creates a DigestCredentials object and attaches it to the Subject and then invokes LoginContextDriver.login passing the new credentials.

The DigestLoginModule.login method is invoked as part of LoginContextDriver.login processing, but it looks for the digest creds to process by using an instanceof check on each of the Subject's private credentials. And there is the problem, because DigestLoginModule is checking for

com.sun.enterprise.security.ee.auth.login.DigestCredentials (in the appserver/security/core-ee module)

whereas the RealmAdapter has created a

com.sun.enterprise.security.auth.login.DigestCredentials (in the main/nucleus/security/core module)

Neither class extends the other, so the instanceof check in the DigestLoginModule fails and it never sees the digest credentials and authentication never happens.

A candidate fix in which the DigestLoginModule checks for and works with both types of DigestCredentials allows the failing SQE test to pass.


Tim Quinn added a comment - 03/Apr/13 04:52 PM
  • What is the impact on the customer of the bug?
    This is a regression; SQE tests which passed now fail.
  • What is the cost/risk of fixing the bug?
    The candidate fix is a few lines of code, isolated to one method of one class.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    SQE pe/security tests
  • Which is the targeted build of 4.0 for this fix?
    4.0_b84 (assuming b83 is already done)
  • 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

Tim Quinn added a comment - 03/Apr/13 06:10 PM

Fix checked in.

Project: glassfish
Repository: svn
Revision: 61146
Author: tjquinn
Date: 2013-04-03 18:08:42 UTC
Link:

Log Message:
------------
Fix for GLASSFISH-19879 - digest authentication security test failed in GF4.0

RealmAdapter.authenticate:581 creates a DigestCredentials object and attaches it to the Subject and then invokes LoginContextDriver.login passing the new credentials.

The DigestLoginModule.login method is invoked as part of LoginContextDriver.login processing, but it looks for the digest creds to process by using an instanceof check on each of the Subject's private credentials. And there is the problem, because DigestLoginModule is checking for

com.sun.enterprise.security.ee.auth.login.DigestCredentials (in the appserver/security/core-ee module)

whereas the RealmAdapter has created a

com.sun.enterprise.security.auth.login.DigestCredentials (in the main/nucleus/security/core module)

Neither class extends the other, so the instanceof check in the DigestLoginModule fails and it never sees the digest credentials and authentication never happens.

With this change the DigestLoginModule checks for and works with both types of DigestCredentials allows the failing SQE test to pass.

Reviewed: Jeff T.
Approved: Michael C.
Tests: QL, the failing SQE test

Revisions:
----------
61146

Modified Paths:
---------------
trunk/main/appserver/security/core-ee/src/main/java/com/sun/enterprise/security/ee/auth/login/DigestLoginModule.java