JSF Security Comparison – EL vs Component Approach

After finalizing the release of Acegi-JSF’s new version, I’ve come across to a presentation of Duncan Mills about his JSF Security Project. We’ve already discussed our views with him here, however I really would like to hear your thoughts on this. His presentation contains the following slide that I cannot agree much.

Free Image Hosting at www.ImageShack.us

The idea of jsf security project is to provide an EL approach using a variable resolver like;
#{securityScope.remoteUser}
#{securityScope.userInRole[‘role1,role2,?’]}
#{securityScope.userInAllRoles[‘role1,role2,?’]}

Well, I have no problem with the EL approach, actually like it, for example I’ve created a hibernate persistent object lookup resolver that brings all the records in the db when bind to components like combos, listboxes, radio and checkbox groups. Works like this;
#{lookup.classname.key.value.all}

Anyway when comparing these two approaches; EL vs Security Components, these come up to my mind;
1) For example to secure some components on page, one must write the same thing to every single one of the components.

    <h:outputText rendered=”#{securityScope.userInAllRoles[‘role1,role2,?’]}”>
    <h:outputText… rendered=”#{securityScope.userInAllRoles[‘role1,role2,?’]}”>
    <h:outputText… rendered=”#{securityScope.userInAllRoles[‘role1,role2,?’]}”>
    <h:outputText… rendered=”#{securityScope.userInAllRoles[‘role1,role2,?’]}”>
    <h:commandButton… rendered=”#{securityScope.userInAllRoles[‘role1,role2,?’]}”>

Same with component approach;

<acegijsf:authorize ifAllGranted=”role1,role2″>
    <h:outputText…>
    <h:inputText…>
    <h:inputText…>
    <h:outputText…>
    <h:commandButton…>
</acegijsf:authorize>

Imagine a requirement has changed, then you must change it for all the components, component approach provides a more centralized solution. What if a secured component has already a value binding to it’s rendered attribute? EL way brings complexity here.

2) What if there is a need to secure static HTML not just jsf components? The component approach can do it as well.

3) For instance, you have grouped your roles and the role lists are not hardcoded in the jsp but defined in a bean, the component approach allows valuebinding to get the role list from a bean.

<acegijsf:authorize ifNotGranted=”#{yourBeanName.notTheReaderTypeRolesList}”></acegijsf:authorize>

4) Since acegi wraps HttpServletRequest, there is no dependency to acegi or spring. You can use it with a servlet container security as well.(Tested with tomcat).

5) The component approach is likely to secure data-based security. I’ve not implemented this one but surrounding a jsf datatable with an acegijsf component will filter the list of the datatable and allow only the records that the given user can see.(ACL).

6) Finally and my favorite, the component way provides an abstraction between the ui components used for business and the security context of the application. The secured components do not know their position in the security context and do not depend on anything. This brings flexibility, maintainability and decoupling. Wait! aren’t those some of the principals of good software design?

Above are the advantages of the component way I can think of at first glance. Acegi project team also favor this way and informed the users about acegi-jsf components at their home sourceforge site.(http://acegisecurity.org/articles.html).

So, as I mentioned, I am wondering about your thoughts on the comparison, what do you think about these approaches to the JSF Security, any more pros and cons?

8 Responses to JSF Security Comparison – EL vs Component Approach

  1. yigit says:

    I saw the powerpoint presentation of Duncan Mills today and I appreciate the new approach to the JSF security concern. I always like to have more than one possibilities for a problem for having a chance to select one.

    Cagatay has described the pros of the Acegi JSF over EL approach, I do think the 1st and 6th reasons are very important and vital. I am using acegi-jsf in our project and I think Cagatay didn’t mentioned but the extensibility of the Acegi-JSF also gives a power to.

    From the presentation of Duncan Mills, I couldn’t see any answers to these arguments and also, form his project page in sourceforge I couldn’t see a demo web application so I couldn’t see an advantage of this EL approach over Cagatay’s solution.

  2. joey says:

    DRY.

    Your approach solves that problem. I think it’s silly to include the rendered attribute on multiple objects if they all fall within the same grouping.

  3. Hasan says:

    i think the problem raises from Duncan’s thinking security as metadata. but security is not a property at the same time.
    i am using acegi jsf 1.1.1 in my project too. And it meets my security requirements simply and effectively.
    it’s clear that Cagatay’s solution is a perfect fit for this job. Because, i don’t want to change all the components’ rendered bindings when i changed a role. By this approach, components decide to render or not after the security pass. So, a component may be in rendered=true case but if it cannot pass the security, rendering meanless. this is the simplicty🙂
    i’d like to congratulate Cagatay on creating such a component that provides simple usage and effective results at the same time. There is not so many such components exist(long live ibm’s extension components ;))

  4. Duncan Mills says:

    I’m afraid I’ll have to disagree with you there. If you had multiple components in a group that needed a security constraint then you’d protect their container not each and every one…







  5. Mert says:

    The aim of using containers is to obtain an abstraction level for components and treat them as a “one” component.

    It’d be senseless to group them if the developer want to apply different security rules for each child.

  6. Srihari Vogeti says:

    Having trouble using

  7. Alex Savitsky says:

    Most of the points you listed apply to EL way, as well (I can be certain for the first four for sure), however, EL also brings flexibility that component approach lacks. Say, you have the following business rule (an example right from my project):

    If entity’s status property is A, don’t show the UI component
    If entity’s status property is B, show the UI component only for MGR role
    If entity’s status property is C, show the UI component for MGR and USER roles

    Implementing it using EL is trivial (rendered=#{(entity.status == B and security:hasRole(‘MGR’)) or (entity.status == C and security:hasRole(‘MGR, USER’))} – I use a static method bound via Facelets) – I wonder how would you implement it using components?

  8. Kris says:

    Are both the approaches tied to contained managed security??
    Meaning am I forced to use contained managed security if I want to use the above mentioned tags?

%d bloggers like this: