Ah, see your idea. Yes it looks nice and let consider it. Thanks! Regards, Kai
-----Original Message----- From: Marc Boorshtein [mailto:[email protected]] Sent: Sunday, November 29, 2015 9:50 AM To: [email protected] Subject: Re: Kerby client library refactoring Sorry, was working on some other projects. My thought was instead of code that looks like this: requestOptions = new KOptions(); requestOptions.add(KrbOption.USE_TGT, tgt); //requestOptions.add(KrbOption.SERVER_PRINCIPAL, "HTTP/freeipa.rhelent.lan"); requestOptions.add(KrbOption.SERVER_PRINCIPAL, new PrincipalName("HTTP/[email protected]",NameType.NT_UNKNOWN)); requestOptions.add(KrbOption.FORWARDABLE,true); requestOptions.add(KrbOption.PROXIABLE,false); requestOptions.add(KrbOption.RENEWABLE_OK,false); I would think this would be more OO: requestOptions = new KOptions(); requestOptions.setTgt(tgt); //requestOptions.setServerPrincipal("HTTP/freeipa.rhelent.lan"); requestOptions.setServerPrincipal(new PrincipalName("HTTP/[email protected]",NameType.NT_UNKNOWN)); requestOptions.setForwardable(true); requestOptions.setProxiable(false); requestOptions.setRenewable(false); Could keep it backed by a set of options On Thu, Nov 26, 2015 at 7:54 PM, Zheng, Kai <[email protected]> wrote: > 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 > > >
