JP2006331044A

JP2006331044A - シングルサインオン実現方法

Info

Publication number: JP2006331044A
Application number: JP2005153261A
Authority: JP
Inventors: Katsuro Kikuchi; 克朗菊地
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2005-05-26
Filing date: 2005-05-26
Publication date: 2006-12-07
Anticipated expiration: 2025-05-26
Also published as: US20060271689A1; JP4779444B2; US8006294B2

Abstract

【課題】シングルサインオンを実現するためには、対象となるWebアプリケーションのログイン、セッショントラッキング方式を解析する必要がある。システムエンジニアに対してHTTP、HTMLなどの下位レイヤの技術を要求することになり、シングルサイノンの技術的ハードル、実現コストが高くなっている。
【解決手段】ナレッジとして格納したシングルサインオンを実現するシングルサインオンモジュール105、業務システムのログイン通信を解析し適用可能なシングルサインオンモジュールを選択、実行するシングルサインオンサーバ102によりHTTP、HTMLなどの下位レイヤの知識を必要せずにシングルサインオンを実現する。
【効果】システムエンジニアにHTTP、HTMLなどの下位レイアの知識を要求することなくシングルサインオンを実現できるので、短期間、低コストでのシングルサインオンが実現できる。
【選択図】図１

Description

本発明は、Webアプリケーションに自動的にログインするためのシステム構成および処理方式に関する。

企業内の情報システムは、従来のクライアントサーバ型システムからWeb(World Wide Web)技術を基盤とした3階層システムに移行しつつある。これまでに様々な業務がWebアプリケーション化され、業務効率の向上が図られてきているが、その一方で、企業内に多数の情報システムが業務ごとに存在する結果となり、ユーザは日常業務遂行のためこれらのシステムを巡回し、それぞれのシステムにログインするなど煩雑な操作を強いられている。この問題を解決するためにシングルサインオン技術が注目されている。シングルサインオンとは、認証を必要とする複数のシステムを利用する際に、一度だけログイン操作を行い認証を受けるのみで、全てのシステムを利用できるようにするログイン方式である。

企業情報システムすなわちWebアプリケーションへのシングルサインオンを実現するには、Webアプリケーションのユーザ認証方式やセッション管理方式に対応した処理が必要となる。一方、Webアプリケーションを実現するためのHTTPやHTMLは、元々ドキュメントの公開・閲覧システムを目的として開発されたため、Webアプリケーション実行基盤としては力不足であるといえる。たとえば、通信プロトコルであるHTTPは、ステートレスな通信プロトコルのためセッションの概念を持たず、また、ユーザ認証の仕組みも提供していない。そのため、ユーザ認証機能やセッション管理機能といったWebアプリケーションの基盤機能は、アプリケーション毎に独自に作りこむ必要がある。近年、Sun Microsystems社のJ2EE(Java 2 Platform, Enterprise Edition)（JavaはSun Microsystems社の登録商標）、Microsoft社の.NET FrameworkなどWebアプリケーションを開発、実行するためのフレームワークが整備され、ユーザ認証方式やセッション管理方式がある程度集約されてきているが、一本化されるには至っていない。このため、Webアプリケーションにおいてシングルサインオンを実現するには、独自に作り込まれたWebアプリケーションのユーザ認証機能やセッション管理機能に対応するシングルサインオン方式を作りこむ必要ある。

シングルサインオン実現方式としては、Webアプリケーションのユーザ認証機能やセッション管理機能に対応して、「特許文献１」、「特許文献２」、「特許文献３」、「特許文献４」、「特許文献５」、「特許文献６」など様々な方法が提案されている。
また、シングルサインオンを実現するための製品としてNetegrity社のSiteMinder(登録商標)などがある。

特願2004-138834号公報

特開2003-141081号公報特開2003-58503号公報特開2002-32340号公報特開2002-41380号公報特開2002-334056号公報

企業内に多数の情報システムが業務ごとに存在し、ユーザは日常業務遂行のためこれらのシステムを巡回し、それぞれのシステムにログインするなど煩雑な操作を強いられている。この問題を解決するためにシングルサインオン技術が注目されている。

シングルサインオンを実現するための製品もいくつか知られている。しかし、これらの製品を適用するには基本的にバックエンドシステムを改変することが必要であり、シングルサインオン実現のための構築期間や構築コストが大きくなる傾向がある。ITシステムの構築には、構築期間の短縮と費用対効果が求められており、これらの製品では、本要求の達成が難しい場合がある。

