Book Promotion : Hacking Exposed: J2EE and Java

[Brian Buege]

Howdy!
I'm Brian Buege and I'll be guest hosting this forum for the next week or so. I am one of the coauthors of "Hacking Exposed: J2EE and Java (Developing Secure Enterprise Applications with Java Technology)" (Whew!). Specifically, I authored the J2SE, Web Application and Web Services material in the book.
Our book is somewhat unique in the sense that we have attempted to focus on application-level security over a variety of common J2SE and J2EE architectures and applications. Instead of focusing on some technology (like EJB or Servlets) and then including a chapter on security, we've tried to write a book that focuses on security and transcends various technologies (kind of like a one stop shop for J2EE security). Here are some of the application architectures we cover:
- Standalone applications (security features of J2SE 1.4 - including JCE and JAAS)
- Client Server apps
- Java WebStart apps
- Applets
- RMI-based object servers
- Web Applications (Servlets and JSP)
- Web Services (using JAX-RPC and JAXM)
- EJBs (Session, Entity, and Message Driven)
For each of these topologies we wrote a "unsecured" version of a simple *working* application that contains some common security vulnerabilities. Then, through several steps, we suggest "countermeasures" to secure the sample application. Working code is provided, along with install scripts, on our web site http://www.hackingexposedjava.com.
I'll tell you right now that I'm a pragmatist when it comes to security implementation. My philosophy (and the philosophy that drove the creation of the book) is that it's better to have a moderate level of security consistently implemented, than to have provably perfect security implemented inconsistently or incorrectly because of its complexity. Most of our examples focus on simple (or mostly simple) things that you can do to drastically increase the security of your J2SE and J2EE applications.
So, I'll try to field your questions on just about anything security related (I might be overly ambitious here, but I'll try my best )!
Also, I apologize in advance if I can't help out with your particular app server / web container questions. I'm pretty familiar with WebSphere 4.X, older versions of WebLogic (pre-7), and Tomcat, so I should be able to answer questions about those. For questions dealing with other servers, I'll give it my best shot, but we may have to confine our discussion just to the specs. Hopefully there are others lurking here who are gurus with JBoss, Oracle/Orion, SunONE, etc. who can help us out too...
I'm looking forward to having a lot of fun this week!!!
Thanks in advance,
Brian
[ October 21, 2002: Message edited by: Brian Buege ]

[Anirut Worakitrungruang]

Hi there, I need to tell you guys first that I'm too new to Java and this board.
I visited this topic just by linking from JavaRanch Newsletter.
It said there is a book drawing this week.
And the book is absolutely cool in my opinion.
Now I'd like to know how I can participate the game to win the prize.
Plz kindly let me know
Thank you in advance,
Ruttario

[JeF Ald]

Does this book cover any of the internal java security features of jave like encryption and other security features that would be cross platform

[Bill Ngu]

Err... I'm new to the ranch and this board as well..
Could someone tell me how can I implement a MD5 method for my password field ?
The book that I'm looking at now on J2EE merely store the password as plain text .. which I think is not a good practice..

[Mustakim]

Hi, I'm new too.. the book sound kewl.. i want to participate too.. what do i need to do?

[sridhar satuloori]

welcome brian
[ October 22, 2002: Message edited by: sridhar satuloori ]

[Lisa Jorgensen]

I too am new to the Java world. Any help is very welcome and so far, I've very much enjoyed this site!

[Sam Moran]

Brian, at our company one of our web servers takes a lot of hits. It is an NT box running IIS, with Domino DBs. Is there a way, through a servlet, to monitor ports and kill any requests from hackers? Does your book cover instances like this? Thank you very much.

[Patrick Cheung]

how can i get the book?

[Tom Stevns]

Hello Brian Buege !
Please mention some of the most "popular" ways
to java-hack into an application server, a WAS 4.0 as an example.
And especially how to avoid them
Thanx in advance

[Ahmad, Usman]

