directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Moyer <smo...@psu.edu>
Subject Re: Kerby client library refactoring
Date Mon, 30 Nov 2015 12:57:41 GMT
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" <elecharny@gmail.com>
To: kerby@directory.apache.org
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/freeipa.rhelent.lan@RHELENT.LAN",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/freeipa.rhelent.lan@RHELENT.LAN",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.

Mime
View raw message