<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>We’ve configured IdP v2.3.6 on RHEL6 x64 to reload the attribute filter engine, attribute resolver, and relying party configuration manager services every 2 hours in service.xml. The IdP starts normally and runs fine, however the IdP starts throwing errors after the relying party configuration manager reloads following a manual change to relying-party.xml even though the affected SPs were accessed successfully prior to the reload. These issues are resolved after restarting Tomcat. The SPs involved in the error’d transactions differ after each Tomcat restart/relying-party update. The specific errors encountered on the IdP are pasted below, and result in a FatalProfileException with message “Unable to encrypt assertion” on the SP.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>12:02:00.516 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:923] - [cl.ie.nt.ip] - Could not resolve a key encryption credential for peer entity: <a href="https://some-sp.domain.edu/shibboleth">https://some-sp.domain.edu/shibboleth</a><o:p></o:p></p><p class=MsoNormal>12:02:00.518 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:289] - [cl.ie.nt.ip] - Unable to construct encrypter<o:p></o:p></p><p class=MsoNormal>org.opensaml.xml.security.SecurityException: Could not resolve key encryption credential<o:p></o:p></p><p class=MsoNormal> at edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.getEncrypter(AbstractSAML2ProfileHandler.java:924) ~[shibboleth-identityprovider-2.3.6.jar:na]<o:p></o:p></p><p class=MsoNormal> at edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.buildResponse(AbstractSAML2ProfileHandler.java:286) ~[shibboleth-identityprovider-2.3.6.jar:na]<o:p></o:p></p><p class=MsoNormal> at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.completeAuthenticationRequest(SSOProfileHandler.java:310) [shibboleth-identityprovider-2.3.6.jar:na]<o:p></o:p></p><p class=MsoNormal> at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.processRequest(SSOProfileHandler.java:177) [shibboleth-identityprovider-2.3.6.jar:na]<o:p></o:p></p><p class=MsoNormal> at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.processRequest(SSOProfileHandler.java:88) [shibboleth-identityprovider-2.3.6.jar:na]<o:p></o:p></p><p class=MsoNormal> at edu.internet2.middleware.shibboleth.common.profile.ProfileRequestDispatcherServlet.service(ProfileRequestDispatcherServlet.java:84) [shibboleth-common-1.3.5.jar:na]<o:p></o:p></p><p class=MsoNormal> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) [servlet-api.jar:na]<o:p></o:p></p><p class=MsoNormal> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) [catalina.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at edu.internet2.middleware.shibboleth.idp.util.NoCacheFilter.doFilter(NoCacheFilter.java:50) [shibboleth-identityprovider-2.3.6.jar:na]<o:p></o:p></p><p class=MsoNormal> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter.doFilter(IdPSessionFilter.java:81) [shibboleth-identityprovider-2.3.6.jar:na]<o:p></o:p></p><p class=MsoNormal> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at edu.internet2.middleware.shibboleth.common.log.SLF4JMDCCleanupFilter.doFilter(SLF4JMDCCleanupFilter.java:52) [shibboleth-common-1.3.5.jar:na]<o:p></o:p></p><p class=MsoNormal> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219) [catalina.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [catalina.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [catalina.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [catalina.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [catalina.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) [catalina.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) [tomcat-coyote.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) [tomcat-coyote.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:776) [tomcat-coyote.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:705) [tomcat-coyote.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898) [tomcat-coyote.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) [tomcat-coyote.jar:6.0.35]<o:p></o:p></p><p class=MsoNormal> at java.lang.Thread.run(Thread.java:722) [na:1.7.0_03]<o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The reload configuration for relying party in service.xml is (polling attributes are the same for attribute filter and resolver):<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><srv:Service id="shibboleth.RelyingPartyConfigurationManager" xsi:type="relyingParty:SAMLMDRelyingPartyConfigurationManager" depends-on="shibboleth.SAML1AttributeAuthority shibboleth.SAML2AttributeAuthority" configurationResourcePollingFrequency="PT120M" configurationResourcePollingRetryAttempts="12"><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in;text-indent:.5in'><srv:ConfigurationResource file="/opt/shibboleth-idp/conf/relying-party.xml" xsi:type="resource:FilesystemResource"/><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'></srv:Service><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The IdP Common Errors page on the wiki suggests the “Unable to construct encrypter” error is related to the SP metadata not having an encryption certificate. I’ve confirmed that each of the SPs encountering this error all have a certificate, all of which omit the ‘use’ attribute. Somewhere in the reload of the relying party file, certain certificates are not being read from the SP metadata files, though they are read successfully during IdP startup.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This behavior can be reproduced in my DEV and QA environments. The only change made to relying-party.xml between automatic reloads is to `touch` the file to update the modified timestamp. I’ve removed the other reloading configurations, leaving relying party as the only service being reloaded, and the problem persists. There’s nothing in the logs (at DEBUG level) for the reload indicating anything failed or was not successfully reloaded.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We are well aware of the warning on the wiki regarding use of the configuration reloading in production, and we have sufficient configuration testing in place to prevent invalid configurations from being loaded into the production environment. The goal of using the reloading features is to provide shorter turn-around when adding new SPs to the IdP and modifying attributes and release policies without resetting session state for all authenticated users by restarting Tomcat entirely. Given this issue, however, we’ve delayed implementation of this feature and instead scheduled a restart of Tomcat nightly to pick up any changes made the previous day, which means even the smallest change doesn’t take effect until the following day.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>What is preventing the IdP from using an SP’s encryption certificate following a reload of the relying party service, when the same SP works fine prior the reload?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal>Server: RHEL6 x64<o:p></o:p></p><p class=MsoNormal>IdP: 2.3.6<o:p></o:p></p><p class=MsoNormal>Tomcat: 6.0.35.0<o:p></o:p></p><p class=MsoNormal>JVM: 1.7.0_03<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b><i><span style='font-size:12.0pt;color:#365F91'><o:p> </o:p></span></i></b></p><p class=MsoNormal>Brett Slaughter<o:p></o:p></p><p class=MsoNormal>Information Security & Access Management | ISAM<o:p></o:p></p><p class=MsoNormal>Division of IT, University of Missouri<o:p></o:p></p><p class=MsoNormal><a href="mailto:slaughter@missouri.edu"><span style='color:windowtext;text-decoration:none'>slaughter@missouri.edu</span></a><o:p></o:p></p></div></body></html>