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_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 Agreed. This is fully compatible with the definition of all the KrbOptions enums, except thay will not be visible by the end user.
