J2EE Security

Simon P. Chappell writes "Security is not just for the paranoid anymore. There is plenty of documented evidence to show that there are people that are out to get you (and your information). Sun's J2EE framework brings a work-chest with many powerful tools in it, but with power there is always complexity, and many of these tools, especially the security-oriented tools, are under-used because of this. Pankaj Kumar's book J2EE Security is a guide to using these tools when building security into your Servlets, EJBs, web services and web applications." Read on for the rest of Chappell's review.

J2EE Security for Servlets, EJBs, and Web Services
author	Pankaj Kumar
pages	426 (12 page index)
publisher	Prentice Hall
rating	9
reviewer	Simon P. Chappell
ISBN	0131402641
summary	A great combination of security primer and cookbook.

What is J2EE Security?

J2EE Security covers a very wide range of techniques and mechanisms: Access control based on permissions and authentication of identity; encryption of data passing in or out of an application; and validation of presented credentials. These are the big things: needless to say, there are levels of detail below each of these three.

What do I know about J2EE Security?

More than I did when I started reading this book! In my experience, security is either bolted on at the last minute or badly implemented using home-grown techniques. As one who has seen or tried both of these approaches, I was determined to seek out the better way, so when the chance to review this book came along I jumped at it.

Overview

The first section, with chapter one and two, is "The Background." Chapter one is a security primer and should be old hat to most of the readership of Slashdot. Chapter two is a tour of the Java language strictly from a security perspective. This is interesting and very informative, even for a long-time Java programmer like me.

The second section is "The Technology," and includes chapters three through seven. Chapter three is a discussion of cryptography with Java and would have been worth the price of the whole book for me if (I hadn't have gotten it for free as a review copy)! :-) Chapter four covers PKI (Public Key Infrastructure) with Java. Managing certificates is explained as well as the steps necessary to issue and revoke your own. Chapter five is a discussion of access control. Access control in Java is available based on the origin of the code (the applet effect), the signer of the code or the logged-in user. Chapter six concerns securing the wire. This is the use of encryption for the transmission channel, SSL in a web browser being the most obvious example, where everything served over HTTPS is encrypted. Chapter seven secures the message. This covers message encryption for those times in life where you have to use a non-encrypted transfer medium as well as techniques for authentication, so that the message you do send can be guaranteed to be authentic and provably from you.

The third section is "The Application." Chapter eight discusses the security aspects of RMI based applications, especially using the Java security managers. Chapter nine reviews web application security using both declarative and programmatic security, giving examples using Apache Tomcat.Chapter ten discusses EJB security, including JNDI-based client authentication, SSL and declarative access control. Chapter eleven talks about the security issues associated with web services using the Apache Axis tool to illustrate the points. Chapter twelve is a wrap up of the whole book.

What's To Like

The book is logically divided into chapters on each of the main aspects of security that apply to J2EE. These chapters are then located within three sections: background, technology and application. This sequence worked nicely for me, each chapter getting more detailed. This way I knew how deep I was by how far into the book I'd gotten.

The main thing that struck me about this book was that it was designed to be practical. Mr. Kumar not only explains his point and gives you example source code, but he has written a freely available security toolkit, to demonstrate each of the points he makes. The Java Security Tool Kit (JSTK) is a very nice addition to the book's text. Being able to try out the concept being explained really helps. This approach takes example code to another level and I hope other authors will take note.

What's To Consider

There is almost nothing to nit-pick concerning the book, but I do have one complaint about the JSTK software. The supplied shell scripts in the bin directory all had MS-DOS end-of-lines. This prevented them running unmodified on my OS X iBook. I had to remove all of the ^M's. This may also be a problem under Linux, but I have not had an opportunity to test there yet. Once the end-of-line problem was fixed, the software worked like a charm.

Summary

A great combination of security primer and cookbook. If you're a serious crypto-freak then you probably don't need this book. If you're a regular Java programmer looking to move to the next level in your understanding and practice of security in your J2EE applications, then this is an excellent book to purchase and learn from.

Table Of Contents

1. A Security Primer
2. A Quick Tour of the Java Platform
3. Cryptography with Java
4. PKI with Java
5. Access Control
6. Securing the Wire
7. Securing the Message
8. RMI Security
9. Web Application Security
10. EJB Security
11. Web Service Security
12. Conclusions
Appendix A: Public Key Cryptography Standards
Appendix B: Standard Names - Java Cryptographic Services
Appendix C: JSTK Tools
Appendix D: Example Programs
Appendix E: Products Used For Examples Appendix F: Standardization Bodies

---

Simon P. Chappel would like Tim O'Reilly to call him to discuss the great Java book he's itching to write. You can purchase J2EE Security from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.

Slashbot book review

[rkz]

This one is a great addition to the book shelf, I know how to do certain things related to security n J2EE by using the docs and coming across them in my line of work, but this book clarifies nicely why you are actually doing it and provides better language specific ways of doing things that might now occur to you.

Also, it introduces nice security concepts in a clear and easy way which self taught coders might not have come considered before.

I got my copy from Barns & Noble which was a couple of dolla

Re:Slashbot book review

[Anonymous Coward]

go to your local bookstore once in a while, your community depends on it

Re:Slashbot book review

[EmCeeHawking]

go to your local bookstore once in a while, your community depends on it

Stop using outdated, inefficient methods of retail transaction, the future growth of productivity and economnic gains depend on it.

Re:Slashbot book review

[bethane]

This may well have been true when you brought the book but the price on amazon at the moment is $10 whole dollars cheaper than B&N. [Linky] [amazon.com]

Re:Slashbot book review

[hendridm]

Wow, I can't believe he got +5 while having an affiliate link to B&N. Nice moves, especially since it's quite a bit cheaper at Amazon [amazon.com]. Amazon is even cheaper than Bookpool and Half.com!

I have lost all faith in the mod system! ;)

