Common Errors

The following errors are commonly encountered by users, usually when initially setting up their IdP. The best means of troubleshooting these errors is to turn on debug logging, find the error message, and read the log messages (usually anywhere between 5-20 messages) prior to the error. This should provide the context within which the error is occurring.

Startup Issues

These are issues that affect the IdP when it starts up:

org.opensaml.xml.XMLConfigurator: UndeclaredPrefix: Cannot resolve 'xt:DEFAULT' as a QName: the prefix 'xt' is not declared.

OpenSAML requires an xml parser that supports JAXP 1.3 and DOM3. The JVM is currently configured to use the Sun XML parser, which is known to be buggy and can not be used with OpenSAML.

This error is always because you did not not endorse Xerces and Xalan. If you think you did then you have made a mistake, perhaps because your application container isn't doing what you think it's doing (for example, Tomcat "helpfully" overrides the default location of the endorsed library directory).

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'shibboleth....'

This indicates a syntactic or logical error in a config file. Often this is due a configuration element containing a reference to another element which is not present (perhaps commented out).

The bean name (e.g. shibboleth.RelyingPartyConfigurationManager) will often indicate the file in which the error is located. The relationships are defined in service.xml, currently as follows:

• shibboleth.RelyingPartyConfigurationManager: relying-party.xml
• shibboleth.AttributeResolver: attribute-resolver.xml
• shibboleth.AttributeFilterEngine: attribute-filter.xml
• shibboleth.HandlerManager: handler.xml

Message Security Issues

These are issues that indicate a problem with the security of either an incoming request or an outgoing response

org.opensaml.ws.security.SecurityPolicyException: Rejecting replayed message ID '#' from issuer https://your.sp.example.org/shibboleth-sp

This SAML authentication request has already been presented once and you're presenting it again. This is not allowed for security reasons. You should ask your SP to issue a fresh one, and avoid using the "back" button of some browsers. Alternatively, this issue may stem from the SP only restarting shibd after making certain SP modifications, but not their web server - if they have not, have them try restarting their web server as well.

org.opensaml.ws.security.SecurityPolicyException: Message was rejected due to issue instant expiration

This error is caused when the SAML authentication request received by the IdP was issued too long ago. The machine running the IdP or SP has a clock that is wrong, or you took a very long time to get from your SP to the IdP for some reason. You should always run ntpd and know that VM's will tend to have severe clock issues.

org.opensaml.ws.security.provider.MandatoryAuthenticatedMessageRule Inbound message issuer was not authenticated.

This rule requires that the peer system entity (e.g an SP from the perspective of the IdP) that is the issuer of the SAML protocol message be authenticated. This happens typically within another prior security policy rule or rules that process for example client TLS certificates or a digital signature over the message (either XML message signature or raw/blob binding-specific signature). Look for log messages indicating failures in these rules to determine the exact cause of the failure.

Common specific reasons are:

1. Protocol message is delivered over SOAP binding (e.g an attribute query or artifact resolve message) and the client TLS cert is either not present in the request or is not trusted. The former is often caused by incorrect configuration of the web server's and/or servlet container's SSL/TLS endpoint. The latter is often a result of required trust information in metadata for the peer being absent or invalid.
2. Protocol message was delivered over a front-channel binding such as HTTP POST or Redirect, and the message was either not signed or the signature was invalid. The former is because the peer did not sign the message. The latter is often a result of required trust information in metadata for the peer being absent or invalid.

edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler: Unable to construct encrypter, caused by: org.opensaml.xml.security.SecurityException: Could not resolve key encryption credential

If the IdP is configured to encrypt assertions or name ID's to a particular SP, the metadata for the SP (as held by the IdP) must contain the public key that will be used for key encryption. This key encryption key (usually a public key or certificate) must be represented in metadata within the EntityDescriptor/SPSSODescriptor/KeyDescriptor for the SP in question. The KeyDescriptor must either omit the 'use' attribute or have a value of 'use="encryption"'. The KeyInfo contained within the KeyDescriptor must contain either the SP's certificate in an X509Data/X509Certificate element, or must contain the SP's raw public key value in a KeyValue element.

Endpoint Issues

These are issues that affect specific incoming protocol messages.

edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler: No return endpoint available for relying party ...

This is caused by one of three issues:

• There is no metadata, for the relying party, available to the Identity Provider and such metadata is required for the IdP to determine where to send a response. Some examples of this are:
  • Actually have no metadata whatsoever for the relying party; it may have been filtered out or expired
  • A service provider sends a SAML 2 request but the IdP only has SAML 1 metadata for that service
  • A service provider, issuing a SAML 2 request, sends an assertion consumer service index within a message (as the IdP is required to look up the URL associated with that index within metadata)
• The IdP does not support the binding for the response endpoint requested by the service providers. For example if the SP requires the IdP send a response back by means of an artifact but the IdP does not support artifacts.
• A generalized case of the previous issue. The Service provider does not specify a particular response endpoint, but the IdP does not support any of bindings listed in the service providers metadata. For example, the IdP is configured to support POST and Redirect and the service provider metadata indicates it only supports POST-SimpleSign and Artifact.

SAML 2 SSO profile is not configured for relying party

