How to incorporate permission check in jsf pages

[Thomas Fischer <fi...@seitenbau.net>]

Hi all,

We have a jsp tag which checks whether the user has the permission to
access a given page. The tag retrieves the user and the item displayed on
the page from the session, and checks the permissions of the user on the
item. If the user is not permitted to access the item, the tag adds a faces
message to the context and redirects to the main page of the application.
This works all fine.

Now this page permisson check tag  would be the only tag in the application
so far which is NOT a jsf component. Does it make sense to convert this
into a jsf component ? (Note it has no counterpart in the rendered html.)

If yes, how can I hook the permission check logic into the jsf lifecycle ?
If I implement the permission check as a standard JSF component, my
understanding was that the logical place to do the check  is the "invoke
application" phase ? But I did not find a place where a component can hook
itself into the "invoke application phase". Is there any ? Or should I do
this in the validation phase and hook into the processValidators() method
of UIComponent instead ?

Alternatively, as one can regard permission checks as a sort of validation,
I tried to implement the permission check as a validator. The logical point
to put the validator tag is directly inside the f:view tag, as it is a
permission for the entire page. However, this does not work as the View
Root is no EditableValueHolder. Of course, one could  put the validator
inside any EditableValueHolder on the page, but I'd consider this as a bad
hack (e.g. what if the EditableValueHolder is sometimes rendered and
sometimes not ?)

Any hints towards the "jsf way" of doing page permission checks are
appreciated.

   Regards,

          Thomas

Re: How to incorporate permission check in jsf pages

[Thomas Fischer <fi...@seitenbau.net>]

Hi Catagay,

Thanks a lot for your answer.

Cagatay Civici wrote:
> Security is more kinda metadata and handling it with a ui tag would be
hard to
> maintain.

Hm, but it maps neatly to the requirement "the user can see this page for
that item if he has the relevant permission on the item". The alternatives
you gave are all centralized approaches, meaning that you have one big
configuration file for all permissions, instead of having "decentralized"
checks in the page. It is probably a matter of personal preference and
project organisation, but I'm a friend of decentralized approaches.

> You can still use container managed security with security
> constraints,

This is using the "user has roles" approach, right ? If yes, this is not
enough in my case as it does not incorporate concepts like "this user is
the owner of that item".

> another alternative would be to use a phaselistener or a filter.

The problem with filters is that one would typically use the request url
for filtering. However, the request url does not correspond to the view id
of the protected page. E.g. I have page 1 and if submitted, I want to
display page 2, and page 2 is protected, but if the submit is processed the
url corresponds to the view id of page 1, not to page 2. This is very
difficult to sort out using filters.

Translating this to using phase listeners, this would mean that I would
have to use the "Render response" phase in order to get the correct view id
for the page being rendered from facesContext.getViewRoot.getViewId(),
right ?

> The best solution would be acegi in case you have complex security
constraints.

Thanks for the hint, I'll look into this, but this will take some time.
However, I suspect it uses the "centralized" approach :-), and I'm not sure
if one does not run into the "request url not equals to view id" problem as
in filters.

>
> You can also check out the MyFaces SecurityContext that provides builtin
> security features on EL level.

Thanks, I was not aware of that. However, if I understand it correctly, it
can be used only to switch rendering for some components on and off, not
for permissions on whole pages ?

    Regards,

           Thomas

> On 8/24/07, Thomas Fischer <fi...@seitenbau.net> wrote:
>
> Hi all,
>
> We have a jsp tag which checks whether the user has the permission to
> access a given page. The tag retrieves the user and the item displayed on

> the page from the session, and checks the permissions of the user on the
> item. If the user is not permitted to access the item, the tag adds a
faces
> message to the context and redirects to the main page of the application.

> This works all fine.
>
> Now this page permisson check tag  would be the only tag in the
application
> so far which is NOT a jsf component. Does it make sense to convert this
> into a jsf component ? (Note it has no counterpart in the rendered html.)

>
> If yes, how can I hook the permission check logic into the jsf lifecycle
?
> If I implement the permission check as a standard JSF component, my
> understanding was that the logical place to do the check  is the "invoke
> application" phase ? But I did not find a place where a component can
hook
> itself into the "invoke application phase". Is there any ? Or should I do
> this in the validation phase and hook into the processValidators() method

> of UIComponent instead ?
>
> Alternatively, as one can regard permission checks as a sort of
validation,
> I tried to implement the permission check as a validator. The logical
point
> to put the validator tag is directly inside the f:view tag, as it is a
> permission for the entire page. However, this does not work as the View
> Root is no EditableValueHolder. Of course, one could  put the validator
> inside any EditableValueHolder on the page, but I'd consider this as a
bad
> hack (e.g. what if the EditableValueHolder is sometimes rendered and
> sometimes not ?)
>
> Any hints towards the "jsf way" of doing page permission checks are
> appreciated.
>
>   Regards,
>
>          Thomas

Re: How to incorporate permission check in jsf pages

[Cagatay Civici <ca...@gmail.com>]

Hi,

Security is more kinda metadata and handling it with a ui tag would be hard
to maintain. You can still use container managed security with security
constraints, another alternative would be to use a phaselistener or a
filter. The best solution would be acegi in case you have complex security
constraints.

You can also check out the MyFaces SecurityContext that provides builtin
security features on EL level.

Regards,

Cagatay


On 8/24/07, Thomas Fischer <fi...@seitenbau.net> wrote:
>
>
> Hi all,
>
> We have a jsp tag which checks whether the user has the permission to
> access a given page. The tag retrieves the user and the item displayed on
> the page from the session, and checks the permissions of the user on the
> item. If the user is not permitted to access the item, the tag adds a
> faces
> message to the context and redirects to the main page of the application.
> This works all fine.
>
> Now this page permisson check tag  would be the only tag in the
> application
> so far which is NOT a jsf component. Does it make sense to convert this
> into a jsf component ? (Note it has no counterpart in the rendered html.)
>
> If yes, how can I hook the permission check logic into the jsf lifecycle ?
> If I implement the permission check as a standard JSF component, my
> understanding was that the logical place to do the check  is the "invoke
> application" phase ? But I did not find a place where a component can hook
> itself into the "invoke application phase". Is there any ? Or should I do
> this in the validation phase and hook into the processValidators() method
> of UIComponent instead ?
>
> Alternatively, as one can regard permission checks as a sort of
> validation,
> I tried to implement the permission check as a validator. The logical
> point
> to put the validator tag is directly inside the f:view tag, as it is a
> permission for the entire page. However, this does not work as the View
> Root is no EditableValueHolder. Of course, one could  put the validator
> inside any EditableValueHolder on the page, but I'd consider this as a bad
> hack (e.g. what if the EditableValueHolder is sometimes rendered and
> sometimes not ?)
>
> Any hints towards the "jsf way" of doing page permission checks are
> appreciated.
>
>   Regards,
>
>          Thomas
>
>