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 <[EMAIL PROTECTED] >>>> <mailto:[EMAIL PROTECTED]>> 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 >>>> > [email protected] >>>> <mailto:[email protected]> >>>> > 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 >>>> [email protected] >>>> <mailto:[email protected]> >>>> 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:[EMAIL PROTECTED] >>>> <mailto:[EMAIL PROTECTED]> >>>> GTALK/JABBER/PAYPAL:[EMAIL PROTECTED] >>>> <mailto:[EMAIL PROTECTED]> >>>> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch >>>> >>>> FreeSWITCH Developer Conference >>>> sip:[EMAIL PROTECTED] >>>> <mailto:[EMAIL PROTECTED]> >>>> iax:[EMAIL PROTECTED]/888 >>>> <http://iax:[EMAIL PROTECTED]/888> >>>> googletalk:[EMAIL PROTECTED] >>>> <mailto:[EMAIL PROTECTED]> >>>> pstn:213-799-1400 >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Freeswitch-users mailing list >>>> [email protected] >>>> 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 >>> [email protected] >>> 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 > [email protected] > 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 _______________________________________________ Freeswitch-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