This usually indicates a metadata problem, which results in the IdP assigning the incoming request to the category of an "anonymous" relying party. By default, anonymous requests are not handled, so indeed the SAML 2 profile is not configured in that case. To fix it, supply correct/valid metadata for the requesting SP to the IdP. If you do have metadata, it's broken or invalid in some way. Check the idp-process.log for warning messages indicating why it was unacceptable.

In rare cases, you could encounter this error if you change default settings such that particular SPs are not allowed to use that profile. Of course, in that case, the error may be perfectly normal.

Error processing profile request java.lang.ClassCastException: org.opensaml.saml1.core.impl.RequestImpl cannot be cast to org.opensaml.saml2.core.AttributeQuery

This indicates that the SP being connected to is attempting to make a SAML1 back-channel attribute request to a SAML2 endpoint.  It is usually caused by improperly configured IdP endpoints at the federation.  Some federations do not support SAML2 yet and trying to "fool" them by putting the 2.0 endpoints into their 1.0 fields will not work.

Authentication Issues

These are issues that affect the authentication of the user.

User is required to authenticate to every Service Provider (i.e., no SSO occurs)

This issues is almost always due to a misconfiguration of something outside the IdP. But there are two things within the IdP's configuration that may cause this:

• The Previous Session login handler has been disabled
• The IdP's session timeout or the authenticationDuration for the login handler as set to very low numbers.

The more common cause of this issue is a problem with the environment in which the IdP is deployed. The IdP, like every other stateful web application, uses cookies to associate a user-agent (the user's web browser) with the server-side session data. If that cookie fails to get back to the IdP then the session is lost and the user is required to log in again. This can occur due to:

• A mixing of HTTP and HTTPS requests. Cookies set via HTTPS are not available over HTTP.
• A load balancer, proxy, or web server using a different hostname for the IdP than the one with which the servlet container is configured.
• A load balancer, proxy, or filter mangling or removing the cookie from the request/response.
• A user-agent changing IP addresses in mid-session. The cookie is tied to the IP address of the user-agent when the session was established.

There is no way within the IdP to determine what the environmental issues is but, enabling TRACE debugging for the logger edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter will tell you whether the IdP receives a valid session cookie or not.

edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine: User HttpSession did not contain a login context. Unable to return to authentication engine

This error occurs when the servlet container loses the login context and the user's session across requests to the IdP through the authentication process.

If this error occurs after every authentication, possible causes are:

• The most likely cause of this is:omission of TLS/SSL https:// protection of either the SSO handler or the authentication handler. Both must be protected with SSL or the servlet container will lose the session at some point.
• Erroneous metadata entries which point to /idp/Authn/RemoteUser  or /idp/Authn/UsernamePassword rather than /idp/profile/Shibboleth/SSO produce this error.
• The other known cause is a misconfiguration of a machine with more than one host name. If the host name changes, the session is lost. So, make sure either you only have one hostname or your configure your servlet container(e.g. Tomcat's server.xml) to only use one.

If this error is only encountered occasionally by some users, possible causes are:

• Most likely, the user has set a bookmark for the page https://your.idp.example.org/idp/Authn/UserPassword after a successful authentication. The IdP of course doesn't know where to send the user in such a case.
• The user's web browser doesn't accept/send cookies
• You are running Tomcat earlier than 6.0.17. From IdP version 2.1.3, at least Tomcat 6.0.17 is required, otherwise it won't work with certain browsers like Internet Explorer and Chrome.

edu.internet2.middleware.shibboleth.idp.authn.AuthenticationException: No principal name returned from authentication handler.

Upon receipt of an authentication request, an SSO handler will redirect the user to the appropriate authentication handler to login. The authentication handler must set the username and then send the user back to the identity provider's SSO handler. If the authentication handler sends the user back to the SSO handler but fails to set the username, this error will result. Investigate why the authentication handler that was used would have sent back no username, such as omitting protection for the RemoteUser location.

Attribute Issues

These are issues that affect the resolution, release, and encoding of user attributes.

javax.naming.PartialResultException: Unprocessed Continuation Reference(s)

When using Microsoft Active Directory as a source of attribute data via the LDAP data connector, be aware of AD-specific configuration and deployment issues.

Attribute is not released to the Service Provider:

This issue can be caused by a number of things. Looking at your logs will help you determine which of the following problems is occurring:

• The attribute was not provided by a data connector, perhaps because it did not contain any values
• There is no attribute definition defined for that attribute (only attributes defined by an attribute definition are released from the resolver, anything else is just internal state)
• The attribute definition does not define a source attribute and/or dependency from which to pull the source attribute. This would cause the attribute to have no values and thus not be released.
• The attribute definition is marked as a dependency only attribute and thus is not released from the resolver
• The attribute definition does not define an encoder appropriate for the given request protocol (e.g., the attribute definition has a SAML 1 encoder but the current request is a SAML 2 request)
• The attribute is being filtered out by the attribute filter policy. The most common causes of this are:
  • there is no AttributeRule permitting the release of the attribute; only attributes which are explicitly permitted are released
  • the PolicyRequirementRule, for the AttributeFilterPolicy, does not permit the release of information for the given request.

Note, the authentication configuration in no way influences the resolution of attributes. If you configured LDAP authentication you still have to configure an LDAP data connector in order to pull in attributes about the user. The authentication step only returns a yes/no answer not user attributes.