Java Technology Home Page
A-Z Index

Java Developer Connection(SM)
Chat

Downloads, APIs, Documentation
Java Developer Connection
Tutorials, Tech Articles, Training
Online Support
Community Discussion
News & Events from Everywhere
Products from Everywhere
How Java Technology is Used Worldwide
Print Button
 
JavaLive Transcripts Index

Security Chat
August 22, 2000



Guest Speakers are Jeff Nisewanger and Gary Ellison

This is a moderated forum

Ed: Welcome to today's Java Live! session on security features in J2SETM version 1.3 Our guests are Sun engineers Jeff Nisewanger and Gary Ellison, two key members of Sun's JavaTM 2 Platform security team. They'll answer your security-related questions, especially on new security features in J2SE version 1.3 So let's begin. Who has the first question?

ernesto: Security includes encryption?

gary: ernesto, yes the security group is also responsible for the encryption elements in the Java 2 platform. This includes JavaTM Cryptography Architecture (JCA) and JavaTM Cryptography Extension (JCE).

Gino: The sample program that accompanies the JavaTM Authentication and Authorization Service (JAAS) Developer's guide only works properly if the first login attempt is successful. Second or third attempts (only three are allowed), though successful, do not retain the Principals assigned in the Login Modules. The only fix I could come up with was to instantiate a newLoginContext object for each login() call. Is this the correct behavior or is there a bug in the JDK LoginContext implementation?

Jeff: Gino, I'm not sure offhand what the answer to your question is. I don't work on JAAS internals day-to-day although it is developed in our group. You should probably file a bug report against JAAS through the JDC bug page and we'll get you an answer.

jtr: The security features in JDKTM 1.3 are pretty thorough, as far as client data is concerned. However, they are hard to use, especially for the common user. Editing policy files by hand is trouble-prone.The GUI tool is almost a case study for usability problems. Are there any efforts to make this security easier to use? JavaTM Web Start is a good starting point for making security easier to code as well as easier to use, but its security needs to be more fine-grained. Will we see more security APIs in Java Web Start?

Gino: For a servlet container that provides it's own ClassLoader (perhaps to support reloading of servlets), is it incumbent on the vendor to ensure that the ClassLoader honors the JSA when the JavaTM Virtual Machine1 is run with a security manager installed? For example, should one expect that the associated ProtectionDomain for the servlet class properly identify the CodeSource (URL and certificates) and Permissions? The latest servlet spec does not seem to address the issue of using JSA-based security in a servlet environment.

gary: jtr, We realize that the tools provided to manage policy are less than intuitive. We are looking at a number of alternatives to provide a better integration of Policy, Signing and Key management. Java Web Start should ease some deployment issues. To the best of my knowledge the Web Start team will not be developing any new APIs.

Jeff: Gino, if your class loader subclasses java.net.URLClassLoader or is a direct instance of URLClassLoader then the business with CodeSources and ProtectionDomains should be automatic. If you subclass, you just need to follow the normal rules for implementing a ClassLoader's various protected methods for finding the classes and resources.

JLearn: Hi, I been through hell and back trying to deploy an applet that needs to work outside the sand box. Can you help me with this? Currently, I sign either a .cab file or .jar file. I also install the application on the client side via java script or cab file installation. This is very sloppy! Can you help me?

Gino: Jeff, I actually did that a few weeks back. No response as yet. FYI - the 'internal review id' was 107911.

test: Am I correct in assuming that the recently-found security bug (dubbed "Brown Orifice") in Netscape 4.x does not apply to J2SE 1.3 or to a corresponding plug -in?

Jeff: Gino, I'll make a note of the bug number. Thanks.

gary: JLearn, I can't speak specifically to the problems you are having with the various browser implementations. However I would suggest that you take a look at the Java PluginTM. In version 1.3 it has a new extension loading mechanism which can ease your deployment problems. More information is on the Plugin product page on java.sun.com.

Gino: Jeff, the class loader actually subclasses ClassLoader, which may in part explain some of the problems I've been having. FYI - it's not my code. I'm trying to use a third-party application server (without naming names, unless anyone is interested).