また、既存の情報システムの認証方式やセッション維持方式を解析してシングルサインオンを実現することも可能である。しかしながら、これを行うシステムエンジニアには、業務ロジックに関する知識、上位レイヤのIT技術以外に、Webアプリケーションの基盤技術であるHTTP、HTMLなどの下位レイヤの深い知識が要求される。このことから、シングルサイオン実装方式はシステムエンジニアのノウハウ(暗黙知)の固まりとなっており、シングルサインオン実現には技術的ハードルやコストが高いものとなっている。また、通信をSSL(Secure Socket Layer)などで暗号化している場合には、解析が事実上困難といえる。

本発明の特定の認証方式やセッション維持方式に対応したシングルサインオンモジュールを予め作成し、本シングルサインオンモジュールが適用可能な通信パターンと共にシングルサインオンサーバに登録する。情報システムログインの通信ログを取得し、上記通信パターンと照らし合わせ、適用可能なシングルサインオンモジュールを選択する。選択されたシングルサインオンモジュールを用いてシングルサインオンを行う。これにより、システムエンジニアが情報システムの認証方式やセッション維持方式を解析することなくシングルサインオンを実現可能とする。

本発明によればWebアプリケーションの基盤技術であるHTTP、HTMLなどの下位レイヤの深い知識を必要とすることなくシングルサインオンを実現できる。これにより低コストでのシングルサインオン環境が実現できる。

シングルサインオン実現のための一実施例について説明する。
図１はシングルサインオンを実現するためのシステム構成の一例である。SSOサーバ102はクライアント100に対してシングルサインオンサービスを提供する。クライアント100とSSOサーバ102は任意のネットワークシステム101を介して接続される。SSOサーバ102はSSOサーバのシングルサインオンサービスの提供を受けるユーザを管理するSSOサーバユーザ管理テーブル103、SSOサーバのユーザとシングルサインオン対象となるバックエンドシステムのユーザ情報を対応付けるための業務システムユーザ情報マッピングテーブル104、シングルサインオンを実現するシングルサインオンモジュール郡を格納するSSOモジュール管理テーブル105を管理下に保有する。また、業務システム１(106)および業務システム2(107)は本実施例におけるシングルサインオン対象の情報システムである。本実施例ではバックエンドシステムは2つであるが、１つ以上の任意の数のバックエンドシステムへのシングルサインオンサービスを提供可能である。

シングルサインオンサービスを受ける場合、ユーザは、まずはじめにクライアント100からSSOサーバ102にログインする。SSOサーバ102はユーザの認証を行い、認証が成功すると図２に示すようなシングルサインオンサービス画面をクライアント100に返却する。基本的な画面構成としては、シングルサインオン対象のリンク（200,201）が列挙されたものとなる。リンクは202のようにシングルサインオン対象が分かるようクエリなどが埋め込まれている。

SSOサーバユーザ管理テーブル103、業務システムユーザ情報マッピングテーブル104、SSOモジュール管理テーブル105のテーブル構成はそれぞれ図３、図４、図５を示す通りである。SSOサーバユーザ管理テーブル103にはSSOサーバ102が提供するシングルサインオンサービスの提供を受けるユーザの認証を行うための情報としてユーザID300とパスワード301とが格納されている。本実施例では、シングルサインオンサービスのユーザの認証方法として一般的に用いられる、ユーザID、パスワードを用いた方法をとっているが、他の認証方法を採用してもよい。例えば、ICカードによるクライアント認証なども採用可能であり、SSOサーバユーザ管理テーブル103に予め保存する情報の種類は採用する認証方法による。業務システムユーザ情報マッピングテーブル104は、SOOサーバ102のユーザと、個々のバックエンドシステムのユーザを紐付けするためのテーブルである。たとえば、SSOサーバ102のユーザIDが"u0000001"のユーザ(302)は、業務システム１のユーザ"bk1u0001"（303）、および業務システム２のユーザ"bk2u0001"(305)に対応している。また、本テーブルはバックエンドシステムへのログインに必要な情報も合わせて格納している。本実施例では業務システム１、業務システム２共にユーザID、パスワードで認証しており、パスワードがそれぞれ格納されている（304、306）。本実施例ではユーザID、パスワードで認証する例をあげているが、企業コードやX.509証明書など任意の情報を格納可能である。本マッピング情報は、システム管理者が一括で設定したり、図６に示すようなインターフェイスをSSOサーバ100にもたせ、ユーザごとに設定させたりすることが可能である。

