Developers : Dynamically Extending or Modifying the Acegi Security Chain in SBS 4.0 and later : Comments

RE: Dynamically Extending or Modifying the Acegi Security Chain in SBS 4.0 and later

communities@jivesoftware.com — Tue, 16 Mar 2010 22:12:57 GMT

Great write up Mark. I'm in the process of upgrading from 2.5 -> 4.01

In 2.5 I added filters to the filter chain list like this:

<value>

CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON

PATTERN_TYPE_APACHE_ANT

/rpc/soap/admin/**=wsRequireSSLFilter, httpSessionContextIntegrationFilter, meshAdminBasicAuthenticationFilter, jiveAuthenticationTranslationFilter

...

</value>

</property>

</bean>

...

</bean>

That fired the meshAdminBasicAuthenticationFilter on request to this URI /rpc/soap/admin

No filter initialization code is needed in the plugin init routine.

Will I need to change the plugin behavior in 4.x?

Or is this use case not what you are talking about.

Thanks

Wayne

RE: Dynamically Extending or Modifying the Acegi Security Chain in SBS 4.0 and later

communities@jivesoftware.com — Tue, 16 Mar 2010 22:48:39 GMT

It would be advisable to change the plugin filter behavior as I described in order for your plugin to be a good citizen. The purpose of the method is so that a plugin can add it's behavior without having to modify the spring-security.xml file that ships with SBS. Customizing any file within SBS core code not only leaves you exposed to future upgrade problems but also may prevent other third-party code from working correctly.

By using the programmatic method I described you can keep your meshAdminBasicAuthenticationFilter completely within your plugin. If your plugin is ever removed it will not impact the system.

RE: Dynamically Extending or Modifying the Acegi Security Chain in SBS 4.0 and later

communities@jivesoftware.com — Tue, 16 Mar 2010 23:02:08 GMT

I see, I had put the bean definitions in a plugin specific spring.xml file, but in essence you are correct it is still an overlay of the spring-security.xml file.

Your point is well taken, I'll try making the suggested changes.

Thanks

Wayne

RE: Dynamically Extending or Modifying the Acegi Security Chain in SBS 4.0 and later

communities@jivesoftware.com — Tue, 16 Mar 2010 23:45:36 GMT

Hi Mark,

One more question. Under the overlay model I was by-passing authentiction for the following URIs

via these key value pairs

<bean id="filterChainProxy">
        <property name="filterInvocationDefinitionSource">
            <value>
                CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
                PATTERN_TYPE_APACHE_ANT

...

               /styles/**=#NONE#
               /resources/**=#NONE#
               /themes/**=#NONE#
               /images/**=#NONE#

...

</value>
</property>
</bean>

How would you recommend by-passing authentication for those URIs under the new model?

Thanks

Wayne

RE: Dynamically Extending or Modifying the Acegi Security Chain in SBS 4.0 and later

communities@jivesoftware.com — Wed, 17 Mar 2010 00:00:44 GMT

You could define a AllowAnonymousFilter and map it to the pluginPreFilterChain. The doFilter method would set the authentication context as the guest user and then would return immediately - it would not called chain.doFilter to ensure the filters are not processed.

Or are you simply trying to block access to these services altogther? If so, just define a blocking filter that rejects everything.