[JIRA] Commented: (SIDP-545) Automatic reloading of relying-party.xml results in errors
Brent Putman (JIRA)
noreply at shibboleth.net
Wed Sep 26 20:59:22 EDT 2012
[ https://issues.shibboleth.net/jira/browse/SIDP-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14421#comment-14421 ]
Brent Putman commented on SIDP-545:
-----------------------------------
Also, until an upgrade is possible, a workaround for deployers seems to be to also enable the handler manager (handler.xml) to be reloaded and to force that to reload at the same time as the relying-party.xml. This causes new profile handler instances to be created, which avoids the problem.
> Automatic reloading of relying-party.xml results in errors
> ----------------------------------------------------------
>
> Key: SIDP-545
> URL: https://issues.shibboleth.net/jira/browse/SIDP-545
> Project: Shibboleth IdP 2 - Java
> Issue Type: Bug
> Security Level: Standard(Standard bug, may impact functionality but does not represent a security vulnerability )
> Affects Versions: 2.3.6, 2.3.7, 2.3.8
> Environment: CentOS 6 x64, Tomcat 6.0.24, OpenJDK 1.6.0_22, Terracotta 3.6.1
> Reporter: Rhys Smith
> Assignee: Chad La Joie
> Fix For: 2.3.9
>
>
> Automatic reloading of relying-party.xml through the config alteration in service.xml is a bit b0rked. Simply touch the file so the timestamp changes - no other changes at all - and the config is reloaded automagically after the specified period, all good, no obvious errors displayed on DEBUG. Then when you try to connect to an SP where encryption is meant to happen, the browser displays an error - opensaml::FatalProfileException - Error from identity provider:
> Status: urn:oasis:names:tc:SAML:2.0:status:Responder
> Message: Unable to encrypt assertion
> And the IdP shows this in its logs:
> 08:44:27.686 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:923] - Could not resolve a key encryption credential for peer entity: https://sh2testsp1.iay.org.uk/shibboleth
> 08:44:27.688 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:289] - Unable to construct encrypter
> org.opensaml.xml.security.SecurityException: Could not resolve key encryption credential
> at edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.getEncrypter(AbstractSAML2ProfileHandler.java:924) ~[shibboleth-identityprovider-2.3.6.jar:na]
> at edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.buildResponse(AbstractSAML2ProfileHandler.java:286) ~[shibboleth-identityprovider-2.3.6.jar:na]
> at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.completeAuthenticationRequest(SSOProfileHandler.java:310) [shibboleth-identityprovider-2.3.6.jar:na]
> at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.processRequest(SSOProfileHandler.java:177) [shibboleth-identityprovider-2.3.6.jar:na]
> at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.processRequest(SSOProfileHandler.java:88) [shibboleth-identityprovider-2.3.6.jar:na]
> at edu.internet2.middleware.shibboleth.common.profile.ProfileRequestDispatcherServlet.service(ProfileRequestDispatcherServlet.java:84) [shibboleth-common-1.3.5.jar:na]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) [tomcat6-servlet-2.5-api-6.0.24.jar:na]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) [catalina-6.0.24.jar:na]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina-6.0.24.jar:na]
> at edu.internet2.middleware.shibboleth.idp.util.NoCacheFilter.doFilter(NoCacheFilter.java:50) [shibboleth-identityprovider-2.3.6.jar:na]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina-6.0.24.jar:na]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina-6.0.24.jar:na]
> at edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter.doFilter(IdPSessionFilter.java:81) [shibboleth-identityprovider-2.3.6.jar:na]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina-6.0.24.jar:na]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina-6.0.24.jar:na]
> at edu.internet2.middleware.shibboleth.common.log.SLF4JMDCCleanupFilter.doFilter(SLF4JMDCCleanupFilter.java:52) [shibboleth-common-1.3.5.jar:na]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina-6.0.24.jar:na]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina-6.0.24.jar:na]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219) [catalina-6.0.24.jar:na]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [catalina-6.0.24.jar:na]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [catalina-6.0.24.jar:na]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [catalina-6.0.24.jar:na]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [catalina-6.0.24.jar:na]
> at org.terracotta.modules.tomcat.tomcat_5_5.SessionValve55.invoke(SessionValve55.java:87) [na:na]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) [catalina-6.0.24.jar:na]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857) [tomcat-coyote-6.0.24.jar:na]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) [tomcat-coyote-6.0.24.jar:na]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) [tomcat-coyote-6.0.24.jar:na]
> at java.lang.Thread.run(Thread.java:679) [na:1.6.0_22]
> Needless to say I tried this before the reload and it worked just fine. Restarting the container means it then works just fine until the next time the relying-party.xml is modified.
> Can provide the whole log snippet with the relying-party.xml reloading on DEBUG if required out-of-band (don't want to post it on here as it shows all of my config :-) ).
> This has also been seen by other people, e.g. Brett Slaughter, as discussed on shib-users. His env: Server: RHEL6 x64, IdP: 2.3.6, Tomcat: 6.0.35.0, JVM: 1.7.0_03
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the commits
mailing list