[keycloak-dev] Kerberos progress

Bill Burke bburke at redhat.com
Wed Feb 11 15:44:20 EST 2015


I guess I don't understand why you would need Pedro's brokering 
mechanism to implement kerberos support.

On 2/11/2015 3:38 PM, Bill Burke wrote:
> I am not understanding how you have implemented this.  Wouldn't kerberos
> just be an authentication mechanism that the auth server uses?  I don't
> understand why you would want special configuration at the adapter
> level.  This should all be configured at the auth server so that the
> application doesn't have to know if kerberos is used or not.
>
> Wouldn't it be:
>
> 1. App does regular SAML or OIDC redirect to auth server
> 2. Auth server checks to see if realm supports kerberos
> 3. Sends 401 + HTML
> 4. Browser sends back ticket
> 5. Auth server verifies ticket, creates SAML or OIDC response and
> redirects browser back to application
>
>
>
> On 2/11/2015 2:29 PM, Marek Posolda wrote:
>> 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.
>>
>> 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
>>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


More information about the keycloak-dev mailing list