Uzyskiwanie błędu podczas odszyfrowywania tokenu Saml

Question

Otrzymuję błąd podczas odszyfrowywania tokenu saml. Jednak ten problem nie jest spójny działa po ponownym uruchomieniu serwera. To działa prawidłowo do ostatniej nocy :(

DEBUG Decrypter:631 - Attempt to decrypt EncryptedKey using credential from KEK KeyInfo resolver failed: 
     org.opensaml.xml.encryption.DecryptionException: Probable runtime exception on decryption:unknown parameter type. 
      at org.opensaml.xml.encryption.Decrypter.decryptKey(Decrypter.java:705) 
      at org.opensaml.xml.encryption.Decrypter.decryptKey(Decrypter.java:628) 
      at org.opensaml.xml.encryption.Decrypter.decryptUsingResolvedEncryptedKey(Decrypter.java:783) 
      at org.opensaml.xml.encryption.Decrypter.decryptDataToDOM(Decrypter.java:524) 
      at org.opensaml.xml.encryption.Decrypter.decryptDataToList(Decrypter.java:442) 
      at org.opensaml.xml.encryption.Decrypter.decryptData(Decrypter.java:403) 
      at org.opensaml.saml2.encryption.Decrypter.decryptData(Decrypter.java:141) 
      at org.opensaml.saml2.encryption.Decrypter.decrypt(Decrypter.java:69) 
      at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationResponse(WebSSOProfileConsumerImpl.java:199) 
      at org.springframework.security.saml.SAMLAuthenticationProvider.authenticate(SAMLAuthenticationProvider.java:82) 
      at org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156) 
      at org.springframework.security.saml.SAMLProcessingFilter.attemptAuthentication(SAMLProcessingFilter.java:84) 
      at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:195) 
      at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) 
      at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) 
      at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:166) 
      at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) 
      at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87) 
      at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) 
      at org.springframework.security.saml.metadata.MetadataGeneratorFilter.doFilter(MetadataGeneratorFilter.java:87) 
      at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) 
      at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) 
      at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) 
      at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346) 
      at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259) 
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) 
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) 
      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) 
      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) 
      at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503) 
      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170) 
      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) 
      at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) 
      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) 
      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:421) 
      at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1070) 
      at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611) 
      at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314) 
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
      at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) 
      at java.lang.Thread.run(Thread.java:745) 
     Caused by: java.lang.IllegalArgumentException: unknown parameter type. 
      at org.bouncycastle.jce.provider.JCERSACipher.engineInit(Unknown Source) 
      at javax.crypto.Cipher.implInit(Cipher.java:791) 
      at javax.crypto.Cipher.chooseProvider(Cipher.java:849) 
      at javax.crypto.Cipher.init(Cipher.java:1348) 
      at javax.crypto.Cipher.init(Cipher.java:1282) 
      at org.apache.xml.security.encryption.XMLCipher.decryptKey(XMLCipher.java:1475) 
      at org.opensaml.xml.encryption.Decrypter.decryptKey(Decrypter.java:697) 
      ... 41 more 
     09:21:51,120 ERROR Decrypter:639 - Failed to decrypt EncryptedKey, valid decryption key could not be resolved 
     09:21:51,120 DEBUG Decrypter:787 - Attempt to decrypt EncryptedData using key extracted from EncryptedKey faile 

Wcześniej byłem coraz Invalide błędu rozmiaru klucza, który ja ustalonej za pomocą Spring SAML ADFS: java.security.InvalidKeyException. Jednak nie jestem pewien, czy będzie to miało żadnego wpływu na prawa polityki bezpieczeństwa USA .

Ale to wyjątek odszyfrować nie jest rozwiązany, a jego uzyskanie nie spójne. Jakiś czas zacznie działać po ponownym uruchomieniu serwera.

próbowałem każdego i wszystko, co w ostatnich 2-3 dni. Myślałem problem występuje po odświeżeniu metadanych więc próbowałem dodać poniżej właściwość ResourceBacked Fasola MetadataProvider, ale bez powodzenia.

<property name="parserPool" ref="parserPool"/> 
<property name="minRefreshDelay" value="120000"/> 
<property name="maxRefreshDelay" value="300000"/> 

Potem debugowania kodu WebSSOProfileConsumerImpl.java że to mught być problem związany z jira więc kasy najnowszy kod i utworzyć nowy słoik i dodaje do mojego projektu, ale bez powodzenia.

Answer 1

Po spędzeniu jednego tygodnia na debugowaniu i wyszukiwaniu w Google, postanowiłem rozwiązać ten problem przy pomocy małego hacka.

Sprawdziłem kod źródłowy Spring-Saml z głównego repozytorium gitHub Repository i skompilowałem słoik i zaimportowałem go do mojego projektu. Myślałem, że ten numer SES-144 jest podobny do mojego, więc próbowałem z najnowszym kodem, ale bez powodzenia.

Postanowiłem więc zdebugować kod xmlTooling.jar i znaleźć dokładny punkt awarii oraz zapisać poniższą metodę decryptKey(EncryptedKey encryptedKey, String algorithm) w XMLCipher.java z poniższym kodem.

Cipher c = constructCipher(encryptedKey.getEncryptionMethod() 
        .getAlgorithm(), encryptedKey.getEncryptionMethod() 
        .getDigestAlgorithm()); 

Instead of calling 
    c.init(4, key, oaepParameters); 
used below code and removed if/else block 
    c.init(4, key); 

można sprowadzić niestandardowych słoików z github

Musisz zaktualizować swoją zależność SAML poniżej linii w pliku pom.xml aby użyć ten zwyczaj Jar

<dependency> 
    <groupId>org.springframework.security.extensions</groupId> 
    <artifactId>spring-security-saml2-core</artifactId> 
    <version>1.0.1.RELEASE</version> 

    <exclusions> 
      <exclusion> 
        <artifactId>xmlsec</artifactId> 
        <groupId>org.apache.santuario</groupId> 
      </exclusion> 
    </exclusions> 
</dependency> 

<dependency> 
    <artifactId>xmlsec</artifactId> 
    <groupId>org.apache.santuario</groupId> 
    <version>1.5.6-custom</version> 
</dependency> 

Jeśli ktoś znaleźć lepsze rozwiązanie proszę dać mi znać.