From dev-return-35570-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Wed Nov 10 16:11:41 2010 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 10701 invoked from network); 10 Nov 2010 16:11:40 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 10 Nov 2010 16:11:40 -0000 Received: (qmail 47531 invoked by uid 500); 10 Nov 2010 16:12:12 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 47493 invoked by uid 500); 10 Nov 2010 16:12:12 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 47473 invoked by uid 99); 10 Nov 2010 16:12:12 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Nov 2010 16:12:12 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [192.136.15.167] (HELO maisz02h.gdls.com) (192.136.15.167) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Nov 2010 16:12:01 +0000 Received: from maiss03h.gdls.com (maiss03h.gdls.com [136.180.1.16]) by maisz02h.gdls.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id oAAGBbGb026362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 10 Nov 2010 11:11:38 -0500 (EST) Received: from GDLLSDSRVSHC102.ls.gdls.com (gdllsdsrvshc102.ls.gdls.com [136.180.145.102]) by maiss03h.gdls.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id oAAGBKmC022106 for ; Wed, 10 Nov 2010 11:11:21 -0500 (EST) Received: from gdllsdsrvtlh002.ls.gdls.com ([136.180.182.2]) by GDLLSDSRVSHC102.ls.gdls.com (Lotus Domino Release 8.5.1FP3) with ESMTP id 2010111011111712-335874 ; Wed, 10 Nov 2010 11:11:17 -0500 In-Reply-To: To: Apache Directory Developers List Subject: Question regarding code partitioning in Shared MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: <20339_1289405498_oAAGBbGb026362_OFF932CF88.35E0F1D7-ON852577D7.005296B6-852577D7.0058EC2E@gdls.com> From: feezelr@gdls.com Date: Wed, 10 Nov 2010 11:11:16 -0500 X-MIMETrack: Serialize by Router on TLH01/SRV/LS/GDYN(Release 7.0.3FP1|February 24, 2008) at 11/10/2010 11:11:17 AM, Serialize complete at 11/10/2010 11:11:17 AM, Itemize by SMTP Server on STLSMTP/SRV/LS/GDYN(Release 8.5.1FP3|May 23, 2010) at 11/10/2010 11:11:17 AM, Serialize by Router on STLSMTP/SRV/LS/GDYN(Release 8.5.1FP3|May 23, 2010) at 11/10/2010 11:11:20 AM, Serialize complete at 11/10/2010 11:11:20 AM X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="=_alternative 0058EC2B852577D7_=" X-Virus-Checked: Checked by ClamAV on apache.org This is a multipart message in MIME format. --=_alternative 0058EC2B852577D7_= Content-Type: text/plain; charset="US-ASCII" I have been exploring the possibility of using the ApacheDS Kerberos implementation in another application in which the backing store would not be an LDAP server. There seem to be a number of areas in which the Kerberos modules are entangled with the LDAP code. One area of particular note is Kerberos' use of the ASN1 packages in "shared-ldap". As a test I created a "shared-asn1" module containing all the ASN1 packages but none of the LDAP packages. The module satisfied all of Kerberos' needs and the jar file was only 81Kb whereas the shared-ldap jar file is over 1500 Kb. So I'm asking the developer's opinion regarding separating the ASN1 packages from shared-ldap and created a "shared-asn1" module. The relatively small size of such a module wouldn't seem to be a concern as there are other modules, such as dsml-engine at only 14.5 Kb. I assume that the ASN1 packages were originally created for the LDAP message parsing but they clearly have application in non-LDAP protocols as evidenced by their use in the Kerberos implementation. I will be investigating the other LDAP code dependencies in the Kerberos code as well. On another topic... I raised the question some weeks ago about interest in a RADIUS implementation. Since then I have written one using Mina 2.0 and modelled loosely on ApacheDS Kerberos. It was carefully crafted to be independent of the information store implementation by including definitions of a few Interfaces to be implemented by the instantiating framework. I have created implementations of the interfaces that use a SQL DB as the store and hope to have it deployed in a real-world environment for intial testing in the next few weeks. Another pluggable aspect to the design is the use of request "Evaluators" strung together using a "commons-chain" framework. I have created request evaluators for PAP, CHAP, and MS-CHAP authentication requests (all based on the availability of the users' clear-text password, Proxy forwarding to another RADIUS server based on the domain name in the User-Name attribute of the request, and Accounting message processing. I've also begun creating the framework needed to handle EAP requests but it isn't complete. Also the Accounting evaluator currently only accepts or rejects messages based on whether it can find the specified user in the data store, but always discards the message content. Clearly more is needed here. I am planning to donate this RADIUS implementation to the Apache Directory project if you're interested in incorporating it. Obviously an implementation of the data store interfaces which uses the ADS LDAP is required in order for it to be useable within Apache Directory. Unfortunately I have no experience creating applications which make extensive use of an LDAP store. Some basic information about each NAS (network access server) which are the "clients" of a RADIUS server is needed. Additionally, attributes which are to be incorporated into server responses need to be associated with individual users, groups of users, groups of NAS's, etc. Since I've also never been a RADIUS server administrator, my familiarity with configuration management is limited to what I've read in the descriptions of other servers such as FreeRADIUS and Microsoft IAS. It is my understanding that making the decision-making as to what attributes to included in a response is generally based on testing of the attributes included in the request. I have classes to support a basic implementation of this idea though I'm not clear it is sufficient for all uses. Thoughts? Thanks, Richard Feezel . This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. --=_alternative 0058EC2B852577D7_= Content-Type: text/html; charset="US-ASCII"
I have been exploring the possibility of using the ApacheDS Kerberos implementation in another application in which the backing store would not be an LDAP server.  There seem to be a number of areas in which the Kerberos modules are entangled with the LDAP code.  One area of particular note is Kerberos' use of the ASN1 packages in "shared-ldap".  As a test I created a "shared-asn1" module containing all the ASN1 packages but none of the LDAP packages.  The module satisfied all of Kerberos' needs and the jar file was only 81Kb whereas the shared-ldap jar file is over 1500 Kb.  So I'm asking the developer's opinion regarding separating the ASN1 packages from shared-ldap and created a "shared-asn1" module.  The relatively small size of such a module wouldn't seem to be a concern as there are other modules, such as dsml-engine at only 14.5 Kb.  I assume that the ASN1 packages were originally created for the LDAP message parsing but they clearly have application in non-LDAP protocols as evidenced by their use in the Kerberos implementation.

