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
> >
>