次いで、SSOモジュール管理テーブル105について説明する。SSOモジュール管理テーブル105には実際にSSOを実現するためのプログラムモジュールが格納されている。なお、SSOモジュールの実装方法は「特許文献１」に詳しく記述されている。

ここでは、シングルサインオンモジュールの一例を図８、図９を用いて説明する。本シングルサインオンモジュールは、バックエンドシステムのセッショントラッキング方式がクッキー方式、URL書き換え方式の何れにでも適用できるシングルサインオンモジュールである。図８はクライアント100、SSOサーバ102、バックエンドシステム106間の処理の流れを、図９は自動ログインで流れる情報を示す。クライアント100のシングルサインオン要求を受け取ったSSOサーバ102は、WebアプリSSO対応テーブル504から、バックエンドシステムに対応するSSOモジュールを検索し、検索されたSSOモジュール600を呼びだす(602)。なお、登録、呼び出し方法については後述する。呼び出されたSSOモジュールは、ステップ603で業務システム１(106)のユーザID、パスワードを業務システムユーザ情報マッピングテーブル104から取得した後、図９の700に示す応答HTMLをクライアント100に返却する(604)。図９のHTML(700)は業務システム１(106)のログイン用フォームにユーザIDとパスワードを予め埋め込んだHTMLに、更に「inputをhidden属性とする」、「HTML読み込み時にフォームをサブミットする」の二つの変更を行ったものである。ログイン用フォームを受け取ったクライアント100は、onloadイベントのイベントハンドラスクリプトによりHTML読み込み完了と同時にフォームのサブミットを行う(605)。図９の701にサブミットされるリクエストを示す。本リクエストは、ユーザがログイン画面にユーザID、パスワードを入力後にサブミットしたリクエストと同様となる。従って、業務システム１（106）へログインを行うことができる。これにより自動ログインを実現できる。上記が実際にSSOモジュールでシングルサインを行う一例である。

さて、図３のSSOモジュール管理テーブル105は、上記で一例として説明したSSOモジュールに加えてSSOモジュールが適用可能な通信パターンを記述したファイルのパス308およびSSOモジュールを識別するためのインデックス307からなる。図１０に通信パターン例を示す。本例では通信パターンを定義するためにXML形式ファイルを用いるが、下記通信パターンが記述できれば任意の記述方法を用いてよい。ここでは、ベーシック認証(800)およびCookieでセッショントラッキングを行うForm認証例(803)を示す。通信パターン記述はログイン画面表示のリクエスト、レスポンス(801、804)および認証情報送付時のリクエスト、レスポンス(802、805)からなり、それぞれmessage要素にて記述している。message要素は、リクエストのパターンを示すrequest要素およびレスポンスのパターンを示すresponse要素からなる。request要素は、HTTPのリクエスト形式に対応して、scheme要素、method要素、header要素からなる。scheme要素は、通信タイプとして「http」もしくは「https」を指定する。method要素では主に認証情報送付方式として「GET」もしくは「POST」を指定する。header要素ではリクエストヘッダのヘッダ名、値に対応して、name属性、value属性をそれぞれ指定する。一方、response要素は、HTTPのレスポンス形式に対応している。基本的にheader要素で必要なヘッダー情報を定義する。なお、expression要素は特別な要素で、子要素の論理和を指定するために使用する。805の例では、「Set-Cookie」もしくは「Set-Cookie2」ヘッダの両方もしくは何れかが存在することを示している。なお、パターンに記述された情報は必須の情報をあらわしている。

