JP5193787B2 - Information processing method, relay server, and network system - Google Patents

Description

  The present invention relates to a technique for making it possible to use a plurality of applications requiring authentication by inputting authentication information (such as an ID and a password) once.

  In recent years, various web application services are provided on the Internet by various organizations or companies, and are widely used by users. Many of these Web applications provide a convenient application service for each user by authenticating the user using a user ID and password issued to the user who has registered the user. Therefore, as the number of Web applications to be used increases, user IDs and passwords held by users also increase. Therefore, for the user, a plurality of user IDs and passwords must be properly used for each Web application, which is complicated. In this case, the following situation occurs as an example. A user provides a portal site service that provides services such as blogs, online auctions, and Web mail, online banking services for banks, online trade services for securities companies, electronic application services for local governments, and online electricity for electric power companies. Suppose you are using a start / stop service. Usually, since five organizations of a portal site, a bank, a securities company, a local government, and a power company individually manage users, it is necessary for this user to properly use five types of user IDs and passwords.

  As a technique for avoiding complicated use of the user ID and password, a technique called single sign-on is generally known. Single sign-on is a technique that enables a plurality of applications requiring authentication to be used by inputting authentication information (such as an ID and a password) once. For example, if user authentication is performed at a certain website or a Third-Party Security Service (hereinafter referred to as “authentication site”), log-on operations will not be performed when accessing other websites. There is known a user authentication technique that becomes unnecessary (see, for example, Patent Document 1 and Non-Patent Document 1).

JP 2003-58503 A Assassions and Pppppols for the OASIS Security Assessment Markup Language (SAML) V2.0, OASIS Standard, 15 March 2005, p. 11, FIG. 4. [Search July 22, 2008] Internet <URL: http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>

  Since the above prior art is based on the premise that each Web site accepts the authentication result at the authentication site, a trust relationship needs to be established between each Web site and the authentication site. Therefore, in the above prior art, an authentication site is provided in one organization that can easily build such a trust relationship, and the authentication result in this authentication site is used in the Web site possessed by each department in the organization. It is realistic to use it as an in-house authentication platform, or between companies that are affiliated with each other. Taking the five organizations described above as an example, it is possible to realize a network system in which a plurality of systems in one organization such as a blog, a net auction, and a web mail share an authentication site in the portal site.

  However, in reality, it has been difficult to realize a network system in which a plurality of systems that are not in a mutual trust relationship or cooperative relationship such as a portal site, a bank, a securities company, a local government, and a power company share an authentication site. However, the prior art does not describe a technique for solving this problem.

  The object of the present invention is to use a plurality of applications that require authentication by inputting authentication information (such as ID and password) once in a network system composed of a plurality of systems that are not in a trust relationship or cooperative relationship with each other. It is to provide the technology.

  A typical example of the present invention is as follows. That is, the present invention is an information processing method in a relay server connected to a plurality of user terminals and a plurality of Web servers. The relay server identifies the same user with user identification information for identifying the user by the web server, link information to the web server, and information issued for the combination of the user identification information and the link information. The same user information storage unit that stores information for identification in association with each other. The relay server indicates that the user authentication is successful from the first Web server, the first user identification information constituting the user authentication information, the link information to the first Web server, the second The same user information storage unit based on the first user identification information included in the received message and the link information to the first Web server. The second Web server acquires second user identification information for identifying the user, and the first user identification information included in the received message is used as the second user identification information. Rewrite and send the message to the second Web server.

  According to the present invention having the above features, in a network system composed of a plurality of systems that are not in a trust relationship or cooperative relationship with each other, a plurality of authentication items that require authentication by inputting authentication information (such as an ID and a password) once. A technique for making an application available can be provided.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

  FIG. 1 is a diagram showing an example of the overall configuration of a network system 1 to which the present invention is applied. The network system 1 is a system including a plurality of Web servers 10 and 11, a relay server 12, and a plurality of user terminals 13 connected to a network 14 such as the Internet. The present embodiment will be described by distinguishing the plurality of Web servers from the Web servers 10 and 11, respectively, as shown in FIG. The Web servers 10 and 11 include not only a narrowly defined Web server that provides static content, but also a server called an AP server that dynamically generates content and content material, a reverse proxy that has an authentication function, and the like. .

  FIG. 2 is a diagram illustrating a hardware configuration example of the Web servers 10 and 11. Web servers 10 and 11 include an output unit 1011 such as a display, an input unit 1021 such as a keyboard and a mouse, a control unit 1031 such as a CPU (Central Processing Unit), a RAM (Random Access Memory), a HDD (Hard Disk Drive), and the like. A storage unit 1041 and a network interface unit 1051 such as a LAN (Local Area Network) card for transmitting and receiving information to and from other computers (user terminal 13 and relay server 12) via the network 14 are provided.

  The storage unit 1041 stores various programs executed by the control unit 1031 and various data used when the programs are executed. As shown in FIG. 2, the various programs include a user authentication function 201, a user authentication information change function 202, a user authentication information operation recording function 203, a user attribute information update function 204, a user attribute information operation recording function 205, an authentication strength generation / A calculation function 206, an authenticated message generation / notification function 207, an authenticated user re-authentication function 208, and a Web application 209 are included. Various data is stored in the user authentication information database 210, the user authentication information operation policy file 211, the user authentication information operation record database 212, the user attribute information database 213, the user attribute information operation policy file 214, and the user attribute information operation record database 215. Recorded or listed.

  The user authentication function 201 compares the user authentication information (for example, user ID and password) from the user terminal 13 with the user authentication information (for example, user ID and password) stored in the user authentication information database 210. Authenticate. The user authentication information change function 202 changes the user authentication information stored in the user authentication information database 210 in response to a user authentication information change request from the user terminal 13. When the user authentication information changing operation 203 is performed by the user, the user authentication information operation recording function 203 records the operation date / time and operation content in the user authentication information operation recording database 212 in association with the user ID. Upon receiving a user attribute information update request from the user terminal 13, the user attribute information update function 204 updates the user attribute information stored in the user attribute information database 213. When the user attribute information change operation 205 is performed by the user, the user attribute information operation recording function 205 records the operation date and time, operation content, and the like in the user attribute information operation recording database 215 in association with the user ID. The authentication strength generation / calculation function 206 generates or calculates authentication strength information based on the operation rule definition 405 described in the user authentication information operation policy file 211 when a user authentication information change operation is performed by the user. And recorded in the user authentication information operation record database 212 in association with the corresponding user ID. Further, the authentication strength generation / calculation function 206, when a user attribute information change operation is performed by the user, is based on the operation rule definitions 709 and 710 described in the user attribute information operation policy file 214. Is generated or calculated and recorded in the user attribute information operation record database 215 in association with the corresponding user ID. The authenticated message generation / notification function 207 indicates that the user authentication is successful as a result of the user authentication by the user authentication function 201 and indicates that the user authentication has been successful in the Web server, and includes a message ( This message is referred to as an “authenticated message” and is transmitted to the relay server 12 via the network 14. The authenticated user re-authentication function 208 stores, in the Web server, information related to the authentication strength included in the authenticated message from the other Web server and the user who has been successfully authenticated by the other Web server. Re-authenticate based on information related to authentication strength.

  FIG. 3 is a diagram illustrating a configuration example of the user authentication information database 210. In the user authentication information database 210, a user ID (user identification information) 301 and a password (secret information) 302 are stored in association with each other.

  FIG. 4 is a diagram illustrating a configuration example of the user authentication information operation policy file 211. The user authentication information operation policy file 211 includes a user authentication information definition unit 401 and a user authentication information operation rule unit 404. The user authentication information definition unit 401 includes a user ID definition 402 and a password definition 403, and defines restrictions on the data structure such as a minimum number of characters and a combination of characters (mixing alphabets and numbers). In the user authentication information operation rule unit 404, zero or more operation rule definitions 405 are described. The operation rule definition 405 includes, for example, the operation rule for which data defined by the user authentication information definition unit 401, the rule for which operation is targeted, the maximum frequency, and the maximum number of generations before Operation rules are defined such as whether or not re-use is prohibited. In the example illustrated in FIG. 4, the operation rule definition 405 defines restrictions such as updating a password within 6 months and reusing up to two generations at the time of update. .

  FIG. 5 is a diagram illustrating a configuration example of the user authentication information operation record database 212. In the user authentication information operation record database 212, the user ID 301, the operation date and time 501, the operation content 502, and the authentication strength 503 of the user who performed the user authentication information change operation are recorded in association with each other. The authentication strength 503 is generated or calculated by the authentication strength generation / calculation function 206 from, for example, the compliance level (or margin rate) of the operation rule defined in the operation rule definition 405. In the operation rule shown in Fig. 4, the password is renewed within 6 months and the reuse is defined as up to 2 generations ago. For example, if either of the conditions is not met, or both in the past The authentication strength C is renewed within 5 months and has not been reused until 3 generations ago, and the authentication strength B is the authentication strength B. It is recorded in the authentication strength 503 of the user authentication information operation record database 212 by the strength generation / calculation function 206.

  FIG. 6 is a diagram illustrating a configuration example of the user attribute information database 213. In the user attribute information database 213, user attribute information such as a user ID 301, a user name 601, an address 602, a sex 603, a date of birth 604, and an account number 605 are stored in association with each other.

  FIG. 7 is a diagram illustrating a configuration example of the user attribute information operation policy file 214. The user attribute information operation policy file 214 includes a user attribute information definition unit 701 and a user attribute information operation rule unit 702. The user attribute information definition unit 701 includes a user ID definition 703, a name definition 704, an address definition 705, a gender definition 706, a date of birth definition 707, an account number definition 708, and other information stored in the user attribute information database 213. , Restrictions on data structures such as the minimum number of characters are defined. In the user attribute information operation rule part 702, zero or more operation rule definitions are described. In the example illustrated in FIG. 7, the user attribute information operation rule unit 702 describes two operation rule definitions 709 and 710. The operation rule definition 709 describes that when creating a new name, address, gender, date of birth, and account number, it must be confirmed by an ID that can confirm residence. The operation rule definition 710 describes that confirmation by writing or telephone is required when updating the name, address, and gender.

  FIG. 8 is a diagram illustrating a configuration example of the user attribute information operation record database 215. In the user attribute information operation record database 215, the user ID 301, the operation date and time 801, the operation content 802, the operation target 803, the confirmation method 804, and the authentication strength 805 of the user who performed an operation such as updating user attribute information are associated with each other. Has been recorded. The authentication strength 805 is generated or calculated by the authentication strength generation / calculation function 206 from the compliance level (or margin rate) of the operation rules defined in the operation rule definitions 709 and 710. For example, in the operation rule 710 described in the user attribute information operation policy file 214 shown in FIG. 7, confirmation by writing or telephone is required, and if the confirmation is by writing in the face-to-face procedure, the authentication strength A is If it is confirmed by the above, the authentication strength B lower in strength than the document is recorded in the authentication strength 805 of the user attribute information operation record database 215 by the authentication strength generation / calculation function 206. Note that the information recorded in the authentication strength 805 is the strength related to the operation of the user attribute information, that is, the information indicating the certainty of the updated information if the user attribute information is updated. It may be a name (for example, “a copy of a resident's card”, “a driver's license 120 days after issuance”, “credit card company Z company usage statement notice”, etc.).

  FIG. 9 is a diagram illustrating a hardware configuration example of the relay server 12. The relay server 12 includes an output unit 1012 such as a display, an input unit 1022 such as a keyboard and a mouse, a control unit 1032 such as a CPU, a storage unit 1042 such as a RAM and an HDD, and another computer (Web server 10) via the network 14. 11) and a network interface unit 1052 such as a LAN card for transmitting and receiving information.

  The storage unit 1042 stores various programs executed by the control unit 1032 and various data used when the programs are executed. As shown in FIG. 9, the various programs include at least a user ID resolution function 901 and an authenticated message relay function 902. Various data are stored in the same user information database 903.

  The user ID resolution function 901 refers to the same user information database 903, and the user ID valid in the Web server 11 corresponding to the user ID valid in the Web server 10 (referred to as the first user ID) (Referred to as user ID). Note that the user ID valid in the Web server 10 or the Web server 11 indicates a user ID for identifying each user.

  FIG. 15 is a diagram illustrating a configuration example of the same user information database 903. As shown in FIG. 15, the same user information database 903 includes a cooperative user ID 1501, a URL to the Web server 10 (referred to as a first URL) 1502, and a URL to the Web server 11 (referred to as a second URL) 1503. Are stored in association with each other. The cooperative user ID 1501 is information serving as a key for resolving the second user ID corresponding to the first user ID, and is a combination of the URL to the Web server and the user ID for the Web server to identify the user. Issued against. In the same user information database 903, records having the same cooperative user ID indicate records relating to the same user.

  FIG. 10 is a diagram illustrating a hardware configuration example of the user terminal 13. The user terminal 13 includes an output unit 1013 such as a display, an input unit 1023 such as a keyboard and a mouse, a control unit 1033 such as a CPU, a storage unit 1043 such as a RAM and an HDD, and another computer (Web server 10) via the network 14. 11) and a network interface unit 1053 such as a LAN card for transmitting and receiving information.

  The storage unit 1043 stores various programs executed by the control unit 1033. As shown in FIG. 10, the various programs include a user authentication information acquisition / update function 1001, a user attribute information acquisition / update function 1002, and a service request / service relay request transmission function 1003.

  FIG. 11 is a sequence diagram showing an outline of processing of the entire network system 1. Each process illustrated in FIG. 11 is executed by a control unit included in each computer according to a program stored in the storage unit. Here, in order to simplify the description, each process will be described simply with the control unit as the execution subject.

  First, the control unit 1033 of the user terminal 13 acquires authentication information input by the user via the input unit 1023, and transmits an authentication request including the authentication information to the Web server 10 via the network 14 (step 1101). ).

  The control unit 1031 of the Web server 10 performs user authentication by comparing the received authentication information with the authentication information stored in the user authentication information database 210 (step 1102), and sends the authentication result to the user terminal via the network 14. 13 (step 1103). If the authentication fails as a result of the user authentication, the processing after step 1103 is not performed.

  If the authentication result indicates successful authentication in step 1103, the control unit 1033 of the user terminal 13 transmits a service request (Web application use request) to the Web server 10 via the network 14 (step 1104).

  In response to the service request, the control unit 1031 of the Web server 10 transmits a service screen indicating the execution result of the Web application 209 to the user terminal 13 via the network 14 (Step 1105). This service screen is output to the output unit 1013 of the user terminal 13. An example of the service screen is shown in FIG. In the example illustrated in FIG. 14, the service screen includes an online banking transfer service screen provided by the Web server 10 and a text box 1401 input screen for inputting a URL to another site. When the user inputs a second URL to the Web server 11 in the text box 1401 and performs an operation of pressing the send button 1402 using the input unit 1023, a new Web service screen is output to the output unit 1013. At the same time, the control unit 1033 of the user terminal 13 transmits a service relay request including the second URL to the Web server 10 via the network 14 (step 1106).

  The control unit 1031 of the Web server 10 indicates that the user authentication is successful in the Web server 10 and sends an authenticated message including information related to the first user ID, the first URL, the second URL, and the authentication strength. It is generated (step 1107) and transmitted to the relay server 12 via the network 14 (step 1108).

  The control unit 1032 of the relay server 12 refers to the same user information database 903, acquires a second user ID corresponding to the first user ID included in the authenticated message (step 1109), and sets the authenticated message as the authenticated message. The included first user ID is rewritten to the second user ID, and this authenticated message is transmitted to the Web server 11 via the network 14 (step 1110).

  The control unit 1031 of the Web server 11 identifies the user from the second user ID included in the authenticated message, and stores information related to the authentication strength included in the authenticated message and the storage unit 1041 of the Web server 11. The user is re-authenticated based on the information related to the authentication strength (step 1111), and the result is transmitted to the user terminal 13 via the network 14 (step 1112). If user authentication fails as a result of re-authentication, the processing after step 1112 is not performed.

  If the re-authentication result indicates successful authentication in step 1112, the control unit 1033 of the user terminal 13 transmits a service request to the web server 11 via the network 14 (step 1113).

  Upon receiving the service request, the control unit 1031 of the Web server 11 executes the corresponding Web application 209, and transmits a service screen indicating the execution result to the user terminal 13 via the network 14 (Step 1114). This service screen is output to the output unit 1013 of the user terminal 13.

  FIG. 12 is a flowchart showing detailed processing in the Web server 10 that generates an authenticated message and transmits it to the relay server 12 (FIG. 11—Steps 1107 and 1108). First, the control unit 1031 of the Web server 10 receives a service relay request transmitted from the user terminal 13 via the network 14 and the network interface unit 1051 (step 1201). Next, the control unit 1031 extracts the first user ID and the second URL from the received service relay request (step 1202). Next, the control unit 1031 searches the user authentication information operation record database 212 based on the first user ID, and acquires the user authentication information operation record from the corresponding record (step 1203). Next, the control unit 1031 searches the user attribute information operation record database 215 based on the first user ID, and acquires the user attribute information operation record from the corresponding record (step 1204). Next, the control unit 1031 includes the first user ID and second URL extracted in step 1202, information (url) indicating the storage location of the user authentication information policy file 211 described in advance in the program, and step 1203. Authenticated message including the user authentication information operation record acquired in step 1, the information (url) indicating the storage location of the user attribute information operation policy file 214 described in advance in the program, and the user attribute information operation record acquired in step 1204 It is generated (step 1205) and transmitted to the relay server 12 via the network 14 (step 1206). In step 1202 (FIG. 12), the first user ID is extracted from the service relay request. The method for realizing the first user ID includes a method of extracting the first user ID described as a parameter in the URL, A method for extracting the first user ID described in the HTTP header, a method for extracting the first user ID described as a parameter in the HTTP body, a cookie for session management and the user authentication information database 210 There are several implementation methods, such as a method for extracting a user ID. In step 1205, the url to the user authentication information operation policy file and the url to the user attribute information operation policy file are included in the authenticated message. However, the information entity described in each file is included in the authenticated message. It may be included.

  FIG. 13 is a diagram illustrating a configuration example of an authenticated message generated by the Web server 10. As shown in FIG. 13, the authenticated message includes a first user ID 1302, a first URL described in the From element and a second URL 1303 described in the To element, a user authentication information operation information unit 1304, a user An attribute information operation information unit 1305 is described. In the user authentication information operation information part 1304, a url 1306 to the user authentication information operation policy file 211 and a user authentication information operation record 1307 are described. The user attribute information operation information unit 1305 describes a url 1308 to the user attribute information operation policy file 214 and a user attribute information operation record 1309.

  FIG. 16 shows that the relay server 12 resolves the second user ID corresponding to the first user ID, rewrites the first user ID included in the authenticated message with the second user ID, and this authenticated message. FIG. 11 is a flowchart showing detailed processing (steps 1109 and 1110 in FIG. 11). Here, FIG. 16 will be described using specific parameters shown in FIGS. 13 and 15. First, the control unit 1032 of the relay server 12 receives the authenticated message transmitted from the Web server 10 via the network 14 and the network interface unit 1052 (step 1601). Next, the control unit 1032 receives the first user ID “100001” (1302), the first URL “https://www.test.com/” and the second URL “from the authenticated message (FIG. 13). “https://www.example.com/” (1303) is extracted (step 1602). Next, the control unit 1032 searches the same user information database 903 (FIG. 15) based on the first user ID “100001” 1302 and the first URL “https://www.test.com/” 1303. The cooperation ID “IDF000001” 1501 is acquired from the corresponding record (1503) (step 1603). Next, the control unit 1032 searches the same user information database 903 based on the cooperation ID “IDF000001” 1501 and the second URL “https://www.example.com/” 1303, and from the corresponding record (1504). The second user ID “20001” 301 is acquired (step 1604). Next, the control unit 1032 rewrites the first user ID “100001” (1302) of the authenticated message with the second user ID “200001” (301) (step 1605), and the authenticated message is rewritten to the network 14. To the Web server 11 (step 1606).

  17 and 18 are sequence diagrams illustrating processing for registering the same user information in the same user information database 903 provided in the relay server 12 in the network system 1. In the following description, an ID registration request indicates a request for registering a user ID and a URL to a Web server. First, with reference to FIG. 17, a process of temporarily registering the first user ID and the first URL in the same user information database 903 will be described. The control unit 1033 of the user terminal 13 transmits an authentication request to the Web server 10 via the network 14 (step 1701).

  The control unit 1031 of the Web server 10 performs authentication processing by comparing the authentication information included in the authentication request with the authentication information stored in the user authentication information database 210 (step 1702), and the result is sent via the network 14. To the user terminal 13 (step 1703).

  When the authentication result indicates successful authentication, the control unit 1033 of the user terminal 13 transmits an ID registration request to the Web server 10 via the network 14 (step 1704).

  The control unit 1031 of the Web server 10 transmits an ID registration request including the first user ID and the first URL 170 to the relay server 12 via the network 14 (step 1705).

  When the received first user ID and the first URL are not registered in the same user information database 903, the control unit 1032 of the relay server 12 can create a new linked user that does not collide with the registered linked user ID. An ID is issued, and this is provisionally registered in the same user information database 903 in association with the first URL and the first user ID. When the received first user ID and first URL are already registered in the same user information database 903, the control unit 1032 does not perform temporary registration processing. Next, the control unit 1032 generates information (referred to as a ticket) 171 including the temporarily registered cooperation user ID (referred to as a ticket) 171 (step 1707), and transmits it to the Web server 10 via the network 14 (step 1708). Note that the cooperation user ID may be encrypted when the ticket is generated. However, the encryption method must be a method that can be decrypted by the receiving device.

  The control unit 1031 of the Web server 10 transmits the received ticket 171 to the user terminal 13 via the network 14 (step 1709). The user terminal 13 holds the received ticket 171 in a memory or the like (step 1710).

  Next, a process for registering the second user ID and the second URL in the same user information database 903 will be described with reference to FIG. First, the control unit 1033 of the user terminal 13 transmits an authentication request to the Web server 11 via the network 14 (step 1801).

  The control unit 1031 of the Web server 10 performs authentication processing by comparing the authentication information included in the authentication request with the authentication information stored in the user authentication information database 210 (step 1802), and the result is transmitted via the network 14. To the user terminal 13 (step 1803).

  When the authentication result indicates successful authentication, the control unit 1033 of the user terminal 13 transmits an ID registration request together with the held ticket 171 to the Web server 11 via the network 14 (step 1804).

  The control unit 1031 of the Web server 11 transmits an ID registration request including the second user ID and the second URL 172 together with the ticket 171 to the relay server 12 via the network 14 (step 1805).

  The control unit 1032 of the relay server 12 extracts the cooperative user ID from the received ticket 171 and determines whether or not this cooperative user ID is registered in the same user information database 903 (step 1806). If the cooperative user ID is registered in the same user information database 903 as a result of the determination, the control unit 1032 registers the second URL and the second user ID 172 in the same user information database 903 in association with the cooperative ID. (Step 1807). When the control unit 1032 finishes the ID registration process, the control unit 1032 transmits the registration result to the Web server 11 via the network 14 (step 1808). The registration result is information indicating, for example, the URL of each Web server accessed by the user and the fact that registration of the user ID for identifying the user on each Web server has been completed normally. The control unit 1031 of the Web server 11 transmits this registration result to the user terminal 13 via the network 14 (step 1809).

  When receiving the registration result, the control unit 1033 of the user terminal 13 deletes the ticket 171 held in the memory or the like from the memory or the like (step 1810).

  FIG. 19 is a flowchart showing detailed processing in the Web server 11 for re-authenticating the user authenticated by the Web server 10 and transmitting the result to the user terminal 13 (FIG. 11—Steps 1111 and 1112). First, the control unit 1031 of the Web server 11 receives the authenticated message transmitted from the relay server 12 via the network 14 and the network interface unit 1051 (step 1901). Next, the control unit 1031 determines, from the authenticated message, the second user ID 1302, the url 1306 to the user authentication information operation policy file, the user authentication information operation record 1307, the url 1308 to the user attribute information operation policy file, The user attribute information operation record 1309 is extracted (step 1902). Here, the control unit 1031 downloads the user authentication information operation policy file 211 and the user attribute information operation policy file 214 from the url 1306 and url 1307, and the user authentication information operation policy and the user attribute information operation policy described in these files. To get. Note that since it is rare to change the operation policy information once it is determined, it is not always necessary to download it, and it may be cached in the Web server 11. Next, the control unit 1031 confirms whether or not the second user ID extracted in Step 1902 is registered in the user authentication information database 210 (Step 1903). If the second user ID is not registered in the user authentication information database 210 as a result of the confirmation, the control unit 1031 transmits information indicating authentication failure to the user terminal 13 via the network 14 (step 1905). . On the other hand, if the second user ID is registered in the user authentication information database 210 as a result of the confirmation, the control unit 1031 displays the information extracted in step 1902 (user authentication information operation policy, user authentication information operation record 1307). , User attribute information operation policy, user attribute information operation record 1309) and information stored in the storage unit 1041 of the Web server 11 (user authentication information operation policy, user authentication information operation record, user attribute information operation policy, user attribute The user is re-authenticated based on the information operation record (step 1904), and the re-authentication result is transmitted to the user terminal 13 via the network 14 (step 1905). That is, the control unit 1031 compares the information related to the authentication strength held by the Web server 10 with the information related to the authentication strength held by the Web server 11, determines the success or failure of re-authentication based on the comparison result, The result is transmitted to the user terminal 13 via the network 14. The success / failure of re-authentication includes (1) the comparison result of the user authentication information operation policy, (2) the comparison result of the user authentication information operation record, (3) the comparison result of the user attribute information operation policy, and (4) the user attribute information operation record. Judgment is made by any one of the comparison results or any combination of (1) to (4). For example, the control unit 1031 of the Web server 11 compares the user authentication information operation policy held by the Web server 10 with the user authentication information operation policy held by the Web server 11, and as a result, the user authentication held by the Web server 11. If the information operation policy imposes stricter requirements than the user authentication information operation policy held by the Web server 10, it is determined that re-authentication has failed. Further, for example, the control unit 1031 compares the comparison result of the minimum password length (FIG. 4-403), the comparison result of the number of combination character types (403) of the password, the comparison result of the longest password update period (405), the password Any one of the comparison result of the minimum number of reuse generations (405), the comparison result of the number of items of the user attribute information (FIG. 7-701), the comparison result of the confirmation condition (702) regarding the operation of the user attribute information, or Re-authentication success or failure is determined based on any combination of these. When comparing the confirmation conditions (702) regarding the operation of the user attribute information, codes such as A, B, and C that can be expressed as levels and ranks are used instead of the natural language sentence as shown in FIG. It is necessary to score with numerical values. In this case, the meanings of these codes and scores need to be agreed in advance between the Web server 10 and the Web server 11. Further, for example, the control unit 1031 of the Web server 11 uses the authentication strength 503 stored in the user authentication information operation record database 212 and the authentication strength 805 stored in the user attribute information operation record database 215 to cause the control unit 1031 of the Web server 11 to The minimum authentication strength for accepting the authentication result of 10 may be set. This is a method of performing a re-authentication process in which the authentication strength is not accepted if it is not A or higher, and is not accepted if the authentication strength is not B or higher. Since the message example includes the authentication strength B in the user attribute information operation record (1309), the control unit 1031 of the Web server 11 transmits the result indicating the authentication failure to the user terminal 13 via the network 14. Further, for example, the control unit 1031 of the Web server 11 determines the degree of compliance (or margin rate) of the user authentication information operation record (FIG. 13-1307) from the operation rule 405 (FIG. 4) described in the user authentication information operation policy file 211. ) And if the prescribed degree of compliance is not satisfied, it is determined that the authentication has failed. In this case, the process in which the Web server 10 calculates the authentication strength 503 (FIG. 5) stored in the user authentication information operation record database 212 is equivalent to recalculation on the Web server 11 side.

