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/