Application Security, Part 15

Okay: so now that we have our ADAM directory service configured for TaskVision II, thereby completing the first step in our deployment of that application. The next step, you will recall, was that of setting up a channel of communication to ADAM from Active Directory via MIIS.

If we were to install MIIS, then there would be two things we would be glad to know in advance. The first is that the Enterprise Edition of Windows Server 2003 is required. The second is that SQL Server 2000 is also required. Yes, MIIS uses SQL Server as its data repository, and you might be remembering that, earlier, I said that LDAP directories are preferable to relational databases for the storage of user data, so doesn’t MIIS’ reliance on SQL Server contradict that claim? It truly does not, because MIIS is not a directory service but a channel between directory services and other repositories of user data. So, whereas directory services are meant to be written infrequently and read often, MIIS is likely to be written and read with almost equal frequency, with changes from connected repositories being written, and then read to the others.

Now, the connection between MIIS and other repositories is made by management agents, which one creates and configures within the MIIS Identity Manager user interface. In doing so, one selects the categories of objects in the other that one wishes MIIS to know about.  When the management agent executes, all of the objects in the specified categories are copied over to MIIS, into a staging area, known as the Connector Space, for that repository. Beyond the various connector spaces for the connected repositories, there is the meta-verse, which is MIIS’ synthesized view of the objects in the various connected repositories. So, for example, if there exist various entries for the same person in an organization’s repositories of user data, with one recording the person’s full name, another the person’s department, yet another the person’s telephone number, and yet another the person’s employee identifier, then the meta-verse is intended to serve as the repository where all of the information about the individual is collected into a single entry.

Then, let us think about what a management agent will need to do. As an object is brought into the connector space of a connected data source, the agent will need to search the meta-verse to determine whether a corresponding object already exists there. In the lexicon of MIIS, the process of finding a match in the meta-verse for an object in the connector space is known as joining the object in the connector space to the corresponding object in the meta-verse. In searching for a suitable match, the management agent follows join rules that one defines in the process of configuring the agent. In the simplest case, a join rule merely tells the agent which attributes of an object in the connector space to compare to which attributes of the objects in the meta-verse to determine if there is a match. So, again, in the simplest case, one might specify that the common name attribute, cn, of the connector space object is to be compared with the common name attribute of the meta-verse objects to find a match. If no match is found, if no join is possible, then in the lexicon of MIIS, the agent will follow rules that may permit it to project the object from the meta-verse. Projection rules are even easier to define than join rules in the simplest case, merely specifying what type of meta-verse object to create for a given type of object in the connector space.