Alrighty then – let’s talk roles.

In my post on user context decisions in the Enterprise, I built on a foundation that perhaps should have been better defined before drawing conclusions. A few people noticed it, and I think they make great points — so let’s step away from the fancy schmancy terms and look at [my conception of] the underlying issue.

Here is my problem with current technical definitions/applications of roles. In most organization, roles are expected to be true of a given person 100% of the time. Jenny is *always* a “production accountant level II” if that role is present in her profile.

Roles are indeed in the domain of the “identity weenie” — but alone, roles are nothing but a maintenance nightmare – they exist to be leveraged. Rules on the other hand, are the problem of the “authorization weenie” and are written (for example) as a WAM policy that says “All Production Accountant Level II resources can access the accounting SharePoint instance”. When you collect roles into a profile and collect rules into a policy and then evaluate for a given user, resource, and point in time, what you eventually get is an entitlement, ie “Jenny should get into the accounting SharePoint instance”. The goal is to have transitive logic between roles and rules, such that two different people can take on the two different statements being made. Jenny’s Manager can authoritatively state (through a workflow approval) that Jenny is indeed a production accountant. The owner of the Accounting Sharepoint instance can authoritatively state (through an authorization policy) that all production accountants should have access to their site.

This is, of course, just my interpretation of the verbage. Heaven knows there are many many other interpretations out there, I could be waay behind the times. Still, the basic logic I’ve just outlined forms (I believe) a simplistic basis for most identity projects out there. All of it is based on the idea that whatever set of roles are present for a given account at a given time are all simultaneously true.

What happens when the system detects the static presence of two conflicting roles? What happens if one role is “truer” than another at some point in time?

There is no simple way to say that John is a broker 100% of the time, but 50% of the time he represents Client A and only Client A, and the other 50% he solely represents Client B. There is no way to represent mutual exclusivity of roles in a single user profile (that I’m aware of).

In the case where two roles are assigned to the same person, but should never be simultaneously applicable, Enterprises have limited choices. If, however, there is a layer in between the consumer and the provider that lets you mask roles based on user-chosen context, in my mind this problem goes away. I don’t see how you can do it without the user part — but perhaps I’m just not thinking hard enough :)

I hope I’ve now managed to dig myself in sufficiently deep that pretty well anyone will be able to take potshots — have fun :)

2 thoughts on “Alrighty then – let’s talk roles.

  1. Pingback: Links » Conflicting Roles

Comments are closed.