Learn more about J2EE security patterns and their benefits. A chapter excerpt from "J2EE Design Patterns Applied" (Wrox Publications), introduces security patterns in the context of a J2EE Web Banking Application. It identifies relevant security patterns, and applies them to the design of both the app and its operating environment. Uses cases are developed and code is presented for all the major classes.

Read About "Patterns Applied to Manage Security" Here

Hi all,

Just a couple questions:
1. Is there a guide as to who wrote which Chapters of this book? For instance, my guess would be that Chapter 5 - the sample chapter would have been largely done by Sasha Romanowsky as there is also a well-known catalog of security patterns by the same author elsewhere on the Net.
2. Who wrote Chapter 3 on the persistence framework?

Regards,

Rich Katz
Java Skyline
http://www.javaskyline.com/
We now return you to the future - already in progress.

guys,

the download link seems to be broken
(connection to localhost:9001).

cheers,

nn.

This problem should be fixed. Thanks.

This seems silly. Can you change the PDF so it can be printed please? Thanks.

There is no problem printing the PDF

When I click on this PDF, the Acrobat plug-in's Printer icon is disabled; if I click on another PDF from this site, such as the Core JSTL article pdf, its enabled. Maybe it just happens on my machine.

The print button is disabled for me too.

you may crack it with software.

Richard,

could you tell me where I can find the catalog of security patterns you mention?

Regards,
Haagen

Hi Haagen,

All of these are cross-referenced in a draft I have for a book I'm working on with the working title of "J2EE Web Service Design Patterns" for John Wiley.

Here are several. Some overlap with others - otherwise it wouldn't be as much fun :)

1. The Romanowsky catalog:
Security Design Patterns, 2001
http://www.cgisecurity.com/lib/securityDesignPatterns.html

2. The Yoder catalog:
Joseph W. Yoder and Jeffrey Barcalow 1997
Architectural Patterns for Enabling Application Security
http://www.joeyoder.com/papers/patterns/Security/appsec.pdf

3. The Blakey catalog:
Security Design Patterns (SDP), April 2002.
http://www.opengroup.org/security/sdpd1.zip (draft)

4. The Ramachandran catalog(s) in
Designing Security Architecture Solutions Jay Ramachandran, Wiley 2002

The new chapter also discusses and illustrates:
- The Security Layer pattern and
- the Roles pattern and
- Single Sign-on pattern [related to Security Provider and Known source of authority] (Romanowsky) pattern and introduces
- Web Services Gateway framework (IBM)

Regards and all the best,

