Thanks Emmanuel for the useful discussion!! >> The rational here is that we need this ASN.1 lib for ApacheDS, regardless of >> Kerby. I agree. The ASN.1 part can be used for ApacheDS LDAP things, regardless of Kerberos.
>> ASN.1 lib would be of use for other projects as an independent sub-project Sounds good for the future, if the lib becomes useful for more projects. >> Now, the problem is that replcaing it with something else will be difficult. >> When it comes to Kerberos, we have to support TCP *and* UDP ... I thought since ApacheDS uses MINA, the Kerberos part it contains should use it even when we use Kerby. As I said before, Kerby KDC server is already easy to support another network transport, like we did using Netty. I agree this is a major thing to consider if we're going to use Kerby for the Kerberos part. >> IMHO, it's better to do it piece by piece, because in order to do that, you >> have to decouple the code. If the code is highly coupled, we will face some >> bigger issues later on. I agree. What I said is, for some initial attempting, we could try it in a whole in a branch and see what's the major gaps, issues and concerns. With that initial work done, we can give it a try and an overall review. If all looks good, then we can break the work down into pieces and get them in one by one. >> If you have some time, feel free to play around... Sure! I will consider this and find some time for it. Regards, Kai -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: Friday, July 31, 2015 4:27 PM To: Apache Directory Developers List Subject: Re: Leveraging Kerby Kerberos library in ApacheDS Le 31/07/15 09:36, Zheng, Kai a écrit : > >> 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 ... The rational here is that we need this ASN.1 lib for ApacheDS, regardless of Kerby. Let me explain what I have in mind here : - from day one, the idea was for Kerby to be independant from ApacheDS, as much as possible, but still making ut possible to bundle the two guys into a single package. - you have proven that the ASN.1 codec we are using in ApacheDS is slower and more complex than the one in Kerby - regardless of Kerby/apacheDS relation, we want to use the best possible codec. That being said, I think that releasing the ASN.1 lib first could be a sweat plan : - first, it's almost ready : it works, the code is quite clean, and it's small - second, that would be an excellent exercise for the kerby project : cutting a small release first to learn how it's done would benefit everyone in Kerby - third, this will be a shared library anyway. I can forsee that the ASN.1 lib would be of use for other projects as an independent sub-project (like MINA or the LDAP API) Now, this might be just me. wdyt ? > >>> 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. MINA was used in ApacheDS for a good reason : back in 2003, when ApacheDS was started, Alex didn't want to spend some time on the network layer (I can understand) and decided to check on the internet if there was already something wrapping NIO available. He found Netty 1, and asked Trustin to join the project. It became MINA. At some point (2007?) MINA become a top level project, and we continued using it, but it became more and more complex. Many features added in MINA were not necessary for ApacheDS, and I must admit I spent a HUGE portion of time fixing bugs in MINA to get it working fine (well, more or less). In any case, I do think MINA 2 is overly complex, and the way we use it in ApacheDS is clearly sub-optimal. Now, the problem is that replcaing it with something else will be difficult. When it comes to Kerberos, we have to support TCP *and* UDP, plus the switch from TCP to UDP. We also have to deal with concurrent requests in ApacheDS, where one request can potentially be interrupted by an Abandon request (that means we can't block a session at all). That makes it quite complex to handle, if we were to rewite the whole system. Bottom line, I think that MINA 3 should address those issues, but there is a 3/6 months effort to put there, and we have many other more urgent tasks to complete before. So, here, we should have a discussion. > > I thought we could first focus on ApacheDS side (then Studio), attempting to > use Kerby to replace the old Kerberos codes. This would be a post-Kerby 1.0 task, agreed. > 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. IMHO, it's better to do it piece by piece, because in order to do that, you have to decouple the code. If the code is highly coupled, we will face some bigger issues later on. > 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. A branch might really be an option. Nothing replace real world experimentation :-) If you have some time, feel free to play around ! I'm just trying to proviude some feedbacks and perception of teh potential roadblocks, certainly not saying we should not try ! Sometime it's better to unleash people, and let them experiment. If they don't succeed, at least they will understand better why !
