directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <kai.zh...@intel.com>
Subject RE: Leveraging Kerby Kerberos library in ApacheDS
Date Mon, 03 Aug 2015 14:24:44 GMT
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:elecharny@gmail.com] 
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 !

Mime
View raw message