JP2006031064A - Session management system and management method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a session management for safe single sign-on capable of preventing a user from forgetting log-out from a partial system, at the time of continuing log-in over a plurality of systems to perform single sign-on performing, or preventing an unintended log-out by time-out of a system. <P>SOLUTION: Single sign-on session information (SSO session information) such as system information which is logged in at the present, route information of single sign-on, status information, and time of validity of single sign-on session is matched among a plurality of systems a user logged in by single sign-on, and linked with a local session set between each application system and the user, whereby the unintended log-out is prevented. The SSO session information is reported to the user, and a selective log-out function is provided thereto, whereby the forgetting of log-out is prevented. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a session management technique in a case where login is continued and a single sign-on is performed across a plurality of systems.

  With the spread of electronic commerce using the Internet, digital content distribution services, and ubiquitous networks using IT technology, a secure and convenient ID assignment method and authentication method for identifying users is required. It is coming.

  Currently, when a user uses various services, registration and authentication of user information is required for each service, and the convenience is low.

  As a technique for solving this problem, a single sign-on and session management method described in Patent Document 1 is known. When the user is authenticated, the session information is embedded in the cookie of the user browser, and when there is an access from the user, the session management server verifies the validity of the cookie session information, extends the validity period, and sets the cookie again. . This realizes single sign-on and session management among multiple servers.

  In the federated single sign-on method described in Non-Patent Document 1, an authentication server that first authenticates a user holds an authentication state as a result of authentication execution, and creates and issues an authentication token indicating the authentication state. The second authentication server requested and accepted by the user uses the authentication token to take over the user's authentication state, and the user can use a plurality of services with a single login.

  In addition, when logging out from a specific server, logout information is propagated between servers that have single-signed on, and all servers are logged out at once to reduce a decrease in security level due to forgetting to log out.

US Patent Application Publication No. 2003/0158949 Thomas Wason, “Liberty ID-FF Bindings and Profiles”, [online], 2003, Liberty Alliance Project, [searched June 24, 2004], Internet <URL: http://www.projectliberty.org/specs/ liberty-idff-bindings-profiles-v1.2.pdf>

  The single sign-on method described in Patent Document 1 manages a session using Cookie. Since Cookie is data sent only from a Web client such as a Web browser to the Cookie issuer domain, it cannot be used for single sign-on across multiple domains. In addition, if each server is accessed during single sign-on, the session management server extends the session validity period and continues single sign-on, but the session is valid for other servers that have been previously single-signed on. Since it is not notified that the time limit has been extended, other servers often time out without the user's knowledge.

  Similarly, in the inter-system single sign-on method of Non-Patent Document 1, the login is continued by the single sign-on across a plurality of systems, but the login is continued to other servers that have been previously single-signed on. Therefore, other servers often time out without the user's knowledge.

  In the method disclosed in Non-Patent Document 1, single sign-on is performed by taking over authentication information across a plurality of systems without placing a central management server. Propagate the route in reverse and log out from all servers at once. Therefore, when a server on the way has already timed out due to a server failure or timeout, the logout information is not propagated, and there is a possibility that a server that is not logged out may be created, resulting in a decrease in the security level.

  Similarly, even when the user directly logs out from a part of the server that has been single-signed on, there is a possibility that a server in which logout information is not propagated at the time of collective logout may occur, so that the user cannot selectively log out.

  In addition, when the user himself / herself performs single sign-on to many servers, it is not possible to know which server is logged in, and there is a possibility that the security level is lowered due to forgetting to log out or the like.

  Accordingly, there is a need for improved session management technology at the time of single sign-on.

  An outline of the session management method of the present invention will be described below.

  When the user logs in to the first system using the user terminal and then moves to the second system, the user accesses the second system and requests authentication by single sign-on. At that time, the second system receives the authentication information, the validity period of the single sign-on session, the history information of the single sign-on so far from the first system (hereinafter referred to as the validity period of the single sign-on session, The history information of single sign-on up to is collected as SSO session information).

  The second system determines whether or not access is possible based on the received information and sets a local session with the user when access is permitted. Further, the second system updates the single sign-on history information and the validity period of its own server included in the SSO session information, registers it in its own session management table, and single sign-on from the second system. The update information is transmitted to the first system that has performed.

  The first system extends the local session with the user based on the received update information, updates the managed SSO session information, and has already set up a single sign-on session with another system. Then, the update information is transmitted to the other system based on the single sign-on route information.

  Also, when a local session with the user is extended in a specific system, the SSO session information is updated and propagated to all systems that have performed single sign-on.

  Thus, by coordinating a local session of a plurality of systems with a common SSO session between the systems, an unexpected time-out without the user's knowledge is prevented.

  The SSO session information held by each of the first and second systems includes information on the system to which the user is logged in. The system requested in response to the request from the user is the SSO session information. By displaying the session information on the user interface on the user terminal, the user can confirm which server is currently logged in regardless of which system is accessed, such as the first or second system.

  The user can selectively request logout from an arbitrary system based on the SSO session information displayed on the user terminal. The logout request is first received by the system performing the display, and propagated through a plurality of systems based on the single sign-on path information included in the SSO session information, and transmitted to the logout system.

  The selected logout system deletes the user's local session and executes logout, thereby enabling selective logout with the user's intention.

  When the selected logout system performs logout, it sets a new single sign-on path excluding the logout system, updates the SSO session information, and transmits it to the other systems.

  In addition, the system periodically checks the state of the user's local session with respect to a plurality of systems that are adjacent on the single sign-on path, and if the local session is terminated due to a system failure or the like, Similarly, a new single sign-on path excluding the logout system is set, and the SSO session information is updated and transmitted to the other systems.

  That is, even when the user's local session is terminated in some systems due to logout or system failure, another system establishes a new single sign-on path and maintains cooperation between the systems. These solutions solve the conventional problem of being unable to log out from some systems when performing collective logout, and enable robust single sign-on session management.

