Date: Fri, 29 Mar 2024 09:44:42 +0000 (UTC) Message-ID: <1414700648.37.1711705482855@e89e1969b9fa> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_36_1319962088.1711705482855" ------=_Part_36_1319962088.1711705482855 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The following errors are commonly encountered by users, usually when ini= tially 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 occ= urring.
These are issues that affect the IdP when it starts up:
This error is always because you did not not endorse Xe= rces 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 (f= or example, Tomcat "helpfully" overrides the default location of the endors= ed 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 w= hich is not present (perhaps commented out).
The bean name (e.g. shibboleth.RelyingPartyConfigurationManager) will of= ten 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
htt=
ps://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 shou= ld ask your SP to issue a fresh one, and avoid using the "back" button of s= ome browsers. Alternatively, this issue may stem from the SP only restartin= g shibd after making certain SP modifications, but not their web server - i= f they have not, have them try restarting their web server as well.
This error is caused when the SAML authentication request received by th= e IdP was issued too long ago. The machine running the IdP or SP has a cloc= k that is wrong, or you took a very long time to get from your SP to the Id= P for some reason. You should always run ntpd and know that VM's will ten= d to have severe clock issues.
This rule requires that the peer system entity (e.g an SP from the persp= ective of the IdP) that is the issuer of the SAML protocol message be authe= nticated. This happens typically within another prior security policy rule = or rules that process for example client TLS certificates or a digital sign= ature over the message (either XML message signature or raw/blob binding-sp= ecific 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 particu= lar SP, the metadata for the SP (as held by the IdP) must contain the publi= c key that will be used for key encryption. This key encryption key (usuall= y a public key or certificate) must be represented in metadata within the E= ntityDescriptor/SPSSODescriptor/KeyDescriptor for the SP in question. The K= eyDescriptor must either omit the 'use' attribute or have a value of 'use= =3D"encryption"'. The KeyInfo contained within the KeyDescriptor must conta= in either the SP's certificate in an X509Data/X509Certificate element, or m= ust 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 assi= gning the incoming request to the category of an "anonymous" relying party.= By default, anonymous requests are not handled, so indeed the SAML 2 profi= le 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 indicat= ing why it was unacceptable.
In rare cases, you could encounter this error if you change default sett= ings such that particular SPs are not allowed to use that profile. Of cours= e, in that case, the error may be perfectly normal.
This indicates that the SP being connected to is attempting to make a SA= ML1 back-channel attribute request to a SAML2 endpoint. It is usually= caused by improperly configured IdP endpoints at the federation. Som= e 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 outs= ide the IdP. But there are two things within the IdP's configuration that m= ay cause this:
authent=
icationDuration
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 applicat= ion, uses cookies to associate a user-agent (the user's web browser) with t= he server-side session data. If that cookie fails to get back to the IdP th= en the session is lost and the user is required to log in again. This can o= ccur due to:
There is no way within the IdP to determine what the environmental issue=
s is but, enabling TRACE debugging for the logger edu.internet2.middl=
eware.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 p= rocess.
If this error occurs after every authentication, possib= le 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 los=
e 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 authentica= tion handler must set the username and then send the user back to the ident= ity provider's SSO handler. If the authentication handler sends the user ba= ck 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.<= /p>
These are issues that affect the resolution, release, and encoding of us= er attributes.
When using Microsoft Active Directory as a source of attribute data via = the LDAP data connector, be aware of AD-specific configurati= on and deployment issues.
This issue can be caused by a number of things. Looking at your logs wil= l help you determine which of the following problems is occurring:
AttributeRule
permitting the release of the at=
tribute; only attributes which are explicitly permitted are releasedPolicyRequirementRule
, for the AttributeFilterPo=
licy
, does not permit the release of information for the given reque=
st.Note, the authentication configuration in no way influences the resoluti= on of attributes. If you configured LDAP authentication you still have to c= onfigure an LDAP data connector in order to pull in attributes about the us= er. The authentication step only returns a yes/no answer not user attribute= s.