LDAP vs JDBC¶
Lightweight Directory Access Protocol (LDAP) and Java Database Connectivity (JDBC) servers can be configured as user stores in the WSO2 Identity Server. A JDBC server is used for updating data and processing queries to a relational database, while an LDAP server is used to process queries and data updates to an LDAP information directory. In other words, an LDAP information directory is a type of database, but it's not a relational database.
The following table provides a comparison between LDAP and JDBC that may aid you in your choice for a suitable user store manager.
| Comparison factor | Description |
|---|---|
| Static data | LDAP is mostly picked over JDBC if the read/write ratio is more than 10,000/1 (this number can be debatable). This is due to the fact that LDAP is more optimal for read operations. So, in general, LDAP is more preferred for static data. |
| Scalability | Even though LDAP can scale to multiple replicated servers and handle tens of thousands of authentication requests a second, LDAP has certain scalability concerns. Even Microsoft tends to recommend MS SQL server ahead of Microsoft Active Directory in cases where there is a user base of more than 1.5 million users. In most of the large scale deployments, JDBC is preferred over LDAP. There are instances where organizations use MySQL to handle as many as 60 million users. Some US state governments use MS SQL server to manage all of their citizens. However, not all organizations require the user store to have an exceptionally large user base and it is important to note that more than 90% of Fortune 500 companies use Microsoft Active Directory. So, the rule-of-thumb is if the user base is less than 1 million then LDAP should fine. However, if it exceeds that, then it is best to go with JDBC. |
| Easy identity management | LDAP implementations provide more in-built functionalities like password update/rotation policies, fine-grained access control via ACLs, account locking, groups, etc. However, if you are using a JDBC based user store, then either you need to implement all those yourself or use a third-party identity management system on top of the database. |
| Hierarchical relationships between user entities | LDAP has inbuilt support to manage hierarchical relationships between user entities. For JDBC based user stores, this has to be implemented from the scratch if it is a requirement for you. |
| Transactional data | Transactional data related to the user should not be stored in the LDAP. Those have to be maintained in the JDBC based database and linked to the LDAP user via entry UUID. |
| User attributes | The LDAP has in-built support for attributes with multiple values. For example, someone can have multiple email addresses, phone numbers, etc. By design, LDAP supports storage of multiple values for the same attribute. For JDBC based user stores, this has to be implemented from scratch If this is a requirement for you. |
| Security | LDAP has an in-built security model for the data it stores. You can define ACLs over attributes and sub-trees. You cannot do this in a JDBC based user store and it has to be implemented from scratch. |
| Extensibility of the schema | The schema can be extended in both LDAP and JDBC. |
| Integration with third-party applications | Integration with third-party applications is much more flexible with LDAP since it is a standard. |