The Shibboleth IdP V3 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP4 wiki space for current documentation on the supported version.
X509InternalAuthnConfiguration
- Scott Cantor
- Takeshi Nishimura
Current File(s): conf/authn/x509-authn-internal-config.xml
Format: Native Spring
Overview
The "authn/X509Internal" login flow leverages any surrounding mechanism you have available for TLS client certificate authentication, provided the standard servlet request attribute ("javax.servlet.request.X509Certificate") is populated. By default, this flow is configured without support for advanced authentication controls like passive or forced authentication since this is not generally possible with client certificate authentication.
The difference between this flow and the X509 flow is that this flow doesn't redirect to a protected path; rather, the path of the requested profile flow has to be protected, which typically will trigger as soon as the client makes its first request. This is primarily suited to non-browser clients or other scenarios in which authentication is uniformly certificate-based.
The main disadvantage of using this flow for browser use cases is that it will perform the request for authentication without having a chance to determine if the request will succeed, which may be undesirable from a usability perspective.
The result of this flow is a Java Subject containing an X500Principal derived from the subject of the certificate, and the certificate is added as a public credential of the Subject. Note that no actual "username" is produced; rather, a suitable Subject Canonicalication flow must be enabled/configured to pull a suitable principal name out of the Subject.
Note that if you have a web server that is configured to perform the certificate evaluation for you and populate a header or variable with the "username" to use based on the certificate, you almost certainly will want to use the RemoteUser or RemoteUserInternal flow. This flow pulls in the certificate as the primary result of the authentication and relies on downstream logic (often the x500 subject canonicalization flow) to get a username out of it.
General Configuration
There is no configuration required, but you may use conf/authn/x509-internal-authn-config.xml to define a Spring bean named shibboleth.authn.X509.TrustEngine as an OpenSAML TrustEngine that should be used to validate the client certificate chain. Of course, it's often simpler and more common to do this validation at the web server itself, although that's less flexible.
Reference
Beans
The beans defined in authn/x509-internal-authn-config.xml follow:
Bean ID | Type | Default | Function |
|---|---|---|---|
shibboleth.authn.X509.TrustEngine | TrustEngine<X509Credential> | An optional bean for validating the client certificate | |
| shibboleth.authn.X509.resultCachingPredicate | Predicate<ProfileRequestContext> | An optional bean that can be defined to control whether to preserve the authentication result in an IdP session | |
| shibboleth.authn.X509.addDefaultPrincipals 3.2 | Boolean | true | Whether to add the content of the supportedPrincipals property of the underlying flow descriptor to the resulting Subject |
V2 Compatibility
There is no equivalent V2 feature, but this implementation is based on a V2-compatible contribution from SWITCH.
Direct support for extracting subjectAltName extensions as custom Principals is not provided by this implementation, but the same functionality can be configured using the x500 subject canonicalization flow.
Notes
TBD