J2EE security? should be just Java 2 security

[musikit]

i find it a little funny how this book only contains three chapters on actual J2EE security.

9. Web Application Security
10. EJB Security
11. Web Service Security

Seems more like this is Security book for all Java 2 folks with J2EE tagged on at end. Ohh let us not forget that J2EE is a big buzzword that will most likely increase sales an extra 10-15% versus naming the book "Java Security"

i'll take the karma hit to state my opinion. Name the book on what it is about not what will generate a large amount of sales.

Re:J2EE security? should be just Java 2 security

[ebuck]

Yes, you're correct, but consider that many of the "seasoned" programmers don't have a good concept of what security is in the first place.

I know it's a shame to have programmers who think that telnet is "secure" because they are prompted with a login, but usually these programmers are not stupid, they are just uninformed. As soon as they realize the issues involved, they take steps to correct them. That is why I am happy to see that the foundations of "what we mean by security" was laid out before the "how we do it in J2EE"

That said, I am sorry to see that they didn't devote a chapter to Java's authentication and authorization service (JAAS), as in my humble opinion, for all of its power, its not terribly straightforward or simple. In a mixed application environment, the pressures for "single sign-on" capabilites usually require JAAS or a home brew implementation which most likely would be even less secure.

Re:J2EE security? should be just Java 2 security

[musikit]

i never liked the idea of "single sign on" it reminds me too much of the US Social Security Number. once you have it you got everything. how exactly do you protect yourself against someone that figures out the single sign on? how do you prove you are who you are if it's lost or stolen?

in the case of identity theft. is level 2 ID theft them finding out your SSN and calling and getting a new SSN saying you are the ID theft? (kinda like a reverse ID theft?)

thank you but no thank you.

Re:J2EE security? should be just Java 2 security

[smccrory]

Agreed about JAAS's absence, and I'll pass this book up for that specific reason. I can't think of any security implementation better poised to really benefit J2EE applications than JAAS. Yet its complexity and relative lack of documentation and tutorials involving the most common of scenarios is IMHO really holding it back. It isn't the fault of JAAS itself - granular security isn't child's play, but solid discussions about JAAS-based authentication and authorization implementations are few and far betw

Re:J2EE security? should be just Java 2 security

[pankaj_1536]

I am the author of this book.
JAAS is indeed a great feature of Java/J2EE systems and no good book would be complete without a good discussion on this topic. This book is no different. It include a complete chapter devoted to it -- the chapter titled "Access Control". This chapter includes description of policy files to control access using codebase (from where the class files are loaded), signer, logged-in user or any combination of these. The cahpter also has details on using LoginModules, how to write J

Re:J2EE security? should be just Java 2 security

[Delirium Tremens]

And they should probably also have added:

12. Securing the Application Server
13. Securing the JVM and the ClassLoader
14. Securing the Operating System (or at least, the File System)

