JCK tests verify that AuthProvider implementation throw LoginException if the login operation fails. 
sun.security.pkcs11.SunPKCS11.login throws NPE if null value passed to the method. This behaviour contradicts with the spec.

/net/archer/export5/re/jck/6a/nightly/qac/b06-2007- customer -08/binaries/JCK-runtime-6a/classes javasoft.sqe.tests.api.java.security.AuthProvider.loginTests
----------out1:(144/9497)----------
Provider XMLDSig: Passed. Not AuthProvider. Skiped.
Provider SUN: Passed. Not AuthProvider. Skiped.
Provider SunJSSE: Passed. Not AuthProvider. Skiped.
Provider SunPCSC: Passed. Not AuthProvider. Skiped.
Provider SunJCE: Passed. Not AuthProvider. Skiped.
Provider SunSASL: Passed. Not AuthProvider. Skiped.
java.lang.NullPointerException
	at sun.security.pkcs11.SunPKCS11.login(SunPKCS11.java:1049)
	at javasoft.sqe.tests.api.java.security.AuthProvider.loginTests$1.run(loginTests.java:84)
	at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithTCKSM(SecurityTestRunner.java:278)
	at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithPermissions(SecurityTestRunner.java:235)
	at javasoft.sqe.jck.lib.SecurityTestRunner.runTestWithAllPermissions(SecurityTestRunner.java:157)
	at javasoft.sqe.jck.lib.AllPermissionSM.testRun(AllPermissionSM.java:86)
	at javasoft.sqe.jck.lib.AllPermissionSM.testRun(AllPermissionSM.java:111)
	at javasoft.sqe.tests.api.java.security.AuthProvider.loginTests.login001(loginTests.java:94)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at javasoft.sqe.javatest.lib.MultiTest.invokeTestCase(MultiTest.java:406)
	at javasoft.sqe.jck.lib.ProviderTest.invokeTestCase(ProviderTest.java:286)
	at javasoft.sqe.javatest.lib.MultiTest.run(MultiTest.java:195)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.sun.jck.lib.ExecJCKTestSameJVMCmd$Version2Test.execute(ExecJCKTestSameJVMCmd.java:461)
	at com.sun.jck.lib.ExecJCKTestSameJVMCmd$StandardTest.run(ExecJCKTestSameJVMCmd.java:373)
	at com.sun.jck.lib.ExecJCKTestSameJVMCmd.execute(ExecJCKTestSameJVMCmd.java:241)
	at com.sun.jck.lib.ExecJCKTestSameJVMCmd.run(ExecJCKTestSameJVMCmd.java:142)
	at com.sun.javatest.agent.Agent$Task.executeCommand(Agent.java:822)
	at com.sun.javatest.agent.Agent$Task.execute(Agent.java:753)
	at com.sun.javatest.agent.Agent$Task.handleRequest(Agent.java:614)
	at com.sun.javatest.agent.Agent.handleRequestsUntilClosed(Agent.java:381)
	at com.sun.javatest.agent.Agent.access$000(Agent.java:41)
	at com.sun.javatest.agent.Agent$1.run(Agent.java:253)
	at java.lang.Thread.run(Thread.java:619)
login001: Failed. Test case throws exception: java.lang.NullPointerException
Provider XMLDSig: Passed. Not AuthProvider. Skiped.
Posted Date : 2007-02-13 16:14:54.0

Failed tests:
api/java_security/AuthProvider/ProviderTests.html#login[login001]
api/java_security/AuthProvider/ProviderTests.html#login[login002]
api/java_security/AuthProvider/ProviderTests.html#login[login003]
Posted Date : 2007-02-13 17:22:24.0

These tests failed only when running in Java plugin, the failure reproduced constantly.
Posted Date : 2007-03-19 17:46:58.0

First of all, run tests in Java plugin is a standard feature of JavaTest. JavaTest UG desribes all neccesary steps!
In addition, the failing tests can be run via JCK QA scripts:

