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