図１０の2例について説明すると、ベーシック認証800は、ログイン画面表示の際のレスポンスヘッダ(801)に「WWW-Authenticate」、ログイン情報送付の際のリクエストヘッダに「WWW-Authorization」がそれぞれ現れることを示している。また、ログイン情報送付は「http」によって行っている。後述する通信ログと本通信パターンのマッチングが取れた場合、本通信パターンに対応するシングルサインオンモジュールにしてシングルサインオンを実現することが出来る。
Cookieでセッショントラッキングを行うForm認証803は、ログイン画面表示の際のリクエスト、レスポンスは特に規定せず、ログイン情報送付の際のリクエストが、schemaが「http」、methodが「POST」、リクエストヘッダに「Content-Type : application/x-www-form-urlencoded」および「Content-Length」の指定が現れることを示している。ベーシック認証800と同様に、後述する通信ログと本通信パターンのマッチングが取れた場合、本通信パターンに対応するシングルサインオンモジュールにしてシングルサインオンを実現することが出来る。

次いで、図７を用いてSSOサーバ102の構成について説明する。SSOサーバ102は、HTTP/HTTPSプロキシ部500、通信ログ取得部501、SSOモジュール選択部502およびSSO実行部503、そしてWebアプリSSO対応テーブル504からなる。
HTTP/HTTPSプロキシ部500および通信ログ取得部501は、HTTP/HTTPSが一般的なプロキシサーバのような動作を行いバックエンドシステムへのログイン操作の通信ログを取得する。なお、HTTPSの場合、クライアント100とSSOサーバ102間をHTTP通信、SSOサーバ102とバックエンドシステム間をHTTPS通信とすることで、HTTPレベルの通信ログを取得する。WebアプリSSO対応テーブル504は、Webアプリを識別するためのIDとSSOモジュールIDの組み合わせからなる。

図１１にSSOサーバ102の動作例を示す。
シングルサインオンサービスは2つのステップからなる。第１のステップは初期設定でありバックエンドシステムのログイン方式の解析およびSSOモジュールの選択、第２のステップはシングルサインオンサービスの提供をうけるステップであり、第１のステップで選択されたSSOモジュールを用いてシングルサインオンサービスの提供を受ける。

初めに第１のステップである初期設定について説明する。バックエンドシステムのログイン方式を解析するために、SSOサーバ102は、バックエンドシステムのログインページのURLをクライアント100から指定してもらう(900)。SSOサーバ102は、ログインページのURLの入力を受け付けると、ログインページ取得処理901として、指定されたURLへHTTP GETリクエストを出す(902)。ログインページ要求902を受け取った業務システム１(106)は、ログインページを生成(903)し、SSOサーバ102にログインページを応答する（904）。

SSOサーバ102は、ログインページを受け取り、通信ログとしてログインページ要求902およびログインページ応答904を記録する(905)。ログインページリクエスト902に対応する通信ログは図１２の1000となる。リクエストの通信ログは、リクエストURL、リクエストメソッド、リクエストヘッダおよびリクエストボディとなる。業務システム１(106)からのレスポンス904に対応する通信ログは図１２の1001となる。レスポンスの通信ログは、レスポンスコード、レスポンスヘッダ、レスポンスボディからなる。

通信ログ記録後、SSOサーバ102は、業務システム１(106)の応答したログインページ(904)のログインFormのactionで指定されているURLをSSOサーバ102を経由するよう書き換える。ついで、書き換え結果のログイン画面をクライアント100に返却する(907)。なお、Basic認証の場合は、本書き換え処理は行わない。ログイン画面を受け取ったクライアント100は、ユーザからの認証情報の入力を受け付ける(908)。認証情報としては、たとえばユーザID、パスワードなどがある。認証情報入力し、ログイン要求を行うと、URLが変更されているので要求はSSOサーバ102に送信される(909)。ログイン要求を受け取ったSSOサーバ102は、ログインページ要求と同様に、ログイン要求の通信を記録する(910)。通信ログ例を図１２の1002に示す。ログインリクエストの通信ログと同様に、リクエストURL、リクエストメソッド、リクエストヘッダ、リクエストボディをそれぞれ記録する。通信ログ記録後、そのままバックエンドシステムにログイン要求を転送する(911)。ログイン要求を受け取ったバックエンドシステムは、認証を行い(912)、認証後ページを返却する(913)。認証後ページを受け取ったSSOサーバ102は、これまでのステップと同様に通信を記録(914)し、クライアント100に認証後ページを転送する(915)。

