Architecture of SPNEGO/Kerberos login flow

[Daniel Lutz]

We are developing a login flow for SPNEGO/Kerberos for IdP V3
(https://issues.shibboleth.net/jira/browse/IDP-111).
Our goal is to provide this flow as a built-in feature of
the IdP V3.

SPNEGO/Kerberos allows a user to smoothly and transparently
log in at the IdP without needing to enter username/password,
provided that Kerberos is available on the client (e.g. on a
Windows client that is part of a Windows domain).

One possible deployment is to try the SPNEGO/Kerboros login
as the first authentication method. If it succeeds, the user is
logged in without noticing it. If it fails, the next flow should
be tried, usually the Password login flow, so that the user can
log in by username/password.

But there's at least one problem with this approach: If
Internet Explorer is used, and Kerberos is not supported
by the client, Internet Explorer would fall back to NTLM
and show a login box to the user. IE won't return a result
to the IdP, so the SPNEGO/Kerberos login flow would fully
break. The user might be lost. Therefore, this situation
must be avoided.

Unfortunately, SPNEGO doesn't allow the server (IdP)
to reliably recognize whether Kerberos is supported
on the client or not.

The only way to reliably avoid this problem seems to
be to force the user to opt-in for SPNEGO/Kerberos login.
The user should only opt-in if SPNEGO/Kerberos is
expected to work.

In our current approach, we implemented a combined
login flow for username/password and SPNEGO/Kerberos.
This flow shows a login page, where the user can either
log in by username/password or by SPNEGO/Kerberos.
(The user can enable auto-login, so that SPNEGO/Kerberos
is automatically tried the next time the user logs in.)

The flow is actually a merge of the Password login flow and
a standalone SPNEGO/Kerberos login flow, where the
flow states and actions are re-arranged and modified
as required. This approach works quite well.

But this approach has some drawbacks:
- The functionality of the Password flow is duplicated.
- The flow depends on parts of the Password flow that
  are not publicly exposed via the API.

These two points are not a real problem as long as
the flow will be an integral part of the IdP V3.
But a cleaner approach may be desired.


Which alternatives exist to implement this, while preserving
a good user experience and avoiding technical problems such as
described above?

Do you see a possibility to implement a flow that calls
the SPNEGO/Kerberos flow as a subflow instead of merging
two flows?
(I assume that this would still require to create a new flow
and integrating the existing flows.)


For more information, you may refer to the following resources:

- Description of use cases in JIRA entry IDP-111
  https://issues.shibboleth.net/jira/browse/IDP-111
  Last comment by Daniel Lutz, 26/Aug/15 5:13 AM

- Development Documentation for the SPNEGO/Kerberos Authentication Flow
  https://forge.switch.ch/redmine/projects/idp_v3_kerberos_authentication_flow/repository/raw/doc/Development_Documentation.pdf

- Snapshot of the current source code
  Subversion Repository:
  https://subversion.switch.ch/svn/general/aai/java-idp3-kerberos-authentication-flow/trunk

- Test deployment to try the login flow (combined login page):
  https://idpv3.dlu.switch.ch/idp/profile/SAML2/Unsolicited/SSO?providerId=https%3A%2F%2Fattribute-viewer.aai.switch.ch%2Fshibboleth&target=https%3A%2F%2Fattribute-viewer.aai.switch.ch%2Faai

Daniel