directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <>
Subject RE: Leveraging Kerby Kerberos library in ApacheDS
Date Fri, 31 Jul 2015 07:36:58 GMT
>> Mavibot *has* to be completed, and we must cut a 2.0 RC too
Agree, the Mavibot backend is still relying on SNAPSHOT version, which should be resolved
if we have to include it for the release.

>> One other thing we need to do in ApacheDS is to switch from our complex and crippled
ASN.1 code to use Kerby code.
Yeah this can be done separately along with the Kerberos part.

>> we can start by releasing teh ASN.1 part of Kerby, and use it in ApacheDS
I thought it may depend. If we still have a long way to go for the cut of the first release,
then better to release the ASN.1 part first for the use; but if we could get it done not too
late, then ... 

>> AFAICT, Kerby is having its own code to manage communication. We depend on MINA.
If we have to get rid of MINA, that's fine.
Ah good point. It's a major issue we need to address. Since ApacheDS uses MINA I thought there
is no good not to use it for the Kerberos functionality. We may enhance kerby KDC server to
support plugin network mechanism, which needs some work, but won't be very hard.

I thought we could first focus on ApacheDS side (then Studio), attempting to use Kerby to
replace the old Kerberos codes. It's nicer to do it piece by piece and get the changes in
incrementally, but I guess some time it's hard to break down into tasks. Maybe we can have
a branch for the attempt if anyone would help with? Without some trying, something won't expose.
It may be not possible to come to the good time point when Kerby is well prepared for ApacheDS,
on the other hand, trying to do the integration work will expose some issues/enhance opportunities/adapting
things in Kerby side. 


-----Original Message-----
From: Emmanuel Lécharny [] 
Sent: Friday, July 31, 2015 2:00 PM
Subject: Re: Leveraging Kerby Kerberos library in ApacheDS

Le 31/07/15 07:27, Zheng, Kai a écrit :
>>> once Kerby is matured enough then we can add a dependency on it in ApacheDS and
> Is there any good sign in your view for the maturity? It looks reasonable, but should
we wait and do it then? I guess some pioneering work in ApacheDS side would be tried first.

The very first step, talking about maturity, would be a release.

IMO, there is no hurry to merge Krby and ApacheDS, even though I *do* think that would benefit
both projects. And when I talk about a merge, I mean a complete replacement of what we have
in ApacheDS with the Kerby code base. We also have a couple of things that need to be done
in ApacheDS : Mavibot *has* to be completed, and we must cut a 2.0 RC too.

So, as you can see, this is not at all about Kerby only : we have a lot on our plate too :-)

One other thing we need to do in ApacheDS is to switch from our complex and crippled ASN.1
code to use Kerby code. This would bring us a clear speeup. This can be done sperarately,
too (ie, we can start by releasing teh ASN.1 part of Kerby, and use it in ApacheDS).

Regardng teh configuration...
>>> The current code base tries to support way too many configuration formats and
I would like to see it support only one format, well and complete.
> Well, kerby-config may attempt to support various formats, but in the main/Kerberos part,
only MIT format is used right now. I agree we may support a ‘standard’ format if krb5.conf
isn’t any good standard. In your view, what’s left to be complete? Writing or generating
of configuration file in a format? Or whatever?
Krb5.conf support is mandatory, as it *is* the currnt format that most of those that would
use Kerby as a replacement will want to use. The only format we would like to support is a
LDAP based configuration.
There is no need to support JSon, XML, whatever other format.

Anyway, this is not a big deal. Enough say that having a way to deal with this configuration
from inside Kerby, regardless to the externam format, is fine. That means we need an internal
representation, and a few readers (a krb5.conf reader and a LDAP reader would be enough).

Kiran, what other formats is Kerby supporting atm ?

>>> And then we can add a GUI config editor in Studio easily.
> Did you mean we need to generate a config file after some editing using the GUI tool?
Kerby-config module allows to load configuration items from a Java Map/Properties, which may
work here. I mean, the edited values can be stored in any form and then all the values can
be loaded in a map for config to use.

The GUI should not care too much about the format, except that if we have to add as many options
("save as...") as we have supported format, would be a PITA. Again, 2 formats seems enough
to me.

But anyway, is this a problem at all ? Kai's question is more about 'Leveraging Kerby libs
in ApacheDS'. And as he says : "I'm thinking about what would be next steps after Kerby 1.0.0
out". 1.0.0 is not out yet, but will be soon, and this concern has been addressed already
:-) So, let's talk about the "what's next" (after the release) instead of talking about the
"what's before", because we all agree that a release is a pre-condition.

Here is what I can foresee :

0) Code style :

We don't care if Kerby uses a different code style, as soon as it's just a Lib being used
by ApacheDS. MINA uses a different code still already.

1) first step : get rid of ApacheDS ASN.1 code.

We don't even need a Kerby 1.0 to be oiut for that ! What we need is to have a separate ASN.1
lib which is released (that's easy to do).
That being said, the main problem will be the network layer. AFAICT, Kerby is having its own
code to manage communication. We depend on MINA.
If we have to get rid of MINA, that's fine. There is work to be done in this area, and it
will not come free of charge...

2) The big next step : get rid of ApacheDS Kerberos code

Whatever time we have spend on it, we should not feel to be semtimentally attached to this
code. This is just code, not a child. I'm not. If something better pops up, then fine (and
IMO, Kerby *is* or *will be* better.
How do we substitute ApacheDS Kerberos code with Kerby ? There are a few parts that need love
- the kerberos server
- the configuration
- the GUI

ApacheDS Kerbeors code is a layer on top of Directory Service, which means it relies on three
components : the backend (LDAP), the Network and the configuration. Note that the configuration
is a differnet beast, as it just glues all the other elements. As Kerby means to be also a
complete independent component, we need to be careful in the way we move it inside ApacheDS.
This is were we should have some work done, and it won't be easy.

3) In parallel : the GUI

Probably the easiest part. We just have to revamp what we have, but we probably also need
to make it separate. ATM, Kerberos config and ApacheDS config are tightly coupled, and it's
not necessarily a good think. I can imagine having a complete new plugin for Kerby (standalone
Kerby or Kerby in ApacehDS).

It's not funny to develop - I'm in the middle of some Studio work, and I know that !) but
it's probably a couple of month of work, max.

So, to be clear : there is a lot of work in front of us, but I can see a clear path on how
this can be done, and I can see the HUGE benefit we can all get out of this work, either from
Kerby POV and from ApacheDS POV.

View raw message