问题
I have a few questions about about how SSL (HTTPS) connections are handled with the Spring Security SAML extension v1.0 release.
I'm using the extension to develop an SP. The remote IDP I'm using has an HTTPS URL. I have the root and issuing certificates for that SSL cert in my JRE cacerts keystore used by Tomcat. The metadata for the IDP is loaded just fine via the HTTPMetadataProvider. In the ExtendedMetadata for my SP's metadata, I have:
<property name="securityProfile" value="metaiop"/>
<property name="sslSecurityProfile" value="pkix"/>
When I hit my SP, I'm redirected to my IDP just fine and I provide my credentials. Then the IDP sends me back to my SP. But I get an error here
ERROR org.springframework.security.saml.trust.MetadataCredentialResolver PKIX path construction failed for untrusted credential
The log shows that this is happening right after the SOAP message is built. I'm thinking my SP is trying to connect to my IDP for artifact resolution.
In section 7.2.3 of the Spring SAML documentation, it says that by default the HTTPS metadata connection will use Java's keystore. I've got that taken care of as stated above. But then in sec 8.1.4, it says direct SSL/TLS connections (used with HTTP-Artifact binding) require verification of the public key presented by the server and the certificate should be retrieved and imported to the keystore as a usual public key. I'm assuming this means the SP's keystore defined in the JKSKeyManager. When I import the SSL cert from my IDP into the SP keystore, the error goes away and all is well.
First question Is this the correct way of handling this? Can artifact resolution over HTTPS not use the JRE's cacerts keystore?
Second question
If I don't import the cert into the SP keystore and change sslSecurityProfile value to metaiop, I still get an error at the same point but instead it says SSL peer failed hostname validation for name: null even if I set sslHostnameVerification to allowAll. Why does this happen?
From what I understand of the MetaIOP profile, it looks for the certificate in IDP's metadata. Since that certificate is different than the SSL certificate, it fails. Correct?
回答1:
Yes, the HTTPS connections opened during Artifact resolution are only using keys from the samlKeystore.jks (or another configured KeyManager) for trust resolution, the cacerts is ignored.
Changing the security profile on SSL to MetaIOP means that you have to import the exact certificate used at the HTTPS endpoint (import either to the keystore or to the metadata of your IDP - it checks both). System will also not verify the certificate's validity (or any other values verified by standard PKIX algorithm).
With PKIX you can import certificate of an certification authority and system will automatically trust certificates which are issued by it.
I believe that the reason system fails on the hostname verification is due to some changes in Java 8. Spring SAML will throw CertificateException from the X509TrustManager - indicating to JDK that the server is not trusted, but JDK doesn't report this exception further, instead it returns an empty SSLSession - which later fails on the hostname verification as its hostname is null.
The hostname verification logic which should check whether the SSLSession is correctly opened is in OpenSAML (TLSProtocolSocketFactory), and is likely to get amended in a later version.
So the exception is a bit misleading, but otherwise system behaves correctly.
来源：https://stackoverflow.com/questions/29435629/spring-security-saml-https-connections