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 [mailto:[email protected]] Sent: Friday, November 27, 2015 8:43 AM To: [email protected] 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" <[email protected]> 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 >
