I'd even go a step further. Hiding buttons and links that a user should not have access to does little other than improve the user experience. Locking down URL patterns can be effective in security for web interfaces. But like Matt said, what happens when you access your manager some other way? For example, if you use DWR calls are typically made by DWR directly to your managers, so URL security isn't really enough even in most webapps being built today. The only way I'm satisfied with security is when the methods on the manager are secured, and when necessary the objects being returned from the manager are also checked for authorization. If those are in place then all the other security is there to handle gross abuse or improve the user experience.

Nathan

P.S. I love how Acegi Security makes this security stuff so straight forward. It may still be tedious, but it is still so much easier to do security right than any other option I have found.

Matt Raible wrote:
This extra checking is there because you might not only have a web
client.  Having methods secured in the service level is a good idea in
case you ever have web services. While JSF might allow you to add/hide
stuff in the view, it's not always as straightforward with other web
frameworks.

Matt

On 2/28/07, tonyl <[EMAIL PROTECTED]> wrote:

I don't quite understand why we have this additional
FilterSecurityInterceptor and MethodSecurityInterceptor stuff when the jsf code has authorizations on all the actions - including menus, buttons, etc.
This seems way overcomplicated and also not readily transparent from a
coding perspective. Which is better - just put all the authorization and
access on methods in various managers, or put all the access/authorization code into the jsf pages to "restrict" user access to functions? It seems to
me if we are going to control user access to functions  - having things
appear/disappear/enable/disable based on roles and permissions, then why
have this extra layer of checking?


mraible wrote:
>
> Yes, I do believe there is a duplication here.  However, when you're
> doing security-related stuff, duplication is not necessarily a bad
> thing.
>
> In 2.0, we've removed the adminUrlMapping bean and adjusted
> security.xml to contain all the URLs that need to be protected.
>
>     <bean id="filterInvocationInterceptor"
> class="org.acegisecurity.intercept.web.FilterSecurityInterceptor">
>         <property name="authenticationManager"
> ref="authenticationManager"/>
>         <property name="accessDecisionManager"
> ref="accessDecisionManager"/>
>         <property name="objectDefinitionSource">
>             <value>
>                 PATTERN_TYPE_APACHE_ANT
>                 /activeUsers.*=admin
>                 /clickstreams.jsp*=admin
>                 /flushCache.*=admin
>                 /passwordHint.html*=ROLE_ANONYMOUS,admin,user
>                 /reload.*=admin
>                 /signup.html*=ROLE_ANONYMOUS,admin,user
>                 /users.html*=admin
>                 /**/*.html*=admin,user
>             </value>
>         </property>
>     </bean>
>
> Matt
>
> On 2/24/07, j2ee dodo <[EMAIL PROTECTED]> wrote:
>>
>>
>> Hi guys,
>>
>> For appfuse 1.9.4, I removed the line
>>
>>  <prop key="/users.html">userController</prop>
>>
>> from "adminUrlMapping" bean in action-servlet.xml and everything
>> works normal as before, the same security check seems to
>> be done in security.xml already
>>
>> E.g.
>>
>>   <bean id="filterInvocationInterceptor"
>> class="org.acegisecurity.intercept.web.FilterSecurityInterceptor">
>>         <property name="authenticationManager"
>> ref="authenticationManager"/>
>>         <property name="accessDecisionManager"
>> ref="accessDecisionManager"/>
>>         <property name="objectDefinitionSource">
>>             <value>
>>                 PATTERN_TYPE_APACHE_ANT
>>       .....
>>                 /signup.html*=ROLE_ANONYMOUS,admin,user
>>                 /users.html*=admin
>>       ...
>>             </value>
>>         </property>
>>     </bean>
>>
>> So I was wandering if we even need adminUrlMapping bean at all
>> in action-servlet.xml if we simply do all security check in
>> security.xml??
>>
>> on the other hand, it looks like we replace acegi security on the
>> filterInvocationInterceptor bean part
>>  with spring spring security like adminUrlMapping bean in
>> action-servlet.xml....
>>
>>
>> Thanks,
>>
>> Sam
>
>
> --
> http://raibledesigns.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>

--
View this message in context: http://www.nabble.com/redundant-security---tf3286242s2369.html#a9231892
Sent from the AppFuse - User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to