JP2007293760A - 個別認証を用いたシングルサインオン連携方法およびシステム - Google Patents

Abstract

【課題】既存サービスサイトにＳＳＯ技術を適用する場合、利用するユーザと利用しないユーザが混在する環境になる可能性がある。また、ＳＳＯ利用ユーザにログイン先のＵＲＬやログインＩＤを変更させるため、ユーザに負担がかかる。
【解決手段】各サービスサイトが、個別ログインＩＤに対してＳＳＯ利用ユーザの可否を判定する情報を持ち、個別ログイン画面から前記個別ログインＩＤとパスワードでログインしたクライアント端末がＳＳＯ利用ユーザかを判定し、ＳＳＯ利用ユーザであれば当該クライアント端末をＳＳＯ認証サーバにリダイレクトさせ、前記個別ログインＩＤ情報と、前記サービスサイトのログイン成功情報を前記ＳＳＯ認証サーバに渡し、前記ＳＳＯ認証サーバは、受け取った前記個別ログインＩＤ情報を元に、それに紐付くＳＳＯログインＩＤ情報を取得し、当該クライアント端末のＳＳＯ認証を行う。
【選択図】図１

Description

本発明は、ユーザがクライアント端末から、インターネット上のあるサイトにログインした後に、別サイトに遷移する場合、再度ログインＩＤとパスワードを入力することなくログインが可能となるシングルサインオン（ＳＳＯ）システムに関する。

複数のサービスサイトを利用しているユーザは、各サービスサイトで利用するログインＩＤとパスワードを管理し、各サービスサイトにログインする度にログインＩＤとパスワードを入力する必要があった。その問題を解決するために、一度ログインＩＤとパスワードをユーザが入力した後は、ログインＩＤとパスワードの入力の必要がなく他サービスサイトにログイン可能なＳＳＯ技術がある。

ＳＳＯの従来技術として、エージェント型、リバースプロキシ型が存在する。エージェント型は、各サイトにエージェントプログラムを設置し、ＳＳＯ認証処理を行っていないユーザがクライアント端末からサイトにアクセスした場合に、エージェントプログラムがクライアント端末のアクセスをＳＳＯの認証サーバにリダイレクトさせて認証処理を行う。リダイレクトとは、サーバが指定したアクセス先にクライアント端末を誘導する仕組みであり、ＨＴＴＰプロトコルなどで規定されている。

リバースプロキシ型は、リバースプロキシサーバにエージェントプログラムを設置し、ＳＳＯ認証処理を行っていないユーザがクライアント端末からリバースプロキシサーバにアクセスした場合に、エージェントプログラムがクライアント端末のアクセスをＳＳＯの認証サーバにリダイレクトさせてＳＳＯ認証処理を行う。ＳＳＯ認証後、ＳＳＯ認証サーバがクライアント端末をリバースプロキシサーバにリダイレクトし、リバースプロキシサーバはクライアント端末の代わりにサイトからコンテンツを取得し、クライアント端末に対してコンテンツを送信する。

従来技術では、ＳＳＯ用のログインＩＤが各サービスサイトのログインＩＤとは独立して存在し、ユーザは、ＳＳＯ用ログインＩＤを用いてＳＳＯの認証を受ける。また、ユーザがＳＳＯの認証を受ける場合、各サービスの個別ログイン画面ではなく、ＳＳＯ用のログイン画面で認証を受ける。シングルサインオンシステムの従来技術は、特許文献１で開示されている。
特開平９−８１５１８号公報

独立してログインＩＤを管理している複数のサービスサイトが既に存在し、その複数サービスサイトに対してＳＳＯシステムを適用する場合、各ユーザの利用サービス数や契約関係などから、ＳＳＯシステムを利用するユーザと、利用しないユーザが混在する環境となる場合がある。ＳＳＯシステムを利用するユーザが、クライアント端末から各サービスサイトにログインする場合、ＳＳＯ用のログイン画面にアクセスし、ＳＳＯ用のログインＩＤを用いて認証を受ける。ＳＳＯシステムを利用しないユーザがクライアント端末から各サービスサイトにログインする場合、各サービスサイトの個別ログイン画面にアクセスし、各サービスサイトの個別ログインＩＤとパスワードを用いて認証を受ける。

従来技術では、ＳＳＯシステムの利用開始時に、ＳＳＯシステム利用ユーザが、各サービスサイトの個別ログイン画面へのアクセス先と個別ログインＩＤを、ＳＳＯ用ログイン画面とＳＳＯ用ログインＩＤに変更しなければならないため、ユーザに負担がかかるという問題がある。

本発明の目的は、ユーザがクライアント端末から、各サービスサイトの個別ログイン画面にアクセスし、サービスサイトの個別ログインＩＤとパスワードを用いて認証を受けた場合、ＳＳＯシステム利用ユーザであれば、ＳＳＯの認証が行われ、ＳＳＯシステムを利用しないユーザであればそのサービスサイトの個別ログインのみを行うシングルサインオンシステムを提供し、ＳＳＯ利用ユーザの利便性を高めることにある。

課題を解決するための方法として、各サービスサイトが、個別ログインＩＤに対してＳＳＯ利用ユーザの可否を判定する情報を持ち、個別ログイン画面から前記個別ログインＩＤとパスワードでログインしたユーザがＳＳＯ利用ユーザかを判定し、ＳＳＯ利用ユーザであれば当該ユーザのクライアント端末をＳＳＯ認証サーバにリダイレクトさせ、前記個別ログインＩＤ情報と、前記サービスサイトのログイン成功情報を前記ＳＳＯ認証サーバに渡し、前記ＳＳＯ認証サーバは、受け取った前記個別ログインＩＤ情報を元に、それに紐付くＳＳＯログインＩＤ情報を取得し、当該ユーザのクライアント端末のＳＳＯ認証を行うことを特徴とするシングルサインオン方法がある。

また他の方法として、各サービスサイトにはＳＳＯ利用ユーザの可否を判定する情報を持たず、個別ログイン画面から前記個別ログインＩＤとパスワードでログインした全てのユーザのクライアント端末をＳＳＯ認証サーバにリダイレクトさせ、前記個別ログインＩＤ情報と、前記サービスサイトのログイン成功情報を前記ＳＳＯ認証サーバに渡し、前記ＳＳＯ認証サーバは、受け取った前記個別ログインＩＤ情報を元に、それに紐付くＳＳＯログインＩＤ情報が取得可能であれば、当該ユーザのクライアント端末のＳＳＯ認証を行い、ＳＳＯログインＩＤ情報が取得不可能であればＳＳＯ認証を行わないことを特徴とするシングルサインオン方法がある。

