[keycloak-dev] Kerberos progress

[Marek Posolda]

I've pushed the Kerberos credential delegation stuff including 
documentation and example, so I hope the kerberos stuff is finished for 
now. As discussed before, I've used federation providers for Kerberos 
authentication support.

The credential delegation works in similar way like 3rd party social 
providers. Despite it's easier as credential is valid just for the 
session and doesn't need to support refreshing;-)

So user authenticates to Keycloak with kerberos ticket and Keycloak 
transmits the kerberos credential to the example application, which can 
use it for further calls to other kerberized services. The only 
difference is that kerberos credential is valid just for given 
UserSession, it's not attribute of UserModel. So I've added new 
OIDCUserSessionNoteMapper to map UserSession notes to the access token 
claims.

I hope to show more in the demo next week, let me know if you think that 
something should be improved. ATM I am considering kerberos as finished 
and going to look at other tasks I have - removing PL IDM dependency 
(hope I am able to catch the train for 1.2.0.Beta1 with this) and then 
other LDAP improvements and some other minor JIRAs related to 
export/import, mongo etc.

Marek

On 17.2.2015 09:59, Marek Posolda wrote:
> On 16.2.2015 22:52, Bill Burke wrote:
>>
>> On 2/16/2015 4:34 PM, Marek Posolda wrote:
>>> 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 ;-)
>>>
>> That's why I brought it up before...I wasn't sure what the right SPI
>> to use would be, or if our SPIs needed to improve and be refactored.
>> Maybe the answer is use both??? *shrug*
> Yeah, the fact you pointed it and some feedback from users in JIRA
> https://issues.jboss.org/browse/KEYCLOAK-828 makes me think that
> federation suits better:-) Was also thinking about keep both, but as you
> mentioned few months back, every possibility we offer also adds
> complexity and potential error-proness.
>
> ATM I am more to use federation SPI. And Kerberos identity broker can be
> restored later if there are usecases from community?
>
>> I don't know if this makes sense, but a kerberos broker would import
>> users from information from the kerberos ticket.  A Kerberos
>> Federation Provider interacts directly with an LDAP server to provide
>> a more complete integration point???  I don't know...just thinking.  I
>> don't know enough about kerberos or how people want to use it with us
>> to make a decision.
> ATM I am thinking about 2 possibilities:
>
> * Integration with Kerberos not backed by LDAP: For this case there will
> be KerberosFederationProvider. Kerberos ticket contains just username,
> so once user authenticated for the first time, he will usually need to
> update a profile (that would be configurable on/off switch). Same
> required action "Update_profile", which is used for social/identity
> brokering, will be used for this too
>
> * Integration with Kerberos backed by LDAP: For this case,
> LDAPFederationProvider will be enhanced. There will be configuration
> possibility on LDAP provider screen "Allow kerberos authentication".
> When user is first authenticated with Kerberos ticket, his profile data
> (firstName, lastName, email ...) are imported from LDAP. There is single
> federation link, so once I authenticate with Kerberos principal or with
> username/password from LDAP, Keycloak knows that it's same user.
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev