JP2015103194A - Mail address control system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To solve the problems in which: an initial user whose mail address has been incorrectly registered cannot receive log-in information and log-in to a service, and in multi-tenant architecture, the user cannot acquire log-in information and correct the mail address from the outside of a tenant; after the initial user has started the use of the service, there is no need to notify the initial user of the log-in information, and therefore, processing for inhibiting re-notification is needed.SOLUTION: When an initial user does not start the use of a mail address control system, the system receives a correction request of a mail address, and issues a unique value and then temporarily stores in association with the mail address. When the initial user logs in the system for the first time, the system acquires the mail address from the unique value included in the log-in for the first time, and updates the mail address of the initial user under the authority of the initial user and updates the usage state as well.

Description

  The present invention relates to a mail address management system in a multi-tenant environment, and more particularly to a method of managing an initial user mail address.

  In recent years, there are many businesses that provide services to customers using servers installed on the Internet, such as cloud services. In such a service, since the server manages data of a plurality of customer companies, a multi-tenant architecture is adopted. When a service employing a multi-tenant architecture provides a service to a customer company, the service provider creates a new tenant and assigns it to the customer company. Create an initial user to manage the newly created tenant on the customer company side and register it with the tenant. The administrator of the customer company can log in to the service as the created initial user, add the user to the assigned tenant, and set the necessary settings so that the customer company can start using the service.

  In order for the administrator of the customer company to log in to the service, the login information of the initial user is required. Examples of the login information include an ID / password pair and an initial login URL that can be used only when the user logs in for the first time. When the service provider obtains such information, the service provider can access information in the tenant that should be accessible only to the customer company.

  In order to avoid such a problem, the user's mail address may be registered when an initial user is created, and login information may be transmitted to the registered mail address. By doing so, the administrator of the client company can log in to the service without the service provider knowing the login information.

  Consider the case where the email address registered to the user is incorrect. In such a case, the user cannot receive mail sent by the service. Therefore, there is a method (Patent Document 1) that prompts the user to change to the correct email address by notifying that the email address is incorrect when the user logs in when the email address registered to the user is incorrect. It was.

Japanese Patent Laid-Open No. 2002-351785

  However, the conventional method has the following problems. That is, if the e-mail address notifying the login information of the initial user is registered by mistake, the administrator at the customer company side cannot log in to the service and cannot correct the e-mail address. In the multi-tenant architecture, even if it is a service providing side, information in the tenant on the customer company side cannot be corrected, and login information is not known. As a result, tenants and initial users created for customer companies cannot be used.

  Since it is no longer necessary to notify the initial user of login information after the initial user starts using the service, a process for prohibiting re-notification is also necessary. A lot of customer company information is stored in the tenant that has started to be used, but if re-notification of login information is not prohibited, login information can be notified to users who do not belong to the customer company, and there is a possibility of information leakage There is also.

  The present invention has been made in view of the above-described problems.

In a system where tenants are separated, an initial user is created at the time of tenant creation, and the email address of the created initial user is set and managed.
Usage status management means (306, S603, S808) for managing whether the created initial user has started to use the system;
A correction request receiving means (301, S604) for receiving a correction request for the mail address set for the created initial user when the created initial user has not started using the system (S603);
Issuing means (304, S503) for issuing a unique value;
Storage means (305, S504) for temporarily storing the unique value in association with a user identifier for identifying the initial user and a new mail address received by the receiving means;
An initial login acceptance means (351, S701) for accepting an initial login to the system;
With
The initial login accepting unit includes an acquiring unit (351, S704) for acquiring the unique value included in the initial login;
Using the e-mail address corresponding to the acquired unique value included in the storage means, the e-mail address of the initial user is updated with the authority of the initial user corresponding to the acquired unique value (351, S803). Updating means (351, S805) to perform,
Usage status update means (351, S808) for updating the usage status as the initial user starts using the system;
An e-mail address management system comprising:

  According to the present invention, the login information can be re-notified to the initial user who has registered with the wrong e-mail address at the time of creation, and the initial user can log in to the service. In addition, upon notification, the mail address can be corrected, and the correct mail address can be set as user information.

  Furthermore, when the user starts using the service, the service provider cannot notify again, so that it is possible to prevent an unintended third party from logging in to the tenant that has started using the service.

It is a figure which shows a network structure. It is a lineblock diagram of PC concerning an embodiment of the invention. It is a module block diagram concerning this Embodiment. It is a flow of tenant creation concerning this embodiment. It is a flow which notifies login information concerning this embodiment. It is a flow in which the initial user according to the present embodiment logs into the service for the first time. It is an example of the screen for service providing users according to the present embodiment. It is an example of the screen for initial users concerning this Embodiment. It is an example of data concerning this embodiment. It is a module block diagram which concerns on the 2nd Embodiment. It is a flow of the password reset which concerns on the 2nd Embodiment. It is an example of the screen of the password reset which concerns on the 2nd form of this Embodiment.

  The best mode for carrying out the present invention will be described below with reference to the drawings.

  The mail address management system according to the present embodiment is realized on a network configured as shown in FIG.

  Reference numeral 100 denotes a wide area network (WAN 100), and in the present invention, a World Wide Web (WWW) system is constructed. Reference numeral 101 denotes a local area network (LAN 101) for connecting each component.

  Reference numeral 200 denotes a client PC operated by the user, 300 denotes a tenant management server that manages the tenant and users belonging to the tenant, and 350 denotes an authentication server that authenticates the user.

  The client PC 200, the tenant management server 300, and the authentication server 350 are connected via the WAN network 100 and the LAN 101, respectively. The client PC 200 and each server may be configured on individual LANs or may be configured on the same LAN. Further, they may be configured on the same PC or server computer. For example, the authentication server 350 may be configured on a server computer in which the tenant management server 300 is configured.

  Each of the tenant management server 300 and the authentication server 350 operates on a server computer described later.

  FIG. 2 is a diagram showing a configuration of the client PC 200 according to the present embodiment. The configuration of the server computer of the tenant management server 300 and the authentication server 350 is the same. The hardware block diagram shown in FIG. 2 corresponds to the hardware block diagram of a general information processing apparatus, and the hardware configuration of a general information processing apparatus is used for the client PC 200 and the server computer of this embodiment. Can be applied.

  In FIG. 2, the CPU 201 executes a program such as an OS or an application stored in the program ROM of the ROM 203 or loaded from the hard disk 211 to the RAM 202. Here, the OS is an abbreviation for an operating system running on a computer, and the operating system is hereinafter referred to as an OS. The processing of each flowchart to be described later can be realized by executing this program. The RAM 202 functions as a main memory, work area, and the like for the CPU 201.

  A keyboard controller (KBC) 205 controls key input from a keyboard (KB) 209 or a pointing device (not shown). A CRT controller (CRTC) 206 controls display on the CRT display 210. A disk controller (DKC) 207 controls data access in a hard disk (HD) 211 or a floppy (registered trademark) disk (FD) that stores various data. The NC 212 is connected to the network and executes communication control processing with other devices connected to the network.

  In all the descriptions below, unless otherwise specified, the execution hardware main body is the CPU 201, and the software main body is an application program installed in the hard disk (HD) 211.

  FIG. 3 is a diagram showing module configurations of the tenant management server 300 and the authentication server 350 according to the present embodiment. 3A shows the module configuration of the tenant management server 300, and FIG. 3B shows the module configuration of the authentication server 350. The tenant management server 300 has a tenant management module 301, a mail address storage module 302, and a mail notification module 303. It also has a URL generation module 304, a URL storage module 305, and a usage status management module 306. The authentication server 350 has an initial login processing module 351.

  FIG. 4A shows a flow of processing in which the tenant management server 300 creates a tenant according to the operation of the service providing user according to the present embodiment. This flow starts when the user operates the tenant management server 300.

  In step S401, the tenant management module 301 receives initial user information of a tenant to be created. It also accepts designation of whether to send a notification email to the user at the same time that tenant creation is completed. Here, the initial user information includes a user ID and a mail address. The email address may be omitted. The screen displayed in step S401 is, for example, a tenant creation screen as indicated by 1001 in FIG.

  In step S402, the tenant management module 301 creates a user with the specified information.

  In step S403, the tenant management module 301 creates a tenant. Also, the user created in step S402 is registered in the created tenant as an initial user.

  In step S404, the mail address storage module 302 temporarily stores the mail address designated in step S401 in association with the designated user ID. This is stored in an area different from the user information of the user created in step S402. If the e-mail address is not specified in step S401, the fact that it has been omitted is stored. The information stored in step S404 is stored in a mail address temporary storage table as indicated by 1500 in FIG. 9A, for example.

  In step S405, the tenant management module 301 determines whether the e-mail address of the initial user has been specified in step S401. If the e-mail address is specified as a result of the determination, the process proceeds to step S406. If the e-mail address is omitted, the flow ends.

  In step S406, the tenant management module 301 determines whether it has been designated to send a notification mail in step S401. If the notification is specified as a result of the determination, the process proceeds to step S407. If no notification is specified, the flow is terminated.

  In step S407, the mail notification module 303 notifies the login information of the initial user to the mail address temporarily stored in step S404. When the notification is completed, the flow ends.

  FIG. 4B shows an example of processing for notifying login information to the initial user in accordance with the operation of the service providing user according to the present embodiment. This flow is a detailed flow of step S407 in FIG. The detailed flow of step S608 in FIG. 5 is also the same.

  In step S501, the mail notification module 303 acquires the user ID of the initial user who is the notification destination of login information.

  In step S502, the mail notification module 303 extracts the mail address temporarily stored in association with the user ID acquired in step S501 from the mail address storage module 302.

  In step S503, the URL generation module 304 generates an initial login URL for an initial user who is a notification destination of login information.

  In step S504, the URL storage module 305 stores the URL generated in step S503 in association with the user ID / mail address pair extracted in step S502. In this case, the URL expiration date is also set. The information stored in step S404 is stored in an initial login URL temporary storage table, for example, as indicated by 1550 in FIG.

  In step S505, the mail address storage module 302 transmits the user ID acquired in step S501 and the initial login URL generated in step S503 to the mail address extracted in step S502, and ends the flow.

  FIG. 5 shows an example of processing for notifying login information to the initial user of the created tenant in accordance with the operation of the service providing user according to the present embodiment. This flow is performed, for example, when the login information is notified to the correct e-mail address when the login information is to be notified to the e-mail address registered with the initial user but the e-mail address is incorrect. In addition, the process is also performed when the user is not notified in the flow of FIG. 4A (when No in step S405 or step S406).

  In step S601, the tenant management module 301 receives designation of a tenant that notifies login information. The screen displayed here is, for example, a tenant designation screen as indicated by 1101 in FIG.

  In step S602, the tenant management module 301 acquires the initial user of the tenant designated in step S601.

  In step S603, the usage status management module 306 determines whether the initial user acquired in step S603 has started using the service. If it is determined that the use has not started, the process proceeds to step S604. If it is determined that the use has started, the process proceeds to step S650.

  In step S604, the tenant management module 301 accepts designation of an e-mail address that is a notification destination. The screen displayed here is, for example, a mail address designation screen as indicated by 1102 in FIG. When the mail address designation screen 1102 is displayed on the screen, the mail address associated with the initial user acquired in step S602 may be displayed.

  In step S605, the mail address storage module 302 determines whether the mail address associated with the initial user acquired in step S602 is stored. If it is determined that the mail address is associated and stored, the process proceeds to step S606. If it is determined that the mail address is not associated and stored, the process proceeds to step S607.

  In step S606, the mail address storage module 302 deletes the mail address temporarily stored in association with the initial user acquired in step S602 from the storage.

  In step S607, the mail address storage module 302 temporarily stores the mail address specified in step S604 in association with the user ID acquired in step S602.

  In step S608, the mail notification module 303 notifies the login information of the initial user to the mail address temporarily stored in step S607. When the notification is completed, the flow ends.

  In step S650, the tenant management module 301 displays that the target user has already started use and cannot perform a notification operation, and ends the flow.

  FIG. 6A shows an example of the process of the initial login flow when the initial user who has received the notification logs in to the service for the first time, according to the present embodiment.

  In step S701, the initial login processing module 351 accepts access to the initial login URL by the initial user.

  In step S702, the initial login processing module 351 inquires the URL storage module 305 and determines whether the accessed URL is valid. If it is determined that the URL is valid, the process proceeds to step S703. If it is determined that the URL is invalid, the process proceeds to step S750. Here, the validity of the URL is determined by checking whether it is included in the storage of the URL storage module 305 and whether it is within the expiration date.

  In step S703, the initial login processing module 351 displays an initial login screen 1201 as shown in FIG. 8A and accepts input of a user ID.

  In step S704, the initial login processing module 351 makes an inquiry to the URL storage module 305 and extracts the user ID corresponding to the accessed initial login URL.

  In step S705, the initial login processing module 351 compares the user ID received in step S703 with the user ID acquired in step S704. As a result of the comparison, if the two match, the process proceeds to step S706. If they do not match, the process proceeds to step S750.

  In step S706, the initial login processing module 351 sets the state of the user ID matched in step S705 to the use start state, and ends the flow.

  In step S750, the initial login processing module 351 notifies the user that the access is unauthorized, and ends the flow.

  FIG. 6B shows an example of processing according to the present embodiment for setting the user ID to the use start state according to the operation of the initial user who has received the notification. This flow is a detailed flow of step S706 in FIG.

  In step S801, the initial login processing module 351 displays a password setting screen 1202 as shown in FIG. 8B and accepts input of a new password.

  In step S802, the initial login processing module 351 registers the password received in step S801 as the password of the user ID to be processed.

  In step S803, the initial login processing module 351 logs in to the service as the user with the target user ID using the password received in step 801.

  In step S804, the initial login processing module 351 inquires the URL storage module 305 and the email address storage module 302, and acquires the email address corresponding to the accessed initial login URL.

  In step S805, the initial login processing module 351 rewrites the target user's email address with the email address acquired in step S804, using the authority of the user who logged in in step S803.

  In step S806, the initial login processing module 351 deletes the temporary storage of the initial login URL associated with the user ID of the target user from the URL storage module 305.

  In step S <b> 807, the initial login processing module 351 deletes the temporary storage of the mail address associated with the user ID of the target user from the mail address storage module 302.

  In step S808, the initial login processing module 351 requests the usage status management module 306, changes the target user ID to the usage start state, and ends the flow.

  FIG. 7 is an example of a screen displayed according to the operation of the service providing user according to the present embodiment.

  FIG. 7A shows a tenant creation screen 1001 for receiving initial user information of a tenant to be created. The service providing side user operates this screen and designates the user ID and the mail address as the initial user information of the tenant to be created. It also specifies whether to send a notification email to the user as soon as tenant creation is complete.

  FIG. 7B shows a tenant designation screen 1101 for designating a tenant for notifying login information. The service providing side user specifies the tenant to notify the login information by entering the tenant ID on this screen.

  FIG. 7C shows a mail address designation screen 1102 for designating designation of a mail address as a notification destination. The service provider user can send the login information of the initial user of the target tenant to the entered email address by entering the email address on this screen.

  FIG. 8 shows an example of a screen displayed according to the operation of the initial user who has received the notification according to the present embodiment.

  FIG. 8A shows an initial login screen 1201 for accepting input of a user ID. In this screen, in order to confirm whether the initial login URL accessed by the user is the intended user, the user ID is requested to be input.

  FIG. 8B shows a password setting screen 1202 for setting a new password. If the user ID entered by the user on the initial login screen 1201 is correct, this screen is displayed, and the user can set a password by himself. The user can log in to the service using the password set here.

  FIG. 9 shows an example of data according to the present embodiment.

  FIG. 9A shows a mail address temporary storage table 1500. This table temporarily stores a user ID and a notification destination mail address for notifying login information of the user ID. When the service providing user performs an operation of notifying the initial user of login information, the user ID and the mail address are registered in this table. When the initial user accesses the initial login URL, the mail address registered in this table is referred to, and the mail address registered for the user is updated.

  FIG. 9B shows an initial login URL temporary storage table 1550. This table temporarily stores the initial login URL and the URL expiration date in association with the user ID and email address pair stored in the email address temporary storage table 1500. When the service providing user performs an operation of notifying the initial user of login information, the initial login URL is registered in this table. When the initial user accesses the initial login URL, this table is referred to and the validity of the URL is confirmed.

  According to the present embodiment, the login information can be re-notified to the initial user who has registered with the wrong e-mail address at the time of creation, and the initial user can log in to the service. In addition, upon notification, the mail address can be corrected, and the correct mail address can be set as user information.

  Furthermore, when the user starts using the service, the service provider cannot notify again, so that it is possible to prevent an unintended third party from logging in to the tenant that has started using the service.

  Next, a second embodiment for carrying out the present invention will be described with reference to the drawings. Note that description of parts common to the first embodiment will be omitted, and only different parts will be described below.

  The user who has received the login information can obtain the user ID from the mail text and the mail address from the mail address. If the user can reset the password using the user ID and the e-mail address, the user can use the service without accessing the initial login URL. For this reason, the re-notification of login information by the service providing user is not prohibited. Therefore, in the following, a method for preventing a user who has not started using password resetting will be described.

  FIG. 10 is a module configuration diagram of the authentication server 350 according to the second embodiment. The authentication server 350 has an initial login processing module 351 and a password reset module 352. The password reset module 352 accepts a user ID and an e-mail address, and resets the password of the user ID when the correspondence is correct, and is used when the user forgets the password.

  FIG. 11 is a password reset flow according to the second embodiment. This flow starts when the user performs an operation provided in case the user forgets the password.

  In step S901, the password reset module 352 receives access to the password reset screen. What is displayed here is a password reset screen 2001 as shown in FIG.

  In step S902, the password reset module 352 receives an input of a user ID of a user whose password is to be reset and an e-mail address registered for the user.

  In step S903, the password reset module 352 checks the correspondence between the user ID input in step S902 and the mail address. As a result of the confirmation, if it is determined that the input mail address is that of the user ID, the process proceeds to step S904. If it is determined that the input mail address is not that of the user ID, the process proceeds to step S950.

  In step S904, the password reset module 352 makes an inquiry to the usage status management module 306 and confirms whether or not the user ID input in step S902 has been started. If the user ID has not been started, the process proceeds to step S905. If the user ID has already been used, the process proceeds to step S950.

  In step S905, the password reset module 352 transmits information for resetting the password of the user ID input in step S902 to the e-mail address input in step S902, and ends the flow.

  In step S950, the password reset module 352 notifies the user that the operation is unauthorized, and the flow ends.

  FIG. 12 shows an example of a screen displayed when the user performs a password reset operation according to the second embodiment. A password reset screen 2001 prompts for input of a user ID of a user whose password is to be reset and an e-mail address registered for the user. If the correspondence between the input user ID and the e-mail address is correct, a password reset process is performed.

  According to the second embodiment, a user who has not started use cannot reset the password, and the service can be prevented from being used without prohibiting re-notification of login information by the service providing side user.

