The method and system of the present invention pertains to the management of computer networks and, more particularly, to an improved method for managing user identities on a network.
Managing user identities on a small network with a limited number of users, a single operating system, and a limited number of applications can be a fairly straight-forward task. For example, in a local area network (LAN) the user registry (the location where user identities are stored) is defined on each machine. That information is then replicated on each server in the domain. If the network is small enough, the system administrator can manually track all of the users identities on the network using different administration tools developed for this purpose. For example, if a new user starts work at the company, the user's account information is approved and an identity is manually created on the system. If a user takes a leave of absence, that user's identity is manually disabled upon his or her departure and manually re-enabled upon his or her return.
Unfortunately, few computer networks in this day and age are this elementary as the one described above. For example, although a company may start small, as the company grows, the number of users can proliferate. Because each user identity is typically created, altered and removed at a time that is dependant on that specific users behavior, it is rarely possible to gain efficiencies as the user population grows. Manual management of user identities quickly becomes inefficient, costly and undependable.
As computers from disparate manufacturers, or newer computer from the same manufacturer, are added to the network, it is inevitable that new operating systems will also be added. Because each operating system typically maintains its own user registry, it becomes necessary for the system administrator to learn and become proficient in managing user identities for each of the respective operating systems. Moreover, each operating system typically has its own administrative tools that allow a system administrator to add, delete, or modify user identities in the user registry, each user may require several user identities for the different operating systems on the network. As the number of users and the number of operating systems increases, management of user identities on the network becomes a daunting task.
In the prior art, administration of different user identities is typically performed using a software tool that is unique for each environment. For example, one approach to manage user identities is to use a distributed computing environment wherein the user registers with a first server and receives a set of credentials. Those credentials are then presented when accessing resources on a second computer. The second server will accept or deny the presented credentials after validating them through a series of queries. This is generally the type of user management technique employed by Windows NT. This approach is problematic when a large number of users are actively adding, deleting and modifying their identities because the second computer is (and subsequent computers are) constantly trying to stay current with the first computer. The larger the network and the greater the number of servers, the greater the problem.
Another approach is that utilized by the Windows 2000 operating system in which all applications and operating systems are forced to share a common user registry. However, implementing this approach on a network that includes several different operating systems would require that each operating system and each application be re-written to access a common user registry, a solution which is clearly not feasible.
Another complexity in the management of user identities is the increasing demands of network management. For example, there was a time when a user would call the help desk at a company to have a password reset and the help desk personnel would simply be able to click on the “reset password” button for the operating system and the user's password would be reset. In the current environment, however, other obstacles exist. For example, the user account may be locked, in which case clicking the “reset password” button will not work. In this case, because the password reset implementation resides in the software code, the help desk personnel would need to write a new program or module that calls the application program interfaces (APIs) to unlock the account. This requires a working knowledge of the programming language and the APIs necessary to unlock the account. Typical help desk support staff would not be skilled in reading and making modifications to standard programing languages. In addition, if the administrator wanted additional features, such as sending an email to the person requesting a password reset and requiring a return email prior to resetting the password, typical help desk personnel would have to send such a request to a skilled programmer.
Certain programs that address this issue to a limited degree are commercially available. For example, Sun Microsystems, Inc. makes an identiy management application that facilitates the writing of the workflow for certain identity management tasks. However, users of this product must have a fundamental understanding of standard programming languages. The application is not intended for a non-programmer and does not allow a non-programmer to efficiently and reliably manage user identities without manually writing or modifying code.
There is a need, therefore, for a method of managing user identities in the different user registries so a system administrator can, in a simple and straight-forward manner, manage the company's user identities dynamically yet in a cost effective, reliable and timely manner.
There is also a need for a method of managing user identities which increases application reuse and reduces the cost and complexity of application development and management that is portable into the future.
There is also a need for a method of managing user identities that is platform independent, thereby reducing the time, cost and complexity associated with utilizing disparate tools for different platforms.
There is also a need for a method of managing user identities that allows developers, designers and system administrators to use languages and concepts with which they, are comfortable.
The present invention is for an improved method and system for managing user identities on a network. An administrator is provided with the ability to add, modify and delete actors on the network. Each actor, such as a help desk, is ascribed use cases, such as enabling passwords, resetting passwords, and disenabling passwords, that are appropriate for that actor. The administrator can then modify each use case, such as by unlocking a user's account before resetting the password or providing an email notification to a user prior to resetting a password, to the extent desired by the administrator. As a result, an actor with no or little programming skills can perform sophisticated identity management functions resulting is improved efficiency and lower cost to the company
These features and advantages, as well as others, will be apparent from the following more detailed description of the preferred embodiments of the invention, as illustrated in the accompanying drawings.
A better understanding of the system and method of the present invention may be had by reference to the drawings, wherein:
The present invention is an improved method and system allowing a user to manage multiple user identities on a network. The invention can be used in managing user identities in a large corporate enterprise or can be used to manage users in a small corporate setting. Accordingly, the words “enterprise,” “corporation,” “company,” “venture” and “operation” are used interchangeably herein and can be used to describe private organizations or governmental entities. A “user” may be a human user, a file, or may be a software process that is assigned a shared resource, such as a print server. The term “network” can mean the Internet, a wide area network, a local are network or any other aggregation of more than one computer without regard to the topology of the network, the protocols used in communication on the network, or the method by which devices on the network communicate. Also, in general the term “identity” means a password, account name, personal identification number, biometric identifier, permission level or other attribute identifying or pertaining to the user in some manner.
It is important to note that while the present invention has been and will continue to be described in one embodiment as a system, those skilled in the art will appreciate that the present invention is capable of being distributed as a program product in a variety of forms, and that the present invention applies equally regardless of the particular type of media used to actually carry out the distribution. Examples of suitable media include recordable type media such as CDROM and suitable transmission mechanisms include digital and analog communications links.
The present invention provides a platform-independent model for managing user identities on a network and then translated to one or more platform-specific models for the actual implementation. To accomplish this goal, an architecture is defined that provides a set of guidelines for structuring user identity management specifications expressed as models. The translation between the platform-independent model and the platform-specific model is then performed using automated tools.
The product resulting from the above approach provides an open, vendor-neutral solution to the obstacle of inter operability between platforms. As new platforms and technologies emerge, it is possible to rapidly integrate those platforms and technologies into the existing system. As a result, the present invention provides a thorough, structured solution for portability into the future.
Referring now to the drawings,
Once the actor has been identified, use cases can be assigned to that actor.
If the administrator, for example, clicks on the Reset Password 507 link shown in
If the administrator selects the options 706 tab on the screen shown in
Once the use case information has been modified, an implementation of the Reset Password use case is generated. The resulting implementation is vendor-specific, but the Administrator may choose which implementation to generate.
It is important to note that the foregoing discussion describes one embodiment of the invention. For example, while the actor in the foregoing discussion was a company's help desk, the actor could alternatively be a end user such as any non-administrative user requiring identity management functionality. In such a case, use cases may be, for example, reset password enabling the end user to reset a forgotten password; change password enabling the end user to change their password; access request enabling the end user to access information technology resources; change answers enabling the end user to answer their authentication questions used during the Reset Password process; Change Information enabling the end user to change personal information; and Create User Request enabling the end user to make requests which are subsequently approved by the administrator or others.
As another example, the actor could be designated as HR Synchronization which could automatically initiate provisioning events based on changes in an employee's human resources data. In this case, use cases may be, for example, Create User enabling the end user to create a new user account; Update User enabling the end user to update the user's account; Rename User enabling the end user to rename the user's account; Disable User enabling the end user to disable the user's account; and Delete User enabling the end user to delete the user's account.
There are numerous additional use cases for the actors described herein and there are numerous additional actors which can be designated for any organization. The specific actors and use cases described herein are not meant to be limiting and are meant only to serve as examples of the types of actors and use cases that may be used in connection with the present invention.
While the present system and method has been disclosed according to the preferred embodiment of the invention, those of ordinary skill in the art will understand that other embodiments have also been enabled. Even though the foregoing discussion has focused on particular embodiments, it is understood that other configurations are contemplated. In particular, even though the expressions “in one embodiment” or “in another embodiment” are used herein, these phrases are meant to generally reference embodiment possibilities and are not intended to limit the invention to those particular embodiment configurations. These terms may reference the same or different embodiments, and unless indicated otherwise, are combinable into aggregate embodiments. The terms “a”, “an” and “the” mean “one or more” unless expressly specified otherwise.
When a single embodiment is described herein, it will be readily apparent that more than one embodiment may be used in place of a single embodiment. Similarly, where more than one embodiment is described herein, it will be readily apparent that a single embodiment may be substituted for that one device.
In light of the wide variety of possible actors and use cases, the detailed embodiments are intended to be illustrative only and should not be taken as limiting the scope of the invention. Rather, what is claimed as the invention is all such modifications as may come within the spirit and scope of the following claims and equivalents thereto.
None of the description in this specification should be read as implying that any particular element, step or function is an essential element which must be included in the claim scope. The scope of the patented subject matter is defined only by the allowed claims and their equivalents. Unless explicitly recited, other aspects of the present invention as described in this specification do not limit the scope of the claims.