Hi.
Ok, so I was aked to make this JSP website the other day. Now this site is no ordinay site. It requires approvals of some of the REALLY BIG shots in our organizations so it has to be air-tight secure. I have Websphere 4.0.2 Application Developer Studio and WepSphere app Server. Any suggestions are welcome coz I am totally lost where to begin.
Thanx.

[Brian Buege]

Anirut, I think you became eligible for the review just by posting...
Simple enough, huh?

[Brian Buege]

JeF -
Yup.. The book covers the JCE as well as some basics of cryptography use in Java. It's extremely heavy on code examples and focuses on how to use the JCE (application of concepts such as encryption/decryption, using message digests, MACs, etc) instead of the fundamentals of cryptography (developing your own algorithm or the costs/benefits of using various ciphers).
Most of the sample code is cross-platform, with the exception of one example app that uses the JAAS NTLoginModule to fetch information about the prevailing Windows user. That's one really nice thing about the 1.4 JDK: Many of the security features that were previously separate products were rolled up into the base JDK, virtually ensuring good cross-platform support... Every platform that supports J2SE 1.4 HAS to support the basic security-related stuff now.

[Brian Buege]

Bill-
This code will take the first input arg and compute the MD5 digest for it... Please forgive my lack of argument validation!

import sun.misc.BASE64Encoder;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.io.UnsupportedEncodingException;
public class Digester{
    public static void main(String[] args) {
        try {
            // Get an instance of the right digest object (MD5) from the
            // JCE...
            MessageDigest md = MessageDigest.getInstance("MD5");
            // This line actually calculates the digest
            byte[] digestedBytes = md.digest(args[0].getBytes("UTF-8"));
            // BASE 64 encode the value so we can store it in a text file.
            BASE64Encoder enc = new BASE64Encoder();
            System.out.println("Digested value is: " + enc.encode(digestedBytes));
        } catch (NoSuchAlgorithmException e) {
            e.printStackTrace();
        } catch (UnsupportedEncodingException e) {
            e.printStackTrace();
        }
    }
} 

[Roger Gazdzicki]

I am running a IIS system and planning to change to a resin system. I have uploaded resin and got it working, still trying to install struts. Is there any security issues with my page still trying to use nt authentication. I am currently using it so that users don't have to remember more passwords. Any suggestions would be appreciated.

[Brian Buege]

Patrick-
You can get the book by following the link in my signature, or by going to your favorite bookstore and asking for a copy... OR, you can tempt fate and hope you are one of the lucky winners of this promotion

[Brian Buege]

Originally posted by Sam Moran:
Brian, at our company one of our web servers takes a lot of hits. It is an NT box running IIS, with Domino DBs. Is there a way, through a servlet, to monitor ports and kill any requests from hackers? Does your book cover instances like this? Thank you very much.