The embodiments of the present invention have been described above. According to the present embodiment, in a network system composed of a plurality of systems that are not in a trust relationship or cooperative relationship with each other, a plurality of applications that require authentication are used by inputting authentication information (such as ID and password) once. Technology that enables it can be provided. Further, the present invention is not limited to the above-described embodiment, and various modifications can be made within the scope of the spirit thereof. Other embodiments will be described below.
(Other embodiment 1)
FIG. 20 is a sequence diagram showing an outline of processing in the entire network system 1 according to another embodiment. In addition, each process shown in FIG. 20 is performed according to the program memorize | stored in the memory | storage part by the control part which each computer comprises. Here, in order to simplify the description, each process will be described simply with the control unit as the execution subject.

  First, the control unit 1033 of the user terminal 13 acquires authentication information input by the user via the input unit 1023, and transmits an authentication request including the authentication information to the Web server 10 via the network 14 (step 2001). ).

  The control unit 1031 of the Web server 10 performs user authentication by comparing the received authentication information with the authentication information stored in the user authentication information database 210 (step 2002), and sends the authentication result to the user terminal via the network 14. 13 (step 2003). Note that if the authentication fails as a result of the user authentication, the processing after step 2003 is not performed.

  If the authentication result indicates successful authentication in step 2003, the control unit 1033 of the user terminal 13 transmits a service request including the second URL to the Web server 10 via the network 14 (step 2004).

  The control unit 1031 of the Web server 10 indicates that the user authentication has been successful in the Web server 10 and includes an authenticated message including information relating to the first user ID, the first URL, the second URL, and the authentication strength. Is generated (step 2005) and transmitted to the relay server 12 via the network 14 (step 2006).

  The control unit 1032 of the relay server 12 refers to the same user information database 903, acquires the second user ID corresponding to the first user ID included in the authenticated message (step 2007), and sets the authenticated message as the authenticated message. The included first user ID is rewritten to the second user ID, and this authenticated message is transmitted to the Web server 14 via the network 14 (step 2008).

  The control unit 1031 of the Web server 11 identifies the user from the second user included in the authenticated message, and is stored in the storage unit 1041 of the Web server 11 and information related to the authentication strength included in the authenticated message. The user is re-authenticated based on the information related to the authentication strength (step 2009), and the result is transmitted to the web server 10 via the network 14 (step 2010). Note that if the user authentication fails as a result of the re-authentication, the processing after step 2010 is not performed.

  If the re-authentication result indicates successful authentication in step 2010, the control unit 1031 of the web server 10 transmits a service request to the web server 11 via the network 14 (step 2011).

  Upon receiving the service request, the control unit 1031 of the Web server 11 executes the corresponding Web application 209, and transmits a service screen and a content 173 indicating the execution result to the Web server 10 via the network 14 (Step 2012). .