The session management system of the present invention that realizes the session management method described above,
When the user accesses the system, the user management unit executes single sign-on if single sign-on is possible, and otherwise authenticates the user by another method (for example, password authentication);
The SSO session information is managed using a session management table. When the SSO session information of the user is changed in another system, the SSO session information of the user is received and updated, and the other system is used as necessary. A session management unit that transmits the SSO session information to synchronize SSO session information among a plurality of systems;
A session information display unit that displays the SSO session information of the user on the user terminal for the user and accepts a request for logout or the like for a plurality of systems that are single-signed on from the user.

  As described above, when the user continues to log in across multiple application systems and performs single sign-on as described above, the session between the systems is linked to prevent unexpected logout and single sign-on to the user. Information about the system, and allows selective logout from any system.

  According to the present invention, safe and convenient single sign-on session management can be realized.

(Network configuration)
FIG. 1 illustrates a single sign-on service (hereinafter, referred to as a single sign-on service) in which a plurality of application systems 1-1 to 1-n that provide an application to a user cooperate to provide single sign-on and session management. 2 shows a network configuration in an SSO service).

  The application systems 1-1 to 1-n are operated by one or a plurality of providers (hereinafter referred to as service provider).

  Service providers include companies that provide services on the Web, such as travel agencies, car rental operators, and shopping site operators, and system management departments that operate application systems within companies. is assumed.

  By providing the SSO service, these service providers can improve the convenience of the user and prevent the security level from being lowered due to forgetting to log out. It should be noted that the SSO service may be acted on behalf of another provider contracted with the service provider.

  In FIG. 1, an application system 1-1 to 1-n, user terminals 2-1 to 2-m, and a certificate authority terminal 3 possessed by a certificate authority as a third party are connected via a network 4 such as the Internet. Are connected to each other.

  A user who contracts with at least one service provider accesses the application systems 1-1 to 1-n using the user terminals 2-1 to 2-m, and each service provider provides SSO services can be used in addition to existing application services.

  The certificate authority that uses the certificate authority terminal 3 is a third party that issues electronic certificates to service providers, users, and the like. The certificate authority terminal 3 acquires and / or obtains a public key and a public key certificate for verifying signatures applied to various certificates described later such as a single sign-on certificate and a logout request. Used for verification. It is assumed that the public key certificate is registered in advance with the certificate authority by the service provider. In addition, the steps of obtaining and verifying the public key and public key certificate are performed as necessary in the following embodiments, and are not specified.

