Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Trivial Trivial
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Security
    • Labels:
      None
    • Status Whiteboard:
      Hide

      size_large importance_medium

      Show
      size_large importance_medium

      Description

      Add native authentication and access-control to JSF.

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

        Issue Links

          Activity

          Hide
          Ed Burns added a comment -

          Too broad.

          Show
          Ed Burns added a comment - Too broad.
          Hide
          arjan tijms added a comment -

          (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.

          Show
          arjan tijms added a comment - (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 .
          Hide
          Ed Burns added a comment -

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

          Show
          Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
          Hide
          arjan tijms added a comment -

          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)

          Show
          arjan tijms added a comment - 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)
          Hide
          john_waterwood added a comment -

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

          Show
          john_waterwood added a comment - Is this still planned for 2.2? Some level of support is really important for a web framework imho.
          Hide
          arjan tijms added a comment -

          >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.

          Show
          arjan tijms added a comment - >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.

            People

            • Assignee:
              Unassigned
              Reporter:
              luisalves00
            • Votes:
              19 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1 week
                1w
                Remaining:
                Remaining Estimate - 1 week
                1w
                Logged:
                Time Spent - Not Specified
                Not Specified