directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Question regarding code partitioning in Shared
Date Wed, 10 Nov 2010 16:11:16 GMT
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 

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.

View raw message