A concept that’s key to understanding the Identity Manager user application is that of data abstraction, or being able to define, view, and manipulate instances of directory abstraction layer definitions.
Traditional storage technology, whether it involves relational databases, X.500 directories, or other repositories, typically requires that data entries (rows in a database, objects in an X.500 directory, and so forth) conform strictly to a well-defined schema. Queries over the stored data can be arbitrarily complex (in theory) and the data may include indexes and/or backlinks, but the actual data entries themselves are expected to conform to a fixed definition. Moreover, it’s assumed that the applicable schema(s) will not change markedly, if at all, over time.
This is a problem when information (possibly from disparate data sources, relying on disparate schemas) needs to be brought together to create composite data objects conforming to arbitrary new (and possibly transient) schema. Identity data is a classic example, because identities tend to be compositional and non-static. Moreover, the pieces of data on which a given identity is based can come from different sources, each of which might have administrators who are (understandably) protective of the information.
The distributed nature of identity data poses identity-management challenges that can be hard to solve in the face of rigid (and politically bound) schema definitions. One way to attack the problem is to bring together identity data in a logical vault (implemented as a directory) and assemble logical identities from the source data as needed, according to one or more logical schemas that map traditional LDAP objects and attributes (for example) to arbitrary abstraction layer definitions and attributes. In this way, identity data becomes highly compositional and dynamic. Changing the definition of an identity does not require making changes to an LDAP schema. Identity objects can be redefined at will, to suit particular applications or even particular users of particular applications.
This overall approach is often referred to as data abstraction, meaning that identities are materialized as needed, in the form needed.
Abstraction of identity data has a number of advantages:
It’s possible to avoid disruptive, potentially risky changes to LDAP-directory schemas
Abstraction technology is non-intrusive, requiring no changes to connected systems
New relationships between data are possible
The abstraction layer definition(s) can be changed or extended at any time
Objects can have as many or as few attributes as needed
Attributes from unrelated LDAP objectclasses can be merged in an abstraction layer definition
Arbitrary names can be used for attribute naming (there’s no requirement to use LDAP names)
Fine-grained access control policy is still applicable (users see only the data they have the rights to see)
Complex searches can be performed against new object types (or attribute combinations) which might otherwise be impossible in a pure-LDAP environment
Identity Manager leverages abstraction to achieve all of these goals and more.