Page Comparison

...

Even then, many basic needs can be met with a set of built-in Spring beans and properties (described below) that provide basic client functionality, at the cost of "global" behavior (meaning all components would be relying on common clients with common settings).

You might need to dive into this topic further if you want to finely tune settings for different situations or if you have advanced security requirements that go beyond default behavior. A common example would be if you want to control TLS server authentication at a finely-grained level to avoid dependence on the default trust behavior of Java's TLS implementation. This is particularly true if you ever find yourself modifying the "global" Java trust store. That should never be done, since it makes Java upgrades much more troublesome.

In comparison to some of the IdP's features, the veneer here is very "thin". That is, we don't have a lot of layers of abstraction and simplification in place to hide the gory details (this may come as news, but much of the rest of the configuration is very abstracted and simplified from what it could look like). So two points: this topic is will eventually be heavy on examples, and going beyond the examples is more a case of reading javadocs and just finding the right settings than reading some documentation to magically impart the right answer.

...

Many common settings are exposed as properties (mostly commented out for easy definition in services.properties).These properties are a mix of global settings that configure each client type and specific settings controlling the caching behavior of the individual types. This is a suitable approach if you have one use case, or are fine with all use cases sharing client behavior.

Custom Clients

If you have more advanced needs, just define your own bean that inherits from one of these, and override any settings as needed. For example, instead of relying on the global idp.httpclient.socketTimeout property, perhaps you want to define a special client instance with a shorter timeout:

...

Now you have a bean name you can inject into other components that support an httpClientRef property that will behave differently than the defaults.

Security Configuration

TLS Server Trust

A common use for advanced configuration is to control the server certificate evaluation process. While the IdP typically relies on SAML metadata for this when communicating with servers, this doesn't work for a lot of non-SAML use cases. However, much of the same machinery can be repurposed to support a variety of trust models, and we have integrated this into the HttpClient library.

By default, the HttpClient will rely on Java's built-in TLS behavior and code built into the HttpClient library, and perform basic hostname/certificate checks and will rely on the Java global trust store to determine whether to trust the certificate (or its issuer). This is where most non-Shibboleth software stops, and where we start. In testing scenarios, you can turn off this checking via the connectionDisregardTLSCertificate property, but this should never be used in production.

TLS Client Authentication

TBD

HTTP Authentication

TBD

Reference

Beans

...