Hi Pradeep, First let me thank you for asking these questions and giving me an opportunity to answer them.
1. Do you think that Java/J2EE is lacking in security ? :roll:
I would love to answer this one with "ABSOLUTELY NO", however this question deserves a fair answer. To state the cliche -- Security means different things to different people.
If you are an implementer of a J2EE spec., your primary interest (in the area of security) is whether relevant security issues are addressed for a working implementation or not. Java/J2EE does fairly well in this respect. I am particularly impressed by the framework for algorithm and implementation independence of Cryptographic Service Providers. I did come across few corner cases where things are yet not very clear, though. One example is security of RMI-IIOP connections. Another is disconnect between Java policies for J2SE programs and declarative statements in Web Application/EJB descriptor files. Though some of these are being addressed.
If you are a programmer using a particular J2SE/J2EE system, your immediate concern is proper use of the available APIs and tools and availability of features. JAAS is a great framework for pluggable login modules, though the list of packaged modules is fairly limited. The cryptographic providers that come with Sun's J2SE SDK are good but no match for BouncyCastle's JCE Provider (in terms of algorithms and types supported).
If you are an end user of Java/J2EE products then you are primarily interested in tools to manage keys, certififcates, policy configurations and other such things. And this is where I found the basic infrastrcuture lacking. Take keytool -- the command line utility for managing keys and certificates. This has lots of problems. You can't even export a cert-chain in PKCS12 format to import in Windows CertStore. It can't even parse cetain valid certificates.
Well, I just touched upon some of the issues. There are many more areas where Java/J2EE security is great and some areas where things can be better. The above application-centric discussion is not to discount the security provided at the byte-code level and eliminating bugs that cause buffer-overflow and stack smashing. This capability alone would justify use of Java in many projects, for most of the high profile and dangerous vulnerabilities are due to these bugs.
2. Is the book targeted to new comers to security or advanaced users?
I would say it is for advanced Java programmers who may be beginner/intermediate int the Security area.
3. What motiviated you to write the book. Thanks
Let me be frank here. To start with -- it was the excitement of being asked by an acquisition editor to write book. It was fun to work on the proposal in one of my interest areas (which happened to be Security in Java Enterprise applications ). Later on, it was the constant reminders about the deadline from my editor. :roll: Once again, thanks for a great set of questions. [ December 16, 2003: Message edited by: Pankaj Kr ]
You mentioned BountyCastle JCE Provider. Would you consider that to be at/near the top of the list for easily-pluggable security modules for EJB apps?
Sun Certified Java 2 Programmer
Joined: Sep 09, 2003
Though Bouncy Castle provider can be used from any Java program (including EJBs), I would consider it something specialized for EJBs. While writing EJBs, the only security API you use is to determine if a particular user is in a specific role or not and then allow him/her certain privileges. Bouncy Castle is moste focussed on cryptographic capabilities. As a deployer of EJBs, you may want to interface with a particular authentication server. THis is not something directly addressed by Bouncy Castle.