[Freeswitch-users] Freeswitch Ldap Integration
John Skopis (Lists)
jlists at skopis.com
Sun Jun 1 13:11:05 PDT 2008
Hi,
I had some free time and decided to add sasl support to mod_xml_ldap. I
only tested kerberos5 auth though.
I also added support for search filters.
The problem with the xml_ldap directory stuff is that since freeswitch
never actually sends the hash (or cleartext password) to the module it
can't bind as the extension to compare.
I would have much rather registered a module as an authentication
provider vs a xml provider. As I understand this portion of code is
somewhere in between the core and mod_sofia so it would need to be done
as an extension to mod_sofia.
All it does is connect to ldap as a privileged user, search for a
freeswitch extension, generate xml, and send the xml to fs.
If I find some more free time I may add support for requested attrs in
the ldap query. If you take a look at the code it currently grabs all
attrs and then joins on key=keyval. I did this so ldap schema didn't
have to be extended everytime the fs xml schema is extended. The reason
would be rather than requesting 100 attrs and iterating through them all
just request the ~4 required to generate the xml and iterate through them.
Also startls/ssl support might be nice ;]
-john
PS Until someone adds the config to tree (I cant write the config file
=\) here it is:
http://rafb.net/p/A37tLo10.html
Faraz R. Khan wrote:
> Thanks a lot. I intend to use it mostly as a SIP user directory. For the
> dial-plan I dont mind parsing and syncing XML file across servers (if
> there were a small cluster). The main deal is AUTHENTICATION. The
> authentication scheme I wish to keep is Kerberos (with SASL in Ldap for
> binding). This way all my credentials are centralized, be it SIP or
> mail.
>
> This would be a great achievement for me and many enterprises having
> thousands of identities. The dialplan stays fairly static once developed
> so I dont mind that being in a XML file. The dynamic stuff (user
> credentials) I wish to keep in a centralized store such as LDAP.
>
>
> On Wed, 2008-05-28 at 20:12 -0500, John Skopis (Lists) wrote:
>> At one point I was very interested in this...then I got a job. =[
>>
>> I thought mod_ldap was more of a PoC than anything. It might work (I
>> couldn't get it working and unfortunately don't remember exactly why..)
>> but there really isn't much point. I would have to do at least 5 ldap
>> queries (if not more) to get the most of the same functionality as the
>> XML dialplan. Also, the elegance of stackable functionality in the XML
>> dialplan is hard to imitate, at least with the any amount of efficiency.
>> If you don't need to stack actions a regular expression will almost
>> certainly be better.
>>
>> Attached is the schema, config, and sample ldif I used to get the xml
>> stuff working.
>>
>> With a little effort it could work with an existing schema (possibly the
>> ITU recomended LDAP schema that ser uses). I am not sure how easy it
>> would be to get the same flexibility as key/value pairs (like the FS xml
>> uses) though.
>>
>> -John
>>
>> Anthony Minessale wrote:
>>> We have a concept called the "directory interface" not to be confused
>>> with the "user directory".
>>> The directory interface is a pluggable abstract API that looks and feels
>>> like LDAP only you can plug in anything you want to implement the
>>> functions.
>>>
>>> mod_ldap is a module that registers to this interface and connects LDAP
>>> to it. So essentially you load mod_ldap then you use the freeswitch
>>> directory interface as you would have used the ldap code and it will
>>> carry over.
>>>
>>> There is a mod_dialplan_directory who uses the directory interface to
>>> ask for a dialplan, and installs the results into an extension. In the
>>> case of mod_ldap obviously it allows you to get your dialplan from LDAP.
>>>
>>> Now also in mod_ldap, there is some code someone recently contributed to
>>> tie our XML interface to LDAP,
>>> This is more interesting because then when anything in FreeSWITCH tries
>>> to lookup a user, dialplan entry or anything else in our XML config, all
>>> the important details are passed to LDAP where it can make a query, pull
>>> the info out of LDAP and deliver it back to FreeSWITCH as the XML it was
>>> looking for. This allows you to make all of the registrations, dialplan
>>> etc real time driven by LDAP, you can also bind a perl or lua script to
>>> this operation as well as mod_xml_curl who will turn the request into an
>>> HTTP post to a web server to fetch the data.
>>>
>>>
>>>
>>> On Wed, May 28, 2008 at 8:09 AM, Michael Jerris <mike at jerris.com
>>> <mailto:mike at jerris.com>> wrote:
>>>
>>> Currently the directory interface is only used for that dialplan, I
>>> would like to enhance that in the future. The directory dialploan
>>> uses a filter of exten=destination number, and then has name/value
>>> pairs, I will see if I can find the schema we used back when we
>>> developed it, short of that, the code is the best reference on that.
>>> Another option is to use mod_xml_curl and have your cgi back end to
>>> ldap of your choice. This will give you more flexibility to use
>>> other caller information in your ldap lookup.
>>>
>>> Mike
>>>
>>> On May 28, 2008, at 1:58 AM, Faraz R. Khan wrote:
>>>
>>> > First of all- Amazing project. Tired of asterisk deadlocking all the
>>> > time we have been deploying asterisk with OpenSER as the registrar.
>>> > Freeswitch is a huge relief!
>>> >
>>> > This is an extremely important feature we have been looking for.
>>> > Asterisk realtime ldap integration is very flaky. I found this page:
>>> >
>>> > http://wiki.freeswitch.org/wiki/FreeSwitch_Dialplan_Directory
>>> >
>>> > But there are no clues as to the schema, the queries generated and
>>> > what
>>> > exactly it can hold in Ldap. I am also curious to know whether
>>> sofia's
>>> > sip registrations, gateways etc can be kept in LDAP.
>>> >
>>> > We are basically developing an extensive plugin based control panel
>>> > and
>>> > a Asterisk module is already ready. However, we are writing
>>> > asterisk .conf files for managing asterisk. We would be quite
>>> > pleased to
>>> > develop a FreeSwitch Ldap plugin to manage users,sip gateways,
>>> groups,
>>> > features, etc.
>>> >
>>> > Though the XML configuration file is extremely easy to parse and
>>> > write,
>>> > pure LDAP integration would be amazing. Any pointers on this would be
>>> > appreciated.
>>> >
>>> >
>>> > --
>>> > Faraz R Khan
>>> > Chief Architect
>>> > Emergen Consulting Pvt Ltd
>>> > +92.21.529.0381 x200
>>> > www.emergen.biz <http://www.emergen.biz>
>>> >
>>> >
>>> > _______________________________________________
>>> > Freeswitch-users mailing list
>>> > Freeswitch-users at lists.freeswitch.org
>>> <mailto:Freeswitch-users at lists.freeswitch.org>
>>> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> >
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> > http://www.freeswitch.org
>>>
>>>
>>> _______________________________________________
>>> Freeswitch-users mailing list
>>> Freeswitch-users at lists.freeswitch.org
>>> <mailto:Freeswitch-users at lists.freeswitch.org>
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>>
>>>
>>>
>>> --
>>> Anthony Minessale II
>>>
>>> FreeSWITCH http://www.freeswitch.org/
>>> ClueCon http://www.cluecon.com/
>>>
>>> AIM: anthm
>>> MSN:anthony_minessale at hotmail.com
>>> <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>>
>>> FreeSWITCH Developer Conference
>>> sip:888 at conference.freeswitch.org
>>> <mailto:sip%3A888 at conference.freeswitch.org>
>>> iax:guest at conference.freeswitch.org/888
>>> <http://iax:guest@conference.freeswitch.org/888>
>>> googletalk:conf+888 at conference.freeswitch.org
>>> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>> pstn:213-799-1400
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Freeswitch-users mailing list
>>> Freeswitch-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>> plain text document attachment (sample.ldif)
>> dn: cn=1000,ou=192.168.0.102,o=galacticbell,dc=galacticbell,dc=com
>> objectClass: top
>> objectClass: sipCred
>> objectClass: inetOrgPerson
>> cn: 1000
>> sn: 1000
>> idname: 1000
>> param: password
>> param: vm-password
>> paramvalue: 1234
>> paramvalue: 0000
>> variable: accountcode
>> variablevalue: 1000
>>
>> plain text document attachment (garbageschema.schema)
>> attributetype ( 1.3.6.1.4.1.65535.1 NAME 'Reserved'
>> DESC 'Reserved attribute'
>> EQUALITY caseExactIA5Match
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
>>
>> attributetype ( 1.3.6.1.4.1.65535.2.1.1 NAME 'FSname'
>> DESC 'exten FSname import from exten name= in xml'
>> EQUALITY caseIgnoreIA5Match
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
>>
>> attributetype ( 1.3.6.1.4.1.65535.2.1.2 NAME 'exten'
>> DESC 'exten number'
>> EQUALITY caseIgnoreIA5Match
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
>>
>> attributetype ( 1.3.6.1.4.1.65535.2.1.3 NAME 'application'
>> DESC 'action for exten'
>> EQUALITY caseIgnoreIA5Match
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
>>
>> attributetype ( 1.3.6.1.4.1.65535.2.1.4 NAME 'data'
>> DESC 'argument to application'
>> EQUALITY caseIgnoreIA5Match
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
>>
>> attributetype ( 1.3.6.1.4.1.65535.2.1.53 NAME 'field'
>> DESC 'target for regular expression'
>> EQUALITY caseIgnoreIA5Match
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
>>
>> attributetype ( 1.3.6.1.4.1.65535.2.1.6 NAME 'expression'
>> DESC 'regular expression to matich in field'
>> EQUALITY caseIgnoreIA5Match
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
>>
>> attributetype ( 1.3.6.1.4.1.65535.2.1.7 NAME 'regex'
>> DESC 'BOOL if true process regex'
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
>>
>>
>>
>>
>> attributetype ( 1.3.6.1.4.1.65535.3.1.1 NAME 'context'
>> DESC 'context of exten'
>> EQUALITY caseIgnoreIA5Match
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
>>
>> objectclass ( 1.3.6.1.4.1.65535.3.2.1 NAME 'contextObject' SUP top
>> AUXILIARY
>> DESC 'Context'
>> MUST ( context ) )
>>
>> objectclass ( 1.3.6.1.4.1.65535.2.2.2 NAME 'extenObject' SUP top
>> AUXILIARY
>> DESC 'exten object'
>> MUST ( FSname $ exten $ application $ data )
>> MAY ( regex $ expression $ field ) )
>>
>> attributetype ( 1.3.6.1.4.1.65535.4.1.1 NAME 'FShost'
>> DESC 'BOOL if true process regex'
>> EQUALITY caseIgnoreIA5Match
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
>>
>> attributetype ( 1.3.6.1.4.1.65535.4.1.2 NAME 'section'
>> DESC 'BOOL if true process regex'
>> EQUALITY caseIgnoreIA5Match
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
>>
>> attributetype ( 1.3.6.1.4.1.65535.4.1.3 NAME 'tag'
>> DESC 'BOOL if true process regex'
>> EQUALITY caseIgnoreIA5Match
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
>>
>> attributetype ( 1.3.6.1.4.1.65535.4.1.4 NAME 'idname'
>> DESC 'BOOL if true process regex'
>> EQUALITY caseIgnoreIA5Match
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
>>
>> attributetype ( 1.3.6.1.4.1.65535.4.1.5 NAME 'param'
>> DESC 'BOOL if true process regex'
>> EQUALITY caseIgnoreIA5Match
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
>>
>> attributetype ( 1.3.6.1.4.1.65535.4.1.6 NAME 'paramvalue'
>> DESC 'BOOL if true process regex'
>> EQUALITY caseIgnoreIA5Match
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
>>
>> attributetype ( 1.3.6.1.4.1.65535.4.1.7 NAME 'variable'
>> DESC 'BOOL if true process regex'
>> EQUALITY caseIgnoreIA5Match
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
>>
>> attributetype ( 1.3.6.1.4.1.65535.4.1.8 NAME 'variablevalue'
>> EQUALITY caseIgnoreIA5Match
>> DESC 'BOOL if true process regex'
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
>>
>> objectclass ( 1.3.6.1.4.1.65535.4.2.1 NAME 'sipCred' SUP top AUXILIARY
>> DESC 'sip object'
>> MUST ( idname $ param $ paramvalue )
>> MAY ( variable $ variablevalue ) )
>>
>> objectclass ( 1.3.6.1.4.1.65535.4.2.2 NAME 'fsDirectory' SUP top
>> AUXILIARY
>> DESC 'fs object'
>> MUST ( idname )
>> MAY ( tag $ section $ FShost ) )
>>
>>
>> _______________________________________________
>> Freeswitch-users mailing list
>> Freeswitch-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
More information about the FreeSWITCH-users
mailing list