JP5373493B2 - ID management program - Google Patents

Description

  The present invention relates to a program for causing a computer to execute processing for managing a user ID.

  Conventionally, regarding a personal authentication system, “a management configuration of a personal identification certificate in a personal authentication system using a personal identification certificate storing a template that is personal identification data is provided. As a technology for the purpose of, “Personal identification certificate generated by a personal identification authority (IDA), which is a third party, for example, a service provider (SP) and a user device (UD) that execute personal authentication processing”. A template is acquired from (IDC) and personal authentication is executed. The IDA executes the personal confirmation process of the IDC issuance requester, generates the IDC, and performs the registration process. Further, the IDC is deleted, changed, and the template stored in the personal identification certificate is added, Management of deletion validity stop, stop release, etc. is executed. Is proposed (Patent Document 1).

JP 2002-73571 A (summary)

  In a system for managing computer users, individual IDs (identification information) are assigned to the users, and the users are managed by managing the IDs. An ID management program for managing a user ID generally manages the state of the user ID by “new registration” or “deletion” of the user ID. The state of the user ID is either “normal” state or “deleted” state (= does not exist).

  In the conventional ID management program as described above, the state of the user ID is limited to the above two types, but on the other hand, the state of the user ID using the computer has also diversified due to the recent diversification of employment forms. . For this reason, it has become difficult for the conventional ID management program to flexibly cope with diversified user ID states.

  The present invention has been made to solve the above-described problems, and an object thereof is to provide an ID management program that can flexibly manage the state of a user ID.

  In the ID management program according to the present invention, a new state of “schedule deletion” is introduced as the state of the user ID. The ID set in the scheduled deletion state becomes temporarily unavailable at that time, and is physically deleted when a predetermined expiration date has passed.

  According to the ID management program of the present invention, the temporary state before physically deleting the user ID can be managed by introducing the “schedule deletion” state. Thus, for example, if there is a possibility that the user ID needs to be validated again after the user ID is temporarily disabled, the user ID is set in the “scheduled deletion” state and later validated again. can do.

  Since the user ID in the “scheduled deletion” state is automatically deleted when a predetermined expiration date has passed, if there is no need to re-enable the user ID, there is no need to perform management work again, and management Can be reduced.

It is a figure which shows the ID management server 100 which performs the ID management program which concerns on Embodiment 1, and its surrounding computer environment. 2 is a functional block diagram of an ID management server 100. FIG. It is a figure which shows an example of the content described in the user structure information. 6 is a diagram illustrating an example of user configuration information 112 according to Embodiment 2. FIG. It is a flow of processing in which the ID management program 111 generates a user ID. It is a flow of processing in which the ID management program 111 deletes a user ID. This is a flow of processing in which the ID management program 111 checks the expiration date of the user ID. It is a figure which shows the life cycle of the user ID which belongs to each user type demonstrated in FIG.

