[keycloak-dev] Kerberos progress

Marek Posolda mposolda at redhat.com
Thu Feb 12 03:55:43 EST 2015


On 11.2.2015 21:45, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, February 11, 2015 5:29:54 PM
>> Subject: [keycloak-dev] Kerberos progress
>>
>> I've already pushed initial version of Kerberos broker. It uses existing
>> brokering mechanism from Pedro and allows to login users to KC with
>> SPNEGO/Kerberos token. There are still things I need to address (more
>> testing + automated testing, Credentials delegation etc).
>>
>> I have a question about automatic Kerberos login without displaying
>> login form. Browsers support this very well - when server returns
>> response with status 401, header "WWW-Authenticate: Negotiate" and HTML
>> with login page, browsers are able to handle it and:
>>
>> * In case that user has Kerberos ticket, browser will send it back in
>> additional HTTP request with "Authorization: Negotiate <ticket>" . In
>> this case login form is not displayed to user
>>
>> * In case that user hasn't Kerberos ticket, browser just displays HTML
>> with login form
>>
>> You can try https://saml.redhat.com/idp/ to see what I mean.
>>
>> JBoss Negotiation supports this, so I believe we should address it too.
>>
>>
>> I have some ideas how to do it:
>>
>> 1) Configure default broker on server side per-realm. If used, login
>> request will automatically redirect to configured broker. It may be also
>> possible to override default broker per client?
>>
>> 2) Add on/off switch to broker configuration to specify if it should be
>> default or not
>>
>> 3) Leverage existing "k_idp_hint" parameter. I am thinking about adding
>> option "idp_hint" into AdapterConfig . In case it's configured, adapter
>> will use it for attach "k_idp_hint" parameter to login request. This
>> will allow per-application configuration and no changes on auth-server
>> side, but all applications will need to use it in their adapter
>> configuration.
> IMO, all above are valid. #1 and #2 may be useful even if not using Kerberos. And yes, IMO this should be per-client as well. I've added a new tab in Application and OAuth Client to enable/disable providers on a client. Maybe you can put this config there.
Ok, I can put the on/off switch for the brokering configuration (option 
#2). For Kerberos, it will be "on" by default, for other broker types 
"off" by default. This would be for specifying default brokering 
mechanism for the realm. Then I can take a look for allowing to override 
it per client in your new tab. Sounds good?

Marek
>
> I think #3 is also valid if apps want to bypass login form for their users and go straight to an identity provider.
>
> FYI, currently implementation redirects the user automatically to an identity provider if there is a single one and no credentials are configured for a realm.
>
>> 4) Don't configure anything, but hard-code that Kerberos will be always
>> used by default if configured. Basically add new method "boolean
>> isDefault()" to IDentityProvider interface. It will return "true" for
>> Kerberos impl and "false" for other broker types we currently have.
>>
>> I like (1) or (2) most. Thoughts?
>>
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>



More information about the keycloak-dev mailing list