directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From feez...@gdls.com
Subject Re: Question regarding code partitioning in Shared
Date Wed, 10 Nov 2010 18:34:46 GMT
Emmanuel Lecharny <elecharny@gmail.com> wrote on 11/10/2010 11:43:11 AM:

> 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.

The difference seems to elude me more often that I grasp it.

> 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)

I thought that was what shared-all was for.  Then there is only one jar to 
include.  Perhaps I misunderstand.
 
> It's convenient.

It just seems inconsistent with the architectural philosophy.  Oh well...

> > 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 initial 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

The framework I'm using for testing has other functions built on the SQL 
DB 
so I don't have direct control of what the backend is, if that's what you 
mean
by the "full stack".  I expect that framework with my RADIUS in it to 
persist.
Due to my familiarity with it, and my lack of experience using LDAP, I was 

inclined to integrate it there first.

> > 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 !

I expect to have a long-term relationship with this code so, yes I expect 
to be around to maintain 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.
>
> That's a non issue at this point. We can work out a solution.

I know everyone is pretty busy and this is a distraction from the drive to 
get 
a solid 2.0 version, especially given that it didn't seem to be on the 
radar 
until I asked the question a few weeks ago.

> > 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...

I expect to have some light shed on this as we push to get a running 
deployment
in place.  I'll try to get the code more stabilized and perhaps write a 
more
thorough architectural description.  Asking you to wade into the code to 
try to 
understand how it fits probably isn't the best approach.

> Anyway, sounds like a very good addition.

I thought it seemed to make sense for ADS.

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



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.


Mime
View raw message