SX Spring Security Extension
  1. SX Spring Security Extension
  2. SES-106

HTTPMetadataProvider does not handle tlsKeys correctly

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: saml-1.0.0.RC1
    • Component/s: saml
    • Labels:
      None
    • Environment:
      tomcat, ADFS2.0

      Description

      When we use the HTTPMetadataProvider:

      On return from the IDP, we get a

      java.security.cert.CertificateException: Peer SSL/TLS certificate is not trusted, add the certificate to your trust store and update tlsKey in extended metadata with the certificate alias.

      To overcome this we wrap the HTTPMetadataProvider in an ExtendedMetadataDelegate and provide a tlsKey which is the SSL certificate presented by the IDP. This should probably be handled by the HTTPMetadataProvider so the wrapping should be unnecessary. We also tried to give the CA certificate used to sign the SSL certificate but that did not work either, which will pose a maintenance nightmare.

        Activity

        Hide
        Vladimir Schäfer added a comment -

        The previous situation was: There are two security modes which can be set in the extended metadata - MetaIOP and PKIX. Currently they pertain to both verification of SAML messages (signatures, encryption, decryption, ...) and to SSL/TLS connections used during artifact resolution. MetaIOP is currently set as default and this means that the SSL/TLS certificate used by the SSL/TLS server have to be explicitly defined in the keystore. No PKIX verification (using trust anchors and certificate chains leading to CA certificates) is used unless whole system is switched to PKIX.

        This is now changed: SSL/TLS is using PKIX by default - this means that any certificate in the keystore is trusted as a CA. This can be restricted using property trustedKeys set in the ExtendedMetadata of the IDP. The SSL/TLS trust verification can be switched back to MetaIOP by setting sslSecurityProfile to "metaiop" in the extended metadata of the local entity (service provider). Logging of situations when peer's certificate is not trusted has been improved and displays pem encoded certs in the UI to simplify their importing.

        This should solve the maintenance problems and need to explicitly import the leaf SSL/TLS cert from the server. It is still needed to import at least the CA.

        Show
        Vladimir Schäfer added a comment - The previous situation was: There are two security modes which can be set in the extended metadata - MetaIOP and PKIX. Currently they pertain to both verification of SAML messages (signatures, encryption, decryption, ...) and to SSL/TLS connections used during artifact resolution. MetaIOP is currently set as default and this means that the SSL/TLS certificate used by the SSL/TLS server have to be explicitly defined in the keystore. No PKIX verification (using trust anchors and certificate chains leading to CA certificates) is used unless whole system is switched to PKIX. This is now changed: SSL/TLS is using PKIX by default - this means that any certificate in the keystore is trusted as a CA. This can be restricted using property trustedKeys set in the ExtendedMetadata of the IDP. The SSL/TLS trust verification can be switched back to MetaIOP by setting sslSecurityProfile to "metaiop" in the extended metadata of the local entity (service provider). Logging of situations when peer's certificate is not trusted has been improved and displays pem encoded certs in the UI to simplify their importing. This should solve the maintenance problems and need to explicitly import the leaf SSL/TLS cert from the server. It is still needed to import at least the CA.

          People

          • Assignee:
            Vladimir Schäfer
            Reporter:
            Henrik Abeler
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: