The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

NativeSPTrustEngine

Owned by Scott Cantor
Last updated: Apr 11, 2012

The <TrustEngine> element configures the trust engine used by the SP to authenticate the security messages it receives. It works in conjunction with the security policy layer to secure the system.

If omitted on V2.4 and above, a chain of the ExplicitKey and PKIX engines is used.

Common Attributes

  • type (string)
    • Plugin type name.

Common Child Elements

  • <KeyInfoResolver> (optional)
    • Advanced plugin interface for mapping <ds:KeyInfo> elements into keying material. Mostly for future use.

Chaining Trust Engine

Identified by type="Chaining", applies one or more trust engines in sequence to authenticate a message. Allows multiple approaches to be combined.

With V2.4 and above, this is implied by any configuration with multiple <TrustEngine> elements, so is no longer explicitly needed.

Child Elements

  • <TrustEngine> (one or more)
    • The embedded trust engine plugins to chain together.

ExplicitKey Trust Engine

Identified by type="ExplicitKey", extracts keys to trust directly from the metadata of the peer.

For detailed information about how this engine works, see the ExplicitKeyTrustEngine topic.

PXIX Trust Engine

Identified by type="PKIX", extracts key identifiers (i.e. certificate names) to trust from the metadata of the peer, but also extracts sets of trust anchors from a special metadata extension and then applies path validation to candidate certificates.

For detailed information about how this engine works, see the PKIXTrustEngine topic.

StaticPKIX Trust Engine

Identified by type="StaticPKIX", extracts key identifiers (i.e. certificate names) to trust from the metadata of the peer, and then applies path validation to candidate certificates based on a static list of trust anchors.

The difference from the previous engine is that the list of anchors is fixed and does not vary based on whose credentials are being examined.

Attributes

  • verifyDepth (integer) (defaults to 1)
    • Length of CA chain to permit.
  • certificate (local pathname)
    • Optional path to a file with one or more CA certificate to trust.
  • checkRevocation ("off", "entityOnly", "fullChain") (defaults to "off") (Version 2.4 and Above)
    • Controls the behavior of CRL checking by the trust engine. If omitted or set to "off", no CRLs are used at all. The other options require that at least one CRL be available and will fail the check otherwise. The "fullChain" option requires that a CRL be available for all untrusted certificates in the validation path, otherwise only a CRL for the end entity certificate is required.

Child Elements

  • <CredentialResolver> (optional)
    • A credential resolver plugin to use to load the CA certificate(s) to trust.