Announcement Announcement Module
No announcement yet.
ACL based servlet filtering Page Title Module
Move Remove Collapse
This topic is closed
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • ACL based servlet filtering


    In an application we are developing there is a new requirement that ACL is used for controlling access to the web pages through servlet filters. As this was requested friday afternoon and due today I put up together a quick solution over the weekend which was based on a custom AccessDecisionVoter, doing something similar to what is done for ACL method interception (but still using the FilterSecurityInterceptor).
    One thing that complicates matters a little bit is the fact that in the ACL DB we are using all resources are specified only by name, so there has to be a mapping in the XML file between the URL and the functionality name stored in the DB.

    I feel however that perhaps a more adequate solution would be providing a custom FilterSecurityInterceptor which would wrap the FilterInvocation as an AclObjectIdentityAware object. That would then allow me to use the standard BasicAclEntryVoter for ACL handling. Is this a good idea, or I am talking nonsense? :shock: Any help would be greatly appreciated...



  • #2
    I would suggest you'd find it easier to write a custom FilterInvocationDefinitionSource that is database-driven. That way you could use the stock-standard FilterSecurityInterceptor and voters. The ACL services could be used - as you discovered - but it is probably a more complicated way of doing things.

    A thread that might help:
    Last edited by robyn; May 16th, 2006, 04:29 AM.


    • #3
      Hello Ben,

      I refactored my implementation and I did the following:

      - Created a custom FilterInvocationDefinitionSource. It is not database driven because we already use a custom ACL provider which was used mainly for taglib authorization. The format for this custom definition is ant based like:

      - Extended the FilterSecurityInterceptor in order to support a custom FilterInvocation which stores also the "name" of the resource to be protected.

      - Implemented a custom AccessDecisionVoter which can authorize this custom FilterInvocation using an AclManager. It was implemented because the BasicAclEntryVoter expects only MethodInvocation objects.

      This approach IMHO kept all the ACL info in one place (the ACL provider) and is similar to the approach adopted for ACL based method security, except that now we give names to URLs and secure them based on these names. Do you think thats a good approach?




      • #4
        Victor, I must compliment you on following the internal architecture of Acegi Security so well and implementing a good solution to your requirement!