Configuring Multiple Login Handlers

Main Page

Some Identity Providers may support multiple login methods (Username/Password and Certificates). The following briefly details how one can support multiple and default to a specific login method.

Shibboleth User Authentication describes how to configure user authentication, and this must be done for each login handler.

Once both login handlers are configured properly and working (typically you will want to only have a single login handler active while testing and debugging it), you then have need to specify a default handler within the relying party file. Shibboleth's Relying Party Configuration Page provides a comprehensive discussion of how to do this. For most GFIPM style IDP deployments this would take the form of simply adding one additional attribute to the DefaultRelyingParty element within the relying-party.xml configuration file:

      <DefaultRelyingParty provider="GFIPM:IDP:EntityId"
                        defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"
                        defaultSigningCredentialRef="IdPCredential">

To request a specific Authentication Context Class with the Shibboleth Service Provider, you can do so in multiple ways:

• Specify via login handler as a parameter authnContextClassRef with a value of the URI of the desired Authentication Context Class. You can use this method with the GFIPM Reference Service Provider.
• You can control it via the SessionInitiator, by including the attribute authnContextClassRef in the SAML2 Session Initiator. The details are in the Shibboleth Documentation.
• Finally you can control it via the Shibboleth SP's Native Content Settings, which is particularly useful if you have one portion of the Service Provider that has more stringent Authentication Context Class requirements.

Main Page