Keystone supports multiple backend for Identity. While SQL is the default, LDAP is one of the most used. With Federation protocols, the user data won’t even be stored in the identity backend at all. All three of these approaches have different use cases, and all work together. The way that that I’ve come to think of them is as three types of Keystone users: employees, partners, and customers. Take the following as a metaphor, not literal truth.
LDAP is the enterprise database of choice for employees (technically, a Directory server, accessed by LDAP, but we call the Database LDAP to distinguish from relation database which we call SQL due to the query language, to should satisfy the pedants.) LDAP entries are managed by HR (with help from IT) and is considered read-only data by most applications in the enterprise. The Keystone users in LDAP are people that we pay money to use OpenStack.
Partners are people from other companies that we work with. They have their own LDAP servers, but we don’t have access to them via LDAP. Instead, we get a SAML document, which is basically a snapshot of an LDAP query, signed with a private key. Partners are people we work with to make money. We neither pay them nor do they pay us.
Customers are people who pay us to use our OpenStack deployment. There are lots of them. They are quickly added to our Keystone store. Since LDAP is read only, we stick them in SQL. They belong to different companies, and people from different companies shouldn’t know about each other, so each of these companies are in their own domain. Only SQL allows multiple domains to be added dynamically.
Obviously, this is greatly over simplified. It does not account for service users. SAML might be used for employees. Another approach is that everyone might be in LDAP, and LDAP is set to be read-write; CERN does this. But the three classes of users listed above each represents a different usage pattern for Keystone’s identity store, and all three can and should be supportable in the same Keystone deployment.