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:
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:
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