You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Ed Roberts <g....@gmail.com> on 2010/11/10 14:42:01 UTC
Where is rg.apache.directory.shared.ldap?
Hi,
I have been all over the site... but I can not find the source for
rg.apache.directory.shared.ldap.* code... can you tell me where it is?
--
G. Edward Roberts
Elparazim
http://www.elparazim.com/GERBusinessCard.png
Re: Where is rg.apache.directory.shared.ldap?
Posted by Felix Knecht <fe...@apache.org>.
Hi
You can find most of it here:
http://svn.apache.org/repos/asf/directory/shared/trunk/
http://svn.apache.org/repos/asf/directory/shared/trunk/ldap/src/main/java/org/apache/directory/shared/ldap/
HTH
Regards
Felix
On 11/10/2010 02:42 PM, Ed Roberts wrote:
> Hi,
>
> I have been all over the site... but I can not find the source for
> rg.apache.directory.shared.ldap.* code... can you tell me where it is?
>
Re: Where is rg.apache.directory.shared.ldap?
Posted by Alex Karasulu <ak...@apache.org>.
You missed the o in org.apache.dir...
On Wed, Nov 10, 2010 at 3:42 PM, Ed Roberts <g....@gmail.com>wrote:
> Hi,
>
> I have been all over the site... but I can not find the source for
> rg.apache.directory.shared.ldap.* code... can you tell me where it is?
>
> --
> G. Edward Roberts
> Elparazim
> http://www.elparazim.com/GERBusinessCard.png
>
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: Question regarding code partitioning in Shared
Posted by Alex Karasulu <ak...@apache.org>.
On Wed, Nov 10, 2010 at 6:43 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
> 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.
>
This was exactly one of the reasons why we separated out some modules. It is
foreseeable that people want a small footprint and multiple jars and modules
is really not bad. With the boom around low resource devices it's inevitable
that our LDAP and KRB5 clients and libraries will be used in them. In fact
we should separate out everything based on protocol. The should be a
shared-ldap and shared-krb module and the associated asn1 classes/interfaces
should be in the respective modules.
> I will be investigating the other LDAP code dependencies in the Kerberos
>> code as well.
>>
> There are not too many.
>
True not 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.
>
+1 - I recommend this approach. There will be several benefits to this.
(1) Configuration in DIT for your server even if the store for your users is
not in LDAP natively.
(2) This will allow you to present user data in LDAP even if the store is
not LDAP and this has great value since most user information is stored in
LDAP.
(3) When we have auto-reconfiguration working for DIT based service
configurations the RADIUS can auto-reconfigure if the configuration is
changed in the DIT.
(4) Eventually we'll use OSGi to enable modularization and micro-rebooting
and you'll automatically gain from this.
(5) This really is where RADIUS data should go anyways since you'll gain
from the replication subsystem and have high availability for your service.
There's more but I'm sure this is enough to convince many. We can talk more
about this if you like.
> 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 !
>
Yes that's great news - it's a wonderful addition to the set of protocols we
already have. Nice to have DIAMETER as well :-). But you're more important
to us than the code you donate. Code is static, it's the community that
gives the code life.
If you're interested in getting involved and building this thing up we can
start off by creating a sandbox project for the RADIUS server. Slowly as you
get it operational and integrated we can start working on releasing it in
the server.
> 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.
>
>
+1
Looking forward to your involvement.
Best Regards,
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: Question regarding code partitioning in Shared
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 11/10/10 7:34 PM, feezelr@gdls.com wrote:
>
>> 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.
There are very few differences betwwen DER and BER encoding, most of
those differences are not relevant in Kerberos and LDAP.
>> 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.
We wanted to merge most of the 14 shared sub-projects because most of
them are not useful. When it comes to ASN.1 codec, the problem is that
there is a deep link between the codec and the data structures.
However, regarding Kerberos, we are currently working in a separate
submodule, and at some point, we may recreate a sub-project for ASN.1,
so that one who want to work with the kerberos codec can avoid including
the whole shared stack.
It's still a work in progress.
Also note that we want to merge the Ldap API project with shared (n
fact, shared will become the new LDAP API).
>
>> It's convenient.
> It just seems inconsistent with the architectural philosophy. Oh well...
Again, work in progress :)
There are some other factors here, like cross-modules dependencies,
cyclic dependencies, etc.
>
>> 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.
np, your call.
>> Anyway, sounds like a very good addition.
> I thought it seemed to make sense for ADS.
Indeed !--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Question regarding code partitioning in Shared
Posted by fe...@gdls.com.
Emmanuel Lecharny <el...@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.
Re: Question regarding code partitioning in Shared
Posted by Emmanuel Lecharny <el...@gmail.com>.
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
Question regarding code partitioning in Shared
Posted by fe...@gdls.com.
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
here.
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.