Rich Katz
"I never met a pattern I didn't like." (corollary to Alexander's quote on patterns as vocabulary)

Sasha and I wrote the security chapter.

Ta
Meeraj

Hi Rich,

I wrote Chapter 3 on the persistence framework.

    Thanks,
      John

Hi John,
I bought the book several months back and although I enjoyed reading it I have always wondered what was the logic behind creating the DAO's as SLSB's instead of just POJO's.
I would have thought this just adds a further overhead when I call from my SLSB business facade to persist an object and doesnt appear to provide anything additional?

Thanks
Rob

What is the preferred way to authenticate using j_security_check...e.g if I am using Weblogic...adding the user tusing admin consoles or using LDAP or by using database...can any one help me in giving me some pointers to this.

You can tie WLS to the security realm that you like (e.g. LDAP) and then the FORM auth will go through that. You just setup the roles, and which roles are allowed to access the various areas on the site.

This is nice as you can change the security system (e.g. change to auth through a DB) yet the application doesn't change at all.

WLS 7.0 comes with pluggable security providers for various aspects os security like authentication, authroization, role mapping, adjudication, identity assertion, auditing etc. It also provides the SPI for developing custom providers. However, it comes with out-of-the-box LDAP authentication providers for authentication information stored in IPlanet, Active Directory, Open LDAP etc. The authentication provider only takes care of principals (users and groups). Mapping principals to roles is done by the role mapper. The default role mapper uses the embedded LDAP server. If you want to store the mapping information in a relational database, you will have to write one on your own. It is all JMX based and can be configured through the console. There are examples on Dev2Dev on writing custom providers.

So if my site has say 50, 000 users then we store all the users in LDAP rather than DB. with roles also being mapped in LDAP ?. Currently we have a custom made system in which all the users and roles are stored in Oracle. We dont use j_security_check..instead we have our won servlets....So if a user is newly registerd i add this user in LDAP online.. Is this the correct way of implementing a large user base.

Reagrdless of whether you use the role mapping information in an LDAP server or a relational database, you will have to cache the information as the WLS security framework will check the role mapping everytime a restricter URL is accessed or an EJB invocation is made.

Hi Rob,

You can write them either way. At the time I was writing the chapter we were using our DAOs on a project as SLSB. I used SLSBs for the automatic transaction management and control that can be associated with the EJB.

However, you are right they are a lot of overhead and on small to medium size projects, I usually stick to POJ-based DAO.

       Thanks,
         John

Hi John,

I've included a reference to your persistence framework in Chapter 3 on the Database page.

http://www.javaskyline.com/database.html

Regards,

Rich Katz

Do you have the URL for where we can find that security pattern catalog?

Thanks.

See response to Haagen - Regards, Rich

I skimmed the chapter but please let me know if this is contained in the book - I didn't see any of these.

1. instance based security - certainly it is not the case that anyone in role of Customer see any account detail? How was that implemented?

2. data validation via rules-based engines?

3. JACC - JAAS was mentioned - JACC wasn't.

OK, so if you wanted to avoid declerative J2EE security from Servlet 2.2 spec:
http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpServletRequest.html#getUserPrincipal()

and as required by J2EE containers
ex http://jakarta.apache.org/tomcat/tomcat-4.0-doc/realm-howto.html
and WebLogic, WebSphere or Resin.

Then you can write something yourself as above book states that would not pass any audit of security.

The rest of use can continue using web.xml based declerative security.

.V

Specifically, the description for Single Access Point sounds more like they're talking about a single point of failure, which it isn't. A single access point is like a castle wall with one gate. The access point is the weak point, and the idea of the pattern, in my mind, is to force all traffic through that point -- for observation, or whatever. Probably the most common security mistake is assuming the you have a single access point when in actuality, you don't.

They then describe a check point as multiple single access points, which, though a good pattern, I see as something completely different. A drawback of the single access point pattern is that all traffic must go through that point, which can lead to bottlenecks. Another drawback is that it must be implemented completely, which is expensive and difficult, just like a city wall, because it takes up real estate, needs extra effort to build, and must be complete. A wall with a few holes is no longer a single access point.

Checkpoints are created with this problem in mind. First of all, it is cheaper to set up multiple checkpoint at likely points of weakness than to build an all-emcompassing wall, and secondly, it helps to prevent the single access point from turning into a single point of failure. As an added benefit, the load can be distributed among multiple points, hopefully reducing tendency to bottleneck. Traffic lights use this principle. A checkpoint isn't meant to be all encompassing.

Another attribute is that a checkpoint can be passive, allowing you to monitor without challenging. Maybe that should be a different pattern, perhaps called "Sentry"

I don't see how the Role pattern as described is related to the single access point or checkpoint pattern. These are access patterns, but the role is about authorization. A role may be the mechanism for obtaining access. The Authoritative Source of Data defines a role, so I'm a little confused about the structuring of the chapter at this point, especially having it come after the Risk Assessment and Management, where you're sure they've left off describing patterns (and roles).

I don't want to be all negative. It was a very nice example, but the intro parts seem like someone provided filler for a heading outline that was actually someone else's notes.

Nothing to add, except that Aaron Evans wrote EVERYTHING
that I thought, while reading the sample chapter;
Thankfully he has the intelect to articulate it.
Thanks Aaron.