directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Boorshtein <>
Subject Re: Kerby client library refactoring
Date Fri, 27 Nov 2015 00:42:59 GMT
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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message