本発明により、各サービスサイトでＳＳＯを利用するユーザと利用しないユーザが混在する環境で、ＳＳＯ利用ユーザはサービスサイトへログインするアクセス先と個別ログインＩＤを変更することなく、ＳＳＯ認証サーバの認証を受けることができ、ＳＳＯ利用ユーザの利便性が向上する。

以下、図を用いて本発明の実施の形態を詳細に説明する。実施例１、２は、エージェント型、実施例３、４はリバースプロキシ型のＳＳＯ技術を用いた本発明の実施例である。

本発明のシステム構成例を図１に示し、処理フローを図４、図５に示す。処理フローの中でシステムが管理する情報を、図２、図３、図６、図７、図８、図９、図１０に示す。図４、図５の処理フローのＨＴＴＰ要求・応答は暗号化されたＨＴＴＰＳプロトコルを利用する。処理フローの図は、縦の点線がシステムが行う処理、横向きの矢印線がシステム間の通信を示しており、各システムの動作を同時に示している。

図１は、本発明のシステム構成例であり、ユーザが利用するＷｅｂブラウザなどのクライアント端末２と、ＳＳＯ認証を行うＳＳＯ認証サーバ３と、サービスを提供するサービスサイトＡのアプリケーションサーバ４と、サービスサイトＢのアプリケーションサーバ５が、インターネット１でそれぞれ接続されている。

クライアント端末２は、例えば、パーソナルコンピュータや携帯電話等であり、サーバとの間でＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ），ＨＴＴＰＳ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）プロトコルでの通信が可能なＷｅｂブラウザ等のアプリケーションを保有しており、セッション管理情報としてクッキー等が利用可能であるものとする。クライアント端末２は安全性を考慮して、暗号化された通信を行うＨＴＴＰＳプロトコルなどを利用することが望ましい。

アプリケーションサーバ４は、サービスを提供するアプリケーションであり、個別ログイン用ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）と、ＳＳＯ用ＵＲＬを保有している。クライアント端末２が個別ログイン用ＵＲＬにアクセスした場合、アプリケーションサーバ４は、クライアント端末２を介してユーザに個別ログインＩＤとパスワードを入力させ、サービスの利用を許可する。

一方、クライアント端末２がＳＳＯ用ＵＲＬにアクセスした場合、アプリケーションサーバ４が保有しているＳＳＯエージェントプログラム６が動作する。ＳＳＯエージェントプログラム６は、クライアント端末２がＳＳＯ認証サーバ３からＳＳＯの認証を受けているか確認し、ＳＳＯ認証を受けていればアプリケーションサーバ４のサービスの利用を許可し、ＳＳＯ認証を受けていなければクライアント端末２をＳＳＯ認証サーバ３にリダイレクトし、ＳＳＯ認証サーバ３でＳＳＯの認証を行わせる。ＳＳＯエージェントプログラム６は、ＳＳＯシステムの一機能であり、ＳＳＯ製品の中に含まれていることが多い。アプリケーションサーバ４は、ＳＳＯ用ＵＲＬにアクセスしてＳＳＯエージェントプログラム６がＳＳＯ認証を確認したクライアント端末２に対して、ログインＩＤとパスワードの入力画面を表示しないという設定が必要となる。ＳＳＯエージェントプログラム６は、ＳＳＯ認証を受けたユーザを識別するため、図１０に示す、サービスサイトログインＩＤ１００１と、セッション情報１００２と、セッション有効期限１００３を管理している。

ＳＳＯ認証サーバ３でクライアント端末２がＳＳＯの認証を受けている場合、クライアント端末２がアプリケーションサーバ４もしくはアプリケーションサーバ５のＳＳＯ用ＵＲＬにアクセスすると、クライアント端末２はログインＩＤとパスワードの入力の必要なしにサービスの利用が許可され、シングルサインオンが実現する。

ＳＳＯ認証サーバ３は、図２で示すＳＳＯログインＩＤ２０１と、パスワード２０２と、サービスサイトＡログインＩＤ２０３と、サービスサイトＢログインＩＤ２０４の静的な情報と、ＳＳＯログインＩＤ２０１に対応するセッションＩＤ２０５と、セッション有効期限２０６の動的な情報を管理している。ＳＳＯログインＩＤ２０１と、パスワード２０２と、サービスサイトＡログインＩＤ２０３と、サービスサイトＢログインＩＤ２０４は、ユーザのＳＳＯ利用申し込み時などに、ユーザもしくはユーザ企業の管理者、もしくはＳＳＯ認証サーバのシステム管理者などによって設定され、パスワード２０２はユーザもしくはユーザ管理者によって更新される。セッションＩＤ２０５と、セッション有効期限２０６は、ＳＳＯ認証サーバ３においてクライアント端末２の認証が成功した場合に、ＳＳＯ認証サーバ３によって生成される。セッションＩＤとセッション有効期限の組合せを、セッション情報と定義する。

その他にＳＳＯ認証サーバ３においては、ＳＳＯ認証後にアプリケーションサーバ４もしくは、アプリケーションサーバ５にクライアント端末２をリダイレクトするため、図６に示す、サービスサイトＩＤ６０１と、リダイレクト先個別ログインＵＲＬ６０３とリダイレクト先ＳＳＯ用ＵＲＬ６０４を管理している。

ＳＳＯ認証サーバ３では、各サービスサイトのアプリケーションサーバで暗号化された情報を復号するために、図６で示すサービスサイトＩＤ６０１と、そのサービスサイトが利用する秘密鍵６０２の情報を有する。アプリケーションサーバ４、アプリケーションサーバ５は、それぞれ秘密鍵６０２と同一の情報を有する。暗号化の方式は、対称鍵暗号方式、非対称鍵暗号方式などあるが、この例では対称鍵暗号方式を利用している。秘密鍵６０２は、ＳＳＯ認証サーバと各サービスサイトのシステム管理者が事前に鍵を交換し設定する。秘密鍵６０２をシステム管理者同士がオンラインで交換する場合、非対称鍵暗号方式を用い、互いの公開鍵をオンラインで交換し、相手の公開鍵を用いて対象鍵暗号の秘密鍵６０２を暗号化して交換する方法もある。また、システム間で秘密鍵６０２を交換する場合も、交換先システムの公開鍵をシステムがオンラインで取得し、その公開鍵を用いて秘密鍵６０２をシステムが暗号化し交換する。システム間で公開鍵を用いて秘密鍵６０２を交換する場合は、毎回異なった値の秘密鍵６０２を交換することも可能であるため、システムの安全性が向上する。

