>> 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. Regards, Kai -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: Friday, July 31, 2015 2:00 PM To: [email protected] 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 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.
