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 for all providers is invalid or missing metadata. Please ensure that you have uploaded valid metadata for your provider before testing.

SP Logs:

  • INFO Shibboleth.AttributeExtractor.XML [1130] [default]: skipping unmapped SAML 2.0 Attribute with Name: favoritePizza, Format:urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified: SAMLtest only maps and displays attributes that are commonly used attributes with a URI NameFormat, e.g. urn:oasis:names:tc:SAML:2.0:attrname-format:uri. If you send attributes with a null NameFormat, a urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified NameFormat will be presumed. You’ll still be able to see the attributes in the logs, but they will not be visible on the landing page.
  • 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.
  • 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.
  • 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.
  • INFO Shibboleth.SessionInitiator.SAML2 [51] [default]: unable to locate SAML 2.0 identity provider role for provider (provider): You have successfully uploaded metadata for your provider, but it’s apparently SP metadata. Please use the SP test for your SP or upload IdP metadata.
  • ERROR [org.opensaml.xmlsec.keyinfo.impl.provider.InlineX509DataProvider:?] – Error extracting certificates from X509Data org.cryptacular.EncodingException: Cannot decode certificate: The certificate that you are have in your metadata is not parseable and should be fixed. Until then, all assertions sent to your SP will be unencryoted.

IdP Logs:

  • WARN [net.shibboleth.idp.profile.impl.SelectProfileConfiguration:117] – Profile Action SelectProfileConfiguration: Profile is not available for RP configuration shibboleth.UnverifiedRelyingParty (RPID 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 SP.
  • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified is not supported by the IdP in any context because of the overwhelming zen in specifying the unspecified. You will receive messages like WARN [org.opensaml.saml.common.profile.logic.MetadataNameIdentifierFormatStrategy:74] – Ignoring NameIDFormat metadata that includes the ‘unspecified’ format. Instead, try using a different existing NameID, an attribute, or defining your own NameID with a clear meaning.
  • WARN [net.shibboleth.idp.saml.profile.impl.PopulateBindingAndEndpointContexts:?] – Profile Action PopulateBindingAndEndpointContexts: Unable to resolve outbound message endpoint for relying party ‘’: EndpointCriterion [type={urn:oasis:names:tc:SAML:2.0:metadata}AssertionConsumerService, Binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST, Location=, 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 for return 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.
  • WARN [org.opensaml.profile.action.impl.LogEvent:105] – A non-proceed event occurred while processing the request: MessageAuthenticationError: SAML messages, including logout requests(, must be appropriately authenticated, which generally means signed. The message that was sent was not able to be authenticated, perhaps for lack of a signature or a key mismatch.
  • WARN [org.opensaml.profile.action.impl.LogEvent:?] – A non-proceed event occurred while processing the request: NoPassive: The password-based authentication form is interactive, so if you send IsPassive=”true”, then the IdP will be unable to honor it. While existing sessions and support for basic authentication are passive, the IdP more likely needs to display a login page, so IsPassive=”true” is not supported. If you have a specific need for it, please ask and we’ll see what we can do.