Welcome Kai,
On Wed, Dec 24, 2014 at 1:57 AM, Zheng, Kai <[email protected]> wrote: > Hi all, > > > > I’m Kai and a guy from Intel Big Data team. I have been working on Apache > Hadoop for some while, and used to be an ApacheDS contributor and committed > the feature of CredentialCahce and a simple Kinit tool, guided by Emmanuel > and Kiran. After that when I was going to implement more Kerberos features > I realized there needs important improvement space in the existing > fundamental Kerberos codes. As a prototype I initiated Haox project and > have implemented an ASN1 encoding/decoding framework, complete encryption > and checksum crypto, Kerberos codec, Keytab and CredentialCache facilities, > KrbClient API and simple KDC server. It’s still in its initial phase and > far from ideal. However as strongly suggested by Emmanuel and Kiran, I > should collaborate with ApacheDS community and continue to make the effort > with you together. It’s great and now I’m going to contribute the project > to ApacheDS. I have discussed with Emmanuel and Kiran for quite some time > about this. Based on our discussion, we have the following proposal. It’s > for your review and consider. Please kindly provide your feedback and > advise. Thanks in advance. > > > > 1. First all our vision for the long term, we would think it makes great > sense to establish a first class Kerberos implementation in Java for the > Apache world targeting today’s environments in cloud, Hadoop and mobile. > Therefore we could collaborate together in ApacheDS community to build a > “Apache Kerberos” project. That’s why we’re here. > > > it was indeed and still is a goal of ApacheDS > 2. And as the first step to start with, ApacheDS would accept Haox as a > sub-project, renamed as “Apache Kerberos”. Then we consolidate existing > Kerberos implementation codes in ApacheDS into the new project; > > > and I hope that goal can be reached now with this effort > 3. Afterwards we will make further effort to push “Apache Kerberos” out > as a top level project, probably in a year or so. > > > sure it can be, MINA became a TLP this way > We have discussed other approaches, like using the good stuffs in Haox > to replace the corresponding parts in ApacheDS Kerberos, as one may also > suggest. So let’s figure out what might be good parts implemented in Haox. > > 1. Haox-ASN1. It’s a schema/model driven ASN1 parser and codec. Based > on the framework new Kerberos types can be easily defined following fixed > patterns, without having to take care of ASN1 encoding/decoding procedures. > We see this as very important because Kerberos itself and related > extensions are very ASN1 heavy. Without the basic friendly library support > it’s hard for new developers to contribute on new Kerberos evolving > features. We tested the codec performance and it outperforms a little. > Emmanuel has even contributed a few optimization improvements. > > > > 2. Kerberos crypto. The crypto framework (based on RFC3961) and > library implement all the encryption types and checksum types that MIT > Kerberos supports, like DES, DES3, AES, RC4, CAMELLIA, with extensive > interoperable tests covered. It relies on JCE for encryption but not any > Kerberos facilities provided in JRE. Potentially we could port it to other > non-Oracle Java environment like Android system, assuming we can implement > corresponding encryption and hash providers which can be pluggable. > > > > 3. Kerberos codec. Based on Haox-Asn1, the codec has implemented all > the necessary Kerberos types defined in Krb5(RFC4210), > Preauth/FAST(RFC6113), and PKINIT(4556). The core part has some test cases > covered already. > > > > 4. KDC server. The implementation abstracts an KrbIdentityService API > and decouples any specific identity backend from the Kerberos server. We > can provide an LDAP based backend, or allow vendor to implement their own > backed by SQL database, external LDAP server or whatever. For simple unit > test usage, a memory HashMap is all the needs. This allows our embedded KDC > really very lightweight avoiding many unnecessary dependencies. > > > > 5. Haox-event. It implements a UDP/TCP mixed network event support > based on Java NIO and reactor pattern according to Kerberos’s needs, where > UDP and TCP are both required, and even in IAKERB, a KDC proxy would serve > both TCP server role and UDP/TCP client role. In Haox-event, all these > roles can be done in an unified event receiving, processing and replying. > Test cases are given but it definitely need to tune and improve. Again, it > doesn’t rely on any other libraries, thus based on it KrbClient could > easily be supported in other Java environment. > > > > Keeping our long term goal in mind, we thought above functionalities, > properties and considerations may serve better to establish the foundation > for “Apache Kerberos” project, and it would be much easier to consolidate > the existing Kerberos implementation into it. > > > > So as a first step for the collaboration, how about: > > 1. Prepare, which involves: > > 1) Necessary cleanup; > > 2) All Kerberos related codes will start package names with > “org.apache.kerberos”, all the non-Kerberos related codes will be moved > into contrib projects or libraries, like Haox-ASN1, Haox-event, > Haox-config, which are actually not Kerberos logic specific. > > > > 2. Move Haox to be an ApacheDS sub-project: > > 1) Renaming Haox as “Apache Kerberos”; > > 2) A separate GIT repo; > > 3) A separate coding style, subject to be discussed and determined. > > > > Then as the 2nd step, consolidate the necessary parts in existing Kerberos > implementation. Below is the initial list and please complement: > > 1. Apache Directory Server support. We need to create an > LdapIdentityBackend using Apache Directory Server and use it by default, > embedded in the KDC server. > > 2. Installation packaging and service wrapper. Haox hasn’t > implemented such but ApacheDS does. > > 3. Tests. All the Kerberos related tests should be evaluated and > ported to the new codebase if not obsolete. > > > > In addition to above, we also need to consider the following aspects, to > make it good enough for potential users. > > 1. Adding the missing Javadoc. > > 2. Adding more tests. > > 3. Adding the documentation. > > 4. Building the web site > > > > With such done, then we might obsolete the AacheDS Kerberos implementation > and might move all the related codes into an history folder for existing > users. We would encourage users to use the new project. > > For the 3rd step, we would continue to implement some essential and > advanced features, which may include: > > 1. Cross realm support, which means Apache Kerberos can federate with > MIT Kerberos or MS AD; > > 2. Full functional client tools, like kinit, klist and kadmin, or > other alternatives; > > 3. Preauth/FAST framework, which allows to support other > authentication mechanisms based on the secure channel protected by an Armor > TGT/key; > > 4. PKINIT, authenticating user using x509 certificate other than > plain password; > > 5. Token preauth, authenticating user using a JWT token, to support > OAuth. > > 6. … > > > > Note tasks in step2 and 3 are not necessarily to be done in the order. > We’re likely to work on them in parallel. > > > > We would encourage more developers to contribute to the effort and develop > the community. Without that, we may not be able to make it to have a high > quality of Kerberos implementation, with all the important Kerberos feature > gaps being filled. > > > > Then finally as the last step, in some appropriate time we would push > Apache Kerberos out to be an Apache top level project. > > > sounds good on all parts, but as Stefan pointed out we must carefully evaluate the crypto part. > All the points are just suggestions and subject to your discussion. Your > feedback is most welcome. As widely discussed in a week or so, this > proposal is to be finalized and then re-posted. Then let’s collaborate and > make it together. > > > > Thanks for your support. Below is Haox project. > > https://github.com/drankye/haox > > > > At last but not least, many thanks to Emmanuel and Kiran. I can’t > appreciate them anymore. Without their encouraging, I would not have the > motivation though it’s still far away from the long term goal of “a first > class Kerberos implementation”. I do believe the Java world needs such, and > the whole Apache world needs it as well. Thanks for your great questions, > suggestions, complement points to sort this out. Thanks for helping me > understand further about the Apache way, particularly regarding how I > should proceed and collaborate with you guys in the community. > > > > Thank you all. > > > thanks for the detailed proposal, appreciate it. > Regards, > > Kai > -- Kiran Ayyagari http://keydap.com