Because if I add to attack a J2EE application, I would do (14), (13) and then (12). If that doesn't work, I would go straight to (10) or to the database. So, maybe they should also have added:

15. Securing the JDBC driver properties and the Database

Overall, this is another Java book that I will not buy.

Role of programmer versus server admin

[Watts]

While it'd be nice to know these steps, I've personally never had to address them. This book seems to cover all of the programmer-oriented pieces of the security model while assuming the server environment is complete.

I would guess the reasoning for omitting these steps is due to this role seperation, or the fact that Application Servers and OSes tend to have vastly different configuration options and covering all of them (or even just a few major ones like WebLogic, JRun, WebSphere, etc.) could be a book

quote?

[Ryosen]

>>but with power there is always complexity

I thought it was "with power comes great responsibility"? Applicable nonetheless.

Re:quote?

[hey!]

I'd rather put it this way:

With scope comes complexity.

With power comes the willingness to tackle more scope.

With power comes complexity?

[Unoti]

Actually, I think it's more like With EJB comes complexity.

Re:With power comes complexity?

[BigGerman]

sure, by transitivity -
with EJB comes power, with power comes complexity, ...

Re:With power comes complexity?

[Unoti]

Right. Now what about the women and free beer...

Programming primadonnas

[Anonymous Coward]

but with power there is always complexity, and many of these tools, especially the security-oriented tools, are under-used because of this.

Security models and tools that are so complex as be underutilized are worthless. It only takes one unsecured app to ruin all the rest of your security. Ultimately security will have to come automagically from the framework, compiler, or language itself. It will be a fight because programmers will feel too constrained in such an environment (thinking they can do it better, which may be true). If only experts can write secure code, we will never have security. This business will always have amateurs working in it. If we have to depend on expertise, we will never have security.

Someone's going to say it, dos2unix

[ebuck]

Although the author did a great review, it's a shame he added in a CR/LF gripe.

For those who may be unfamiliar with file conversion issues, here's (only a few) ways to convert DOS text files.

For Linux, there's dos2unix.
For MacOSX, there's native2ascii (Haven't used it personally, but is reported to work)
Also dos2unix has been ported to MacOSX, see http://www.osxgnu.org/software/Fileutils/Unix2Dos/

And I'm not including several dozen awk scripts, perl commands, shell scripts, etc. to do the same thing.

For perl

[kevin_conaway]

perl -p -i -e 's/\cM//g' file

Re:Someone's going to say it, dos2unix

[gUmbi]

It's a shame that more UNIX tools don't take the high road and just support both formats...

Jason.

Re:Someone's going to say it, dos2unix

[ebuck]

International visitors usually say the same thing every time they visit the good old U.S. of A.

It's not pratical to maintain two dialects when they are not both in active use, in language or in computer software.

Never mind that DOS was created after UNIX, and decided to be particular about wanting thier own file format, so they embedded what was previously a printer command just in case the computer didn't realize that it already had a carrige return to process.

Of course, I'm not really trying to convince you that the UNIX way is better, but now you see it from a different point of view.

Re:Someone's going to say it, dos2unix

[RetroGeek]

Yes but )in the DOS world) I have used just a carrige return, and I have used just a line feed. And then I have used both in combination.

Just a carriage return (no line feed) can be used as a status display with a command line app. In a loop you update the status (such as a line counter), then use just the caraige return to return the cursor to the beginning of the line. The you write out the line number again ON THE SAME LINE.

Just a line feed can mimic a tree. One line down, same character position.

Re:Someone's going to say it, dos2unix

[Delirium Tremens]

People who write portable code use '\b' (backspace) instead of CR. More complex, but much cleaner too.

Re:Someone's going to say it, dos2unix

[RetroGeek]

Think of a typewriter. There are seperate controls for the two functions.

I have always thought that the *nix way was wrong, and took control AWAY from me. If I want a CR, I want a the actions of a CR, NOT an automatic CR/LF.

Automatic actions are the MS way, IMHO.

Sigh, now I will get flamed for this, Oh Well.....

Re:Someone's going to say it, dos2unix

[Unoti]

Ironically, I had a problem where I was wishing my tools didn't support both formats seamlessly the other day! Under AIX, I use vi and :%s/^V^M// to get rid of the CR's. I was using Linux, though, and had a file with CR's in there that were messing things up, but I didn't know the cause at the time. I pulled thed file up in Linux vi, and the file looked fine. (I'm accustomed to using AIX vi, where I can see the ^M's all over the place plain as day, and delete them.) It was half an hour of troubleshooti

