[keycloak-dev] Kerberos progress

[Bill Burke]

Ok, sounds good.  Don't worry about filters and interceptors.  We'll see 
where the community takes us.

On 2/12/2015 11:35 AM, Marek Posolda wrote:
> I see your point. I still believe that kerberos better suits Broker SPI
> for few reasons.
>
> - Broker SPI allows update profile after first login, which is required
> for Kerberos (Kerberos doesn't have a way to provision firstName,
> lastName or email).
>
> - Also it allows link your account with kerberos in account management.
>
> - Finally broker allows to expose 3rd party token/credential from broker
> authentication to be shared to application and used for further calls.
> For Kerberos, this is achieved through credential delegation and we need
> to support as JBoss Negotiation supported it too (AFAIK Keycloak should
> support all the usecases previously supported by Picketlink+JBoss
> Negotiation).
>
> Only thing is automatic login without displaying login screen, but it
> makes sense to easily extend our broker SPI to allow configuring this.
> Usually people will require automatic login with Kerberos, but maybe not
> always. For example realm can be configured with 2 kerberos servers. In
> this case login page may be displayed and user will need to click on
> "Login with kerberos 1" or "Login with kerberos 2" according to which
> kerberos domain he has ticket.
>
> For handling more protections, maybe we should add something like
> AuthenticationFilter or AuthenticationInterceptor? That will allow
> people to configure chain of more interceptors and configure that user
> is required to login with all of Kerberos ticket, Facebook password and
> TOTP? We can also add flags like PAM (Required, Requisite, Sufficient etc)?
>
> Marek
>
> On 12.2.2015 14:49, Bill Burke wrote:
>> 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