ついで、図１３を用いてバックエンドシステムに適用可能なSSOモジュール候補を選択する処理について説明する。まず初めに、SSOモジュール管理テーブル105の適用可能通信パターン308を取り出し、それぞれについてマッチング処理を行う。具体的には、図１０で示した適用可能通信パターンに現れるヘッダなどが、図１２で示した通信ログ中に現れているか否かを確認する(1101)。通信ログが通信パターンにマッチした場合、適用可能SSOモジュール候補としてSSOモジュールIDを記録しておく(1102)。本処理を全てのSSOモジュールについて実施する(1103)。本処理を実施すると適用可能性のあるSSOモジュールを選択できる。

ついで、実際にSSOモジュールが適用可能か検査を行う。具体的な処理の流れを図１４に示す。図１３で適用可能と記録(1102)されたSSOモジュールについて、以下の処理を行う(1200)。実際にSSOモジュールを用いてシングルサインオンを実行し、シングルサインオン後画面をクライアントに提示し、ログイン成否の回答を受け付ける(1201)。ログインが失敗した場合(1207)、次の候補について同様の処理を行う。ログインが成功した場合(1205)、Webアプリ対応テーブル504に、SSOモジュールIDを記録する。また、全てのSSOモジュールについてログインが失敗した場合や、そもそも適用候補がない場合には、たとえば、「適用可能SSOモジュールはありません」とワーニングメッセージをクライアント100に出力する。この場合、本ログイン方式に対応したSSOモジュールを開発する必要がある。なお、本検査に先立って、SSOモジュールの設定として、SSOモジュールが業務システムに認証情報として送付するユーザID、パスワードのフィールド名を設定しておく。
上記により、バックエンドに対応したSSOモジュールが選択できた。実際にシングルサインオンを実施する場合は、図８、図９の説明の通り行う。

次いで、第２の実施例について説明する。「特許文献１」で記載されているように、バックエンドシステムのログイン方式に着目した場合、適用可能なシングルサインオン方式は必ずしも一つではない。また、シングルサインオンは、実装方式により、セキュリティレベルの差異や必要とする計算機リソース量に差が出る。実施例１では、図１４の処理の流れのように、そのことを考慮せず、もっとも早く適用可能と判定されたSSOモジュールを選択したいた。そこで、SSOモジュール判定にSSOモジュールの属性を加味させるべく、SSOモジュール管理テーブル105にSSOモジュールの属性を加える。ここでは、SSOモジュールのセキュリティ強度を追加した例を示す。上記テーブル項目の追加に加え、図１４の処理フロー中のSSOモジュールID記録処理1204後の遷移を処理終了にするのではなく、1203の前段にすることで、適用可能なSSOモジュールが複数となる場合が発生する。複数のSSOモジュールが適用可能となった場合、図１５に示すSSOモジュールの属性に基づいて選択を行うものとする。

更に、第３の実施例について説明する。
上記２実施例では、適用可能なSSOモジュールについて、実際に適用可能かはクライアントの判断、すなわちユーザの判断に委ねられていた。そこで、成否判定を更に自動化するために、図１４のステップ1201の判定を、図１１のログ取得フェーズの認証後ページのログ(914)とSSOモジュールの実行結果を用いて行うものとする。これにより、ユーザに頼らずに全自動でSSOモジュールの選択が可能となる。

更に、第４の実施例について説明する。本実施例も、成否判定の自動化を行うためものである。
図１１における通信ログ取得フェーズのログインページURL入力の際(900)に、ログインに成功した場合に現れるキーワードも合わせて入力する。次いで、SSOモジュールのログイン成否判定を行う図１４のステップ1201の判定を、SSOモジュールの実行結果の画面に対して本キーワードが含まれているか否かに代用する。これにより、ユーザに頼らずに全自動でSSOモジュールの選択が可能となる。上記では、ログインに成功した場合に現れるキーワードでログイン成功を判定しているが、その逆に、ログインに失敗した場合に現れるキーワードを入力してもらい、失敗判定を行うことも可能である。
以上が実施例の説明である。

