• Have authentication set up using SAML with no custom encryption options
• Wait (I suspect waiting a year for validity expiration is what triggers this)
• Log in attempts break with a verbose backtrace on the login page

  Stack trace
  org.pac4j.core.exception.TechnicalException: Unsupported resource format: jar:file:/srv/jenkins/home/plugins/saml/WEB-INF/lib/saml.jar!/samlKeystore.jks. Use a relative or absolute path
  	at org.pac4j.core.util.CommonHelper$1.getFilename(CommonHelper.java:373)
  	at org.pac4j.saml.client.SAML2ClientConfiguration.getKeystorePath(SAML2ClientConfiguration.java:313)
  	at org.pac4j.saml.crypto.KeyStoreCredentialProvider.<init>(KeyStoreCredentialProvider.java:92)
  	at org.pac4j.saml.client.SAML2Client.initCredentialProvider(SAML2Client.java:174)
  	at org.pac4j.saml.client.SAML2Client.internalInit(SAML2Client.java:111)
  	at org.pac4j.core.util.InitializableWebObject.init(InitializableWebObject.java:24)
  	at org.jenkinsci.plugins.saml.OpenSAMLWrapper.createSAML2Client(OpenSAMLWrapper.java:145)
  	at org.jenkinsci.plugins.saml.SamlRedirectActionWrapper.process(SamlRedirectActionWrapper.java:45)
  	at org.jenkinsci.plugins.saml.SamlRedirectActionWrapper.process(SamlRedirectActionWrapper.java:30)
  	at org.jenkinsci.plugins.saml.OpenSAMLWrapper.get(OpenSAMLWrapper.java:64)
  	at org.jenkinsci.plugins.saml.SamlSecurityRealm.doCommenceLogin(SamlSecurityRealm.java:258)
  	at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627)
  	at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:396)
  	at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:408)
  	at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:212)
  	at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:145)
  	at org.kohsuke.stapler.MetaClass$11.doDispatch(MetaClass.java:537)
  	at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58)
  	at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:739)
  

The call stack above is misleading. It appears to be caused by the "demo keystore" path (PAC4J_DEMO_KEYSTORE) being invalid in principle. The real issue is however that the plugin tries to use the demo key store in the first place, which is hinted at in a brief log line with no backtrace:

WARNING: Using bundled keystore : /srv/jenkins/home/saml-jenkins-keystore.jks (Permission denied)
Jun 19, 2019 8:19:44 AM org.jenkinsci.plugins.saml.OpenSAMLWrapper createSAML2Client
WARNING: Using bundled keystore : resource:samlKeystore.jks

The configuration used no custom encryption settings, so whatever default key store the plugin wanted was used. Trying to disable and enable the saml authentication did not help, trying to use a custom key store in encryption settings an dreverting back to the default did not work.

Looking at the code I realized it has code to create the key store from scratch if it doesn't exist and sure enough, removing (moving away)

rm $JENKINS_HOME/saml-jenkins-keystore.jks
rm $JENKINS_HOME/saml-jenkins-keystore.xml

and reconfiguring the plugin made login work again.

I'm filing this mainly to have a reference to the workaround, because I couldn't find anything about this error anywhere. I do think that at the very least, the error path in the keystore loading code should give more info before trying to load the demo keystroke. It's confusing that the call stack is not from the actual problem.

Perhaps the plugin should also handle the key store corruption / expiration in a more graceful way, but that's less obvious to me.