[keycloak-dev] Kerberos progress

Mon Feb 16 16:34:21 EST 2015

Still thinking whether it's better to use federation SPI or identity 
broker SPI for kerberos integration. I am finally much more inclined to 
Federation SPI ;-)

Identity broker SPI is more flexible and allow to do things like link 
user account to 2 different kerberos servers. But is this real usecase 
in practice? Also is linking of accounts in Account management by user 
himself useful in production? It seems that admins, who integrate with 
Kerberos, will have similar infrastructure like LDAP (predefined set of 
users with hardwired user accounts to kerberos usernames) and there is 
likely no need to allow account linking like with social networks.

It looks that very common usecase for Kerberos will be integration with 
LDAP account. So same user is linked to both Kerberos and LDAP. Using 
Federation SPI means that single federation link is used for both LDAP 
and Kerberos (assuming that LDAPFederationProvider itself has support 
for Kerberos credentials). It makes the whole integration easier.

So today I prototyped Kerberos integration with Federation SPI approach. 
It's not yet pushed to master. What I did is:

* Add new "kerberos" UserCredentialModel type

* Add new method on UserProvider with signature 
"CredentialValidationOutput validCredentials(RealmModel realm, 
UserCredentialModel... input)" . New method is needed as with 
Kerberos/SPNEGO you don't know the user, who is going to authenticate. 
CredentialValidationOutput encapsulates info about authenticated user 
(or responseToken if additional handshake is needed)

* I am going to add support for "kerberos" credential into 
LDAPFederationProvider, so LDAP user can authenticate either with 
username/password (login screen) or with Kerberos ticket. Environments, 
which have Kerberos backed by user data in LDAP (MSAD domains etc) will 
use this one.

* I've added separate KerberosFederationProvider, which is for 
use-cases, when users have standalone Kerberos servers *not* backed by 
LDAP.

* HTTP handshakes are handled from single place in 
OpenIDConnectService.loginPage method. I will need to add it to 
SamlService, but that should be easy. I still think that earlier or 
later, we would need to improve authentication pluggability and do some 
filters/interceptors to handle it...

Anyone has strong feeling about federation vs. broker? If not, I will 
likely continue and push federation based Kerberos integration around 
tomorrow.

Marek

On 12.2.2015 17:43, Bill Burke wrote:
> 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
>>>>>>
>>>>
>>>
>>
>