JP2006031064A - セッション管理システム及び管理方法 - Google Patents

Abstract

【課題】
複数のシステムに跨ってログインを継続しシングルサインオンを行う場合において、ユーザが一部のシステムからログアウトを忘れることを防ぐこと、または、システムのタイムアウトによる意図しないログアウトを防ぐ、安全なシングルサインオンのセッション管理を提供する。
【解決手段】
ユーザがシングルサインオンによりログインした複数のシステム間で、現在ログイン中のシステム情報、シングルサインオンの経路情報、ステータス情報、シングルサインオンセッションの有効期限などのシングルサインオンセッション情報（以下ＳＳＯセッション情報）を一致させ、各アプリケーションシステムとユーザの間で設定されているローカルセッションと連携させることにより、不意のログアウトを防ぐ共に、ＳＳＯセッション情報をユーザに通知し、選択ログアウト機能を提供することによりログアウトし忘れを防ぐ。
【選択図】 図９

Description

本発明は複数のシステムに跨ってログインを継続しシングルサインオンを行う場合セッション管理技術に関する。

インターネットを利用した電子商取引やデジタルコンテンツの配信サービス、ＩＴ技術を利用したユビキタスネットワークが普及するに伴って、ユーザを識別するためのＩＤの安全で利便性の高い付与方法や認証方法が必要になってきている。

現在、ユーザは様々なサービスを利用する場合、個々のサービス毎にユーザ情報の登録や認証を求められ、利便性の低いものとなっている。

この問題を解決するための技術として、特許文献１に記載のシングルサインオンおよびセッション管理方法が知られている。ユーザを認証した際に、ユーザブラウザのＣｏｏｋｉｅにセッション情報を埋め込み、ユーザからのアクセスがあるとセッション管理サーバがＣｏｏｋｉｅのセッション情報の有効性を検証し、有効期間を延長して再度Ｃｏｏｋｉｅに設定する。これにより複数サーバ間でのシングルサインオンおよびセッション管理を実現する。

また、非特許文献１に記載の連盟型シングルサインオン方法では、最初にユーザを認証した認証サーバが、認証実行の結果である認証状態を保持し、当該認証状態を示す認証トークンを作成発行し、当該ユーザからコンテンツ要求され、受け付けた第２の認証サーバが当該認証トークンを利用して、当該ユーザの認証状態を引き継ぎ、ユーザが１回のログインで、複数のサービスを利用可能としている。

また、特定のサーバからログアウトした際に、ログアウト情報をシングルサインオンしたサーバ間で伝播させ、全てのサーバから一括してログアウトし、ログアウト忘れによるセキュリティレベルの低下を低減することを特徴としている。

米国特許出願公開第２００３／０１５８９４９号明細書 Thomas Wason、「Liberty ID-FF Bindings and Profiles」、[online]、2003年、Liberty Alliance Project、[2004年6月24日検索]、インターネット<URL:http://www.projectliberty.org/specs/liberty-idff-bindings-profiles-v1.2.pdf>

特許文献１に記載のシングルサインオン方法は、Ｃｏｏｋｉｅを用いてセッションを管理している。ＣｏｏｋｉｅはＷｅｂブラウザなどのＷｅｂクライアントからＣｏｏｋｉｅの発行元ドメインに対してだけだけ送られるデータであるため、複数ドメインに跨るシングルサインオンには利用できない。また、シングルサインオン時に各サーバに対してアクセスがあるとセッション管理サーバではセッションの有効期限を延長しシングルサインオンを継続しているが、以前にシングルサインオンした他のサーバにはセッションの有効期限を延長したことが通知されないため、ユーザの知らない間に他のサーバがタイムアウトしてしまうことが多くなってしまう。

同様に、非特許文献１のシステム間シングルサインオン方法でも、複数のシステムに跨ってシングルサインオンによりログインを継続しているが、以前にシングルサインオンした他のサーバにはログインが継続されていることが通知されないため、ユーザの知らない間に他のサーバがタイムアウトしてしまうことが多くなってしまう。

また非特許文献１の方法では、中央管理サーバを置かず、複数のシステムにわたって認証情報を引き継ぐことによりシングルサインオンを行い、特定のサーバからログアウトした際に、ログアウト情報をシングルサインオンしたサーバの経路を逆に伝播させ、全てのサーバから一括してログアウトする。したがって、サーバの障害やタイムアウトなどにより途中のサーバが既にタイムアウトしてしまっている場合にログアウト情報が伝播されず、ログアウトされないサーバが出来てしまう恐れがあり、セキュリティレベルの低下を招いてしまう。

同様にシングルサインオンしたサーバの一部からユーザが直接ログアウトした場合も、一括ログアウト時にログアウト情報が伝播されないサーバができる恐れがあるため、ユーザの意思で選択的にログアウトすることができない。

また、ユーザ自身も多くのサーバにシングルサインオンした場合、どのサーバにログイン中であるのか分らなくなり、ログアウト忘れ等によるセキュリティレベルの低下を招く恐れがある。

したがって、シングルサインオン時の、より改善されたセッション管理技術が求められている。

本発明のセッション管理方法の概略を以下に説明する。

ユーザは、ユーザ端末を用いて第１のシステムにログインした後、第２のシステムに移動するとき、第２のシステムにアクセスしシングルサインオンによる認証を要求する。その際、上記第２のシステムは上記第１のシステムより認証情報、シングルサインオンセッションの有効期間、それまでのシングルサインオンの履歴情報などを受信する（以下シングルサインオンセッションの有効期間、それまでのシングルサインオンの履歴情報をまとめてＳＳＯセッション情報とする）。

上記第２のシステムは、受信した上記の情報によりアクセス可否を決定し、アクセス許可した場合はユーザとの間にローカルセッションを設定する。さらに上記第２のシステムは上記ＳＳＯセッション情報に含まれている自サーバのシングルサインオン履歴情報ならびに有効期間を更新し、自システムのセッション管理テーブルに登録すると共に、第２のシステムからシングルサインオンを行った上記第１のシステムに対して更新情報を送信する。

第１のシステムでは受信した更新情報を基に上記ユーザとのローカルセッションを延長し、管理している上記ＳＳＯセッション情報を更新し、さらに、既に他のシステムとシングルサインオンのセッションが設定されていれば、シングルサインオン経路情報を基に更新情報を当該他のシステムに送信する。

また、特定のシステムにおいて上記ユーザとのローカルセッションを延長した際にも、上記ＳＳＯセッション情報を更新してシングルサインオンを行ったシステム全てに伝播させる。