Re:Someone's going to say it, dos2unix

[mabinogi]

if you're using vim, put the following in your .vimrc

set fileformats=unix

That will make it show the ^Ms

Not so

[be-fan]

"with power there is always complexity"
---------------
Some of the most powerful concepts are also among the most simple. One of the principle weaknesses of the Java (and C#, and before that Win32 and MFC) API is that they fail to grasp that.

Re:Not so

[MSBob]

Your statement is so vague to the point of being meaningless. Which parts of the Java API do you consider too complex? The power of Java lies in the simplification of a number of APIs that previously were nearly undecipherable. Consider the API to DirectShow versue Java Media Framework. I can certainly tell which one I'd rather work with.

Java APIs make things as simple as possible. But not simpler.

Re:Not so

[Unoti]

Java itself is simple and elegant, generally. But it's really strayed in later years. If you talk about basic Java, most of J2SE, it's pretty well on target. Most of J2EE, though, is a fine example of technology bloat that's just too complex. (People may flame me for this, but I really thik some things in J2SE are somewhat out of control too. Like JTable, for example.)

Sample chapter download

[iksrazal_br]

http://www.j2ee-security.net/book/sample-chap/

This chapter is for Web Services Security using XML Encryption and XML digital signatures.

iksrazal

Another good book on the subject...

[JohnnyCannuk]

...is "Hacking Exposed - J2EE and Java" [hackingexposedjava.com] from Osborne by Art Taylor, Brian Buege and Randy Layman. It's a really good overview of security in Java, from cryptography, code-signing, sealing jar files, byte code obfuscation etc. It runs the gambit from standalone code hacking, through the client-server tier and on to the J2EE and Web tiers. It has lots of good, reusable code samples too.

I highly reccomend it and it's a great "how to" companion to O'Reilly's Java Security [oreilly.com] by Scott Oaks.

Plain text passwords in web.xml

[GreggBert]

The number of J2EE applications that are out there with plain text passwords (database, application and otherwise) in their web.xml is just staggering. I think that's the first place many J2EE developers need to start looking when thinking about shoring up their security holes.

If I see one more book on server side Java that has example web.xml web app configuration files with plain text passwords, I'm going to go postal.

Re:Plain text passwords in web.xml

[citrusboy]

Agreed - plain text passwords in web.xml or properties files are a security hole. What do you do instead? If you encrypt the password but your code can decrypt it, can't an attacker grab your war file along with web.xml and decrypt it?

Re:Plain text passwords in web.xml

[evac]

It can be done. The decryption of the password should take place outside the server itself, using a physically secure encryption device such as an Atalla or Futurex box. An organization should also have solid key management policies and procedures in place (dual-control/split-knowledge/etc) to keep your master key safe - otherwise the PSD don't really add any value.

Re:Plain text passwords in web.xml

[fthiemonge]

If the code that does this is compiled in to class files then at least the person would have to decompile this code. But if you make it so that the code even under decompilation is no good, such as by using PGP or some equivalent to decrypt where the private key is in a secure location, that would be better.

Re:Plain text passwords in web.xml

[ebuck]

You use JAAS, and back the passwords to an authenticating service.

Depending on your choice, the authenticating service can be: /etc/passwd
a different passwd file not in /etc
a shadow password file
a NIS setup
a Windows Domain controller
a kerberos setup
and many many more...

JAAS is not simple to setup and it's documentation isn't written for the people who need it the most. Homebrew encryption is easy to break, so people don't bother encrypting. These factors play a big role in the number of plain text password files.

Re:Plain text passwords in web.xml

[BigGerman]

Number one reason for plain password in Java deployment files is the database. These days, J2EE app _must_ use a connection pool so everything connects to the database using the same, faceless database account (app/app, prod/prod and so on).
To reduce complexity, the same db user is often the owner of the database schema so has unlimited power to mangle tables and data.
It is kind of ironic to have powerful db server the creators of which put together sofisticated securuty features and always see the databa

Java security documentation

[Anonymous Coward]

http://www.cgisecurity.com/development/java.shtml [cgisecurity.com]

IBM red book

[radhamohan]

This red book has indepth converage of Java 2 security aspects including PKI, SSL and even classloaders. Though it doesn't deal with J2EE security details the foundation is lays is solid.