The present invention relates to the information technology field. More specifically, the invention relates to the management of user IDs having a plurality of possible different roles.
In a data processing system which controls a plurality of resources it is necessary to make sure that only authorized users have access to system resources and normally not all the users can have access to all and to the same resources. It is known to create user profiles to which a predetermined set of authorizations is associated. Access to software resources is generally controlled by security software that grants or prevents access based on two main access control themes: authentication and authorization. Authentication verifies whether or not a person is who he claims to be, through methods such as checking userID/password combinations or similar. When a user fails authentication checks, he is generally prevented from accessing any of the systems. When a user is authenticated, then he may access a pre-determined subset of the system resources, based on authorization rights. Authorization defines what an authenticated user is allowed to do in a system. Authorization may define tasks that a user is allowed to execute, it may define a subset of resources that a user may work with, or it may be a combination of the two.
System administrators (or system programmers) require extensive authorization rights in order to perform priviledged operations to configure and maintain the systems. Working at the administrator level of authorization requires extreme care, as the results of an inadvertent mistake could be extremely costly. As a result, best practices dicatate that administrators perform ‘normal’ operations with the authorization granted to a ‘normal’ userID, and log off and then on again with an ‘administrator’ id when a higher level of authorization is required. This approach requires that multiple userIDs are assigned to users that require different roles. An alternative is to run with a priviledged id in terms of the commands that can be executed, but with a low default level of authorization in terms of scope, and granting oneself priviledges when required to perform specific operations on specific resources.
An example of state of the art system is the Resource Access Control Facility (RACF) by International Business Machines Corp. With this system, each userID has a single authorization scope, defined by the combination of permissions for the group(s) to which the userID belongs, and permissions assigned to the individual userID. Even if permissions can be inherited from different groups, the resultant permission set is static, and is always assigned to the userID when it logs onto the system. Each userID has a single password. Users with a high degree of authorization (e.g. systems programmers) will often maintain two userIDs, one for doing ‘normal’ operations as an end user, and the other for when certain permissions are really required. Using the ‘normal’ userID for normal operations ensures that system damage will not result from mistakes or oversights. When the high-priviledge userID is used, extra caution is taken. Another method that is used to defend from costly mistakes is to maintain the permissions to a minimum, but to authorize a user to execute a command (TSO PERMIT) to grant permissions to themselves only when needed. This technique is used by trusted users to defend themselves from potential errors or oversights.
Another example is UNIX standard security systems which allow a single authorization profile per userID. Even users that have authorization to the ROOT userID will refrain from using it unless necessary for the job at hand. Usually they will log on with their normal userID and ‘upgrade’ their priviledges using the Switch User (SU) to gain ROOT priviledges for the time that is necessary. At this point however the user switches identity from their normal login to ROOT.
A drawback of the solutions described above is that they require additional overhead and level of indirection in audit trails, and they are also rather error-prone and requires multiple steps for every operation.
It is an object of the present invention to provide a solution which overcome the above drawback of the prior art.
The present invention provides a solution as set out in the independent claims. Advantageous embodiments of the invention are described in the dependent claims.
According to the present invention, we provide a method for controlling user access to a plurality of resources in a data processing system, the data processing system maintaining a set of stored userIDs each userID having a plurality of associated stored passwords, each password being coupled to a predetermined profile defining a set of resource access authorizations, the method including the steps of: prompting a user to input a userID; prompting the user to input a first password; scanning the stored userIDs and the associated stored passwords to identify a match with the input userID and first password; responsive to a match being identified selectively granting the user access to the resources according to the predetermined profile coupled to the input first password.
Another aspect of the invention proposes a computer program for performing the method.
A further aspect of the invention proposes a corresponding system.
The invention itself, as well as further features and the advantages thereof, will be best understood with reference to the following detailed description, given purely by way of a non-restrictive indication, to be read in conjunction with the accompanying drawings, in which:
The present invention provides a method to associate multiple authorization roles with a single userID, and allows for movement between the roles without changing identity. This results in a clearer audit trail, and removes the need for extensive knowledge of the security system commands and for multiple steps to allow a step up or down in authorization.
With reference in particular to
Considering now
Moving to
The module Access Control 301 includes a software (e.g. RACF of International Business Machines Corp described above) which manages all access requests arriving from the I/O module 303. When a new request is received, the user is prompted to enter the userID and the corresponding password. The Access Control module looks for the userID/password pair on the database 305 and associates the corresponding profile contained in database 307, where all the authorization levels associated to such profile are defined. According to the associated profile, access to the resources 103 is granted or denied. The resources can be any kind of physical or logic objects which can be controlled by a data processing system: just to make a few examples a resource can be a file, a directory, a peripheral HW device, a data base, a SW application. Also the kind of possible authorizations can have a wide variety of different implementations: e.g. it could be a simple permission to read, write or execute a file, or to use a resource, or to perform an action; another possibility is that a file or a resource could be “visible” only to some users and hidden to all the other users. It is often the case that a privileged user, called Administrator can see and access all resources and perform any possible actions. Those skilled in the art will appreciate that many different alternative implementations are possible, e.g. the information on userID/password and the corresponding profile, could be stored in the same database or could be e.g. stored in the working memory of the data processing system.
According to a preferred embodiment of the present invention, the security system allows for multiple authorization roles to be assigned to a single user. According to a preferred embodiment of the present invention, these roles are mutually exclusive at any given time (i.e. on OR and not in AND), however different implementations are possible. Each role (profile) is associated to a different password. The passwords for each role follow a different lifecycle and may be subject to different rules, although, clearly, the password for each role must be different from the others in any instant. When a user logs on to a system, he chooses the role with which to access the system based on which of the active passwords is entered. The authentication system checks the entered password with each of the valid passwords for the userID in turn, and when a match is found the corresponding authorization role is applied. Once logged onto a system with a particular role, a user may change role by executing a command that re-authenticates the user and which re-assigns the authorization role based on the password entered.
With reference now to
Naturally, in order to satisfy local and specific requirements, a person skilled in the art may apply to the solution described above many modifications and alterations. Particularly, although the present invention has been described with a certain degree of particularity with reference to preferred embodiment(s) thereof, it should be understood that various omissions, substitutions and changes in the form and details as well as other embodiments are possible; moreover, it is expressly intended that specific elements and/or method steps described in connection with any disclosed embodiment of the invention may be incorporated in any other embodiment as a general matter of design choice.
Particularly, similar considerations apply if the system has a different architecture or includes equivalent units; for example, the resources could be physically placed on the same data base. Moreover, each computer may have another structure or may include similar elements (such as cache memories temporarily storing the programs or parts thereof to reduce the accesses to the mass memory during execution); in any case, it is possible to replace the computer with any code execution entity (such as a PDA, a mobile phone, and the like).
Without departing from the principles of the invention, it is also possible to exploit equivalent structures only dedicated to this purpose.
It should be readily apparent that the implementation of the present invention is not limited to any specific application and/or technique for verifying the userID and the password; for example, it is possible to use other Access Control applications and to implement different user access policies.
Similar considerations apply if the program (which may be used to implement each embodiment of the invention) is structured in a different way, or if additional modules or functions are provided; likewise, the memory structures may be of other types, or may be replaced with equivalent entities (not necessarily consisting of physical storage media) . Moreover, the proposed solution lends itself to be implemented with an equivalent method (having similar or additional steps, even in a different order). In any case, the program may take any form suitable to be used by or in connection with any data processing system, such as external or resident software, firmware, or microcode (either in object code or in source code) . Moreover, the program may be provided on any computer-usable medium; the medium can be any element suitable to contain, store, communicate, propagate, or transfer the program. Examples of such medium are fixed disks (where the program can be pre-loaded), removable disks, tapes, cards, wires, fibers, wireless connections, networks, broadcast waves, and the like; for example, the medium may be of the electronic, magnetic, optical, electromagnetic, infrared, or semiconductor type.
In any case, the solution according to the present invention lends itself to be carried out with a hardware structure (for example, integrated in a chip of semiconductor material), or with a combination of software and hardware.
Number | Date | Country | Kind |
---|---|---|---|
07109478.3 | Jun 2007 | EP | regional |