(System configuration)
The system configuration and functional module configuration of the application systems 1-1 to 1-n will be specifically described with reference to FIG. The application systems 1-1 to 1-n include an application providing unit 10, a user management unit 11, a session management unit 12, a session information display unit 13, a registered user information DB 14, a cooperative application system information DB 15, and a session information DB 16. ing. Note that each function of the application systems 1-1 to 1-n may be realized by distributing each processing unit to a plurality of devices without constructing them on one server device.

  The application providing unit 10 provides each application service provided by each service provider to the user via the network 4. Access control to the application service is executed based on a user authentication result by the user management unit 11. Further, after user authentication and access authorization, a local session is set up with any of the user terminals 2-1 to 2-m and continues until logout is executed.

  The application providing unit 10 holds a local session table for managing session information in the session information DB 16 when setting the local session. In this local session table, for example, a local session ID for uniquely identifying a session, various data (for example, a user ID) to be stored in association with the session, an expiration date of the local session, and the like are registered.

  The user management unit 11 is connected to the user terminals 2-1 to 2-m and other application systems 1-1 to 1-n via the network 4, and has already received another application when receiving an access from the user. If access has been authenticated by the system 1-1 to 1-n and single sign-on access, authentication by single sign-on is executed. If access is not by single sign-on, authentication is executed by another method (for example, password authentication) To do.

  In addition, the user management unit 11 holds a registered user information management table in which user information is registered in the registered user information DB 14. In this registered user information management table, for example, user attribute information such as user information identification ID, user ID, password, name, age, address, e-mail address, matter of interest is registered, and user authentication and application Used to provide

  Further, when performing single sign-on, the user management unit 11 holds an SSO certificate management table for temporarily managing a certificate related to single sign-on (an SSO certificate 41 described later) in the session information DB 16. In this registered user information management table, for example, a search key ID and an SSO certificate 41, which will be described later, are registered and used for single sign-on.

  The session management unit 12 manages information related to a single sign-on session (SSO session information to be described later), and transmits / receives the SSO session information between systems when the SSO session information is changed in any application system. In addition, when a single sign-on status confirmation message is periodically transmitted to a plurality of adjacent application systems on the single sign-on route and the result of the status confirmation cannot be received due to a failure or the like, the SSO Update session information and send to other application systems.

  Further, the session management unit 12 holds a cooperative application system management table for registering information of other cooperative application systems in the cooperative application system information DB 15. This cooperation application system management table includes an application system information identification ID, application system ID, single sign-on reception URL, logout reception URL, SSO session information update reception URL, public key certificate and the like for cooperation with other application systems. The cooperative application system information is registered and used as necessary when providing the SSO service. These pieces of information are searched using the application system ID that cooperates when the SSO service is implemented as a key, and are used as necessary.

  Further, the session management unit 12 holds an SSO session management table 1000 and an SSO history table 2000 for registering information related to a single sign-on session in the session information DB 16.

  FIG. 2 shows an example of the SSO session management table (1000) held in the session information DB 16. The SSO session management table includes an identification ID (1001), a common user ID (1002) of the accessing user in the application systems 1-1 to 1-n, and the user terminals 2-1 to 2-m. Local session ID (1003) to be set, SSO session ID (1004) for uniquely identifying a single sign-on session among a plurality of application systems 1-1 to 1-n that have performed single sign-on, It consists of the last update time (1005), the last updater (1006), and the SSO session expiration date (1007).

  Note that the user ID may be common between systems, and the registered user ID may differ depending on the system even for the same user. In the latter case, the local user ID mapping table between other systems and the own system is managed for each system, and the local user ID in the own system is determined from the local user ID described in the received SSO session information. A method is proposed in Non-Patent Document 1.

  FIG. 3 shows an example of the SSO history table (2000) held in the session information DB 16. The SSO history table includes an identification ID (2001), an SSO session ID (2002) that is a key associated with data in the SSO session management table 1000, and an identifier of each of a plurality of application systems 1-1 to 1-n that have performed single sign-on. SSO system ID (2003), a source system ID (2004) indicating which application system 1-1 to 1-n has moved by single sign-on, and a user for the application system 1-1 to 1-n And a status (2005) for registering the login state or the like.

  The data in the SSO session management table 1000 and the SSO history table 2000 are associated by SSO session IDs (1004 and 2002). Among these, the last update time (1005), the last updater (1006), the SSO session expiration date (1007), the SSO system ID (2003), the source system ID (2004), and the status (2005) are collectively shown below. Called SSO session information.

  Also, for example, when single sign-on or session information is updated, the SSO session information corresponding to the SSO session ID (1004 and 2002) is searched for and transmitted / received between the application systems 1-1 to 1-n. .

  The information registered in the SSO session management table 1000 and the SSO history table 2000 is stored when the user logs out from the application system 1-1 to 1-n and / or when the SSO session expiration date (1007) has passed. Deleted from the session information DB 16. In the latter case, each system is synchronized, and as a result, it is deleted from all systems.

  The session information display unit 13 searches the SSO session information from the session information DB 16 in response to a request for disclosure of single sign-on session information from the user, and displays it on any of the user terminals 2-1 to 2-m. To do.

(Hardware configuration)
As shown in FIG. 4, the application systems 1-1 to 1-n include a memory 101, a secondary storage device (referred to as a hard disk) 102 such as a hard disk in which various programs (session management program, OS, etc.) and various data are stored, A program (for example, a session management program 100 or the like) is loaded from the hard disk 102 to the memory 101 and executed, and the CPU 103, the input / output interface 104, and a communication line 105 such as a bus connecting them are constructed on a computer. it can.

  The input / output interface 104 includes a display device 106, an input device (such as a keyboard) 107, a drive 108 in which a portable storage medium is mounted, a network control device 109 that controls data transmission with the network 4 as a communication medium, and the like. Is connected.

  In the application systems 1-1 to 1-n, the CPU 103 executes the session management program 100 and the like, thereby realizing the function units 10, 11, 12, and 13 that provide the SSO service on the computer. The hard disk 102 also stores a registered user information DB 14, a cooperative application system information DB 15, and a session information DB 16.

  Other terminals shown in FIG. 1, that is, user terminals 2-1 to 2-m and certificate authority terminal 3 have the same configuration as that of application systems 1-1 to 1-n except that the programs in the hard disk 102 are different. Prepare. The CPU 103 executes the program 100 included in each device, thereby realizing the function provided by each device on the computer.

  A program executed by the CPU 103 of each device may be stored in the memory 101 and / or the hard disk 102 in advance, or a portable storage medium that can be used by each device is attached to the drive 108 as necessary. In other words, the memory 101 and / or the hard disk 102 may be introduced from another device.

  Similarly, the memory 101 and / or from other devices via a carrier wave or a digital signal propagating on a communication line or a communication line connected to the network control device 109, that is, an available communication medium for each device. It may be introduced into the hard disk 102.

(SSO certificate)
FIG. 5 shows a data configuration example of the SSO certificate 41 issued, transmitted, and received by the user management unit 11. The SSO certificate 41 is data for certifying authenticated user authentication information and SSO session information. The SSO certificate 41 includes data describing authenticator identification information (for example, user ID) for identifying the authenticated user, and the SSO certificate. It consists of session information, digital signatures applied to these data by the publisher's application system, and the like. The SSO certificate 41 shown in FIG. 5 includes a certificate ID, authentication information (user ID, authentication domain name, authentication method), SSO session information, certificate validity period, issuer name, issue date and time, and digital signature. It is.

(SSO session update request)
The SSO session update request issued, transmitted, and received by the session management unit 12 is obtained by removing authentication information from the SSO certificate 41. When the SSO session information is changed, a single update request is issued. This is data to be transmitted to each of the application systems 1-1 to 1-n that are logged in by sign-on.

(Logout request)
FIG. 6 shows a data configuration example of the logout request document 42 issued, transmitted, and received by the session management unit 12. The logout request form 42 is data for requesting logout to the application systems 1-1 to 1-n selected by the user, an ID for identifying a logout session (for example, an SSO session ID 1004), and an identification of the system to log out. It is composed of data describing information, a digital signature applied to these data by the application systems 1-1 to 1-n of the issuer, and the like.

  The logout request form 42 shown in FIG. 6 includes a certificate ID, an SSO session ID, a logout system, a requester, a request date / time, an issue date / time, and a digital signature.

  Each certificate listed above (SSO certificate 41, SSO session update request, logout request 42) is a specification such as SAML (Security Association Markup Language) that is a specification for describing an assertion related to security such as authentication and attributes. It can be created using existing standard technology.

