Exposing Customer Databases Securely for Authentication and Authorization

To securely authenticate and authorize all your users, you need access to your customer database, where those identities are stored and managed. But the best practice for security is to consume identity in the form of a directory. We build technology that bridges the gap between the two, and we know you need both. But how can you ensure security via LDAP, while still taking advantage of the versatility of SQL?  

SQL: Flexible, Robust—and Slow to Join

In most enterprises, databases already hold much of the identity data your portal needs to enable access. Unfortunately the need for flexibility sometimes conflicts with the need for specialization. And security requires a specialized high-speed form of access for these core processes:

• Authentication: Although SQL can be optimized for very general queries, it’s not the fastest engine when you’re doing high speed “lookup” for a specific piece of information, such as an email address (used as the login for many sites). This is the great advantage of more specialized “access method” used by directory storage, which is why LDAP is used for authentication and email address lookup—especially when dealing with large-volume populations, such as customers.
• Authorization: The hallmark of the relational database is its guaranteed consistency—thanks to the normalization rules and transaction support, you know there won’t be any update anomalies. SQL is also well known for its extreme flexibility for creating all kind of views, including hierarchical ones, if needed. However, there is a very high cost to be paid for this flexibility. RDBMS generate its views through joins, which can be extremely slow in situations where you need rich, contextual information. And this is typically the case for advanced authorization policies.

Finally, access to information inside a SQL database requires a good knowledge of the metadata. To issue a query, you must know the name of an entity, its attributes, and its relationships. This requirement is difficult to fulfill for an external consuming application, which is often totally different from the native application hosting the database. By providing a more granular query by attributes, directories offer a simpler, faster access method for security applications.

LDAP: Fast, Hierarchical—and Rigid

Directories provide fast access, more granular security, and enable search without having to understand the underlying schema. For these reasons, LDAP is the preferred—and often required—protocol for IAM initiatives.

The hierarchical organization of directories also allows them to scale out easily. By definition, you can always partition a tree into multiples nodes—an approach that fits perfectly in the cloud architecture. Partitioning a relational schema is not as simple.

But directories are also a relatively inflexible data structure. The view you create is fast to access, but hard to modify. And you always need more than one view, more than one hierarchy.

The Solution: Liberating your Data through Virtualization

With RadiantOne virtualization technology, it’s easy to create LDAP views on top of databases, so your consuming applications get the rich information they need at the speed they want and in the format they expect. But you are not limited to directory protocol—the identity service can be consumed from SQL or web services, as well. A potential scenario is to store data in SQL, represent it as LDAP, and consume it as web services.

RadiantOne lets you use the strengths of both relational databases and directories, combining the power of join (SQL) with the power of speed (LDAP). You can keep these two worlds in sync thanks to our exclusive real-time “auto refresh” synchronization mechanism: the RadiantOne Cache refresh.