これらにより、複数システムのローカルセッションをシステム間で共通のＳＳＯセッションと連携させることにより、ユーザの知らない間の不意のタイムアウトを防ぐことを特徴とする。

上記第１，第２の各システムが保持しているＳＳＯセッション情報には上記ユーザがログインしているシステムの情報が含まれており、上記ユーザからの要求に応じて要求されたシステムが上記ＳＳＯセッション情報を上記ユーザ端末上のユーザインタフェースに表示することにより、上記ユーザは第１，第２等、どのシステムにアクセスしていても現在どのサーバにログイン中であるのか確認することができる。

上記ユーザは、上記ユーザ端末に表示されるＳＳＯセッション情報により任意のシステムに対して選択的にログアウトを要求することができる。当該ログアウト要求は上記表示を行っているシステムがまず受信し、上記ＳＳＯセッション情報に含まれるシングルサインオン経路情報に基づいて複数システムを伝播して当該ログアウトシステムに送信される。

選択された当該ログアウトシステムが当該ユーザのローカルセッションを削除し、ログアウトを実行することにより、ユーザの意思で選択ログアウトが可能となる。

上記選択ログアウトした上記ログアウトシステムは、ログアウトを実行すると、当該ログアウトシステムを除いた新たなシングルサインオン経路を設定し、上記ＳＳＯセッション情報を更新し他の上記システムに送信する。

また、上記システムは定期的にシングルサインオン経路上隣接関係にある複数のシステムに対して上記ユーザのローカルセッションの状態を確認し、システムの障害等により当該ローカルセッションが終了している場合は、同様に当該ログアウトシステムを除いた新たなシングルサインオン経路を設定し、上記ＳＳＯセッション情報を更新し他の上記システムに送信する。

つまり、ログアウトやシステム障害により一部のシステムで上記ユーザのローカルセッションが終了した場合にも、他のシステムが新たなシングルサインオン経路を構築し、システム間の連携を維持する。これらにより一括ログアウトを行う際に一部のシステムからログアウトできないという従来の問題を解決し、ロバストなシングルサインオンセッションの管理を実現可能とする。

上記セッション管理方法を実現する本発明のセッション管理システムは、
上記ユーザがシステムにアクセスした際に、シングルサインオン可能であればシングルサインオンを実行し、シングルサインオンできなければユーザを別の方法（例えばパスワード認証）で認証するユーザ管理部と、
上記ＳＳＯセッション情報をセッション管理テーブルを用いて管理し、上記ユーザのＳＳＯセッション情報が他のシステムにおいて変更された場合に、当該ユーザのＳＳＯセッション情報を受信および更新し、必要に応じて他のシステムに当該ＳＳＯセッション情報を送信して複数システム間のＳＳＯセッション情報を同期させるセッション管理部と、
上記ユーザに対して当該ユーザのＳＳＯセッション情報をユーザ端末に表示し、当該ユーザよりシングルサインオンしている複数のシステムに対するログアウトなどの要求を受け付けるセッション情報表示部とを備えることを特徴とする。

以上述べたとおり、上記態様は、ユーザが複数のアプリケーションシステムに跨ってログインを継続しシングルサインオンを行う場合において、システム間でのセッションを連携させ不意のログアウトを防ぐとともに、ユーザにシングルサインオンに関する情報を提示し、任意のシステムからの選択的なログアウトを可能とする。

本発明により、安全で利便性の高いシングルサインオンのセッション管理が実現できる。

（ネットワーク構成）
図１は、本発明の実施形態として、アプリケーションをユーザに提供する複数のアプリケーションシステム１−１ないし１−ｎが連携して、シングルサインオンおよびセッションの管理を提供するシングルサインオンサービス（以下、ＳＳＯサービスと呼ぶ）におけるネットワーク構成を示す。

アプリケーションシステム１−１ないし１−ｎは一つのまたは複数の事業者（以下、サービス提供事業者と呼ぶ）が運営する。

サービス提供事業者としては、旅行代理店やレンタカー事業者やショッピングサイト運営事業者などのＷｅｂ上でサービスを提供している事業者や、企業内のアプリケーションシステムを運営しているシステム管理部署などが想定される。

これらのサービス提供事業者はＳＳＯサービスを提供することにより、ユーザの利便性を向上させ、またログアウトのし忘れに伴うセキュリティレベルの低下を防ぐことができる。なお、ＳＳＯサービスは、サービス提供事業者と契約した、他の事業者が代行してもよい。

図１において、アプリケーションシステム１−１ないし１−ｎ、ユーザ端末２−１ないし２−ｍ、および第三者機関としての認証局が有する認証局端末３は、例えばインターネットなどのネットワーク４を介して相互に接続されている。

少なくとも一つの上記サービス提供事業者と契約しているユーザは、ユーザ端末２−１ないし２−ｍを用いてアプリケーションシステム１−１ないし１−ｎにアクセスし、各サービス提供事業者がそれぞれ提供しているアプリケーションサービスに加えてＳＳＯサービスを利用できる。

認証局端末３を利用する認証局は、サービス提供事業者、ユーザなどに対し電子証明書を発行する第三者機関である。認証局端末３は、シングルサインオン証明書、ログアウト要求書など後述する各種証明書に施された署名を検証するための、公開鍵および公開鍵証明書を、サービス提供事業者が取得および／または検証するために利用する。また、公開鍵証明書は事前にサービス提供事業者により認証局に登録されているとする。また、公開鍵や公開鍵証明書の取得、検証のステップは、以下の実施例中、必要に応じて行われるものであり、特記していない。

（システム構成）
アプリケーションシステム１−１ないし１−ｎのシステム構成および機能モジュール構成を図１を用いて具体的に説明する。当該アプリケーションシステム１−１ないし１−ｎは、アプリケーション提供部１０、ユーザ管理部１１、セッション管理部１２、セッション情報表示部１３、登録ユーザ情報ＤＢ１４、連携アプリケーションシステム情報ＤＢ１５、セッション情報ＤＢ１６より構成されている。なお、アプリケーションシステム１−１ないし１−ｎの機能各々は１つのサーバ装置上に構築せずに、複数の装置に各処理部を分散させて実現してもよい。

アプリケーション提供部１０は、各サービス提供事業者によるそれぞれのアプリケーションサービスを、ネットワーク４を介して、ユーザに提供する。アプリケーションサービスへのアクセス制御はユーザ管理部１１によるユーザの認証結果を基に実行される。また、ユーザ認証およびアクセス認可後はユーザ端末２−１ないし２−ｍのいずれかとの間でローカルセッションを設定し、ログアウトが実行されるまで継続する。

