Repository navigation
skip kerberos SSO authentication to use login-form #8989
Description
Description
In certain cases we need to skip automatic login through Kerberos.
According to the keycloak documentation this should be done through the parameter ?prompt=login:
prompt - Keycloak supports these settings:
login - SSO will be ignored and the Keycloak login page will be always shown, even if the user is already authenticated
With Kerberos configured and activated in the auth-flow the user is always signed in automatically.
Discussion
Stackoverflow - Skip kerberos sso authentication in keycloak
Motivation
The reason to skip Kerberos authentication is to login with an admin-account where username+password is used.
Details
Here is a possible solution within org.keycloak.authentication.authenticators.browser.SpnegoAuthenticator:
@Override
public void authenticate(AuthenticationFlowContext context) {
// +++ BEGIN CHANGE +++
AuthenticationSessionModel session = context.getAuthenticationSession();
Map<String, String> clientNotes = session.getClientNotes();
if ("login".equals(clientNotes.get("prompt"))) {
logger.info("skip SPNEGO authenticator because of client requests login prompt: " + clientNotes); //$NON-NLS-1$
context.attempted();
return;
}
// +++ END CHANGE +++
HttpRequest request = context.getHttpRequest();
String authHeader = request.getHttpHeaders().getRequestHeaders().getFirst(HttpHeaders.AUTHORIZATION);
if (authHeader == null) {
Response challenge = challengeNegotiation(context, null);
context.forceChallenge(challenge);
return;
}
.....
Reacted by DAHAG-ArisNourbakhsh, Marek Kamiński, sma_mdu, Antoine Jacques, wyfrel and Dmitry Mazurov
Activity
amhest commentedon Dec 10, 2021
Thank you so much for finding this! I was able to implement this same solution for a broader issue affecting a fair number of developers. The custom authenticator I created works perfectly for me; I had to add a manifest dependency to an internal jar which is not ideal. It would be nice for this option to be rolled into the standard SpnegoAuthenticator in future release.
If using same realm and client for both domain and non-domain users and kerberos is enabled the non-domain users see a basic authentication pop-up rather than just landing on the keycloak login page. The issue prevents use of SPNEGO in mixed domain and non-domain environments.
References:
https://keycloak.discourse.group/t/basic-auth-prompt-with-kerberos-enabled/8591
https://lists.jboss.org/archives/list/keycloak-user@lists.jboss.org/message/GBXG2I4RLYBPABVQFB7WZSXX6VUYLWEB/
https://lists.jboss.org/pipermail/keycloak-user/2018-April/013634.html
https://bugzilla.redhat.com/show_bug.cgi?id=1309041
amhest commentedon Mar 11, 2022
As I understand the issue in chromium there is no solution possible in keycloak (or any other single web app) alone. The best solution I know of is to detect the mechanism of entry, refer, subnet etc. in load balancer, firewall etc. and add the parameter supported by this PR to the url.
amhest commentedon Jun 15, 2022
I just confirmed this issue still exists in 18. Can we consider this for a future release? As it expects a url hint the side effects are likely minimal. In the meantime, I have to implement a special browser flow with a custom subclass.
it-aperam commentedon Jun 28, 2022
Also interrested in resolving that.
slominskir commentedon Sep 28, 2022
A work-around if you don't want to modify Keycloak source code is to leverage the
kc_idp_hintparameter, since Keycloak already honors that. The idea is to setup an Identity provider that contains an otherwise duplicate browser flow, but has Kerberos SPNEGO disabled. Clients would need to manually request it via the kc_idp_hint parameter. You can hide this IDP from the login screen so it's only a client requested option (client app would need a "switch user" link with this kc_idp_hint). It's a lot of extra configuration to do it this way (extra realm since kc_idp_hint will be simply pointing back to same keycloak instance but different realm plus that new realm needs a user storage provider). You also must re-order the primary realm browser flow such that IDP comes before Kerberos otherwise the kc_idp_hint is ignored. You also must then use the autolink first broker flow to avoid prompting users to accept the link. I've been doing it this way since 2018. It's worth mentioning that it isn't clear prompt=login is SUPPOSED to skip Kerberos login. I think it probably should, but the response I got when I asked this question was that Kerberos is behaving as designed. It's fair to say it's murky how it's supposed to work.slominskir commentedon Sep 29, 2022
Here is a pre-built plugin: https://github.com/slominskir/KeycloakConditionalSpnegoAuthenticator
Drop it in the
providersdirectory of Keycloak, then run./kc.sh buildand then start Keycloak. The "Conditional SPNEGO" browser authenticator will be available and respond toprompt=login.slominskir commentedon Oct 3, 2022
Worth mentioning that prompt=login is currently NOT forwarded to an IDP.
Our site has two separate logical domains of user accounts (two separate passwords). Half of users have accounts in both domains. Many users have access to multiple accounts on a single domain. I have a primary realm mapping to the primary domain, then an IDP for another realm mapping to the secondary domain. Historically I've also setup a mirror realm for each (four total realms) with the mirror realms having SPNEGO disabled such that SU (Switch User) manually requested via
kc_idp_hintwas possible. Looks like the prompt=login could reduce this to three realms, but I'd still need a mirror realm for disabled SPNEGO on the secondary realm since prompt=login is not forwarded when an IDP is requested via kc_idp_hint.Related: #12469
nhart12 commentedon Jun 10, 2024
I see #17064 is still in draft. Is there a better workaround in 2024 for this?
slominskir commentedon Jun 10, 2024
Not that I'm aware of. The standalone plugin of which the PR is built is here: https://github.com/slominskir/KeycloakConditionalSpnegoAuthenticator/releases
You'll probably have to compile a new version if you're using latest Keycloak, as I haven't tried to upgrade recently.
This Microsoft HTTP Authenticate protocol (SPNEGO/Kerberos) is only a nice-to-have, not a must-have feature and is only useful in a tightly controlled Intranet, which limits it's applicability. Unless you have a ton of extra time on your hands I'd run away.
oculos commentedon Sep 12, 2024
This plugin was an eye-opener. Thanks a lot.
I have used it as an inspiration for our own plugin, more directed towards ip ranges and cookie control. Cookie control is used here to allow logout without an immediate kerberos login.
https://github.com/unioslo/kc-conditional-kerberos
We appreciate any comments.
larsw commentedon Sep 12, 2024
@oculos link doesn't work (404)
oculos commentedon Sep 12, 2024
My bad, forgot to make it public.
Wenkow commentedon Aug 10, 2025
I have made a new plugin to solve this problem. The plugin will test in the background whether the client can authenticate with Kerberos and decide whether Kerberos will be used or skipped.
https://github.com/Wenkow/Keycloak-Kerberos-Probe-plugin
slominskir commentedon Aug 13, 2025
Neat plugin. Years ago I had a custom background Kerberos login via AJAX setup as well at our site. It was app side, via a shared lib that each app included (when clicking login link a series of background login attempts were made, before redirect to form if none worked). It was a ton of work/complexity to maintain. And for us with remote work lots of the workforce moved offsite for a substantial amount of the week so it was no longer worth the hassle for an onsite only nice-to-have. Part of the complexity is, for us at least, we needed to also provide a switch user link beside the login link because there were a few cases where users needed to choose between accounts and auto-logging in with OS user wasn't always the right choice. This means a bunch of extra config in Keycloak, a separate IdP that doesn't prompt for SPNEGO, duplicated for each Kerberos realm. Plus we have multiple Kerberos realms onsite, and different IT teams maintain subsets of hosts and getting them all to agree to configure the browsers to support Kerberos (and keep it configured over the years/upgrades) was painful. Also, at least one department decided to wrap user browser launch with a script that ran it in a nobody user sandbox, for security (breaking Kerberos).
Added conditional authenticator for prompt param
stianst commentedon May 7, 2026
Closing this as skipping authenticators based on the prompt parameter is not the correct thing to do; there is step-up authentication that can be used if an application wants a user to authenticate with some specific means.