On Fri, Jul 31, 2015 at 2:00 PM, Emmanuel Lécharny <[email protected]>
wrote:
> 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 ?
>
there are a bunch of readers for various formats but krb5.conf is the one
which is currently used.
>
> >
> >>> 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 :-)
>
infact integrating Kerby into ApacheDS can be done at any time later, and
this
is independent of the release cycle of Kerby
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.
>
>
--
Kiran Ayyagari
http://keydap.com