<Embodiment 1>
Hereinafter, embodiments of the present invention will be described with reference to the drawings. First, the environment in which ID management is performed and the linking operation of each device will be described with reference to FIG. Next, the ID management program according to the first embodiment will be described with reference to FIG.

  FIG. 1 is a diagram showing an ID management server 100 that executes an ID management program according to the first embodiment and the surrounding computer environment. It is assumed that a LAN (Local Area Network) 401, a LAN 402, and a LAN 403 are arranged on different floors of a building, and employees of different departments work on each floor. The role and operation of each device shown in FIG. 1 will be described below.

  The ID management server 100 is a computer that executes an ID management program 111 described later with reference to FIG. The ID management server 100 manages IDs of users who use the computers 200a to 200c and the computers 500a to 500c, and distributes user IDs managed by the ID management server 100 to the authentication server 300 and the authentication server 600. Details will be described later. The ID management server 100 is connected to the LAN 401 and can communicate with each device connected to the LAN 402 and the LAN 403.

  The computers 200a, 200b, and 200c are computers that are used by a user to perform business processing and the like. Since the operation of each computer is the same, the computers 200a, 200b, and 200c are hereinafter collectively referred to as the computer 200. The computer 200 is connected to the LAN 402.

  The authentication server 300 authenticates a user who uses the computer 200. The difference between the user ID for which the authentication server 300 performs authentication processing and the user ID managed by the ID management server 100 will be described later.

  The computers 500a, 500b, and 500c are computers that are used by a user to perform business processing and the like. Since the operation of each computer is the same, the computers 500a, 500b, and 500c are hereinafter collectively referred to as the computer 500. The computer 500 is connected to the LAN 403. The user who uses the computer 500 belongs to a different department from the user who uses the computer 200, and thus the user ID system is different from the user ID of the computer 200.

  The authentication server 600 authenticates a user who uses the computer 500. Regarding the computer 500, since the user ID system is different from that of the computer 200, the authentication server 600 is provided separately from the authentication server 300 for authenticating the user of the computer 200.

  In an environment where there are a plurality of user ID management units as shown in FIG. 1, an authentication system may have to be constructed for each user ID management unit, such as the authentication server 300 and the authentication server 600. In such an environment, if each authentication server individually manages the user ID, it may be difficult to control the user ID. Therefore, the ID management server 100 can be used as a higher-level management system that manages such distributedly managed user IDs in an integrated manner.

  The computer environment in the first embodiment has been described above. Next, the cooperative operation of each device shown in FIG. 1 will be described in the following (Step 1) to (Step 3).

(Step 1: Distribute ID)
The ID management server 100 distributes the user ID managed by itself to the authentication server 300 and the authentication server 600. Distributing a user ID distributes authentication information such as a password and access authority definition information assigned to each user ID as necessary in addition to the ID itself, and reflects these information in each authentication server That means.

(Step 2: Register the distributed ID)
The authentication server 300 and the authentication server 600 receive the ID distributed by the ID management server 100 and register it in its own authentication system. If the ID has already been registered, the ID is updated using the newly received information.

(Step 3: Authenticate the user using the authentication server)
The user of the computer 200 inputs his / her user ID and password to the computer 200 when using the computer 200. The computer 200 issues an authentication request to the authentication server 300 using the user ID and password. The authentication server 300 performs authentication processing and transmits the result to the computer 200. Similar processing is performed between the computer 500 and the authentication server 600.

  The link operation of each device illustrated in FIG. 1 has been described above. Next, the configuration of the ID management server 100 will be described.

  FIG. 2 is a functional block diagram of the ID management server 100. The ID management server 100 includes a storage unit 110, a CPU (Central Processing Unit) 120, and a memory 130.

  The storage unit 110 includes a writable storage device such as an HDD (Hard Disk Drive), and stores an ID management program 111, user configuration information 112, and a user ID file 113.

  The ID management program 111 is a software program corresponding to the ID management program according to the first embodiment.

  The user configuration information 112 describes definition information necessary for the ID management program 111 to manage user IDs. A specific example will be described later with reference to FIG.

  The user ID file 113 is a data file describing a user ID, a password, access authority information given to each user ID, and the like. The user ID file 113 corresponds to the “database” in the first embodiment. Any file format may be used as long as it can serve as a database.

  The CPU 120 is an arithmetic device that executes an OS (Operating System) of the ID management server 100 and an ID management program 111. In the following description, the ID management program 111 is described as the operating subject from the viewpoint of simplicity of description, but the operating subject that actually executes the operation specified by the ID management program 111 is the CPU 120.

  The memory 130 is appropriately used as a temporary data storage area or the like when the CPU 120 executes a software program.

  FIG. 3 is a diagram illustrating an example of contents described in the user configuration information 112. Although an example of data configured in a table format is shown here, the data format may be arbitrary. The user configuration information 112 holds the type of user ID managed by the ID management program 111 and information representing the ID life cycle of each user ID type. Each item will be described below.

  The “user type” column holds the type of user ID. The value in this column is assigned to each user ID recorded in the user ID file 113. That is, each user ID managed by the ID management program 111 belongs to one of the user types defined by the values in this column.

  The “life cycle” column holds information representing a state transition from generation to deletion of the user ID belonging to the user type specified by the value of the “user type” column. This process of state transition is called a life cycle.

  In the “expiration date” column, when “schedule deletion” is included in the value of the “life cycle” column, the period until the ID is actually deleted from the user ID file 113 after transitioning to the “scheduled deletion” state Holds a value representing the period of. The time unit in this row may be arbitrary, but here the day unit is used.

