Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 96276 invoked from network); 10 Nov 2010 18:34:47 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 10 Nov 2010 18:34:47 -0000 Received: (qmail 27414 invoked by uid 500); 10 Nov 2010 18:35:18 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 27356 invoked by uid 500); 10 Nov 2010 18:35:18 -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 27349 invoked by uid 99); 10 Nov 2010 18:35:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Nov 2010 18:35:18 +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 (athena.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 18:35:11 +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 oAAIYlCE003842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 10 Nov 2010 13:34:49 -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 oAAIYl4G006413 for ; Wed, 10 Nov 2010 13:34:47 -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 2010111013344700-339684 ; Wed, 10 Nov 2010 13:34:47 -0500 In-Reply-To: <4CDACB9F.1020501@gmail.com> To: Apache Directory Developers List Subject: Re: Question regarding code partitioning in Shared MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: <28462_1289414089_oAAIYlCE003842_OFB1F11AC5.D49DBAAA-ON852577D7.00613D7C-852577D7.00660F7A@gdls.com> From: feezelr@gdls.com Date: Wed, 10 Nov 2010 13:34:46 -0500 X-MIMETrack: Serialize by Router on TLH01/SRV/LS/GDYN(Release 7.0.3FP1|February 24, 2008) at 11/10/2010 01:34:47 PM, Serialize complete at 11/10/2010 01:34:47 PM, Itemize by SMTP Server on STLSMTP/SRV/LS/GDYN(Release 8.5.1FP3|May 23, 2010) at 11/10/2010 01:34:47 PM, Serialize by Router on STLSMTP/SRV/LS/GDYN(Release 8.5.1FP3|May 23, 2010) at 11/10/2010 01:34:47 PM X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="=_alternative 00660F68852577D7_=" This is a multipart message in MIME format. --=_alternative 00660F68852577D7_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Emmanuel Lecharny 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= =20 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=20 particular > > note is Kerberos' use of the ASN1 packages in "shared-ldap". As a=20 test I > > created a "shared-asn1" module containing all the ASN1 packages but=20 none > > of the LDAP packages. The module satisfied all of Kerberos' needs and= =20 the > > jar file was only 81Kb whereas the shared-ldap jar file is over 1500=20 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=20 as > > there are other modules, such as dsml-engine at only 14.5 Kb. I=20 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= =20 > 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=20 > decided to merge it into shared, just because it's a PITA to deal with=20 > many jars when building an application on top of shared (we have more=20 > than one : the server of course, but also the installers, Studio, the=20 > API, groovy-LDAP) I thought that was what shared-all was for. Then there is only one jar to= =20 include. Perhaps I misunderstand. =20 > It's convenient. It just seems inconsistent with the architectural philosophy. Oh well... > > I will be investigating the other LDAP code dependencies in the=20 Kerberos > > code as well. > There are not too many. > > > > On another topic... I raised the question some weeks ago about=20 interest > > in a RADIUS implementation. Since then I have written one using Mina= =20 2.0 > > and modelled loosely on ApacheDS Kerberos. It was carefully crafted=20 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= =20 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,=20 > except that the Backend could be a SQL implementation. T The framework I'm using for testing has other functions built on the SQL=20 DB=20 so I don't have direct control of what the backend is, if that's what you= =20 mean by the "full stack". I expect that framework with my RADIUS in it to=20 persist. Due to my familiarity with it, and my lack of experience using LDAP, I was= =20 inclined to integrate it there first. > > Another pluggable aspect to the design is the use of request=20 "Evaluators" > > strung together using a "commons-chain" framework. I have created=20 request > > evaluators for PAP, CHAP, and MS-CHAP authentication requests (all=20 based > > on the availability of the users' clear-text password, Proxy=20 forwarding to > > another RADIUS server based on the domain name in the User-Name=20 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=20 rejects > > messages based on whether it can find the specified user in the data > > store, but always discards the message content. Clearly more is=20 needed > > here. > > > > I am planning to donate this RADIUS implementation to the Apache=20 Directory > > project if you're interested in incorporating it. > > Of course we are ! The question is : who will maintain it ? Are you=20 > 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= =20 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= =20 get=20 a solid 2.0 version, especially given that it didn't seem to be on the=20 radar=20 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=20 server > > responses need to be associated with individual users, groups of=20 users, > > groups of NAS's, etc. Since I've also never been a RADIUS server > > administrator, my familiarity with configuration management is limited= =20 to > > what I've read in the descriptions of other servers such as FreeRADIUS= =20 and > > Microsoft IAS. It is my understanding that making the decision-making= =20 as > > to what attributes to included in a response is generally based on=20 testing > > of the attributes included in the request. I have classes to support= =20 a > > basic implementation of this idea though I'm not clear it is=20 sufficient > > for all uses. > > My Radius book is still in the bookshelf, I have to open it again (it=20 > was 3 years ago the last time I browse it) before I can bring some=20 > valuable insights atm... I expect to have some light shed on this as we push to get a running=20 deployment in place. I'll try to get the code more stabilized and perhaps write a=20 more thorough architectural description. Asking you to wade into the code to=20 try to=20 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. >=20 > --=20 > Regards, > Cordialement, > Emmanuel L=E9charny > www.iktek.com >=20 This is an e-mail from General Dynamics Land Systems. It is for the intende= d 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 t= his message to the sender and delete the message and any attachments from y= our computer. Your cooperation is appreciated. --=_alternative 00660F68852577D7_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"

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 Kerbe= ros
> > 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&q= uot;.  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 messa= ge
> > 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.  Th= en 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<= br> > > definitions of a few Interfaces to be implemented by the instanti= ating
> > 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<= br> > > 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 functi= ons 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 experi= ence 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 distrac= tion 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 incorporat= ed 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 FreeR= ADIUS and
> > Microsoft IAS.  It is my understanding that making the decis= ion-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 stabil= ized 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 appro= ach.

> Anyway, sounds like a very good addition.
I thought it seemed to make sense for ADS.
>
> --
> Regards,
> Cordialement,
> Emmanuel L=E9charny
> www.iktek.com
>
This is an e-mail from General Dynamics Land Systems. It is for the intende= d 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 t= his message to the sender and delete the message and any attachments from y= our computer. Your cooperation is appreciated. --=_alternative 00660F68852577D7_=--