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. Extend the ViewHandlerWrapper abstract class;
2. Declare a private ViewHandler for the viewHandler that we decorates;
3. Create a constructor with a ViewHandler parameter;
4. Override the renderView method with the authorization logic;
5. Declare the decorating ViewHandler in faces-config.xml
I don't generally find it necessary to get that complicated. Usually it's sufficient for me to add boolean render methods to the backing bean for the activity I want to constrain.
An IDE is no substitute for an Intelligent Developer.
Joined: Mar 16, 2010
Tim Holloway wrote:I don't generally find it necessary to get that complicated. Usually it's sufficient for me to add boolean render methods to the backing bean for the activity I want to constrain.
We are in a research in college with the objective of to know whether is possible to have something intercepting the renderization of the pages and recognizing the elements those possibly will have some restriction.
We do this so we take the responsibility to choose what should or should not be protected for the right person: an administrator access and not the programmer. So we can leave the code of pages and the MB's cleaner, without references to resources and roles and thus accelerate the development.
I'm very much a proponent of "wrap-around" security myself, as you'll discover if you spend much time here. In this particular case, however, I don't know that there's enough of a distinction between business function and security to externally supply that kind of control. In other words, to restrict access to the UI element, you'd first need to know the business application of that particular UI element. So it's not really something that can be applied by a third party who knows nothing of the application.
Notice 2 things about the example I supplied:
1. The element render check is deferring to an external security manager of the "black box" variety. It provides a yes/no confirmation and volunteers nothing, as is consistent with good security practices.
2. I don't expect the client to be honest. So I also guard the function(s) that the UI element interacts with. This is critical. In fact I recently received an application with Yet Another Do-It-Yourself Security System (YADIYSS) which depended on UI control hiding. By crafting a suitable request, not only can I invoke the "protected" function, I can modify data in the database. Not just mine, but other people's as well. In fact, depending on how sloppy the DBA was, I can potentially spike the entire OS.
So don't just consider security based on what the user can see. You don't always have to see a target to hit it.
As far as it goes, the most popular way to apply security externally is to use an AOP wrapping approach. You can for example, craft an annotation such as
And/or apply the same functionality from an external XML config file. The Spring Framework is good for this kind of stuff.
The Sun standard J2EE container managed security system (which I favor) can guard URLs by patterns defined in the web.xml file. It's a little trickier in JSF than in most J2EE frameworks, but it can be done and I do it extensively. In fact, all my administrative functions are under the "admin" sub-context as far as their URLs go. That blocks attacks at the server level, before the app ever has to worry about it. The app never sees forbidden attempts at all.
I should point out that quite a few of my apps have more than one type of administrator. Sometimes there's a "sysop" role, a "diagnostic" role and an "application administrator" role. The application administrator typically invokes application controls and screens that configure the app and sometimes the non-admin users. One of my bigger apps also had an "auditor" role. That was very much like what you're talking about, where certain controls were omitted when an auditor looked at a page, because the auditor was permitted to review, but not to update data. However, I did still guard the update logic independently. As I said, hidden targets aren't safe.
Finally, in the event that I actually did have some sort of specialized control that could only be used for administrative purposes, I'd probably code the guards right into the control.
Incidentally, the Struts HTML tags can be role-controlled. JSF tags don't generally have that ability, excepting some of the MyFaces Tomahawk elements. I'm not sure why. Maybe they figured that EL was sufficient.