Dots of Tech Perception

October 28, 2008

On Role Mining

The role mining problem is a wrong way to go when trying to solve the role definition problem. There is a need to distinguish between actual and potential/candidate roles.

  • The actual roles are a complete and definite set that have semantics in the considered organizational context.
  • The role mining problem will define a set of potential roles. We can only come with an incomplete solution to the role mining problem. By means of approximation and heuristic, we could find an almost optimal solution or one that works reasonably well, so a subset of the all the potential roles.
  • Whereas all the actual roles set are assumed to exist and be useful in an enterprise context from the set of candidate roles a overwhelming majority will be eliminated.

So instead of trying to find all roles, why not just redefine the problem and take into consideration the correct premises to derive the set of correct roles. It all comes in the end to the old saying, why buy the cow (i.e. define the set of ALL candidate roles) when you can have the milk for free (i.e. the actual roles)?

October 7, 2008

Roles for Provisioning

Roles can help simplify entitlement and user provisioning inside an organization. By using roles, the organization’s management can gain visibility into the entitlements allocated to users. Roles are also desirable to organizations wishing to deploy provisioning systems or to measure access compliance, because of their potential for improving security and control. Even if the advantages of using roles in an enterprise environment are acknowledged, no agreement exists on the theoretical definition of a role. From the perspective of role theory, roles are the culturally defined norms—rights, duties, expectations, and standards for behavior—associated with a given social position.

By extending this definition to an enterprise environment, roles can be defined as company specific norms (duties and responsibilities) associated with a given functional or organizational position. Hence, roles are defined by operational needs and functional constraints. Roles limit access to data and enable administration of user and entitlement objects. Roles can be used to describe a class of entitlements from a technical point of view. They are also used by business units to represent aspects of the organizational structure. Organizations often use the term role to cover both meanings, and then it becomes immediately very difficult to define roles. That is why, in the context of role definition for provisioning, we will use two types of roles: business roles and technical roles.

A business role (organizational or structural role) is an articulation of a business responsibility required to perform a job function. A business role is a named collection of business functions (duties or responsibilities) that can be performed by users in an organization. Business roles are derived from operational procedures and policies. They are created and managed by business users, such as managers and team leaders. A business role can be either static or dynamic. Dynamic business roles depend on rules to determine role-to-user assignment. Allocation rules define who must be assigned to a particular role and under what circumstances. For example, a business unit manager, John, can create a rule to grant the business role, Statistician, to all active users in the Statistics department who have the job description Statistician. All users in the selected department who meet the condition described by this rule are automatically added to the list of users of the Statistician role. Automatically entitling users to business roles is based on data available from human resources target systems. When attribute values that control automated assigned roles change, user assignments to roles will change. Static business roles assign roles through manual-requests. Unlike dynamic business roles, that rely on rules, static business roles must be requested manually for each individual user that is entitled to the specific role. For example, consider the static business role “mission travel”. John, a manager, decides to assign this role to his employee Jane who is traveling on a mission to Europe. John must manually request this role for Jane. Ideally, when Jane comes back from the mission, John should not have to manually revoke the role from Jane. The role definition should consider environmental attributes (e.g., role duration), and the role assignment should automatically be revoked when a given condition (e.g., role duration is less than 3 months) is satisfied.

A technical role (IT or functional role) is a named collection of entitlements and can be mapped to business roles in order to assign users to a set of entitlements. Suppose that Jane is a new employee in the Statistics Department of Mother Organization and that among her main responsibilities is data dissemination to partner organizations. Then John, Jane’s
manager, should give her access to the Data Dissemination business role. The data dissemination role is further divided into the technical roles Dissemination Access to Partner
Organization 2 and Dissemination Access to Partner Organization 1, depending on the information system used for exchange between Mother Organization and the Partner
Organizations. In other words, the technical role Data Dissemination to Partner Organization 1 is a collection of entitlements: Create New Data Set, Publish Data Set and See Reports of
Published Data on a specific target system used for data exchange between Partner Organization 1 and Mother Organization. Technical roles can be refined based on target systems (e.g., various exchange systems between organizations), based on various levels of security within the same target system, or based on user attributes.

The industry is split into two camps when it comes to role definition: the pragmatic one thinking that there is no need for multiple categories of roles, (Courion, 2007) and the more academic one believing that there is a need for distinction (Eurekify Ltd, 2008). I am in the latter camp and think that business and technical roles have practical applications.
There is an immediate and urgent need for role-based provisioning, which may not involve role types. However, using the business and technical role types generates options for additional uses of each type within and outside the span of provisioning. More this differentiation induces the necessary level of abstraction between technical and business organizational levels. The main argument in favor of using role types, is that they make role-based provisioning easier to understand over time. Hence, the distinction between business and technical helps role maintenance. One additional argument in favor of the separation between business and technical roles is that it allows implementation of management and security controls, such as:

  • all business roles must be approved by the personnel administrative department
  • all business roles must be approved and activated by business units managers
  • only business roles can be directly assigned to users upon manual-request
  • business roles can only contain other roles, and not direct entitlements
  • technical roles can only be approved by resource owners

Blog at WordPress.com.