アプリケーションサーバ４で認証が成功したという情報を、アプリケーションサーバ４が暗号化し、ＣｏｏｋｉｅやＵＲＬに情報を埋め込むなどして、クライアント端末２経由でＳＳＯ認証サーバ３へ送信するため、暗号化された情報が含まれるＣｏｏｋｉｅやＵＲＬ情報が盗まれてしまうと、リプレイ攻撃を受ける可能性がある。従って、ＳＳＯ認証サーバ３は、各サービスサイトのアプリケーションサーバで暗号化された情報の内容を復号し、図７に示すサービスサイトＩＤ７０１、サービスサイトログインＩＤ７０２、ランダム文字列有効期限７０３、ランダム文字列７０４の情報を管理し、同一の情報を受信した場合に検知することでリプレイ攻撃を防ぐ。ＳＳＯ認証サーバ３は、リプレイ攻撃を検知するための判定情報量を減らすために、管理している情報のランダム文字列有効期限７０３の期限が切れた情報を削除する。リプレイ攻撃の対処方法の詳細は後述する。アプリケーションサーバ４は、有効期限内に同一のランダム文字列の生成を回避するために、ランダム文字列生成時に図８に示すサービスサイトログインＩＤ８０１と、ランダム文字列有効期限８０２と、ランダム文字列８０３の組合せを有する。ランダム文字列有効期限８０２と、ランダム文字列８０３は、ランダム文字列有効期限８０２の期限が切れた場合にアプリケーションサーバ４によって消去される。

アプリケーションサーバ４では、図３で示すサービスサイトＡログインＩＤ３０１と、パスワード３０２と、ＳＳＯ利用可否３０３の静的な情報と、サービスサイトＡログインＩＤ３０１に対応するセッションＩＤ３０４と、セッション有効期限３０５の動的な情報を管理している。ＳＳＯ利用可否３０３は、初期値に利用不可を示す値（Ｉｎａｃｔｉｖｅ）を指定し、ＳＳＯ利用ユーザに対しては、ユーザ管理者もしくはサービスサイト管理者などが、ＳＳＯ利用可能を示す値（Ａｃｔｉｖｅ）を設定する。サービスサイトＡログインＩＤ３０１、パスワード３０２は、ユーザ管理者もしくはサービスサイト管理者が設定し、パスワード３０２はユーザやユーザ管理者が更新する。セッションＩＤ３０４と、セッション有効期限３０５は、アプリケーションサーバ４でクライアント端末２の認証が成功した場合に、アプリケーションサーバ４によって生成される。

その他に、アプリケーションサーバ４では、サービス画面上に他サービスサイトのリンクを表示するため、図９に示す、サービスサイトＩＤ９０１と、個別ログイン用ＵＲＬ９０２と、ＳＳＯ用ＵＲＬ９０３を管理している。

アプリケーションサーバ５は、アプリケーションサーバ４と同様の構成の情報を有する。

図４において、インターネット１に接続しているクライアント端末２が、アプリケーションサーバ４の個別ログイン用ＵＲＬに接続要求を行う（４０１）。アプリケーションサーバ４は、クライアント端末２に対し、個別ログイン画面を表示する認証要求を返す（４０２）。クライアント端末２は、個別ログイン画面を表示し、ユーザが個別ログインＩＤとパスワードの入力を行った後、アプリケーションサーバ４にユーザの入力した情報を送信する（４０３）。

アプリケーションサーバ４は、サービスサイトＡログインＩＤ３０１とパスワード３０２と、クライアント端末２から受け取ったログインＩＤとパスワードとの照合処理を行い、クライアント端末２を認証する（４０４）。ステップ４０４において認証失敗であった場合、アプリケーションサーバ４は再度個別ログイン画面を表示するなどの認証失敗通知をクライアント端末２に返し（４０５）、クライアント端末は認証失敗の画面を表示する（４０６）。

ステップ４０４において認証成功であった場合、アプリケーションサーバ４は、クライアント端末２のログインを許可し、次回以降のクライアント端末２からのアクセスを識別可能とするためのセッションＩＤ３０４とセッション有効期限３０５を持つセッション情報を作成し管理する（４０７）。ステップ４０７で作成されたセッションＩＤ３０４とセッション有効期限３０５は、クライアント端末２がアプリケーションサーバ４に対してログアウトした場合、もしくは一定時間アクセスせずタイムアウトした場合、もしくはセッション有効期限３０５を越えた場合に、アプリケーションサーバ４によって消去される。

次に、アプリケーションサーバ４は、ユーザのサービスサイトＡログインＩＤ３０１と、ＳＳＯ利用可否３０３の情報から、ステップ４０４で認証したユーザのサービスサイトＡログインＩＤ３０１に対し、ＳＳＯの利用が可能か判定する（４０８）。ステップ４０８でＳＳＯの利用不可という判定であった場合、アプリケーションサーバ４は、ステップ４０７で作成したセッションＩＤ３０４とセッション有効期限３０５をＣｏｏｋｉｅにセットし、ログイン後のサービス画面などを表示する認証成功通知と共にクライアント端末２に送信する（４０９）。クライアント端末２はアプリケーションサーバ４のログイン後のサービス画面を表示し（４１０）、その後ユーザはサービスを利用する。

ステップ４０８でＳＳＯの利用が可能という判定であった場合、アプリケーションサーバ４は、ステップ４０７で作成したセッションＩＤ３０４とセッション有効期限３０５をＣｏｏｋｉｅにセットし、その他にサービスサイトＡログインＩＤ３０１と、アプリケーションサーバ４においてユニークなランダム文字列８０３と、ランダム文字列有効期限８０２の３つの情報を暗号化したものと、暗号化を行ったアプリケーションサーバを示すサービスサイトＩＤをＣｏｏｋｉｅにセットし、クライアント端末２をＳＳＯ認証サーバ３にリダイレクトさせる情報と共にクライアント端末２に送る（４１１）。ステップ４１１において、リダイレクト先は常にＳＳＯ認証サーバ３のため、事前にアプリケーションサーバ４のシステム管理者がリダイレクト先を設定する。

ステップ４１１において、アプリケーションサーバ４とＳＳＯ認証サーバ３のドメインが異なるなど，Ｃｏｏｋｉｅが利用できない環境の場合、ＵＲＬの一部にセッション情報や暗号化した情報を埋め込む方法もある。

次に、クライアント端末２が、ＳＳＯ認証サーバ３にリダイレクトされ、ステップ４１１でアプリケーションサーバ４がＣｏｏｋｉｅの中に含めたサービスサイトＩＤと、暗号化した３つの情報を、ＳＳＯ認証サーバ３に送信する。ＳＳＯ認証サーバ３は、受け取ったＣｏｏｋｉｅから、サービスサイトＩＤと暗号化された情報を取得し、秘密鍵６０２を利用し、復号を行う（４１２）。

