[jira] [Updated] (DELTASPIKE-1022) Support for evaluating access decision voters (defined for @Secured views) after processing view parameters

["Juan Pablo Angamarca (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DELTASPIKE-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juan Pablo Angamarca updated DELTASPIKE-1022:
---------------------------------------------
    Description: 
Deltaspike allows for securing views with access decision voters by annotating the view config classes in a typesafe view-config (@Secured). The issue I'm experiencing is, ADVs are evaluated before page parameters are set, and authorization could depend on page parameters, (example: a page that serves to create and edit entities, depending on a entity-id passed to it, or, a particular property of the entity with the passed id).

The sample application application that demonstrates this can be found at https://github.com/jpangamarca/deltaspike-authorization-demo (there you'll find instructions for running it), and works like this (it is very simplistic, for the sake of demonstration):

- There are two users, 'john' and 'peter'. john is authorized to create and edit employees, and peter is authorized for edits only (permission codes are 'employee.create' and 'employee.edit', and are stored in a set in User.java). A reference to the currently logged-in user is stored in the UserSession session-scoped bean. The currently logged-in user can be changed at the homepage.
- The application has a employee.xhtml page. If an employee id is not provided, the page will be used to create a employee. If an id is passed, it will be used to edit an employee.
- The ADV checks for the id passed to the page to find out what permission the user needs to access the page. But it is evaluated before the id is set (via a page parameter), resulting on 'peter' being unable to edit employees (the id is not set = 'employee.create' is required) and 'john' being authorized with the wrong permission (he has the 'employee.create' permission, but should be authorized with 'employee.edit'). See application logging.

Seam, for example, evaluates page parameters first, then restrict expressions (analogous to ADVs) and then page actions (see Seam pages.xml: http://shrubbery.homeip.net/c/display/W/Seam+pages.xml#Seampagesxml-restrictrestrict). My Seam application (which I'm porting to CDI) works without any problems with these authorization requirements.

The application implements a Deltaspike exception handler, which handles the authorization violations.

Is there any chance to support this kind of authorization requirements?

Thanks for your attention.




  was:
Deltaspike allows for securing views with access decision voters by annotating the view config classes in a typesafe view-config (@Secured). The issue I'm experiencing is, ADVs are evaluated before page parameters are set, and authorization could depend on page parameters, (example: a page that serves to create and edit entities, depending on a entity-id passed to it, or, a particular property of the entity with the passed id).

The sample application application that demonstrates this can be found at https://github.com/jpangamarca/deltaspike-authorization-demo (there you'll find instructions for running it), and works like this (it is very simplistic, for the sake of demonstration):

- There are two users, 'john' and 'peter'. john is authorized to create and edit employees, and peter is authorized for edits only (permission codes are 'employee.create' and 'employee.edit', and are stored in a set in User.java). A reference to the currently logged-in user is stored in the UserSession session-scoped bean. The currently logged-in user can be changed at the homepage.
- The application has a employee.xhtml page. If an employee id is not provided, the page will be used to create a employee. If an id is passed, it will be used to edit an employee.
- The ADV checks for the id passed to the page to find out what permission the user needs to access the page. But it is evaluated before the id is set (via a page parameter), resulting on 'peter' being unable to edit employees (the id is not set = 'employee.create' is required) and 'john' being authorized with the wrong permission (he has the 'employee.create' permission, but should be authorized with 'employee.edit'). See application logging.

Seam, for example, evaluates page parameters first, then restrict expressions (analogous to ADVs) and then page actions (see Seam pages.xml). My Seam application (which I'm porting to CDI) works without any problems with these authorization requirements.

The application implements a Deltaspike exception handler, which handles the authorization violations.

Is there any chance to support this kind of authorization requirements?

Thanks for your attention.





> Support for evaluating access decision voters (defined for @Secured views) after processing view parameters
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: DELTASPIKE-1022
>                 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1022
>             Project: DeltaSpike
>          Issue Type: Improvement
>          Components: JSF-Module
>    Affects Versions: 1.5.1
>            Reporter: Juan Pablo Angamarca
>            Priority: Minor
>
> Deltaspike allows for securing views with access decision voters by annotating the view config classes in a typesafe view-config (@Secured). The issue I'm experiencing is, ADVs are evaluated before page parameters are set, and authorization could depend on page parameters, (example: a page that serves to create and edit entities, depending on a entity-id passed to it, or, a particular property of the entity with the passed id).
> The sample application application that demonstrates this can be found at https://github.com/jpangamarca/deltaspike-authorization-demo (there you'll find instructions for running it), and works like this (it is very simplistic, for the sake of demonstration):
> - There are two users, 'john' and 'peter'. john is authorized to create and edit employees, and peter is authorized for edits only (permission codes are 'employee.create' and 'employee.edit', and are stored in a set in User.java). A reference to the currently logged-in user is stored in the UserSession session-scoped bean. The currently logged-in user can be changed at the homepage.
> - The application has a employee.xhtml page. If an employee id is not provided, the page will be used to create a employee. If an id is passed, it will be used to edit an employee.
> - The ADV checks for the id passed to the page to find out what permission the user needs to access the page. But it is evaluated before the id is set (via a page parameter), resulting on 'peter' being unable to edit employees (the id is not set = 'employee.create' is required) and 'john' being authorized with the wrong permission (he has the 'employee.create' permission, but should be authorized with 'employee.edit'). See application logging.
> Seam, for example, evaluates page parameters first, then restrict expressions (analogous to ADVs) and then page actions (see Seam pages.xml: http://shrubbery.homeip.net/c/display/W/Seam+pages.xml#Seampagesxml-restrictrestrict). My Seam application (which I'm porting to CDI) works without any problems with these authorization requirements.
> The application implements a Deltaspike exception handler, which handles the authorization violations.
> Is there any chance to support this kind of authorization requirements?
> Thanks for your attention.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)