On 11/10/10 5:11 PM, [email protected] 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
