I'm integrating the SAML Spring security extension into a Spring 3.0 application (tomcat) that's previously been integrated with Spring Security 3.1.

The source for the Spring Security SAML extension needed some changes to build against Spring Security 3.1,

1) In SAMLAuthenticationProvider.getEntitlements(), I modified the returned value to cast to (Collection<GrantedAuthority>), to track the change to UserDetails.getAuthorities() in Spring Security 3.1

2) The sample app's securityContext.xml file was changed to move the intercept-urls with "filters='none'" out into seperate <security:http ../> elements, to track changes in Spring Security 3.1 regarding how to map a filter pattern to an empty filter chain.

So far, so good...

I deployed the sample war file built with the Spring Security SAML extension (spring-security-saml2-sample.war to my application, modified securityContext.xml to point to my on-disk IDP metadata file and restrated tomcat.

When I hit the root context of the sample app,

https://polaris-dev101.mycompany.com...-saml2-sample/

I see this showing up in catalina.out:

java.lang.UnsupportedOperationException
java.util.Collections$UnmodifiableCollection.clear (Collections.java:1037)
org.opensaml.saml2.metadata.provider.ChainingMetad ataProvider.setProviders(ChainingMetadataProvider. java:104)
org.springframework.security.saml.metadata.Metadat aManager.refreshMetadata(MetadataManager.java:203)
org.springframework.security.saml.metadata.Caching MetadataManager.refreshMetadata(CachingMetadataMan ager.java:86)
org.springframework.security.saml.metadata.Metadat aGeneratorFilter.processMetadataInitialization(Met adataGeneratorFilter.java:123)
org.springframework.security.saml.metadata.Metadat aGeneratorFilter.doFilter(MetadataGeneratorFilter. java:69)
org.springframework.security.web.FilterChainProxy$ VirtualFilterChain.doFilter(FilterChainProxy.java: 324)
org.springframework.security.web.FilterChainProxy. doFilter(FilterChainProxy.java:165)
org.springframework.web.filter.DelegatingFilterPro xy.invokeDelegate(DelegatingFilterProxy.java:237)
org.springframework.web.filter.DelegatingFilterPro xy.doFilter(DelegatingFilterProxy.java:167)


Here's the relevant section of my security-context.xml:
<!-- Enable autowiring -->
<context:annotation-config/>
<context:component-scan base-package="org.springframework.security.saml"/>

<security:http entry-point-ref="samlEntryPoint" pattern="/saml/web/**" security="none"/>

<security:http entry-point-ref="samlEntryPoint" pattern="/logout.jsp" security="none"/>

<security:http entry-point-ref="samlEntryPoint" pattern="/login.jsp" security="none"/>

<security:http entry-point-ref="samlEntryPoint" pattern="/favicon.ico" security="none"/>

<security:http entry-point-ref="samlEntryPoint">
<security:intercept-url pattern="/**" access="IS_AUTHENTICATED_FULLY"/>

<!-- <security:intercept-url pattern="/saml/web/**" filters="none"/> changed to the http elements above to track Spring Security 3.1 xsd changes
<security:intercept-url pattern="/logout.jsp" filters="none"/>
<security:intercept-url pattern="/login.jsp" filters="none"/>
<security:intercept-url pattern="/favicon.ico" filters="none"/> -->

<security:custom-filter before="FIRST" ref="metadataGeneratorFilter"/>
<security:custom-filter after="BASIC_AUTH_FILTER" ref="samlFilter"/>
</security:http>

<bean id="samlFilter" class="org.springframework.security.web.FilterChai nProxy">
<security:filter-chain-map path-type="ant">
<security:filter-chain pattern="/saml/login/**" filters="samlEntryPoint"/>
<security:filter-chain pattern="/saml/logout/**" filters="samlLogoutFilter"/>
<security:filter-chain pattern="/saml/metadata/**" filters="metadataDisplayFilter"/>
<security:filter-chain pattern="/saml/SSO/**" filters="samlWebSSOProcessingFilter"/>
<security:filter-chain pattern="/saml/SSOHoK/**" filters="samlWebSSOHoKProcessingFilter"/>
<security:filter-chain pattern="/saml/SingleLogout/**" filters="samlLogoutProcessingFilter"/>
<security:filter-chain pattern="/saml/discovery/**" filters="samlIDPDiscovery"/>
</security:filter-chain-map>
</bean>

Has anyone else encountered this failure to generate the SP metadata ?