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 10, 2008

Provisioning – A Definition

Filed under: provisioning,role definition — GG @ 3:25 am

In an enterprise environment, provisioning mechanisms are used to ensure that users have access only to the entitlements that they need in order to perform the responsibilities assigned to them throughout their full life-cycle (i.e., employment to separation). Provisioning mechanisms attempt to automate the previously manual responsibilities of the human resources and information technology departments. More formally, provisioning can be viewed as all the life-cycle steps required to setup, maintain and terminate user access to a directory and a data target systems.

The life-cycles to be defined in order to assign users to the required level of access depend on the chosen provisioning model (e.g., rule-based provisioning, role-based provisioning). Role-based provisioning – provisioning based on roles that users can play in an enterprise environment (e.g., team leader role, division manager role). Role-based provisioning can be viewed in terms of three life cycles: user life-cycle, role life-cycle and entitlement life-cycle.

The entitlement life-cycle uses entitlement objects as abstractions of privileges that are currently held by users. An entitlement object instance can be approved or pending approval, fulfilled /active or pending fulfillment/activation, removed or pending removal. Pending entitlement objects may also represent privileges to be added to a user, privileges to be removed or changes in the configuration of a current privilege.  The role life-cycle uses abstract role objects. Roles dictate what electronic access and physical assets are to be provided to a user, either automatically or manually, and how each entitlement is to be encapsulated in a role. Roles can be in the same states as the entitlements.  The user life-cycle defines user objects as abstractions of users that are hired, transferred, promoted, leaving on vacation and/or separated (i.e., leave the organization). User object entities are the current users with their organizational responsibilities and duties, function, rank, location and other attributes (e.g., visa status, location). User objects may represent employees, contractors, vendors, partners, customers or other types of employment in the considered organization. An implementation of a user object can be represented on target systems by authentication credentials or user profile attributes.

The consolidated user attributes in a provisioning system contains logically integrated user, role and entitlement object instances. Entitlement and role objects cannot exist in a provisioning system without a user object but user objects can exist without role and entitlement objects. Any of the above life-cycles are triggered when user attributes are changed due to transfers or separations or when data for a new user is detected. A change in a user object instance will trigger a role or entitlement life-cycle task.

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.