ＳＳＯ認証サーバ３は、ステップ４１２で復号した３つの情報とサービスサイトＩＤの情報から、はじめにランダム文字列有効期限が期限内かの判定を行い、次にサービスサイトＩＤ７０１と、サービスサイトログインＩＤ７０２と、ランダム文字列有効期限７０３と、ランダム文字列７０４と同一の組み合わせの情報がＳＳＯ認証サーバ３に存在するか照合し、リプレイ攻撃の検知を行う（４１３）。

ＳＳＯ認証サーバ３が暗号化された情報を復号できない場合、または復号が成功したがランダム文字列有効期限７０３が切れている場合、またはサービスサイトＩＤ７０１と、サービスサイトログインＩＤ７０２と、ランダム文字列有効期限７０３と、ランダム文字列７０４の同一の組み合わせが既にＳＳＯ認証サーバ３に存在する場合は、不正な情報とみなし、ＳＳＯ認証サーバ３は認証失敗通知情報をクライアント端末２に返す（４１４）。クライアント端末２は、認証失敗画面を表示し、処理を終了する（５５３）。

ＳＳＯ認証サーバ３が暗号化された情報を復号可能、かつ復号した情報のランダム文字列有効期限７０３が期限内、かつサービスサイトＩＤ７０１、サービスサイトログインＩＤ７０２、ランダム文字列有効期限７０３、ランダム文字列７０４と同一の組み合わせの情報がＳＳＯ認証サーバ３に存在しない場合において、ＳＳＯ認証サーバ３は、アプリケーションサーバ４で認証されたサービスサイトＡログインＩＤ３０１と、ＳＳＯ認証サーバ３が管理するサービスサイトＡログインＩＤ２０３と照合する（５０１）。リプレイ攻撃の検知をより強固にするために、ＳＳＯ認証サーバ３は、取得したランダム文字列７０４がアプリケーションサーバ４に存在するか、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）などを用いて確認する方法を組み合わせると良い。

ステップ５０１において照合に失敗した場合、ＳＳＯ認証サーバ３はクライアント端末２のＳＳＯ認証を行わず、アプリケーションサーバ４の個別ログイン用ＵＲＬ６０３にリダイレクトする（５０２）。ステップ５０２において、ＳＳＯ認証サーバ３がクライアント端末２を各アプリケーションサーバの個別ログイン用ＵＲＬにリダイレクトするため、ＳＳＯ認証サーバ３のシステム管理者は、事前にアプリケーションサーバ毎のリダイレクト先の個別ログイン用ＵＲＬ６０３をＳＳＯ認証サーバ３に設定する。

クライアント端末２はステップ４０７でセッション情報が作成され、ログインが許可されているため、アプリケーションサーバ４は、ログイン後のサービス画面などを表示する認証成功通知をクライアント端末２に送信する（５０３）。クライアント端末２はアプリケーションサーバ４のログイン後のサービス画面を表示し（５０４）、その後ユーザはサービスを利用する。

ステップ５０１において、照合に成功した場合、ＳＳＯ認証サーバ３はサービスサイトＡログインＩＤ２０３に紐付くＳＳＯログインＩＤ２０１を取得し（５０５）、ＳＳＯ認証を成功とする。

次回以降のクライアント端末２からのアクセスを識別するため、ＳＳＯ認証サーバ３は、セッションＩＤ２０５とセッション有効期限２０６の情報を作成し管理する（５０７）。ステップ５０７で作成したセッションＩＤ２０５とセッション有効期限２０６は、クライアント端末２がＳＳＯ認証サーバ３に対してログアウトした場合、もしくは一定時間アクセスせずタイムアウトした場合、もしくはセッション有効期限２０６を越えた場合に、ＳＳＯ認証サーバ３によって消去される。

ＳＳＯ認証サーバ３は、ステップ５０７で作成したセッションＩＤ２０５とセッション有効期限２０６をＣｏｏｋｉｅにセットし、クライアント端末２をアプリケーションサーバ４のＳＳＯ用ＵＲＬ６０４にリダイレクトする要求と共にクライアント端末２に送信する（５０８）。ステップ５０８において、ＳＳＯ認証サーバ３がクライアント端末２を各アプリケーションサーバのＳＳＯ用ＵＲＬにリダイレクトするため、ＳＳＯ認証サーバ３のシステム管理者は、事前にアプリケーションサーバ毎のリダイレクト先ＳＳＯ用ＵＲＬ６０４をＳＳＯ認証サーバ３に設定する。

クライアント端末２がアプリケーションサーバ４のＳＳＯ用ＵＲＬ６０４にリダイレクトされると、ＳＳＯエージェントプログラム６がクライアント端末２のＣｏｏｋｉｅにセットされているＳＳＯ認証サーバ３のセッションＩＤ２０５とセッション有効期限２０６を取得し、ＳＳＯ認証サーバ３にＳＳＬを利用し、セッションＩＤ２０５とセッション有効期限２０６が有効か問い合わせを行う（５０９）。

ＳＳＯ認証サーバ３は、ＳＳＯエージェントプログラム６から受け取ったセッションＩＤ２０５とセッション有効期限２０６が有効か検証し、有効であればサービスサイトＡログインＩＤ２０３の情報を返す（５１０）。

ＳＳＯエージェントプログラム６は、ＳＳＯ認証サーバ３から受け取ったサービスサイトＡログインＩＤ２０３の情報を元に、次回以降の認証済みのクライアント端末２からＳＳＯ用ＵＲＬへのアクセスを識別可能とするためのセッションＩＤ１００２と、セッション有効期限１００３を生成する（５１１）。ステップ５１１で作成されたセッションＩＤ１００２とセッション有効期限１００３は、クライアント端末２がＳＳＯ認証サーバ３に対してログアウトした場合、もしくは一定時間アクセスせずタイムアウトした場合、もしくはセッション有効期限１００３を越えた場合に、ＳＳＯエージェントプログラム６によって消去される。

アプリケーションサーバ４は、ステップ５１１で生成されたセッションＩＤ１００２とセッション有効期限１００３をＣｏｏｋｉｅにセットし、ログイン後のサービス画面などを表示する認証成功通知のコンテンツと共に、クライアント端末２に送信する（５１２）。クライアント端末２はアプリケーションサーバ４のログイン後のサービス画面を表示し（５１３）、その後ユーザはサービスを利用する。