The control unit 1031 of the Web server 10 embeds content in the service screen and transmits it to the user terminal 13 via the network 14 (step 2013). This service screen is output to the output unit 1013 of the user terminal 13.
(Other embodiment 2)
Since each of the Web server 10, the Web server 11, and the relay server 12 provides a server function, an embodiment in which two to three server functions are mounted on the same computer may be used. In particular, a software delivery form called SaaS (Software as a Service) is becoming widespread recently, and in the SaaS form, a plurality of server functions are mounted on the same computer. Similarly, an embodiment in which a plurality of server functions are installed for each OS (Operating System) on the same computer using a server virtualization mechanism is also within the scope of the modification of the present invention.
(Other embodiment 3)
When the user ID and the Web server URL are registered in the same user information database 903 using the ID registration method shown in FIGS. 17 and 18, a plurality of linked user IDs are issued to the same user and registered in the same user information database 903. May be. For example, after registering the first user ID, the first URL, the second user ID, and the second URL in the same user information database 903 according to the processing procedure shown in FIGS. , A user ID valid on a Web server other than the Web servers 10 and 11 and a URL to the other Web server are provisionally registered in the same user information database 903 according to the processing procedure shown in FIG. 17, and then the processing shown in FIG. If the second user ID and second URL that are valid in the Web server 11 are registered in the same user information database 903 according to the procedure, the URL and user ID that are provisionally registered differ at each registration opportunity. An ID is assigned. As a method for preventing this, for example, there is a method of reusing a ticket. Specifically, the ticket 171 (FIG. 17-step 1710) held in the user terminal 13 at the time of the initial user ID temporary registration is not deleted from the memory or the like (FIG. 18-step 1810), and the IDs for the second and subsequent times. At the time of provisional registration, the control unit 1033 of the user terminal 13 transmits an ID registration request together with the ticket 171 to the Web server 10 via the network 14, and the control unit 1031 of the Web server 10 transmits the ID registration request together with the ticket 171 (see FIG. 17-step 1705) is transmitted to the relay server 12 via the network 14. However, in this case, if a reused ticket is stolen by another person, impersonation registration can be easily performed. Therefore, consideration is required such as requiring strict management of the ticket or setting an expiration date on the ticket to reduce the risk of impersonation registration.

  As another ID registration method, when there is a record of the same user registered with a different cooperative user ID, there is a collision in the ID temporary registration process (FIG. 17-step 1706) or the ID registration process (FIG. 18-step 1807). There is a method of rewriting the cooperation user ID of the generated record. This ID registration method will be described with reference to FIGS. FIG. 21 and FIG. 22 are diagrams showing a registration state of the same user information database 903 when ID registration is performed in the following procedure. As shown in FIG. 21, for convenience of explanation, the user ID and the URL to the Web server are simplified and used, such as URL1 and ID1. The network system shown in FIG. 21 is a system in which a relay server 12 and five Web servers (2201, 2202, 2203, 2204, 2205) are connected to the network 14, and ID registration is performed twice. The results are shown. In the first ID registration, the Web server 2201 is registered as the first Web server and the Web server 2202 is registered as the second Web server. In the second ID registration, the Web server 2203 is registered as the first Web server and the Web server 2204 is registered as the first Web server. Registered as a second Web server. In this case, the data content stored in the same user information database 903 is as shown in FIG. Here, consider a case where the Web server 2205 is registered as the first Web server, and any one of the Web servers 2201 to 2204 is registered as the Web server 11. When the Web server 2205 is provisionally registered (FIG. 17—Step 1706), since there is no record in which the URL 1502 is “URL5” and the user ID 301 is “ID5”, a new cooperative user ID 1501 is issued. The newly issued cooperative user ID is assumed to be “IDF5”. Next, for example, when trying to register the Web server 2201 as the second Web server, the URL 1502 is “URL1” and the user ID 301 is “ID1” during ID registration (step 1807 in FIG. 18). Since the record is found on the first line, it can be seen that “IDF1” and “IDF5” are linked user IDs representing the same person. In this case, by rewriting “IDF5” with “IDF1” that has already been registered, there are three records with the linked user ID “IDF1”, and the ID linkage between the Web server 2201, the Web server 2202, and the Web server 2205 is established. it can.

  Also, consider a case where the Web server 2203 is registered as the first Web server and the Web server 2205 is registered as the second Web server. In this case, a record in which the URL 1502 is “URL3” and the user ID 301 is “ID3” is found during temporary ID registration (FIG. 17—step 1706), and the linked user ID is “IDF3”. “IDF3” is written as the cooperation user ID. In this case, at the time of ID registration (step 1807 in FIG. 18), a pair of “IDF3”, “URL5”, and “ID5” is registered, and ID cooperation between the Web server 2203, the Web server 2204, and the Web server 2205 can be performed.

  Further, consider a case where the Web server 2201 is registered as the first Web server and the Web server 2203 is registered as the second Web server. In this case, it is found that the cooperative user ID is “IDF1” during the temporary ID registration (FIG. 17-step 1706), and the cooperative user IDs “IDF3” and “IDF1” are registered during the ID registration (FIG. 18-step 1807). "Is consistent. Therefore, if “IDF3” is rewritten with “IDF1”, the Web server 2201, the Web server 2202, the Web server 2203, and the Web server 2204 can be linked to each other.