また、アプリケーション提供部１０は上記ローカルセッションを設定する際にセッション情報を管理するローカルセッションテーブルをセッション情報ＤＢ１６に保持している。このローカルセッションテーブルには例えばセッションを一意に識別するローカルセッションＩＤ、セッションに関連付けて保存したい各種データ（例えばユーザＩＤなど）、ローカルセッションの有効期限などが登録される。

ユーザ管理部１１はネットワーク４を介して、ユーザ端末２−１ないし２−ｍおよび他のアプリケーションシステム１−１ないし１−ｎと接続され、ユーザからのアクセスを受け付けた際に、既に他のアプリケーションシステム１−１ないし１−ｎで認証済みおよびシングルサインオンによるアクセスであれば、シングルサインオンによる認証を実行し、シングルサインオンによるアクセスでなければ別の方法（例えばパスワード認証）により認証を実行する。

また、ユーザ管理部１１はユーザ情報が登録される登録ユーザ情報管理テーブルを登録ユーザ情報ＤＢ１４に保持している。この登録ユーザ情報管理テーブルには例えばユーザ情報識別ＩＤ、ユーザＩＤ、パスワード、氏名、年齢、住所、メールアドレス、興味を持っている事柄などの、ユーザの属性情報が登録され、ユーザの認証やアプリケーションの提供に使用される。

また、ユーザ管理部１１はシングルサインオンを行う際に、シングルサインオンに関する証明書（後述するＳＳＯ証明書４１）を一時的に管理するＳＳＯ証明書管理テーブルをセッション情報ＤＢ１６に保持している。この登録ユーザ情報管理テーブルには例えば検索用キーＩＤ、後述するＳＳＯ証明書４１が登録され、シングルサインオンの際に使用される。

セッション管理部１２はシングルサインオンセッションに関する情報（後述するＳＳＯセッション情報）を管理し、いずれかのアプリケーションシステムで当該ＳＳＯセッション情報が変更された場合にシステム間で当該ＳＳＯセッション情報を送受信する。また、シングルサインオンの経路上、隣接関係にある複数アプリケーションシステムに対して定期的にシングルサインオンの状態確認メッセージを送信し、障害などにより状態確認の結果を受信できなかった場合には当該ＳＳＯセッション情報を更新して他のアプリケーションシステムに送信する。

また、セッション管理部１２は連携する他のアプリケーションシステムの情報を登録する連携アプリケーションシステム管理テーブルを連携アプリケーションシステム情報ＤＢ１５に保持している。この連携アプリケーションシステム管理テーブルには他のアプリケーションシステムと連携するためのアプリケーションシステム情報識別ＩＤ、アプリケーションシステムＩＤ、シングルサインオン受付ＵＲＬ、ログアウト受付ＵＲＬ、ＳＳＯセッション情報更新受付ＵＲＬ、公開鍵証明書などの連携アプリケーションシステム情報が登録され、ＳＳＯサービスを提供する際に必要に応じて利用される。これらの情報はＳＳＯサービスを実施する際に連携するアプリケーションシステムＩＤをキーに検索され、必要に応じて利用されるものである。

また、セッション管理部１２は、シングルサインオンのセッションに関する情報を登録するＳＳＯセッション管理テーブル１０００およびＳＳＯ履歴テーブル２０００をセッション情報ＤＢ１６に保持している。

図２にセッション情報ＤＢ１６に保持しているＳＳＯセッション管理テーブル（１０００）の一例を示す。ＳＳＯセッション管理テーブルは識別ＩＤ（１００１）、アクセスしてきたユーザの当該アプリケーションシステム１−１ないし１−ｎでの共通のユーザＩＤ（１００２）、当該ユーザ端末２−１ないし２−ｍとの間で設定される上記ローカルセッションＩＤ（１００３）、シングルサインオンを行った複数のアプリケーションシステム１−１ないし１−ｎの間で一意にシングルサインオンのセッションを識別するためのＳＳＯセッションＩＤ（１００４）、最終更新時刻（１００５）および最終更新者（１００６）、ＳＳＯセッション有効期限（１００７）とで構成される。

なお、ユーザIDは、システム間で共通の場合と、同一ユーザであっても、システムによって登録しているユーザIDが異なる場合がある。後者の場合、システム毎に、他のシステムと自システムとのローカルユーザIDのマッピングテーブルを管理して、受信したSSOセッション情報に記載のローカルユーザIDから、自システムでのローカルユーザIDを判定する方法が、非特許文献１において提案されている。

図３にセッション情報ＤＢ１６に保持しているＳＳＯ履歴テーブル（２０００）の一例を示す。ＳＳＯ履歴テーブルは識別ＩＤ（２００１）、上記ＳＳＯセッション管理テーブル１０００のデータと関連付けるキーであるＳＳＯセッションＩＤ（２００２）、シングルサインオンを行った複数のアプリケーションシステム１−１ないし１−ｎ各々の識別子であるＳＳＯシステムＩＤ（２００３）、どのアプリケーションシステム１−１ないし１−ｎからシングルサインオンで移動してきたかを表す移動元システムＩＤ（２００４）、現在当該アプリケーションシステム１−１ないし１−ｎに対するユーザのログイン状態などを登録するステータス（２００５）とで構成される。

ＳＳＯセッション管理テーブル１０００とＳＳＯ履歴テーブル２０００のデータはＳＳＯセッションＩＤ（１００４および２００２）により関連付けられている。これらの内、最終更新時刻（１００５）、最終更新者（１００６）、ＳＳＯセッション有効期限（１００７）、ＳＳＯシステムＩＤ（２００３）、移動元システムＩＤ（２００４）、ステータス（２００５）をまとめて、以下、ＳＳＯセッション情報と呼ぶ。

また、例えば、シングルサインオンやセッション情報の更新の際に当該ＳＳＯセッションＩＤ（１００４および２００２）をキーに該当するＳＳＯセッション情報が検索され、アプリケーションシステム１−１ないし１−ｎ間で送受信される。

また、上記ＳＳＯセッション管理テーブル１０００およびＳＳＯ履歴テーブル２０００に登録された情報は当該ユーザが当該アプリケーションシステム１−１ないし１−ｎからログアウト時および／またはＳＳＯセッション有効期限（１００７）の経過時に、当該セッション情報ＤＢ１６より削除される。後者の場合、各システムが同期するので、結果的に全てのシステムから削除される。

セッション情報表示部１３は、ユーザからのシングルサインオンのセッション情報の開示要求に応じて、上記ＳＳＯセッション情報をセッション情報ＤＢ１６より検索し、当該ユーザ端末２−１ないし２−ｍのいずれかに表示する。