The contents described in the data example of FIG. 3 will be described below.
(1) When a new user ID belonging to “type A” is newly generated, the ID management program 111 generates it in the “normal” state and records that fact in the user ID file 113. When deleting the user ID, “physical deletion”, that is, deleting the user ID from the user ID file 113 immediately.

(2) When the ID management program 111 newly generates a user ID belonging to “type B”, the ID management program 111 generates it in the “normal” state and records that fact in the user ID file 113. When deleting the user ID, the "logical deletion" state, that is, the user ID is set to an unusable state, and the fact is recorded in the user ID file 113, but the user ID itself is left.

(3) When the ID management program 111 newly generates a user ID belonging to “type C”, the ID management program 111 generates it in the “normal” state and records that fact in the user ID file 113. When deleting the user ID, the “scheduled deletion” state, that is, the user ID is set to an unusable state, and the fact is recorded in the user ID file 113, but the user ID itself is left. The ID management program 111 deletes the user ID from the user ID file 113 after 30 days have passed since the user ID was set to the “scheduled deletion” state.

  The content of the user configuration information 112 has been described above. Next, how to use the user type described with reference to FIG. 3 will be described.

  In general companies, when a user ID is given to an employee, the life cycle of the user ID may differ depending on the employment form of the employee. Examples are given below.

(Example 1: Regular employees)
In many cases, it would be sufficient to give a regular employee a user ID in the “normal” state and “physical deletion” state. However, some full-time employees may take long vacations, so it may be possible to disable the user ID and save it without deleting it. Therefore, it is preferable to give a “Type A” or “Type B” user ID to a regular employee. For regular employees who return after taking a long vacation, if a user ID of “Type B” is given and the ID is set to “logically deleted” during the vacation, the user ID during the vacation may be used illegally. Will disappear.

(Example 2: part-time employee)
For part-time employees, there are many cases where it is desirable to immediately delete the user ID of the employee when the employment contract ends. Therefore, a part-time employee may be given a “type A” user ID.

(Example 3: Contract employee)
Contract employees may re-contract even after the contract period expires. For this reason, it is conceivable that the contract employee's user ID is stored for a predetermined period after the contract period expires, and is automatically deleted if no contract is made again during that period. A user ID of “type C” is most convenient for such an operation mode. Therefore, a user ID of “type C” may be given to contract employees.

  As described above, the ID management program 111 according to the first embodiment manages the life cycle of each user ID based on the value of “user type” defined in the user configuration information 112. For the user ID for which “physical deletion” is defined as the deletion method, the ID management program 111 deletes the record of the ID from the user ID file 113 and the user ID for which “scheduled deletion” is defined as the deletion method. Is written in the user ID file 113 to the effect that the ID is temporarily disabled, and the record of the ID is deleted after the expiration date. This enables not only a simple ID management method of simply deleting a user ID, but also flexible ID management such as temporarily disabling IDs and automatically deleting unnecessary IDs. .

  Further, according to the first embodiment, by performing flexible ID management as described above, it is possible to easily cope with various ID management systems of users who give user IDs. For example, regarding management of user IDs in a company, by assigning a “user type” corresponding to the employment form of an employee to a user ID, ID management that matches the user ID management policy in the company can be easily performed.

<Embodiment 2>
In the first embodiment, it is assumed that when the ID management program 111 generates or deletes a user ID, that fact is automatically reflected in each authentication server. On the other hand, depending on the environment, the user ID may be manually distributed from the ID management program 111 to each authentication server. Therefore, in the second embodiment of the present invention, a configuration and an operation example in which it is possible to select whether the user ID is automatically or manually distributed will be described.

  FIG. 4 is a diagram illustrating an example of the user configuration information 112 according to the second embodiment. In the second embodiment, in addition to the contents described in FIG. 3 of the first embodiment, a “distribution type” column is newly added.

  In the “distribution type” column, whether the user ID assigned the user type specified by the value of the “user type” column is manually distributed to each authentication server, or is automatically distributed by the ID management program 111. Holds a value that specifies whether or not.

  When the value of this column is “automatic”, the ID management program 111 automatically distributes the user ID to the authentication server when the user ID is generated. When the value of this column is “manual”, the ID management program 111 only records the state change of the user ID in the user ID file 113 and does not perform distribution to the authentication server. In this case, an administrator or the like will later distribute manually.

  FIG. 5 is a flow of processing in which the ID management program 111 generates a user ID. Hereinafter, each step of FIG. 5 will be described.

(FIG. 5: Step S500)
This operation flow is started when the administrator of the ID management server 100 performs ID generation work and instructs the ID management program 111 to that effect. Other triggers, such as when receiving an ID creation from an external system, also fall under the conditions for starting this operation flow. However, for the sake of simplicity, the administrator etc. Assumption. The same applies to FIG. In this step, the ID management program 111 also receives a designation for the user type of the user ID to be generated.

(FIG. 5: Step S501)
The ID management program 111 generates the user ID specified in step S500 and records it in the user ID file 113.

(FIG. 5: Step S502)
The ID management program 111 collates the user type specified in step S500 with the value of the “user type” column defined in the user configuration information 112, and the “distribution type” column corresponding to the value of the user type Get the value of. If the value of the “distribution type” column is “automatic”, the process proceeds to step S503, and if not, the operation flow ends.

(FIG. 5: Step S503)
The ID management program 111 distributes the user ID generated in step S501 to the authentication server.

  FIG. 6 is a flow of processing in which the ID management program 111 deletes the user ID. Hereinafter, each step of FIG. 6 will be described.

(FIG. 6: Step S600)
This operation flow is started when an administrator of the ID management server 100 performs ID deletion work and instructs the ID management program 111 to that effect. In this step, the ID management program 111 receives a designation for the user ID to be deleted.

(FIG. 6: Step S601)
The ID management program 111 determines whether the user ID instructed to be deleted in step S600 is valid. A user ID that is not valid refers to a user ID that is substantially not managed by the ID management program 111, such as a user ID that is in the process of being deleted. If the user ID is valid, the process proceeds to step S602. If the user ID is not valid, the operation flow ends.

(FIG. 6: Step S602)
The ID management program 111 determines whether “scheduled deletion” is specified in the life cycle of the user ID instructed to be deleted in step S600. If “schedule deletion” is designated, the process proceeds to step S603, and if not designated, the process proceeds to step S605.

(FIG. 6: Step S603)
The ID management program 111 changes the state of the user ID instructed to be deleted in step S600 to “schedule deletion”, and records that fact in the user ID file 113. The user ID is suspended from being deleted until the expiration date defined in the user configuration information 112 elapses.

(FIG. 6: Step S604)
The ID management program 111 reflects the state of the user ID on the corresponding user ID on the authentication server.

(FIG. 6: Step S605)
The ID management program 111 determines that “physical deletion” is designated in the life cycle of the user ID, and deletes the record of the user ID from the user ID file 113.

(FIG. 6: Step S606)
The ID management program 111 reflects that the user ID has been deleted in the corresponding user ID on the authentication server.

  FIG. 7 is a flow of processing in which the ID management program 111 checks the expiration date of the user ID. Hereinafter, each step of FIG. 7 will be described.

(FIG. 7: Step S700)
The ID management program 111 starts this operation flow at a predetermined time interval or the like.

(FIG. 7: Step S701)
The ID management program 111 searches the user IDs recorded in the user ID file 113 for those for which “schedule deletion” is specified in the life cycle. If there is a user ID for which “schedule deletion” is designated, the process proceeds to step S702, and if not, this operation flow is terminated.

(FIG. 7: Step S702)
The ID management program 111 lists the user IDs searched for in step S701 that have expired. If there is an expired user ID, the process proceeds to step S703, and if not, the operation flow ends.

(FIG. 7: Step S703)
The ID management program 111 deletes the expired user ID listed in step S <b> 702 from the user ID file 113.

(FIG. 7: Step S704)
The ID management program 111 reflects that the user ID has been deleted in the corresponding user ID on the authentication server.

  The operation of the ID management program 111 has been described above. 5 to 7, only when the user ID is generated, it is determined whether the “distribution type” is “automatic” or “manual”. However, even when the user ID is deleted, “ The value of “distribution type” may be checked.

  As described above, in the second embodiment, the “distribution type” column is newly provided in the user configuration information 112, and the timing at which the ID management program 111 distributes the user ID managed on the user ID file 113 to the authentication server is set. Enabled selection. Thereby, the process which synchronizes user ID between the ID management server 100 and an authentication server can be comprised more flexibly.

<Embodiment 3>
In the third embodiment of the present invention, a specific example of the process of synchronizing the user ID managed by the ID management server 100 (ID management program 111) and the user ID managed by the authentication server, that is, the ID distribution process I will explain.

  FIG. 8 is a diagram illustrating a life cycle of user IDs belonging to each user type described in FIG. Hereinafter, each user type in FIG. 8 will be described.

(A) User type A
Since “manual” is designated as the “distribution type” for the user type A, the user ID exists only on the ID management server 100 (user ID file) when the ID management program 111 generates the user ID. . When the administrator of the ID management server 100 executes a manual distribution operation, the user ID is also distributed to the authentication server. When the user ID is deleted from the user ID file 113, the ID management program 111 instructs the authentication server to delete the user ID. When the user ID is deleted, the user ID does not exist on the user ID file 113, so that the user ID is substantially the same as the initial state in FIG. The fact that the user ID does not exist due to deletion is expressed as a “physical deletion” state.

(B) User type B
Since “automatic” is designated as the “distribution type” for the user type B, when the ID management program 111 generates a user ID, the user ID is automatically distributed to the authentication server. In the user type B, “logical deletion” is designated as the user ID deletion method. Therefore, when the administrator or the like instructs the user type B to delete the user ID, the ID management program 111 temporarily stores the user ID. Is written in the user ID file 113 to disable use (logical deletion). The ID management program 111 instructs the authentication server to temporarily disable the user ID. On the authentication server, the user ID is temporarily unavailable according to the specification of the authentication server. Here, the example which invalidates the said user ID was shown. Invalidation means a state in which the user ID itself exists but cannot be used.

(C) User type C
Since “automatic” is designated as the “distribution type” for the user type C, when the ID management program 111 generates a user ID, the user ID is automatically distributed to the authentication server. In the user type C, “schedule deletion” is designated as the user ID deletion method. Therefore, when the administrator or the like instructs the user type C to delete the user ID, the user ID is set to “scheduled”. “Delete” is written in the user ID file 113. The ID management program 111 instructs the authentication server to temporarily disable the user ID. On the authentication server, the user ID is temporarily unavailable according to the specification of the authentication server. When the expiration date of the user ID elapses, the ID management program 111 deletes the user ID from the user ID file 113 and instructs the authentication server to delete the user ID.

  As described above, in the third embodiment, a specific example is given of the ID distribution processing that synchronizes between the user ID managed by the ID management server 100 (ID management program 111) and the user ID managed by the authentication server. explained.

<Embodiment 4>
In the first to third embodiments, it has been described that the ID management server 100 (ID management program 111) distributes the user ID and its state to the authentication server. For example, the “logically deleted” state and the “scheduled deleted” state mean that the user ID cannot be temporarily used, and therefore it is necessary to reflect that fact on the corresponding user ID on the authentication server. is there. In FIG. 8 of the third embodiment, the example in which the user ID on the authentication server is invalidated has been described.

  However, depending on the specification of the authentication server, the user ID state “temporarily unavailable” may not exist. In such a case, the state of the user ID managed by the ID management program 111 and the state of the user ID managed by the authentication server cannot be matched.

  In such a case, the ID management program 111 can use the following method in order to invalidate the user ID on the authentication server.

(Pseudo invalidation of user ID: Example 1)
The ID management program 111 instructs the authentication server to randomly change the password for the user ID that is in the “logical deletion” state or the “scheduled deletion” state. The authentication server randomly changes the password of the user ID so that the user cannot use it. Thereby, since the user ID is substantially unusable, the same effect as when the user ID is invalidated can be exhibited. When re-enabling the user ID, the password may be initialized.

(Pseudo invalidation of user ID: Example 2)
The ID management program 111 instructs the authentication server to randomly change the user ID itself for the user ID that has entered the “logic delete” state or the “planned delete” state. The authentication server randomly changes the user ID so that the user cannot use it, and stores the original user ID. Thereby, since the user ID is substantially unusable, the same effect as when the user ID is invalidated can be exhibited. In order to validate the user ID again, the stored user ID may be restored.

  As described above, in the fourth embodiment, when invalidating a user ID on the authentication server is not supported, a method for pseudo-invalidating the user ID and a method for re-enabling the user ID have been described.

<Embodiment 5>
In the first to fourth embodiments, it has been described that the ID management program 111 manages the user ID and distributes the user ID to the authentication server. However, the ID managed by the ID management program 111 is not limited to the user ID, and any type of ID can be targeted.

  Similarly, the target for distributing the ID managed by the ID management program 111 is not limited to the authentication server that authenticates the user, but can be any type of server or other computer.

  100: ID management server, 110: storage unit, 111: ID management program, 112: user configuration information, 113: user ID file, 120: CPU, 130: memory, 200a to 200c: computer, 300: authentication server, 401 403: LAN, 500a to 500c: computer, 600: authentication server.

Claims (4)

A program for causing a computer to execute a step of managing a user ID,
In the computer,
Reading the configuration information defining the method of deleting the ID and the type of the ID ;
An ID generation step of generating the ID and registering it in a database;
A deletion instruction receiving step for receiving an instruction that the ID should not be used;
An ID deletion step for preventing the ID from being used in accordance with the instruction received in the deletion instruction receiving step;
And execute
The configuration information defines at least two types of deletion methods, physical deletion and scheduled deletion, as a method for deleting IDs ,
The configuration information further includes, as the type of the ID, the first type that performs the physical deletion when receiving an instruction to delete the ID, and the scheduled deletion when receiving an instruction to delete the ID And the second type that implements
The configuration information further defines an expiration date from the scheduled deletion of the ID belonging to the second type,
In the ID generation step, the computer
Receiving an instruction to generate the ID by designating the first type or the second type, and performing a process of storing the ID and the type of the designated ID in the database according to the instruction,
In the ID deletion step, the computer
The type of the ID indicated in the deletion instruction receiving step is read from the database,
For the ID belonging to the first type, as the implementation of the physical deletion, the record of the ID is immediately deleted from the database,
For the ID belonging to the second type, after the information indicating that the ID is temporarily disabled is written in the database as the execution of the scheduled deletion, the deletion of the ID is temporarily suspended and the effective An ID management program that deletes the ID from the database when the time limit elapses. Claim 1 Symbol placement ID management program, characterized in that to perform the ID distribution step of reflecting the ID registered in the database to other computers in the computer. In the ID distribution step, the computer
3. The ID management program according to claim 2, wherein the ID in which information indicating that the database is temporarily disabled on the database is written is temporarily invalidated in the other computer. 4. . In the ID distribution step, the computer
4. The ID for which information indicating that it is temporarily disabled on the database is written, the password of the ID in the other computer is randomly changed. ID management program.

Images