You've got plenty of options to choose from. IMO security is a business requirement, and therefore should be dealt with in the business layer. Another way to look at is ... If I were to switch to a command-line UI, would I loose functionality. Most times the answer to this question is to do security in the business layer. However, not every project needs to be a multi-layer architecture. If its a small project then you can consider doing it in the web layer.
Here are some options
In the web layer �
a) You can secure a
Struts action mapping using the role attribute. You can either use your container's role definitions (in web.xml), or point it to your own
b) You can protect areas on a page by using the role attribute on a tile definition
c) You can protect a field using the role attribute on a present tag
d) The RequestProcessor
The choices on (a), (b),(c) are matter of granularity. Each of these are addressed in Struts Recipes (Manning)
In the business layer �
i) EJB: If you are using EJB, then you can secure using J2EE security on the bean or method level. You can use a SSB (with local interfaces if the architecture is collocated) to provide security. WebSphere allows you to use LDAP or whatever you want
ii) Spring Framework: Spring use Aspect Orientated Programming (AOP) to provide security
iii) AOP: If you don't want to use Spring, then you can use AOP on its own.
iv)
Java Dynamic Proxies: Java supports the something like AOP, but uses reflection to intercept a call to a method. You would then combine this with a call to your security service
v) roll your own
All of my large projects have been done with (i) EJB, but I'm starting to become serious about (ii) Spring.
[ February 01, 2005: Message edited by: George Franciscus ]