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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev