BACKGROUND OF THE INVENTION 
       [0001]    1. Field of the Invention 
         [0002]    The present invention relates generally to an improved data processing system, and in particular, to a computer implemented method and apparatus for role based access control. Still more particularly, the present invention is related to a computer implemented method and apparatus for automatic activation of roles in a role based access control system. 
         [0003]    2. Description of the Related Art 
         [0004]    Several kinds of security measures are implemented in data processing systems for preventing unauthorized access to data, applications, or other information. One of the security measures pertains to allowing only users with proper authority to run certain applications or execute certain commands. 
         [0005]    In a data processing system, the abilities of users are determined by the roles assigned to the users. A user can be assigned multiple roles. The data processing system evaluates a user&#39;s roles in order to determine the authority of the user for performing certain functions. For example, one user may be assigned the role of system administrator, and another user may be assigned a guest role. The data processing system will allow the user with a system administrator role to open operating system files and manipulate roles of other users. In this sense, the data processing system will allow broader access to the user with the system administrator role. On the other hand, the data processing system may only allow the user with the guest role to access public information and access to the Internet, but no access to operating system files or any applications that manipulate roles of other users. 
         [0006]    Other roles can be created as needed in a particular data processing system. For example, all users have at least a role of “user”, which implies that the user is an authorized user of the data processing system and has some access to the applications and commands available in the data processing system. 
         [0007]    A user may be assigned multiple roles. The user may assume one of the assigned roles when needed, such as to perform a task, run an application, or execute a certain command. Role activation is the assumption of an assigned role and is required before the user can perform the task, run the application, or execute the command. 
       SUMMARY OF THE INVENTION 
       [0008]    Illustrative embodiments provide a computer implemented method, apparatus, and computer usable program product for automatically activating roles for a user. When a user initiates an action, a set of roles needed for the action is identified. A set of roles assigned to the user is also identified. A subset of roles that includes all roles common to the two sets of roles is identified. A role from this subset of roles is automatically activated without requiring any user input to activate the role. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0009]    The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein: 
           [0010]      FIG. 1  is a block diagram of a data processing system in accordance with an illustrative embodiment; 
           [0011]      FIG. 2  is a block diagram of software components in a data processing system is shown in accordance with an illustrative embodiment; 
           [0012]      FIG. 3  is a flowchart of the process for automatic role activation for a user in accordance with an illustrative embodiment; and 
           [0013]      FIG. 4  is a flowchart of a process for selecting the role for automatic activation in accordance with an illustrative embodiment. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
       [0014]    With reference now to the figures and in particular with reference to  FIG. 1 , a block diagram of a data processing system is depicted in accordance with an advantageous embodiment of the present invention. In this illustrative example, data processing system  100  includes communications fabric  102 , which provides communications between processor unit  104 , memory  106 , persistent storage  108 , communications unit  110 , I/O unit  112 , and display  114 . 
         [0015]    Processor unit  104  serves to execute instructions for software that may be loaded into memory  106 . Processor unit  104  may be a set of one or more processors or may be a multi-processor core, depending on the particular implementation. Further processor unit  206  may be implemented using one or more heterogeneous processor systems in which a main processor is present with secondary processors on a single chip. Memory  106 , in these examples, may be, for example, a random access memory. Persistent storage  108  may take various forms depending on the particular implementation. For example, persistent storage  108  may be, for example, a hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above. 
         [0016]    Communications unit  110 , in these examples, provides for communications with other data processing systems or devices. In these examples, communications unit  110  is a network interface card. I/O unit  112  allows for input and output of data with other devices that may be connected to data processing system  100 . For example, I/O unit  112  may provide a connection for user input though a keyboard and mouse. Further, I/O unit  112  may send output to a printer. Display  114  provides a mechanism to display information to a user. 
         [0017]    Instructions for the operating system, the object-oriented programming system, and applications or programs are located on persistent storage  108 . These instructions may be loaded into memory  106  for execution by processor unit  104 . The processes of the different embodiments may be performed by processor unit  104  using computer implemented instructions, which may be located in a memory, such as memory  106 . 
         [0018]      FIG. 1  is intended as an example, and not as an architectural limitation for different embodiments. The hardware in  FIG. 1  may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash memory, equivalent non-volatile memory, or optical disk drives and the like, may be used in addition to or in place of the hardware depicted in  FIG. 1 . In addition, the processes of the illustrative embodiments may be applied to a multiprocessor data processing system. 
         [0019]    In some illustrative examples, data processing system  100  may be a personal digital assistant (PDA), which is generally configured with flash memory to provide non-volatile memory for storing operating system files and/or user-generated data. A bus system may be comprised of one or more buses, such as a system bus, an I/O bus and a PCI bus. Of course, the bus system may be implemented using any type of communications fabric or architecture that provides for a transfer of data between different components or devices attached to the fabric or architecture. A communications unit may include one or more devices used to transmit and receive data, such as a modem or a network adapter. A memory may be, for example, main memory  106  or a cache such as found in a north bridge, which is a memory controller hub that controls the communication between the random access memory, graphics processor, PCI bus, and the processor. A processing unit may include one or more processors or central processing units (CPUs). The depicted examples in  FIG. 1  and above-described examples are not meant to imply architectural limitations. For example, data processing system  100  also may be a tablet computer, a laptop computer, or a telephone device. 
         [0020]    Presently, a user is responsible for knowing which roles are needed for a particular user action. The user is also responsible for activating the appropriate roles, in the correct order and in a timely manner, for the user action to complete successfully. Alternatively, a system administrator is sometimes responsible for the selection and activation of the roles for a user. 
         [0021]    Illustrative embodiments recognize that such user and administrator dependent activation is a time consuming and error prone process. The time consumed by a user in selecting and activating roles is generally longer than the time needed to perform these actions by an automatic process. Further, illustrative embodiments also recognize that the user based selection and activation can result in the activation of incorrect roles. Incorrect role activation can result in the failure of a user action. Incorrect role activation can also open unnecessary access for malicious or unintended actions in the data processing system. 
         [0022]    Illustrative embodiments provide a method, apparatus, and computer usable program product for automatic role activation to overcome the problems recognized above. Automatic role activation according to the illustrative embodiments is faster and more accurate that role activation by the user or administrator. Automatic role activation also reduces the possibility of human errors such as incorrect role activation or accidental role activation. Therefore, automatic role activation is useful in preventing malicious and unintended actions in the data processing system. 
         [0023]    With reference now to  FIG. 2 , a block diagram of software components in a data processing system, such as data processing system  100  in  FIG. 1 , is shown in accordance with an illustrative embodiment. Operating system kernel  202  is an essential component of an operating system that provides support for core operating system services, such as input/output access and task scheduling. 
         [0024]    Users-and-roles database  204  is a listing of one or more authorized users on a data processing system, and their assigned roles. Commands-roles-and privileges database  206  is a listing of the various commands available on the data processing system, the roles required to execute those commands, and privileges under which those commands execute. Roles and privileges are described in further detail in the following paragraph. In a given data processing system, databases  204  and  206  can exist in the form of flat files, encrypted files, tables in a database, or other forms usable by the operating system used in the data processing system. 
         [0025]    A user is identified by a user identification known as user ID. A privilege is a low level permission required to perform a privileged operation in an operating system kernel. An example of privileged operation is the modification of system time. Privileges are used to override security restrictions in the operating system kernel. Some examples of privileges are, ability to change ownership of any file on the file system, ability to configure network adapters, and ability to load kernel extensions. A process including any of these operations must have the corresponding privilege. 
         [0026]    A command may perform certain privileged operations. The operating system may require certain privileges to be available in the process that is trying to execute the command. Based on the role of the user who is executing the command, certain privileges are assigned to the command. For example, assume that a role A can be used to control the execution of command A and command B. Command A running under role A could require a privilege A, but a command B running under role A could require privilege B as well as privilege C. 
         [0027]    A user has roles, and a command requires privileges to run. A user starts a process when the user executes a command with an appropriate role activated. The command then runs under the process with appropriate privilege from the activated role. 
         [0028]    Each of applications  208 - 210  can be a software application that requires a user to have certain roles before the user can run the application. For example, one such application can be a database application that accesses confidential financial information of a company&#39;s customers, which requires that the user trying to access the database have a customer service role. 
         [0029]    Any number of applications, such as applications  208 - 210 , can be loaded on the data processing system. Furthermore, an application can be a component of the operating system in which the application is used for performing an operating system specific function such as user administration. Each of the software components depicted in  FIG. 2  can be loaded into a storage device, such as, for example, main memory  106  in  FIG. 1 , persistent storage  108  in  FIG. 1 , an on-board cache of processor unit  104  in  FIG. 1 , or a combination of the these storage devices. The software components may be loaded onto other types of storage devices in other implementations. Furthermore, additional software components may be loaded in a data processing system, but are not shown in  FIG. 2  for the sake of clarity. 
         [0030]    With reference now to  FIG. 3 , a flowchart of the process for automatic role activation for a user is depicted in accordance with an illustrative embodiment. The process can be implemented in a software application, such as application  208  in  FIG. 2 , which can be loaded in the main memory of a data processing system, such as main memory  106  in  FIG. 1 . 
         [0031]    The process begins by receiving a user action for executing a command, running an application, or performing a task, that requires a specific role to be activated (step  302 ). These types of user actions are collectively referred to as user action here. Activation of a role is the process of enabling a role that is already assigned to the user for completing a user action. 
         [0032]    The process checks the database containing the correlation of various commands, roles, and privileges, such as commands-roles-and-privileges database  206  in  FIG. 2 , to identify the various roles that are authorized for the user action (step  304 ). Next, the process checks the database containing the correlation of users and their roles, such as users-and-roles database  204  in  FIG. 2 , to determine if the user is assigned any of the roles identified in step  304  (step  306 ). 
         [0033]    Next, the process identifies the roles that are common to the roles identified for the action and the roles identified as being assigned to the user (step  308 ). One or more roles may be common to the roles identified in steps  304  and  306 , resulting in a set of common roles. This set of common roles contains one or more roles and is the subset of roles that are assigned to the user, and that are sufficient for completing the user action. Any one or more of these common roles, when activated by the process, will allow the user to complete the user action. The process of determining which of these common roles to activate is described in  FIG. 4  below. 
         [0034]    Once the set of common roles is identified in step  308 , one or more common roles from the set are activated for the user (step  310 ). The process ends thereafter. 
         [0035]    Once activated, a role can remain active for subsequent user actions that also require that role to be active. These subsequent user actions may or may not be the same action that first activated the role. 
         [0036]    Furthermore, once activated, a role can remain active for the duration of a user session even if the process that first caused the role to be activated terminates. A user session is a series of activities that a user can perform on a data processing system once the data processing system has granted access to the user, without requiring further grant of access to the user. Once a user session ends, the user typically has to be granted a new access before the user can perform any activities on the data processing system. An example of a user session is a computer login using a login identification and password. During a user session, a user may execute several commands, each of which may require certain roles to be activated. An implementation of automatic role activation may provide that if a role is activated for one command, and the role is also required by another command, the role need not be activated a second time for all or part of the user session. 
         [0037]    With reference now to  FIG. 4 , a flowchart of a process for selecting the role for automatic activation is depicted in accordance with an illustrative embodiment. The process begins by receiving a set of roles that have been identified (step  402 ). This set of roles in step  402  is identified by a process, such as the process in  FIG. 3 . The set roles are one or more roles that are common between each role assigned to the user and each role required to complete the user action. 
         [0038]    The process determines which role to activate based on activation rule (step  404 ). One exemplary activation rule can result in activation of the first role in the set (“first role” path of step  404 ). The process activates the first role from the set of common roles and terminates thereafter (step  406 ). 
         [0039]    Alternatively, another exemplary activation rule can result in activation of all roles in the set (“all roles” path of step  404 ). The process activates all roles from the set of common roles and terminates thereafter (step  408 ). 
         [0040]    Alternatively, another exemplary activation rule can apply a system policy in determining which roles should be activated (“policy” path of step  404 ). For example, a system policy may be that the user must have been assigned all the roles that can execute a command, and not just one of those roles, and that all such roles must be activated for the user before the user can execute that command. The process activates appropriate roles from the set of common roles as determined by the system policy and terminates thereafter (step  410 ). 
         [0041]    A system policy can also be that a role B cannot be activated if role A is already active. This particular system policy is referred to as dynamic separation of duties (DSD). Thus, the illustrative embodiments can be used for enforcing dynamic separation of duties as well. 
         [0042]    System policies described above are only described as illustrative examples and are not intended to be limiting on the illustrative embodiment. Additionally, these methods of selecting roles for automatic activation are also exemplary and not limiting on the illustrative embodiments. Other examples of system policies and many more methods of selection will become apparent to those of ordinary skill in the art from this disclosure. 
         [0043]    Thus, the illustrative embodiments describe a method and system by which appropriate roles can be selected and automatically activated for a user. In the manner described above, the role activation process becomes transparent to the user. The method and system of the illustrative embodiments remove the need for the user or someone else, such as a system administrator, to select and activate the needed roles so that the user can perform the user action. 
         [0044]    The automation of role identification and activation make the overall execution of the user action faster and less prone to errors caused by incorrect role activation. The automatic role activation is also useful for running scheduled tasks on a data processing system. For example, a daily reboot of the data processing system can be scheduled by a user. As described above, the appropriate roles can be automatically activated at the scheduled time without requiring the user to be present. 
         [0045]    The illustrative embodiment can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. 
         [0046]    Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium can be any tangible apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. 
         [0047]    The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk—read only memory (CD-ROM), compact disk—read/write (CD-R/W) and DVD. 
         [0048]    A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. 
         [0049]    Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. 
         [0050]    Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the currently available types of network adapters. 
         [0051]    The description of the illustrative embodiment has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
A method, apparatus, and computer usable program product for automatic activation of roles is provided. When a user initiates an action, a set of roles needed for the action is identified. A set of roles assigned to the user is also identified. From the two sets of roles, all roles that are common to both sets are identified in a subset of roles. Roles in this subset are assigned to the user and are sufficient for the action. One or more roles from this subset of roles is selected for activation depending on system policies in effect. Selected roles are automatically activated without requiring any intervention from the user. Once the selected roles are activated, they can become inactive upon completion of the current action, or remain active for subsequent actions by the user during all or part of a user session. System policies can decide how the roles are selected for activation, and the duration of which the roles remain active once activated.