（ハードウェア構成）
アプリケーションシステム１−１ないし１−ｎは図４に示すように、メモリ１０１、各種プログラム（セッション管理プログラム、ＯＳ等）および各種データが格納されたハードディスクなどの二次記憶装置（ハードディスクという）１０２、ハードディスク１０２からメモリ１０１にプログラム（例えば、セッション管理プログラム等１００）をロードしそれを実行するＣＰＵ１０３、入出力インタフェース１０４、これらの間をつなぐバスなどの通信線１０５を有する計算機上に構築することができる。

入出力インタフェース１０４には表示装置１０６、入力装置（キーボード等）１０７、可搬型記憶媒体が装着されるドライブ１０８、通信媒体であるネットワーク４との間のデータ伝送を制御するネットワーク制御装置１０９、等が接続されている。

このアプリケーションシステム１−１ないし１−ｎは、ＣＰＵ１０３が、セッション管理プログラム等１００を実行することによって、ＳＳＯサービスを提供する上記各機能部１０、１１、１２、１３を上記計算機上に実現する。また、ハードディスク１０２は、登録ユーザ情報ＤＢ１４、連携アプリケーションシステム情報ＤＢ１５、セッション情報ＤＢ１６を格納する。

図１に示すその他の端末、すなわち、ユーザ端末２−１ないし２−ｍ、認証局端末３は、ハードディスク１０２内のプログラムが異なる以外は、アプリケーションシステム１−１ないし１−ｎと同様の構成を備える。そして、ＣＰＵ１０３が、各装置が備えるプログラム１００を実行することによって、各装置が提供する機能を上記計算機上に実現する。

各装置のＣＰＵ１０３が実行するプログラムは、あらかじめメモリ１０１および／またはハードディスク１０２に格納されていても良いし、必要に応じて、ドライブ１０８に装着される、各装置が利用可能な可搬型記憶媒体を介して、他の装置からメモリ１０１および／またはハードディスク１０２に導入されても良い。

同様に、各装置が利用可能な通信媒体、すなわち、ネットワーク制御装置１０９に接続される、通信回線または通信回線上を伝搬する、搬送波またはデジタル信号を介して、他の装置からメモリ１０１および／またはハードディスク１０２に導入されても良い。

（ＳＳＯ証明書）
図５は、上記ユーザ管理部１１により発行、送信、受信されるＳＳＯ証明書４１のデータ構成例を表している。ＳＳＯ証明書４１は、認証されたユーザの認証情報、ＳＳＯセッション情報を証明するためのデータであり、認証されたユーザを識別する認証者識別情報（例えばユーザＩＤ）を記述したデータと、上記ＳＳＯセッション情報、発行者のアプリケーションシステムによってこれらのデータに施されたデジタル署名、などから構成される。図５に示すＳＳＯ証明書４１には、証明書ＩＤ、認証情報（ユーザＩＤ、認証ドメイン名、認証方法）、ＳＳＯセッション情報、証明書有効期間、発行者名、発行日時、およびデジタル署名が含まれている。

（ＳＳＯセッション更新要求書）
また、上記セッション管理部１２により発行、送信、受信されるＳＳＯセッション更新要求書は、ＳＳＯ証明書４１から認証情報を除いたものであり、ＳＳＯセッション情報が変更された際に、更新要求をシングルサインオンによりログイン中の各アプリケーションシステム１−１ないし１−ｎに送信されるためのデータである。

（ログアウト要求書）
図６は、上記セッション管理部１２により発行、送信、受信されるログアウト要求書４２のデータ構成例を表している。ログアウト要求書４２は、ユーザにより選択されたアプリケーションシステム１−１ないし１−ｎにログアウトを要求するためのデータであり、ログアウトするセッションを識別するＩＤ（例えばＳＳＯセッションＩＤ１００４）、ログアウトするシステムの識別情報を記述したデータと、発行者のアプリケーションシステム１−１ないし１−ｎによってこれらのデータに施されたデジタル署名、などから構成される。

図６に示すログアウト要求書４２には、証明書ＩＤ、ＳＳＯセッションＩＤ、ログアウトシステム、要求者、要求日時、発行日時、およびデジタル署名が含まれている。

以上に挙げた各証明書（ＳＳＯ証明書４１、ＳＳＯセッション更新要求書、ログアウト要求書４２）は、認証や属性等セキュリティに関する表明を記述するための仕様であるＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などの既存の標準技術を用いて作成可能である。

（実施形態の前提条件）
以下に本発明のユーザが複数のアプリケーションシステム間でシングルサインオンを行う際の、セッション管理方法およびシステムについて実施例を説明する。前提条件として、アプリケーションシステムは例えばＷｅｂショッピングサイトなどのＷｅｂコンテンツをユーザに提供する３つのＷｅｂアプリケーションシステム（以下Ｗｅｂシステム１−ａ、１−ｂ、１−ｃと呼ぶ）とし、ユーザ２−Ａはユーザ端末２−ａ上で動作するＷｅｂブラウザなどのＷｅｂクライアントを用いてＷｅｂシステム（１−ａ、１−ｂ、１−ｃ）にアクセスするものとする。また、既に従来の方法でユーザ２−Ａが３つのＷｅｂシステム（１−ａ、１−ｂ、１−ｃ）に登録済みでアクセス権限を持つものとする。また、上記３つのＷｅｂシステム（１−ａ、１−ｂ、１−ｃ）は、それぞれ連携アプリケーションシステム情報ＤＢ１５に他のＷｅｂシステムと連携するための情報を保持しているもとのする。ユーザ２−Ａのユーザ端末２−ａ、Ｗｅｂシステム（１−ａ、１−ｂ、１−ｃ）はネットワーク４を介して互いに接続する。ユーザ端末２−ａとＷｅｂシステム（１−ａ、１−ｂ、１−ｃ）間のネットワーク４では、悪意のある第３者により盗聴される危険があるため、Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ（ＳＳＬ）等の暗号化通信技術を用いて通信路の機密性を確保することが望ましい。また、Ｗｅｂシステム（１−ａ、１−ｂ、１−ｃ）間ネットワーク４では、盗聴や改ざん、成りすまし等のセキュリティ上の危険を避けるため、ＳＳＬ等の暗号化通信技術を用いて情報の暗号化、クライアント認証、サーバ認証を行うことが望ましい。以下、これらのセキュリティの確保は必要に応じて行われるものとし、特記しない。

