|
|
-
One of the features of Microsoft Identity Lifecycle Manager "2" is self-service password re-set. That feature sits on top of a generic facility of the Microsoft Identity Lifecycle Manager service that provides for multi-factor authentication.
To explain, one can define any number of management policy rules in Microsoft Identity Lifecycle Manager "2," each of which may apply, according to your choice, to a narrow or a broad a variety of operation that users may attempt to perform. Among other things, those rules may specify whether additional confirmation of the user's identity is necessary before permitting them to perform the operation. In Microsoft Identity Lifecycle Manager "2" that addtional confirmation will always be in addition to a Kerberos token identifying whoever it was that initiated the operation. If additional confirmation is required, then the management policy rule will identify the definition of a authentication workflow that must complete successfully before the requested operation willbe allowed to proceed. An authentication workflow will typically incorporate one or more activities for obtaining additional confirmation of the identity of whoever requested the operation, confirmation that could cover any number of authentication factors.
Microsoft Identity Lifecycle Manager "2" ships with one type of activity for corroborating identity: a question-and-answer activity. If one was to use that activity as a means for corroborating the identity of someone attempting to re-set their password, then that activity would present questions to the user for which the user would have previously provided the answers, during the process of registering to use the password re-set facility. So, for instance, the user might be confronted by any number of questions to confirm their identity, such as their mother's maiden name, the city of their birth, the make of their first car, and so on.
Now, as you may have read, a person was arrested last week for breaking into U.S. vice-presidential candidate Sarah Palin's Yahoo e-mail account. He is accused, apparently, of re-setting the password on the account, and publishling the new password on the Web, among other misdeeds. The account's privacy was protected by question-and-answer authentication gates. The lesson here is that if you are public figure, especially one as a visible as a candidate for U.S. federal executive office, then one will be afforded precious little protection by question-and-answer gates. While most people will not know the answers to even a few commonplace questions about your life and mine, unfortunately, if you are a candidate for high office in a democracy with a free press, then anybody will be able to ascertain the answers to those same questions, in your case.
|
-
I read a lot of spy fiction. I have observed that the sociology of an espionage organization, as depicted, especially by Len Deighton, is very similar to that of a software development enterprise. While I may expand on that observation in more detail here, at some point, suffice to say, now, that in both cases, there are people who go over the wall, as it were, and people who do not, and things only work well when those two groups function well together, and share the same priorties, and unfortunately, they often do not.
Anyhow, last weekend, while on what Bridget Jones referred to, in her famous diary, as a mini-break, I read David Ignatious' spy novel, Body of Lies. The film version of that book opened in wide release across the United States last weekend as well, and the review I read in The Seattle Times was not favorable, and the film did not perform very well at the box office. I have not seen the film, but from the review, it is apparent that the character played by Russell Crowe has been adapted somewhat for the screen. The reviewer also questioned whether there is room, in such a tale, for a romantic interest, which is odd to someone who had only read the book, because that romantic interest is the central plot element in the novel, the one that drives all the action toward its climax. So the question of whether there is room for a romantic interest in the story is rather like asking whether there is room for the character of Teresa di Vicenzo in On Her Majesty's Secret Service.
Regardless, as I say, I have not seen the movie, but the book is terrific.
|
-
Requests
In the argot of Microsoft Identity Lifecycle Manager, a request is a request to perform some operation on resource or on all or some of the attributes of a resource. The resource to which a request refers is generally known as the target of the request.
Sets
A set is a named collection of resources identified by a given filter expression, plus any resources that are added to the set regardless of whether or not those resources match the filter expression. Resources that are added to a set regardless of whether they is identified by the set's filter expression, are referred to as explicit members of the set, and the act of adding or removing such members is referred to as explicitly adding or explicitly removing a resource.
Recursive Sets
Recursive sets are sets with recursive filter expression. A recursive filter expression incorporates a secondary filter expression, and also names an attribute. The set includes every resource identified by the named attribute of any resource that is identified by the secondary filter expression, and it also includes every resource identified by the named attribute of any resource that is a member of the set. The attribute named by the filter of a recursive set will be referred to, below, as the recursive set's recursive attribute.
Set Membership Conditions
A set has membership conditions which are used to determine whether any given resource, in any given state, at any given point in time, belongs to the set. Each membership condition consists of one or more statements, each of which must be true for the given resource, in its specified state, if the resource, in that state, is to satisfy the membership condition. A resource must satisfy at least one of the membership conditions of a set in order for it to be among those resources identified by the filter expression.
Each statement of a membership condition is an assertion about the value of an attribute of a resource. Therefore, whenever an attribute of a resource is to be modified by a request, one can identify the membership condition statements that pertain to that attribute, and, thereby, identify the sets that the resource may join or leave as a result of the modification.
Management Policy Rules
Management policy rules stipulate who can request which changes to which resources. They also specify which workflows must be executed at which stage in the processing of a request.
Request Evaluation
When a request is submitted, a representation of the request is created in the Microsoft Identity Lifecycle Manager data store. Then the implications of the management policy rules for the request are determined. That step of determining the implications of the management policy rules for a request is generally referred to as request evaluation.
The management policy rules can have the following implications for a request:
1. They can grant the right for the request to be executed.
2. If no rule grants the right for the request to be executed, then the request is denied.
3. The rules can specify that certain authentication workflows must be completed before the request may be executed.
4. The rules can specify that certain authorization workflows must be completed before the request may be executed.
5. The rules can specify that once the request has been executed, certain action workflows must be executed on the target.
6. The rules can specify that once the request has been executed, certain action workflows must be executed on resources other than the target. An action that is to be performed on a resource as a result of a request is generally referred to as a collateral action if the resource is not the target of the request.
The scope of a management policy rule is most commonly defined in terms of the set that the target of the request would join if the request was to be executed. For example, one might have a management policy rule that says that a certain action workflow is to be executed on the target of a request if the target will join the set of resources located at a certain address as a result of the request. Consequently, in order to determine which management policy rules may apply to a request, it is necessary to ascertain which sets the target will join if the request were to be executed. Since the request evaluation process must therefore determine at least some of the implications of the request on set membership, it has been given the task of calculating all of those implications.
The Scope of Management Policy Rules
Whether a management policy rule applies to a request depends on the scope of the rule. The scope of the rule a rule is controlled by several attributes:
1. The ActionType attribute: this attribute identifies an operation that may be requested. Other things being equal, a management policy rule applies to a request if the operation that is requested is one of those identified by the ActionType attribute of the rule.
2. The ActionParameter attribute: this attribute identifies an attribute of a resource to which a modification may be requested. Other things being equal, a management policy rule applies to a request if the attribute of a resource to which a modification is requested is one of those identified by the ActionParameter attribute of the rule.
3. The PrincipalSet attribute: this attribute of management policy rules identifies a set, and, other things being equal, a management policy rule applies to a request if the initiator of the request is a member of the set identified by the PrincipalSet attribute of the rule.
4. The PrincipalRelativeToResource attribute: this attribute of a management policy rule identifies an attribute of a resource. Other things being equal, a management policy rule applies to a request if it is true, for the target of the request, that the initiator of the request is identified by the value of the attribute specified by the rule's PrincipalRelativeToResource attribute. For example, if the value of the PrincipalRelativeToResource attribute is Manager for a management policy rule, X, then, other things being equal, the rule applies to any request that is initiated by a someone who is the manager of the target of the request. If a management policy rule has a PrincipalRelativeToResource attribute, then it cannot also have a PrincipalSet attribute.
5. The ResourceCurrentSet attribute: this attribute of a management policy rule identifies a set. Other things being equal, a management policy rule applies to a request if the target of the request currently belongs to the set identified by the management policy rule's ResourceCurrentSet attribute.
6. The ResourceCurrentRelativeToPrincipal attribute: this attribute of a management policy rule identifies an attribute of a resource. Other things being equal, a management policy rule applies to a request if it is true, for the initiator of the request, that the target of the request is identified by the value of the attribute specified by the rule's ResourceCurrentRelativeToPrincipal attribute. For example, if the value of the ResourceCurrentRelativeToPrincipal attribute is Assistant for a management policy rule, X, then, other things being equal, the rule applies to any request that is initiated by a someone whose assistant is the target of the request. If a management policy rule has a ResourceCurrentRelativeToPrincipal attribute, then it cannot also have a ResourceCurrentSet attribute.
7. The ResourceFinalSet attribute: this attribute of a management policy rule identifies a set. Other things being equal, a management policy rule applies to a request if, after the request has been processed, the target of the request will belong to the set identified by the management policy rule's ResourceCurrentSet attribute.
8. The ResourceFinalRelativeToPrincipal attribute: this attribute of a management policy rule identifies an attribute of a resource. Other things being equal, a management policy rule applies to a request if it will be true, for the initiator of the request, after the request has been processed, that the target of the request is identified by the value of the attribute specified by the rule's ResourceFinalRelativeToPrincipal attribute. For example, if the value of the ResourceFinalRelativeToPrincipal attribute is Assistant for a management policy rule, X, then, other things being equal, the rule applies to any request that is initiated by someone who is requesting a modification to their own data to make someone else their assistant. Other things being equal, the rule would also apply to any request that is initiated by someone whose current assistant is the target of the request, unless the request was to delete that resource, in which case, after the request has been processed, the target would no longer exist to be the assistant of the person who initiated the request. If a management policy rule has a ResourceFinalRelativeToPrincipal attribute, then it cannot also have a ResourceFinalSet attribute.
Rights
If someone makes a request, and that request is permitted according to the management policy rules, then, in the Microsoft Identity Lifecycle Manager argot, that person has the right to make that request. However, even if a person has the right to make a request, the management policy rules may require that other people authorize the request. In other words, the right to make a request is not always sufficient for the request to be authorized.
If a management policy rule applies to a request and the value of that rule's optional GrantsRight parameter is 1, then that rule grants the right for some or all of the requested modifications to be made. Specifically, the right is granted for the requested modifications to those attributes that are referred to by the ActionParameter attribute of the rule. If the ActionParameter attribute of the management policy rule only refers to one attribute, but the request is to modify several attributes, then, unless other management policy rules permit the requested modifications to those other attributes, the request is denied.
|
-
Reading Judith Barker's excellent Agincourt: Henry V and the Battle That Made England, I came across what is, in effect, an early fifteenth-century Dilbert cartoon. Barker, in discussing the strategtic logistical planning for the Agincourt campaign, which Henry V of England undertook by invading France in the early 1400's, notes that gunpowder had been invented, and artillery had appeared on the battlefield. Early cannons, she explains, were not only difficult to aim, being very heavy metal things with no mechanical means of orienting them, but also required considerable effort merely to fire. The ammunition had to be loaded in the front, and a complicated, albeit primitive device, was used to get the gunpowder into the cannon. Consequently--and this is the crucial fact--the typical artillery crew usually only managed to fire their weapon once during a battle.
Now there is a record of a particularly efficient gunner, who, in a battle, was able to fire no less than an amazing three shots from his cannon in the course of a fight. Witnessing this feat, his commanders concluded that he could not have accomplished it were he not in league with the devil. So the gunner was sent off an a pilgrimage to cure his soul.
|
-
A startling proportion of our team, including myself, are Canadians, either by birth, or, like me, by naturalization. Also, two of the products that Microsoft purchased and are now incorporated into Microsoft Identity Lifecycle Manager "2"--the synchronization engine that used to be marketed by itself as Microsoft Identity Integration Server 2003, and the smart card management solution acquired from Alacris--were both developed by Canadian companies. Alacris was based in the Canadian capital, Ottawa, which has always been a computer technology hub in that country--Corel is based there, and Cognos, among many other of the biggest software companies in the nation. The synchronization engine, my colleague Sorin Iftimie, another Canadian expatriate tells me, was born in Toronto. Anyhow, you can't toss a football down our corridors--as some folk have been known to do--without hitting at least a couple of hapless Canadians.
So what is that all about? Well, I recall that, at least when I was doing post-graduate studies in sociology at McMaster University in Hamilton, Ontario, Canada, in the late '80s and early '90s, there was much discussion about how Canadians lacked a common identity--anything substantive that they cherished together as Canadians, especially beliefs and aspirations. A notion that was already well-established at the time was that whereas the United States of America had been a melting pot of immigrants who came from diverse backgrounds but ended up practicing the same culture, Canada was a mosaic. At first glance, the largest distinct pieces of the mosaic would be English Canadians and French Canadians, but I believe it is true that among French-speaking Canadians, there are at least two distinct identities, that of the Quebecois, and that of the Acadians. Frankly, among English-speaking Canadians, it really is hard to discern a common sense of identity among them at all, except perhaps that of being huddled in the cold North, away from "the Americans," and generally being open and accepting to everyone except pedophiles (or at least those that don't respond well to treatment). Even an interest in ice hockey is not a given. My wife, who is a native-born east-coast Canadian, whose Canadian heritage extends further back than anyone in her family knows, has never watched a complete hockey game in her life--because hockey is just not a big deal where she comes from. (Hunting is another matter, although she hasn't shot anything either, except perhaps me, a few times, in fond daydreams.)
Anyhow ... here we have a team focused on the problem of identity and a ridiculous preponderance of Canadians working on it--people who, historically and culturally, have none, and feel the lack of it.
|
-
That I am able to spend time blogging about Microsoft Identity Lifecycle Manager "2" has nothing to do with some scary marketing person suddenly declaring that we are allowed to talk about the product now, when we weren't able to before. We've been public about the product in general, and most of its intended features since we annouced it at the RSA Conference in San Francisco in 2007.
Rather, I have had blogging time recently because we now have no less than 138 test applications that have to be run before we can submit any code changes, and several of those test applications incorporate many individual tests--26 in the case of one of mine that I had occasion to spend a lot of time on over this past weekend. As a result they take a while to run, during which time, I can, say, write a blog post.
Actually, our rule is that we have to run the tests on an essentially clean machine. Such a machine does not have our source control client installed on it. We copy over the binaries from our development machines, (re-)install the product, copy over the test sources, and run the tests. When we are at that stage of testing, obviously, we can be more productive during the test runs, working on our development machines while the tests proceed on the clean machines. However, especially in the case of more complex changes, it is generally a good idea to run the tests, or at least the most pertinent subset of them, through on our development machines first, where we have more facilities for debugging if any of the tests fail. That's what's happening as I'm typing this entry--a large subset of the tests are ticking over on my development machine.
Naturally, now that we are approaching the completion of our release candidate, nothing is more important than avoiding regressions. So the development team has to take particular care not to introduce any new defects, and to endeavor to catch any issues before the next daily build goes to the test team.
Most of the developers are currently in the state of what we call "Zero Bug Bounce," or ZBB, which is reached when your list of bugs for the current release drops to zero. Inevitably, one is going to "bounce" up again as the test pass identifies more issues, but the idea is that once one has hit ZBB, the duration of each bounce will be briefer, and that bounces will soon be stopping. I hit ZBB myself for this milestone on Monday morning, then identified 4 new issues myself during the course of yesterday, plus one that got added by a test team member this morning. So my bug count is currently sitting at 5. I have made all the fixes, and I am waiting on the outcome of the aforementioned tests before distributing the changes for code review, and running the full suite of tests on my clean machine.
|
-
A previous post introduced you to Microsoft Identity Lifecycle Manager "2"'s concept of policy. We provide a user interface for managing and creating policies. Here are some screenshots stepping through the process of creating a policy to allow users to read any information about themselves (which may or may not be a policy that you would want to create).
This shows the list of all policies:
The first page of the policy wizard is shown here. On this page, one gives one's policy a name, and indicates whether or not this will be a policy that grants permissions:
On this page, I have indicated that I want to create a policy that applies to all full-time employees. That is, to everyone in the set of full-time employees. I have also said that my policy defines what those folk can read.
On this page, I express the idea that my policy allows full-time employees to read information about themselves, and I choose to say that I am allowing them to read any information about themselves, and not just the information contained in specific attributes:
This next page would allow me to trigger the execution of Windows Workflow Foundation workflows in response to requests covered by my policy:
The last page of the wizard summarizes the new policy that I am about to submit:
|
-
-
Goldfrapp played the Showbox SODO here in Seattle two weeks ago: their only general admission gig in North America on this leg of their tour. I showed up at 4:30 to secure a spot in the front row when they came on at 10.
I'd like to thank the the folk at the Showbox SODO for providing a great, welcoming venue for the fans. My wife and I were able to hang out in their newly-renovated lounge with other fans before the show, and were treated to a rare performance of Black Cherry during the sound-check, presumably as a rehearsal for the subsequent shows in Australia where that hallowed number was on the set list.
It was terrific to meet other hardcore fans from the Goldfrapp Message Board, which happens to be an unusually nice place to hang out on the 'net, so delightfully free of the vitriol that makes most other social gathering places on the Web a chafing bore. Josh snapped this excellent shot of Alison, who clearly enjoyed performing as much as we all did watching.
I'd also like to give a shout out to another fellow fan, John Roger Schofield, who is the bassist for Seattle indie rock group, The Myriad. Give them a listen, too.
|
-
Now that I have explained that the concept of organizing things into sets is the most fundamental idea in Microsoft Identity Lifecycle Manager "2," I can tell you about a notion that builds upon it: management policy rules. Now I have no idea why we use that wordy term, when the single word, policy, would do just as well. Perhaps it is because, in the ignominious tradition of such names as Windows Communication Foundation and Windows Presentation Foundation, we still believe that three words are better than one despite P-Diddy and J-Lo having firmly established that barely one word will usually do better than two. Anyhow, when we say, management policy rule, grit your teeth and think of policy.
A management policy rule is one of the various types of objects that is included by default in Microsoft Identity Lifecycle Manager "2." Like any other type of object, it has attributes. In particular, thanks to my colleague, Jack Kabat, who figured out how to make policies work, management policy rules have these attributes, among others:
- Principal Set
- Action Type
- Action Parameter
- Resource Current Set
- Resource Final Set
- Grant Right
- Authentication Workflow Definition
- Authorization Workflow Definition
- Action Workflow Definition
You will note that the term set appears several times in this list of attributes, which is why I need to introduce that concept before moving on to this topic. Together, these attributes define whether a request by someone to do something to an object is permissable, and, if it is permissable, what its consequences might be. How do those attributes accomplish that?
If you want to say what a particular set of users is allowed to do, or what the consequences of their actions might be, then you use the Principal Set attribute to identify that set of users. Every policy rule must define a set of principals, even if that is the built-in set of all objects, or the built-in set of all people.
The action type parameter specifies what action requested by a principal set is covered by the policy. Multiple actions might be identified. The possible actions are Create, Delete, Read, Add, Remove, and Modify, those being all of the things that one is allowed to do to an object, or an attribute of an object.
The action parameter attribute of a policy is a list of the attributes to be modified by a request covered by the policy. For example, if a policy has, as its principal set, everyone that reports to Henry, has Read as its action parameter, and Title and Salary as the value of the action parameter attribute, then it is a policy that says whether or not everyone that reports to Henry and read the title and salary attributes of certain objects.
The resource current set attribute identifies the set of objects that the set of principals might be requesting to perfom some operation upon. So, if I want to say that everyone who reports to Henry have the right to delete everyone who reports to Anne, then I express that in a policy that has the set of people who report to Henry as the principal set, and the set of people who report to Anne as the resource current set.
Now, when a request to perform some operation on an object is actually executed, that may result in the object joining or leaving a set. For example, if Joe reports to Anne, and Henry requests that Joe's manager attribute be changed from Anne to Peter, then Joe will leave the set of people who report to Anne when the request is executed, and join the set of people who report to Peter. Thus, for that request, the resource final set would be the set of people who report to Peter. The resource final set attribute of a policy allows one to say what may or may not be permitted depending on what the consequences might be.
The Grant Right attribute of a policy indicates whether, if this policy applies to a request, the policy grants the right for the request to be executed. This attribute allows us to have one policy that applies to the request that permits it, by virtue of having the Grant Right attribute set to true, and another policy that also applies to the request, but only defines the consequences that follow from the request being executed. The latter policy would have the Grant Right attribute set to false. Such a policy would not prohibit a request to which it applied, but in order for that request to be permitted, at least one other applicable policy would have to grant permission for the request to be executed.
The Authentication, Authorization and Action workflow definition attributes of a policy identify Windows Workflow Foundation workflow definitions that must be executed in response a request, if the request is permitted. Authentication, Authorization, and Action are the three phases of the Microsoft Identity Lifecycle Manager "2" request processing model. That processing model will be the subject of an upcoming post.
|
-
In an earlier post, I explained the crucial concept of organizing things into sets, in Microsoft Identity Lifecycle Manager "2." I wrote that sets are collections of things that match some criterion, expressed in an XPath expression. Well, because Microsoft Identity Lifecycle Manager "2" is meant to be used by anyone in an organization, we naturally don't require folk to have a knowledge of XPath in order to define a set. Consequently, we have provided a tool called the "Filter Builder," which provides a friendly user interface by which one can craft a filter, either to use in query, or to use in defining a set. I wrote the Filter Builder, as a matter of fact, from an excellent specification by my most excellent colleague, Bobby Gill. Come to think of it, I also wrote the initial specification of the XPath dialect that is generated by the Filter Builder, under the covers.
Here is a screenshot of the Filter Builder:
|
-
Here is the schema administration page that I mentioned in an earlier post:
|
-
Here is a screenshot of the Microsoft Identity Lifecycle Manager "2" home page:
|
-
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 ...
|
-
For almost two years, I have been part of the team developing Microsoft Identity Lifecycle Manager "2." I've been on that project almost from its inception, first as a program manager, and now as a developer. So I will devote a series of posts to telling you about the product, with the intention of providing a view of its innards.
Microsoft Identity Lifecycle Manager "2" provides these facilities:
- The synchronization of passwords, and data concerning users, groups and other types of entities, among the various data stores of an enterprise. This functionality was inherited from the legacy product, Microsoft Identity Integration Server 2003, and incorporated wholesale in Microsoft Identity Lifecycle Manager "2."
- Self-service smart card management. That functionality was inherited from a product that Microsoft purchased from Alacris, and released last year, along with an update to Microsoft Identity Integration Server, as Microsoft Identity Lifecycle Manager 2007.
- Self-service distribution list and security group management.
- Self-service personnel information management.
- Self-service password re-set.
The third beta was made available in July, and we are currently progressing toward a release candidate.
The most important concept in the product that of organizing things into sets. Hence, that will be the subject of my next post.
|
|
|
|
