[JAVASERVERFACES_SPEC_PUBLIC-948] JSF Security Created: 15/Mar/11  Updated: 12/Aug/14  Resolved: 12/Aug/14

Status: Resolved
Project: javaserverfaces-spec-public
Component/s: Security
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Trivial
Reporter: luisalves00 Assignee: Unassigned
Resolution: Won't Fix Votes: 19
Labels: None
Σ Remaining Estimate: 1 week Remaining Estimate: 1 week
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: 1 week Original Estimate: 1 week

Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-971 Multi-templating System Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-446 How to Provide JAAS Authorization in ... Sub-task Open  
Status Whiteboard:

size_large importance_medium


 Description   

Add native authentication and access-control to JSF.

Related projects:
http://jsf-security.sourceforge.net/



 Comments   
Comment by arjan tijms [ 17/May/11 ]

>Add native authentication and access-control to JSF.

I'm not sure if JSF itself should implement any authentication, but it IMO should definitely integrate better with the existing security infrastructure offered by Java EE and the Servlet spec in particular.

Currently, JSF can work with Java EE's form-based authentication, but posting to j_security_check and using input elements with j_username and j_password names feels a little awkward. I'm sure a more native JSF solution would be possible here, possibly taking advantage of Servlet 3.0's programmatic login.

The securityScope proposed by the linked project is interesting, although with the latest EL revision it's now possible to call several of the existing methods in HttpServletRequest from EL.

Some like Tomhawk's enabledOnUserRole and visibleOnUserRole attributes may also be worth considering.

Comment by john_waterwood [ 06/Oct/12 ]

Is this still planned for 2.2? Some level of support is really important for a web framework imho.

Comment by arjan tijms [ 19/Jul/14 ]

Having thought about this on and off for the better of 3 years now, I don't think there's much JSF should define itself.

At most a few utility methods could be defined (like isUserInAnyRole), but those invariably would be useful for the entire platform and not just for JSF.

More elaborate things like a general SecurityContext that can be injected in CDI beans as well as CDI/Interceptor based versions of things like @RolesAllowed for use in backing beans are all certainly better defined by a security JSR.

What JSF could perhaps do though is providing several integration points with such security JSR (if this indeed was started for Java EE 8). E.g. the mentioned SecurityContext could be defined as a new implicit EL variable in JSF. Actions that are bound to methods for which the user is not authorized at the time of rendering could optionally be omitted or rendered differently. The same thing could be done for links that resolve to URLs for which the user is not authorized.

E.g.

public class MyBean {

    @RolesAllowed("foo")
    public String doAction() {
        // ...
        return "bar"
    }
}

On some view:

<h:commandButton action="#{myBean.doAction}" value="do it"/>
<h:link outcome="/something" value="some link" />

faces-config.xml

<security>
    <components>
         <unauthorized-binding>RENDER_IS_FALSE</unauthorized-binding>
         <unauthorized-navigation-outcome><class>COLOR_RED</class></unauthorized-navigation-outcome>
    </components>
</security>         

If, using the to-be-defined security API and annotations, JSF determined that the doAction binding is protected and the user does not have the role "foo", and that /something resolves to a URL that is protected and for which the user does not have access, then JSF will not render the command button and will apply the COLOR_RED CSS class to the link component.

(the syntax is faces-config is just an example)

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by arjan tijms [ 03/Aug/14 ]

(the syntax is faces-config is just an example)

Actually, explicit syntax in faces-config wouldn't even be necessary. The styles and rendered attributes could be set with something like o:massAttribute (see http://showcase.omnifaces.org/taghandlers/massAttribute) in a template, purely based on EL expressions and the above mentioned securityContext.

Comment by Ed Burns [ 12/Aug/14 ]

Too broad.

Generated at Sat May 23 09:07:56 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.