directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Question regarding code partitioning in Shared
Date Wed, 10 Nov 2010 16:43:11 GMT
On 11/10/10 5:11 PM, feezelr@gdls.com wrote:
> 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.
LDAP asn.1 is using BER encoding, when Kerberos is using DER. Not really 
a big deal though, as we are encoding and decoding the PDU the same way.

FYI, we had a separate package shared-asn1 6 months earlier, and we 
decided to merge it into shared, just because it's a PITA to deal with 
many jars when building an application on top of shared (we have more 
than one : the server of course, but also the installers, Studio, the 
API, groovy-LDAP)

It's convenient.
> I will be investigating the other LDAP code dependencies in the Kerberos
> code as well.
There are not too many.
>
> 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.
I'm just wondering if it would not be better to use the full stack, 
except that the Backend could be a SQL implementation. T
> 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.
Of course we are ! The question is : who will maintain it ? Are you 
going to be around ? If so, that would be a pleasure !
> 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.
That's a non issue at this point. We can work out a solution.
> 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.
My Radius book is still in the bookshelf, I have to open it again (it 
was 3 years ago the last time I browse it) before I can bring some 
valuable insights atm...

Anyway, sounds like a very good addition.



-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message