directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <>
Subject RE: Kerby client library refactoring
Date Fri, 27 Nov 2015 00:54:55 GMT
Thanks Marc.

An KOption is an enum value, and KOptions is essentially a map that does optionName ->
optionValue. You mean some getters/setters for KOptoins? For what? Now there're already some
methods to operate a KOptions. Maybe a simple example code? Thanks.

-----Original Message-----
From: Marc Boorshtein [] 
Sent: Friday, November 27, 2015 8:43 AM
Subject: Re: Kerby client library refactoring

One other thing I was thinking is if we could make the options more object oriented. Like
instead of having name value pairs we have getters/setters.
On Nov 24, 2015 12:59 AM, "Zheng, Kai" <> wrote:

> There are good feedbacks from Steve recently. Based on discussions 
> with him and Emmanuel, I assembled below thoughts.
> KrbClient and its relatives like KrbOption would be broken down 
> according to supported mechanisms and functionalities.
> Eventually we would have these client side APIs for applications to use.
> == KrbClient ==
> Focus on classical Kerberos protocol, allowing to request/update 
> tickets to KDC using password, keytab, credential cache and etc.
> == KrbPkinitClient ==
> Support PKINIT mechanism, allowing to request tickets to KDC using 
> anonymous and x509 certficate.
> == KrbTokenClient ==
> Support standard JWT token, allowing to request tickets to KDC using 
> JWT token.
> == KrbPwChange ==
> Change passwd client, interacting with KDC using the change password 
> protocol.
> == KrbAdmin ==
> KDC admin utilities compatible with MIT kadmin tool in either local or 
> remote mode. In remote mode interacting  with KDC, though no spec 
> standardizing that.
> Note there're already keytab and credential cache utilities.
> All these components will define their own options with good specific 
> descriptions; For the components that use configurations, krb5.conf is 
> default format; For the components that interacts with KDC side 
> servers, common network and message support will be used; All will 
> provide both intuitive functions and advanced function that supports 
> directly calling into the underlying layer.
> These library APIs can be used to write tools like kinit, or embedded 
> in applications.
> It would be good to provide corresponding server side components or 
> supports, but not mandatory. Better to have at least for easier tests.
> When sounds good, we can break this down into smaller tasks and get 
> the major work done before the 1.0.0 formal release.
> Regards,
> Kai
View raw message