[keycloak-user] Option to disable SPNEGO

[Marek Posolda]

Thanks for the JIRA.

Marek

On 27/03/2019 21:35, Ryan Slominski wrote:
> Ticket created:
>
> https://issues.jboss.org/browse/KEYCLOAK-9927
> ------------------------------------------------------------------------
> *From:* Ryan Slominski
> *Sent:* Wednesday, March 27, 2019 3:55 PM
> *To:* Marek Posolda; keycloak-user
> *Subject:* Re: [keycloak-user] Option to disable SPNEGO
> The OIDC protocol "prompt=select_account" looks very interesting.  I 
> think this would be sufficient for handling "switch user".
>
> It actually look like "select account" is more sophisticated than 
> "switch user" as it supports multiple users simultaneously and you 
> choose a primary account. With switch user it is simply the ability to 
> choose which user is logged in, but not necessarily more than one at a 
> time.  The fact "select account" is an OIDC standard makes it very 
> appealing.
>
> It seems one of the Keycloak competitors has this:
>
> https://connect2id.com/products/server/docs/guides/select-account
>
> Is there an issue ticket for this already?
> ------------------------------------------------------------------------
> *From:* Marek Posolda <mposolda at redhat.com>
> *Sent:* Wednesday, March 27, 2019 3:36 PM
> *To:* Ryan Slominski; keycloak-user
> *Subject:* Re: [keycloak-user] Option to disable SPNEGO
> On 26/03/2019 21:02, Ryan Slominski wrote:
> > With the "LDAP" User Storage Provider you can configure 
> authentication with a Kerberos password, but disable SPENGO.  The 
> admin web interface labels this "Allow Kerberos Authentication" (seems 
> like a bad label).  However, with the "Kerberos" User Storage Provider 
> there is no such option.  Is there a reason, or can this be added?
> It is not on the Kerberos provider as when you configured "Kerberos"
> provider, there is an assumption that you will want SPNEGO integration.
> >
> > Going a step further, the option to request SPENGO be disabled via 
> url parameter (regardless of LDAP vs Kerberos User Storage Provider) 
> was discussed years ago 
> (https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.jboss.org%2Fpipermail%2Fkeycloak-dev%2F2015-October%2F005399.html&amp;data=02%7C01%7Cryans%40jlab.org%7C9e96bb7576494bd6e90e08d6b2eb9612%7Cb4d7ee1f4fb34f0690372b5b522042ab%7C1%7C0%7C636893122238064707&amp;sdata=bR8w8t8%2FLT8Bfp6Oy%2BS9b5VMoKOLukVWsasAJ3CCoKI%3D&amp;reserved=0) 
> with no resolution.   Where are we with this?   Either the parameter 
> approach or some sort of support for "Switch User" would be 
> appreciated because it is very tricky to accommodate with the current 
> API.  Currently I'm using a brokered identity provider which is a 
> duplicate of the primary realm minus SPNEGO support. Then client 
> applications are coded with a "switch user" link that uses the 
> idp_hint parameter to indicate the special su brokered realm be 
> used.   Seems unnecessarily complex.    Maybe I'm missing something 
> easier?
>
> There is nothing easier ATM and nothing was done in the end.
>
> I was thinking about another option (maybe it was discussed in the
> thread, but not 100% sure...) to use "prompt=select_account" parameter
> supported by OIDC protocol. The original pupose of the
> "prompt=select_account" is maybe a bit different - it allows you to
> choose the account when you're somehow authenticated to multiple
> accounts. However I can see the usage for the use-cases like SPNEGO or
> X.509 authentication, that when the parameter is used, it will show the
> confirmation screen (aka "Is this you?" screen) where user will confirm
> that he wants to authenticate with his SPNEGO/X509 identity.
>
> Marek
>
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > 
> https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-user&amp;data=02%7C01%7Cryans%40jlab.org%7C9e96bb7576494bd6e90e08d6b2eb9612%7Cb4d7ee1f4fb34f0690372b5b522042ab%7C1%7C0%7C636893122238064707&amp;sdata=huRxdoPbDPtyBayZDCaE2jv3H8jPxSHqwL8utg5KoWo%3D&amp;reserved=0
>
>