JP2007257426A - Collaborative authentication method and system corresponding to servers different in authentication intensity - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To realize a collaborative authentication among servers different in authentication intensity. <P>SOLUTION: A portal server (5) for performing associated type authentication about a plurality of servers comprises: an authentication request receiving part (7) for receiving from a user terminal (1) an authentication request being a request for performing authentication with designated authentication intensity among a plurality of authentication intensities and one or more authentication information elements used for authentication with the authentication intensity; an authenticating part (11) for determining whether a user is authorized by using one or more received authentication information elements according to the authentication request, executing authentication processing with the designated authentication intensity and registering authenticated intensity about the user in a prescribed storage area (15); an inquiry receiving part (21) for receiving an inquiry about the authenticated intensity at the corresponding portal site about the user from each of the plurality of servers; and an answering part (23) for specifying the authenticated intensity about the user from the storage area and issuing an answer about the authenticated intensity to an inquiry source in response to an inquiry from each server. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a technique for authentication, and more particularly to a technique for cooperative authentication.

  An authentication method called federated authentication (sometimes called Federated authentication) is known. Federated authentication is an authentication method for realizing single sign-on across different servers. For example, technologies disclosed in Patent Documents 1 and 2 are known as cooperative authentication. Further, as cooperative authentication, for example, technologies disclosed in SAML (Security Assertion Markup Language) (Non-Patent Documents 1 and 2), Liberty (Non-Patent Document 3), WS (Web Service) -Federation (Non-Patent Document 4) It has been known. In addition, as services using cooperative authentication, for example, there are services disclosed in e-CAT (Non-Patent Document 5), VISA Authentication Service (Non-Patent Document 6), and PayPal “Website Payments” (Non-Patent Document 7). Are known.

  On the other hand, the required authentication strength may be different for each server. For example, in an authentication method with a low authentication strength, authentication is performed with one factor (for example, a password manually input by a user), and in an authentication method with a high authentication strength, multi-factor authentication may be performed. Multi-factor authentication is an authentication method using a plurality of authentication devices. As an example of multi-factor authentication, there is an authentication method in which biometric information such as fingerprints and retinas and an IC card are used in combination. As a technique related to multi-factor authentication, for example, there is a technique disclosed in Patent Document 3.

JP 2002-163235 A JP 2004-362189 A JP-T-2006-505021 http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip http://www.xmlconsortium.org/websv/kaisetsu/C10/content.html http://www.projectliberty.org/jp/resources/index.html#Phase2_Spec ftp://www6.software.ibm.com/software/developer/library/ws-fed.pdf http://www.rakuten-kc.co.jp/p/member/all/ecat/index.html http://www.visa.co.jp/verified/index.jsp https://www.paypal.com/en_US/pdf/PP_WebsitePaymentsStandard_IntegrationGuide.pdf

  In the cooperative authentication system, when all servers require the same authentication strength (in other words, a certainty level that the user is valid), so-called single sign-on can be realized. However, as described above, not all servers require the same authentication strength. For this reason, in the conventional cooperative authentication system, cooperative authentication cannot be realized with servers having different authentication strengths required. Specifically, for example, for a service provider that manages a user's account (hereinafter referred to as “IdSP” for abbreviated as “Identity Service Provider”), the user manages an account managed by the IdSP and authentication. After logging in with a low-strength authentication procedure, a service provider (hereinafter referred to as SP) that requires an authentication strength higher than the authentication strength cannot perform so-called single sign-on. In this case, the user is requested by the SP to log in by an authentication procedure according to the authentication strength required by the SP, and is managed by the SP in order to log in to the SP. You need to log in with an account other than your account. That is, after all, the user needs to manage an account for each SP.

  Accordingly, an object of the present invention is to realize cooperative authentication with servers having different authentication strengths.

  Other objects of the present invention will become clear from the following description.

