Announcement Announcement Module
No announcement yet.
Failure to generate SP metadata Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Failure to generate SP metadata

    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,

    I see this showing up in catalina.out:

    java.util.Collections$UnmodifiableCollection.clear (
    org.opensaml.saml2.metadata.provider.ChainingMetad ataProvider.setProviders(ChainingMetadataProvider. java:104) aManager.refreshMetadata( MetadataManager.refreshMetadata(CachingMetadataMan aGeneratorFilter.processMetadataInitialization(Met aGeneratorFilter.doFilter(MetadataGeneratorFilter. java:69)$ VirtualFilterChain.doFilter( 324) doFilter(
    org.springframework.web.filter.DelegatingFilterPro xy.invokeDelegate(
    org.springframework.web.filter.DelegatingFilterPro xy.doFilter(

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

    <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"/>

    <bean id="samlFilter" class=" 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"/>

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

  • #2
    One more thing: I had to make this change to saml2-core/pom.xml to successfully build:

    $ git diff ../../../../../saml2-core/pom.xml
    diff --git a/spring-security-saml/saml2-core/pom.xml b/spring-security-saml/saml2-core/pom.xml
    index d43b6e3..4ad1966 100644

    --- a/spring-security-saml/saml2-core/pom.xml
    +++ b/spring-security-saml/saml2-core/pom.xml
    @@ -36,7 +36,7 @@
    - <version>2.5.2</version>
    + <version>2.5.1</version>
    @@ -99,4 +99,4 @@



    • #3
      My environment was fubar'd, when I fixed the environment the problem went away.


      • #4
        Clear your env?

        What do you mean by cleaning the environment?

        I am having the same issue.

        ERROR [[default]] Servlet.service() for servlet default threw exception
        org.opensaml.saml2.metadata.provider.MetadataProvi derException: Metadata for entity http://localhost
        :8080/timelink/nui/saml/metadata/alias/defaultAlias and role {urn:oasis:names:tc:SAML:2.0:metadata}S
        PSSODescriptor wasn't found
        at extProviderImpl.populateLocalEntity(SAM
        at extProviderImpl.populateLocalContext(SA


        • #5
          Is the exception caused by using Java 1.6 ? Docs say to use 1.5

          When I run 'mvn clean install' on the core module, the test cases fail

          See Below:

          Failed tests:
          testMetadataRefresh( aml.metadata.MetadataManagerTest)

          Tests in error:
          testMetadataChanges( aml.metadata.MetadataManagerTest)
          testMissingSP( bsso.WebSSOProfileHoKImplTest): Unexpected exception, expected<org.opensaml.saml2.metadata.provider.Meta dataProviderException> but was<java.lang.UnsupportedOperationException>
          testMissingSP( bsso.WebSSOProfileImplTest): Unexpected exception, expected<org.opensaml.saml2.metadata.provider.Meta dataProviderException> but was<java.lang.UnsupportedOperationException>


          • #6
            Does anyone have more information on the 'generation problem'? I have been able to avoid this problem by writing my own metadata by hand but I am running into problems with artifact resolution now and was hoping to see what the metadata generator would come up with.


            • #7
              The generation exception was caused by JOST-174 in the OpenSA ML library, everything should be fine for quite some time now. If you still face the issue please update your OpenSAML dependency to 2.5.3. The required Java is now 1.6+ due to recent changes in OpenSAML.