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.
These are issues that affect the IdP when it starts up:
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).
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:
These are issues that indicate a problem with the security of either an incoming request or an outgoing response
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.
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.
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:
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.
These are issues that affect specific incoming protocol messages.
This is caused by one of three issues:
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.
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.
These are issues that affect the authentication of the user.
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:
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:
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.
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:
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.server.xml
) to only use one.If this error is only encountered occasionally by some users, possible causes are:
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.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.
These are issues that affect the resolution, release, and encoding of user attributes.
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.
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:
AttributeRule
permitting the release of the attribute; only attributes which are explicitly permitted are releasedPolicyRequirementRule
, 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.