(Prerequisites of the embodiment)
Embodiments of a session management method and system when a user of the present invention performs single sign-on between a plurality of application systems will be described below. As a precondition, the application system is assumed to be three Web application systems (hereinafter referred to as Web systems 1-a, 1-b, 1-c) that provide Web content such as a Web shopping site to the user, and the user 2-A It is assumed that the Web system (1-a, 1-b, 1-c) is accessed using a Web client such as a Web browser that operates on the user terminal 2-a. Further, it is assumed that the user 2-A has already been registered in the three Web systems (1-a, 1-b, 1-c) and has the access authority by the conventional method. The three Web systems (1-a, 1-b, 1-c) are assumed to hold information for linking with other Web systems in the linked application system information DB 15, respectively. The user terminal 2-a of the user 2-A and the Web system (1-a, 1-b, 1-c) are connected to each other via the network 4. In the network 4 between the user terminal 2-a and the Web system (1-a, 1-b, 1-c), there is a risk of eavesdropping by a malicious third party. It is desirable to ensure the confidentiality of the communication path using an encrypted communication technique. Further, in the network 4 between the Web systems (1-a, 1-b, 1-c), in order to avoid security risks such as eavesdropping, falsification, and impersonation, encryption of information is performed using an encryption communication technology such as SSL. It is desirable to perform authentication, client authentication, and server authentication. In the following, securing of these security is assumed to be performed as necessary, and is not specified.

(First embodiment)
Hereinafter, the cooperation of session information between systems when a user according to the first embodiment performs single sign-on between a plurality of application systems will be described. The procedure will be described with reference to FIG. 7, taking as an example a case where the user 2-A moves the Web systems (1-a, 1-b, 1-c) in order by single sign-on.

  First, the user 2-A accesses the Web system 1-a from the terminal 2-a and inputs login information (for example, user ID and password) (201). When the user authentication is completed (202), the Web system 1-a sets up a local session with the user terminal 2-a.

  When the local session is realized using, for example, Cookie, a local session ID that can be uniquely identified is registered as Cookie on the Web client of the user terminal 2-a, and the local session in the session information DB 16 of the Web system 1-a is registered. In the table, information (eg, user ID) is stored in association with the local session ID, and when the user 2-A accesses the user terminal 2-a again, the local session ID is acquired from Cookie. Information associated with the local session ID is acquired from the local session table, the user is identified, and access is permitted. This local session is valid until the user logs out of the Web system 1-a, the session expires, or the user exits the Web client. When the setting of the local session is completed, the Web system 1-a displays a screen of the provided service on the display device 106 (203).

  Next, the user 2-A requests the Web system 1-a for single sign-on to another Web system 1-b (204).

  The user management unit 11 of the Web system 1-a that has received the request generates a certificate related to single sign-on (hereinafter, SSO certificate 41) to be transmitted to the Web system 1-b, and further issues a handle ID.

  This handle ID is configured by combining a system ID uniquely associated with the Web system 1-a and a key ID composed of temporary random characters, numbers, and the like according to a predetermined format.

  Next, the SSO certificate 41 is temporarily stored in the SSO certificate management table on the DB 16 in association with the key ID so that the SSO certificate 41 can be uniquely identified from the key ID. The SSO session information included in the SSO certificate is stored in the SSO session management table 1000 and the SSO history table 2000 of the session information DB 16 in association with the local session.

  Next, the issued handle ID is transmitted to the user terminal 2-a (205). In order to reduce the risk of falsification and forgery by a malicious user, the handle ID is preferably transmitted / received after an electronic signature is applied using a digital signature technique.

  The user 2-A accesses the Web system 1-b from the user terminal 2-a, and requests single sign-on and service provision. At this time, the handle ID received from the Web system 1-a is notified (206).

  The user management unit 11 of the Web system 1-b decodes the received handle ID, identifies the Web system 1-a from the system ID, and provides the SSO certificate 41 to the Web system 1-a based on the handle ID. Request.

  The user management unit 11 of the Web system 1-a searches the SSO certificate management table in the memory from the key ID included in the handle ID, specifies the SSO certificate 41, and transmits it to the Web system 1-b.

  When the user management unit 11 of the Web system 1-b receives the SSO certificate 41, it verifies the signature information, searches the registered user information DB 14 for the relevant user information, and if there is valid user information. If access is not permitted, an access denial message is transmitted to the user terminal 2-a (207).

  When access by single sign-on is permitted, the session management unit 12 of the Web system 1-b first reads the SSO session information included in the received SSO certificate 41, updates the information that needs to be updated, and updates the session information DB 16 Are registered in the SSO session management table 1000 and the SSO history table 2000.

  The main information to be updated is the SSO system ID 2003 (ID that identifies the Web system 1-b) and the migration source system ID 2004 (here, the ID that identifies the Web system 1-a that is the migration source system) that are SSO history information. ) And status 2005 (here, “login” since single sign-on was successful), last update time 1005 and last update person 1005. If the SSO session validity period 1007 is not sufficient to provide the service of the Web system 1-b, the SSO session validity period 1007 is extended and registered.

  Next, the Web system 1-b generates the SSO session update request including the updated SSO session information, transmits it to the Web system 1-a that is the migration source system, and makes an SSO session update request (208).

  Upon receiving the SSO session update request, the session management unit 12 of the Web system 1-a searches the SSO session management table 1000 and the SSO history table 2000 based on the SSO session ID 1004 included in the received SSO session update request. The field is updated to the received SSO session information. At this time, if the SSO session expiration date 1007 has been updated, the local session expiration date set with the user 2-A is updated in accordance with the SSO session expiration date 1007 (209).

  Next, the Web system 1-a calculates a single sign-on path (hereinafter referred to as an SSO path) of the user 2-A. This SSO path is calculated by determining from which system the user 2-A has moved to which system by single sign-on based on the SSO system ID 2003 and the migration source system ID 2004 included in the SSO session information. The Web system 1-a identifies an application system that is adjacent to the Web system 1-a on the SSO path from the calculated SSO path information, and the SSO session information has already been updated in the SSO path information. An update request for SSO session information is made to a system other than the Web system 1-b that is the transmission source of the session update request (210). However, in this embodiment, since the Web system 1-a is adjacent to the Web system 1-b only on the SSO path, an update request for SSO session information is not performed.

  After transmitting the SSO session update request, the Web system 1-b sets a local session with the user terminal 2-a. At this time, the expiration date of the local session is set to be the same as the updated SSO session expiration date 1007. Next, the Web system 1-b displays the screen of the provided service on the user terminal (203).

  When the user 2-A performs single sign-on from the web system 1-b to another web system 1-c, the same process as the single sign-on process and the SSO session information update process (204 to 210, 203) is repeated. The web system 1-c executes single sign-on by acquiring the SSO certificate from the web system 1-b.

  However, when the user 2-A further performs single sign-on from the Web system 1-b to the Web system 1-c, the Web system 1-b on the SSO path is adjacent to the Web system 1-a and the Web system 1-c. is there. Accordingly, when the Web system 1-b receives the SSO session update request from the Web system 1-c, it further makes an SSO session update request to the Web system 1-a (211).

  As described above, when a user performs single sign-on between a plurality of application systems, SSO session information is synchronized (matched) in all application systems on the single sign-on path, and each application system By synchronizing (matching) the SSO session information with the local session, SSO session cooperation is realized in the entire system that has performed single sign-on. This prevents unexpected logout due to session timeout or the like.

