directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <kai.zh...@intel.com>
Subject RE: Kerby client library refactoring
Date Thu, 26 Nov 2015 12:03:45 GMT
Thanks all for the confirm! Will be back and proceed for this sometime later.

Regards,
Kai

-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com] 
Sent: Tuesday, November 24, 2015 1:59 PM
To: kerby@directory.apache.org; dev@directory.apache.org
Subject: Kerby client library refactoring

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

Mime
View raw message