Current File(s): conf/authn/remoteuser-internal-authn-config.xml, conf/authn/authn.properties (V4.1+)
Format: Native Spring, Properties (V4.1+)
Overview
The authn/RemoteUserInternal login flow relies on whatever container-based mechanism you have available (HTTP BASIC auth, LDAP, Kerberos, other SSO systems, etc.). It is particularly friendly to non-browser profiles such as ECP. By default, this flow is configured without support for advanced authentication controls like passive or forced authentication.
The difference between this flow and the RemoteUser 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 will trigger as soon as the client makes its first request. This is primarily suited to the use of basic-authentication and non-browser clients, though of course this will depend on the exact mechanism involved. Using a second SSO mechanism is likely to be incompatible with non-browser clients.
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.
Enabling Module (V4.1+)
For V4.1+, configuring and using this feature requires that you first enable the "RemoteUserInternal" module if it isn't already enabled. Systems upgraded from older releases generally come pre-enabled due to the prior state of the configuration tree.
(Windows) C:\opt\shibboleth-idp> bin\module.bat -t RemoteUserInternal || bin\module.bat -e RemoteUserInternal (Other) $ bin/module.sh -t RemoteUserInternal || bin/module.sh -e RemoteUserInternal