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 integrate.
> 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.
