Commentary by Mark Wahl
Organizing principles for identity systems:
Background: SP-DNA metaschema
(2005/6/14)
In a subsequent post I'll be using some concepts derived from metaschema which appeared in SP-DNA, so I wanted to reintroduce the SP-DNA's history and provide a brief summary of its metaschema plan.
In the late 1990's, the Sun/Netscape alliance iPlanet and Nortel created a
partnership to enable the iPlanet messaging server software and the Nortel telecoms
server software, both targeting the service provider marketplace, to be able
to use the same LDAP directory: entries created by one vendor's management tools
would be visible to and usable by the other vendor's tools. From this derived
a standardization effort, 
Service
Provider Directory-enabled Network Applications (SP-DNA), that was later
integrated
into the Directory Interoperability Forum (DIF). The DIF is now part
of the Open Group, and the SP-DNA
activity ended around 2002.
One of the key assumptions in SP-DNA was that the applications may be deployed into a hosting service provider environment: the directory tree may contain information from potentially many hundreds of organizational customers of that service provider. Another assumption was that there was to be more than one access query pattern to directory information which needed to be made efficient - some applications make domain-based queries to route mail, others username-based queries to check access.
If an organization, such as a service provider, were in a green fields scenario in which they were able to to deploy a brand-new directory to support SP-DNA, and were able to control the structure and content of the subtrees being provided by the customers to be hosted, then it would in principle be possible to simply define a directory tree structure, specifying the position of each kind of entry (organization, organizationalUnit, person) and the content of each entry (e.g. an individual subscriber was to be represented as an inetOrgPerson entry below ou=People with attribute mail containing the public email address), and standardize that definition as the green fields scenario Information Model. All SP-DNA applications would be hardcoded to this model, and so long as the only directory servers they accessed were storing entries in this model, the applications would work.
However, what if the service provider already had their directory service in place, and had chosen a slightly different tree structure? Or if the hosted customers provided their own directory structure and content for their subtree, and had their own applications relying upon that structure or content? Applications which break subtly because of a customer's choice of email address, or would require a costly rewrite, are undesirable.
So besides the Information Model, the SP-DNA Conceptual Model was developed provide the context for directory interoperability. First, to capture semantics not available in LDAP, but implemented in Service Provider applications. Secondly, to allow a wide set of directory information trees (DITs) to be conformant to SP-DNA, and in particular be mappable onto the Information Model for green fields deployments. Unfortunately, this Conceptual Model was not completed by the time SP-DNA shut down, but some of the concepts are of interest.
The Conceptual Model was to be specified as a series of views, each corresponding to a role in the deployment (Service Provider or Hosted Organization). Within a view, were a series of layers. Each layer defined a UML graph illustrating the relationships between the modeled objects, implemented as instances of classes. (The layers interconnected and were mainly a way of constraining the size of each graph to be understandable and fit on a single page.) A simplified example of what one of the graphs would look like (from a presentation by Nigel Jacobs of Sun):
Some classes in the Conceptual Model inherited from or associated to similar base classes in the DMTF Common Information Model (CIM), primarily to enable better alignment with the Directory Enabled Networking (DEN) specifications, which also had an LDAP mapping and were based on CIM. However the core SP-DNA Conceptual Model classes remained separate from CIM, primarily as
- Some aspects of CIM were unnecessary to SP-DNA applications (and vice versa),
- CIM was typically being deployed in environments with a single system view and a single administrative control, which was inconsistent with SP-DNA's multiple views and distributed control,
- SP-DNA used modelling concepts, such as associations to association classes, that were uncommon in CIM
The planned approach to allow schema and DIT flexibility was to have applications converge through a layer of indirection: the Conceptual Model, rather than at the underlying directory schema (in the Information Model). They might leverage Metaschema Mapping Components that would translate query and update requests expressed in terms of the Conceptual Model into the pattern of LDAP operations that would effect these requests into the DIT structure of a particular deployment.
The Metaschema Mapping Component would have pre-loaded from the directory configuration information contained in the Metaschema DIT, a few administrative entries that encoded:
- the kinds of conceptual objects (such as Tenant and Subscriber in the case of SP-DNA), their attributes and associations used in the Conceptual Model, and
- the mapping of each of these into concrete LDAP DIT structure and schema
The mappings would be determined when the first SP-DNA application was deployed at a particular organization's directory: in the case of a green fields scenario, the default mappings could be chosen represent the Information Model exactly, otherwise the mappings could be tweaked to adjust to the schema and DIT of a particular deployment. Such mappings might have rules like
- the User entity is implemented by an entry of LDAP objectClass inetOrgPerson, and the tenant has users association is implemented by the user's entry being located below the ou=People entry, which is located immediately below the entry representing the Tenant
Fortunately, an SP-DNA application (other than an installer or a directory management tool) could remain unaware of these mappings.
As the query operations that a particular SP-DNA application would be performing are typically known during the application's implementation phase, they would be encoded within the application as a series of steps in a graph traversal across the SP-DNA Conceptual Model, from a known point (such as a Service Provider), given some attribute as input (e.g. a domain name), to find the attributes of another point in the graph (e.g. the distinguished name of a tenant organization which has a service for that domain). When the application starts up, it would have provided these steps to the metaschema mapper. The metaschema mapper would have responded with a template (in the case of a query, consisting of a series of one or more LDAP Search and Bind operations) with parameters where the input when the application is running could be plugged in. The application could then fill in this template and send the series of LDAP operations to the directory server each time a domain name needed to be looked up.