（第１の実施形態）
以下、第１の実施形態であるユーザが複数のアプリケーションシステム間でシングルサインオンを行う際の、システム間のセッション情報の連携について説明する。ユーザ２−ＡがＷｅｂシステム（１−ａ、１−ｂ、１−ｃ）を順にシングルサインオンにより移動する場合を例にして、その手順を図７を用いて説明する。

ユーザ２−Ａはまず端末２−ａよりＷｅｂシステム１−ａにアクセスし、ログイン情報（例えばユーザＩＤとパスワード）を入力する（２０１）。Ｗｅｂシステム１−ａはユーザ認証が完了する（２０２）と、ユーザ端末２−ａとの間にローカルセッションを設定する。

ローカルセッションは例えばＣｏｏｋｉｅを用いて実現する場合は、ユーザ端末２−ａのＷｅｂクライアント上に一意に識別可能なローカルセッションＩＤをＣｏｏｋｉｅとして登録し、さらにＷｅｂシステム１−ａのセッション情報ＤＢ１６のローカルセッションテーブルにローカルセッションＩＤと関連付けて情報（例えばユーザＩＤなど）を保存しておき、再度当該ユーザ２−Ａがユーザ端末２−ａによりアクセスしてきた際にはＣｏｏｋｉｅより当該ローカルセッションＩＤを取得し、上記ローカルセッションテーブルより上記ローカルセッションＩＤと関連付けた情報を取得し、ユーザを識別してアクセスを許可する。このローカルセッションはユーザがＷｅｂシステム１−ａからログアウトするか、セッションの有効期限が切れるか、ユーザがＷｅｂクライアントを終了するまで有効であるとする。Ｗｅｂシステム１−ａはローカルセッションの設定が完了すると提供しているサービスの画面を表示装置１０６に表示する（２０３）。

次にユーザ２−ＡはＷｅｂシステム１−ａに対して別のＷｅｂシステム１−ｂへのシングルサインオンを要求する（２０４）。

要求を受信したＷｅｂシステム１−ａのユーザ管理部１１は、Ｗｅｂシステム１−ｂへ送信するシングルサインオンに関する証明書（以下ＳＳＯ証明書４１）を生成し、さらにハンドルＩＤを発行する。

このハンドルＩＤはＷｅｂシステム１−ａに一意に対応付けられたシステムＩＤと、一時的でランダムな文字、数字等から構成するキーＩＤと、を予め決めておいた書式に従って組み合わせて構成する。

つぎに、当該ＳＳＯ証明書４１が当該キーＩＤから一意に特定できるよう、キーＩＤと対応付けた形でＳＳＯ証明書４１がＤＢ１６上のＳＳＯ証明書管理テーブルに一時的に保存される。また、ＳＳＯ証明書に含まれるＳＳＯセッション情報は、セッション情報ＤＢ１６のＳＳＯセッション管理テーブル１０００およびＳＳＯ履歴テーブル２０００にローカルセッションと関連付けて保存される。

次に発行した当該ハンドルＩＤをユーザ端末２−ａに送信する（２０５）。ハンドルＩＤは悪意のあるユーザによる改ざん、偽造による危険を減らすためデジタル署名技術を用いて電子署名を施した上で送受信することが望ましい。

ユーザ２−Ａはユーザ端末２−ａよりＷｅｂシステム１−ｂにアクセスし、シングルサインオンおよびサービスの提供を要求する。この際、Ｗｅｂシステム１−ａより受信したハンドルＩＤを通知する（２０６）。

Ｗｅｂシステム１−ｂのユーザ管理部１１は受け取ったハンドルＩＤを解読し、システムＩＤよりＷｅｂシステム１−ａを特定し、ハンドルＩＤをもとにＷｅｂシステム１−ａに対してＳＳＯ証明書４１を要求する。

Ｗｅｂシステム１−ａのユーザ管理部１１ではハンドルＩＤに含まれるキーＩＤよりメモリ上のＳＳＯ証明書管理テーブルを検索し、ＳＳＯ証明書４１を特定し、Ｗｅｂシステム１−ｂに送信する。

Ｗｅｂシステム１−ｂのユーザ管理部１１では当該ＳＳＯ証明書４１を受け付けると、署名情報を検証するとともに、当該するユーザ情報があるか登録ユーザ情報ＤＢ１４を検索し、有効なユーザ情報がある場合はアクセスを許可し、ない場合はアクセス拒否メッセージをユーザ端末２−ａに送信する（２０７）。

シングルサインオンによるアクセスを許可した場合、Ｗｅｂシステム１−ｂのセッション管理部１２はまず受信したＳＳＯ証明書４１に含まれる、ＳＳＯセッション情報を読み出し、更新が必要な情報を更新してセッション情報ＤＢ１６のＳＳＯセッション管理テーブル１０００およびＳＳＯ履歴テーブル２０００に登録する。

更新する主な情報は、ＳＳＯ履歴情報であるＳＳＯシステムＩＤ２００３（ここではＷｅｂシステム１−ｂを識別するＩＤ）および移動元システムＩＤ２００４（ここでは移動元システムであるＷｅｂシステム１−ａを識別するＩＤ）およびステータス２００５（ここではシングルサインオン成功なので“ログイン”）および最終更新時刻１００５および最終更新者１００５である。また、ＳＳＯセッション有効期限１００７がＷｅｂシステム１−ｂのサービスを提供するのに十分ではない場合は、ＳＳＯセッション有効期間１００７を延長して登録する。

次にＷｅｂシステム１−ｂは更新したＳＳＯセッション情報を含む上記ＳＳＯセッション更新要求書を生成し、移動元システムであるＷｅｂシステム１−ａに送信し、ＳＳＯセッション更新要求を行う（２０８）。

ＳＳＯセッション更新要求書を受信したＷｅｂシステム１−ａのセッション管理部１２では、受信したＳＳＯセッション更新要求書に含まれるＳＳＯセッションＩＤ１００４を基にＳＳＯセッション管理テーブル１０００およびＳＳＯ履歴テーブル２０００を検索し、当該のフィールドを受信したＳＳＯセッション情報に更新する。また、この際ＳＳＯセッション有効期限１００７が更新されている場合は、ユーザ２−Ａとの間に設定してあるローカルセッションの有効期限をＳＳＯセッション有効期限１００７に合わせて更新する（２０９）。

