What design pattern to use for User Authentication in Java

There are certain common components that are used across projects:

1. User Authentication and Authorization
2. Exception Handling
3. Logging
4. E-mail
5. DataBase Access
6. Caching etc

Is there a consistent design pattern that can be used for each of these common modules? By the way, the framework can vary like JAAS/JNDI for User Authentication and Authorization, log4j/java logging for logging, JavaMail for E-mai, JDBC/Hibernate for DataBase access.

For example there is DAO for database access. Is there any good design pattern that can be used for User Authentication and Authorization no matter what framework is used(JAAS/JNDI/SSO)?

From stackoverflow $pageUsers[$entry.posts[0].author].name

• I don't know for design patterns for the user authentication/authorization but... if you want to be able to mock them easily, in .NET we use Providers.

  We can then configure which component we use for the authentication and authorization directly through our configuration file.

  What do you think?

  From Maxim

• Perhaps not a pattern per se, but I've always thought that the spring annotations approach was quite clever. Essentially you annotate the methods that need to be secured. Providing that you have a nice tiered architecture then this should make things pretty straightforward! It does all of the hard work for you. Check it out here. The FAQ is pretty good.

  I've only used this in really elementary stuff as part of my spring training with Rod Johnson.

  From Egwor

• For cross cutting concerns you might want to consider Aspect Oriented Programming (AOP). Not so much a design pattern but it is used in the scenarios you described. In a nutshell you have a number of components that require security ...you define the security elsewhere and have the AOP system add it to your components as needed. This way you design your code around the core business case without worrying too much about security. Security gets injected automatically.

  This article might be helpful. It explains how it is done in Spring. I use Spring in a large project right now and I do not know how I managed before without it.

  Here is the documentation from Spring itself about its AOP.

  I know that this may not be applicable to every scenario you mentioned but it might be a start.

  From Vincent Ramdhanie

• This might not be what you're looking for, but all those features are typical examples of cross-cutting concerns. AspectJ is a Java language extension designed especially to handle these types of features in a modular way.

  There is an Eclipse plugin if you decide to give it a try.

  From albertb

• JAAS itself specifies a few: Subject, Prinicipal, Credential and LoginContext. Any authentication framework would have to have similar classes.

  2 that at first glance are specific to JAAS but are very important to making authentication independent of an application's business logic are CallBackHandlers and LoginModules.

  From Vivek Kodira

• I think you are talking about an interceptor pattern.

  It's damn easy in web apps because its already baked into the servlet container spec, through the web.xml

  http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html

  It gets a little more tricky in the j2se world... as if you want to make it everything completely seamless you could use a dynamic proxy (think spring transactional daos) http://java.sun.com/j2se/1.5.0/docs/api/java/lang/reflect/Proxy.html

  From $pageUsers[$post.author].name

• I would be wary of using aspect-oriented programming and especially interceptors. Interceptors and some implementations of AOP operate at runtime and don't actually modify the code that is run.

  What happens if the application is deployed incorrectly, without the interceptor/aspect? Well, in general, your application probably depends heavily on the function provided by the interceptor, and will conspicuously break without it. But authorization is a little different. If a user is not authorized, something happens, like raising an exception. But in the typical case, a user is authorized, and the interception is a no-op. When an application is accidentally deployed without its authorization interceptor, it effectively authorizes all operations.

  In contrast, the conventional approach using explicit permission checks incorporates security in the sensitive operation itself so that it doesn't depend on external configuration of an interceptor, filter, or runtime aspect support.

  Historically, when AOP was a solution looking for a problem, security was seized on as a likely victim. Unfortunately, AOP fans tend to discount the critical thinking needed to safely apply it to this important function. I believe it can be done, but that it's not as simple as annotating a couple of methods.

  Egwor : We actually did something to help this in a scenario where we were using WebSphere's security for signing web service requests. As soon as we were in our code the first thing we did was then map the user to an app user which had privs. If we couldn't do the mapping we threw an error. Same soln here?

  erickson : Yes, that's the kind of active verification that's needed to safely employ AOP for what is normally a passive function. It might sound paranoid or over-cautious... but that's what makes good security.
  From erickson