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.
Configuring the IdP for Remote User Authentication
In order to support the use of container-based authentication the Shibboleth IdP ships with an endpoint that may be secured by whatever container-based mechanism you have available (HTTP BASIC auth, LDAP, Kerberos, other SSO systems, etc.).
This login handler does not support the SAML 2 forced re-authentication or passive authentication feature.
How It Works
This login handler is, under the covers, a Java Servlet. That is, it's a bit of Java code addressed by a URL. This code looks for a value in the REMOTE_USER header and uses this as the username for the user sitting at the browser. The assumption is that if the container (web server or servlet container) can set REMOTE_USER, then it should be trusted.
Therefore, to use this handler you must protect the URL of the remote user servlet (see below for this path) with some authentication mechanism within your container. If you do not know how to do this, you must refer to your container's documentation.
Define the Login Handler
This login handler is defined with the element <LoginHandler xsi:type="RemoteUser"> with the following optional attributes:
authenticationDuration - length of time in minutes that the authentication method associated with this login handler is active; default: 30 minutes
protectedServletPath - context-relative path to the Servlet protected by REMOTE authentication; default is /Authn/RemoteUser
Additionally the login handler must contain one or more <AuthenticationMethod> elements whose content is the authentication method(s) serviced by the login handler.
Finally, you may also need to configure the Servlet with an "init" parameter in web.xml named authnMethod, set to a an authentication context/method/type value to return via SAML to the SP. By default, the value returned will be urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport. This is usually fine, but if you're doing something more advanced, it may need to be changed.
Note that if you were to assign the login handler to multiple <AuthenticationMethod> values up front, you will potentially have a problem because the Servlet itself can only return one of them. This may work fine, but would break if you are supporting SAML 2.0 SPs that request particular methods. You will probably need a custom login handler or handlers in such cases.
Because container-based authentication is specific to the container being used we can not provide an exhaustive list of all possible containers or options per container. Instead we have tried to provide examples for commonly used environments.