100 WAN
101 LAN
200 client PC
300 Tenant Management Server 302 Mail Address Storage Module 305 URL Storage Module 306 Usage Status Management Module 350 Authentication Server 351 Initial Login Processing Module 351

Claims (2)

In a system where tenants are separated, an initial user is created at the time of tenant creation, and the email address of the created initial user is set and managed.
Usage status management means (306, S603, S808) for managing whether the created initial user has started to use the system;
A correction request receiving means (301, S604) for receiving a correction request for the mail address set for the created initial user when the created initial user has not started using the system (S603);
Issuing means (304, S503) for issuing a unique value;
Storage means (305, S504) for temporarily storing the unique value in association with a user identifier for identifying the initial user and a new mail address received by the receiving means;
An initial login acceptance means (351, S701) for accepting an initial login to the system;
With
The initial login accepting unit includes an acquiring unit (351, S704) for acquiring the unique value included in the initial login;
Using the e-mail address corresponding to the acquired unique value included in the storage means, the e-mail address of the initial user is updated with the authority of the initial user corresponding to the acquired unique value (351, S803). Updating means (351, S805) to perform,
Usage status update means (351, S808) for updating the usage status as the initial user starts using the system;
An e-mail address management system comprising: The email address management system
Has password reset means (352, S901) for resetting the password set for the user,
The password reset means is a reset information accepting means (352, S902) for accepting a user identifier and an email address for password reset;
A reset information confirmation unit (352, S903) for confirming whether the information received by the reset information reception unit prior to password reset is valid;
With
A reset permission unit (352, S904) for permitting a password reset when a user corresponding to the user identifier received by the reset information receiving unit has started using the system;
The mail address management system according to claim 1, further comprising: