The Shibboleth IdP V4 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP5 wiki space for current documentation on the supported version.
ProfileConfiguration-Authentication
Options common to profiles that perform authentication:
Name | Type | Default | Description |
---|---|---|---|
postAuthenticationFlows | List<String> | Ordered list of profile interceptor flows to run after successful authentication | |
defaultAuthenticationMethods | List<Principal> | Ordered list of Java Principals to be used to select appropriate login flow(s) to attempt, in the event that a relying party does not signal a preference. See AuthenticationFlowSelection. | |
forceAuthn | Boolean | false | Disallows use (or reuse) of authentication results and login flows that don't provide a real-time proof of user presence in the login process |
proxyCount | Non-Negative Integer | Limits use of proxying either to service providers downstream or when requesting authentication from identity providers upstream. This will generally depend on whether a particular protocol supports the feature. |
Guidance
The postAuthenticationFlows
property is used to apply special processing to requests, such as attribute release consent, password expiration warnings, authorization checks, or other custom processing.
Examples of postAuthenticationFlows property
With the increased use of multi-factor authentication, it is more common to find RPs that can specify authentication requirements, but there are still many cases, particular with commercial services, in which it becomes necessary to force the use of specific login methods. This can be achieved using the defaultAuthenticationMethods
property by specifying one or more corresponding Principals to trigger the use of stronger methods.
Note that you must also prevent a malicious actor from overriding this preference for a SAML 2.0 SP by manufacturing a request, via one of two means:
For a SAML 2.0 SP that can sign its requests, its metadata can be modified with the
AuthnRequestsSigned
flag to indicate that its requests must be signed.Alternatively, the
disallowedFeatures
property may be set with the SAML2.SSO.FEATURE_AUTHNCONTEXT bean to block use of the SAML 2.0<RequestedAuthnContext>
feature.
At present, no other authentication profiles support a feature capable of requesting the authentication method.