Christopher Steel

Most of the security exploits are with the implementation, not the pattern itself. The patterns specifies the problem and how to solve it, not the code to implement that solution. This conversation crosses into the open source security debate and different people have different opinions on that issue.

Eric,
Additionally, we have tried to include sample code for each of the patterns. This code is available for download on the website at http://www.coresecuritypatterns.com

Our book is fairly generic and strives not to address vendor specific solutions. The whole point of Java and J2EE is to provide a vendor-independent way to build applications. Many vendors, IBM specifically, have proprietary security solutions that you may leverage. The problem is that your application then becomes tied to that vendor. In the real world, I realize most often applications are never ported from one vendor to another. It may make sense to leverage vendor specific security functionality.

I do see however, that most developers move around a lot and end up working with many different vendor implementations. Therefore, it may make more sense for you as a developer, to learn and use vendor-independent techniques such as those prescribed in the book. In either case, many of the patterns address problems that are not solved by any vendor implementations and must be implemented in the application. You, as the developer, should be aware of what patterns to use and when to use them.

Bhaskar,
Patterns are, in general, a proven software technique for capturing recurring problems and solving them in a standard way. They reduce time in the development cycle by providing the common terminology and implementation strategy that allows developers to coomunicate the problem and implement it in a reusable fashion. The patterns in the our book are focused on solving recurring security problems in J2EE and Web Services-based applications. You don't have to use them, but you will most likely end up trying to solve the same problems that they describe. If you choose not use them (or similiar industry patterns), you will just end up re-inventing the wheel. And that may be O.K., depending on your situation. If you want develop software quickly and have it maintained by others, using patterns is a good idea. If you need to sit around and justify time by reinventing solutions, using patterns is not a good idea.

Pratik,
I hate to be too blatantly self promoting, but "buy the book". ;-)
The common patterns I use for web apps are Secure Pipe, Secure Logger, Audit Interceptor, Intercepting Validator, Intercepting Web Agent, Authentication Enforcer, Authorization Enforcer and a few others. The best practices are too numerous to list here. Check out the website: http://www.coresecuritypatterns.com

Alex,
I have ended up doing application security in various forms for the past 10 years. I started out in security in the Internet Lab research group at Thomson Labs. I then transitioned to product development for another Thomson company. After that I was at Sun Microsystems for 5+ years in the Java Center group of Professional Services. There I consulted to many different customers large and small implementing security in large enterprise applications for financial istitutions to working on Jini security for a Navy project.
While at Sun, I worked alongside John Crupi and Danny Malks. It was from their Core J2EE Patterns book that we got the idea to write Core Security Patterns. John had pressured me for some security patterns to add to the second edition of CJP. I completed a chapter but was too late to fold it in. After Sun, I went to a small consulting company and built a large collection application for the U.S. Treasury. A lot of the patterns and best practices came out of that experience. During that time Ramesh and I met and he really got me to start to the book and kept me at it.
In general, my experience is all hands on, not theoretical. You will find a lot of valuable best practices, pitfalls, and reality checks. Much of this is not just our knowlege, but the collective knowlege of many developers and consultants we have worked alongside over the last 10 years.

This is the first book to focus on design patterns for implementing application security in J2EE and Web Services. It attempts to cover the broad spectrum of securing enterprise apps with a focus on developers. Unlike many other books that include chapters on security, this book focuses on it and takes you through the basics all the way to baking security into an application from the ground up with best practices, pitfalls, and reality checks. It is not a theoretical book, it goes into the real world challenges associated with building secure applications.

Dilip,
There seem to be quite a few questions here. I think one of them was how to get authorization from a customer's bank. There are credit card authorization providers out there that provide such a service. I have dealt with Vital, which did credit card authorizations for a government system I worked on. The POS should be responsible for gathering the credit card number, expiration date, security code (optional), name, etc and sending to the web app. The web app then contacts Vital for authorization and receives a code. In our case that code is then sent with the transaction to the settling bank. The security you need to be concerned with is between your web app and the POS, which can be handled using the Secure Pipe pattern mentioned in Chapter 9.

Zafar,
Justifying the need for good developers and a solid security framework to management is often hard. It is like selling insurance, you don't need it unless something goes wrong. The best approach is to do a thorough risk analysis and spell out the liability to the company if the application is compromised. Your management then needs to make a business decision as to how much to invest in security based on the liability. By stating quantitatively the risks and liability, you have put the responsibility on your management officially. Most managers who are cognizant of the risks and the fact that it is their responsibility, will take the appropriate measures.

Levani,
We cover container managed security in Chapter 10 and touch on it in other chapters as well. In fact, Container Managed Security is one of our business tier patterns (pg. 635)

Rivka,
A better approach may be to use a taglib to enforce the page level access control. See the Authorization Enforcer pattern in Chapter 9 for a description and sample code on how to do this.

Chris,
We have a similiar requirement on my current project. If you are using Oracle, you can take a round-about approach to circumvent the connection pool limitation and enforce row-level security. What we do is upon authentication, we take the Principal name and add it (with other adt) to a seperate user table. When a request comes to the back end, we set the user context in the connection from the pool and then a stored procedure in Oracle filters the rows returned based on the data in the user table. It is a little outside-the-box, but works well and makes the developers happy since they do not have to construct their own SQL clauses to enforce access control.

You can create secure virtual organizations via aggregated (web) services. If you look at the case study in Chapter 14 we discuss parts of this. If you go through the whole book you should come out with all the knowlege to construct secure VOs, but it is more than I can address in this forum.

Guillaume,
The Container Managed Security pattern in Chapter 10 touches on declarative security, however it does not address the JSR. What exactly are you looking to do?

Thomas,
I am currently leading a large development project using AJAX and Spring. Spring is a bit different from many frameworks in that it implements dependency injection. The fundamentals still apply and most of the patterns in the book are still relevant. Take a look at the Audit Interceptor pattern in Chapter 10. It implies a filtering interceptor approach that fits nicely into the Spring framework. You can then take the other relevant business tier patterns and implement them using similiar filtering strategies. Dynamic Service Management is practically already implemented for you if you are using XDoclet with Spring. The Policy Delegate pattern could also be implemented as a filter to enforce access control to your business objects.
Hope this helps.