By continuing such registration processing, ID linkage among all Web servers is completed.
(Other embodiment 4)
The present invention is also applicable when re-authentication is performed by a web server other than the web servers 10 and 11. After receiving normal authentication processing at the Web server 10 and receiving re-authentication at the Web server 11, authentication is performed from the Web server 10 to another Web server via the relay server 12 in order to receive re-authentication at another Web server. Send a completed message. However, if a re-authentication is attempted in another Web server after a certain amount of time has passed since the last operation on the Web server 10, a timeout may occur in the Web server 10 and the authentication result may be invalid. Therefore, in this case, after being re-authenticated by the web server 10, the web server 10 is re-authenticated by another web server, or the web server 11 is authenticated and the web server is re-authenticated by another web server. Either authentication is required or some processing is required.
(Other embodiment 5)
In the above embodiment, a user ID and a password have been described as examples of user authentication information. However, for secret information, a one-time password, a public key infrastructure (PKI) electronic certificate, or the like can be used in addition to the password. Operation conditions such as what kind of secret information is used and whether the secret information is stored in the IC card are described in the user authentication information operation policy file 211.
(Other embodiment 6)
In the above-described embodiment, the case where the re-authentication result (step 1112) in the Web server 11 is directly set to the user terminal 13 in FIG. 11 has been described, but is transmitted to the user terminal 13 via the relay server 12 or the Web server 10. You may do it.
(Other embodiment 7)
In the above embodiment, in FIG. 19, whether or not the second user ID is registered is confirmed, and the user is re-authenticated when registered. However, when the user is re-authenticated and the re-authentication is successful In addition, it may be confirmed whether the second user ID is registered.
(Other embodiment 8)
In the above embodiment, a case has been described in which either the first user ID or the second user ID is described as the user ID 1302 of the authenticated message (FIG. 13). Both user IDs may be described. However, describing both user IDs will unnecessarily widen the disclosure range of user IDs, and even if the user ID itself is not secret information or privacy information, it may lead to an increase in security risk. Normally, only one of them is described, and the relay server 12 is operated so that ID replacement is correctly performed. Similarly, the URL 1303 of the Web server does not describe both the first URL and the second URL, but only the second URL is sent from the Web server 10 to the relay server 12, and the relay server 12 to the Web server 11. It is also possible to send an authenticated message without describing the URL. When a Web server or a relay server makes an IP (Internet Protocol) connection, the IP address and URL of the connection source host can be automatically acquired and resolved. However, since the correspondence between the IP address and the URL is not necessarily one-to-one, it is preferable to describe the first URL and the second URL.
(Other embodiment 9)
As for the procedure for registering the same user information in the relay server 12, the relay server 12 may be registered as a user. In this case, the user ID on the relay server 12 has the same effect as the cooperative user ID, and the same user information database 903 has a plurality of cooperative user IDs as shown in FIGS. The problem of having Also, there is no need to issue a ticket.

