Glossary
LDAP (Lightweight Directory Access Protocol)
The protocol behind the corporate directory. LDAP is how applications look up users and groups in Active Directory or OpenLDAP and check a password against it, and it is the source of truth that single sign-on and provisioning tools sit on top of.
General definition
LDAP (Lightweight Directory Access Protocol) is the standard way to talk to a directory: a hierarchical database optimised for many reads and few writes, holding entries for people, groups, devices and services. The current version, LDAPv3, is specified in RFC 4511 and its companions. Each entry has a distinguished name (DN) that places it in the tree, such as uid=jane,ou=staff,dc=example,dc=com, and a set of attributes governed by object classes (mail, memberOf, telephoneNumber). Microsoft Active Directory is by far the most common LDAP directory; OpenLDAP, FreeIPA and hosted directories from identity vendors are the other frequent ones.
- Bind: the client authenticates to the directory, simply with a DN and password or through SASL; applications use a bind with the user’s credentials as a password check
- Search: queries with a base DN, a scope and a filter such as
(&(objectClass=person)([email protected])) - Modify, add, delete: writes, usually restricted to administrators and provisioning systems
- Transport: port 389 with StartTLS, or LDAPS on port 636; plain LDAP without TLS should not be used
In enterprise software LDAP plays two roles. First, authentication: an application takes a username and password, binds to the directory with them and treats success as a valid login. This is simple but exposes the password to the application, which is why organisations have moved user-facing logins to SAML and OIDC, where the identity provider (itself usually backed by the directory) handles the credential. Second, user and group synchronisation: an application reads the directory to create accounts, assign roles from group membership and disable people who have left.
The second role is where LDAP still matters most for a chat platform. Someone has to keep the set of chat users and their permissions in step with HR reality, and the directory is where that reality lives. Whether the sync is done by a scheduled job reading LDAP, by a SCIM feed from the identity provider, or by the customer’s own backend calling the application’s API, the directory is upstream of all of them.
In the Ethora ecosystem
On dedicated and self-hosted deployments the recommended pattern is API-provisioned end users: the customer’s backend or an integration job reads its LDAP or Active Directory, creates and updates Ethora users through the API, and issues chat tokens, so people never see a separate Ethora login and departures are reflected as soon as the directory changes. Roles for the team members who administer the platform are set in the admin panel with role-based access control and ACL settings.
User-facing authentication then follows whatever the customer already runs: social sign-on through OAuth and OIDC providers, enterprise SSO against the corporate identity provider on dedicated deployments, or the host application’s own session when chat is embedded through the Chat SDK. Every provisioning and role change is recorded in the audit trail, which is what compliance reviewers ask for when they want to see how directory changes reached the chat system.
