We restarted the *idp* service this morning to enable several new configurations. One metadata was not parsing according to the *idp-warn.log* file. When this happens, the entire Gluu Shibboleth instance fails and all accesses return a 503. We removed the Canvas trust relationship from our configuration, so the other 60 trust relationships would function. Since we removed the Canvas trust relationship, users can now login. To rule out the 60 other configurations, we added the Canvas metadata via a file to a test instance with no other trust relationships. The result is that Gluu Shibboleth does not work. I have attached the Canvas metadata XML. I see nothing wrong with the metadata and we validated the metadata with OneLogin. You can observe the problem by using the attached metadata with a new trust relationship and then restarting the *idp* service. Here is what I see repeated in the *idp-warn.log* file. >2020-09-27 13:55:38,808 - - ERROR [org.opensaml.saml.metadata.resolver.impl.AbstractReloadingMetadataResolver:449] - Metadata Resolver FilesystemMetadataResolver SiteSP1: Unable to unmarshall metadata 2020-09-27 13:55:38,809 - - ERROR [org.opensaml.saml.metadata.resolver.impl.AbstractReloadingMetadataResolver:364] - Metadata Resolver FilesystemMetadataResolver SiteSP1: Error occurred while attempting to refresh metadata from '/opt/shibboleth-idp/metadata/AFE14DA7FAD7F545000265E63CE200061FF58C2E-sp-metadata.xml' I have verified that the file exists. This was working prior to the restart this morning. Looking at the file, I suspect the issue is with the below element. ><md:RequestedAttribute Name=""/> What are your thoughts? Regardless of whether the metadata is bad, the entire Gluu Shibboleth instance should not be brought down by an error in a single trust relationship.