algorithm URI was invalid: http://www.w3.org/2001/04/xmlenc#aes128-cbc

Joy Veronneau jv11 at cornell.edu
Thu Sep 26 22:41:10 EDT 2013


Hi,

Thanks for continuing to look at this. You are probably correct, at this point I think it is not working for any SPs. I think that for some of the SPs we already had the "encryptAssertions" set to "never", so that was why I was thinking only some SPs were causing the error.

I looked at the logs, and even in debug mode there are no other messages, but here is the stack trace in case that helps.

Is there any other information I could provide that would be helpful?

Thanks,

Joy

08:54:30.000 - ERROR [org.opensaml.xml.encryption.Encrypter:649] - Could not generate encryption key, algorithm URI was 
invalid: http://www.w3.org/2001/04/xmlenc#aes128-cbc
08:54:30.002 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:294] - Unable to
 encrypt assertion
org.opensaml.xml.encryption.EncryptionException: Could not generate encryption key, algorithm URI was invalid: http://ww
w.w3.org/2001/04/xmlenc#aes128-cbc
        at org.opensaml.xml.encryption.Encrypter.generateEncryptionKey(Encrypter.java:650) ~[xmltooling-1.4.0.jar:na]
        at org.opensaml.saml2.encryption.Encrypter.encrypt(Encrypter.java:341) ~[opensaml-2.6.0.jar:na]
        at org.opensaml.saml2.encryption.Encrypter.encrypt(Encrypter.java:258) ~[opensaml-2.6.0.jar:na]
        at edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.buildResponse(AbstractSAML2
ProfileHandler.java:287) ~[shibboleth-identityprovider-2.4.0.jar:na]
        at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.completeAuthenticationRequest(SSOProf
ileHandler.java:319) ~[shibboleth-identityprovider-2.4.0.jar:na]
        at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.processRequest(SSOProfileHandler.java
:173) ~[shibboleth-identityprovider-2.4.0.jar:na]
        at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.processRequest(SSOProfileHandler.java
:90) ~[shibboleth-identityprovider-2.4.0.jar:na]
        at edu.internet2.middleware.shibboleth.common.profile.ProfileRequestDispatcherServlet.service(ProfileRequestDisp
atcherServlet.java:83) ~[shibboleth-common-1.4.0.jar:na]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) ~[servlet-api.jar:na]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) ~[catalina.
jar:na]
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) ~[catalina.jar:na]
        at edu.internet2.middleware.shibboleth.idp.util.NoCacheFilter.doFilter(NoCacheFilter.java:50) ~[shibboleth-ident
ityprovider-2.4.0.jar:na]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) ~[catalina.
jar:na]
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) ~[catalina.jar:na]
        at edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter.doFilter(IdPSessionFilter.java:87) ~[shibbol
eth-identityprovider-2.4.0.jar:na]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) ~[catalina.
jar:na]
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) ~[catalina.jar:na]
        at edu.internet2.middleware.shibboleth.common.log.SLF4JMDCCleanupFilter.doFilter(SLF4JMDCCleanupFilter.java:52) 
~[shibboleth-common-1.4.0.jar:na]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) ~[catalina.
jar:na]
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) ~[catalina.jar:na]
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) ~[catalina.jar:na]
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) ~[catalina.jar:na]
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) ~[catalina.jar:na]
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) ~[catalina.jar:na]
        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567) ~[catalina.jar:na]
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) ~[catalina.jar:na]
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) ~[catalina.jar:na]
        at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) ~[tomcat-coyote.jar:na]
        at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) ~[tomcat-coyote.jar:na]
        at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769) ~[tomcat-coyote.jar:na]
        at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698) ~[tomcat-coyote.jar:na]
        at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891) ~[tomcat-coyote.jar:na]
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) ~[tomcat-coyote.jar:na]
        at java.lang.Thread.run(Unknown Source) ~[na:1.7.0_25]
08:54:30.003 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:796] - Encoding respons
e to SAML request _ada8c3b35c92745b0369859f35989e34 from relying party https://corp.collegenet.com/shibboleth-sp/

On Sep 26, 2013, at 3:18 PM, Brent Putman <putmanb at georgetown.edu> wrote:

> 
> On 9/26/13 2:03 PM, Cantor, Scott wrote:
>> 
>> Were that the case, though, there's no way it would work for *any* SPs. I
>> can't think of any scenario  in today's IdP that could be specific to one
>> SP unless some kind of interaction were possible between code that is
>> looking for the RSA key in metadata.
> 
> 
> Right, I don't see any scenario either for per-SP behavior either.  I'm
> literally just trying to understand at a code level exactly what is
> happening.  Without that, everything else is speculation.
> 
> 
>> So perhaps the error is somehow
>> mis-reporting itself as being about the AES algorithm.
> 
> Maybe, that's why I was interested in the additional logging.
> 
>> 
>> A lot of this comes down to that issue. All the messages have alluded to
>> the claim that encryption is working for some. I think that claim has to
>> be examined.
> 
> 
> I was pretty much half-way assuming that that could not be the case. 
> Based on the code, I don't see any way that this can be SP-specific. 
> It's too low-level.  It's not even related to metadata.  I'm (almost)
> 100% certain It's either Santuario or something at the JCA crypto
> provider level, and none of that has anything to do with SAML or Shib.
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> 




More information about the users mailing list