1. ssh moonblade.russia.sun.com
2. mkdir -p /tmp/ProviderTests/tmp
3. mkdir -p /tmp/ProviderTests/workdir
4. mkdir -p /net/archer.russia.sun.com/export4/jck/tmp/ProviderTests/resultsdir
5. export TEMP=/tmp/ProviderTests/tmp
6. cd /net/archer.russia.sun.com/export4/jck/sqe-bin/QATools/bin
7. ./qa_latest -tc p002 -tcsuff _ProviderTests -testtype promoted -mailto <e-mail_address> -iu api/java_security/AuthProvider/ProviderTests.html -display moonblade.russia.sun.com:0.0 -workdir /tmp/ProviderTests/workdir -resultsdir /net/archer.russia.sun.com/export4/jck/tmp/ProviderTests/resultsdir
Posted Date : 2007-03-26 15:35:18.0

N/A

I don't observe any JCK test failure using both the official jdk6 b105 and my own jdk7 builds on Solaris 10. The JCK tests are executed as:
-----------------
/java/re/jdk/6.0/promoted/fcs/b105/binaries/solaris-sparc/bin/java -showversion -classpath /java/re/jck/6a/nightly/qac/b06-2007-02-08/binaries/JCK-runtime-6a/classes:/java/re/jck/6a/nightly/qac/b06-2007-02-08/binaries/JCK-runtime-6a/lib/javatest.jar javasoft.sqe.tests.api.java.security.AuthProvider.loginTests
-----------------

The output looks fine too. Sample messages:
Provider XMLDSig: Passed. Not AuthProvider. Skiped.
Provider SUN: Passed. Not AuthProvider. Skiped.
...
Provider SunSASL: Passed. Not AuthProvider. Skiped.
Provider SunPKCS11-Solaris: Passed. OKAY
Provider SunRsaSign: Passed. Not AuthProvider. Skiped.
Provider SunJGSS: Passed. Not AuthProvider. Skiped.

So, I am marking this bug "incomplete" for now so that submitter can verify if this bug can still be reproduced on his end.
Posted Date : 2007-03-16 18:33:59.0

It's unclear why these tests only fail when running in Java Plugin. Thus, please provide detailed information on how these tests are executed.
Again, marking this w/ "incomplete - need more info".
Posted Date : 2007-03-21 03:40:30.0

I can only reproduce the problem with a given test account.
After further troubleshooting, it appears that Sun softtoken impl does not fully work when running under that particular account.

For example, if you run the following command line:
--------------------------------------------------------------------------
$ cryptoadm list -v provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so
Number of slots: 1

Slot #1
Description: Sun Crypto Softtoken                                            
Manufacturer: Sun Microsystems, Inc.          
PKCS#11 Version: 2.11
Hardware Version: 0.0
Firmware Version: 0.0
Token Present: False
Slot Flags: 
/usr/lib/security/$ISA/pkcs11_softtoken.so: failed to retrieve the mechanism list.
--------------------------------------------------------------------------

I tried to inspect the default keystore used by Sun softtoken impl with pktool but the "<user home>/.sunw/pkcs11_softtoken" directory is not there. Nor do I get expected behavior when running "pktool setpin" command.

Thus, this suggests that the problem is in the account setup and not Sun's PKCS#11 provider.

Changing the status to Incomplete/Other until further confirmation from the submitter.
Posted Date : 2007-06-01 00:46:45.0

Re-assigning it to solaris softtoken category since it's agreed that the root cause is due to an inconsistency with PKCS#11 spec.
Also update the synopsis accordingly.
Posted Date : 2007-07-27 21:52:38.0

As Yu-ching Peng stated, the test account has a problem.  Given the investigation she and I have done, it is clear that the test user does not have access to it's home directory and the system is operating as expected..

Without access to the home directory, softtoken is not operating at full functionality, it can still provide crypto services, but not perform token object support.  Given this is a conformance test, it is within spec in this case to report the provider as not properly functioning..
Posted Date : 2007-07-30 21:39:17.0

Solaris softtoken team is hesitant about changing the return value, thus SunPKCS11 provider would have to make necessary adjustments.
Although Solaris softtoken impl can still perform some crypto operations, e.g. RSA keypair generations, existing SunPKCS11 provider impl has dependency on token be present and would generally not able to function. Given the rarity of such accounts, the fix is to disable SunPKCS11 provider when keystore is unaccessible.
Posted Date : 2007-08-09 02:51:27.0