[Freeswitch-users] Freeswitch Ldap Integration
Faraz R. Khan
faraz.khan at emergen.biz
Sun Jun 1 21:03:09 PDT 2008
Sounds amazing. Thanks a ton!
John Skopis (Lists) wrote:
> 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
>
>
> _______________________________________________
> 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
>
--
Faraz R Khan
Chief Architect
Emergen Consulting Pvt Ltd
+92.21.529.0381 x200
www.emergen.biz
More information about the FreeSWITCH-users
mailing list