[keycloak-dev] Kerberos progress

[Bill Burke]

I'm just trying to figure out where does the Broker SPI end and the User 
Federation SPI begin?  And wondering if our SPIs can be unified, 
simplified, or refactored.  For example, how would client-cert auth be 
implemented?  Like Kerberos, its a credential that is checked prior to 
displaying a login screen.

Another thing, does the broker SPI allow you to still require extra 
credentials supplied by Keycloak instead of the brokered IDP?

We just have to make these SPIs intuitive enough so that users know what 
they need to do and simple enough to extend Keycloak.

On 2/12/2015 3:49 AM, Marek Posolda wrote:
> On 11.2.2015 21:38, 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.
> Yeah, ok. I've mentioned the option #3 (Adding parameter to adapter
> config) just for case if you guys think that this is a way to go. But I
> don't like much as well ;-)
>>
>> 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
> Sure, that's exactly what I am doing. Application uses just SAML or OIDC
> for communication with auth-server. It doesn't know how it is
> authenticated. Existing brokering mechanism handles this very well and
> that's why I am using it.
>
> Only thing in your flow, which I don't yet have, is step 2. Currently
> login screen is always displayed and user needs to click on "Login with
> Kerberos" . Addressing it is what I am asking about.
>
> I can either do it automatically (realm will always use kerberos broker
> when it is available) or allow to configure it (Redirect automatically
> to kerberos just when it's configured as default broker). I think that
> allowing to configure is better way as it allows more flexibility.
>
> Marek
>>
>>
>>
>> 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