I am currently busy with a J2EE 1.3 project, where I am alsoresponsible for implementing the security architecture. I have 2 questions:
1. Is it OK if I implement security later, or will security affect my design/implementation now ie. Am I correct in my understanding that security can effectively all be defined via the web.xml and the ejb deployment descriptors. We don't have any unusual security requirements.
2. Does anyone know of any goods docs/books/tutorials/websites that have good information on J2EE security?
Thanks very much.
Not sure of good books off the top of my head, but security will affect the code you write, depending on how you do it. If your security needs are basic access (role A can access this method on an EJB, role B cannot, for instance), then you can do everything through the deployment descriptors. If your needs are a bit more granular, and you reference the roles within your code, you will need to plan for this up front. It's probably good to plan up front anyway, since this may change the way you design your code. For instance, if you plan to have a role that can only read certain information, you may want to specify a read-only method that the role could access.
Hope this helps...
On the security subject, O'Reilly has an excellent book titled Java Security that covers the standard Java security model as well as good coverage of JAAS.
In terms of designing your application for security, security issues should be covered up front. It's an economic as well as a technological choice. It's often more difficult to go back and retrofit software that wasn't designed with good security in mind, and that often leads to leaving open holes in your software.
But taking that into consideration, it doesn't necessarily mean that you have to put in place all of the security code up front. One technique that might work would be to use AspectJ (www.aspectj.org) and code security checks as precondition aspects, which will allow you to modify and tailor the exact security checks that you do in the code later in the project lifecycle.