A Discussion of Computed, Explicit, and Temporal Sets in Microsoft Identity Lifecycle Manager "2"

I would like to take a short detour from my current discussion of the Microsoft Identity Lifecycle Manager "2" Policy Service to focus on a particularly important concept within the Microsoft Identity Lifecycle Manager "2" platform:  set membership.  I have answered a number of questions from people regarding types of set membership in Microsoft Identity Lifecycle Manager "2".  Often these questions start off discussing something other than set membership, but quickly come down to correcting misunderstandings about set memberships.

Let me start with a quick definition of a Set.  As I mentioned in previous posts about the Microsoft Identity Lifecycle Manager "2" platform, the Policy Service component is responsible for managing the lifecycle or "Resources".  "Resources" are just a collection of data described by a schema.  Within Microsoft Identity Lifecycle Manager "2" there are a number of these "Resources" that describe metadata that helps to drive the Policy Service itself.  One of these metadata "Resources" is an object type called Set which allows the grouping of other "Resources" that meet share criteria.  The criteria used to group "Resources" within a Set can be described as a membership condition and Microsoft Identity Lifecycle Manager "2" supports different types of set membership.

To try and keep this discussion short (for a change), let me identify four types of set membership:

1. Explicit Membership – Membership of the set is explicitly managed with requests to insert and remove members directly.
2. Computed Membership – Membership of the set is computed based on a filter.  This results in implicitly managed membership by requests modifying data within the system which results in objects transitioning into or out of the target set.
3. Temporal Membership - Membership of the set is computed based on a filter that includes at least one time based criteria.  This results in implicitly managed membership similar to Computed Membership but also includes transitions triggered simply by the passage of time.
4. Parameterized Membership – Membership of the set is computed based on both a filter and some parameters provided by the client requesting membership.  This results in a fluid set membership that differs not only as data within the system changes, but also depending on whom tries to access the membership.

Microsoft Identity Lifecycle Manager "2" supports the first three but not the last one.  I would further argue that the last one actually results in undesirable behavior.  Since the set membership changes depending on who accesses the membership it becomes difficult to audit membership at any given time.  Performing actions based on this type of membership quickly becomes problematic and difficult to predict consistent results.  Some very specific scenarios exist where it seems Parameterized Membership is needed.  These scenarios center around capturing relationships.  Granting rights to read specific, sensitive attributes on Person resources to a specific person's manager.  Asking a group's owner to approve a request to join that group.  Creating a group of Person resources that reside in the same cost center.

While Microsoft Identity Lifecycle Manager "2" does not support Parameterized Membership, it does understand the need to evaluate relationships in a manner to address these (and other) scenarios.  In most (if not all) cases, these relationship based evaluations can be accomplished with three features:

1. "Reflexive Rights" - The ManagementPolicyRule (MPR) is responsible for controlling the Policy Service's request processing.  It allows enterprises to define the policy for how resources are managed including granting rights.  Rights are granted to a set of principals against a resources that start in an initial set and, as a result of the operation, end in a final set.  While each of these sets can contain one of the three supported memberships described above, they each also allow for a "reflexive" description.  The principals may be described by an attribute relative to the target of the operation.  Further the initial and final resource sets can be described by an attribute relative to the current actor.  This allows the first scenario above of granting rights to read attributes on a Person resource to a specific person's manager.  I will provide more details on MPRs in later posts.
2. "Lookup Grammar" - The Windows Workflow Foundation integration includes the ability for activities to resolve a lookup grammar to reference relationships appropriate for the current executing request.  Some of the WF activities that ship with Microsoft Identity Lifecycle Manager "2" include this integration.  One example is the ApprovalActivity that is responsible for gating requests on the acknowledgement of a set of approvers.  Using the "Lookup Grammar" feature it is possible to identify a group's owner as an approver for operations that target that group, such as requests to join.  In this particular case, an ApprovalActivity would be configured to have the approver "[//Target/Owner]".  As I dive deeper into the Windows Workflow Foundation integration and authoring of custom activities and workflows I will provide more information on the "Lookup Grammar".
3. Custom Activities - The Windows Workflow Foundation integration allows for enterprises to write their own custom activities that can be executed within the Microsoft Identity Lifecycle Manager "2" Policy Service.  This essentially allows enterprises to introduce their own custom code into how the Policy Service manages resources.  In the final example of relationship based grouping, the custom activities feature would allow enterprises to write a custom Windows Workflow Foundation activity (or custom workflow) that can detect the addition of a new Cost Center.  Upon finding a new Cost Center, the activity can simply create a new group (or set) that uses Calculated Membership to include all Person resources that are part of that Cost Center.

I know this has been a brief discussion of set membership within Microsoft Identity Lifecycle Manager "2".  Sets are a core part of the Policy Service platform, and understanding membership of those sets is the basis of being able to successfully map specific solutions onto that platform.  I hope this has provided a primer into understanding the types of memberships supported by Microsoft Identity Lifecycle Manager "2".  I have a feeling I will be revisiting this topic more than once to dive deeper into the specifics of each type of membership.  I will definitely touch base on the appropriate membership types when I start providing How-To posts for specific scenarios.

Next Week:  AuthN, AuthZ, and Action, oh my:  Microsoft Identity Lifecycle Manager "2" Request Processing

Comments

• Anonymous
  July 16, 2008
  I understand your concern for Parameterized Membership.  But as you say, their may be many types of situations where outside parameters are necessary to define a sets members. In the enterprise space, we are all "members" of dynamically created/destroyed "sets".   These relationships, or the authority implicit to membership in these sets isn't typically reflected by our groupings in Active Directory.   So if an organization needed to provide authority for anyone who was invited to the "Be nice to animals" committee meeting, wouldn't it be cool to be able to define a set's members that way? While organizations still have their hard coded hierarchies, there's a lot more fluid empowerment and providing for that in the identity platform is really cool. Now, I think you've hit on the key for this, that being audit.  Any set created with outside parameters would require audit of the parameters used and their values.   Fun stuff!   Jeff

• Anonymous
  July 17, 2008
  Just to be clear, the scenario you mention is supported by ILM "2" and does not require parameterized membership.  First, let me state that I am assuming you have represented the invitation to the "Be nice to animals" committee meeting inside of ILM "2" (otherwise not even parameterized membership would help).  Depending on how the "Be nice to animals" committee meeting attendance is stored this can be accomplished with either a dynamic membership (/Committee[DisplayName='Be nice to animals']/MeetingAttendees) or with a dynamically managed static membership (MPR includes an Action workflow whenever an attendee is added to the meeting that adds that person to the ExplicitMember attribute of a set).  In either case you do not need parameterized membership. Parameterized membership really comes down to reusing a single Set to contain multiple memberships depending on some external context.  In other words, the Set contains no members until evaluated since it requires that external context to calculate its membership.  Because of that you could never audit how a resource became a member since it never really is a member (except for the split second that the membership is evaluated). Again, I ask for some patience as I continue to peel back the onion here.  After providing some background on the request processing pipeline I will introduce the resource that controls request processing within the ILM "2" Policy Service: the ManagementPolicyRule (MPR).  This resource makes heavy use of sets and, so, I will provide more details on how Sets work within ILM "2".

• Anonymous
  August 21, 2008
  Well a "short break" turned into something a bit longer than I anticipated.  My laptop