We're having the same problems with this. We have multiple Jenkins instances that authenticate against Azure AD. Azure AD updates it's metadata quite frequently (normally every couple of weeks, but it can occur any time without warning). Every time this happens, nobody can logon to Jenkins anymore. This means a major outage of Jenkins for our many Jenkins users. 

To 'fix' this means manually logging on to our many Jenkins servers and updating the IDP metadata in the Jenkins config.xml file. (tip: if you just paste the updated metadata in the config file and then restart Jenkins, you won't lose all your security configuration).

It's considered best practice, if you authenticate against Azure AD, to reference the metadata by URL, instead of copy-pasting the metadata, as Azure can update the certificates at any time. It's really a big problem for us that the SAML plugin doesn't support this.

This issue can be resolved by implementing JENKINS-41907. 

there is a workaround in 1.0.3 version you can replace the JENKINS_HOME/saml-idp-metadata.xml file

OK, after updating to version 1.0.3 and the mentioned workaround, everything works as expected.

This is a large step forward, as I now only need to download the metadata from IdP, remove the String "<?xml version="1.0" encoding="utf-8"?>" at the beginning and save it as saml-idp.metadata.xml (remark: there's a little typo in your comment, you have to replace the second "-" with ".").

I think, if I could just configure the Saml IdP metadata download URL and the download is automatically triggered (e.g. each day or at least when this exception occurs) and saved in the file, that would be a good solution for this problem. Catching this Exception properly (e.g. when the IdP metadata is not available anymore) could make it perfect.

So now, the update is so much easier! But the users still complain when they see the Oooops and can't work with Jenkins anymore until I update the metadata.

released 1.0.5

After updating the plugin to version 1.0.5 I experienced the same Ooops again. I had to grant temporary access to everyone (<sid>anonymous</sid> in <assignedSIDs> in config.xml). After that I could access and enter the metadata URL in the plugin. Finally, I removed the anonymous-sid again. Now everything works as expected. Many thanks for your work.

I am also running 1.0.5 and provided the IdP URL provided. I also still regularly get this error. Should I submit a new issue, since this one list listed as resolved? When it happens the user has to go to office365, logout and then revisit the Jenkins server and login again.

dwatroustrinet Open a new one, please attach the log when the issue is exposed with the loggers activated, also you can take a look at troubleshooting guide in the Azure section you have son setting to activate that resolve the issue, finally I wonder the Entry Id type that you have in your IdP Metadata we are tracking a similar issue with Azure on https://issues.jenkins-ci.org/browse/JENKINS-48030 case see the latest 10 comments.