次にＷｅｂシステム１−ａではユーザ２−Ａのシングルサインオン経路（以下ＳＳＯ経路と呼ぶ）を計算する。このＳＳＯ経路の計算はＳＳＯセッション情報に含まれるＳＳＯシステムＩＤ２００３、移動元システムＩＤ２００４よりユーザ２−Ａがどのシステムからどのシステムにシングルサインオンにより移動したのかを判定することにより計算される。Ｗｅｂシステム１−ａは計算されたＳＳＯ経路情報より、当該Ｗｅｂシステム１−ａとＳＳＯ経路の上で隣接関係のあるアプリケーションシステムを特定し、その中で、既にＳＳＯセッション情報を更新済みであるＳＳＯセッション更新要求書の送信元のＷｅｂシステム１−ｂ以外のシステムにＳＳＯセッション情報の更新要求を行う（２１０）。ただし、本実施例ではＷｅｂシステム１−ａはＷｅｂシステム１−ｂとだけＳＳＯ経路上隣接関係にあるので、ＳＳＯセッション情報の更新要求は行わない。

Ｗｅｂシステム１−ｂではＳＳＯセッション更新要求を送信後、ユーザ端末２−ａとの間にローカルセッションを設定する。この際、ローカルセッションの有効期限は更新したＳＳＯセッション有効期限１００７と同じに設定する。次にＷｅｂシステム１−ｂは提供しているサービスの画面をユーザ端末に表示する（２０３）。

ユーザ２−ＡがＷｅｂシステム１−ｂから別のＷｅｂシステム１−ｃへシングルサインオンする場合は上記シングルサインオン処理およびＳＳＯセッション情報更新処理（２０４〜２１０、２０３）と同様の処理を繰り返し、Ｗｅｂシステム１−ｃがＷｅｂシステム１−ｂからＳＳＯ証明書を取得することによりシングルサインオンを実行する。

ただし、ユーザ２−ＡがさらにＷｅｂシステム１−ｂからＷｅｂシステム１−ｃにシングルサインオンした場合、ＳＳＯ経路上Ｗｅｂシステム１−ｂはＷｅｂシステム１−ａおよびＷｅｂシステム１−ｃと隣接関係にある。従って、Ｗｅｂシステム１−ｂは、Ｗｅｂシステム１−ｃよりＳＳＯセッション更新要求書を受信した際、ＳＳＯセッション更新要求をさらにＷｅｂシステム１−ａに行う（２１１）。

以上に示したように、ユーザが複数のアプリケーションシステム間でシングルサインオンを行う際に、シングルサインオン経路上の全てのアプリケーションシステムでＳＳＯセッション情報を同期させ（一致させ）、さらに各アプリケーションシステムでＳＳＯセッション情報とローカルセッションを同期させる（一致させる）ことにより、シングルサインオンを行ったシステム全体でＳＳＯセッションの連携を実現する。これにより、セッションタイムアウト等による不意のログアウトを防ぐことができる。

（第２の実施形態）
以下、図８を用いて、第２の実施形態であるユーザに対するシングルサインオンセッション情報の表示および特定のシステムからの選択的なログアウト（以下、選択ログアウトという）について説明する。前提として、第１の実施例に従いユーザ２−ＡはＷｅｂシステム１−ａ、１−ｂ、１−ｃを順にシングルサインオンした状態とする。

ユーザ２−Ａはシングルサインオンでログイン中のＷｅｂシステムの一つ（ここではＷｅｂシステム１−ｃとする）に、現在のシングルサインオンセッションの情報を要求する（３０１）。

要求を受け付けたＷｅｂシステム１−ｃのセッション情報表示部１３はユーザ端末２−ａからＣｏｏｋｉｅなどにより設定しているローカルセッションＩＤ１００３を取得し、ローカルセッションＩＤ１００３をキーにＳＳＯセッション管理テーブル１０００およびＳＳＯ履歴テーブル２０００より当該ＳＳＯセッション情報を検索する。

具体的には、ローカルセッションＩＤ１００３をキーにＳＳＯセッション管理テーブルより当該ＳＳＯセッションＩＤ１００４の値を検索し、さらに検索した当該ＳＳＯセッションＩＤ１００４をキーにＳＳＯ履歴テーブル２０００より、ＳＳＯ履歴テーブル２０００上の各データを検索し取得する。

取得した情報をもとにＷｅｂ画面を生成しユーザ端末２−ａに送信し、Ｗｅｂクライアントに表示する（３０２）。

図９に上記ステップ３０２においてユーザ端末２の表示装置１０６に表示されるＳＳＯセッション情報表示画面（５０）の例を示す。図９中、５１は現在シングルサインオンによりログイン中のアプリケーションシステムとそのシングルサインオン経路を表すシングルサインオンセッションマップ５１の例であり、ユーザは現在ログイン中のシステムを確認できる。

また、例えばログアウトしたい特定のシステムを選択して選択ログアウト要求や、シングルサインオンしている全てのシステムからの一括ログアウト等を選択しボタンを押すことにより要求することができる。

５２はＳＳＯセッション情報に含まれている現在のＳＳＯセッション有効期限１００７を表示する例であり、必要に応じて有効期限の延長要求を行うことができる。また５３は、ＳＳＯセッション情報のステータス２００５よりログアウト済みのシステムを検索し表示した例である。

次に、ユーザ２−ＡがＷｅｂシステム１−ｃからＷｅｂシステム１−ｂの選択ログアウトを行う方法を以下に説明する。ユーザ２−ＡはＳＳＯセッション情報表示画面５０からログアウトするＷｅｂシステム１−ｂを選択し、選択ログアウトを要求する（３０３）。要求を受け付けたＷｅｂシステム１−ｃのセッション管理部は、当該ユーザ２−ＡのＳＳＯセッション情報を基にログアウト要求書４２を生成し、Ｗｅｂシステム１−ｂに送信する。

ログアウト要求を受け付けたＷｅｂシステム１−ｂのセッション管理部１２は、受信したログアウト要求書４２に記載のＳＳＯセッションＩＤをキーにＳＳＯセッション管理テーブル１０００およびＳＳＯ履歴テーブル２０００より当該ＳＳＯセッション情報を検索する。さらにＳＳＯセッション情報のローカルセッションＩＤ１００３をキーに、ローカルセッションテーブルよりローカルセッション情報を検索し、このローカルセッション情報を削除することによりログアウトを実行する（３０５）。

次にログアウトした当該Ｗｅｂシステム１−ｂを除いた新たなシングルサインオン経路（ＳＳＯ経路）を計算し、ＳＳＯセッション情報を更新する。この新ＳＳＯ経路の計算においては、例えばまず当該Ｗｅｂシステム１−ｂからシングルサインオンにより移動した先のアプリケーションシステム（ここではＷｅｂシステム１−ｃ）と、当該Ｗｅｂシステム１−ｂの移動元のアプリケーションシステム（ここではＷｅｂシステム１−ａ）を検索する。次に移動先のＷｅｂシステム１−ｃの移動元システムを当該Ｗｅｂシステム１−ｂの移動元システムである１−ａに変更する。

