August 17, 2018

What does this error mean?

Something’s broken.

But more seriously, this is list of abbreviated errors that appear in SAMLtest’s logs that you may encounter when something is misaligned and a brief explanation of how to remediate the problem.

The most common issue is invalid metadata. In particular, ensure that your metadata’s validUntil is at some point in the future or SAMLtest will consider it expired and you must upload a fresh copy with a validity date in the future.

SP Logs:

  • WARN Shibboleth.SessionInitiator.SAML2: unable to locate metadata for provider: This message means that you have either not uploaded metadata for your IdP or the entityID in the uploaded metadata doesn’t match the entityID that was in the AuthnRequest. Make sure to upload your metadata.
  • ERROR OpenSAML.MetadataProvider.Dynamic: error while resolving (https://entityid/here): Root of metadata instance was not an EntityDescriptor: Metadata that you upload must not be wrapped by EntitiesDescriptor elements because SAMLtest uses the LocalDynamic metadata provider, which does a direct SHA-1 hash on the inbound entityID and searches for a file by that name. Please remove the EntitiesDescriptor open and close tags.
  • DEBUG Shibboleth.AttributeExtractor.XML [64] [default]: skipping unmapped NameID with format (urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified): Shibboleth by default ignores all instances of urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified, whether in actual assertions, metadata, or AuthnRequests because, well, unspecified is by definition not a specified format with any meaning. If you’re utilizing these NameID’s, you’ll see them in your assertions in the logs, but they won’t be mapped to anything by the SP other than the session index.
  • WARN Shibboleth.SSO.SAML2: error processing incoming assertion: Message was signed, but signature could not be verified: the key that was used to sign the assertion doesn’t match any valid key with either usage=”signing” or null usage in your IdP’s metadata.
  • WARN OpenSAML.SecurityPolicyRule.MessageFlow [100] [default]: rejected expired message, timestamp (epoch), oldest allowed (epoch): Shibboleth allows for some modest clock skew between providers, but the security of SAML and the bounds of the replay cache dictate that this duration is less than 10 minutes in most cases. Please ensure the clock on your IdP is correct.

IdP Logs:

  • WARN [net.shibboleth.idp.profile.impl.SelectProfileConfiguration:117] – Profile Action SelectProfileConfiguration: Profile http://shibboleth.net/ns/profiles/saml2/sso/browser is not available for RP configuration shibboleth.UnverifiedRelyingParty (RPID https://sp.example.org/shibboleth): Shibboleth is configured to selectively send assertions only to partners that it recognizes, so this message indicates that your SP is not trusted by SAMLtest’s IdP. Please ensure you’ve uploaded correct metadata for your IdP.
  • WARN [net.shibboleth.idp.saml.profile.impl.PopulateBindingAndEndpointContexts:?] – Profile Action PopulateBindingAndEndpointContexts: Unable to resolve outbound message endpoint for relying party ‘http://example.org/shibboleth’: EndpointCriterion [type={urn:oasis:names:tc:SAML:2.0:metadata}AssertionConsumerService, Binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST, Location=http://example.org/Shibboleth.sso/SAML2/POST, trusted=false]: The IdP checks to ensure that the recipient of an assertion matches precisely one of the valid AssertionConsumerService URL’s in your provider’s metadata for security purposes. While there could be any number of reasons for a mismatch, the most common by far is that you have https: endpoints in your metadata and your AuthnRequest was issued over http:, or vice versa. Shibboleth relies on the web environment to generate these URL’s, so if you downloaded your metadata and accessed the login initiator over different schemes, you will get this error. Try to use https everywhere.