ステップ５１３の時点で、クライアント端末２はＳＳＯ認証サーバ３に有効なセッションＩＤ２０５が存在するため、例えばクライアント端末２がアプリケーションサーバ５のＳＳＯ用ＵＲＬにアクセスした場合、アプリケーションサーバ５のＳＳＯエージェントプログラム６がＳＳＯ認証サーバ３にセッションＩＤ２０５の有効性を確認し、アプリケーションサーバ５のログインを許可する。ユーザは、アプリケーションサーバ５のログインＩＤとパスワードが要求されず、サービスを利用できる。

ユーザは、ＳＳＯの利用申し込み後であっても、従来と同じように個別ログイン用ＵＲＬから各アプリケーションサーバにログイン可能なため、ＳＳＯ用ＵＲＬを意識する必要はない。

しかし、クライアント端末２が、アプリケーションサーバ４からアプリケーションサーバ５へ遷移する場合、アプリケーションサーバ４が表示するリンク先の表示方法によってはユーザがＳＳＯ用ＵＲＬを意識する必要がある。例えば、アプリケーションサーバ４が、アプリケーションサーバ５の個別ログイン用ＵＲＬ９０２とＳＳＯ用ＵＲＬ９０３の２つのリンクを表示し、ユーザに遷移先を選択させる場合などである。

クライアント端末２が、アプリケーションサーバ４からアプリケーションサーバ５へ遷移する場合、ユーザにＳＳＯ用ＵＲＬを意識させないようにするために、アプリケーションサーバ４は、ログイン中のユーザがＳＳＯ認証を受けている場合、表示するアプリケーションサーバ５のリンクをＳＳＯ用ＵＲＬ９０３にする必要がある。アプリケーションサーバ４が表示するリンクのＵＲＬを動的に変更可能な場合、アプリケーションサーバ４は、ＳＳＯエージェント６が管理するセッションＩＤ１００２とセッション有効期限１００３を確認し、セッションＩＤ１００２とセッション有効期限１００３が有効期限内であれば、ＳＳＯ用ＵＲＬ９０３を表示し、有効期限切れもしくはセッションＩＤ１００２が情報として存在しなければ個別ログイン用ＵＲＬ９０２を表示する方法がある。

アプリケーションサーバ４が表示するリンクのＵＲＬを動的に変更不可能な場合や、画面表示プログラムの実装において判定を入れることが不可能な場合は、ＳＳＯ用ＵＲＬ判定ＣＧＩスクリプトをアプリケーションサーバ４に別途設置し、アプリケーションサーバ４は、ＳＳＯ用ＵＲＬ判定ＣＧＩのＵＲＬのリクエストパラメータに、サービスサイトＩＤ９０１の値をセットしたリンクを表示する。

ＳＳＯ用ＵＲＬ判定ＣＧＩスクリプトは、リクエストパラメータに含まれるサービスサイトＩＤ９０１を取得し、アプリケーションサーバ４のＳＳＯエージェント６が管理するセッションＩＤ１００２とセッション有効期限１００３を確認し、セッションＩＤ１００２とセッション有効期限１００３が有効期限内であれば、ＳＳＯ用ＵＲＬ９０３にクライアント端末２をリダイレクトし、有効期限切れもしくはセッションＩＤ１００２が情報として存在しなければ個別ログイン用ＵＲＬ９０２にクライアント端末２をリダイレクトする。

実施例２において、実施例１と異なる点を示す。

実施例２は、アプリケーションサーバ４が管理するＳＳＯ利用可否３０３の情報を持たないことを特徴とする。アプリケーションサーバ４は、図１１に示すサービスサイトＡログインＩＤ３０１と、パスワード３０２と、セッション情報３０４と、セッション有効期限３０５を管理する。

実施例１の処理フローは図４と図５の２つの図で示した。

実施例２の処理フローを、図１２と図５に示す。図１２において、実施例１の図４と異なる点は、ステップ４０８、４０９、４１０の機能を持たないことである。図５において、実施例１と実施例２は同一の内容である。

図１２のステップ４０７において、アプリケーションサーバ４の認証を受けた全てのクライアント端末２は、ステップ４１１においてＳＳＯ認証サーバ３にリダイレクトされる。ステップ５０１において、ＳＳＯ認証サーバ３は、アプリケーションサーバ４で認証されたサービスサイトＡログインＩＤ３０１と、ＳＳＯ認証サーバ３が管理するサービスサイトＡログインＩＤ２０３と照合し、照合に成功したクライアント端末２のみ、ＳＳＯ認証成功とする。図５のステップ５０１において、照合に成功しなかったクライアント端末２は、ＳＳＯ認証サーバ３からＳＳＯ認証されず、アプリケーションサーバ４の個別ログイン用ＵＲＬ９０２にリダイレクトされ、アプリケーションサーバ４へ個別ログインする。

実施例２は、各アプリケーションサーバに個別ログインしたユーザ全てを、ＳＳＯ認証サーバ３にリダイレクトし、ＳＳＯ利用ユーザの判定を行うため、ＳＳＯ認証サーバ３の負荷が増えるが、各アプリケーションサーバはＳＳＯ利用可否３０３の情報を管理する必要がなくなる。

実施例１において、ユーザがＳＳＯ申し込みをする度にアプリケーションサーバのサービスサイト管理者やユーザ管理者が、ＳＳＯ利用可否３０３にＳＳＯ利用可能を示す値（Ａｃｔｉｖｅ）を設定する必要があったが、実施例２においては、その必要がなくなるため、アプリケーションサーバのサービスサイト管理者やユーザ管理者の負担が減る利点がある。

実施例３において、実施例１と異なる点を示す。

実施例３は、リバースプロキシ型のＳＳＯ技術に実施例１の方式を適用した例である。

図１３は、実施例３のシステム構成例である。実施例１の図１と異なる点は、リバースプロキシサーバ９がインターネット１に接続しており、アプリケーションサーバ４、アプリケーションサーバ５に代わってリバースプロキシサーバ９がＳＳＯエージェントプログラム６を有していることである。従って、実施例１においてアプリケーションサーバ４のＳＳＯエージェントプログラム６が管理しているサービスサイトログインＩＤ１００１と、セッションＩＤ１００２と、セッション有効期限１００３は、リバースプロキシサーバ９のＳＳＯエージェントプログラム６が管理する。

実施例１において、アプリケーションサーバ４は個別ログイン用ＵＲＬとＳＳＯ用ＵＲＬを有していたが、実施例３においては、アプリケーションサーバ４は個別ログイン用ＵＲＬのみ有し、ＳＳＯ用ＵＲＬはリバースプロキシサーバ９が有する。

リバースプロキシサーバ９は、各アプリケーションサーバのＳＳＯ用ＵＲＬを持ち、各ＳＳＯ用ＵＲＬに対応するＳＳＯエージェントプログラム６を実行する。

