...
Java servlet applications run in so-called Java containers, such as Jetty, Tomcat, JBoss, or Glassfish. Most servlet containers are themselves web servers, and have sufficient features, flexibility, and performance to support most deployments, at scale, without the use of a separate web server like Apache. The IdP also sometimes occasionally (less often these days) requires certain web server features that are easier to support when Jetty or Tomcat are used alone than other containers or non-Java web servers, which will be discussed further below.
In cases where use of a native web server is required, this is typically done by "connecting" the native web server to the container using either the AJP protocol (recommended where possible) or by HTTP reverse-proxying. In this case, the container generally is must be configured to receive connections only from the native web server and failure to limit this often leads will lead to significant security problemsrisk.
Ports and Connectors
As a standard web application, the IdP primarily operates on a "client-facing" port, generally 443 (the standard HTTP over TLS port). Typically it isn't necessary to worry about allowing access to port 80 to redirect traffic back to 443 , but you certainly canand doing so will generally not work with most SAML profiles anyway. You should essentially never operate the IdP without TLS, so port 80 should only be used to perform that redirect.
The key and certificate you use on port 443 should not be related to any of the keys or certificates you use in configuring the IdP software, and should be managed as you would for any secure web server. Use of an Extended Validation (EV) certificate may be beneficial here because of the role the IdP plays.
...
| Note | ||
|---|---|---|
| ||
If you choose to run a Java-based web server by itself (without Apache or the like), the first thing you'll need to do is to prepare an environment for it to run under a non-root account but allow use of ports port 443 and possibly 80 (optional) and 443 using a technique such as a |
...
Historically, Shibboleth IdP deployments have operated with a second HTTP connector for SOAP requests from Service Providers. This connector by convention usually listens on port 8443. The separate port is used primarily because the connector has generally relied on client certificate authentication at the TLS layer to authenticate requests from SPs. It's possible to host these SOAP services on the same port as the rest of the IdP's services, but this used to require changes to SP configuration, so is beyond the scope of this introductory topic.
Back-Channel Use Cases
Not all deployments, especially newer ones, Most newer deployments do not need to support the back channel. While there are a range of features that rely on the back channel, and probably more in the future, basic use of the IdP for SAML-based SSO does not require it. That said, the following features require a back channel, along with a brief explanation of why you might need them.
...
The Artifact feature in SAML is a pass-by-reference approach to the exchange of a SAML SSO assertion that relies on a redirect to the SP with a small artifact string that is "resolved" by sending a SOAP request to the IdP. Ordinarily, the default SAML flow used in Shibboleth is a POST to the SP in which the assertion is pushed in the body of a form. The primary advantage of the artifact approach is that it handles cases where an unprotected page includes embedded references to images or other content that are protected. It also has security properties that are considered to be an advantage by some people.
Artifact usage is not common today, and it introduces complications when clustering an IdP and when testing upgrades or configuration changes. If not supported, it's very important for correct operation of SPs that your metadata not include the endpoints that indicate support for this feature.
Back-Channel Logout
SAML logout , which the IdP supports only in very limited fashion, can be initiated either with the browser or as a SOAP notification from an SP to the IdP. The latter is by far the most reliable way to process a logout, but is also very limited in effectiveness because many SAML implementations and applications require access to previously-set cookies to perform a logout.
The IdP to date supports only a limited form of logout that does not propagate notifications to other SPs, so this is largely academic right now, but support Support for SOAP logout does require that the session store be on the server side, which is not the V3 default, and greatly complicates clustering. As a result, this isn't a feature likely to matter very much in most cases.
...