I will be investigating the other LDAP code dependencies in the Kerberos code as well.


On another topic...  I raised the question some weeks ago about interest in a RADIUS implementation.  Since then I have written one using Mina 2.0 and modelled loosely on ApacheDS Kerberos.  It was carefully crafted to be independent of the information store implementation by including definitions of a few Interfaces to be implemented by the instantiating framework.  I have created implementations of the interfaces that use a SQL DB as the store and hope to have it deployed in a real-world environment for intial testing in the next few weeks.

Another pluggable aspect to the design is the use of request "Evaluators" strung together using a "commons-chain" framework.  I have created request evaluators for PAP, CHAP, and MS-CHAP authentication requests (all based on the availability of the users' clear-text password, Proxy forwarding to another RADIUS server based on the domain name in the User-Name attribute of the request, and Accounting message processing.  I've also begun creating the framework needed to handle EAP requests but it isn't complete.  Also the Accounting evaluator currently only accepts or rejects messages based on whether it can find the specified user in the data store, but always discards the message content.  Clearly more is needed here.

I am planning to donate this RADIUS implementation to the Apache Directory project if you're interested in incorporating it.  Obviously an implementation of the data store interfaces which uses the ADS LDAP is required in order for it to be useable within Apache Directory.  Unfortunately I have no experience creating applications which make extensive use of an LDAP store.  Some basic information about each NAS (network access server) which are the "clients" of a RADIUS server is needed.  Additionally, attributes which are to be incorporated into server responses need to be associated with individual users, groups of users, groups of NAS's, etc.  Since I've also never been a RADIUS server administrator, my familiarity with configuration management is limited to what I've read in the descriptions of other servers such as FreeRADIUS and Microsoft IAS.  It is my understanding that making the decision-making as to what attributes to included in a response is generally based on testing of the attributes included in the request.  I have classes to support a basic implementation of this idea though I'm not clear it is sufficient for all uses.

Thoughts?  Thanks,
Richard Feezel


. This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. --=_alternative 0058EC2B852577D7_=--