![]() ![]() ![]() |
|
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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
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 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
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 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
Jeff: Right, the "Brown Orifice" exploit does not work in a Java 2 environment and only the much less
significant 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 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 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 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 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
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
Gino: Perhaps you could elaborate on the 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 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.
Reader FeedbackTell us what you think of this transcript.
_______ |