The federated authentication method according to the present invention is:
(A) The portal server, which is a portal for cooperative authentication, is used for an authentication request that is a request for authentication with a specified authentication strength among a plurality of authentication strengths, and for authentication with the authentication strength. Receiving one or more authentication information elements from a user terminal;
(B) performing an authentication process at the specified authentication strength to determine whether the user is valid using the received one or more authentication information elements according to the received authentication request;
(C) When one of a plurality of servers different from the portal server receives a predetermined request from the user terminal, the portal server confirms the authentication that has been completed by the portal server for the user. Steps to inquire about strength,
(D) in response to an inquiry from the server, the portal server issues an answer regarding the strength of authentication completed for the user to the inquiry source server;
(E) If it is specified from the answer from the portal server that the authentication processing with an authentication strength equal to or higher than the authentication strength required by the server has been completed by the portal server, the user terminal On the other hand, a re-authentication request is transmitted to the user terminal, which means that authentication with an authentication strength higher than that required by the server is necessary. Steps. In this cooperative authentication method, when the re-authentication request is transmitted to the user terminal, in the step (A), the portal server sends the re-authentication request from the user terminal that has received the re-authentication request. And an authentication request designating an authentication strength equal to or higher than the authentication strength represented in (1) and one or more authentication information elements used for authentication at the designated authentication strength.

  The above-mentioned “server” may be any computer as long as it provides a certain service when it is confirmed that the user is valid.

  In the step (C), the “inquiry regarding authentication strength” may be, for example, a query of the authentication strength itself, or an authentication strength higher than the authentication strength required by the server that is the query source. It may be an inquiry as to whether or not the authentication process is completed. In other words, an “inquiry about authentication strength” is an inquiry that can be answered in the inquiry source server whether or not authentication processing with an authentication strength higher than the authentication strength required by the server has been completed. Various queries can be employed if any.

  Similarly, in the step (D), the “response regarding the strength of authentication” may be, for example, a response of the authentication strength itself, or an authentication that is higher than the authentication strength required by the inquirer server. It may be an answer as to whether or not the authentication process with strength has been completed. In other words, the “response regarding authentication strength” can be various as long as it is possible to specify whether or not the authentication processing at the authentication strength higher than the authentication strength required by the server has been completed in the response destination server. Can be adopted.

  In the first embodiment, in the step (B), when it is determined that the user is valid in the authentication process, the portal site includes authentication permission information describing the location of the portal site. Send to the terminal. In the step (C), when the server receives the authentication permission information and the predetermined request, the server makes the inquiry to the portal site located at the location recorded in the authentication permission information. It is like that. The portal site does not describe the authentication strength in the authentication process in the authentication permission information.

  In the second embodiment, in the step (A), when the portal site receives an authentication request in which an authentication strength equal to or higher than a predetermined authentication strength is received, the portal site issues a predetermined warning to the user terminal, The authentication process is executed when authentication with the specified authentication strength is requested in spite of issuing the warning.

  In the third embodiment, communication between the user terminal, the portal server, and the server is performed via a first communication network that can be used by an unspecified person, and at least authentication from the portal server to the server is performed. The strength answer is made via a second communication network that cannot be used by unspecified persons.

  The cooperative authentication system according to the present invention includes a portal server that is a portal for cooperative authentication, and a plurality of servers different from the portal server. An authentication request, which is a request for the portal server to authenticate with a specified authentication strength among a plurality of authentication strengths, and one or more authentication information elements used for authentication with the authentication strength, An authentication request accepting unit that accepts from the terminal; and, according to the accepted authentication request, determines whether or not the user is valid using the received one or more authentication information elements; An authentication unit that executes and registers the strength of authentication completed for the user in a predetermined storage area, and accepts an inquiry from each of the plurality of servers for an inquiry regarding the strength of authentication completed for the user at the portal site In response to the inquiry from each server and the server, the authentication strength that has been completed for the user is identified from the storage area, and an answer regarding the authentication strength is obtained from the inquiry source And a reply unit for issuing to the each server. When each of the servers receives a predetermined request from the user terminal, an inquiry unit that inquires the portal server about the strength of authentication that has been completed for the user at the portal server, and a time from the portal server If it is possible to specify that authentication processing with authentication strength equal to or higher than the authentication strength required by the server is completed at the portal server for the user, a predetermined service is provided to the user terminal, If it cannot be specified, an authentication unit is provided that transmits to the user terminal a re-authentication request that means that authentication with an authentication strength higher than that required by the server is required. When the re-authentication request is transmitted to the user terminal, the authentication request reception unit of the portal server receives an authentication strength equal to or higher than the authentication strength represented in the re-authentication request from the user terminal that has received the re-authentication request. , And one or more authentication information elements used for authentication with the specified authentication strength.

  At least the authentication unit and the response unit of the cooperative authentication system described above may be realized by hardware (for example, a circuit), a computer program, or a combination thereof (for example, one or a plurality of CPUs that read and execute a computer program). it can. Each computer program can be read from a storage resource (for example, memory) provided in the computer machine. The storage resource can be installed via a recording medium such as a CD-ROM or DVD (Digital Versatile Disk), or can be downloaded via a communication network such as the Internet or a LAN.

  According to the present invention, it is possible to realize cooperative authentication with servers having different authentication strengths.

  Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

  FIG. 1 shows a configuration example of a cooperative authentication system according to an embodiment of the present invention.

  In the cooperative authentication, an IdSP (Identity Service Provider) 5 serving as a portal for the user terminal 1 and a plurality of SPs (Service Providers) 51 that can be login destinations of the user terminal 1 after authentication by the IdSP 5 are provided. The IdSP 5 and each SP 51 can communicate with each other. Specifically, the communication between the user terminal 1 and the IdSP 5 and SP 51 is performed via a first communication network (for example, the Internet) 3 that can be used by an unspecified person, but the communication between the IdSP 5 and each SP 51 is performed. This is performed via the second communication network 33 that cannot be used by unspecified persons. The user terminal 1 can employ various computers such as a computer including a communication unit, an input unit, and a display unit, such as a personal computer, a cellular phone, and a PDA (Personal Digital Assistants).

  Each SP 51 is, for example, a computer system including a CPU and storage resources (for example, a memory and a hard disk). Each SP 51 includes, for example, an authentication request receiving unit 53 that receives an authentication request from the user terminal 1 via the first communication network 3 as a kind of API (Application Program Interface). Further, each SP 51 is called from the authentication request accepting unit 7 as a computer program (a program that is read from the storage resource and executed by the CPU) and called through the API, and determines whether the user is legitimate. The authentication part 55 which performs the authentication process for performing is provided. In the authentication process, the authentication unit 55 requests authentication strength information (information indicating authentication strength) from the IdSP 5 or requests attribute information described later as necessary. Each SP 51 stores, on the storage resource, for example, a storage area for storing information representing the authentication strength required to provide a predetermined service (for example, login) to the user (hereinafter referred to as an authorized authentication strength storage area). 61 is provided.

  The IdSP 5 is a kind of computer that includes, for example, a CPU and storage resources (for example, a memory and a hard disk). The IdSP 5 receives registration of personal information such as a user's name and address, and issues a dedicated user account to the user terminal 1 in response to the registration. Further, the IdSP 5 can execute an authentication process according to all authentication strengths required by each SP 51 provided in the cooperative authentication system. In the authentication process, for example, a user account from the user terminal 1 and components of authentication information (for example, a user ID different from the user account, a password, a one-time password, information in a matrix card, electronic signature information, bio Metrics information, etc.).

  The storage resource of the IdSP 5 stores, for example, a user management table 15 for managing users who use cooperative authentication according to the present embodiment. A configuration example of the user management table 15 is shown in FIG. The user management table 15 includes, for example, a user account (may be another type of user ID), attribute information for each authentication strength, and a current strength flag for each user. The attribute information is information representing an attribute relating to the user, and is information including, for example, information such as a name, an address, and an e-mail address, and authentication information used for authentication processing with a corresponding authentication strength. The authentication information may be composed of one element (for example, only a manually entered password) or may be composed of multiple elements (for example, a set of biometric information and information in an IC card). . The current strength flag is set for the highest authentication strength among the authentication strengths of the authentication processing completed for the user. In the example of FIG. 2, it can be seen that the highest authentication strength for the user of the user account AAA is 2. In this example, for example, the position of the current strength flag does not change even after the authentication processing of authentication strength 1 is completed, but if the user is determined to be valid in the authentication processing with authentication strength higher than authentication strength 2, A current strength flag is set at a position corresponding to the high authentication strength, and a current strength flag corresponding to the authentication strength 2 is defeated. It should be noted that the maximum authentication strength for each user may be specified by another method.

  For example, the IdSP 5 includes, as a kind of API (Application Program Interface), an authentication request receiving unit 7 that receives an authentication request from the user terminal 1, a strength request receiving unit 21 that receives a request for authentication strength information from each SP 51, and each SP 51 And an attribute request receiving unit 25 that receives a request for attribute information to be described later.

  In addition, the IdSP 5 includes, for example, an authentication unit 11, an authentication strength response unit 23, and an attribute information response unit 27 as computer programs (programs that are read from the storage resource and executed by the CPU) through the API. The authentication unit 11 is called from the authentication request receiving unit 7 and the authentication request receiving unit 7 performs authentication processing according to the specified authentication strength, thereby determining the legitimacy of the user, and sends the result of the determination to the user terminal 1. return. When it is determined that the user is valid, the authentication unit 11 sends authentication result information (for example, an electronic ticket, hereinafter referred to as “authentication ticket” for convenience) used for authentication processing in each SP 51 to the user terminal 1. Send to. The authentication strength answering unit 23 is called from the strength request receiving unit 21 and returns the requested authentication strength information to the request source SP 51 received by the strength request receiving unit 21. The attribute information answering unit 27 is called from the attribute request receiving unit 25 and returns the requested attribute information to the request source SP 51 received by the attribute request receiving unit 25.

  The above is the description of the cooperative authentication system according to the present embodiment. Next, with reference to FIG. 3A and FIG. 3B, the processing flow performed in the cooperative authentication system will be described. In the following description, the first SP 51 is described as “SP1”, and the second SP 51 is described as “SP2”. Further, the authentication strength information indicating the authentication strength 1 is stored in the permitted authentication strength storage area 61 of SP1 (that is, in SP1, the authentication is OK if authentication of authentication strength 1 or higher has been completed. The authentication strength information indicating the authentication strength 3 is stored in the permitted authentication strength storage area 61 of SP2 (that is, the authentication is OK in SP2 if authentication of authentication strength 3 or higher has been completed). ).

  As shown in FIG. 3A, the user terminal 1 requests the IdSP 5 for authentication with a desired authentication strength 1 (step S1). Specifically, for example, by the IdSP 5, a plurality of authentication strengths are displayed in a selectable manner on the user terminal 1, and when the user selects the selection strength 1 as the desired selection strength, the user terminal 1 Request IdSP5 for authentication with authentication strength 1.

  The authentication request reception unit 7 of the IdSP 5 receives the request and calls the authentication unit 11. The authentication unit 11 receives an authentication process with authentication strength 1, for example, input of a user account and a password, and whether or not the password matches the password in the attribute information corresponding to the input user account and authentication strength 1. The process which judges whether is performed. As a result, when it is determined that the user is invalid, the authentication unit 11 returns an authentication NG to the user terminal 1, but when it is determined that the user is valid, an authentication ticket is issued to the user terminal 1. (S2). At that time, the authentication unit 11 sets the current strength flag in the current strength flag column (column on the user management table 15) corresponding to the input user account and the authentication strength 1. Further, the authentication unit 11 can store the issued authentication ticket in association with the authentication strength 1 corresponding to the executed authentication process. Further, the authentication unit 11 records, for example, information such as issuer information (for example, URL (Uniform Resource Locator) of IdSP5) and user account indicating the IdSP5 that is the issuer of the authentication ticket in the authentication ticket (authentication) The ID of the ticket itself may be recorded), and at least authentication strength information indicating the authentication strength corresponding to the executed authentication process is not recorded. The authentication ticket flows to the first communication network 3 that can be used by an unspecified person. However, since the authentication strength information is not recorded in the authentication ticket, even if the authentication ticket is wiretapped, the authentication strength information is not recorded. Leakage can be prevented.

  The user terminal 1 receives the issued authentication ticket. Then, when logging in to each SP, for example, when logging in to SP1, the user terminal 1 transmits the received authentication ticket and authentication request to SP1 (S3). The SP1 authentication request reception unit 7 receives the authentication ticket and the authentication request and calls the authentication unit 55. The authentication unit 55 transmits a request for the authentication ticket and authentication strength information (in other words, an authentication strength inquiry) to the IdSP 5 represented by the issuer information recorded in the authentication ticket (S4).

  The strength request reception unit 21 of the IdSP 5 calls the authentication strength response unit 23 in response to the authentication ticket and the request for authentication strength information. The authentication strength answering unit 23 refers to each current strength flag column (a column on the user management table 15) corresponding to the user account recorded in the authentication ticket, and displays information indicating the authentication strength at which the current strength flag is set. Reply to SP1 which is the request source of authentication strength information (S5).

  If necessary, the authentication unit 55 of SP1 transmits a request for attribute information to IdSP5 (S6). The attribute request receiving unit 25 of the IdSP 5 receives the request and calls the attribute information answering unit 27. The attribute information answering unit 27 acquires attribute information corresponding to the user account from the user management table 15, and transmits the acquired attribute information to SP1 (S7).

  The authentication unit 55 of SP1 determines whether authentication is OK or authentication NG by comparing the authentication strength information answered in S5 with the authentication strength information stored in the permitted authentication strength storage area 61. To do. In the example of FIG. 3A, the authentication strength represented by the authentication strength information in the permitted authentication strength storage area 61 and the authentication strength represented by the returned authentication strength information are 1. Therefore, the authentication unit 55 determines that the authentication is OK. Is transmitted to the user terminal 1 (S8). As a result, the user logs in to SP1.

  Even when the user terminal 1 makes an authentication request to SP2, the same processing as S3 to S5 described above is performed (S9 to S11). However, the authentication strength represented by the authentication strength information in the permitted authentication strength storage area 61 of SP2 (that is, the authentication strength required in SP2) is 3, and the authentication strength 1 represented by the returned authentication strength information is based on the authentication strength. Therefore, the authentication unit 55 of SP2 assumes authentication NG. In this case, the authentication unit 55 transmits a re-authentication request for requesting the IdSP to authenticate with the authentication strength 3 to the user terminal 1 (S12).

  As shown in FIG. 3B, the user terminal 1 requests the IdSP 5 for a screen for performing authentication with the authentication strength 3 in accordance with the re-authentication request (S13). In response to the request, the authentication unit 11 of the IdSP 5 displays a screen for performing authentication with the authentication strength 3 on the user terminal 1 (S14). In accordance with the screen displayed on the user terminal 1, the user inputs an authentication information element necessary for authentication with the authentication strength 3. Here, for example, multiple elements are input for multi-factor authentication. The input authentication information element and authentication request are transmitted from the user terminal 1 to the IdSP 5 (S15). The authentication unit 11 of the IdSP 5 uses the input authentication information element and the authentication information element in the attribute information corresponding to the authentication strength 3 (authentication information element recorded in the user management table 15) to authenticate the user. If it is determined that it is valid, an authentication ticket is issued to the user terminal 1 (S16). At that time, the authentication unit 11 changes the position of the current strength flag column for setting the current strength flag from the column corresponding to the authentication strength 1 to the column corresponding to the authentication strength 3.

  Thereafter, the user can log in by issuing an authentication request together with an authentication ticket without inputting a special authentication information element if the SP is requesting an authentication strength of authentication strength 3 or less. That is, for example, if the user terminal 1 transmits an authentication ticket and an authentication request to SP2 (S17), the same processing as S4 and S5 described above is performed. Here, the authentication strength information representing the authentication strength 3 is returned from the IdSP 5 and satisfies the authentication strength required by the SP 2, so the authentication unit 55 of the SP 2 sets authentication OK (S22). Note that, if necessary, attribute information can be requested and received before authentication is OK (S20 and S21).

  As described above, according to the above-described embodiment, cooperative authentication corresponding to servers (SPs in this embodiment) having different authentication strengths required is realized. If an authentication strength higher than the authentication strength recently performed in IdSP5 is required in the desired SP, authentication with the higher authentication strength is performed in IdSP5 and an authentication request is issued to the desired SP. However, the user only needs to perform the authentication procedure using the user account issued from the IdSP 5, and there is no need to manage the user account for each SP, so the convenience is high.

  Further, according to the above-described embodiment, an authentication procedure according to a low authentication strength is initially performed, and an authentication procedure according to a high authentication strength may be performed as necessary. As a result, it is possible to suppress the flow of authentication information elements to be input in an authentication procedure according to high authentication strength, in other words, highly confidential information, to the first communication network 3 that can be used by an unspecified person. it can.

  In addition, according to the above-described embodiment, when a change occurs in the required authentication strength at each SP, it is sufficient to deal with the SP (for example, an authentication strength division method stored in the permitted authentication strength storage area 61 is used). There is also a convenience that the user terminal 1 and the IdSP 5 do not have to deal with it.

  The embodiment of the present invention has been described above, but this is an example for explaining the present invention, and the scope of the present invention is not limited to this embodiment. The present invention can be implemented in various other forms.

  For example, the authentication unit 11 of the IdSP 5 authenticates the user terminal 1 that has requested authentication with a predetermined authentication strength (for example, the highest authentication strength) from the beginning with a specific warning (for example, authentication with an unnecessarily high authentication strength). A warning that it is not desirable to perform the procedure), and even if the warning is received, the user is permitted to perform the authentication procedure at that authentication strength even if the request is made at that authentication strength. May be. As a result, it is possible to suppress the risk of leaking highly confidential information due to performing an authentication procedure with an unnecessarily high authentication strength.

  Further, for example, instead of inquiring about the authentication strength itself, the SP 51 notifies the IdSP 5 of the authentication strength required by the SP 51, and inquires whether or not the authentication strength or higher has been completed. Also good. In this case, if the notified authentication strength exceeds the authentication strength corresponding to the current strength flag, the IdSP 5 returns an authentication NG, and if the notified authentication strength is equal to or lower than the authentication strength corresponding to the current strength flag. Authentication OK may be answered. When receiving the authentication NG, the SP 51 can also authenticate the user to the user, and can also authenticate the user to the user when receiving the authentication OK.

  For example, the configuration example of FIG. 4 may be adopted as another configuration example of the user management table 15. According to this configuration example, the authentication ticket issued when the authentication is completed is associated with the strength of the authentication completed for the user (for example, in the example of FIG. 3A, the authentication issued in S2 Ticket A is associated with authentication strength 1). If an authentication ticket is issued after authentication with an authentication strength higher than the authentication strength associated with the authentication ticket, the issued authentication ticket is associated with the higher authentication strength. The authentication ticket linked to the lower authentication strength is discarded (for example, in the example of FIG. 3B, the authentication ticket B issued in S16 is linked to the authentication strength 3 and lower authentication strength). The authentication ticket A linked to 1 is discarded). In this way, it is possible to manage the highest authentication strength among the authentication strengths for the user.