実施例３の処理フローを、図４と図１４に示す。図４において、実施例１と実施例３は同一の内容である。実施例３において、リバースプロキシサーバ９が存在するが、図４の処理フローの中では処理がないため省略している。

図１４において、実施例１の図５の処理フローと異なる点を述べる。

ＳＳＯ認証サーバ３は、ステップ５０７で作成したセッションＩＤ２０５とセッション有効期限２０６をＣｏｏｋｉｅにセットし、クライアント端末２をリバースプロキシサーバ９のＳＳＯ用ＵＲＬ ６０４にリダイレクトする要求と共にクライアント端末２に送信する（１６０１）。

クライアント端末２がリバースプロキシサーバ９のＳＳＯ用ＵＲＬ６０４にリダイレクトされると、ＳＳＯエージェントプログラム６がクライアント端末２のＣｏｏｋｉｅにセットされているＳＳＯ認証サーバ３のセッションＩＤ２０５とセッション有効期限２０６を取得し、ＳＳＯ認証サーバ３にＳＳＬを利用し、セッションＩＤ２０５とセッション有効期限２０６が有効か問い合わせを行う（１６０２）。

ＳＳＯ認証サーバ３は、ＳＳＯエージェントプログラム６から受け取ったセッションＩＤ２０５とセッション有効期限２０６が有効か検証し、有効であればサービスサイトＡログインＩＤ２０３の情報を返す（５１０）。

ＳＳＯエージェントプログラム６は、ＳＳＯ認証サーバ３から受け取ったサービスサイトＡログインＩＤ２０３の情報を元に、次回以降のＳＳＯ認証済みのクライアント端末２からＳＳＯ用ＵＲＬへのアクセスを識別可能とするためのセッションＩＤ１００２と、セッション有効期限１００３を生成する（１６０３）。ステップ１６０３で生成されたセッションＩＤ１００２とセッション有効期限１００３は、クライアント端末２がＳＳＯ認証サーバ３に対してログアウトした場合、もしくは一定時間アクセスせずタイムアウトした場合、もしくはセッション有効期限１００３を越えた場合に、ＳＳＯエージェントプログラム６によって消去される。

リバースプロキシサーバ９は、クライアント端末２の代わりにアプリケーションサーバ４に対し、ＨＴＴＰ要求メッセージを送信する（１６０４）。ステップ１６０４のＨＴＴＰ要求メッセージのＨＴＴＰヘッダには、クライアント端末２のサービスサイトログインＩＤ１００１をセットする。

アプリケーションサーバ４は、リバースプロキシサーバ９からのアクセスをＩＰアドレスから判断し、ＨＴＴＰヘッダにセットされているサービスサイトログインＩＤ１００１を取得し、サービスサイトログインＩＤ１００１に対するログイン後のサービス画面などを表示する認証成功通知メッセージをリバースプロキシサーバ９に返す（１６０５）。

アプリケーションサーバ４は、リバースプロキシサーバ９からの接続に対しては、常にログインを許可し、個別ログイン認証画面を表示しない設定が必要である。

リバースプロキシサーバ９は、セッションＩＤ１００２とセッション有効期限１００３をＣｏｏｋｉｅにセットし、ステップ１６０５で受け取った認証成功通知メッセージをクライアント端末２に送信する（１６０６）。

クライアント端末２はアプリケーションサーバ４のログイン後のサービス画面を表示し（５１３）、その後ユーザはサービスを利用する。

実施例１において、クライアント端末２が、アプリケーションサーバ４からアプリケーションサーバ５へ遷移する場合、ユーザにＳＳＯ用ＵＲＬを意識させないようにするための方法を述べた。実施例１では、アプリケーションサーバ４のＳＳＯエージェントプログラム６が管理するセッションＩＤ１００２とセッション有効期限１００３を利用し、ＳＳＯ認証を受けたクライアント端末２の判定が可能であった。

実施例３では、ＳＳＯエージェントプログラム６をリバースプロキシサーバ９に設置するため、アプリケーションサーバ４はクライアント端末２がＳＳＯの認証を受けているか判定できない。

実施例３において、ＳＳＯ認証を受けたユーザの代わりに、リバースプロキシサーバ９がアプリケーションサーバ４のコンテンツを取得する。従って、アプリケーションサーバ４は、リバースプロキシサーバ９の要求が必ずＳＳＯ認証を受けているクライアント端末２の代理要求と判定可能であるため、実施例１で述べた個別ログイン用ＵＲＬ９０２とＳＳＯ用ＵＲＬ９０３のリンクを動的に変更する方法、もしくはＳＳＯ用ＵＲＬ判定ＣＧＩを利用した方法が利用可能となる。具体的な方法は以下に述べる。

アプリケーションサーバ４が表示するリンクのＵＲＬを動的に変更可能な場合、アプリケーションサーバ４は、受信したＨＴＴＰリクエストのＩＰアドレスがリバースプロキシ９のものであれば、ＳＳＯ用ＵＲＬ９０３を表示し、それ以外のＩＰアドレスからのＨＴＴＰリクエストには、個別ログイン用ＵＲＬ９０２を表示するコンテンツを返す。

アプリケーションサーバ４が表示するリンクのＵＲＬを動的に変更不可能な場合や、画面表示プログラムの実装において判定を入れることが不可能な場合は、ＳＳＯ用ＵＲＬ判定ＣＧＩスクリプトをアプリケーションサーバ４に別途設置し、アプリケーションサーバ４は、ＳＳＯ用ＵＲＬ判定ＣＧＩのＵＲＬのリクエストパラメータに、サービスサイトＩＤ９０１の値をセットしたリンクを表示するコンテンツを返す。

アプリケーションサーバ４のＳＳＯ用ＵＲＬ判定ＣＧＩスクリプトは、リクエストパラメータに含まれるサービスサイトＩＤ９０１を取得し、受信したＨＴＴＰリクエストのＩＰアドレスがリバースプロキシ９のものであれば、ＳＳＯ用ＵＲＬ９０３にリダイレクトするメッセージを返し、それ以外のＩＰアドレスからのＨＴＴＰリクエストには、個別ログイン用ＵＲＬ９０２にリダイレクトするメッセージを返す。

実施例４は、リバースプロキシ型のＳＳＯ技術に実施例２の方式を適用した例である。実施例４において、実施例３と異なる点を示す。

実施例４の処理フローを図１２と図１４に示す。図１２において、実施例４と実施例２は同一の内容である。実施例４において、リバースプロキシサーバ９が存在するが、図１２の処理フローの中では処理がないため省略している。

