[JAVASERVERFACES_SPEC_PUBLIC-495] Allow access-control related JSR-250 security annotations on managed beans Created: 14/Oct/08  Updated: 01/Aug/14  Resolved: 24/Jan/14

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Platform Integration (except for Bean Validator)
Affects Version/s: 2.0
Fix Version/s: 2.2

Type: Improvement Priority: Critical
Reporter: cdoremus Assignee: Unassigned
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Issuezilla Id: 495
Status Whiteboard:

cat2 javadoc size_medium importance_medium


It would be nice to have the ability to use access-control related JSR-250
security annotations (in the javax.annotation.security package) on managed beans
in JSF the same way you can do it to EJB 3 (JSR-220). These annotations, which
include @RolesAllowed, @PermitAll and @DenyAll, would be very helpful for
programmatic access control in a finer grained fashion (and more straight
forward) than the use of security-constraint in web.xml on directories. While
the javax.annotation.security annotations are allowed at both the class and
method level in JSR-250 and EJB 3, it would be most helpful on action bound
methods (actions and action listeners).

Implementing the @RolesAllowed annotation check could easily done with the
ExternalContext.isUserInRole() method. The other implementations are trivial.
What happens when an access-control constraint is violated is something that I
could not get clear direction on from the JSR-250 or EJB 3 specs. This is
something that the JSF EG needs to discuss.

In addition to annotation support, it would be nice to have a faces-config.xml
way for setting this kind of access control similar to the way they do it in the
EJB 3.0 spec with the method-permission element in the deployment descriptor. In
that case, the ejb-name child element (/method-permission/method/ejb-name) would
best be named managed-bean-name. As in the EJB 3 spec, it would be best for the
deployment descriptor configured access control to trump a JSR-250 annotation
allowing a user to change access control rules in the DD without having to
recompile the source code.

Personally, I am not as anxious to have the JSR-250 @DeclareRoles and @RunAs
annotations supported in the JSF spec, but it might be nice to have for testing
purposes. These annotations also have deployment descriptor analogs in the EJB 3

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by lincolnbaxter [ 26/Jan/10 ]

Categorized as part of Rev 2.0 A prep

Comment by rogerk [ 05/Mar/10 ]

cat2 - investigate cdi as alternative

Comment by Ed Burns [ 22/Mar/10 ]


Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]


Comment by Ed Burns [ 22/Jun/10 ]


Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]


Comment by Ed Burns [ 24/Jan/14 ]

Managed beans now are the province of CDI.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out

Generated at Fri Sep 04 17:57:15 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.