1 is a diagram illustrating an example of the overall configuration of a user network system 1. FIG. 2 is a diagram illustrating a hardware configuration example of Web servers 10 and 11. FIG. It is a figure which shows the structural example of the user authentication information database. It is a figure which shows the structural example of the user authentication information operation policy file 211. FIG. It is a figure which shows the structural example of the user authentication information operation record database 212. FIG. It is a figure which shows the structural example of the user attribute information database 213. It is a figure which shows the structural example of the user attribute information operation policy file 214. FIG. It is a figure which shows the structural example of the user attribute information operation record database 215. 2 is a diagram illustrating an example of a hardware configuration of a relay server 12. FIG. It is a figure which shows the hardware structural example of the user terminal. FIG. 2 is a sequence diagram showing an outline of processing of the entire user network system 1. FIG. 11 is a flowchart showing detailed processing in the Web server 10 for generating an authenticated message and transmitting it to the relay server 12 (FIG. 11—Steps 1107 and 1108). It is a figure which shows the structural example of an authenticated message. It is a figure which shows the example of a user service screen. It is a figure which shows the structural example of the same user information database 903. FIG. The relay server 12 resolves the second user ID corresponding to the first user ID, rewrites the first user ID included in the authenticated message with the second user ID, and converts the authenticated message to the Web server 11. FIG. 11 is a flowchart showing detailed processing (FIG. 11—Steps 1109 and 1110). In the network system 1, it is a sequence diagram which shows the process which registers the same user information in the same user information database 903 which the relay server 12 comprises. Similarly, in the network system 1, it is a sequence diagram showing a process of registering the same user information in the same user information database 903 provided in the relay server 12. FIG. FIG. 11 is a flowchart showing detailed processing in the Web server 11 for re-authenticating the user authenticated by the Web server 10 and transmitting the result to the user terminal 13 (FIG. 11—Steps 1111 and 1112). It is a sequence diagram which shows the process outline in the network system 1 whole by other embodiment. It is a figure for demonstrating other embodiment of the process which registers a user ID and URL to a web server in the same user information database. Similarly, it is a figure for demonstrating other embodiment of the process which registers user ID and URL to a web server in the same user information database 903. FIG.

