[Asterisk-Dev] Pluggable authentication for assorted channels

[John Todd]

>I'd like people's input on this (better ideas are encouraged!)
>
>I've got a client who wants LDAP authentication added to chan_sip.  I was
>poking at it for a while, then decided "Hey, why not just add an
>abstraction layer for authentication that could be used for any other
>authentication?".
>
>So I mulled over it a bit and came up with this:
>
>Add a built-in to * for all of this...call it ast_pam_auth for lack of a
>better name.  You call it with a variable set of arguments which details
>your request from the PAM system.  The prototype looks something like
>this:
>
>int ast_pam_auth(char *source, int numargpairs, ...) where the variable
>argument list are pairs of "title" and a pointer for the return.  Example:
>
>char *username
>char *password
><mallocing & whatever is in here>
>foo = ast_pam_auth("chan_sip",2,"Username",username,"Password",password).
>
>The PAM subsystem then looks and sees that chan_sip is configured to use
>pam_ldap (which was registered into the system on load, much like
>applications & cdrs).  pam_ldap registered to use pam_ldap_query(...) and
>all the pointers that ast_pam_auth got passed get passed to
>pam_ldap_query, which runs its query, fills in the pointers with
>information, and returns/returns back to the channel.
>
>The channel can then do whatever it needs to with the data that
>ast_pam_auth has gotten for it.

Sounds like an idea whose time has come, certainly.  The inability to 
dynamically authenticate or more easily configure flow in the channel 
.conf files (SIP, specifically) is a real pain in larger 
installations, so I look forward to any work you might have towards 
making a more modular system.


First layer questions:
So, then I assume there would be an auth.conf or some similar file to 
regulate order of databases searched, argument-to-field matching, 
etc., as well as what channels were mapped to what authentication 
types?  I might suggest adding one more variable in there, which 
would be (for lack of a better name) an authentication stanza name 
(see below.)

second layer questions:
How would you indicate in the (for example) sip.conf file that the 
password was to be obtained locally, or from the PAM subsystem? 
Through some special string indicator where the normal username or 
password was usually placed?  Or would you have individual 
authentication processes for each user, some perhaps different than 
others?  This would be the most flexible, and would allow mixing of 
different authentication methods within the same channel.  Of course, 
defaults could be used to simplify configuration, but flexibility 
would be optimal.  Comma-delimited authmethods might be used for 
failovers between databases (not shown in example.)  As an example, 
here's what sip.conf might look like:


[general]
; set the default authentication method
authmethod=ldap-allservers

; any field filled with an * is mapped from
;  whatever mappings are relevant to that particular
;  authentication method

[1234]
user=*
password=*
context=from-sip

[1235]
user=*
password=*
context=from-sip
authmethod=postgres-homeoffice



{then, auth.conf would contain:}

[ldap-allservers]
type=ldap
server=1.2.3.4
port=389
secret=myldapserverpassword
  {more hypothetical LDAP stuff goes here}
mapping=user,dn=
mapping=secret,password=


[postgres-homeoffice]
type=postgres
server=localhost
table=uid-mappings
secret=mypostgrespassword
user=mypostgresuser
  {more hypothetical Postgres stuff goes here}
mapping=user,SIP-device
mapping=secret,SIP-password,md5


{end}

Each data store type (postgres, mysql, ldap, radius, kerberos, 
whatever) would have it's own set of values that you needed to fill 
in, of course, since each lookup method would be different.  In fact, 
the more I look at this the more flexible this module might really 
become, with almost all data being able to be replaced with a lookup 
in the external table, including 'context=' which would allow this 
system to easily become the glue between Asterisk and a 
database-driven mini-OSS.  You could set the context to be 
"deadbeat-recording" or whatever you wanted when the person didn't 
pay their bills, or easily alter the most relevant features of the 
way a device interacts with *, leaving only a bunch of pointers in 
the actual channel configuration files.

JT