All,
I've finally found the time to really dig into the Kerby client code with an
eye towards adding remote kpasswd and kadmin functionality. Today, we found
what I believe to be the last area where the Kerby client generates different
packets than the MIT CLI tools. I've added a couple more sub-tasks to
DIRKRB-440 which will allow the KrbClient to set the list of encryption types.
I also think there's some refactoring to do around how the client builds the
request - the KOption and KrbKdcOptions are added into the request's options
(which does make them easier to pass) but then the requests need to read them
back out. I think I'd prefer that (at least as an option) we be able to build
the request we want and call something like an execute() method on the client.
In any case, adding the remote kpasswd and kadmin functionality will require a
small amount of refactoring within the client code as well as setting up the
class hierarchy in a convenient way. I'd propose the following hierarchy:
+----------------+
| KrbClient (AS) |
+----------------+
^ ^
| |
+----------------+ +-------------------+
| |
+-----------+
+-----------------+
| KdcClient | | <Protocol>
(AP) |
+-----------+
+-----------------+
^ ^ ^ ^ ^
| | | | |
+--------------+ | +-------------+ +----+
+----+
| | | |
|
+-----------+ +----------+ +-----------+ +---------------+
+--------------+
| KinitTool | | KvnoTool | | KlistTool | | KpasswdClient | |
KadminClient |
+-----------+ +----------+ +-----------+ +---------------+
+--------------+
^
^
|
|
+-------------+
+------------+
| KpasswdTool | |
KadminTool |
+-------------+
+------------+
Some important notes about where we would go from here:
1) The kpasswd and kadmin specifications share a protocol but don't share
commands. I haven't thought of a good name for the class yet so <Protocol> is
the placeholder. These commands <use> a ticket retrieved via an AsRequest but
the commands themselves are sent via ApRequests.
2) The Kpasswd client should actually understand both the Microsoft and the
"standard" variant of the protocol, so there are actually two different request
formats represent by kpasswd.
3) Any class above that includes the word "Tool" uses the class above it
(sorry about the ASCII art). Currently, the KrbKdcOption enum include flags
for the Tool but SoC would suggest that the arguments are a concern of the Tool
itself. I think it would also be easier to manage argument parsing with args4j
or commons-cli and that the English title of the flag should also be moved out
of the enum.
4) We might want a base class for some of the tools as they do have some
commonality.
5) There's an AsRequest class defined in the client code as well as in the
server code - is there some reason these classes aren't shared? If they simply
represent the packet on the wire, could they be shared?
6) We don't have an ApRequest in the client yet, if we share the AsRequest
with the server I'd suggest the same be done for ApRequest.
We're planning to continue work on the Kerby Client on Monday but would like
some input before we "perform major surgery". If you're interested, we could
take on responsibility for the client if that helps.
Have a great weekend,
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: "Zheng, Kai" <kai.zh...@intel.com>
To: kerby@directory.apache.org
Sent: Monday, January 11, 2016 7:29:20 AM
Subject: FW: Kerby client library refactoring
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....@rhelent.lan",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/freeipa.rhelent....@rhelent.lan",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.
