Microsoft Identity Lifecycle Manager "2:" Sets
The concept of organizing things into sets is the most fundamental idea behind Microsoft Identity Lifecycle Manager "2." Our Group Program Manager, Alex Weinert, had listened to the requirements our customers had expressed for a self-service update to Microsoft Identity Integration Server 2003, and found that he was able to translate all those requirements into a common, simple language, using the notion of sets.
For example, Alex heard customers say that they needed people to be able to update their own contact information, but needed the administrators of their organization to be able to update office locations and cost centers, but the latter only with approval from the general manager. And he heard customers say that people needed to be able to re-set their own passwords, but that the identity checks to be performed would have to depend on that user's level of access. And so on.
Alex wanted to generalize customer's specific requirements. More importantly, he wanted to be able to describe a system that we could build that could be configured to produce all of the various outcomes that our customers wanted. Microsoft Identity Lifecycle Manager "2" is the implementation of that very general system that he conceived in the fall of 2006, a system that is so general, in fact, that the management of identity information is merely one application of it, and far from the most interesting one.
Parenthetically, I had worked with Alex periodically over the preceding two years. He was a lead program manager on the Windows Communication Foundation team, when I was the technical evangelist for that technology. Alex had been responsible for what I considered to be the most valuable and interesting part of the Windows Communication Foundation: the management facilities. Those features of the technology were the only things that Microsoft was producing at the time, I thought, that were even approaching what the market was demanding in terms of tools for implementing a a service-oriented architecture. So I knew that Alex was a very clever guy. I didn't know that he was going to accomplish by far the most ingenious feat that I have witnessed close at hand. When I was the software vendor developer evanagelist for Microsoft Canada, the very best part of my job was learning about the brilliant ideas that Canadian software vendors had implemented as products. But still I was blown away by Alex's accomplishment.
At the beginning of October 2006, we had a very long list of disparate requirements, and a long list of equally disparate features by which we were planning to meet those requirements. We even had mock-ups of the Web and Outlook user interfaces for the features. However, all we had done to factor out common principles, really, was identify a set of common controls, and, as the months went by, it would turn out that we hadn't done a particularly good job of that. Then Alex took a trip to Shanghai, were some of our team's developers are located, and the plane ride turned out to extraordinarily productive. He convened a meeting when he returned in which he presented the "Core Conceptual Model" for Microsoft Identity Lifecycle Manager "2," by which he was able translate the disparate list of customer requirements into a simple set of general processing requirements--into the description of a core platform, a machine, that would address all of those customer requirements as configurable consequence. In the course of that meeting, we went from having a bag of features to address a long list of requirements, to having a description of a machine that we would build that would yield the necessary features, and address the requirements.
Having a simple conceptual model for our product was an important, albeit implicit goal for us. If you are familiar with Microsoft Identity Integration Server 2003, then you will know that, conceptually, it is, frankly, a mess. Not only is the most expensive product in Microsoft's inventory, it is also by far the most complicated to understand. Everyone wanted Microsoft Identity Lifecycle Manager "2" to be easier to grasp, especially because it was meant to be used by everyone in an organization--not just administrators. Alex's conceptual model had the important virtue of being quite simple.
And at the heart of that conceptual model was the idea of organizing things into sets.
A set is simply a collection of things that match some criteria for membership.
Now that is pretty straightforward, right? I mean, I think I learned about sets in the second grade, because, at least in early '70's, educators had the idea that teaching kids about sets was somehow a prerequisite for teaching them mathematics. That may still be the idea--I wouldn't know, since I don't have children, and have not even spoken to a kid, come to think of it, in about 10 years. (Although my wife thinks she's married to one, but I digress.)
And that simple idea of sets gives us a systematic way of expressing ideas like "administrators can do this, but ordinary users can't" and "the office administrator of a group can update the cost center of people who report to that administrator's boss." Those ideas can be expressed, more generally, by saying, "Members of Set A can X to things in Set B."
Well, wow! Did we ever have fights over that idea. Some folk thought that we'd never figure out how to implement it--and it did take more than a year to really figure that out. And we also had battles over how the criteria for set membership were to be expressed.
In the end, we have been able to support defining the criteria for set membership using XPath. More generally, any query of Microsoft Identity Lifecycle Manager "2" must be expressed in a supported filter dialect, and the only dialect we will support in Microsoft Identity Lifecycle Manager "2" is a variant of XPath 2.0, and criteria for set membership are simply instances of queries.
The variant of XPath 2.0 that we support incorporates a generous subset of the syntax of XPath 2.0, along with a few functions that we have added. The most important limitations of our XPath dialect are that we only support absolute location paths, and only the first location step can have a predicate, as in /Person[DisplayName='Craig'] , where /Person is the first location step, and [DisplayName='Craig'] is the predicate.
Typically, you would use XPath expressions like these to query Microsoft Identity Lifecycle Manager 2, or to define sets:
/X
/X[A='s']
/X[(A='s') or (B='t')]
/X[(A='s' and /Y[B='t']/C]
In these expressions, X and Y each refer to a particular kind of things stored in Microsoft Identity Lifecycle Manager "2," like a Person or a Group. A, B, and C each refer to an attribute of a thing, and s and t refer to values of those attributes. Thus, more expressive examples of queries and set definitions might be these:
/Person
/Person[DisplayName='s']
/Person[(DisplayName='s') or (CostCenter='t')]
/Person[(CostCenter='s' and /Group[DisplayName='Joe's Staff']/ComputedMember]
Some types of objects and their attributes are included by default--like the Person and Group object types, as well as the Set object type. All types of objects have some attributes, like the DisplayName attribute, and each type of object has some unique attributes, such as the FirstName attribute of the Person type. However--and this is a very powerful feature of the product--you can add your own types of objects, and you can add your own attributes, and associate those attributes with various object types. With some restrictions, you can even modify the attributes of the built-in object types. For example, you can add attributes that you define to the Person and Group object types.
How do you know what kinds of objects may be referenced in an XPath expression, and which attributes a given type of object has? Well, there are two ways of doing that. As an administrator of Microsoft Identity Lifecycle Manager "2" installation, you can follow the Schema Management link on the home page. Or as any user who happens to know how to use the Windows Communication Foundation, you can ask the Microsoft Identity Lifecycle Manager "2" service for its metadata. The metadata will include the definition of all of the types of objects and the attributes associated with them, that are currently defined in the system.
More details to follow ...