The structural example of the cooperation type | mold authentication system which concerns on one Embodiment of this invention is shown. The structural example of the user management table 15 is shown. FIG. 3A shows a part of an example of the flow of processing performed in the cooperative authentication system of FIG. FIG. 3B shows a continuation of FIG. 3A. 4 shows another configuration example of the user management table 15.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... User terminal 3 ... 1st communication network 5 ... IdSP (Identity Service Provider) 7 ... Authentication request reception part 11 ... Authentication part 15 ... User management table 21 ... Strength request reception part 23 ... Authentication strength reply part 33 ... Second Communication network 51... SP (Service Provider) 53. Authentication request receiving unit 55. Authentication unit 61.

Claims (7)

(A) The portal server, which is a portal for cooperative authentication, is used for an authentication request that is a request for authentication with a specified authentication strength among a plurality of authentication strengths, and for authentication with the authentication strength. Receiving one or more authentication information elements from a user terminal;
(B) performing an authentication process at the specified authentication strength to determine whether the user is valid using the received one or more authentication information elements according to the received authentication request;
(C) When one of a plurality of servers different from the portal server receives a predetermined request from the user terminal, the portal server confirms the authentication that has been completed by the portal server for the user. Steps to inquire about strength,
(D) in response to an inquiry from the server, the portal server issues an answer regarding the strength of authentication completed for the user to the inquiry source server;
(E) If it is specified from the answer from the portal server that the authentication processing with an authentication strength equal to or higher than the authentication strength required by the server has been completed by the portal server, the user terminal On the other hand, a re-authentication request is transmitted to the user terminal, which means that authentication with an authentication strength higher than that required by the server is necessary. And when the re-authentication request is transmitted to the user terminal, in the step (A), the portal server changes the re-authentication request from the user terminal that has received the re-authentication request. Receiving an authentication request specifying an authentication strength greater than or equal to the indicated authentication strength and one or more authentication information elements used for authentication at the specified authentication strength;
Federated authentication method. In the step (B), when it is determined that the user is valid in the authentication process, the portal site transmits authentication permission information describing a location of the portal site to the user terminal,
In the step (C), when the server receives the authentication permission information and the predetermined request, the server makes the inquiry to the portal site located at the location recorded in the authentication permission information. And
The portal site does not describe the authentication strength in the authentication process in the authentication permission information.
The cooperative authentication method according to claim 1. In the step (A), when the portal site receives an authentication request in which an authentication strength equal to or higher than a predetermined authentication strength is received, the portal site issues a predetermined warning to the user terminal. Regardless, when authentication with the specified authentication strength is requested, the authentication process is executed.
The cooperative authentication method according to claim 1. Communication between the user terminal and the portal server and the server is performed via a first communication network that can be used by an unspecified person, and at least an authentication strength response from the portal server to the server is not specified. Over a second communications network that is unusable to humans,
The cooperative authentication method according to claim 1. A portal server that is a portal for federated authentication;
A plurality of servers different from the portal server,
The portal server is
An authentication request for accepting an authentication request, which is a request for authentication at a specified authentication strength among a plurality of authentication strengths, and one or more authentication information elements used for authentication at the authentication strength from a user terminal A reception department;
In accordance with the received authentication request, an authentication process with the designated authentication strength is performed to determine whether or not the user is valid using the received one or more authentication information elements, and the user has been completed. An authentication unit for managing the strength of authentication in a predetermined storage area;
An inquiry reception unit that receives an inquiry about the strength of authentication that has been completed at the portal site for the user from each of the plurality of servers;
In response to an inquiry from each of the servers, an answering unit that specifies the strength of authentication that has been completed for the user from the storage area and issues an answer relating to the authentication strength to each server of the inquiry source, and
Each of the servers is
When a predetermined request is received from the user terminal, an inquiry unit that issues an inquiry to the portal server regarding the strength of authentication that has been completed at the portal server for the user;
If it is determined from the response from the portal server that authentication processing at an authentication strength higher than the authentication strength required by the server is completed at the portal server, a predetermined service is provided to the user terminal. An authentication unit that transmits to the user terminal a re-authentication request that means that authentication with authentication strength equal to or higher than that required by the server is required.
When the re-authentication request is transmitted to the user terminal, the authentication request reception unit of the portal server receives an authentication strength equal to or higher than the authentication strength represented in the re-authentication request from the user terminal that has received the re-authentication request. And an authentication request specifying one and one or more authentication information elements used for authentication with the specified authentication strength.
Federated authentication system. A server that is a portal for cooperative authentication of multiple servers,
An authentication request for accepting an authentication request, which is a request for authentication at a specified authentication strength among a plurality of authentication strengths, and one or more authentication information elements used for authentication at the authentication strength from a user terminal A reception department;
In accordance with the received authentication request, an authentication process with the designated authentication strength is performed to determine whether or not the user is valid using the received one or more authentication information elements, and the user has been completed. An authentication unit for registering the strength of authentication in a predetermined storage area;
An inquiry reception unit that receives an inquiry about the strength of authentication that has been completed at the portal site for the user from each of the plurality of servers;
A server comprising: an answering unit that identifies the strength of authentication that has been completed for the user from the storage area and issues an answer relating to the authentication strength to each server of the inquiry source in response to an inquiry from each server; A computer program for providing a server as a portal for cooperative authentication for a plurality of servers,
When an authentication request, which is a request for authentication with a specified authentication strength among a plurality of authentication strengths, and one or more authentication information elements used for authentication with the authentication strength are received from a user terminal In accordance with the received authentication request, the authentication process is performed with the specified authentication strength to determine whether or not the user is valid using the received one or more authentication information elements, and the user has been completed. Registering the strength of authentication in a predetermined storage area;
When an inquiry about the strength of authentication that has been completed at the portal site for the user is received from a certain server among the plurality of servers, the user has been completed in response to the inquiry from the certain server. A computer program for causing a computer to execute the step of specifying the strength of authentication from the storage area and issuing an answer regarding the specified authentication strength to the certain server that is the inquiry source.

Images