Summary:	ASTERISK-00023: [request] External Auth and Change Password apps for Voicemail(2)
Reporter:	scrubb (scrubb)	Labels:
Date Opened:	2003-07-28 14:03:10	Date Closed:	2011-06-07 14:04:52
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	VmailAuthenticate and VmailChangePW outside of VoicemailMain. VmailAutheticate essentially just does the authentication loop from the voicemailmain(2) app and procedes to the next prio, like app_authenticate, only it takes a voicemail(2) context as a parameter and otherwise behaves just like app_authenticate (same prompts even).  It should also set variables, when succesfull, that are the ${AUTHEDUSER} and ${AUTHEDCONTEXT} context so the applications that follow can know which user and context was authed. The VMailChangePW would allow for changing a users password outside of the main voicemail application, again relying simply on the password change loop in the voicemailmain(2) app. Both of these applications would allow for using the voicemail userdatabase for _general_ authentication purposes.  They could even be used to allow for a "single sign on" for the phone system and all queue's, voicemail, disa, etc. Exten => s,1,VmailAuthenticate(default[,userid]) and Exten => s,1,VmailChangePW(defatul,userid) ****** ADDITIONAL INFORMATION ****** When I have a chance I will try to do these myself, however, I wanted to get the feature request in, so if someone else had the time or need, it could be done earlier.
Comments:	By: John Todd (jtodd) 2003-10-16 03:08:24 scrubb - nothing happening here; maybe you have some time to hack on these? By: scrubb (scrubb) 2003-10-17 15:47:29 Well, I've taken to doing all my voicemail.conf and otehr user information in a database.  I have an AGI script that pulls that callee's information from a DB into channel variables when * finally determines who locally to be called.  Based on the chanvars, the call gets handled (DND, Forward, etc) as per the users preferences, independent of the channel technology: sip/zap/skinny/etc. As a result of this method, I also have access to the users password and can do an Authenticate(${DB_PASSWORD}).   This long explanaiton above is to explain why my personal need for this feature has been resolved and why I probably wont take this one on any time soon.  However, I still think it is a valuable feature that needs to be implemented. By: Brian West (bkw918) 2003-11-22 16:01:42.000-0600 scrubb is this still something your intrested in? By: scrubb (scrubb) 2003-11-25 08:21:34.000-0600 As I mentioned my _personal_ interest in these is gone for right now.  However, I think this is a key feature to allow authenticated access to phone system resources (disa, menus, etc) without having to have multiple logins and pins.  Just my $.02 worth. By: Olle Johansson (oej) 2003-11-30 04:40:38.000-0600 My $.02 thoughts on a general architecure is here, but it's a large task. http://www.voip-info.org/wiki-Asterisk+password+files Basically I believe we need to construct a general "user" identity * USER -> Secret/Password (for channel authentication, text/numbers) -> Pin code (for voice authentication, not as strong) Voicemail etc -> Groups (Maybe also used for callgroups etc) -> Roles -> Context for incoming calls It needs to be extensible, so one can add other fields needed for an installation, like "customer id". By: scrubb (scrubb) 2003-12-01 09:09:02.000-0600 There have actually been some on list and off list lengthy discussions about the concepts of users/passwords/groups, etc. I beleive that the best way to handle this is with a plugable API for user account information so a standard can exist, but it has the flexibility like PAM. By: Olle Johansson (oej) 2003-12-01 09:19:55.000-0600 Agreed. By: jrollyson (jrollyson) 2004-01-10 23:54:03.000-0600 Why not store voicemail user info in the asterisk database, possibly with a one way hash?