Sample SAML Java Config. Project, Broken From the Start

Question

I pulled in the example Java configuration project for Spring's SAML extension. No commits seem to have been made to the project for about six months as of my writing this question. I have not done anything to this project except for run maven package against it.

I then run the application in Spring Tool Suite as a Spring Boot Application and the application runs; however, the application does not run without error and the application endpoint is inaccessible (resulting in am error message): "ERROR: Something went wrong in the authentication process".

I haven't registered any certificates, etc (and may very well need to). There are no instructions provided with the GitHub project for starting or working with the application. I have intentionally not posted the guts of the project as I have left it unmodified.

INFORMATION ON THE ERROR

From Chrome Dev. Tools, I can see a 500 Internal Server Error returned from the request to the localhost:8080 application. So, the issue is definitely with the sample application (or something that I have not done).

The following error is logged to the console on application deployment (I've included both an image and the text as the text is proving difficult to format):

Text:

[2015-08-20 14:41:40.551] boot - 9908 INFO [localhost-startStop-1] --- HttpMethodDirector: I/O exception (javax.net.ssl.SSLPeerUnverifiedException) caught when processing request: SSL peer failed hostname validation for name: 46.4.112.4
[2015-08-20 14:41:40.551] boot - 9908 INFO [localhost-startStop-1] --- HttpMethodDirector: Retrying request
[2015-08-20 14:41:40.795] boot - 9908 ERROR [localhost-startStop-1] --- HTTPMetadataProvider: Error retrieving metadata from https://idp.ssocircle.com/idp-meta.xml javax.net.ssl.SSLPeerUnverifiedException: SSL peer failed hostname validation for name: 46.4.112.4
at org.opensaml.ws.soap.client.http.TLSProtocolSocketFactory.verifyHostname(TLSProtocolSocketFactory.java:233)
at org.opensaml.ws.soap.client.http.TLSProtocolSocketFactory.createSocket(TLSProtocolSocketFactory.java:194)

I have visited the url endpoint provided by ssocircle and the metadata is exposed.

If I visit the /saml/metadata endpoint of the service provider and get some helpful information: an org.opensaml.saml2.metadata.provider.MetadataProviderException exception. The description if which is "No IDP was configured, please update included metadata with at least one IDP"; however, the source of this may be the above described error.

QUESTION

Am I missing something that is readily apparent to start the example application? In other words, what does this error tell me that I need to be investigating? Or, as it is "non-breaking", do I ignore it?

WHY I'M ASKING

The documentation surrounding the deployment of the Sample Java Configuration application is minimal (as in "non-existant"). The self-documentation only provides "hints", such as the following:

 // IDP Metadata configuration - paths to metadata of IDPs in circle of trust is here
 // Do no forget to call initialize method on providers
 @Bean
 @Qualifier("metadata")
 public CachingMetadataManager metadata() throws MetadataProviderException {
      List<MetadataProvider> providers = new ArrayList<MetadataProvider>();
      providers.add(ssoCircleExtendedMetadataProvider());
      return new CachingMetadataManager(providers);
 }

I am certain there is something I am not doing, particularly since I have not done anything in the deployment of the application except for the run of the mvn package, described above.

Answer 1

The problem occurs due to the sample application's utilization of a deprecated constructor - a deprecation whose warning was explicitly suppressed - for the HTTPMetadataProvider (a fix I will commit, shortly). In configuring the ExtendedMetadataDelegate, the two-parametered constructor is utilized:

    @Bean
    @Qualifier("idp-ssocircle")
    public ExtendedMetadataDelegate ssoCircleExtendedMetadataProvider() throws MetadataProviderException {  
        @SuppressWarnings({ "deprecation"})
        HTTPMetadataProvider httpMetadataProvider = new HTTPMetadataProvider("https://idp.ssocircle.com/idp-meta.xml", 5000);
        // other config.s...
    }

If replaced with the non-deprecated constructor that takes a java.util.Timer and an org.apache.commons.httpclient.HttpClient (in addition to the metadata url), the sample application works, beautifully, and no errors are logged.

Additional Non-OP-related Information

I had to do the below to get the Sample SAML app to run

After removing the deprecated constructor, I recommend doing two things:

1. Follow the steps outlined in 4.2.6 of the documentation, i.e. treat the application during setup as the XML-configured application. All the steps need to be taken to "register" the metada.The application will be unable to register its metadata with the current Java configuration (see below; point no. 2)
2. Change the default configurations in class WebSecurityConfig (read detail, below)

Configuration Change

In the configuration of the ExtendedMetadataDelegate bean ssoCircleExtendedMetadataProvider, change the ExtendedMetadataDelegate's property values as follows:

// code....
extendedMetadataDelegate.setMetadataTrustCheck(true);
extendedMetadataDelegate.setMetadataRequireSignature(false);
// code....

In the ExtendedMetadata bean (different from above), change the property values as below:

// code....
extendedMetadata.setIdpDiscoveryEnabled(true); 
extendedMetadata.setSignMetadata(false);
// code....

"Disclaimer"

Whether or not this should be used in production, I do not know; however, it seems to better reflect both the XML-based configuration and resulting metadata of the XML-configured Service Provider example referenced in the SAML Spring Documentation