[keycloak-user] prompt=login does not override Kerberos

[Ryan Slominski]

Hi Marek,
   Reordering the Identity Provider Redirector execution such that it comes before the Kerberos SPNEGO execution actually does work on second look.  I was running into caching and cross-site scripting issues.   So the workaround for prompt=login being ignored by SPNEGO authenticator is to just reorder authenticator priority.

Ryan

----- Original Message -----
From: "Marek Posolda" <mposolda at redhat.com>
To: "Ryan Slominski" <ryans at jlab.org>, "keycloak-user" <keycloak-user at lists.jboss.org>
Sent: Wednesday, August 22, 2018 2:52:28 AM
Subject: Re: [keycloak-user] prompt=login does not override Kerberos

On 21/08/18 20:43, Ryan Slominski wrote:
> My understanding is sending the parameter prompt=login to the Keycloak authentication URL should force the login form and re-authentication.  However, if Kerberos SPNEGO is available it ignores this parameter and logs the user in without showing a login form.  Is this a bug?  I guess currently the prompt=login is only honored by the cookie execution in the browser flow?
Per OIDC specification, when using prompt=login, the server should 
re-authenticate user. IMO Re-authentication doesn't strictly mean that 
login form must be shown and all the authenticators, which don't have 
any HTML form to display, must be ignored. So we just ignore the cookie 
authenticator at this moment.

In the future, we plan to use "Authentication levels" and I think this 
will allow to address your usecase better. For example you will create 2 
authentication flows and based on the value of the "amr" parameter sent 
from the adapter, the Keycloak will show the correct authentication 
flow. So for example you can have one flow with Kerberos Authenticator 
and one flow with IdentityProviderRedirector etc.

For now, maybe you will need to customize the source-code of 
SpnegoAuthenticator (create your own provider subclass) to deal with the 
prompt=login according your needs.
>
> Another possible bug: if you create a copy of the browser flow and swap the order of the Kerberos execution with the Identity Provider Redirector execution then Kerberos SPNEGO authentication won't work (fails with checksum error).
Sounds strange. Maybe this is a bug. Does it happen even if there are 
not any "kc_idp_hint" parameter sent, so the IdentityProvider Redirector 
doesn't do any redirection HTTP requests? If yes, looks like a bug to 
me. Feel free to create JIRA.

Marek
>
> Combine both issues and it means you can not selectively force some users to use a particular identity broker while sending others to another.  With the normal browser flow if a user has Kerberos SPNEGO credentials then they will ignore the kc_idp_hint parameter as the Kerberos execution comes before the IDP redirect.  If you configure an alternative browser flow where the IDP redirect execution comes before the Kerberos execution then users without the kc_idp_hint who legitimately should login automatically via Kerberos SPNEGO will fail to do so because it appears having IDP redirect execution first breaks the SPNEGO process.  Anyone else run into this?
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_keycloak-2Duser&d=DwICaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=EMs2e6afv3D1GQJO76Z9Fg&m=1qwOFtDDUjNIFHd4cHajk-bR6U9v4ONNEXiOE5S8EMY&s=CBxKq3tKSGOSb2-JH2ju4NmKCx_s8QoYHT_vreeFvBU&e=