図１４において、実施例４と実施例３は同一の内容である。

実施例４は、実施例３と比較して、アプリケーションサーバ４が管理するＳＳＯ利用可否３０３の情報を持たないことを特徴とする。アプリケーションサーバ４は、図１１に示すサービスサイトＡログインＩＤ３０１と、パスワード３０２と、セッション情報３０４と、セッション有効期限３０５を管理する。

実施例４の図１２において、実施例３の図４と異なる点は、ステップ４０８、４０９、４１０の機能を持たないことである。

図１２のステップ４０７において、アプリケーションサーバ４の認証を受けた全てのクライアント端末２は、ステップ４１１においてＳＳＯ認証サーバ３にリダイレクトされる。ステップ５０１において、ＳＳＯ認証サーバ３は、アプリケーションサーバ４で認証されたサービスサイトＡログインＩＤ３０１と、ＳＳＯ認証サーバ３が管理するサービスサイトＡログインＩＤ２０３と照合し、照合に成功したクライアント端末２のみ、ＳＳＯ認証成功とする。図５のステップ５０１において、照合に成功しなかったクライアント端末２は、ＳＳＯ認証サーバ３からＳＳＯ認証されず、アプリケーションサーバ４の個別ログイン用ＵＲＬ９０２にリダイレクトされ、アプリケーションサーバ４へ個別ログインする。

実施例４においては、各アプリケーションサーバに個別ログインしたユーザ全てを、ＳＳＯ認証サーバ３にリダイレクトし、ＳＳＯ利用ユーザの判定を行うため、ＳＳＯ認証サーバ３の負荷が増えるが、各アプリケーションサーバはＳＳＯ利用可否３０３の情報を管理する必要がなくなる。

実施例３において、ユーザがＳＳＯ申し込みをする度にアプリケーションサーバのサービスサイト管理者やユーザ管理者が、ＳＳＯ利用可否３０３にＳＳＯ利用可能を示す値（Ａｃｔｉｖｅ）を設定する必要があったが、実施例４においては、その必要がなくなるため、アプリケーションサーバのサービスサイト管理者やユーザ管理者の負担が減る利点がある。

既存サービスサイトにＳＳＯ技術を適用する場合、ＳＳＯを利用するユーザと利用しないユーザが混在する環境になる可能性がある。従来のＳＳＯ技術では、ＳＳＯ利用ユーザにログイン先のＵＲＬやログインＩＤを変更させるため、ユーザに負担がかかる問題があり、それを解決するために本発明の利用が可能である。

本発明の実施例１、本発明の実施例２に係るＳＳＯのネットワーク構成とシステム構成例である。 本発明の実施例１、本発明の実施例２、本発明の実施例３、本発明の実施例４に係るＳＳＯ認証サーバが管理するＳＳＯログインＩＤと各サービスサイトのログインＩＤとの紐付けと、セッション管理テーブルの一例を示す図である。 本発明の実施例１、本発明の実施例３に係るサービスサイトのアプリケーションサーバが管理するログインＩＤ、ＳＳＯ利用可否とセッション情報の管理テーブルの一例を示す図である。 本発明の実施例１、本発明の実施例３に係るＳＳＯの認証を行う処理フローの図である。 本発明の実施例１の図４の続きの処理フロー図、もしくは本発明の実施例２の図１２の続きの処理フロー図である。 本発明の実施例１、本発明の実施例２、本発明の実施例３、本発明の実施例４に係るＳＳＯ認証サーバが管理する各サービスサイトの情報を管理するテーブルの一例を示す図である。 本発明の実施例１、本発明の実施例２、本発明の実施例３、本発明の実施例４に係るＳＳＯ認証サーバで管理するリプレイ攻撃を防止するための管理テーブルの一例を示す図である。 本発明の実施例１、本発明の実施例２、本発明の実施例３、本発明の実施例４に係る各サービスサイトのアプリケーションサーバが管理するリプレイ攻撃を防止するための管理テーブルの一例を示す図である。 本発明の実施例１、本発明の実施例２、本発明の実施例３、本発明の実施例４に係る各サービスサイトのアプリケーションサーバが管理する他サービスサイトのリンク先ＵＲＬ管理テーブルの一例を示す図である。 本発明の実施例１、本発明の実施例２、本発明の実施例３、本発明の実施例４に係るＳＳＯエージェントプログラムが管理するセッション情報管理テーブルの一例を示す図である。 本発明の実施例２、本発明の実施例４に係るサービスサイトのアプリケーションサーバが管理するログインＩＤとセッション情報の管理テーブルの一例を示す図である。 本発明の実施例２、本発明の実施例４に係るＳＳＯの認証を行う処理フローの図である。 本発明の実施例３、本発明の実施例４に係るＳＳＯのネットワーク構成とシステム構成例である。 本発明の実施例３の図４の続きの処理フロー図、もしくは本発明の実施例４の図１２の続きの処理フロー図である。

符号の説明

１ インターネット
２ クライアント端末
３ ＳＳＯ認証サーバ
４ サービスサイトＡのアプリケーションサーバ
５ サービスサイトＢのアプリケーションサーバ
６ ＳＳＯエージェントプログラム
７ ＳＳＯ認証サーバ管理テーブル
８ アプリケーションサーバ管理テーブル

Claims (10)

1. クライアント端末と、シングルサインオンの認証を行うＳＳＯ認証サーバと、シングルサインオンの提携関係にある複数のアプリケーションサーバがネットワークを介して接続された環境で、前記アプリケーションサーバが前記ＳＳＯ認証サーバとＳＳＯのセッションＩＤの確認を行うシングルサインオン連携方法において、
   前記アプリケーションサーバは、管理するログインＩＤとパスワードでユーザが前記アプリケーションサーバに行った個別ログインに対し、当該ログインＩＤと前記アプリケーションサーバで個別ログインを行った証明情報を前記ＳＳＯ認証サーバに送信し、前記ＳＳＯ認証サーバは、前記アプリケーションサーバの当該ログインＩＤに、ＳＳＯ認証サーバが管理するＳＳＯログインＩＤが紐付いているか判定して、シングルサインオン認証を行うことを特徴とするシングルサインオン連携方法。
2. 請求項１に記載のシングルサインオン連携方法において、
   前記アプリケーションサーバは、前記アプリケーションサーバに備えられた前記ログインＩＤのシングルサインオン利用可否の情報を用いて、前記ログインＩＤがシングルサインオン利用可能か判定し、前記ログインＩＤがシングルサインオン利用可能であれば、当該ログインＩＤと前記アプリケーションサーバで個別ログインを行った証明情報を前記ＳＳＯ認証サーバに送信し、
   前記ＳＳＯ認証サーバは、前記ＳＳＯログインＩＤが存在した場合に、シングルサインオン認証を行うことを特徴とするシングルサインオン連携方法。