Explanation of symbols

10 Web server 11 Web server 12 Relay server 13 User terminal 14 Network

Claims (7)

  An information processing method in a relay server connected to a plurality of user terminals and a plurality of Web servers,
  The relay server is
  Information for identifying the same user by user identification information for identifying the user by the web server, link information to the web server, and information issued for the combination of the user identification information and the link information And having the same user information storage unit that stores them in association with each other,
  The first web server indicates that the user authentication is successful, the first user identification information constituting the user authentication information, the link information to the first web server, the link information to the second web server And a message containing authentication strength related information,
  Second user identification information for the second Web server to identify the user by searching the same user information storage unit based on the first user identification information and link information to the first Web server And rewriting the first user identification information included in the received message with the second user identification information, and transmitting the message to the second Web server.
  An information processing method characterized by the above.   The authentication strength related information includes one or both of information related to the operation rule of the user authentication information and information related to the operation rule of the user attribute information,
  The information processing method according to claim 1.   A relay server connected to a plurality of user terminals and a plurality of Web servers,
  Information for identifying the same user by user identification information for identifying the user by the web server, link information to the web server, and information issued for the combination of the user identification information and the link information And the same user information storage means for storing them in association with each other,
  The first web server indicates that the user authentication is successful, the first user identification information constituting the user authentication information, the link information to the first web server, the link information to the second web server And means for receiving a message containing authentication strength related information;
  Second user identification information for searching the same user information storage means based on the first user identification information and link information to the first Web server, and for the second Web server to identify the user. Means for rewriting the first user identification information included in the received message with the second user identification information, and transmitting the message to the second Web server.
  A relay server characterized by that.   The authentication strength related information includes one or both of information related to the operation rule of the user authentication information and information related to the operation rule of the user attribute information,
  The relay server according to claim 3.   A network system including a plurality of user terminals, a plurality of Web servers, and a relay server,
  The first web server
  First user authentication information storage means for storing user authentication information;
  When user authentication information included in the authentication request from the first user terminal is stored in the user authentication information storage means,
  Sending information indicating that user authentication has been successful to the first user terminal, receiving link information from the first user terminal to the second Web server, indicating that user authentication has been successful, Generating a message including first user identification information constituting the user authentication information, link information to the first Web server, link information to the second Web server, and authentication strength related information; Means for transmitting to the relay server,
  The relay server is
  Information for identifying the same user by user identification information for identifying the user by the web server, link information to the web server, and information issued for the combination of the user identification information and the link information And the same user information storage means for storing them in association with each other,
  The second Web server receives the message, searches the same user information storage means based on the first user identification information included in the received message and link information to the first Web server, and the second Web server Second user identification information for identifying a user is acquired, the first user identification information included in the received message is rewritten to the second user identification information, and the message is sent to the second Web server. Means for transmitting,
  The second web server
  Second user authentication information storage means for storing user authentication information;
  Authentication strength related information storage means for storing authentication strength related information;
  Receiving the message from the relay server, extracting the second user identification information and the authentication strength related information from the received message, and storing the second user identification information in the second user authentication information storage means; And when the authentication strength related information is stored in the evidence strength related information storage means, the information indicating that the user authentication is successful is transmitted to the first user terminal.
  A network system characterized by this.   The authentication strength related information includes one or both of information related to the operation rule of the user authentication information and information related to the operation rule of the user attribute information.
  The network system according to claim 5.   The relay server is
  A registration request for the first user identification information and link information to the first Web server is received from the first Web server, and the received first user identification information and the first Web server are received. When the link information is not stored in the same user information storage means, information for identifying the same user is issued, and this is used as the first user identification information and the link information to the first Web server. Means for registering in the same user information storage means in association with
  Means for transmitting information for identifying the issued same user to the first Web server;
  The registration request for the second user identification information and the link information to the second Web server is received from the second Web server together with the information for identifying the issued same user. When information for identifying a user is stored in the same user information storage means, the received second user identification information and the second link information correspond to information for identifying the same user. And register in the same user information storage means
  The network system according to claim 5 or 6, characterized in that

Images