Using Venn Diagrams for Role-Based Provisioning
Novell Cool Solutions: Feature
By David Guest
Digg This -
Posted: 19 May 2005
"A great primer on how to define roles in an organization - a necessary step for any successful identity management implementation. Thumbs up!
Role based provisioning has formed an increasingly large part of Identity Management. Here identities are created in a number of distinct locations based on the roles associated with that user. However, roles should not exist just for provisioning of identity; they can also be used to define the applications a user should automatically receive, the data areas a user should have access to, and the groups (logical or physical) that the user should be a member of.
Much of this can be seen as provisioning, whether it is the actual creation of an identity within an application identity store or, the provision of application software to the user workstation. But the process of identifying the memberships of the roles has been a source of contention for some time. This article proposes the use of Venn Diagrams to ease the process of defining the role membership.
About Venn Diagrams
Venn diagrams have been used since 1880 to define the relationship between entities that form part of a set. The theory by J. Venn was originally entitled "On the diagrammatic and mechanical representation of propositions and reasonings" and was published by The London, Edinburgh, and Dublin Philosophical Magazine and Journal of Science. For many of us, it has been quite some time since we studied Venn diagrams at school, so a simple illustration may help to remind us what they look like.
Figure 1 - Sample Venn diagram
Here we can see the interaction between three sets - A, B and C. We can see that the placement of an item within the sets relates to the item's characteristics. Although relatively simple, this same criteria can be used to identify the roles (sets) where a user would exist.
To work out roles, we should look at the largest obvious group identities within an organization - everyone. This can then be represented as a set.
Figure 2 - Employee set
This simple diagram shows that the employees of the organisation are not all of the people, this is by design as there may be external users who need system access and should be represented, even though at this early stage they are not really being considered. To this diagram we must then look for the next obvious set of people.
At each stage of the definition process it is necessary to consider the largest sets first. Here we are examining a fictitious company where we already have defined a set of employees. The next set we will consider is e-mail users. In this organization, not every company employee has an e-mail address, so the number of people in the set is less than the complete set of employees.
Figure 3 - E-mail user set
Staying with the application information, we can define the number of users who need secure access to the Intranet and those who need the standard Office Applications. The users who require secure access to the Intranet is a larger selection than those who use e-mail, while the office-based application users are a subset of the e-mail users. This is shown below.
Figure 4 - Sets of various users, no spanning
This is still a relatively simple diagram that deals only with subsets of existing data and does not include sets that span other sets.
Additional sets can be added to the diagram to show the interaction between other types of roles. An example of this may be building access. If this company is based across multiple locations, these can also be added to the set diagram.
Figure 5 - User sets, with spanning
This diagram shows that users in Location 1 may have access to a number of the other sets. So a user based in Location 1 may be an e-mail user, an Intranet user, or an office application user.
The process of refining the sets should now be continued for a reasonable number of definitions. For some organizations, the possible number of roles could exceed the total number of users, but to make a start on this process at least 10-15 sets should be defined.
Once these have been completed they can be put into practice. This does not mean that the defining should stop at this point. The subsequent phase of definition may be started to further refine the internal model, increasing its scope to cover 30, 40, or even more roles.
Once the sets have been identified, the business or provisioning rules that apply to them must be defined. This can be a complex procedure, normally complicated by not having a definition of the actual requirements of the set. However, using this method of set identification effectively defines the actual use of the set. Also, the Legend can be used to show which sets require definition.
Figure 6 - Legend for defining sets
From this Legend, there are 6 sets to be defined. They are specifically identified so as to simplify the actual provisioning information required.
Who Goes Where
In addition to defining the rules used to identify the actual sets, it is also necessary to identify who should fit into which set. This should be done by identifying the common characteristics of those users who are already in the set, or sometimes those users who are outside of the set. These business rules can then be used to ensure that the provisioning required takes place correctly.
By using the Venn diagram method to assist in identifying the members of a set and the rules defining the makeup of a set, the provisioning exercise can be simplified. This simplification should ensure that the implementation of an identity management or provisioning solution can be accelerated.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com