directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Moyer <smo...@psu.edu>
Subject Re: Categorize KrbOption by adding group info
Date Fri, 20 Nov 2015 11:42:42 GMT
Emmanuel and Kai,

I hope I haven't done too much complaining!  If I ever try to push the project in the wrong
direction, please let me know.  I intend to write a bit longer e-mail talking about what Penn
State needs from the Kerberos client with some specific design questions about the Kerby way
of doing things.

I will admit that understanding the structure of the code has taken me a while, and that wrapping
the layers of enums was especially confusing.  Perhaps I'm a power user but I was considering
building the AsRequest object myself since it avoids the ambiguity of which KrbOption ends
up where (the structure looks just like a packet as seen in WireShark).

I share Emmanuel's concern about KrbOption - we're merging things in a way that's opposed
to the idea of "separation-of-concerns".  Everytime something is added, it requires more code
in the requestTgtTicket(KOptions requestOptions) method (https://github.com/apache/directory-kerby/blob/master/kerby-kerb/kerb-client/src/main/java/org/apache/kerby/kerberos/kerb/client/impl/AbstractInternalKrbClient.java)
gets longer.  As an aside, the code added for DIRKRB-450 seems to have been removed from that
method.

There's actually a third layer of enum values - the KinitTool has a set of enums that define
its CLI arguments - these get translated into KrbOption and some of these get translated into
KdcOption.  The KdcOption enum encapsulates the 15 values representing the 15 flags in an
AsRequest which seems like the right level of encapsulation.  I don't mind enums with a lot
of elements (we have one with all the ISO country codes) but it's hard when the context switches
from one element to the next.

With all this said, with the recent changes, we're able to use the Kerby project for both
our authentication and kvno functions.  I'm looking forward to adding kpasswd and kadmin (per
the specifications of course).

Thanks again for all the work that went into this project ... I may be a newcomer but I'm
deeply appreciative!

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: Friday, November 20, 2015 5:09:40 AM
Subject: Re: Categorize KrbOption by adding group info

Le 20/11/15 10:52, Zheng, Kai a écrit :
> Thanks Emmanuel!
>
>>> I just find it easier to stick to the RFC ...
> Agree. Just forgot to mention that in the core we do stick to the specs and define those
types, like KdcOption. I would regard KrbOption(s) as the bridge or wrapper for the KrbClient
API to frontend and interact with users' applications.

I understand. Users might be confused by the various Enum, when they are
to pick the right one for the tool they use.
>
> Note I'm not thinking in the current codes the client API (including the KrbOption) is
defining ideally. Instead, it would be great to have it well reviewed and discussed before
a formal release. We do have enough time for that. 

It's definitively a blured area. I don't like classes/enums with tens of
constants, it's a kind of a pain for users, but the alternative is not
clear to me...

Definitively something that worth a discussion, I'm not sure I would
stand on my position which is not perfect either...

Mime
View raw message