Choosing a Customer Credential Store - AD, AD:LDS, LDAP or RDBMS?

As organizations look for new ways to increase customer intimacy through digital interactions, IT organizations are being asked to bring external identities into their realm, whether customers or partners. The management and security of these new external user communities is stressing current enterprise identity and access management architectures, because enterprise user management is fundamentally different than external user management. As we work with our customers to modernize their IAM architectures to incorporate large numbers of external identities, the first decision to be made is the credential store. The wrong decision can lead to performance, scalability and availability issues.

There are essentially 4 paths to take, each with their own strengths and weaknesses as mapped out below:

AD LDAP RDBMS Comparison

Active directory (AD) was designed and built back in the 90’s for Windows domains with specific features including file and print management. It provided tight integration with windows applications to provide a good user experience via Integrated Windows Authentication (IWA). The directory service conforms to the X.500 standards and comes with a prebuilt schema that will support IAM projects. AD is used by 90% of corporations today for their workforce management and contains many useful features that support daily corporate operations. However, full AD doesn’t support Mac and Linux devices very well, which creates a problem in our BYOD world. There are a number of services not needed for a customer facing portal and as the number of customers scales into the millions, the amount of hardware needed to manage continues to grow.

Active Directory Lightweight Directory Service (AD:LDS), originally released as ADAM in Windows Server 2003 was designed and delivered as a direct competitor to traditional LDAP technology to manage external user identities. AD:LDS is not a domain controller and does not require the same labor intensive management that traditional AD requires. The main benefit of AD:LDS as a customer credential store is that it deploys with a predefined schema that can be extended in the same manner as AD to include security groups. Security groups support course grained access control and can benefit the overall end-to-end system integration. AD:LDS does have the same limitation as traditional AD, in that scaling up into the millions of users requires hardware footprint to continually grow.

OpenLDAP is an open source compliant LDAP server, which is considered a generic LDAP server similar to vendor provided solutions such as UnboundID, Oracle Internet Directory, Fedora DS 389. OpenLDAP is extremely flexible and scales very well without requiring lots of hardware. By default, OpenLDAP is empty after installation and has no structure, as compared to AD:LDS. For OpenLDAP, you need to build the schema and integrate the backend database. The good news is that the configuration is relatively straight forward if you are familiar with building database schemas and know how to build an LDAP directory service schema. If over over a million users are expected and worldwide distribution is required, then OpenLDAP is the better choice over AD:LDAS, as it will scale better over time and has capabilities to distribute the directory over standard protocols like other LDAP compliant directory stores.

Relational Database Management System (RDBMS) technology may be a consideration for management of external user credentials. Since a customer record for identity is fairly straightforward and doesn’t have the complexity of a partner or employee and the number of fields or attributes are minimal, an RDBMS may be a good choice for organizations. The real benefit of an RDBMS is that it can be simple to deploy and there are typically database administrators working on customer portal projects. All the leading federation vendors readily support database connections for the management of identity. However, replication for worldwide deployments is problematic, since most databases are deployed as a highly available cluster and replication can be costly to implement, whereas LDAP replication is native to the standard.

Consider these questions, as you evaluate alternatives:

  • How many users are going to be managed?
  • Is there a worldwide deployment and replication of the credential store required?
  • Does having security groups to manage roles benefit the customer portal?
  • Does your federation technology support RDBMS and/or LDAP?
  • Do you need flexible security options?

The choice of a credential store for a customer facing portal project must be considered up front, as it is the centerpiece of a secure, scalable and performing IAM architecture. There is no wrong answer, but considering your requirements and the alternatives available, you will ensure a successful project. Contact us if you have questions on selecting a customer credential store or if you need help modernizing your identity and access management infrastructure.

Rate this blog entry:
4