(Second Embodiment)
Hereinafter, display of single sign-on session information for a user and selective logout from a specific system (hereinafter referred to as selective logout) according to the second embodiment will be described with reference to FIG. As a premise, according to the first embodiment, the user 2-A sets the Web systems 1-a, 1-b, and 1-c in a single sign-on state in order.

  The user 2-A requests information on the current single sign-on session from one of the web systems logged in with single sign-on (here, Web system 1-c) (301).

  The session information display unit 13 of the Web system 1-c that has received the request acquires the local session ID 1003 set by the cookie from the user terminal 2-a, and uses the local session ID 1003 as a key for the SSO session management table 1000 and the SSO history. The SSO session information is retrieved from the table 2000.

  Specifically, the value of the SSO session ID 1004 is retrieved from the SSO session management table using the local session ID 1003 as a key, and each data on the SSO history table 2000 is retrieved from the SSO history table 2000 using the retrieved SSO session ID 1004 as a key. Search for and get.

  A web screen is generated based on the acquired information, transmitted to the user terminal 2-a, and displayed on the web client (302).

  FIG. 9 shows an example of the SSO session information display screen (50) displayed on the display device 106 of the user terminal 2 in step 302 described above. 9, 51 is an example of an application system currently logged in by single sign-on and a single sign-on session map 51 showing the single sign-on route, and the user can confirm the currently logged-in system.

  Further, for example, it is possible to request by selecting a specific system to be logged out, selecting a selective logout request, batch logout from all systems that are single-signed on, and pressing a button.

  Reference numeral 52 denotes an example in which the current SSO session expiration date 1007 included in the SSO session information is displayed, and an expiration date extension request can be made as necessary. Reference numeral 53 denotes an example in which a logged out system is retrieved and displayed from the status 2005 of the SSO session information.

  Next, a method in which the user 2-A performs selective logout of the Web system 1-b from the Web system 1-c will be described below. The user 2-A selects the Web system 1-b to log out from the SSO session information display screen 50, and requests selective logout (303). The session management unit of the Web system 1-c that has received the request generates a logout request form 42 based on the SSO session information of the user 2-A and transmits it to the Web system 1-b.

  The session management unit 12 of the Web system 1-b that has accepted the logout request searches the SSO session information from the SSO session management table 1000 and the SSO history table 2000 using the SSO session ID described in the received logout request document 42 as a key. . Further, the local session information is searched from the local session table using the local session ID 1003 of the SSO session information as a key, and logout is executed by deleting the local session information (305).

  Next, a new single sign-on path (SSO path) excluding the logged out Web system 1-b is calculated, and the SSO session information is updated. In the calculation of the new SSO route, for example, first, the destination application system (in this case, the Web system 1-c) moved from the Web system 1-b by single sign-on and the source application of the Web system 1-b. The system (here, Web system 1-a) is searched. Next, the migration source system of the destination Web system 1-c is changed to 1-a which is the migration source system of the Web system 1-b.

  As a result, a new SSO route is determined between the Web systems 1-a and 1-c that are adjacent to the Web system 1-b, and the migration source system ID 2004 of the SSO session information is updated. Also, the information updated in the SSO session information by logout (here, status 2005, last update time 1005, last updater 1006) is updated, and an SSO session update request is generated. Then, before logging out, an SSO session update request is transmitted to the Web system 1-a and the Web system 1-c that are adjacent to the Web system 1-b (306).

  The session management unit 12 of the Web system 1-a and the Web system 1-c that has received the SSO session update request form performs processing such as updating SSO session information in the same manner as steps 209 and 210 of the first embodiment.

  In the Web system 1-b, after transmitting the SSO session update request, the SSO session information in the SSO session information table 1000 is deleted (307).

  As shown above, by presenting SSO session information to the user based on the SSO session information distributedly managed by each application system, it is always possible to check which system the user himself is currently logged in to. In addition, you can selectively log out from a specific system when you are accessing any system. Note that when logging out from a plurality of systems, the selective logout may be repeated.