これにより当該Ｗｅｂシステム１−ｂと隣接関係のあるＷｅｂシステム１−ａと１−ｃ間で新たなＳＳＯ経路を決定し、ＳＳＯセッション情報の移動元システムＩＤ２００４を更新する。また、ログアウトによりＳＳＯセッション情報の中で更新された情報（ここではステータス２００５、最終更新時刻１００５、最終更新者１００６）を更新し、ＳＳＯセッション更新要求書を生成する。そして、ログアウト前にＷｅｂシステム１−ｂと隣接関係のあったＷｅｂシステム１−ａ、Ｗｅｂシステム１−ｃにＳＳＯセッション更新要求書を送信する（３０６）。

ＳＳＯセッション更新要求書を受信したＷｅｂシステム１−ａ、Ｗｅｂシステム１−ｃのセッション管理部１２は上記実施例１のステップ２０９、２１０と同様にＳＳＯセッション情報の更新等の処理を行う。

Ｗｅｂシステム１−ｂでは上記ＳＳＯセッション更新要求書を送信した後、ＳＳＯセッション情報テーブル１０００の当該ＳＳＯセッション情報を削除する（３０７）。

以上に示したように、各アプリケーションシステムで分散管理しているＳＳＯセッション情報を基にＳＳＯセッション情報をユーザに提示することにより、ユーザ自身が現在どのシステムにログイン中であるか、いつでも確認することができ、さらにどのシステムにアクセスしている時でも、特定のシステムから選択的にログアウトを行うことができる。なお、複数システムからのログアウトを行う際は、上記選択ログアウトを繰り返せばよい。

（第３の実施形態）
以下、図１０を用いて、第３の実施形態であるアプリケーションシステムの障害情報の通知について説明する。前提として、第１の実施例に従いユーザ２−ＡはＷｅｂシステム１−ａ、１−ｂ、１−ｃの順にシングルサインオンした状態とする。

各Ｗｅｂシステム１−ａ、１−ｂ、１−ｃのセッション管理部１２は、それぞれ繰り返し（例えば、５分毎）にＳＳＯ経路上の隣接システムに対して状態確認要求メッセージを送信する。状態確認要求メッセージには当該ユーザ２−Ａのシングルサインオンセッションを識別するＳＳＯセッションＩＤ１００４などが含まれる。

状態確認要求メッセージを受信した各Ｗｅｂシステム１−ａ、１−ｂ、１−ｃのセッション管理部１２は当該ＳＳＯセッションＩＤ１００４をキーにＳＳＯセッション管理テーブル１０００およびＳＳＯ履歴テーブル２０００を検索し、当該ＳＳＯセッション情報があれば予め定めておいた正常を示すメッセージを送信する。
何らかの原因でローカルセッションが終了してしまっている、データが消去してしまっている場合など、当該ＳＳＯセッション情報がない場合は、予め定めておいたエラーメッセージを送信する。

各Ｗｅｂシステム１−ａ、１−ｂ、１−ｃは正常を示す状態確認結果を受信した場合は、何もせずに定期的に状態確認処理を実施し、エラーメッセージを受信、または状態確認結果を受信しなかった場合は下記に示す障害発生時の処理を実施する（４０１）。

本第３の実施形態ではＷｅｂシステム１−ｂに障害（例えばサーバ停止）が発生し、Ｗｅｂシステム１−ａがＷｅｂシステム１−ｂに送信した状態確認要求メッセージに対する状態確認の結果を受信できなかった場合を例に、障害発生時の処理を以下に説明する。

１回または数回に渡り連続して（例えば、３回続けて）状態確認の結果を受信できなかった場合、Ｗｅｂシステム１−ａは、アクセス不能となった（すなわち、ローカルセッションが終了している）Ｗｅｂシステム１−ｂをアクセス不能状態と判断し（４０２）、当該ＳＳＯセッション情報のステータス２００５のうち、ＳＳＯシステムＩＤ２００３がＷｅｂシステム１−ｂであるステータス２００５を、予め定めておいたアクセス不能を示すコードに変更する（４０３）。なお、本実施例においては、各システムが互いに監視し合うことにより、より確実な状態確認を行うようにしている。

さらに、上記ステップ３０６と同様に当該Ｗｅｂシステム１−ｂを除く新たなＳＳＯ経路を計算し、ＳＳＯセッション情報を更新し、ＳＳＯ経路上の各アプリケーションシステム（ここではＷｅｂシステム１−ｃ）に更新されたＳＳＯセッション情報を送信する（３０６）。

さらに障害が発生したという情報は、ユーザからログイン中のアプリケーションサーバ（ここではＷｅｂシステム１−ｃとする）にアクセスがあった際に、当該アプリケーションサーバが上記実施例２のステップ３０２およびＳＳＯセッション情報表示画面５０を用い、ユーザに通知する（４０４）。

以上の通り、各実施形態によればユーザが複数のアプリケーションシステムに跨ってログインを継続しシングルサインオンを行う場合において、システム間でのセッションを連携させ不意のログアウトを防ぐとともに、ユーザにシングルサインオンのセッションに関する情報を提示し、一部のサーバからの選択的なログアウトなどのサービスを提供する。また、何らかの原因により一部のシステムでログインセッションが終了してしまった場合でもユーザに早く通知することができる。これにより、安全で利便性の高いシングルサインオンのセッション管理を実現することができる。

本発明を用いたシングルサインオン、セッション管理などサービスを提供するネットワーク構成と、システム構成および機能モジュール構成を示す図である。 ＳＳＯセッション管理テーブルの一例を示す図である。 ＳＳＯ履歴テーブルの一例を示す図である。 アプリケーションシステム構成する各装置のハードウェア構成を示す図である。 ＳＳＯ証明書のデータ構成例である。 ログアウト要求書のデータ構成例である。 実施例１に係るシングルサインオン時のシステム間でのセッション情報の連携処理のフロー図である。 実施例２に係るシングルサインオンセッション情報のユーザへの提示および選択ログアウト処理のフロー図である。 実施例２に係るＳＳＯセッション情報表示画面の例を示す説明図である。 実施例３に係る障害情報の検出および通知処理のフロー図である。

符号の説明

