...
As a result, the Shibboleth Project was forced to develop strategies for this purpose to implement in the software. These features give you as a deployer the necessary tools to manage your systems safely, but you are responsible for understanding them and using them properly. Failure to do so will result in serious exposures and open you to various kinds of external threats.
| Table of Contents |
|---|
First Principles
In a lot of security software, including many SAML implementations, "trust" is implemented exclusively via a reliance on an X.509-based PKI, and the rest of the configuration is designed around this assumption. Much of the work involves telling the software about "trusted certificate issuers" or "certificate subject names". Some support for self-signed certificates is often present, but it can be difficult to set up or limited in scope.
...
The usual approach is to express the set of trust anchors to validate end-entity certificates against dynamically, using a <shibmd:KeyAuthority> extension in the Metadata. The extension is placed at or above the level of a given entity, such that you can express a set of trust anchors to apply to one or more entities, or different anchors for different entities, rather than a one-set-fits-all model as one sees in most software.
The benefit is that the metadata is still self-contained in terms of expressing the information, but you also have to make sure that you have CRLs (if any) embedded in the <shibmd:KeyAuthority> extensions you use, because that's the only supported mechanism for preventing use of a revoked certificate when using this plug-in.
...