(Third embodiment)
Hereinafter, notification of failure information of the application system according to the third embodiment will be described with reference to FIG. As a premise, according to the first embodiment, the user 2-A is in a single sign-on state in the order of the Web systems 1-a, 1-b, 1-c.

  The session management unit 12 of each Web system 1-a, 1-b, 1-c repeatedly transmits a status confirmation request message to the adjacent system on the SSO path (for example, every 5 minutes). The status confirmation request message includes an SSO session ID 1004 for identifying the single sign-on session of the user 2-A.

The session management unit 12 of each Web system 1-a, 1-b, and 1-c that has received the status confirmation request message searches the SSO session management table 1000 and the SSO history table 2000 using the SSO session ID 1004 as a key. If there is session information, a predetermined message indicating normality is transmitted.
When there is no SSO session information, such as when the local session has ended or data has been deleted for some reason, a predetermined error message is transmitted.

  When each Web system 1-a, 1-b, 1-c receives a status confirmation result indicating normality, it periodically performs status confirmation processing without doing anything, receives an error message, or status confirmation result Is not received, the following processing when a failure occurs is executed (401).

  In the third embodiment, a failure (for example, server stop) occurs in the Web system 1-b, and the status check result for the status check request message sent from the Web system 1-a to the Web system 1-b cannot be received. The processing when a failure occurs will be described below by taking the case as an example.

  If the result of the status check cannot be received continuously (for example, three times in succession) once or several times, the Web system 1-a becomes inaccessible (that is, the local session ends) The Web system 1-b is determined to be inaccessible (402), and among the status 2005 of the SSO session information, the status 2005 in which the SSO system ID 2003 is the Web system 1-b is determined to be inaccessible in advance. (403). In the present embodiment, the systems monitor each other so that more reliable state confirmation is performed.

  Further, a new SSO route excluding the Web system 1-b is calculated in the same manner as in the above step 306, the SSO session information is updated, and updated to each application system (here, Web system 1-c) on the SSO route. The SSO session information is transmitted (306).

  Further, information indicating that a failure has occurred is that the application server accesses step 302 and the SSO session information in the second embodiment when the application server (in this case, the Web system 1-c) is logged in. The user is notified using the display screen 50 (404).

  As described above, according to each embodiment, when a user continues to log in across multiple application systems and performs single sign-on, a session between the systems is coordinated to prevent unexpected logout and to the user a single sign. Presents information about on sessions and provides services such as selective logout from some servers. In addition, even when a login session is terminated in some systems for some reason, the user can be notified quickly. As a result, safe and convenient single sign-on session management can be realized.