Jeff: Right, the "Brown Orifice" exploit does not work in a Java 2 environment and only the much less significant ServerSocket part of it would work on a Sun reference implementation of JDK 1.1. We will be releasing patches for JDK 1.1 soon.

ernesto: Do you have a light encryption package that can go outside of the USA?

gary: ernesto, the next version of JCE v1.2.1 which is currently in beta has been designed so that the framework can be exported. Check out the feature description on java.sun.com.

KarlScheibelhofe: I heard that you are working on improvements on JCA/JCE to ease the integration of crypto hardware in java. I would have some suggestions. I built a JCA/JCE provider that uses smart cards for signing, so I gained some experience there.

Jeff: Gino, if your 3rd-party class loader directly subclasses java.lang.ClassLoader then you may be stuck with using a custom SecurityManager as in JDK 1.1. Sorry.

rwclark: Where is the security in allowing editable files of PERMISSIONS to reside within reach of the user?

gary: KarlSche, we are open to hearing any details of your experience in this matter. I am personally working with the OpenCard Consortium with this issue as well. You may want to post your experience on their mailing list, which can be found at www.opencard.org. Also you can send the details to java-security@sun.com

Gino: Are there any plans to 'unify' the servlet security model and JAAS? For example, one could specify a new 'JAAS' authorization method which uses the user/groups/roles defined for the web application.

Jeff: rwclark, if you don't trust your users, you can have them run a JRE which has been installed on a network file server or locally in such a way that the user does not have permission to modify the installation. You can then configure the jre/lib/security/java.security file so that it will not look for a local user-specific policy file in their "home directory" and instead will only look for the ones configured by a system administrator. In java.security you will see that the list of security policy files to look for is configurable.

test: What additional security features or enhancements could we expect to see in the future?

gary: Gino, one thing that is currently under consideration is making JAAS part of J2EE. This is in the very early stages of evaluation, and so I have no other information about time frame or whether it will actually happen.

Gino: In order to implement one's own JAAS policy persistence (say in a database), one must provide both a java.security.Policy class and a javax.security.auth.Policy class. I'd heard there were plans to 'merge' these two classes . Is this still the case and could you comment on any issues you have encountered as a result? Also, if one were to implement both these classes, what sort of backwards compatibility should one expect should they be combined in a later release of the JDK?

Ed: Jeff and Gary are free to answer more questions. So send them in if you have any.

Jeff: The basic features of the next major Java release are available through the Java Community process on java.sun.com. We are looking to integrate our various security optional packages, and add support for Kerberos through GSSAPI. There is also work going on to add distributed security support to RMI. We will also be fixing various bugs and making other smaller enhancements.

gary: Gino, we are still planning on merging the functionality of adding principal base grants to our implementation of the Policy class. Thus far we have not run into any significant issues. One area we need to continue to explore is backward compatibility. Right now we don't see any glaring issues but if you have any insight other than this I am all ears.

rwclark: Your response targeted to a network file server is too brittle. Java technology is a distributed architecture which you are now collapsing to two tier. In other words, this solution, a simple one, is not very useful for a REAL implementation.

KarlScheibelhofe: Yes, I know this mailing-list, and I read it. The provider I build also bases on OpenCard. Some of my suggestions relate to JCA/JCE and some other to OpenCard. I sent the suggestions for OpenCard to a developer from gemplus to hear his opinion. I think he knows Gary, but I can't remember his name by now. I will send the suggestions for JCA/JCE to java-security@sun.com. Is there a list of already planned changes/improvements to JCA/JCE?

gary: KarlSche, The changes to JCE are described on java.sun.com. We also are making some performance-related enhancements to JCA to continue to minimize memory footprint and startup times.

Jeff: rwclark, the Java security policy files can also be configured to be picked up from standard system administrator locations on administered web servers. As long as system administrators control the installation of software (the JRE) that is available on the user's systems you should have the basic flexibility you need. If users are able to download and install whatever software they want from the Internet then all bets are off if you don't trust them in the first place. So, there is a basic framework in place. We do plan to look at ways of improving the deployment experience in future releases.

