Thanks Emmanuel for the feedback and sorry for the late response as focusing on the ASN1 things.
>> If those elements are going to be Enum, keep in mind that you can inherit >> from another enum. In current Kerby codes, for options and flags, we favor using the Java enum keyword as a better practice than interfaces of constants. The drawback is that it's not extensible, or in other words, an enum can't extend another enum. However, I thought it won't be a problem, because for example, KrbPkinitOption won't need to extend or include the options defined in KrbOption because KrbPkinitClient can always reference/aware KrbOption directly. Regards, Kai -----Original Message----- From: Emmanuel Lécharny [mailto:elecha...@gmail.com] Sent: Tuesday, November 24, 2015 4:33 PM To: kerby@directory.apache.org Subject: Re: Kerby client library refactoring Le 24/11/15 06:59, Zheng, Kai a écrit : > 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. If those elements are going to be Enum, keep in mind that you can inherit from another enum. So if you have common elements, feel free to put them in a parent Enum. Otherwise, sounds a good idea.
