Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
From: "Li, Jiajia" <jiajia.li@intel.com>
To: "kerby@directory.apache.org" <kerby@directory.apache.org>,
	"dev@directory.apache.org" <dev@directory.apache.org>
Subject: RE: Kerby client library refactoring
Thread-Topic: Kerby client library refactoring
Thread-Index: AdEmd2d+kDNtvzviTFKkjWMa06g6YQABbzrQAAXuLAA=
Date: Tue, 24 Nov 2015 08:53:53 +0000
Message-ID: 
 <9037BCED616A964EB486B12FCA9DCFCF027AB59D@shsmsx102.ccr.corp.intel.com>
References: 
 <8D5F7E3237B3ED47B84CF187BB17B66611CD3F1C@SHSMSX152.ccr.corp.intel.com>
 <8D5F7E3237B3ED47B84CF187BB17B66611CD3F37@SHSMSX152.ccr.corp.intel.com>
In-Reply-To: 
 <8D5F7E3237B3ED47B84CF187BB17B66611CD3F37@SHSMSX152.ccr.corp.intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

It sounds great and will be easier to use these apis to write tools.

Thanks
Jiajia

-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]=20
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 t=
o supported mechanisms and functionalities.
Eventually we would have these client side APIs for applications to use.

=3D=3D KrbClient =3D=3D
Focus on classical Kerberos protocol, allowing to request/update tickets to=
 KDC using password, keytab, credential cache and etc.

=3D=3D KrbPkinitClient =3D=3D
Support PKINIT mechanism, allowing to request tickets to KDC using anonymou=
s and x509 certficate.

=3D=3D KrbTokenClient =3D=3D
Support standard JWT token, allowing to request tickets to KDC using JWT to=
ken.

=3D=3D KrbPwChange =3D=3D
Change passwd client, interacting with KDC using the change password protoc=
ol.

=3D=3D KrbAdmin =3D=3D
KDC admin utilities compatible with MIT kadmin tool in either local or remo=
te 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 descr=
iptions; For the components that use configurations, krb5.conf is default f=
ormat; For the components that interacts with KDC side servers, common netw=
ork and message support will be used; All will provide both intuitive funct=
ions and advanced function that supports directly calling into the underlyi=
ng layer.
These library APIs can be used to write tools like kinit, or embedded in ap=
plications.

It would be good to provide corresponding server side components or support=
s, 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 maj=
or work done before the 1.0.0 formal release.

Regards,
Kai