Sam,
Our book focuses on building secure applications using Java/J2EE technology. The other books in the Hacking Exposed Series (Network Security, Windows 2000, etc) focus more on the system level (and MS specific) security tasks that you're talking about.
That said, I'll try to give a brief answer anyway...
Your best bet probably wouldn't be to use servlet technology. Let me preface this by saying that the last IIS/VBScript/COM app I worked on was quite awhile ago... But, if you want to secure "IIS" and not a particular application, you may want to look at system level, not application level security (application security is the focus of the book).
Some common system level security stuff I'd recommend would be:
1. Install an intrusion detection system (Snort or equiv) to monitor potential attacks on your NT box.
2. If you feel comfortable doing it, block the IP addresses or ranges of the offenders. If your app is supposed to be available to the general public, blocking ranges or specific IPs may not be the best solution though as you could unintentionally block valid traffic.
3. If practical, configure your firewall to block the access to ports of concern if external access isn't necessary.
4. Contact the admins who host the offending IP addresses.
5. If you really want a servlet solution, you *could* build a servlet filter (Servlet 2.3 and above) to inspect incoming IP addresses, or other relevant information and deny requests at the container level. This would only work for servlets though and would not do much for your other native IIS apps.
Hope this helps (even though I'm not a MS guy)!

[Lindsay Morsillo]

Hi Brian,
Are there any specific new security problems introduced when using DIME to send binary data from a web service? What reccomendations do you have to provide adequate security?
I also want to say that I agree wholeheartedly with your pragmatic view of security. I think that if an organization realizes that their security isn't perfect, that it is possible for someone who is determined to perpetrate some form of fraud or mischief to do so, everyone in the organization will be more alert and vigilant. Complacency is itself a vulnerability.
I've found in many eCommerce ventures that the most profitable thefts were not based solely on a technolical flaw, but also other vulnerabilities in the chain of operations. Particularly in the realm of credit cards. Don't forget that 'Dumpster diving' is still a great source of information for those that would steal.
Anyways, I'd appreciate any tidbits you could pass along regarding DIME.
Thanks.
Sincerely,
Lindsay Morsillo

[Brian Buege]

Originally posted by Ahmad, Usman:
Hi.
Ok, so I was aked to make this JSP website the other day. Now this site is no ordinay site. It requires approvals of some of the REALLY BIG shots in our organizations so it has to be air-tight secure. I have Websphere 4.0.2 Application Developer Studio and WepSphere app Server. Any suggestions are welcome coz I am totally lost where to begin.
Thanx.

Is this a loaded question?
To give a short answer: You're on the right track already by thinking about security *before* you build the site. Unfortunately, this isn't usually the way things play out.
Since I just helped write 400+ pages on this exact topic, I may not be able to fit a complete answer in this reply...
Here are some tips to start with:
1. Include "security" in your planning from the beginning. Each one of your use cases (if you're using them) should have a security section detailing the confidentiality, integrity and availablity needs for that use case. Additionally, the actors (entities who will use your system) on your use case diagram will often translate directly into security roles for a basic authorization scheme.
2. Build security from the ground up. First, secure the platforms that your web/app/DB servers will run on by including OS/System level security from the beginning. Then, it's money well spent to hire someone who knows about securing your app server (WS in this case) to help you develop a secure WebSphere configuration.
3. If possible, use standard J2EE security at the application level (the app that you're actually building). Don't try to build a custom scheme. That way, you place your security in the hands of people who do it for a living instead of trying to roll your own. This isn't saying that you (or anyone) couldn't do a good job, but with the time constrains given to most enterprise projects today, you may not have *time* to do a good job... Use the stuff that comes with the app server instead.
Hope these helped... I could type for about the next year and probably not cover everything!!

[ October 22, 2002: Message edited by: Brian Buege ]

[Rick Rodriguez]

Brian,
I have a really dumb question. What is the difference between "system-level" and "app-level" security?
It would seem to me that if the system-level security is "lax", then the application is "open" to attack, as far as getting information packets that it may be sending across the network.
Given this, it would seem that the application does not have a chance against a hacker that is already in the "system".
Could you help me to clarify this Brian, in terms of your expertise?
--Rick

[Ben Sullins]

Welcome Brian.
I am interested in EJB security, and I would like to hear what you have to say on the subject. Other than the access control provided by security roles, what are some other things I can do to secure my EJBs? Is that open-ended enough?
Thanks
-Ben

[Michael Zalewski]

Originally posted by Bill Ngu:
Could someone tell me how can I implement a MD5 method for my password field ?

You need a JCE provider (Java Cryptography Extension). A good one is at http://www.bouncycastle.org
If you install that, you don't even really need to go through JAAS. Just use the MD5Digest class directly like this:

  Digest digMd5 = new MD5Digest();
  byte[] abDigest = new byte[ digSha1.getDigestSize()];
  byte[] abSalt = new byte[ 3];
  byte[] abPassword = sPassword.getBytes();
  // Put 3 random bytes into abSalt[] (code omitted)
  digMd5.update( abSalt, 0, abSalt.length);
  digMd5.update( abPassword, 0, abPassword.length);
  digMd5.doFinal( abDigest, 0);

The MD5 digest of your password will now be in abDigest[]. The digest is always the same length -- I forget how many bytes exactly. It will also be binary, so it may not store into a database CHAR or VARCHAR column without further encoding.

[Brian Buege]

Originally posted by Tom Stevns Nielsen:
Hello Brian Buege !
Please mention some of the most "popular" ways
to java-hack into an application server, a WAS 4.0 as an example.
And especially how to avoid them
Thanx in advance

Tom-
Great question. I'll try to answer briefly because your question is almost grounds for another book: Securing XXXX app server...
With WAS 4.0, there are several high-level points that should be secured:
1. Communication between the WAS Web server plugin and the WAS server itself. This should be tunnelled through ssl. You can do this by adding some extra lines to the plugin configuration file. Unfortunately, on many installations, it's not done. Use SSL client authentication so that the WAS server will deny connections on its plugin port for the app (9080, etc) to everybody but the web servers.
2. To prevent arbitrary adminstrative access, the administrative console on the app server should be locked. To do this, global security should be enabled in WS. Again, many times this is not done.
3. The IBM Secure Association Service (SAS) should be configured such that all ORB-ORB communication is encrytped (and possibly client authenticated by using digital certs). This will allow your app server to automatically (at the ORB level) reject connections from untrusted hosts.
4. Applications should use J2EE security techniques whenever possible. Custom security solutions often provide gaping security holes. When authenticating web clients, if DIGEST or CLIENT-CERT authentication is NOT used (i.e. BASIC or FORM), make sure the authentication happens over a HTTPS connection...
5. An enterprise repository (LDAP, etc) should be used for server authentication (WS can be configured to do this). This will help allow for enterprise intruder locks, password policy, etc. to be enforced.
6. To defend against spoofing and DOS attacks, the COSNaming service should be write protected. Again, many times not done.
All of this stuff has a performance cost (in most cases minor). Just like other security decisions, it boils down to a cost/benefit decision. Compare the damage that could be caused due to a compromise vs. the performance impact (and other costs) of countermeasures and make the call.
Hope these are some helpful starting points... There's a ton more stuff to talk about, but if you've got any more specific questions or issues, I'd be happy to try to answer them.

[Brian Buege]

Originally posted by Michael Zalewski:

  Digest digMd5 = new MD5Digest();
  byte[] abDigest = new byte[ digSha1.getDigestSize()];
  byte[] abSalt = new byte[ 3];
  byte[] abPassword = sPassword.getBytes();
  // Put 3 random bytes into abSalt[] (code omitted)
  digMd5.update( abSalt, 0, abSalt.length);
  digMd5.update( abPassword, 0, abPassword.length);
  digMd5.doFinal( abDigest, 0);

The MD5 digest of your password will now be in abDigest[]. The digest is always the same length -- I forget how many bytes exactly. It will also be binary, so it may not store into a database CHAR or VARCHAR column without further encoding.

Super great point!
Actually, we use the Bouncycastle provider in the book too. However, I'd recommend using the BC JCE provider instead of the native BC interface... I say this for the same reason I'd recommend using JDBC over a proprietary DB interface: portability.
The nice thing about the JCE is that your code can be ported from platform to platform and provider to provider relatively transparently.
To answer the other questions in your post, the MD5 algorithm produces a 128 bit digest (16 bytes).
Also, if you're storing the value in a VARCHAR field in a DB, make sure you base 64 encode the value first (turn the byte[] above into text) -- see my MD5 example earlier in this thread. This will guarantee that your digest won't contain embedded linefeeds, EOF chars, etc.

[Deb Williams]

Brian,
Are there any security issues when using dynamic or static includes? If so, is one better to use than the other?
Thanks,
Deb

[Michael Zalewski]

Originally posted by Ahmad, Usman:
... It requires approvals of some of the REALLY BIG shots in our organizations so it has to be air-tight secure.

You think just because the REALLY BIG shots approve your JSP page, then the site will be air-tight secure? Air-tight security will come through architecture and code reviews. Also through using well known methods such as through JCE and JAAS.
OTOH, you probably mean that any security breaches will get the attention of those REALLY BIG shots. Another good reason to use JAAS instead of trying to program it yourself.

[Brian Buege]

Originally posted by Rick Rodriguez:
Brian,
I have a really dumb question. What is the difference between "system-level" and "app-level" security?
It would seem to me that if the system-level security is "lax", then the application is "open" to attack, as far as getting information packets that it may be sending across the network.
Given this, it would seem that the application does not have a chance against a hacker that is already in the "system".
Could you help me to clarify this Brian, in terms of your expertise?
--Rick

Rick-
Great question!
System level security refers to securing the actual OS, platform and network. Application level security refers to securing the applications running on the systems.
Often strength in one area can compensate for weakness in another.
Here's an example:
If I have weak system security (as in your question), my underlying system can be penetrated and I'm in bad shape... However, strong application security can help mitigate the business risk associated with the penetration: For example, if my application stores data on the local file system (let's say in a flat file), it can encrypt the sensitive data before writing it. Now, even full access to the OS will not yield the business sensitive data.
Obviously, an attacker could still delete the data, or cause a DOS for our application by torching the base OS, but we would have succeeded in protectiing the confidentiality of our clients (a partial victory). This is kind of what I mean... Many times, people make the assumption that "If the OS is breached, all is lost..." I disagree with that assertion. Securing the OS is *super* important, but every business critical application should have a "defense in depth" at the network, OS, AND application level.
This works the other way too... Strong OS security can compensate for poor app security. I can store my app data in plaintext if I know I've got an impregnable OS. This is the common approach used for security today. In most cases it's effective, but can lead to the weakness you specify in your question - if the OS is breached, it's bad news.
So, to add the proprietary book plug, the focus of our book is: simple stuff you can do at the application level to help supplement security at the system level.
Hope this helps!
- Brian

[Roger Goerke]

Brian,
The J2EE specification speaks directly to Security and has several goals that are clearly explained. It also has specific non-goals. One of the non-goals that puzzles me is this:
This specification does not mandate a specific security technology, such as
Kerberos, PK, NIS+, or NTLM.
Could you briefly compare/contrast the Security technologies listed (Kerboros, PK, NIS+ and NTLM) and identify vendor(s) that use them? Is PK the Public Key Infrastructure touted by IBM?
Thanks

[Poorav Chaudhari]

Hi,
I am currently using a struts framework in my web based application and have developed my own security but would love to know what in your opinion is the best way to implement security across an n-tiered application. Should there be an security at every level? wouldn't that affect the performance?
thank you
poorav

[Terri]

Brian,
In your opinion is Web Services secure and ready for the world to use?
What would be the best applications to make use of Web Services?

Thank you

[Daniel Ng]

Are there any examples on password encryption in the book?

[Juanjo Bazan]

Originally posted by Terri:
is Web Services secure and ready for the world to use?
What would be the best applications to make use of Web Services?

Thank you

Check out this article.

[Brian Buege]

          Note: This specification does not presently define any 
          mechanisms for providing security for DIME messages and header 
          information.  Future revisions of this specification will 
          address this open issue. 

And you think you're the only one who puts security in after the fact???
So, with DIME I really would focus on securing the individual payloads instead of the message as a whole. This goes for integrity and non-repudiation too: digital signatures and MACs should be done at the individual payload level and not at the message level.
Additionally, as is the case with any messaging format, I would be wary of any content type that gave the ability to execute code on my machine..
Hopefully the spec will evolve in the future to help with some of these issues.
[ October 23, 2002: Message edited by: Brian Buege ]

[Brian Buege]

Originally posted by Daniel Ng:
Are there any examples on password encryption in the book?

Yup... The book contains several examples that demonstrate how to encrypt arbitrary text within the context of a real application.

[Brian Buege]

Originally posted by Ben Sullins:
Welcome Brian.
I am interested in EJB security, and I would like to hear what you have to say on the subject. Other than the access control provided by security roles, what are some other things I can do to secure my EJBs? Is that open-ended enough?
Thanks
-Ben

Ben-
That is pretty open ended!
Our book has a chapter on EJB security, but here's some simple stuff that can get you started:
1. Use local interfaces for your entity beans whenever possible. This allows you to do two things: Relax security (or turn it off) at the entity bean level, and it also forces you to use the session facade pattern which is just a good idea from an architecture standpoint anyway. The other thing it does is eliminates the possiblity of someone using your entity bean to write directly to the database. I can't tell you how many databases I've seen that are totally locked down, but have unprotected unsecured entity beans sitting out there on app servers ready for use...
2. If you use Message Driven Beans, be on high alert. Most messaging systems have extremely weak security. Combine this with the fact that a MDB essentialy runs suid (you need to set the RunAs property to enable impersonation) and you have a security hole waiting to happen. Once an attacker can figure out how to write a message to your queue, things go downhill from there rapidly. You may have to implement your own security mechanism for those to do simple authentication/authorization.
3. Make sure you understand your container and how it handles security. Since it will be providing most of the security services for your EJBs, it must be configured correctly otherwise the beans will be vulnerable. I've seen plenty of app servers rushed to production with the default settings still enabled. Doing something like this with an Oracle instance could get a DBA fired, but it seems to be par for the course with app servers. Additionally, some app servers provide additional capabilities (such as JAAS support). If you've got an app server that does that, your security possiblities for EJBs are only bounded by the JAAS LoginModule/Principal/Credential support that you're using.
I saw that you've written a book on JMX... That's cool! I'm currently trying to evaluate the security of some JMX providers (unfortunately, it seems to be so new that there isn't much security to evaluate yet...) and may need to post some questions for you!!!
I'll definitely check your book out. I need to get a better idea about what's possible and what's coming in the future with the technology.

Not sure what the bottom 1/3 of this post has to do with EJBs, but hey, it's getting late!!!

[Brian Buege]

Originally posted by Roger Goerke:
Brian,
The J2EE specification speaks directly to Security and has several goals that are clearly explained. It also has specific non-goals. One of the non-goals that puzzles me is this:
This specification does not mandate a specific security technology, such as
Kerberos, PK, NIS+, or NTLM.
Could you briefly compare/contrast the Security technologies listed (Kerboros, PK, NIS+ and NTLM) and identify vendor(s) that use them? Is PK the Public Key Infrastructure touted by IBM?
Thanks

Roger-
Really super question!
Here's how I like to think of it:
The cool thing about J2EE is that in a lot of ways, it lets you as the developer specify what you want done and then the container takes care of doing it. You very rarely get to specify exactly how something happens.
This is similar to SQL and RDBMSs... When you write a SQL query, you tell the DBMS what you want, but (unless you're really into Oracle hints) you don't tell the DB how to find the information (which indexes to use, optimization algorithms to use, etc). It does it by itself.
What does all of this have to do with your question? Here goes (and I'm simplifying a little here):
Kerberos, NIS+, and the other protocols you list above are very much "HOWs" These are technologies that a J2EE container could use to perform its tasks. For example, the container must perform authentication (that's in the spec)... How does it do it? Does it use Kerberos, NIS+, LDAP, or some other mechanism? That's not in the spec. They leave it up to the container vendor. The J2EE spec states what needs to be done from a security standpoint, but leaves the nuts and bolts (the how) up to the individual vendors.
That's why the stuff you mentioned (specific security related technologies) is a stated non-goal. The spec writers probably didn't want to open that can of worms...
Hope this helps!

[Rick Salsa]

Hi Brian,
What's your take on the security interface used provided by most app servers? I have yet to use it in an application myself, but I'm told that is it very unflexible.
I guess I'm looking for something more dynamic that is configurable at runtime. From what I can make out, most container provided security features must be defined in descriptors when deploying.
Is there any way to get around this or do you need to roll your own?
Also, does the book mention securing client-server communication? How does that work, ssh tunneling?
Sorry for the load of questions. Thanks in advance!
/rick

[Brian Buege]

Originally posted by Rick Salsa:
Hi Brian,
What's your take on the security interface used provided by most app servers? I have yet to use it in an application myself, but I'm told that is it very unflexible.
I guess I'm looking for something more dynamic that is configurable at runtime. From what I can make out, most container provided security features must be defined in descriptors when deploying.
Is there any way to get around this or do you need to roll your own?
Also, does the book mention securing client-server communication? How does that work, ssh tunneling?
Sorry for the load of questions. Thanks in advance!
/rick

Rick-
Both great questions!!
Here are a few answers (I'll start from the bottom and work up):
The book includes working sample code for a Java-based SSL tunnel using the JSSE. It also discusses other tunneling products like stunnel. And it discusses them specifically in the context of securing a client-server app. AND, it has working sample code that includes a standalone client talking JDBC to a database, an applet client talking JDBC to a database, and a Java Web Start client talking JDBC to a database.
Next question:
I think that one of the common misconceptions about J2EE security is that it's inflexible. I haven't found that to be the case. There are some things that it doesn't do well, but that's the case with any product.
For example, in SQL it's hard to do some things, but most people would think you were nuts if you suggested rolling your own database. It's kind of the same with J2EE security. There's some stuff that isn't elegant, but I haven't found anything that I couldn't work around yet... Again, just like SQL queries.
J2EE security provides for both declarative (specified in the deployment descriptor) and programatic (handled at runtime) authorization. This allows you to have the best of both worlds: For simple stuff, you can use the authorization in your DD, then when you need to get dynamic, you can interrogate your container to find the identity of the person calling your method and make authorization decisions in your code.
With the advent of JAAS in the newest app servers, this dynamic capability is increased even further and the possiblities are pretty endless.
If you'd like me to be more specific about any of the generalizations I've made above, let me know...
[ October 22, 2002: Message edited by: Brian Buege ]

[Bill Ngu]

To Brian & Michael ..
Thanks for your code on MD5. Will try this later

[Rick Salsa]

Originally posted by Brian Buege:

Rick-
Both great questions!!
Here are a few answers (I'll start from the bottom and work up):
The book includes working sample code for a Java-based SSL tunnel using the JSSE. It also discusses other tunneling products like stunnel. And it discusses them specifically in the context of securing a client-server app. AND, it has working sample code that includes a standalone client talking JDBC to a database, an applet client talking JDBC to a database, and a Java Web Start client talking JDBC to a database.
Next question:
I think that one of the common misconceptions about J2EE security is that it's inflexible. I haven't found that to be the case. There are some things that it doesn't do well, but that's the case with any product.
For example, in SQL it's hard to do some things, but most people would think you were nuts if you suggested rolling your own database. It's kind of the same with J2EE security. There's some stuff that isn't elegant, but I haven't found anything that I couldn't work around yet... Again, just like SQL queries.
J2EE security provides for both declarative (specified in the deployment descriptor) and programatic (handled at runtime) authorization. This allows you to have the best of both worlds: For simple stuff, you can use the authorization in your DD, then when you need to get dynamic, you can interrogate your container to find the identity of the person calling your method and make authorization decisions in your code.
With the advent of JAAS in the newest app servers, this dynamic capability is increased even further and the possiblities are pretty endless.
If you'd like me to be more specific about any of the generalizations I've made above, let me know...
[ October 22, 2002: Message edited by: Brian Buege ]

If you could that be great! So does the book cover programatic security as well? I'm assuming this might be something like isUserInRole, type of thing?
Also, you mentioned that the book talks about securing communcation from client to server, with a swing-jdbc app. What about securing communications with an app server using rmi? Is this mentioned at all and would it be similar to what you describe for the client-sever scenario?
Thanks Brian. The first answer was very informative!
/rick
[ October 23, 2002: Message edited by: Rick Salsa ]