１…アプリケーションシステム、２…ユーザ端末、３…認証局端末、４…ネットワーク、５…ネットワーク、４１…ＳＳＯ証明書、４２…ログアウト要求書、５０…ＳＳＯセッション情報表示画面、１０００…ＳＳＯセッション管理テーブル、２０００…ＳＳＯ履歴テーブル

Claims (11)

1. ユーザに対してサービスを提供する複数のアプリケーションシステムに、前記ユーザがシングルサインオンする場合のセッションを管理するセッション管理システムであって、
   各々の前記アプリケーションシステムは、ユーザ管理部と、セッション管理部とを備え、
   第１の前記アプリケーションシステムで認証済みの前記ユーザが、ユーザ端末を用いて、第２のアプリケーションシステムにアクセスする際に、
   第２の前記アプリケーションシステムの前記ユーザ管理部は、
   前記第１のアプリケーションシステムの前記ユーザ管理部から前記ユーザに関するシングルサインオン証明書を受信し、
   前記シングルサインオン証明書に基づいて、当該第2のアプリケーションシステムへの、ログイン処理を行い、
   第２の前記アプリケーションシステムの前記セッション管理部は、
   前記シングルサインオン証明書に含まれるセッション情報を更新して登録し、かつ、前記セッション情報の更新要求を前記第1のアプリケーションシステムに送信し、
   前記第1のアプリケーションシステムの前記セッション管理部は、送信された更新要求を用いて、自アプリケーションシステムの前記セッション情報を更新する
   ことを特徴とするセッション管理システム。
2. 請求項１に記載のセッション管理システムであって、
   前記第１のアプリケーションシステムの前記ユーザ管理部は、
   前記ユーザが前記ユーザ端末を用いて行う前記第2のアプリケーションシステムへのシングルサインオン要求を受信し、
   前記ユーザに関わる情報を用いた、前記シングルサインオン証明書と、前記シングルサインオン証明書に関連づけられ、当該第１のアプリケーションシステムを特定するハンドルＩＤと、を作成し、
   前記ハンドルＩＤを前記ユーザ端末に送信する
   ことを特徴とするセッション管理システム。
3. 請求項２に記載のセッション管理システムであって、
   前記ユーザ端末は、前記第2のアプリケーションシステムへのシングルサインオン要求時に、前記ハンドルＩＤを送信し、
   前記前記第2のアプリケーションシステムのセッション管理部は、前記ハンドルＩＤに関連づけられた前記シングルサインオン証明書を、前記第1のアプリケーションシステムに要求する
   ことを特徴とするセッション管理システム。
4. 請求項１に記載のセッション管理システムであって、
   前記第１のアプリケーションシステムの前記セッション管理部は、
   前記セッション情報に基づいて、前記シングルサインオンの経路を求め、
   前記第１のアプリケーションシステムへの移動元および／または移動先の、当該シングルサインオン中の他の前記アプリケーションシステムがある場合は、当該他のアプリケーションシステムに対して、前記セッション情報の更新要求を送信し、
   前記他のアプリケーションシステムの前記セッション管理部は、送信された更新要求を用いて、自アプリケーションシステムの前記セッション情報を更新する
   ことを特徴とするセッション管理システム。
5. 請求項１に記載のセッション管理システムであって、
   前記アプリケーションシステムは、前記ユーザ端末に対して、前記ユーザの前記シングルサインオンによりログイン中の前記アプリケーションシステムと、そのシングルサインオン経路に関する前記セッション情報に基づいた表示を行うセッション情報表示部を備える
   ことを特徴とするセッション管理システム。
6. 請求項１記載のセッション管理システムであって、
   前記セッション管理部が管理するセッション情報には、
   前記ユーザの前記アプリケーションシステムへのローカルセッション情報、および／または前記ユーザがシングルサインオンにより移動したおよび／または移動してきた複数の前記アプリケーションシステムに関する情報、および／またはシングルサインオンにより移動した複数の前記アプリケーションシステム間の移動経路に関する情報を含む
   ことを特徴とするセッション管理システム。
7. 請求項１記載のセッション管理システムであって、
   前記第２のアプリケーションシステムの前記セッション管理部は、
   前記第１のアプリケーションシステムから前記ユーザがシングルサインオンによりログインした際に、前記セッション情報を生成し、移動元の前記第１のアプリケーションシステムに対してセッション延長情報を送信し、
   シングルサインオン先の前記第３のアプリケーションシステムからセッション延長情報を受信した際には、該ユーザとの間のローカルセッション情報を更新し、シングルサインオン元の前記第１のアプリケーションシステムに対して受信した前記セッション延長情報を送信する
   ことを特徴とするセッション管理システム。
8. 請求項４記載のセッション管理システムであって、
   前記セッション管理部は、
   管理している前記セッション情報に記載の、移動元および／または移動先の前記アプリケーションシステムに対して、前記ユーザとのローカルセッションが継続しているか確認し、
   該ローカルセッションが既に終了している場合は、当該アプリケーションシステムを除く、新たなシングルサインオン経路を求め、前記セッション情報を更新し、前記セッション情報の更新要求を送信し、
   セッション情報の更新要求を受信した場合は、該セッション管理部が管理している前記セッション情報を更新する
   ことを特徴とするセッション管理システム。
9. 請求項８記載のセッション管理システムであって、
   前記ユーザが、ローカルセッションが終了していない前記アプリケーションシステムにアクセスした場合に、前記セッション情報表示部は、前記ローカルセッションが終了している前記アプリケーションシステムについて通知する
   ことを特徴とするセッション管理システム。
10. 請求項１記載のセッション管理システムであって、
    前記第1のアプリケーションシステムにおいて、
    前記セッション情報表示部は、
    前記ユーザの前記シングルサインオンに関する前記セッション情報に基づく表示を前記ユーザ端末に行い、
    前記ユーザから他の前記アプリケーションシステムに対する選択ログアウト要求を受け付け、
    前記セッション管理部は、選択ログアウトする前記他のアプリケーションシステムに対して、ログアウト要求を送信する
    ことを特徴とするセッション管理システム。
11. 請求項１０記載のセッション管理システムであって、
    前記ログアウト要求を受信した前記他のアプリケーションシステムのセッション管理部は、
    当該アプリケーションシステムにおけるローカルセッションを削除し、
    当該アプリケーションシステムを除く、新たなシングルサインオン経路を求め、前記セッション情報を更新し、
    当該アプリケーションシステムへの移動元および／または移動先の前記アプリケーションシステムへ、前記セッション情報の更新要求を送信し、
    当該アプリケーションシステムにおいて管理する前記セッション情報を削除する
    ことを特徴とするセッション管理システム。
    

Images