Gino: How would you suggest one handle the issue of managing/maintaining a LoginContext in a distributed servlet environment (i.e. one is trying to enforce user-based access)? The LoginContext itself is not serializable, and because it is also declared final one cannot implement a seralizable wrapper. Presumably this would also be an issue if one needs to make some sort of RMI call.

test: Can you recommend any books on implementing Java security?

gary: There are two very good references on Java 2TM security. Li Gong's book Inside Java 2 Platform Security: Architecture, Api Design, and Implementation and the book by IBM Java 2 Network Security.

Jeff: Gino, a >LoginContext acts as a factory for a Subject which encapsulates the identity and authentication secrets of the logged-in identity. I believe Subject is serializable so that may be what you want.

Gino: Perhaps you could elaborate on the DomainCombiner interface? The implication seems to be that changes to a policy file can be dynamically applied to the JVM. Is this the case? Will there be an implementation of this interface?

rwclark: Let's consider the implications of a REAL security requirement: I have various servers in an ASP model supporting 2400 users with 24,000 calls per day. This is not so much an issue of TRUST (which is also part of the equation) so much as an issue of maintenance. How does the current SECURITY model aid me for a REAL implementation? Keep in mind that many of these users are not sharing system administrators (except perhaps at the ASP level).

jtr: Li Gong's book is a good overview. Speaking of books, is Li Gong still working with the security group?

Ed: jtr. Thanks. Li Gong is now working in the Consumer & Embedded area of Sun.

gary: Gino, The DomainCombiner interface is implemented in JAAS, SubjectDomainCombiner. There is a lot of latitude in what a DomainCombiner could do. JAAS also has a property which controls whether policy is read and cached or read whenever it is needed. The current dynamic policy support in Java 2 is broken. We have an active bug open and are looking at all our alternatives. As you might imagine, it is a very complex problem.

Jeff: rwclark, I'm not sure this is the right forum to get into the specifics of your scenario however I'd like to take this offline and learn more from you about your real-world environment. Perhaps Java 2 can solve your issues today or maybe we will learn something that can be added to enhance future Java releases. I will send you a separate private message.

Ed: We're down to the last 10 minutes of the session. So if you haven't asked your question yet, please do it now.

rwclark: Jeff, sounds fine to me. Correspond at rclark@epicedge.com (Ed this address may viewed by the group)

gary: We have discussed a variety of topics today and I would like to ask the participants if there are any specific features that you would like to see in the future. Usability comes to mind but are there other areas.

Gino: One feature that might be useful is to provide a way to install the JRE so that the security manager is always installed.

jtr: Usability of the security systems by the end user and the programmer is what I'd like to see most. To me, this means something other than a GUI over the APIs and policy files, no matter how fancy.

gary: These feature requests seem reasonable and are the kind of feedback we like to hear. We are always trying to improve deployment of the Java 2 security model. If you have further questions you can post them to our security alias at java-security@sun.com. Thanks for your participation.

Ed: Well, we've quickly come to the end of the session. I'd like to thank everyone who participated. And of course, I'd especially like to thank our guests Jeff and Gary.

Ed: Last moderator (me) signing off. The forum is now unmoderated

Participate in the Security Forum.

coffeecup


Reader Feedback

Tell us what you think of this transcript.

Duke

Very worth reading Worth reading Not worth reading

If you have other comments or ideas for future articles, please type them here

_______
1 As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.


Print Button
[ This page was updated: 21-Sep-2000 ]
Products & APIs | Developer Connection | Docs & Training | Online Support
Community Discussion | Industry News | Solutions Marketplace | Case Studies
Glossary | Feedback | A-Z Index
For more information on Java technology
and other software from Sun Microsystems, call:
(800) 786-7638
Outside the U.S. and Canada, dial your country's AT&T Direct Access Number first.
Sun Microsystems, Inc.
Copyright © 1995-2000 Sun Microsystems, Inc.
All Rights Reserved. Terms of Use. Privacy Policy.