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