On Mon, Jun 28, 2010 at 4:26 PM, Geoff Van Brunt <[email protected]> wrote: > Personally, I would like to see an admin only setting that one could > choose which types of logins are allowed: LDAP Only, LDAP with fall-back > to User\PIN, User\PIN. It won't take very much to add that, but the > functionality is similar to other network devices with Radius etc. As > you specified, no matter what the selection, the Admin accounts should > be able to log in with User\PIN no matter what in case of LDAP issues. >
Currently, user portal login is achieved based on the following scenarios: A) User Portal Authentication setting is set to true (checkbox is checked) -sipxconfig db authentication provider is first verified 1 if the user is present in DB than assuming that the credentials are correct it is logged into application 2. if the user is not present in DB then the ldap authentication provider is accessed and ldap authentication is automatically performed B) User Portal Authentication setting is set to false (checkbox is unchecked) -sipxconfig db authentication provider is first verified 1. same as above 2. if the user is not present in DB, login will fail anyway, because the ldap authentication provider is marked as disabled I am working on an improvement that will provide more clear scenarios: A) No LDAP - only sipxconfig db authentication is performed B) LDAP Only - only ldap authentication is performed C) LDAP and PIN - ldap authentication is performed; if it fails then sipxconfig db authentication is performed GUI interface will change: instead of User Portal Authentication checkbox will be a combobox with all 3 possible authentication options In order to achieve this, we need a change into ldap_settings sipXconfig table: enable_web_authentication column (boolean) will be replaced by a column (varchar) that will hold values that will point to the selected condition from above. In order to simplify database maintenance we decided not to provide a DB upgrade patch, but instead to directly modify the table schema, so anyone that runs a build that contains a patch with that table, will have to manually fix the table schema (running SQL commands) Mircea > As a future Jirra, you can add my vote for Single Sign On after LDAP is > working.... :) > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Douglas > Hubler > Sent: June-27-10 4:28 PM > To: sipX developers > Subject: [sipX-dev] LDAP authorization in the user portal,question about > sipXecs user name > > We're working on the feature to log into the user portal with one's LDAP > credentials, should the system be configured to require that. We came > into to a bit of a design question: How to associate the LDAP user to > the sipXecs user. I have a fairly clear proposal I'd like to run > through > > Proposal > =========== > * There are no changes to the LDAP field mapping in the sipXecs admin > interface. Admins still map whatever field they desire to the sipXecs > user name. > * Users log into the user portal with their LDAP user name, not their > sipXecs user name > > Example > ========== > Admin Portal > LDAP Setup > Map sipXecs user name --> customObject.assignedExtention (For > me this would be 2008) > > Web portal > Login > LDAP User Name: douglas.hubler > LDAP Password: ****** > > Technical Details > ============== > On successful login > step 1. We use our ldap credentials to find record with ldap > authorization name (e.g. douglas.hubler) > step 2. Once we have that record, we get field value from > customObject.assignedExtension and instantiate the sipXecs user object > with that value as the user name (e.g. 300) > > Assumptions > ============ > * This assumed there is way to search ldap for "find me the user that > logs in with this name", which i think there has to be, because it needs > to know it on login as well. > * Users will know to log into the web portal with their ldap user name > and not their extension. If not, we can fix this with field description > * Admins would want their users log into the user portal with their LDAP > user name. I think this is an obvious yes. Credentials are user name and > password pair. > > Notes > ====== > * This in no way precludes admins that want their sipXecs user ids to be > their actual LDAP authentication user ids. That scenario still works > under this design. > * This design does not affect the existing "PIN field". That will remain > to function exactly as it does today such as logging into Voice Mail, > and it will continue to map in ldap as is does today. Only change here > is that it would not be considered on user portal login (EXCEPT for > superadmin user but we can talk about this in separate > email.) > _______________________________________________ > sipx-dev mailing list [email protected] List Archive: > http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > sipXecs IP PBX -- http://www.sipfoundry.org/ > _______________________________________________ > sipx-dev mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > sipXecs IP PBX -- http://www.sipfoundry.org/ > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
