JAAS and the HTTP Session Life Cycle by Rajesh Shah — The J2EE security framework supports a transparent login process—even handling expired HTTP sessions with ease. Sometimes, however, you want to know that the user’s session has expired. In this article, Rajesh Shah explores a small part of WebLogic Server’s Security Framework in an attempt to capture this information.
JAAS, HttpSession, WebLogic, Authentication
Are clear-text passwords better and more secure than passwords encrypted using ciphers like AES, 3DES or other 2-way encryption technologies? I started thinking more about this after Dmitri Maximovich and I discussed Matt Luce’s implementation of SecureDriverManagerDataSource as a replacement of Spring’s implementation of javax.sql.Datasource (DriverManagerDataSource). Matt’s implementation overrides the getPassword() and getConnectionFromDriverManager() methods and adds support for encrypting database passwords.
Dmitri asks the questions if there is any value to encrypt password with reversible algorithm and keep the key easily available. Can’t someone just grab the key and decrypt the information you are encrypting? While I agree with Dmitri in principle, I still think encrypting the password is better than storing it in the clear. I think the principle of ‘Defense-in-depth’, suggests that multiple layers of security are better than a single protection mechanism. To me, encrypting password using AES for example, makes it a little harder for someone to derive the original password. First they would need to get the key and then pass the key and encrypted string into an AES decrypter to get the original password, assuming the person knew the algorithm used to encrypt the password. Now I know it is really easy to figure what algorithm was used to encrypt text as most of the algorithms have a certain tell-tale signs like M as the first character or = as the last, etc. So in my scenario, the hacker must determine the encryption algorithm, locate and retrieve the key and then decrypt the password. It’s all still doable but I’ve put up more barriers that simply providing the password in the clear. Is it foolproof? By no means but I still assert that it’s better than having the password in the clear.
Another point Dmitri makes is that calling the class anything Securexx will provide users with a false sense of security. I completely agree with that and JavaDoc and usage notes of any class that provides 2-way encryption should make that clear. Dmitri also suggests the use of the Java keystore as a place to hold the encryption key instead of just keeping it in the same property file. A great idea as you would need the keystore password to get to the encryption key out of the store. This idea adds a slight wrinkle as your process must now account for any VM upgrades and make sure that the new keystore has your encryption key. Still a great idea!
To me, 2-way or reversible encryption is the process of obscuring information to make it unreadable without special knowledge. If you need to get to the original text password or any item you are trying to encrypt, you need to know how to get back to the original string. In most cases, you will also need to automate that task programmatically and so technically anyone can decompile your class and figure out how to derive the original text. The word security people use to describe a situation like this is ‘mitigating controls’ and how many controls or barriers do you have to prevent people from getting to this information. It does give people a false sense of security as it is possible for anyone to decrypt your information. By using a 2-way encryption process, you are making someone do a little work to get to the information you’ve encrypted.
I’m curious to see what people think about this. Please drop me an email or comment if you have any thoughts on this. If you’ve implemented something similar to protect passwords, drop me a comment and tell me about it.
AES, Rijndael, 2-way encryption, Spring
One of the limitations of using Spring outside of the traditional J2EE container is hard-coding database information inside the Spring configuration file. If you are deploying the application inside the container, you can simply reference the DataSource via JNDI and not have to provide login, password information about the database connection. To work around that issue, Matt has extended Spring implementation of javax.sql.Datasource and added support for hashing/encrypting the database password. Permalink to Matt’s blog is here .
Spring, DataSource, Encryption
I am in San Francisco this week on a business trip, staying at the Argent Hotel. The Argent is right across from Moscone Center, which is hosting LinuxWorld this week. It feels so weird to see all the Linux sessions, meetups, and BOFs happening in my hotel and the restaurants around here without participating. 😦
Linux, LinuxWorld
Just discovered this on dev2dev.bea.com – Rob Woollen, the Über WebLogic geek or the WebLogic Server Lead Architect as he is officially known has started a blog. I’ve had the pleasure of meeting Rob several times at eWorld(s) and BEA Users Group events and he is really brilliant. Anyone that’s spent any time in BEA’s newsgroups knows Rob and it’s great to have him blogging. Added to my list of must-read blogs and I’m looking forward to Rob’s inside view of WebLogic 9.0
Rob Woollen, WebLogic
The Milwaukee SPIN (Software Process Improvement Network) groups next meeting will be held this Thursday (August 11th) at Wells Fargo in Menomonee Falls (Location/Directions).
The speaker is Pam Rostal and her presentation will comprise of an introductory talk followed by audience selection of the most important “agile” topics they’d like to cover before the evening is over. The top three topics will constitute the first iteration; the remaining list will be re-prioritized, and the second iteration will follow, and so on until only 15 minutes remain. The evening will end with a retrospective, a common agile technique in which participants summarize what has been learned, discuss their reactions, and plan their next steps.
SPIN, agile
Give Your Business Logic a Framework with Drools by Paul Browne — It’s almost too easy to express your business logic as a spaghetti-code fiasco. The result is hard to test, hard to maintain, and hard to update. Rule engines offer an alternative: express your business logic as rules, outside of your Java code, in a format even the business side of the office can understand. Paul Browne uses the open source Drools framework to introduce the idea.
Drools, business logic
Naveen Balani continues his Spring series with a how-to guide to integrating Hibernate transactions with Spring aspect-oriented programming (AOP). The result is a persistence framework you can count on.
Spring, Hibernate, AOP
I don’t use SpamArrest today or know anything about them but I am going to check them out. SpamArrest is offering a free 90-day trail to Mailblocks users that want to move over to their service. It’s cool to see a company that steps and attempts to woo away their customers for a competitor when their competitor screws up and ends up with a ton of dissatisfied customers.
http://spamarrest.com/affl?555230
Mailblocks, spam, Spamarrest
I know I must have been asleep as I just found out today that WebLogic has an attribute value of replicated_if_clustered for the PersistentStoreType parameter.
WebLogic has a piece of functionality called In-Memory Replication that allows you to choose how HttpSessions are replicated across a cluster. Typical usage pattern is to enable this functionality in a clustered environment and you can have users failover from box A to box B when you take an outage on box A for upgrades, new releases or maintenance. This functionality worked great as you could stuff in serialized EJB handles in the session and have them replicated across cluster. When the user’s primary server went down, the load-balancer or web server directs users request to the backup server designated in the cookie. The backup server has the HttpSession information and can allow the user to continue. Any resource bound to server A that is serialized (EJB handles, etc) can be dynamically recreated and stuffed back in the session or handled appropriately on error.
This functionality worked great but setting the property to replicated in a standalone environment caused problems. And so your Ant script or whatever you used to build would need to know what environment if was building for and that’s ugly. Now using replicated_if_clustered, I can eliminate the ugliness of having the build script caring out what environment it’s building for. I wonder if anyone knows when this functionality was introduced? Please drop me a comment or email if you know.
WebLogic, HttpSession, replication, cluster
Vinny Carpenter's blog 