シングルサインオンを実現するための一実施例の全体構成図である。実施例のシングルサインオンサーバのシングルサインオンサービス画面の一例である。実施例のSSOサーバユーザ管理テーブルのデータ構成図である。実施例の業務システムユーザ情報マッピングテーブルのデータ構成図である。実施例のS SOモジュール管理テーブルのデータ構成図である。バックエンドシステムのユーザID、パスワード設定画面の一例である。シングルサインオンサーバのシステム構成図である。シングルサインオンモジュールの一実行例である。シングルサインオンモジュールの一実行例で用いるHTMLおよび通信例である。 Basic認証およびForm認証(セッショントラッキングにCookieを利用)の通信パターンを定義した通信パターン定義例である。 HTTP/HTTPSプロキシ部の動作例および通信ログ取得例である。取得した通信ログのデータ例である。通信ログと通信パターン定義から適用可能性のあるシングルサインモジュールを選択するための処理シーケンス例である。適用可能性のあるシングルサインオンモジュールを実際に実行し、適用するシングルサインオンモジュールを選択するための処理シーケンス例である。 SSOモジュール管理テーブルを拡張した一例である。

符号の説明

１００：クライアント、１０１：ネットワーク、１０２：シングルサインオンサーバ、１０３：SSOサーバユーザ管理テーブル、１０４：業務システムユーザ情報マッピングテーブル、１０５：SSOモジュール管理テーブル、１０６、１０７：バックエンドサーバ。

Claims

それぞれがWebアプリケーションを提供する複数のWebアプリケーションサーバと前記Webアプリケーションを操作するWebクライアントと、前記WebアプリケーションとWebクライアントの間に介在し、シングルサインオン機能を提供するシングルサインオンサーバからなる分散システムにおけるシングルサインオン実現方法であって、
前記シングルサインオンサーバは、認証、セッション維持方式種別ごとのシングルサインオンモジュール、および該シングルサインオンモジュールのそれぞれについて該シングルサインオンモジュールが適用可能な通信プロトコルを定義した通信パターン定義、シングルサインオン対象となるWebアプリケーションに対応可能なシングルサインオンモジュールを関連付けるWebアプリSSO対応テーブル、シングルサインオンサーバのユーザIDに対応するWebアプリケーションごとのユーザID、パスワードを格納するユーザ情報マッピングテーブルを具備し、
(1) 前記シングルサインオンサーバがWebアプリケーションサーバに対するログイン操作の通信ログを取得するステップと、
(2) 前記シングルサインオンサーバが、ステップ(1)で取得した通信ログとシングルサインオンサブプログラムが適用可能な通信プロトコルを定義した通信パターン定義のマッチングを取り、適用可能と考えられるシングルサインオンサブプログラムを選択するステップと、
(3) 前記シングルサインオンサーバが、ステップ(2)で選択したシングルサインオンサブプログラムにより実際にシングルサインオンをを試みるステップと、
(4) 前記シングルサインオンサーバが、ステップ(3)の実行結果をクライアントに提示し、シングルサインオンの成否判定を受け取るステップと、
(5) 前記シングルサインオンサーバが、ステップ(4)で取得したシングルサインオン成功と判定されたシングルサインオンサブプログラムをWebアプリSSO対応テーブルに設定するステップと、
(6) 前記シングルサインオンサーバが、クライアントからのシングルサインオンの要求を受け付けるステップと、
(7) 前記シングルサインオンサーバが、WebアプリSSO対応テーブルから適用可能なシングルサインオン方式を取得し、シングルサインオンサブプログラムにシングルサインオンの実行を依頼するステップと、
(8) 前記シングルサインオンモジュールが、ユーザ情報マッピングテーブルから必要なユーザID、パスワードを取得し、シングルサインオンを実行するステップとを含むことを特徴とするシングルサインオン実現方法。
請求項１記載のシングルサインオン実現方法において、前記シングルサインオンモジュールにセキュリティ強度や使用する計算機リソース量の属性情報を予め登録するステップを更に有し、前記ステップ(4)のシングルサインオン成否判定では、複数のシングルサインオンモジュールが選択された場合、管理者が予め定義しておいたセキュリティ強度と使用可能な計算機リソース量を定義したポリシー情報に基づいてシングルサインオンモジュールを選択することを特徴とするシングルサインオン実現方法。
前記ステップ(4)のシングルサインオン成否判定を、前記ステップ(1)の通信ログ取得フェーズで取得したログイン後画面とのマッチングにより代用することを特徴とする請求項１記載のシングルサインオン実現方法。
前記ステップ(4)のシングルサインオン成功判定を、HTML中の特定のキーワードにより行うことを特徴とする請求項１記載のシングルサインオン実現方法。
前記ステップ(4)のシングルサインオン失敗判定を、HTML中の特定のキーワードにより行うことを特徴とする請求項１記載のシングルサインオン実現方法。