It is a figure which shows the network structure which provides services, such as single sign-on and session management using this invention, a system structure, and a functional module structure. It is a figure which shows an example of an SSO session management table. It is a figure which shows an example of an SSO history table. It is a figure which shows the hardware constitutions of each apparatus which comprises an application system. It is a data structural example of an SSO certificate. It is an example of a data structure of a logout request. It is a flowchart of the cooperation process of the session information between the systems at the time of the single sign-on concerning Example 1. It is a flowchart of presentation to a user of single sign-on session information and selective logout processing according to the second embodiment. 10 is an explanatory diagram illustrating an example of an SSO session information display screen according to Embodiment 2. FIG. FIG. 10 is a flowchart of failure information detection and notification processing according to a third embodiment.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... Application system, 2 ... User terminal, 3 ... Certificate authority terminal, 4 ... Network, 5 ... Network, 41 ... SSO certificate, 42 ... Logout request, 50 ... SSO session information display screen, 1000 ... SSO session management table 2000 ... SSO history table

Claims (11)

A session management system that manages a session when the user performs single sign-on to a plurality of application systems that provide services to the user,
Each of the application systems includes a user management unit and a session management unit,
When the user who has been authenticated by the first application system accesses the second application system using a user terminal,
The user management unit of the second application system includes:
Receiving a single sign-on certificate for the user from the user management unit of the first application system;
Based on the single sign-on certificate, log in to the second application system,
The session management unit of the second application system includes:
Update and register the session information included in the single sign-on certificate, and send an update request for the session information to the first application system,
The session management unit of the first application system updates the session information of its own application system using the transmitted update request. The session management system according to claim 1,
The user management unit of the first application system includes:
Receiving a single sign-on request to the second application system performed by the user using the user terminal;
Creating the single sign-on certificate using information relating to the user and a handle ID that is associated with the single sign-on certificate and identifies the first application system;
A session management system, wherein the handle ID is transmitted to the user terminal. The session management system according to claim 2,
The user terminal transmits the handle ID at the time of a single sign-on request to the second application system,
The session management system of the second application system requests the first application system for the single sign-on certificate associated with the handle ID. The session management system according to claim 1,
The session management unit of the first application system includes:
Based on the session information, a route for the single sign-on is obtained,
When there is another application system in the single sign-on that is the source and / or destination of the first application system, the session information update request is transmitted to the other application system And
The session management unit of the other application system updates the session information of the own application system using the transmitted update request. The session management system according to claim 1,
The application system includes a session information display unit that performs display on the user terminal based on the session information related to the single sign-on route and the application system that is logged in by the single sign-on of the user. Session management system characterized by The session management system according to claim 1,
The session information managed by the session management unit includes
Local session information of the user to the application system and / or information about the application systems that the user has moved and / or moved by single sign-on and / or a plurality of the moved by single sign-on A session management system including information on a movement route between application systems. The session management system according to claim 1,
The session management unit of the second application system includes:
When the user logs in by single sign-on from the first application system, the session information is generated, and session extension information is transmitted to the first application system that is the movement source,
When session extension information is received from the third application system of the single sign-on destination, the local session information with the user is updated and received by the first application system of the single sign-on source A session management system for transmitting the session extension information. The session management system according to claim 4,
The session management unit
Check whether the local session with the user continues for the application system of the move source and / or the move destination described in the managed session information,
If the local session has already been terminated, a new single sign-on path, excluding the application system, is obtained, the session information is updated, and the session information update request is transmitted.
A session management system that updates the session information managed by the session management unit when a session information update request is received. The session management system according to claim 8, wherein
When the user accesses the application system in which a local session has not ended, the session information display unit notifies the application system in which the local session has ended. The session management system according to claim 1,
In the first application system,
The session information display section
Display on the user terminal based on the session information related to the single sign-on of the user,
Accepting a selective logout request from the user to the other application system;
The session management unit transmits a logout request to the other application system that performs selective logout. The session management system according to claim 10,
The session management unit of the other application system that has received the logout request,
Delete the local session in the application system,
Find a new single sign-on route, excluding the application system, update the session information,
A request for updating the session information is transmitted to the application system that is the source and / or destination of the application system;
A session management system, wherein the session information managed in the application system is deleted.

Images