[OpenSER-Devel] [ openser-Patches-1748544 ] New LDAP module

SourceForge.net noreply at sourceforge.net
Thu Jul 12 23:14:19 CEST 2007 

Patches item #1748544, was opened at 2007-07-05 11:26
Message generated for change (Comment added) made by cschlatter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1748544&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver devel
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Schlatter (cschlatter)
Assigned to: Daniel-Constantin Mierla (miconda)
Summary: New LDAP module

Initial Comment:
This new LDAP module implements an LDAP search interface for OpenSER. It exports script functions to perform an LDAP search operation and to store the search results as OpenSER AVPs. This allows for using LDAP directory data in the OpenSER SIP message routing script.

The following features are offered by the LDAP module:

  * LDAP search function taking an LDAP URL as input
  * LDAP result parsing functions to store LDAP data as AVP
  * Support for accessing multiple LDAP servers
  * LDAP SIMPLE authentication
  * LDAP server failover and automatic reconnect
  * Configurable LDAP connection and bind timeouts
  * Module API for LDAP search operations that can be used by other OpenSER modules

The module implementation makes use of the open source OpenLDAP library available on most UNIX/Linux platforms. Besides LDAP server failover and automatic reconnect, this module can handle multiple LDAP sessions concurrently allowing to access data stored on different LDAP servers. Each OpenSER worker process maintains one LDAP TCP connection per configured LDAP server. This enables parallel execution of LDAP requests and offloads LDAP concurrency control to the LDAP server(s).

An LDAP search module API is provided that can be used by other OpenSER modules. A module using this API does not have to implement LDAP connection management and configuration, while still having access to the full OpenLDAP API for searching and result handling.

Since LDAP server implementations are optimized for fast read access they are a good choice to store SIP provisioning data. Performance tests have shown that this module achieves lower data access times and higher call rates than other database modules like e.g. the OpenSER MYSQL module.

The code was tested with openser svn trunk and 1.2 branch.

----------------------------------------------------------------------

>Comment By: Christian Schlatter (cschlatter)
Date: 2007-07-12 17:14

Message:
Logged In: YES 
user_id=1787345
Originator: YES

I've uploaded revision 1 of the LDAP module. Changes are as follows:

- added avp_type parameter to ldap_result exported function
- updated documentation to reflect changes in ldap_result
- removed SL module dependency
- moved code to free last_ldap_result from get_connected_ldap_session to
lds_search function in ldap_api_fn.c

> Another question about the internal functionality. I see that you do a
> search, store the result inside the module and then convert to AVPs, if
> needed. How the internal result is freed, when a new search comes, the
old
> is freed?

I've moved the code to free last_ldap_result to lds_search in
ldap_api_fn.c for better readability.
File Added: mod_ldap_rev.1.tar.gz

----------------------------------------------------------------------

Comment By: Daniel-Constantin Mierla (miconda)
Date: 2007-07-11 03:42

Message:
Logged In: YES 
user_id=1246013
Originator: NO

AVP spec does not include / . you can use that format to specify the type.
If missing, can be considered default str.

Another question about the internal functionality. I see that you do a
search, store the result inside the module and then convert to AVPs, if
needed. How the internal result is freed, when a new search comes, the old
is freed?

----------------------------------------------------------------------

Comment By: Christian Schlatter (cschlatter)
Date: 2007-07-10 14:44

Message:
Logged In: YES 
user_id=1787345
Originator: YES

I did some research on how other LDAP APIs do solve the type conversion
problem. It looks like converting every LDAP value to string seems to be
the common solution. The reason for that is that LDAP has a very
sophisticated type hierarchy (like e.g. Directory String, Numeric String,
Octet String, or Telephone Number) which cannot be simply mapped to C-style
types.

Nevertheless, it would be handy to specify the AVP type in the ldap_result
call. One possibility would be to append a third field specifying the AVP
type to the first function argument, e.g. like

ldap_result("ldap_attr_name/avp_spec/avp_type" [, regex_subst])

avp_type = str | int

Does this sound reasonable? And is it a good idea to delimit the new field
with '/', can an avp_spec already include '/'?

----------------------------------------------------------------------

Comment By: Daniel-Constantin Mierla (miconda)
Date: 2007-07-10 09:15

Message:
Logged In: YES 
user_id=1246013
Originator: NO

> Is there a script function to convert a string AVP into an integer AVP,
and vice versa?

Yes, it is via string transformations and avp_printf():
http://openser.org/dokuwiki/doku.php/transformations:devel#string_transformations

We can go with the first version loading only as str and then think for
some improvements. There are many AVPs as integer as well, for example
ringing time, so some optimizations may be good in the future.

----------------------------------------------------------------------

Comment By: Christian Schlatter (cschlatter)
Date: 2007-07-10 08:49

Message:
Logged In: YES 
user_id=1787345
Originator: YES

>> Yes, that's how it is supposed to work. I'm using str2sint from ut.h
to
>> test if an LDAP value is of type integer or string. Depending on the
return
>> value of str2sint, the AVP will either be of type integer or string.
>
> I think we should find another solution. Many fields may be converted
to
> integer, but are needed as string. For example RPID, it is only digits
> because is telephone number, but it is added in a header. Also, aliases
may
> be DIDs, but are needed as str.
>
> A way to specify the type of loaded attribute should be added. I would
> rather prefer to load as str and convert to int in script.

You're raising a good point. I guess that having an AVP of type integer is
rather uncommon, so it would make sense to store all LDAP attribute values
as AVP of type string.

Is there a script function to convert a string AVP into an integer AVP,
and vice versa?

----------------------------------------------------------------------

Comment By: Daniel-Constantin Mierla (miconda)
Date: 2007-07-10 05:41

Message:
Logged In: YES 
user_id=1246013
Originator: NO

> Yes, that's how it is supposed to work. I'm using str2sint from ut.h to
> test if an LDAP value is of type integer or string. Depending on the
return
> value of str2sint, the AVP will either be of type integer or string.

I think we should find another solution. Many fields may be converted to
integer, but are needed as string. For example RPID, it is only digits
because is telephone number, but it is added in a header. Also, aliases may
be DIDs, but are needed as str.

A way to specify the type of loaded attribute should be added. I would
rather prefer to load as str and convert to int in script. 

----------------------------------------------------------------------

Comment By: Christian Schlatter (cschlatter)
Date: 2007-07-09 09:25

Message:
Logged In: YES 
user_id=1787345
Originator: YES

> I have few questions:

> 1) is it that the values loaded from LDAP are attempted to be converted
to
> integer, and if success, the AVP is going to have integer value? It is
what
> I got during review, maybe I am wrong.

Yes, that's how it is supposed to work. I'm using str2sint from ut.h to
test if an LDAP value is of type integer or string. Depending on the return
value of str2sint, the AVP will either be of type integer or string.


> 2) I see you import the SL API, but it is not in usage anywhere, any
plans
> with it?

This is a left over from a previous version of the module which I forgot
to delete.

----------------------------------------------------------------------

Comment By: Daniel-Constantin Mierla (miconda)
Date: 2007-07-09 06:23

Message:
Logged In: YES 
user_id=1246013
Originator: NO

I have few questions:

1) is it that the values loaded from LDAP are attempted to be converted to
integer, and if success, the AVP is going to have integer value? It is what
I got during review, maybe I am wrong.

2) I see you import the SL API, but it is not in usage anywhere, any plans
with it?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1748544&group_id=139143

More information about the Devel mailing list