This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
1. create a property file that says which roles are allowed to access which page
2. create a view handler that checks the user's role against the requested page and allow / deny access
MCSD, SCJP, SCWCD, SCBCD, SCJD (in progress - URLybird 1.2.1)
Joined: Sep 07, 2007
Thanks for the reply.
Many roles can access the same page but based on role he/she can have read write access.emp/non empdata kind of thing....i think we need to define the roles in web.xml and programatically needs to check whether the user in perticuler role to do that operation. Could you provide some docs/examples that gives me an idea of how to do it.
I don't think you'll be able to use the security definitions of the web.xml file for a roll-your-own security system. They were designed for container-based security and at a minimum, I think you'd end up having to read and parse the web.xml yourself - assuming the container will let you.
BTW, in CBS, users don't have a role, they have zero or more roles. This is a common misunderstanding, but the advantage of a user posessing multiple roles is that in business, often there are multiple job functions, some of which are sometimes performed by the same person.
When you forgo CBS, you also give up the J2EE security functions provided by the common development apps, such as the standard isUserInRole() method for servlets and the role-sensitive tags in Struts and other tag frameworks. You have to do it all yourself.
More critically, you have to personally ensure that each and every resource access contains the appropriate guard code and that whenever you modify the security system that you remember to alter the affected items and to test everything. If you leave even one opening, sooner or later someone may find it and exploit it.
Container-based security is much safer in this regard, since the bulk of the guardianship is declarative according to broad rules that are applied before a malicious user can get anywhere near the application itself. You can achieve the same effect with filters, of course, and in cases where the traditional CBS system is a bad fit, this is a sound strategy. However, again, you aren't likely to be able to hook into the standard J2EE security facilities - at least without a lot of work and probably internal knowledge of your appserver.
If you get the idea that I'm a firm believer in container-based security, you're correct. Although there are times when CBS is not the way to got, unless you are simply out to prove your own cleverness - at the risk of some hacker proving his own cleverness - there are some compelling advantages to CBS:
1. Ubiquitousness. Because the security is container-based, all requests are filtered through the security system. No accidentally missing one.
2. Standardization. The functionality is there and well-documented. If you get tired of maintaining the system, you can pass it on, secure in the knowledge that questions about the security system are answered anywhere good J2EE books are sold.
3. Robustness. The J2EE CBS system was argued over by some of the best - and most devious - people in the industry. Less chance of loopholes, more chance of applicability to common use cases.
4. Reliability. The code is Someone Else's Problem. They found the time to design and prove the concepts and code. And they had to debug it.
An IDE is no substitute for an Intelligent Developer.