Date: Thu, 28 Mar 2024 12:33:09 +0000 (UTC) Message-ID: <1520232566.1.1711629189975@f3c4ae8074c4> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_0_1132891328.1711629189960" ------=_Part_0_1132891328.1711629189960 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 initially setting up their SP.
Barring an actual replay attack, your SP's clock isn't synchronized with=
the clock of the IdP that issued the message. All servers using SAML
The certificate that was used to sign the message didn't match the one t= he SP expected based on metadata. That can be caused by, in order of likeli= hood:
relying-party.xml
, and hence, the o=
ne in the message. You should change them so they match. This error will b=
e presented in the browser for a variety of different underlying reasons. &=
nbsp;Check shibd.log
for more useful debugging information.
(https://identities.supervillain.edu/idp/shibboleth)
.This message indicates the SP tried to initiate a session with an entity= ID it doesn't recognize as belonging to an identity provider. That's probab= ly because the entityID in the SessionInit= iator has no corresponding metadata loaded, but it could also happen wi= th a discovery service that knows more than you do.
Sometimes a user submits HTTP POST data to a page that requires a valid = Shibboleth session. An example could be a user that completes a web form. I= f the user does not have yet a valid Shibboleth session or if his session e= xpired, he is redirected to his Identity Provider and forced to re-authenti= cate. Coming back to the protected page his HTTP POST data is lost due to t= he redirects. The following steps explain how the SP (2.2 or above required= ) can be configured to preserve HTTP POST data:
Using the above-mentioned settings, the SP will preserve and re-post the=
HTTP POST data after the user got a valid Shibboleth session. Note that th=
is can have unintended consequences if the user clicks on the back button o=
f his web browser. In this case the HTTP POST data might be resent again. T=
herefore, the application that processes the POST data should take this int=
o account when accepting the data.
For further information, have a look at the configuration options postData=
, postTemplate and postExpire on NativeSPSessions<=
/a>.
When a SAML message is addressed to a location inconsistent with where t= he SP believes it's running, this error will be thrown. The SP pulls much o= f this information from the web environment.
Shibboleth.sso
handler p=
ath must be consistent with the SP's metadata.The usual cause for this is an incoming SAML assertion/response from an =
issuer for which the SP has no metadata loaded. This means either the metad=
ata is wrong, or the IdP in question is using the wrong entityID in its configuration, so the URI passed to the SP doesn't match what it =
expects.
More specific information is usually available from the shibd.log<=
/code> file.
Non-specific. You need to check the log for specific information about w= hy the incoming assertion was invalid.
The IdP's metadata provides the rules for determining whether a certific= ate used for a signature or found at a SOAP endpoint is acceptable. This er= ror means it wasn't acceptable. Either the metadata is wrong, or the certif= icate is, but they don't "match".
The SP received encrypted XML (usually an EncryptedAssertion) and couldn= 't decrypt it. The SP's metadata probably doesn't contain the same public k= ey(s) the SP is configured to use (or the credentials didn't load).
Appears in shibd.log
during back-channel communications. Se=
ems to be very unpredictable, but is caused by some kind of OpenSSL bug whe=
n zlib is used to compress the SSL traffic. Particularly common on the seco=
nd (and subsequent) attempts to use a cached SSL session. There doesn't see=
m to be a real solution to this, but a couple of bad work-arounds include:<=
/p>
<TransportOption>
=
a> element to the configuration with a value of 0 for option number 150.
At this time, it is not known if running with Tomcat's SSL implementatio= n is subject to the bug, but running without Apache may be a solution for s= ome sites.
Appears in shibd.log
during back-channel communications. Th=
is indicates that one of the peers rejected the certificate of the other.=
p>
If the log includes errors mentioning a "TrustEngine" failing to verify = the SSL certificate, the error indicates that the SP rejected the IdP's ser= ver certificate and the metadata is wrong or invalid in some respect.
Otherwise, this usually indicates that the IdP rejected the certificate = the SP presented, but did so using a layer of code inside the Apache mod_ss= l module. This happens when Apache is misconfigured by allowing mod_ssl to = validate the certificate. You need to make sure the SSLVerifyClient option = is set to "optional no_ca" on the IdP.
If you think it is set, you're either mistaken or the certificate violat= ed a built-in requirement that mod_ssl refuses to disable. Sometimes this c= an be corrected by upgrading to a newer Apache version, but it may not be s= omething you can fix.
You may also consider running the IdP without Apache, which is now suppo= rted and documented. Note that you can do this for back-channel communicati= on on port 8443 while still running Apache in front of the container for fr= ont-channel support on port 443, if your authentication solution requires t= hat Apache be used.
Appears in the browser when the server module can't communicate with shibd
, bu=
t doesn't really provide much feedback about it.
Feedback about the SELinux issue here can be gleaned by running SELinux =
in permissive
mode - the default is enforcing
.
What you will find, from running audit2allow
for an initial=
httpd+shibd
setup, is that you simply need a policy that perm=
its the Apache server (httpd
) to access /var/run/shibbol=
eth/shibd.sock
Such a module can be created, once you have logged the problem by runnin=
g SELinux inpermissive
mode, by running the command:
grep httpd_t /var/log/audit/audit.log | audit2allow -M <name_of_mod= ule>
after which you will have generated a <name_of_module>.te and
<name_of_module>.pp
file, the latter being the =
compiled module,
along with instructions on how to load the module into the SELinux regime.=
Simply giving the httpd server access to /var/run/shibboleth/shibd=
.sock
should merely require a .te
file that looks like =
this:
module name_of_module 1.0; require { type var_run_t; type httpd_t; type initrc_t; class sock_file write; class unix_stream_socket connectto; } #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D httpd_t =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D allow httpd_t initrc_t:unix_stream_socket connectto; allow httpd_t var_run_t:sock_file write;
Your .te
file may obviously contain extra defintions and ru=
les depending upon what your local httpd
is trying to access, =
however, if the above info is in there, then that should cure the Can=
't connect to listener process
issue, even when restarting SELinux i=
n enforcing mode once again.
Compile and install the policy file with:
checkmodule -m -M -o mod_shib-to-shibd.mod mod_shib-to-shibd.te=20 semodule_package -o mod_shib-to-shibd.pp -m mod_shib-to-shibd.mod semodule -i mod_shib-to-shibd.pp