[Pki-devel] [fedora-java] Tomcat, NSS and OpenJDK

Andrew Wnuk awnuk at redhat.com
Tue Oct 4 22:27:17 UTC 2011


Adding Bob and Elio.

On 10/04/2011 02:49 PM, Adam Young wrote:
> On 10/04/2011 04:47 PM, Dr Andrew John Hughes wrote:
>> On 20:58 Mon 03 Oct     , Adam Young wrote:
>>> Tomcat has a class called "Realm" which is basically a way of managing
>>> the set of authentication mechanisms.  PKI seems To use an older
>>> approach which bypasses the Realm  config in Tomcat.  I started looking
>>> at what it would take to close the distance between the two.  In doing
>>> so, I found something interesting in the openjdk code base:
>>>
>>> In /usr/lib/jvm/java-1.6.0/jre/lib/security/java.security,  there is a
>>> section that looks like this:
>>> #
>>> # List of providers and their preference orders (see above):
>>> #
>>> security.provider.1=sun.security.provider.Sun
>>> security.provider.2=sun.security.rsa.SunRsaSign
>>> ...
>>> # the NSS security provider was not enabled for this build; it can be
>>> enabled
>>> # if NSS (libnss3) is available on the machine. The nss.cfg file may 
>>> need
>>> # editing to reflect the location of the NSS installation.
>>> #security.provider.9=sun.security.pkcs11.SunPKCS11
>>> ${java.home}/lib/security/nss.cfg
>>>
>> This is added by IcedTea, which can enable NSS support during the build.
>> However, from the commenting, it seems the option has not been turned 
>> on in the
>> Fedora packages.
>>
>> If you check /usr/lib/jvm/java-1.6.0-openjdk/lib/security/nss.cfg 
>> points at
>> your NSS install, then uncommenting that line should allow Java to 
>> use NSS
>> for cryptography.
>
>
> I did that on my system and got it to work.  I also went through the 
> steps to do it programmatically from Java code:
>
>  Class providerClass = Class.forName("sun.security.pkcs11.SunPKCS11");
>         System.out.print("found class");
>         Provider provider =  (Provider) 
> providerClass.getConstructor(String.class).newInstance("/usr/lib/jvm/java-1.6.0-openjdk.x86_64/jre/lib/security/nss.cfg");
>         Security.addProvider(provider);
>
>
> I'm sure there is a better approach, this was just the quickest to hack.
>
>>
>>> So it seems that Sun had, at least in the past, supported  NSS as a
>>> Sercurity provider.  For the member of the Java team not familiar with
>>> NSS (I wasn't) It is the Network Security Services and is the basis 
>>> for,
>>> amongst other things, how Mozilla stores passwords and certificates.
>>> PKI makes pretty heavy use of NSS, via the Opensource Java bindings 
>>> in JSS.
>>>
>>> This page here has more info:
>>>
>>> http://download.oracle.com/javase/1.5.0/docs/guide/security/p11guide.html#Intro 
>>>
>>>
>>> It seems like the Oracle JDK has had support in the past for NSS as a
>>> JAAS module.  To close the acronym loop with Tomcat, Tomcat has a JAAS
>>> Realm  class.  What this says to me is that, at one point, Java
>>> developers could have configured Tomcat to use NSS as the 
>>> authentication
>>> mechanism for an application.
>> AIUI, the JDK implementation just uses NSS to provide cryptography 
>> algorithms,
>> not authentication.
>
> Hmmm...seems to me that if you can use it to look at and validate a 
> certificate, you should be able to get the principal from it.  But we 
> are probably going to use LDAP as the JAAS  piece anyway, as that is 
> where all of the Users and ACIs live, so that might be OK.  I'm not 
> certain that it makes sense to get roles out of an NSS database for 
> any but the smallest applications.
>
>>
>>> This class ships in the  file:
>>>
>>> /usr/lib/jvm/java-1.6.0-openjdk.x86_64/jre/lib/ext/sunpkcs11.jar
>>>
>>> And The native library is in
>>>
>>> /usr/lib/jvm/java-1.6.0-openjdk.x86_64/jre/lib/amd64/libj2pkcs11.so
>>>
>>>
>>> So it looks like we might have an additional Java implementation of NSS
>>> available, one that can potentially provide  NSS support for Tomcat and
>>> JBoss  via JAAS.  It looks like all it requires is a change to the
>>> configuration file that we ship.  I'm not quite sure how we would go
>>> about doing this in an automated fashion, short of pulling in 
>>> libnss3 as
>>> part of Open JDK support.  I'm guessing that if we enable it and the 
>>> nss
>>> library is missing it errors our in some ugly manner, but I have not
>>> tested it.
>> The Fedora java-1.6.0-openjdk package would need to be altered to pass
>> --enable-nss to configure and to depend on libnss3 (as you say).
>>
>> I can't remember exactly how it errors out off-hand and I've never 
>> had a system
>> without NSS on to see that on!  If you have Firefox, you have NSS.
>>
>>> Is anyone familiar with this code?
>> I am; I added the support in IcedTea and fix some bugs in the NSS
>> code upstream (which took forever; the security-dev OpenJDK people
>> at Oracle are very slow to respond in my experience).
>
>
> Thank you.  Very nicely done!
>>
>>> Would it be acceptable to activate
>>> this security module by default and to pull in libnss with Java?  Is
>>> there some automated way to enable this if NSS is installed?
>> Debian and Ubuntu do enable it, and the option is there as a USE flag
>> in Gentoo.  However, an issue did come up regarding it and Firefox:
>>
>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=473
>>
>> which may be a blocker.  As I say, the process of enabling it is just a
>> two line change in the java-1.6.0-openjdk spec file.
>
>
> Yes, we would want to wait until we had a resolution for that issue.  
> I hear that a change is coming for NSS due to enough people hitting 
> this, but I do not know the time frame.
>
>
>
>>
>>> -- 
>>> java-devel mailing list
>>> java-devel at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/java-devel
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




More information about the Pki-devel mailing list