Security component implementation

Question

I'm working on a security component that will grant access (or deny access) to protected resources through a password verification, in a JSF RI website.
Can you tell me, in your opinion, what is the best practises to achieve this? Can I rely on the standard JSF validation approach?
Thank you very much,
Ivan Saorin

Answer 1

ivan.saorin wrote:
Maybe we have found an anomaly in the way JSF manage validation/security. It is not a exactly a bug, rather, the absolute lack of documentation on the argument.
We have found that in certain situation the standard security offered by JSF MUST be enforced by some kind of measure.
Immagine a scenario like this (real life sick), you build a custom component with an internal validation. The component accepts a password from the user, the confirm button is not on the component itself, instead the component rely on the confirm button present on the page (becouse the button is on a toolbar).
The page confirm button usually is associated with an action that, for example, grant to the user to confirm a transaction of some kind.
What normaly happen if the user put the wrong passord in the password field, is that tha validation rule fails, a ValidationException is thrown by the validator. The page re-render itself signaling the error occured to the user.
But if an ill-intentioned user remove the component from the page (with a famous firefox plugin for example),The component exists on the server and the server only. The client cannot remove it from the JSF view.
or simply remove the secCmpId=secCmpId parameter from the request, the decode of the component is not even called, and so any associated validation rule. The result is that the action fired by the page confirm button is not blocked at all!That sounds like a poorly written component to me. The component will exist in the restored view (or this is kept server side); if it is enabled and rendered then it should be decoded. The absence of the expected parameter in the request parameter map should cause an error.
>
For me isan error that JSF is not blocking action by default. They should be admitted only and only is all the validation are gone ok, ad not if one fails.
I know that is a rather peculiar use case, but the extreme confidence in the absolute server-side security usually bounded by JSF can lead to such an implementation.
Obviously we have resolved the security hole that luckily was found during an internal security test.Personally I wouldn't (and haven't) checked something like a password in a validator, preferring to do it in the action method.