All:
Pointer to Dave Kearns’ blog (couldn’t find URL pointing to this particular article, which appeared in Dave’s Network World Newsletter on Identity Management, October 19, 2005, and by the way Dave, thanks for pointing back to my blog…have you noticed that I’ve been slacking off in recent weeks in posting new stuff…thanks for your continued patronage everybody…and thanks for indulging my poetic musings… and how’s everything with you these days and….oh my gosh, this is going on too long and I need to launch into my kommentary while the thought is fresh so here’s the pointer to your site and by the way always love your stuff etc etc blah blah blah): http://vquill.com/
Kobielus kommentary:
I’ve glad that Dave cycled back to the discussion of what a role is. I’ve been storing up thoughts on roles like a squirrel his acorns. Dave’s search for an “ontology of identity management” resonates pretty strongly with me. I’m always searching for an ontology on every topic I encounter. The base bedrock simple powerful fundamental representation of the problem domain from which all more nuanced higher-level complex representations may be unfurled, and to which they may be reduced.
Anyway, here are those thoughts on roles. I’ll try to keep them succinct:
Role engineering is the black art of IdM. Almost every IdM project quickly launches a role-engineering exercise. Traditionally, roles have served as a convenient construct for simplifying assignment of permission sets to individual users, per their stable responsibilities/functions within an organization, process, or project. One of the primary benefits of roles—from an IdM/permission management standpoint—is that the privileges associated with a role can be managed in a single role object in the directory, without having to change the permissions of every single user (of which there could be thousands of users, each with myriad permissions) who belong to that role.
But role engineering is difficult to implement effectively. Partly that has to do with the fact that roles are sometimes difficult to generalize at an abstraction level sufficient to lump a significant number of like users together. When examining the diversity of real-world roles played by various individuals, one is sometimes tempted to create a unique role for each person (i.e., the “role of Jim,” encompassing the unique set of stuff that Jim does in our organization). Other problems with role engineering are that many people play many roles; that those roles are evolving continually; and those roles layer and interact with each other in diverse ways that are often specific to each individual.
Roles are multilayer constructs that are difficult to model clearly, and difficult to manage within an IdM user management environment. Per what Ed Zou of Bridgestream is quoted as saying in Kearns’ article: “Business units use [roles] to represent organization structure, responsibility, span of control and authority. For example, if Jane in the marketing department reports to the CEO, supports key sales initiatives at major accounts, manages three staff members, and participates in the revenue recognition team, she has four different business roles. Yet, most likely only two of these roles can be found in the directory: the direct reporting structure and the formal department that she belongs to. The other dimensions are difficult for directories to include and even harder to maintain. Her role changes and thus must be defined to be sensitive to business context, e.g., in-context roles."
Kearns ends his brief article with a call for new terms that the industry can use to describe this multi-level contextualization of roles. I’d like to propose just such a framework.
Essentially, a role is the contextual coordinate system within which an identity is described, qualified, characterized, and classified so that it can be managed effectively. In this regard, we can view any role as existing within a three-dimensional coordinate space:
• Place: This is the notion, highlighted above, of a role being defined in relation to the identity’s contextualization within a “direct reporting structure and formal department.” This is where “roles” and “groups” essentially overlap in semantic scope. For example, my role in Exostar is “senior technical systems analyst,” which is defined within the context of the “project office” which is defined within the context of the org supervised by the “chief technology officer,” which is defined with respect the entire org under the supervision and control of the “chief executive officer.” In this context, “place” simply refers to a standing persistent grouping of identities under an organization. A “project” (e.g., “revenue recognition team”) is another type of “place.”
• Process: This is role in the workflow context of somebody’s position in a flow of tasks, steps, documents, deliverables, etc. In the excerpt above, this corresponds to “supports key sales initiatives.” In that context, someone’s role may be “provides sales engineering support upon request” or whatever. In a document processing workflow, one’s role might be “document originator,” “document reviewer,” “document approver,” or so forth.
• Permission: This is role in the access control context: some stable grouping of permissions to access some set of apps, data, or other resources—a grouping that is associated with particular identities based on various criteria. Quite often, IdM professionals refer to role in this permission-management context. The NIST subject-object role model is built on it, as are the role-based access control features in many apps: read, write, modify, delete, append comments, and other privileges.
So, to sum up, the concept of roles may be applied in any or all of three management contexts:
• Place management
• Process management
• Permission management
Or, more succinctly: A role is an identity defined in its full governance context.
Just a little ol’ ontology I’ve been carrying in my head for a while. A kobelian coordinate system. Use it if you find a use. My ontology.
Jim
