Thanks Steve for the response and great comments! Thanks all for all the good ideas. It looks good to me to expose KdcOption meanwhile to have some handy shortcuts to set those four very frequently used flags, along with some other parameters. Let's get it done some time. Note the refactoring is running slow as we have other urgent things to do. It's tracked here (some task issues to be opened yet). https://issues.apache.org/jira/browse/DIRKRB-478
For the kadmin/kpasswd things, your proposal looks good and any further inputs are welcome. If you feel there're something we should get done first and pave the way, please let we know. Thanks. Regards, Kai -----Original Message----- From: Steve Moyer [mailto:[email protected]] Sent: Monday, November 30, 2015 8:58 PM To: [email protected] Subject: Re: Kerby client library refactoring I'm in favor of separate method calls for the various "parts" of an AsRequest, but am wondering a bit about the KdcOptions as proposed by: requestOptions.setForwardable(true); requestOptions.setProxiable(false); requestOptions.setRenewable(false); FORWARDABLE, PROXIABLE AND RENEWABLE_OK are the three values that the MIT kinit program sets by default, but there are actually 15 of these flags (in a 32-bit bitmap). We talked about separating these flags into their own enum, but perhaps a utility class would work better. There are several options: 1) If KDC Options were declared as public static final int in a utility class: requestOptions.clearKdcOption(KdcOption.FORWARDABLE); requestOptions.clearKdcOptions(); requestOptions.clearKdcOptions(KdcOption.FORWARDABLE | KdcOption.PROXIABLE | KdcOption.RENEWABLE_OK); requestOptions.setKdcOption(KdcOption.FORWARDABLE); requestOptions.setKdcOptions(KdcOption.FORWARDABLE | KdcOption.PROXIABLE | KdcOption.RENEWABLE_OK); 2) If KDC Options continue to be defined in the existing KdcOption class: requestOptions.addKdcOption(KdcOption.FORWARDABLE.getValue()); requestOptions.addKdcOptions(KdcOption.FORWARDABLE.getValue() | KdcOption.PROXIABLE.getValue() | KdcOption.RENEWABLE_OK.getValue()); requestOptions.clearKdcOptions(); requestOptions.setKdcOptions(KdcOption.FORWARDABLE.getValue() | KdcOption.PROXIABLE.getValue() | KdcOption.RENEWABLE_OK.getValue()); There are quite a few other ways I think this would work but I'd argue that the Java convention is to treat a bitmap as an integer type (of appropriate length) and then use the bit-wise math functions to manipulate individual bits (commonly named as static values). If it turns out there are some number of very commonly used flags, I don't have a problem with the shortcut methods proposed but I'd also argue that the two forms are equally readable, but the proposed form has the advantage that you can tell you're manipulating a KDC Option: requestOption.setProxiable(true); versus requestOption.setKdcOption(KdcOption.PROXIABLE); Sorry for my lack of participation on this thread ... I'm very interested in its outcome (I've been on vacation the last week). When I return to the office tomorrow, I'll review it in detail and add the detail I've been promising related to the kadmin and kpasswd functionality. I did notice there was a comment related to the lack of a specification for remote kadmin functionality. The MIT protocol documents for both kadmin and kpasswd are available here: https://github.com/krb5/krb5/tree/master/doc/kadmin When I was working on this a couple years ago, I didn't find any server behaviors that contradicted those documents (note that the server might implement additional functions and I wouldn't have noticed). The Microsoft kpasswd protocol was adopted as a standard: http://tools.ietf.org/html/rfc3244 If I remember correctly, the Kerberos client built into Apache Directory supported clients using either protocol. I'd suggest it would be a good idea for the Kerby client to be able to interact with servers using either kpasswd protocol. Hope this helps! Steve -- “The mark of the immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one.” - Wilhelm Stekel ----- Original Message ----- From: "Emmanuel Lécharny" <[email protected]> To: [email protected] Sent: Sunday, November 29, 2015 2:53:14 AM Subject: Re: Kerby client library refactoring Le 29/11/15 02:50, Marc Boorshtein a écrit : > 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_UNKNO > WN)); 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_UNKNO > WN)); > requestOptions.setForwardable(true); > requestOptions.setProxiable(false); > requestOptions.setRenewable(false); > > Could keep it backed by a set of options Agreed. This is fully compatible with the definition of all the KrbOptions enums, except thay will not be visible by the end user.
