Patent Publication Number: US-2009235326-A1

Title: SYSTEM AND METHOD FOR UPDATING USER IDENTIFIERS (IDs)

Description:
CROSS-REFERENCE TO RELATED PATENT APPLICATIONS 
     This application claims the benefit of Korean Patent Applications Nos. 10-2004-0102390, filed on Dec. 7, 2004, and 10-2005-0051085, filed on Jun. 14, 2005, in the Korean Intellectual Property Office, the disclosures of which are incorporated herein in their entireties by reference. 
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates to a system and method for updating user identifiers (IDs), and more particularly, to a method and system for dynamically creating and updating user identifiers (IDs) shared between systems according to system security environments. 
     2. Description of the Related Art 
     Along with development and expansion of the Internet, electronic commerce is rapidly becoming a common feature of ever life. A user gets memberships of various service provider servers and thus receives services provided from the service provider servers. If a user requests a subscription to a service provider server, the service provider server requests the user to register an identifier (ID) and a password, validates a user authorization using the ID and password registered by the user and then provides services to the user. Many users have so many user IDs and passwords that they cannot correctly remember all their IDs and passwords. Accordingly, many systems provide a function for integrating and managing user&#39;s IDs and passwords. 
     Korean Patent Application No. 10-2000-0030890, entitled “The Method for Managing ID and Password”, discloses a function for preventing a user from forgetting his/her IDs and passwords by enabling the user to integrate and manage his/her IDs and passwords registered on various service provider servers. However, in the Korean Patent Application No. 10-2000-0030890, the user must obtain an authentication from each service provider server whenever he/she accesses one of the service provider servers to use services thereof, which causes inconvenience when the user has registered on many service provider servers. 
     Recently, a Single Sign-On (SSO) technique has been developed in which additional authentications are unnecessary once a user obtains an authentication from one of his/her subscribed service provider servers. A “Passport” system created by Microsoft Corporation is an example of an SSO on the Internet. In the “Passport” system, a single service provider server manages user IDs, and other service provider servers are federated with the server provider server managing the user IDs. However, since user IDs and passwords are centrally managed by a service provider server of Microsoft Corporation, users are worried about privacy protection. 
     In order to resolve this privacy protection issue, the Liberty Alliance Group has defined a so-called “Federated Name Identifier” method, in which service provider severs, each managing user IDs and passwords, are federated with each other through an agreement and provide an SSO to users. The method assigns randomly created user IDs to the users without using the users&#39; actual IDs and manages the encoded user IDs. That is, when a user accesses a service provider server SP in order to use services of the service provider server SP after he/she obtains an authentication through his/her ID from an ID service provider server IDSP, the ID service provider server IDSP transmits a pre-stored user ID for the service provider server SP to the service provider server SP. 
     The service provider server SP confirms through the user ID transmitted from the ID service provider server IDSP a fact that the user obtains an authentication, thereby requiring no further authentication for the user. In this case, the user ID transmitted to the service provider server SP is a randomly encoded user ID. 
     The Liberty Alliance Group defines a method for creating user IDs, but has no definition regarding when or under which circumstances user IDs should be updated. If system or user ID information is hacked, the user ID must be instantly updated. Also, in circumstances where unauthorized access attempts on a system are frequent, associated user IDs must be frequently updated in order to ensure security. 
     SUMMARY OF THE INVENTION 
     The present invention provides a method for dynamically creating and updating user identifiers (IDs) shared between systems, considering system or user security environments, such as unauthorized access of systems, unauthorized access of user ID information, etc. 
     According to an aspect of the present invention, there is provided a user identifier (ID) update system comprising: a security environment collecting unit collecting unauthorized access attempt information for a user ID; an ID policy creating unit creating a user ID update policy for an encoded user ID obtained by encoding the user ID, according to the unauthorized access attempt information received from the security environment collecting unit; an ID policy storage unit storing the user ID update policy; and an ID update unit loading the user ID update policy from the ID policy storage unit, creating a new user ID according to the user ID update policy, and changing the user ID to the new user ID. 
     According to another aspect of the present invention, there is provided a user identifier (ID) updating method comprising: (a) collecting unauthorized access attempt information for a user ID; (b) creating a user ID update policy for an encoded user ID obtained by encoding the user ID, according to the unauthorized access attempt information collected in operation (a); (c) storing the user ID update policy created in operation (b); (d) loading the user ID update policy stored in operation (c) and determining whether or not to update the user ID; and (e) creating a new user ID if it is determined in operation (d) that the user ID should be updated, and changing the user ID to the new user ID. 
     According to still another aspect of the present invention, there is provided a user identifier (ID) updating method comprising: (a) receiving a user ID update policy created by a service provider server which is federated with a user ID update system through the user ID; (b) storing the user ID update policy received in operation (a); (c) loading the user ID update policy stored in operation (b) and determining whether or not to update the user ID; and (d) creating a new user ID if it is determined in operation (c) that the user ID should be updated, and changing the user ID to the new user ID. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The above and other features and advantages of the present invention will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings in which: 
         FIG. 1  is a block diagram of a user identifier (ID) update system according to an embodiment of the present invention; 
         FIG. 2  is a view for explaining examples of user IDs shared between the user ID update system illustrated in  FIG. 1  and service provider servers; 
         FIG. 3  is a view illustrating an example of a user ID updating policy illustrated in  FIG. 1 ; 
         FIG. 4  is a flowchart illustrating a user ID updating method according to an embodiment of the present invention; 
         FIG. 5  is a flowchart illustrating in detail an operation S 410  illustrated in  FIG. 4 ; and 
         FIG. 6  is a flowchart illustrating a user ID updating method according to another embodiment of the preset invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     The present invention will now be described more fully with reference to the accompanying drawings, in which exemplary embodiments of the invention are shown. 
       FIG. 1  is a block diagram of a user identifier (ID) update system  100  according to an embodiment of the present invention. Referring to  FIG. 1 , the user ID update system  100  includes a security environment collecting unit  110 , an ID policy creating unit  120 , an ID policy storage unit  130 , an ID policy transmitting unit  140 , an ID policy receiving unit  150 , an ID update unit  160 , an ID transmitting unit  170 , and an ID receiving unit  180 . Here, the ID update unit  160  includes an ID creating part  162  and an ID storage part  164 . 
     The security environment collecting unit  110  collects unauthorized access attempt information on the user ID update system  100  and user IDs. In this case, the user IDs are randomly encoded user IDs. The ID policy creating unit  120  creates a user ID update policy according to the unauthorized access attempt information received from the policy environment collecting unit  110 . The user ID update policy will be described in detail later with reference to  FIG. 3 . 
     The ID policy storage unit  130  stores the user ID update policy created by the ID policy creating unit  120 . 
     The ID policy transmitting unit  140  provides the user ID update policy created by the ID policy creating unit  120  to a service provider server which is federated with the user ID update system  100  through the user ID. 
     Thereafter, the service provider server which is federated with the user ID update system  100  through the user ID updates the user ID under a predetermined condition, according to the user ID update policy created by the ID policy creating unit  120 . Here, each service provider server, which is federated with the user ID update system  100  through the user ID, stores all user IDs which are shared by the user ID update system  100  and the service provider server. Thus, when a user which has acquired an authentication from the user ID update system  100  through his/her ID and password accesses the service provider server in order to use services of the service provider server, the user ID update system  100  transmits the user ID shared by the service provider server to the service provider server. Accordingly, the user can use the services of the service provider server without any further authentication. 
     The ID policy receiving unit  150  receives the user ID update policy created by the service provider server which is federated with the user ID update system  100  through the user ID, and stores the received user ID update policy in the ID policy storage unit  130 . 
     The ID update unit  160  loads the user ID update policy stored in the ID policy storage unit  130 , creates and stores a new user ID according to the user ID update policy, and changes the pre-stored user ID to the new user ID. 
     The ID update unit  160  includes the ID creating part  162  and the ID storage part  164  as described above. The ID creating part  162  loads the user ID update policy from the ID policy storage unit  130  and creates the new user ID according to the user ID update policy. The ID storage part  164  stores the new user ID created by the ID creating part  162 , and changes the pre-stored user ID to the new user ID. 
     The ID transmitting unit  170  transmits the new user ID to the service provider server which is federated with the user ID update system  100  through the user ID. 
     As described above, the user ID update system  100  and the service provider server federated with the user ID update system  100  through the user ID, respectively store user IDs which are shared by them. If the user ID update system  100  creates and updates a new user ID, it transmits the new user ID to the service provider server, so that the service provider server also updates the corresponding user ID. 
     The ID receiving unit  180  receives a new user ID created by the service provider server federated with the user ID update system  100  through the user ID, and transmits the new user ID to the ID update unit  160 . The ID update unit  160  stores the new user ID in the ID storage part  164  and changes the pre-stored user ID to the new user ID. 
       FIG. 2  is a view for explaining examples of user IDs shared between a user ID update system  200  and service provider servers; 
     Referring to  FIG. 2 , a method in which the user ID update system  200  and the service provider servers are federated with each other and provide Single Sign-On (SSO) for a user “Joe”, will be explained below. 
     As illustrated in  FIG. 2 , the user ID update system  200  uses “Joe123” as a user ID for the user “Joe”, a first service provider server  220  uses “JoeS” as a user ID for the user “Joe”, and a second service provider server  240  uses “JSch” as a user ID for the user “Joe”. 
     If the user ID update system  200  is federated with the first service provider server  220 , the user ID update system  200  uses “mr3tTJ3401mN2ED” as a user ID for the user “Joe” and the user ID “mr3tTJ3401mN2ED” is stored in the user ID update system  200  and the first service provider server  220 . Also, the first service provider server  220  uses “dTvliRcMIpCqV6xX” as a user ID for the user “Joe” and the user ID “dTvliRcMIpCqV6xX” is stored in the user ID update system  200  and the first service provider server  220 . 
     As described above, the user IDs shared between the user ID update system  200  and the first service provider server  220  must be randomly created and periodically updated in order to prevent the user IDs from being revealed. 
     If the user ID update system  200  is federated with the second service provider server  240 , the user ID update system  200  uses “xyrVds+xg0/pzSgx” as a user ID for the user “Joe” and the user ID “xyrVds+xg0/pzSgx” is stored in the user ID update system  200  and the second service provider server  240 . Also, the second service provider server  240  uses “pfk9uzUN9JcWmk4RF” as a user ID for the user “Joe” and the user ID “pfk9uzUN9JcWmk4RF” is stored in the user ID update system  200  and the second service provider server  240 . 
     As described above, the user IDs shared between the user ID update system  200  and the second service provider server  240  must be randomly created and periodically updated in order to prevent the user IDs from being revealed. 
       FIG. 3  is a view illustrating an example of the user ID update policy illustrated in  FIG. 1 . Referring to  FIG. 3 , the user ID update policy may be one of an update_Now policy, an update_Short policy, an update_Long policy, and an update_Normal policy. The update_Now policy is applied to immediately update the user ID when the user ID update system  200  or the user ID is accessed without authorization. In  FIG. 3 , the update-policy is set to immediately update the user ID. The update_Short policy is applied to update the user ID as promptly as possible when unauthorized access attempts on the user ID update system  200  or user ID information are frequent. A determination on whether or not unauthorized access attempts are frequent depends as to the number of unauthorized access attempts occurring during a predetermined period (that is, it is determined that unauthorized access attempts are frequent when the number of unauthorized access attempts exceeds a predetermined number). In  FIG. 3 , the update_Short policy is set to update the user ID after 10 days have elapsed. 
     The update_Long policy is applied to update the user ID more frequently than in a normal status when unauthorized access attempts on the user ID update system  200  or user ID information occasionally occur. Here, whether or not unauthorized access attempts are defined as happening occasionally depends on the number of unauthorized access attempts occurring during a predetermined period (that is, it is determined that unauthorized access attempts occasionally occur when the number of unauthorized access attempts is less than a predetermined number). In  FIG. 3 , the update_Long policy is set to update the user ID after 30 days have elapsed. 
     The update_Normal policy is applied to normally update the user ID when there is no unauthorized access attempt on the user ID update system  200  and user ID information. In  FIG. 3 , the update_Normal policy is set to update the user ID after 60 days have elapsed. 
       FIG. 3  illustrates an example where the update_Now policy is set to immediately update the user ID, the update_Short policy is set to update the user ID after 10 days have elapsed, the update_Long policy is set to update the user ID after 30 days have elapsed, and the update_Normal policy is set to update the user ID after 60 days have elapsed, but the invention is not limited to this. 
       FIG. 4  is a flowchart illustrating a user ID updating method according to an embodiment of the present invention. 
     Referring to  FIG. 4 , firstly, unauthorized access attempt information on a user ID update system or user ID information is collected (operation S 400 ). 
     Then, a user ID update policy for an encoded user ID obtained by encoding a user ID is created according to the unauthorized access attempt information collected in operation S 400  (operation S 410 ). In more detail, the user ID update policy may be one of: an update_Now policy for immediately updating a user ID; an update_Short policy for updating a user ID after 10 days have elapsed; an update_Long policy for updating a user ID after 30 days have elapsed; and an update_Normal policy for updating a user ID after 60 days have elapsed. The user ID updating policies created according to the unauthorized access attempt information will be described in detail later with reference to  FIG. 5 . Here, the user ID is an encoded user ID obtained by randomly encoding a user ID. 
     Then, the user ID update policy created in operation S 410  is stored (operation S 420 ). 
     Next, the user ID update policy stored in operation S 420  is loaded and it is determined whether or not the user ID should be updated (operation S 430 ). A decision on whether or not the user ID should be updated depends on whether or not a predetermined period defined in the user ID update policy has elapsed. 
     If it is determined in operation S 430  that the user ID does not need to be updated, the process proceeds to operation S 440  so as to determine whether or not the predetermined time has elapsed. If it is determined in operation S 440  that he predetermined time has not elapsed, operation S 440  is repeated. If it is determined that the predetermined time has elapsed, the process returns to operation S 430 . 
     Meanwhile, if it is determined in operation S 430  that the user ID should be updated, the method proceeds to operation S 450 . In operation S 450 , a new user ID is created. 
     Then, the new user ID is stored and the pre-stored user ID is changed to the new user ID (operation S 460 ). 
     Successively, the new user ID created in operation S 460  is transmitted to a service provider server which is federated with the user ID update system through the user ID (operation S 470 ). 
       FIG. 5  is a flowchart illustrating in detail the operation S 410  illustrated in  FIG. 4 . Referring to  FIG. 5 , it is determined whether an unauthorized access attempt on the user ID occurs based on the unauthorized access attempt information collected in operation S 400  (operation S 411 ). 
     If it is determined in operation S 411  that no unauthorized access attempt occurs, the process proceeds to operation S 417  and the update_Normal policy is created. If it is determined in operation S 411  that an unauthorized access attempt occurs, the process proceeds to operation S 412 . 
     In operation S 412 , it is determined whether or not unauthorized access has occurred based on the unauthorized access attempt information. 
     If it is determined in operation S 412  that unauthorized access has occurred, the process proceeds to operation S 414  and the update_Now policy is created. On the contrary, if it is determined in operation S 413  that no unauthorized access has occurred, the process proceeds to operation S 413 . 
     In operation S 413 , it is determined whether or not the number of unauthorized access attempts exceeds a predetermined number. Different update policies can be applied according to whether the number of unauthorized access attempts is more or less than a predetermined number. If it is determined in operation S 413  that the number of unauthorized access attempts exceeds the predetermined number, the process proceeds to operation S 415  and the update_Short policy is created. Meanwhile, if it is determined in operation S 413  that the number of unauthorized access attempts is less than the predetermined number, the process proceeds to operation S 416  and the update_Long policy is created. 
     As described above, the user ID update policy may be one of: the update_Now policy, the update_Short policy, the update_Long policy, and the update_Normal policy. The respective user ID update policies will now be described in detail. 
     The update_Now policy is used for immediately updating the user ID when the user ID update system or the user ID is accessed without authorization. In  FIG. 5 , the updata_Now policy immediately updates the user ID. The update_Short policy is used for updating the user ID as promptly as possible when unauthorized access attempts on the user ID update system or the user ID are frequent. Whether or not unauthorized access attempts are defined as being frequent depends on the number of unauthorized access attempts occurring during a predetermined period (that is, it is determined that unauthorized access attempts are frequent when the number of unauthorized access attempts exceeds a predetermined number). In  FIG. 5 , the update_Short policy updates the user ID after 10 days have elapsed. The update_Long policy is applied when unauthorized access attempts on the user ID update system or user ID information occasionally occur. Whether or not unauthorized access attempts are defined as happening occasionally depends on the number of unauthorized access attempts occurring during a predetermined period (that is, it is determined that unauthorized access attempts occasionally occur when the number of unauthorized access attempts is less than the predetermined number). In  FIG. 5 , the update_Long policy updates the user ID after 30 days have elapsed. The update_Normal policy is used for updating the user ID in a normal state when there is no unauthorized access attempt on the user ID update system and the user ID. In  FIG. 5 , the update_Normal policy updates the user ID after 60 days have elapsed. 
       FIG. 5  illustrates an example in which the update_Now policy is set to immediately update the user ID, the update_Short policy is set to update the user ID after 10 days have elapsed, the update_Long policy is set to update the user ID after 30 days have elapsed, and the update_Normal policy is set to update the user ID after 60 days have elapsed, but the invention is not limited to this. 
       FIG. 6  is a flowchart illustrating a user ID updating method according to another embodiment of the present invention. Referring to  FIG. 6 , firstly, a service provider server which is federated with a user ID update system through a user ID receives a user ID update policy (operation S 600 ). In more detail, the user ID update policy may be one of: an update_Now policy for immediately updating a user ID; an update_Short policy for updating a user ID after 10 days have elapsed; an update_Long policy for updating a user ID after 30 days have elapsed; and an update_Normal policy for updating a user ID after 60 days have elapsed. Here, the user ID is an encoded user ID obtained by randomly encoding a user ID. 
     Then, the user ID update policy created in operation S 600  is stored (operation S 610 ). 
     Successively, the user ID update policy stored in operation S 610  is loaded and it is determined whether or not the user ID should be updated (operation S 620 ). Whether or not the user ID should be updated depends on whether or not a predetermined period defined in the user ID update policy has elapsed. 
     If it is determined in operation S 620  that the user ID does not need to be updated, the process proceeds to operation S 630  and it is determined whether or not the predetermined time has elapsed. If it is determined in operation S 630  that the predetermined time has not elapsed, operation S 630  is repeated. If it is determined that the predetermined time has elapsed, the process reverts to operation S 620 . 
     Meanwhile, if it is determined in operation S 620  that the user ID should be updated, the process proceeds to operation S 640 . In operation S 640 , a new user ID is created. 
     Then, the new user ID is stored and the pre-stored user ID is changed to the new user ID (operation S 650 ). 
     Next, the new user ID created in operation S 650  is transmitted to a service provider server which is federated with the user ID update system through the user ID (operation S 660 ). 
     The present invention can also be embodied as computer readable code on a computer readable recording medium. The computer readable recording medium is any data storage device that can store data which can be thereafter read by a computer system. Examples of the computer readable recording medium include read-only memory (ROM), random-access memory (RAM), CD-ROMs, magnetic tapes, floppy disks, optical data storage devices, and carrier waves. The computer readable recording medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion. 
     As described above, according to the present invention, it is possible to ensure security between systems and provide reliability for user IDs, by dynamically creating and updating user IDs which are shared between systems, considering security environments, such as unauthorized access of systems, unauthorized access of user ID information, etc. 
     While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present invention as defined by the following claims.