§ May 31st, 2006 § Filed under Identity Comments Off
A new political movement, dubbed Unity08, has been started to target Republican and Democratic moderates repelled by the polarizing political climate we find ourselves in. It’s an intriguing idea, but alas this is not a political blog, so I’ll leave it to others to comment on the politics of it all. What interested me was the second of Unity08’s three goals:
Goal Two is for the people themselves to pick that Unity Ticket in the first half of 2008 – via a virtual and secure online convention in which all American voters will be qualified to vote.
They are planning to utilize e-voting on a national scale! Granted, this is not a government election, but given that the results would likely end up in the courts if in dispute, it still must be beyond reproach. Voters will need to be registered online, their registration information independently validated, and their identities securely authenticated. The ballots will need to be auditable and non-repudiatable. Unity08 is hoping for 20 million voters to support their candidate, so this will be no small task!
E-voting has been in use in Europe on a small scale, but to my knowledge nothing has been attempted of this scale before. I wonder whether the Unity08 founders appreciate the identity management challenge they will be facing.
I suppose they can avoid some of the complexity by dumbing the whole thing down so that it is closer to voting for American Idol, or an election in Florida, rather than a certified one-vote-per-voter election. But I hope they don’t. I would love to see someone tackle these tough challenges and pull off a national e-vote in the U.S. It could change the face of democracy forever.
A simple explanation for my lack of blogging — Novell, or at least my little corner of Novell, has been extremely busy. And busy is good. I have been doing a lot of consulting work around RBAC and role definition, and will share some of our learnings in this and a few future posts.
The whole role definition problem in RBAC actually has two aspects: 1) determining the entitlements that belong in a role, and 2) defining a set of rules for assigning identities memberships in a role. Both pieces of the problem have to be solved simultaneously to come up with a useful set of roles, but the first seems to get more of the mindshare. But for now, let me address the second.
Without role membership rules that can be automated, we are left manually assigning users to roles. RBAC is still valuable in this scenario, since we are manually provisioning bundles of entitlements instead of individual entitlements. More importantly, we are codifying a set of access policies in the form of the role construct. But we are missing out on a significant cost reduction and risk mitigation opportuniity if we don’t specify role membership rules. These rules automate provisioning in the RBAC world, and codify a second set of security policies at the same time — which employees are supposed to get access to what.
The problem is that the correlation between identity attributes (normally sourced from the HRIS) and the “to-be” role memberships is often pretty weak. We have begun using two metrics to measure the “fit” of proposed membership rules to roles. The first is coverage, which represents the amount of the desired role population that can be identified by a set of membership rules.
A proposed set of rules for role membership, based on identity attributes, will provide a set of true positives, i.e. a set of identities that are correctly specified as members of a role. But the rules may also specify a set of false positives, or a set of identities that the rules indicate should be placed in the role, but in fact have no need for the entitlements contained in the role. The rules may miss some identities that should get the role but don’t — these are false negatives. Then there are the identities that don’t get the role, and shouldn’t, i.e. the true negatives.
Coverage is the ratio between the number of users correctly identified by the membership rules and the total number of users that should get the role:
coverage = true positives/(true positives + false negatives)
It’s nice if coverage is 100%, but anything above zero is a good thing, since it represents provisioning that can be automated.
The second metric is accuracy, which represents the percentage of identities specified by the membership rules that truly should get the role:
accuracy = true positives/(true positives + false positives)
An accuracy less than 100% is more problematic than a coverage less than 100%, since any false positives represent a violation of the least privileges principle. Still, a set of rules that include errors may be of value. Identities that are identified by these membership rules can have an automated provisioning workflow request created which can then be sent off for approval. The approver must sift out those that really need the role and those that don’t. However, since the request is created automatically, no one has to remember to create the request, and the cycle time will be shorter than in an entirely manual process.
So accuracy and coverage have become our key metrics for deciding to what extent we can automate the placing of identities in roles. Feedback is welcome!