3. 請求項１に記載のシングルサインオン連携方法において、
   前記ＳＳＯ認証サーバは、前記ＳＳＯログインＩＤが存在した場合に、シングルサインオン認証を実行し、前記ＳＳＯログインＩＤが存在しなかった場合にはシングルサインオン認証を実行しないことを特徴とするシングルサインオン連携方法。
4. 請求項１ないし請求項３のいずれかに記載のシングルサインオン連携システムにおいて、
   前記クライアント端末の代理で前記アプリケーションサーバからコンテンツを取得するリバースプロキシサーバが前記ネットワークを介して接続されており、前記リバースプロキシサーバは、前記ＳＳＯ認証サーバとＳＳＯのセッションＩＤの確認を行うＳＳＯエージェントプログラムにより前記ＳＳＯ認証サーバとＳＳＯのセッションＩＤの確認を行うことを特徴とするシングルサインオン連携方法。
5. クライアント端末と、シングルサインオンの認証を行うＳＳＯ認証サーバと、シングルサインオンの提携関係にある複数のアプリケーションサーバがネットワークを介して接続されており、前記アプリケーションサーバは、前記ＳＳＯ認証サーバとＳＳＯのセッションＩＤの確認を行うＳＳＯエージェントプログラムを有する環境におけるシングルサインオン連携方法において、
   前記アプリケーションサーバが、ログインＩＤとパスワードでユーザが前記アプリケーションサーバに行った個別ログインに対し、前記アプリケーションサーバに備えられた前記ログインＩＤのシングルサインオン利用可否の情報を用いて、前記ログインＩＤがシングルサインオン利用可能か判定するステップと、前記アプリケーションサーバが、前記ログインＩＤがシングルサインオン利用可能であれば、当該ログインＩＤと前記アプリケーションサーバで個別ログインを行った証明情報を前記ＳＳＯ認証サーバに送信するステップと、前記ＳＳＯ認証サーバが、前記アプリケーションサーバの当該ログインＩＤに、ＳＳＯ認証サーバが管理するＳＳＯログインＩＤが紐付いているか判定するステップと、前記ＳＳＯログインＩＤが存在した場合にシングルサインオン認証を行うステップと、を備えていることを特徴とするシングルサインオン連携方法。
6. クライアント端末と、シングルサインオンの認証を行うＳＳＯ認証サーバと、シングルサインオンの提携関係にある複数のアプリケーションサーバとがネットワークを介して接続されたシングルサインオン連携システムにおいて、
   前記アプリケーションサーバは、前記ＳＳＯ認証サーバとＳＳＯのセッションＩＤの確認を行うＳＳＯエージェントプログラムと、ログインＩＤとパスワードを管理する個別ログインＩＤ情報と、前記アプリケーションサーバは、前記管理するログインＩＤとパスワードでユーザが前記アプリケーションサーバに行った個別ログインに対し、当該ログインＩＤと前記アプリケーションサーバで個別ログインを行った証明情報を前記ＳＳＯ認証サーバに送信する送信部とを備えており、前記ＳＳＯ認証サーバは、前記アプリケーションサーバの当該ログインＩＤに、ＳＳＯ認証サーバが管理するＳＳＯログインＩＤが紐付いているか判定する判定部と、前記判定部の判定にもとづいてシングルサインオン認証を行う認証部とを備えていることを特徴とするシングルサインオン連携システム。
7. 請求項６に記載のシングルサインオン連携システムにおいて、
   前記アプリケーションサーバは、前記ログインＩＤのシングルサインオン利用可否の情報と、前記ログインＩＤがシングルサインオン利用可能か判定する判定部と、前記ログインＩＤがシングルサインオン利用可能であれば、前記送信部は、当該ログインＩＤと前記アプリケーションサーバで個別ログインを行った証明情報を前記ＳＳＯ認証サーバに送信する送信部とを備えており、
   前記ＳＳＯ認証サーバの前記認証部は、前記ＳＳＯログインＩＤが存在した場合に、シングルサインオン認証を行う認証部を備えていることを特徴とするシングルサインオン連携システム。
8. 請求項６に記載のシングルサインオン連携システムにおいて、
   前記ＳＳＯ認証サーバの認証部は、前記ＳＳＯログインＩＤが存在した場合に、シングルサインオン認証を実行し、前記ＳＳＯログインＩＤが存在しなかった場合にはシングルサインオン認証を実行しないことを特徴とするシングルサインオン連携システム。
9. 請求項６ないし請求項８のいずれかに記載のシングルサインオン連携システムにおいて、
   前記クライアント端末の代理で前記アプリケーションサーバからコンテンツを取得するリバースプロキシサーバが前記ネットワークを介して接続されており、前記リバースプロキシサーバは、前記ＳＳＯ認証サーバとＳＳＯのセッションＩＤの確認を行うＳＳＯエージェントプログラムを有することを特徴とするシングルサインオン連携システム。
10. クライアント端末と、シングルサインオンＳＳＯの認証を行うＳＳＯ認証サーバと、シングルサインオンの提携関係にある複数のアプリケーションサーバがネットワークを介して接続されており、前記アプリケーションサーバは、前記ＳＳＯ認証サーバとＳＳＯのセッションＩＤの確認を行うＳＳＯエージェントプログラムを有するシングルサインオン連携方システムにおいて、
    前記アプリケーションサーバは、前記ログインＩＤのシングルサインオン利用可否の情報である個別ログインＩＤ情報と、管理するログインＩＤとパスワードでユーザが前記アプリケーションサーバに行った個別ログインに対し、前記アプリケーションサーバに備えられた前記個別ログインＩＤ情報を用いて、前記ログインＩＤがシングルサインオン利用可能か判定する判定部と、前記ログインＩＤがシングルサインオン利用可能であれば、当該ログインＩＤと前記アプリケーションサーバで個別ログインを行った証明情報を前記ＳＳＯ認証サーバに送信する送信部とを備えており、
    前記ＳＳＯ認証サーバは、前記ログインＩＤとＳＳＯ認証サーバが管理するＳＳＯログインＩＤとを管理するＳＳＯ−ＩＤ紐付け情報と、前記アプリケーションサーバの当該ログインＩＤに、ＳＳＯ認証サーバが管理するＳＳＯログインＩＤが紐付いているか判定する判定部と、前記ＳＳＯログインＩＤが存在した場合にシングルサインオン認証を行う認証部とを備えていることを特徴とするシングルサインオン連携システム。

Images