(57)【要約】【課題】複数のＷｅｂサービスを連携させた連携サービスを低コストで実現すること。【解決手段】認証連携システムの認証サーバ４は、認証処理で扱う認証情報を入力として、秘匿化演算処理を行うことにより、認証情報ごとの秘匿認証情報を生成し、認証情報検証サーバ３は、認証サーバ４により生成された秘匿認証情報とその生成元である認証情報を使用するユーザ端末８のユーザを一意に特定するユーザＩＤとの組み合わせを複数組取得して互いに照合することで、その組み合わせについての流用が発生した複数の認証情報を抽出し、認証連携サーバ２は、ユーザ認証状態を構成する認証結果として、認証情報の流用が発生した認証結果を除外した後のユーザ認証状態が、ポリシを満たしているときにサービスを認可する。【選択図】図１
2012212211.tif 000002
【特許請求の範囲】
【請求項１】
ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムであって、
ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、
前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、
前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、
前記認証サーバは、前記認証処理で扱う前記認証情報を入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、
前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報とその生成元である前記認証情報を使用する前記ユーザ端末のユーザを一意に特定するユーザＩＤとの組み合わせを複数組取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、
前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする
認証連携システム。
【請求項２】
ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムであって、
ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、
前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、
前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、
前記認証サーバは、前記認証処理で扱う前記認証情報と、前記ユーザ端末のユーザを一意に特定するユーザＩＤとを入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、
前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報を複数個取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、
前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする
認証連携システム。
【請求項３】
ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムであって、
ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、
前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、
前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、
前記認証サーバは、同じ前記ユーザ端末が複数の前記認証サーバとそれぞれセッションを確立するときに、そのセッションを識別するセッションＩＤとして、同じセッションＩＤを使用するものとし、前記認証処理で扱う前記認証情報と、セッションＩＤとを入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、
前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報を複数個取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、
前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする
認証連携システム。
【請求項４】
前記認証サーバは、実行する前記認証処理の認証方式がパスワード認証または電子証明書認証であるときには、前記秘匿化演算処理として、入力値を引数とするハッシュ関数を呼び出すことで、前記秘匿認証情報を生成し、
前記認証情報検証サーバは、流用が発生した複数の前記認証情報を抽出するための照合処理として、複数の前記秘匿認証情報の値が一致することにより、複数の前記認証情報間に流用が発生したと判定することを特徴とする
請求項１ないし請求項３のいずれか１項に記載に認証連携システム。
【請求項５】
前記認証サーバは、実行する前記認証処理の認証方式が生体認証であるときには、前記秘匿化演算処理として、生体の前記認証情報および秘密鍵を入力とし、生体情報の相関を不変に変換する関数を呼び出すことで、前記秘匿認証情報を生成し、
前記認証情報検証サーバは、流用が発生した複数の前記認証情報を抽出するための照合処理として、複数の前記秘匿認証情報間の類似度が所定値以上であるときに、複数の前記認証情報間に流用が発生したと判定することを特徴とする
請求項１ないし請求項３のいずれか１項に記載に認証連携システム。
【請求項６】
ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムが実行する認証連携方法であって、
前記認証連携システムは、
ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、
前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、
前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、
前記認証サーバは、前記認証処理で扱う前記認証情報を入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、
前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報とその生成元である前記認証情報を使用する前記ユーザ端末のユーザを一意に特定するユーザＩＤとの組み合わせを複数組取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、
前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする
認証連携方法。
【請求項７】
ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムが実行する認証連携方法であって、
前記認証連携システムは、
ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、
前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、
前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、
前記認証サーバは、前記認証処理で扱う前記認証情報と、前記ユーザ端末のユーザを一意に特定するユーザＩＤとを入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、
前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報を複数個取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、
前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする
認証連携方法。
【請求項８】
ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムが実行する認証連携方法であって、
前記認証連携システムは、
ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、
前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、
前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、
前記認証サーバは、同じ前記ユーザ端末が複数の前記認証サーバとそれぞれセッションを確立するときに、そのセッションを識別するセッションＩＤとして、同じセッションＩＤを使用するものとし、前記認証処理で扱う前記認証情報と、セッションＩＤとを入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、
前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報を複数個取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、
前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする
認証連携方法。
【請求項９】
前記認証サーバは、実行する前記認証処理の認証方式がパスワード認証または電子証明書認証であるときには、前記秘匿化演算処理として、入力値を引数とするハッシュ関数を呼び出すことで、前記秘匿認証情報を生成し、
前記認証情報検証サーバは、流用が発生した複数の前記認証情報を抽出するための照合処理として、複数の前記秘匿認証情報の値が一致することにより、複数の前記認証情報間に流用が発生したと判定することを特徴とする
請求項６ないし請求項８のいずれか１項に記載に認証連携方法。
【請求項１０】
前記認証サーバは、実行する前記認証処理の認証方式が生体認証であるときには、前記秘匿化演算処理として、生体の前記認証情報および秘密鍵を入力とし、生体情報の相関を不変に変換する関数を呼び出すことで、前記秘匿認証情報を生成し、
前記認証情報検証サーバは、流用が発生した複数の前記認証情報を抽出するための照合処理として、複数の前記秘匿認証情報間の類似度が所定値以上であるときに、複数の前記認証情報間に流用が発生したと判定することを特徴とする
請求項６ないし請求項８のいずれか１項に記載に認証連携方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認証連携システム、および、認証連携方法の技術に関する。
【背景技術】
【０００２】
近年、インターネットにおけるサービスや企業内ネットワークにおける各種システムにおいて、ＩＤ/パスワードを登録している一人あたりのサービスの数は、年々増加している。ユーザは多数のＩＤ/パスワードを管理するのに負担が非常に大きく、サービスごとに異なるパスワードを設定し把握するのは困難である。
そこで、特許文献１などのシングルサインオンでは、ユーザ認証を一度受けるだけで、ユーザ認証を必要とする複数のサービスへアクセスできる。これにより、ユーザが管理するパスワードの数を削減することで、より安全にパスワードを管理することが可能となる。
【０００３】
非特許文献１は、ＳＡＭＬ（Security Assertion Markup Language）と呼ばれるシングルサインオン技術であり、標準化団体ＯＡＳＩＳにおいて策定され、認証結果やアクセス認可判定結果などのセキュリティデータを安全に伝達する方法をＸＭＬ（Extensible Markup Language）で記述するマークアップ言語仕様である。ＳＡＭＬでは、ＩｄＰ（Identity Provider）と呼ばれる、ユーザ認証の結果をアサーションと呼ばれるメッセージとして発行し、ＳＰ（Service Provider）と呼ばれるサービスへ提供する。そしてＳＰは、アサーションを信頼することで、ユーザが認証済か否かを検知できる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−１１３４６２号公報
【非特許文献】
【０００５】
【非特許文献１】「Profiles for the OASIS Security Assertion Markup Language （ＳＡＭＬ） V2.0.」,OASIS Standard,March 2005
【発明の概要】
【発明が解決しようとする課題】
【０００６】
一方、オンラインバンキングや公的な手続きなど、高い安全性が求められるサービスでは、１つのサービスを受けるために、複数のユーザ認証の結果を組み合わせて用いるシステム形態（多要素認証）も考えられる。これにより、多要素認証のうちの１つのユーザ認証が不正な攻撃者によって成功したとしても、多要素認証のうちの他のユーザ認証が成功しない限り、サービスは許可されないため、セキュリティ強度を高めることができる。
【０００７】
しかし、ユーザによっては、多要素認証で同じパスワードを使いまわす（流用する）などにより、多要素認証それぞれのパスワード管理を横着してしまう場合もある。そのときには、１つのユーザ認証が攻撃者に解読されてしまうと、連鎖的に他のユーザ認証も解読されてしまい、多要素認証を用いたとしても、充分なセキュリティ強度を保証できない。
【０００８】
そこで、本発明は、前記した問題を解決し、複数のユーザ認証の結果を組み合わせて用いるときに、セキュリティ強度の低下を防止することを、主な目的とする。
【課題を解決するための手段】
【０００９】
前記課題を解決するために、本発明は、ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムであって、
ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、
前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、
前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、
前記認証サーバが、前記認証処理で扱う前記認証情報を入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、
前記認証情報検証サーバが、前記認証サーバにより生成された前記秘匿認証情報とその生成元である前記認証情報を使用する前記ユーザ端末のユーザを一意に特定するユーザＩＤとの組み合わせを複数組取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、
前記認証連携サーバが、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする。
その他の手段は、後記する。
【発明の効果】
【００１０】
本発明によれば、複数のユーザ認証の結果を組み合わせて用いるときに、セキュリティ強度の低下を防止することができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の第１実施形態に関する認証連携システムの構成図である。
【図２】本発明の第１実施形態に関する認証連携システムを構成する各装置の詳細を示す構成図である。
【図３】本発明の第１実施形態に関する認証連携システムを構成する各計算機のハードウェア構成図である。
【図４】本発明の第１実施形態に関するユーザＩＤ「taro」が第１サービスＩＤのサービスコンテンツを使用する処理を示すフローチャートである。
【図５】本発明の第１実施形態に関する図４の実行後に、ユーザＩＤ「taro」が第２サービスＩＤのサービスコンテンツを使用する処理を示すフローチャートである。
【図６】本発明の第１実施形態に関する図４および図５の処理における認証連携サーバの動作を示すフローチャートである。
【図７】本発明の第１実施形態に関する図４および図５の処理における認証情報検証サーバの動作を示すフローチャートである。
【図８】本発明の第２実施形態に関する認証連携システムの構成図である。
【図９】本発明の第２実施形態に関する認証連携システムを構成する各装置の詳細を示す構成図である。
【図１０】本発明の第２実施形態に関するドメインＡ側で開始される処理を示すフローチャートである。
【図１１】本発明の第２実施形態に関するドメインＢへのサービス要求を契機に、ドメインＢ側で開始される処理を示すフローチャートである。
【図１２】本発明の第２実施形態に関するＳＡＭＬ  ＳＰ部が実行する各処理を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、本発明の一実施形態を、図面を参照して詳細に説明する。
【００１３】
図１は、認証連携システムの構成図である。認証連携システムは、２つのドメインＡ，Ｂ間がネットワーク５ａ，５ｂで接続されて構成される。ネットワーク５ａ，５ｂは、企業内ＬＡＮ（Local Area Network）のようなプライベートネットワークでも、インターネットのようなオープンネットワークでもよい。
なお、以下の説明では、２つのドメインで同じ構成要素が存在するときには、その構成要素の符号末尾の「ａ，ｂ」が所属するドメインを示す。例えば、認証連携サーバ２は、ドメインＡ内の認証連携サーバ２ａと、ドメインＢ内の認証連携サーバ２ｂとがそれぞれ存在する。
【００１４】
ＳＡＭＬを用いる認証連携システムは、認証用の構成として、認証連携サーバ２ａ、認証連携サーバ２ｂ、認証情報検証サーバ３、認証サーバ４ｂ、認証サーバ４ａを含む。
さらに、その認証結果を利用する装置として、ユーザ端末８、アプリケーションサーバ１ｘ、および、アプリケーションサーバ１ｙが存在する。ユーザ端末８は、認証連携システムの他装置との通信を行う装置であり、その通信を実施するＷｅｂブラウザ８１を備えている。
なお、これらの装置構成については、各装置が物理的に１台の筐体に収容されていてもよいし、複数の装置（認証連携サーバ２や認証情報検証サーバ３など）が物理的に１台の筐体に収容されていてもよい。
以下、本実施形態で使用される各用語を定義する。
【００１５】
【表１】
2012212211.tif 000003
【００１６】
表１は、認証チェック用パラメータを示す。この表の列要素は、ユーザ端末８を操作する人間であるユーザごとのパラメータと、認証サーバ４ａごとのパラメータと、認証サーバ４ｂごとのパラメータとを示す。
【００１７】
項目「ユーザＩＤ」は、ユーザを識別するためのＩＤであり、ユーザごとの（ユーザ端末８ごとの）ユーザＩＤ「taro」の他に、そのユーザＩＤ「taro」が使用する認証サーバ４ａ上の第１ユーザＩＤ「taroauth1」と、同じユーザＩＤ「taro」が使用する認証サーバ４ｂ上の第２ユーザＩＤ「taroauth2」とがそれぞれ登録される。なお、表１の各セル値の２行目以降の英数字表記（taroなど）は、各セル値の１行目で示すパラメータ名称（ユーザＩＤ）の具体例である。
【００１８】
項目「流用検出用ユーザＩＤ」は、ユーザＩＤのハッシュ値として構成される。このように人間が可読なデータ（taro）から、そのハッシュ値を作成することにより、ハッシュ値がもともと意味する情報を残しつつ、攻撃者による盗み見を困難にする。
【００１９】
項目「認証情報」は、認証サーバ４ごとのユーザＩＤに対応する認証用の入力情報である。
・認証方式が「パスワード認証」のときには、その認証情報が「パスワード（文字列）」である。
・認証方式が「電子証明書認証」のときには、その認証情報が「電子証明書」である。
・認証方式が「生体認証」のときには、その認証情報が「ユーザの生体から（生体センサで測定された値をもとに）生成される情報」である。
【００２０】
項目「認証情報ハッシュ値」は、項目「流用検出用ユーザＩＤ」と同様に、認証情報をハッシュ化することにより、難読性を高める。第１認証情報から第１ハッシュ値が生成され、第２認証情報から第２ハッシュ値が生成される。
【００２１】
項目「秘匿認証情報」は、認証情報またはその認証情報ハッシュ値を入力データとして、秘匿化演算を行うことにより生成されるパラメータである。秘匿化演算は、認証方式により規定される。
・認証方式が「パスワード認証」または「電子証明書認証」のときには、秘匿化演算として「一方向性関数（sha-1やMD5などのハッシュ関数）」の計算結果が秘匿認証情報である。そして、生成された第１秘匿認証情報と第２秘匿認証情報とが一致するときに、同じユーザが複数の認証情報として同じデータを用いていることにより、第１認証情報と第２認証情報が脆弱な認証情報として検出される。
・認証方式が「生体認証」のときには、秘匿化演算「生体情報の相関不変な一方向性変換処理」の計算結果が秘匿認証情報である。なお、一方向性変換処理には、変換用の秘密鍵（認証サーバ４の秘密鍵に流出検出用ユーザＩＤを加えた文字列）が使用される。そして、生成された第１秘匿認証情報と第２秘匿認証情報との画像処理における類似度が所定値以上であるときに、同じユーザが複数の認証情報として同じデータを用いていることにより、第１認証情報と第２認証情報が脆弱な認証情報として検出される。
【００２２】
このように、生成された秘匿認証情報は、通信メッセージに含められ、装置間で伝達される。ユーザのＩＤや属性情報といったプライバシ情報を別のサービスへ提供するときに、ユーザ認証に使用するパスワードなどの認証情報については特に第三者に漏れないように注意する必要がある。
認証情報ハッシュ値が認証サーバ上で管理されている場合、第三者には内容が分からないようになっていたとしても、第三者はこの状態の認証情報を認証サーバ４に送りつけることで、認証情報の所有者になりすましてユーザ認証を成功させてしまう。
そこで、認証情報を外部へ提供する際に、認証情報や認証情報ハッシュ値の代わりに、表１の秘匿認証情報を提供する。これにより、その秘匿認証情報を第三者が取得したとしても、その秘匿認証情報から認証サーバ４の管理する認証情報を得られず、認証情報の所有者へのなりすましを防止できる。
【００２３】
【表２】
2012212211.tif 000004
【００２４】
表２は、表１で定義した各パラメータをもとにした、４種類の認証チェック項目（認可、認証、流用検証、単体検証）を示す。
表２の２行目に示す「認証」は、認証サーバ４ごとに、入力された認証情報をもとに、そのユーザが正当か否かを認証する処理であり、その認証に成功したときには、認証アサーションが発行される。
表２の１行目に示す「認可」は、発行された認証アサーションで示されるユーザ認証状態が、サービスに要するポリシを満たしているときに、サービスの実行を認可する。この「認可」について、１つのサービスを受けるために、複数の認証アサーションを要するポリシとしてもよいし、複数のサービスを受けるために必要な認証アサーションを、サービス間で共有するポリシとしてもよい。
表２の４行目に示す「単体検証」は、「認証」で使用される認証情報を単体としてみたときに、他者に攻撃されやすい認証情報を用いているか否かを検証する処理である。なお、「認可」で使用される認証アサーションは、「単体検証」に合格した認証アサーションだけを「認可」で使用することで、セキュリティ強度を向上できる。
表２の３行目に示す「流用検証」は、「認証」で使用される同じユーザによる複数の認証情報として、同じデータを使い回しているか否かを検証する処理である。「流用検証」に合格した認証アサーションだけを「認可」で使用することで、セキュリティ強度を向上できる。
【００２５】
図２は、認証連携システムを構成する各装置の詳細を示す構成図である。なお、以下の説明では、図１と同様に、２つのドメインで同じ構成要素が存在するときには、その構成要素の符号末尾の「ａ，ｂ」が所属するドメインを示す。例えば、認証状態管理部２１ａは、ドメインＡ内の認証連携サーバ２ａに含まれ、認証状態管理部２１ｂは、ドメインＢ内の認証連携サーバ２ｂに含まれる。
【００２６】
アプリケーションサーバ１は、ユーザ端末８からの処理要求を受信し、認証連携サーバ２から認可がでたときに、その処理要求に対応するサービスコンテンツをユーザ端末８へ提供する装置である。なお、図２では、２台のアプリケーションサーバ１ｘ，１ｙを例示しており、以下のフローチャートなどの説明で、どちらのアプリケーションサーバ１内の構成要素かを示すために、アプリケーションサーバ１内の構成要素を示す符号の末尾に「ｘ」または「ｙ」を付加する。
【００２７】
アプリケーションサーバ１は、ユーザ端末８との間で通信を実施し、認可判定結果に基づきアクセス制御を実施するＳＡＭＬ  ＳＰ部１１、ユーザ端末８からのサービス実行パラメータに基づきサービスを実行し、サービスコンテンツをユーザ端末８へ提示したりするＷｅｂサーバ１２、およびアクセス制御に使用する認可判定結果を格納するアクセステーブル１３を備えている。
【００２８】
認証連携サーバ２は、ネットワーク５単位で存在し、ユーザ端末８からの処理要求の受信を契機に、認証サーバ４からの認証結果に基づいてユーザ端末８に対するアプリケーションサーバ１へのアクセス認可の可否を判定する装置である。どの認証サーバ４から認証結果を取得するかは、認証連携サーバ２が選択して決定し、ユーザ端末８へ認証の実施を促す。
【００２９】
このため、認証連携サーバ２は、認証状態管理部２１と、ロケーション管理部２２と、ＩＤ管理部２３と、認可判定部２４と、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５と、認証情報検証依頼部２６と、認証状態テーブル２７と、認証要求ポリシテーブル２８と、認証サーバリスト２９とを備えている。
認証状態管理部２１は、ユーザ端末８の認証状態およびアプリケーションサーバ１のポリシを管理する。
ロケーション管理部２２は、連携する認証サーバ４のＵＲＬを管理する。
ＩＤ管理部２３は、アプリケーションサーバ１上で使用するユーザＩＤと各々の認証サーバ上で使用するユーザＩＤを結び付けて管理する。
認可判定部２４は、ユーザ端末８の認証状態とアプリケーションサーバ１のポリシを比較することによりアプリケーションサーバ１へのアクセス可否を判定する。
ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５は、ユーザ端末８との通信を実施し他の認証連携サーバ２や認証サーバ４に対しユーザ認証処理を依頼する。
認証情報検証依頼部２６は、認証情報検証サーバ３との通信を実施し、認証情報検証サーバ３に対し認証情報の脆弱度判定を依頼する。
認証状態テーブル２７は、ユーザ端末８の認証状態を格納する。
認証要求ポリシテーブル２８は、アプリケーションサーバ１のポリシを格納する。
認証サーバリスト２９は、連携する認証サーバ４のＵＲＬを格納する。
【００３０】
認証情報検証サーバ３は、ドメイン単位で存在し、認証連携サーバ２から取得した秘匿認証情報および認証情報プロパティにより、ユーザが認証に使用した認証情報が脆弱でないか検証（表２の流用検証、単体検証）するための装置である。なお、認証情報プロパティとは、認証情報が所有する特徴を集めたリストである。特徴の例としては、パスワードの長さやパスワードに使用した文字の種別（英字、数字、記号）などが挙げられる。
【００３１】
このため、認証情報検証サーバ３は、流用検出管理部３１と、認証情報検証部３２と、通信部３３と、流用検出用テーブル３４とを備えている。
流用検出管理部３１は、脆弱度判定の結果脆弱でないと判定した秘匿認証情報を管理する。
認証情報検証部３２は、認証連携サーバ２から取得した秘匿認証情報、認証プロパティおよび後記の流用検出用テーブル３４に格納されている秘匿認証情報を基に、ユーザが認証に使用した認証情報が脆弱でないか検証する。
通信部３３は、認証連携サーバ２との間の通信を実施する。
流用検出用テーブル３４は、認証連携サーバ２から取得した秘匿認証情報を格納する。
【００３２】
認証サーバ４は、ドメイン単位で存在し、ユーザ端末８との間でユーザ認証を実施し、認証結果および認証を実施したユーザの秘匿認証情報、および認証プロパティを認証連携サーバ経由で認証情報検証サーバ３へ提供する装置である。
【００３３】
このため、認証サーバ４は、認証情報管理部４１と、認証情報秘匿化部４２と、認証部４３と、ＳＡＭＬ  ＩｄＰ部４４と、認証情報テーブル４５とを備えている。
認証情報管理部４１は、ユーザの認証情報を管理する。
認証情報秘匿化部４２は、ユーザの認証情報から秘匿認証情報および認証プロパティを生成する。
認証部４３は、ユーザ端末８から取得した認証情報と、後記の認証情報テーブル４５に格納されている認証情報とを照合することによりユーザ認証を実施する。
ＳＡＭＬ  ＩｄＰ部４４は、ユーザ端末８との通信を実施し、認証結果をユーザ端末８経由で認証連携サーバ２へ送信する。
認証情報テーブル４５は、ユーザの認証情報を格納する。
【００３４】
なお、複数の秘匿認証情報間の照合処理（表２の流用検証）において、＜認証情報に対応するユーザ、認証情報から生成された秘匿認証情報＞の組み合わせが一致する複数の組が存在したときに、同一の認証情報の流用検出を行うこととしたが、流用検出用の照合対象として、この組み合わせのデータ以外にも、＜ユーザを特定できる情報と、そのユーザの認証情報を特定できる情報＞であれば、他のデータを用いてもよい。
【００３５】
例えば、以下の（手順１〜３）により、＜ユーザを特定できる情報と、そのユーザの認証情報を特定できる情報＞を生成してもよい。
（手順１）ユーザを特定できる情報として、ユーザＩＤ、または、そのユーザが使用するユーザ端末８と認証サーバ４との間で共有するセッションＩＤを一時ユーザＩＤとする。なお、セッションＩＤとは、メッセージの送受信により取得したパラメータを管理する際に必要となるＩＤである。
（手順２）前記（手順１）で取得したユーザを特定できる情報と認証情報との文字をコロンなどの接続用文字列で連結した文字列を生成する。
（手順３）前記（手順２）で生成した文字列に対して、認証情報秘匿化部４２が秘匿化処理を行うことで、ユーザを特定できる情報を含む秘匿認証情報を生成する。
【００３６】
なお、（手順１）において、ある認証サーバ４で生成したセッションＩＤを、別の認証サーバ４でも使用することにより、セッションＩＤがユーザを特定できるユーザＩＤの代替データ（一時ユーザＩＤ）としての役割を果たす。そのため、ユーザ端末８は新たに認証サーバ４との間でセッションを確立する前に、その確立先とは別の認証サーバ４によって既に生成されたセッションＩＤを新たなセッションでも使用するように、ユーザ端末８から認証サーバ４への処理要求内（Set-cookieヘッダ）に既に生成されたセッションＩＤを含めることとする。
【００３７】
そして、以下の（手順４）により、複数の秘匿認証情報間の照合処理を実施する。
（手順４）前記（手順３）で生成された秘匿認証情報どうしを認証情報検証部３２が照合し、一致する秘匿認証情報を検出したときに、同一ユーザによる認証情報の流用とする。一方、あるユーザと別のユーザとで、偶然に同じ認証情報（パスワード文字列など）を用いていたとしても、（手順２）で生成される文字列は、複数のユーザで互いに異なるため、（手順４）では別々のユーザ間での流用という誤検出は発生しない。
これにより、認証情報検証サーバ３の管理者が不正に同一の秘匿認証情報を結びつけ、ユーザの認証情報を推定し成りすます、といった秘匿認証情報の悪用を防止することができる。
【００３８】
【表３】
2012212211.tif 000005
【００３９】
表３は、認証連携サーバ２内の各テーブルのデータ内容の一例を示す。
【００４０】
認証要求ポリシテーブル２８は、サービスＩＤと、アプリケーションサーバ１と、ポリシとの対応情報を格納する。
項目「サービスＩＤ」は、アプリケーションサーバ１が提供するサービスを特定するためＩＤを示す。
項目「アプリケーションサーバ」は、項目「サービスＩＤ」のサービスを提供するアプリケーションサーバ１を示す。例えば、アプリケーションサーバ１ｘは、サービスＩＤ「第１サービスＩＤ」のサービスを提供し、アプリケーションサーバ１ｙは、サービスＩＤ「第２サービスＩＤ」のサービスを提供する。
項目「ポリシ」は、認証要求ポリシの略であり、項目「サービスＩＤ」のサービスをユーザ端末８に提供するために必要な認証方式（パスワード認証、電子証明書認証、生体認証など）の種別とその認証回数との組を示す。
【００４１】
認証状態テーブル２７は、ユーザＩＤと、そのユーザが認証（表２の認証）に成功した結果（ユーザ認証状態）を管理する。例えば、ユーザ「taro」には、２回の認証に成功した結果である認証アサーション（第１パスワード認証、第２パスワード認証）が対応づけられている。
認証サーバリスト２９は、認証サーバ４のＵＲＬと、その認証サーバ４が提供する認証方式と、対応サービス数とを対応づけて管理する。項目「対応サービス数」とは、認証サーバ４を利用可能なアプリケーションサーバ１の数を示し、このアプリケーションサーバ１の数が多い順に、どの認証サーバ４を利用するか決定される。
【００４２】
【表４】
2012212211.tif 000006
【００４３】
表４は、流用検出用テーブル３４のデータ内容の一例を示す。流用検出用テーブル３４は、ユーザＩＤに対応する流用検出用ユーザＩＤごとに、そのユーザが認証を実施した認証方式と、その認証結果から生成された秘匿認証情報とを対応づけている。なお、ユーザＩＤと流用検出用ユーザＩＤとの対応情報は、ＩＤ管理部２３によって管理される。
【００４４】
【表５】
2012212211.tif 000007
【００４５】
表５は、認証サーバ４ごとに格納される認証情報テーブル４５のデータ内容の一例を示す。認証情報テーブル４５には、認証サーバ４のユーザＩＤごとに、そのユーザＩＤに対応する認証情報から生成されたハッシュ値が対応づけられている。
認証情報テーブル４５ａには、第１ユーザＩＤと第１認証情報から生成された第１ハッシュ値との対応データが格納されている。
認証情報テーブル４５ｂには、第２ユーザＩＤと第２認証情報から生成された第２ハッシュ値との対応データが格納されている。
この第１ユーザＩＤと第２ユーザＩＤとは、同じユーザＩＤ「taro」によって使用されている。
【００４６】
図３は、認証連携システムを構成する各計算機を示すハードウェア構成図である。
計算機９は、ＣＰＵ９１と、メモリ９２と、ハードディスクなどの外部記憶装置９３と、インターネットやＬＡＮなどのネットワーク９９ａを介して他の装置と通信を行うための通信装置９４と、キーボードやマウスなどの入力装置９５と、モニタやプリンタなどの出力装置９６と、可搬性を有する記憶媒体９９ｂの読取装置９７とが、内部バス９８を介して接続されている。記憶媒体９９ｂは、例えば、ＩＣカードやＵＳＢメモリである。
【００４７】
計算機９は、図２で示した各処理部の機能を実現するためのプログラムをメモリ９２上にロードし、ＣＰＵ９１により実行する。そのプログラムは、あらかじめ、計算機９の外部記憶装置９３に格納されていてもよいし、実行時に、読取装置９７や通信装置９４を介して、他の装置から外部記憶装置９３にダウンロードされてもよい。
そして、プログラムは一旦外部記憶装置９３に格納された後、そこからメモリ上にロードされてＣＰＵ９１に実行されてもよいし、あるいは外部記憶装置９３に格納されることなく、直接メモリ上にロードされて、ＣＰＵ９１に実行されてもよい。
【００４８】
図４は、ユーザＩＤ「taro」が第１サービスＩＤのサービスコンテンツを使用する例を示すフローチャートである。図４の詳細は後記するが、図４の処理の概要は、以下の通りである。
まず、認証要求ポリシテーブル２８で「１回のパスワード認証」が必要であるので、その「パスワード認証」を得るための認証サーバ４として、認証サーバリスト２９から対応サービス数が最も多い（７９個）認証サーバ４ｂのＵＲＬ「http://demosite2.com/idpw/」を取得する。
そして、認証サーバ４ｂによる第２パスワード認証に成功し（表２の認証）、かつ、その第２パスワード認証に使用された第２認証情報への検証（表２の単体検証、流用検証）が成功したときには、認証状態テーブル２７内のユーザＩＤ「taro」に対応するユーザ認証状態が「（未認証）」から「第２パスワード認証」へと更新される。これにより、ユーザ認証状態「第２パスワード認証」がポリシ「１回のパスワード認証」を満たすので、ユーザＩＤ「taro」は、第１サービスＩＤのサービスコンテンツをアプリケーションサーバ１ｘから使用できる。
【００４９】
【表６】
2012212211.tif 000008
【００５０】
表６は、図４以降で説明する各フローチャート内で使用される通信メッセージごとの仕様を示す。
表６の名称で示される各データは、そのプロトコルの種別とそのプロトコルのタイプで特定されるフォーマットの通信メッセージに含まれて送信される。
プロトコルの種別として、ＨＴＴＰ（Hypertext Transfer Protocol）は、標準化団体ＩＥＴＦにおいてRFC2616で定義されている。
ＳＯＡＰ（Simple Object Access Protocol）は、標準化団体Ｗ３Ｃによって策定され、他の通信機器上にあるデータやサービスを呼び出すための通信プロトコルであり、通信機器間で送受されるメッセージはＸＭＬ（Extensible Markup Language）で記述される。
【００５１】
検証要求は、<authResultVerifyRequest>〜</authResultVerifyRequest>内に、以下の順序でタグが列挙されて構成される。
<authUserID>「第１ユーザＩＤ（taroauth1）」</authUserID>
<SAML:Assertion>「認証サーバ４が発行した認証結果」</SAML:Assertion>
<credential>「秘匿認証情報」</credential>
<credentialProperties>「認証情報プロパティ」</credentialProperties>
【００５２】
検証応答は、<authResultVerifyResponse>〜</authResultVerifyResponse>内に、以下の順序でタグが列挙されて構成される。
<result>「脆弱性検証の結果」</result>
なお、脆弱性検証の結果には、脆弱でない「invulnerable」または脆弱である「vulnerable」の値が格納される。
【００５３】
【表７】
2012212211.tif 000009
【００５４】
表７は、後記する図４での各ステップごとの通信メッセージの内容（種別、クエリ、セッションＩＤ）を示す。なお、図４での「サービスＩＤ」とは、アプリケーションサーバ１ｘが提供する第１サービス用のＩＤである。
本実施形態では、ユーザ端末８と他装置との間のデータのやりとりに、ＨＴＴＰバインディングを用いた一例を説明する。
セッションＩＤは、ユーザ端末８との間で共有される接続識別子（Set-Cookieの値）であり、転送応答の送信元装置が新たに作成してユーザ端末８に通知した後（例えば、Ｓ３０２で最初に登場する「ｃ１」）、ユーザ端末８からそのセッションＩＤの通知を受ける（例えば、Ｓ３１９で処理要求に含まれる「ｃ１」）。
なお、本明細書の各フローチャートでは、セッションごとに、そのセッションの活性化期間を示す破線の矩形も図示している。例えば、図４のユーザ端末８の動作において、開始点（Ｓ３０１）から終了点（Ｓ３２０）までの期間を破線矩形で示しているが、この破線矩形で示される期間には、セッションＩＤ＝「ｃ１」のセッションが活性化している。
【００５５】
転送応答の送信元装置は、転送応答の受信装置（ユーザ端末８）に対して、次に送信する処理要求の送信先を転送先（Locationヘッダの値）として指定する。転送応答の受信装置は、その転送応答の送信元装置の識別子を次に送信する処理要求の転送元（Refererヘッダの値）として指定する。これにより、処理要求の受信装置は、転送元の装置を特定することができる。
【００５６】
図４に戻り、Ｓ３０１として、ユーザ端末８のＷｅｂブラウザ８１は、ユーザからの操作にしたがって、処理要求をアプリケーションサーバ１ｘに送信する。
Ｓ３０２として、アプリケーションサーバ１ｘのＳＡＭＬ  ＳＰ部１１ｘは、転送応答をＷｅｂブラウザ８１に送信する。この転送応答は、ユーザ端末８が認証済みでないことを示すメッセージであり、認証済みでないことは、アプリケーションサーバ１ｘがアクセステーブル１３ｘから、ユーザ端末８のユーザＩＤおよび認可判定結果の登録を見つけられなかったことで確認される。
【００５７】
Ｓ３０３として、Ｗｅｂブラウザ８１は、処理要求を認証連携サーバ２ａに送信する。
Ｓ３０４として、ロケーション管理部２２ａは、連携する認証サーバ４の認証方式を基に、認証サーバ４のＵＲＬについて認証サーバリスト２９ａを検索することで、呼び出す認証サーバ４を決定する。この決定された認証サーバ４は、Ｓ３０３の処理要求を実現するために不足分の認証を行う相手である。
Ｓ３０５として、認証連携サーバ２ａのＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ａは、転送応答をＷｅｂブラウザ８１に送信する。
【００５８】
Ｓ３０６として、Ｗｅｂブラウザ８１は、処理要求を認証連携サーバ２ｂに送信する。
Ｓ３０７として、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ｂは、転送応答をＷｅｂブラウザ８１に送信する。なお、ロケーション管理部２２ｂは、認証サーバ４ｂのＵＲＬを解析することで、認証サーバ４ｂのドメインが他ドメイン（ドメインＢ）上に存在する旨を確認する。
【００５９】
Ｓ３０８として、Ｗｅｂブラウザ８１は、処理要求を認証サーバ４ｂに送信する。
Ｓ３０９として、認証サーバ４ｂの認証部４３ｂは、ユーザ端末８から認証情報を取得し、ユーザ認証を実施する。認証部４３ｂは、認証情報テーブル４５ｂ内に第２ユーザＩＤと第２ハッシュ値との対応データが存在するので、認証成功の旨を示すＳＡＭＬ２．０で規定された認証アサーションを作成し、これに第２認証結果を含める。
認証情報秘匿化部４２ｂは、認証情報テーブル４５ｂの第２ハッシュ値を秘匿化することで、第２秘匿認証情報を生成する。
認証情報管理部４１ｂは、第２認証情報から特徴量を抽出し、第２認証情報プロパティを生成する。
Ｓ３１０として、ＳＡＭＬ  ＩｄＰ部４４ｂは、転送応答（生成された第２秘匿認証情報と、第２認証情報プロパティとを含む）をＷｅｂブラウザ８１に送信する。
【００６０】
Ｓ３１１として、Ｗｅｂブラウザ８１は、処理要求を認証連携サーバ２ｂに送信する。
Ｓ３１２として、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ｂは、転送応答をＷｅｂブラウザ８１に送信する。
Ｓ３１３として、Ｗｅｂブラウザ８１は、処理要求を認証連携サーバ２ａに送信する。
Ｓ３１４として、認証情報検証依頼部２６ａは、検証要求を認証情報検証サーバ３に送信する。
Ｓ３１５として、流用検出管理部３１は、脆弱性の検証を実施する。
Ｓ３１６として、通信部３３は、検証応答を認証連携サーバ２ａに送信する。
Ｓ３１７として、認可判定部２４ａは、認可の判定を実施する。
【００６１】
Ｓ３１８として、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ａは、転送応答をＷｅｂブラウザ８１に送信する。
Ｓ３１９として、Ｗｅｂブラウザ８１は、処理要求をアプリケーションサーバ１ｘに送信する。
Ｓ３２０として、ＳＡＭＬ  ＳＰ部１１ｘは、成功応答をＷｅｂブラウザ８１に送信する。成功応答のBODY部には、Ｓ３０１のサービス実行パラメータからＷｅｂサーバ１２ｘによって生成されるサービスコンテンツが含まれている。Ｗｅｂブラウザ８１は、受信した成功応答内のサービスコンテンツを処理し、Ｗｅｂブラウザ８１上の画面に表示する。
【００６２】
図５は、図４の実行後に、ユーザＩＤ「taro」が第２サービスＩＤのサービスコンテンツを使用する例を示すフローチャートである。図５は、ユーザが自ドメインの認証サーバ４ａを利用して認証を実施し、アプリケーションサーバ１ｙが提供するサービスを利用する場合の動作を示すフローチャートである。図５の詳細は後記するが、図５の処理の概要は、以下の通りである。
まず、認証要求ポリシテーブル２８で「２回のパスワード認証」が必要であるので、ユーザ認証状態「第２パスワード認証」だけでは、１回分のパスワード認証が不足する。そこで、２回目のパスワード認証として、認証サーバリスト２９（表３）から対応サービス数が２番目に多い（５７個）認証サーバ４ａのＵＲＬ「http://demosite1.com/idpw/」を取得する。
そして、認証サーバ４ａによる第１パスワード認証に成功し（表２の認証）、かつ、その第１パスワード認証に使用された第２認証情報への単体検証と、第１認証情報および第２認証情報の組み合わせへの流用検証が成功したときには、認証状態テーブル２７（表３）内のユーザＩＤ「taro」に対応するユーザ認証状態が「第２パスワード認証」から「第１パスワード認証、第２パスワード認証」へと更新される。これにより、ユーザ認証状態「第１パスワード認証、第２パスワード認証」がポリシ「２回のパスワード認証」を満たすので、ユーザＩＤ「taro」は、第２サービスＩＤのサービスコンテンツをアプリケーションサーバ１ｙから使用できる。
【００６３】
【表８】
2012212211.tif 000010
【００６４】
表８は、後記する図５での各ステップごとの通信メッセージの内容（種別、クエリ、セッションＩＤ）を示す。なお、図５での「サービスＩＤ」とは、アプリケーションサーバ１ｙが提供する第２サービス用のＩＤである。
【００６５】
Ｓ４０１として、ユーザ端末８のＷｅｂブラウザ８１は、処理要求をアプリケーションサーバ１ｙに送信する。
Ｓ４０２として、アプリケーションサーバ１ｙのＳＡＭＬ  ＳＰ部１１ｙは、転送応答をＷｅｂブラウザ８１に送信する。ここで、ＳＡＭＬ  ＳＰ部１１ｙは、Ｓ３０２と同様に、アクセステーブル１３ｙを参照し、ユーザ端末８が認証済でないことを確認する。
【００６６】
Ｓ４０３として、Ｗｅｂブラウザ８１は、処理要求を認証連携サーバ２ａに送信する。
Ｓ４０４として、認証連携サーバ２ａのロケーション管理部２２ａは、呼び出す認証サーバ４を決定する。
Ｓ４０５として、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ａは、転送応答をＷｅｂブラウザ８１に送信する。
【００６７】
Ｓ４０６として、Ｗｅｂブラウザ８１は、処理要求を認証サーバ４ａに送信する。
Ｓ４０７として、認証サーバ４ａの認証部４３ａはユーザ端末８から認証情報を取得し、ユーザ認証を実施する。認証部４３ａは、認証情報テーブル４５ａ内に第１ユーザＩＤと第１ハッシュ値との対応データが存在するので、認証成功の旨を示すＳＡＭＬ２．０で規定された認証アサーションを作成し、これに第１認証結果を含める。
Ｓ４０８として、ＳＡＭＬ  ＩｄＰ部４４ａは、転送応答をＷｅｂブラウザ８１に送信する。なお、Ｓ４０８の転送応答に含まれる各パラメータは、以下に示すように作成される。認証情報秘匿化部４２ａは、認証情報テーブル４５ａの第１ハッシュ値を秘匿化することで、第１秘匿認証情報を生成する。認証情報管理部４１ａは、第１認証情報から特徴量を抽出し、第１認証情報プロパティを生成する。
【００６８】
Ｓ４０９として、Ｗｅｂブラウザ８１は、処理要求を認証連携サーバ２ａに送信する。
Ｓ４１０として、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ａは、検証要求を認証情報検証サーバ３に送信する。
Ｓ４１１として、流用検出管理部３１は、脆弱性の検証を実施する。
Ｓ４１２として、通信部３３は、検証応答を認証連携サーバ２ａに送信する。
Ｓ４１３として、認可判定部２４ａは、認可の判定を実施する。
Ｓ４１４として、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ａは、転送応答をＷｅｂブラウザ８１に送信する。
【００６９】
Ｓ４１５として、Ｗｅｂブラウザ８１は、処理要求をアプリケーションサーバ１ｙに送信する。
Ｓ４１６として、Ｗｅｂサーバ１２ｙは、サービスを実行する。
Ｓ４１７として、ＳＡＭＬ  ＳＰ部１１ｙは、成功応答をＷｅｂブラウザ８１に送信する。成功応答のBODY部には、Ｓ４０１のサービス実行パラメータからＷｅｂサーバ１２ｙによって生成されるサービスコンテンツが含まれている。Ｗｅｂブラウザ８１は、受信した成功応答内のサービスコンテンツを処理し、Ｗｅｂブラウザ８１上の画面に表示する。
【００７０】
図６は、図４および図５の処理における認証連携サーバ２の動作を示すフローチャートである。認証連携サーバ２は、ユーザ端末８に認証が必要か否かを判定し、その結果に基づきアプリケーションサーバへのアクセス認可判定を実施する。図６では、図４および図５で説明した以下の４つのケースについて、説明する。
（ケース１）Ｓ３０３の処理要求からＳ３１２の転送応答まで
（ケース２）Ｓ３１３の処理要求からＳ３１８の転送応答まで
（ケース３）Ｓ４０３の処理要求からＳ４０８の転送応答まで
（ケース４）Ｓ４０９の処理要求からＳ４１４の転送応答まで
【００７１】
認証連携サーバ２のＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５は、４つの各ケースの処理要求を受信し（Ｓ５０１）、その処理要求に含まれるメッセージパラメータを取得し（Ｓ５０２）、メモリ上に格納された内部状態が認証結果待ちであるか否かを判定する（Ｓ５０３）。Ｓ５０３でＹｅｓなら（ケース２，ケース４）Ｓ５０９に進み、Ｎｏなら（ケース１，ケース３）Ｓ５０４へ進む。
【００７２】
Ｓ５０４として、認証状態管理部２１は、サービスＩＤ（第１サービスＩＤ）を基に、ポリシについて認証要求ポリシテーブル２８を検索し、アプリケーションサーバ１のポリシ（ケース１なら「１回のパスワード認証」、ケース３なら「２回のパスワード認証」）を取得する。
Ｓ５０５として、認証状態管理部２１は、ユーザＩＤ（taro）を基に、認証状態テーブル２７を検索し、ユーザ端末８の認証状態（ケース１では「未認証」、ケース３では「第２パスワード認証」）を取得する。
Ｓ５０６として、認可判定部２４は、Ｓ５０５の認証状態がＳ５０４のポリシを満足しているか否かを判定する。この判定は、認証状態テーブル２７のポリシに記載されているすべての認証（認証種別ごとの認証回数）を、ユーザ認証状態が満足しているか否かにより、判定される。Ｓ５０６でＹｅｓなら（ケース２、ケース４）Ｓ５０７へ進み、Ｎｏなら（ケース１、ケース３）Ｓ５１８へ進む。
Ｓ５０７では、認可判定部２４は、認可判定結果（認可）を生成し、処理を終了する。
【００７３】
Ｓ５０９では、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５は、Ｓ５０１のメッセージから認証結果を取得し、その取得した認証結果が認証成功か否かを判定する（Ｓ５１０）。Ｓ５１０でＹｅｓなら、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５は、ＩＤ管理部２３に対して、ユーザ端末８のユーザＩＤを認証情報検証サーバ３用の流出検出用ユーザＩＤに変換する処理を実行させてから、Ｓ５１１へ進む。Ｓ５１０でＮｏならＳ５１４へ進む。
【００７４】
Ｓ５１１では、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５は、認証情報検証依頼部２６を呼び出す。認証情報検証依頼部２６は、検証要求を作成し、認証情報検証サーバ３へ送信することで問い合わせる（ケース２ではＳ３１４、ケース４ではＳ４１０の処理）。
認証情報検証依頼部２６は、認証情報検証サーバ３から検証応答を受信する（ケース２ではＳ３１６、ケース４ではＳ４１２の処理）。認証状態管理部２１は、検証応答内の検証結果が成功か否かを判定する（Ｓ５１２）。Ｓ５１２でＹｅｓならＳ５１３へ進み、ＮｏならＳ５１４へ進む。
Ｓ５１３では、認証状態管理部２１は、認証状態テーブル２７にユーザ端末８の認証状態に関するレコードを追加することで、ユーザ端末８の認証状態を更新する。
【００７５】
認証状態管理部２１は、認証を依頼した各認証サーバ４から、認証結果が全て戻ってきたか否かを判定する（Ｓ５１４）。Ｓ５１４でＹｅｓなら、認証状態管理部２１は、内部状態をリセットし（Ｓ５１５）、認証回数カウンタの値を１増やし（Ｓ５１６）、Ｓ５０４へ進む。Ｓ５１４でＮｏなら、終了する。
【００７６】
Ｓ５１８として、認証状態管理部２１は、メモリ上に格納された認証回数カウンタが規定値（例えば３回）以上であるか否かを判定する。Ｓ５１８でＹｅｓならＳ５１９へ進み、ＮｏならＳ５２０へ進む。
Ｓ５１９では、認証状態管理部２１は、認可判定結果（不認可）を作成し、終了する。
【００７７】
Ｓ５２０では、認可判定部２４は、不足している認証方式を算出する（Ｓ５２０）。Ｓ５２０として、例えば、ポリシ「１回の電子証明書認証と、２回のパスワード認証」に対して、現在のユーザ認証状態「第１パスワード認証」であるときには、不足分の認証は、「１回の電子証明書認証と、１回のパスワード認証」である。
Ｓ５２１として、ロケーション管理部２２は、不足している認証方式のうち最も対応サービス数の多い認証サーバ４（既に認証結果を取得した認証サーバ４を除外）のＵＲＬを取得する。
Ｓ５２２として、ＩＤ管理部２３は、ユーザ端末８から取得したユーザＩＤを、Ｓ５２１で決定した認証サーバ４用のユーザＩＤ（例えば、第１ユーザＩＤ）に変換する。
Ｓ５２３として、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５は、転送応答を作成して、ユーザ端末８へ送信して認証依頼するとともに（ケース１ではＳ３０５、ケース３ではＳ４０５の処理）、Ｓ５０３で判定される内部状態の値を認証結果待ちと設定する（Ｓ５２４）。
【００７８】
図７は、図４および図５の処理における認証情報検証サーバ３の動作を示すフローチャートである。このフローチャートの概要は、認証情報検証サーバ３は、検証要求（図６の説明でのケース２ではＳ３１４で送信、図６の説明でのケース４ではＳ４１０で送信）への検証処理を実行し（ケース２ではＳ３１５で実行、ケース４ではＳ４１１で実行）、その結果を検証応答（ケース２ではＳ３１６で送信、ケース４ではＳ４１２で送信）として送信する処理である。
【００７９】
通信部３３は、認証連携サーバ２から検証要求を受信し（Ｓ６０１）、その検証要求内のメッセージパラメータを取得する（Ｓ６０２）。
・Ｓ６０１の検証要求として、ケース２の場合は、「認証結果Ａ２、流用検出用ユーザＩＤ、第２秘匿認証情報、第２認証情報プロパティ」というメッセージパラメータが取得される（表７参照）。
・Ｓ６０１の検証要求として、ケース４の場合は、「認証結果Ａ３、流用検出用ユーザＩＤ、第１秘匿認証情報、第１認証情報プロパティ」というメッセージパラメータが取得される（表８参照）。
【００８０】
流用検出管理部３１は、Ｓ６０２で取得した流用検出用ユーザＩＤを検索キーとして流用検出用テーブル３４から検索し、該当するレコードの秘匿認証情報列に格納されている秘匿認証情報を検索結果として取得する（Ｓ６０３）。そして、流用検出管理部３１は、Ｓ６０２で取得した秘匿認証情報と、Ｓ６０３で取得した秘匿認証情報とを照合することで、検証要求内の秘匿認証情報が流用検出用テーブル３４内に存在するか否かを判定する（Ｓ６０４）。このＳ６０４の判定処理は、換言すると、同じユーザによる同じ認証情報の流用の有無を判定する処理である。
【００８１】
Ｓ６０４でＹｅｓなら、Ｓ６０５へ進み、Ｓ６０４でＮｏなら、Ｓ６１０へ進む。
・Ｓ６０４の判定結果として、ケース２の場合は、Ｓ６０２で取得した「第２秘匿認証情報」が、Ｓ６０３で取得した秘匿認証情報「第０秘匿認証情報」内には存在しないので、Ｓ６０４でＮｏである。
・Ｓ６０４の判定結果として、ケース４の場合は、Ｓ６０２で取得した「第１秘匿認証情報」が、Ｓ６０３で取得した秘匿認証情報「第０秘匿認証情報、第２秘匿認証情報」内には存在しないので、Ｓ６０４でＮｏである。
Ｓ６０５として、流用検出管理部３１は、検証結果（脆弱を示す「vulnerable」）を作成し、Ｓ６１６へ進む。
【００８２】
Ｓ６１０では、流用検出管理部３１は、流用検出用テーブル３４に、Ｓ６０２で取得したメッセージパラメータに関するレコード（秘匿認証結果）を追加する。
・Ｓ６１０の追加処理として、ケース２の場合は、Ｓ６０２で取得した「第２秘匿認証情報」が流用検出用テーブル３４に追加された結果、流用検出用テーブル３４の秘匿認証情報は、「第０秘匿認証情報、第２秘匿認証情報」へと更新される。
・Ｓ６１０の追加処理として、ケース４の場合は、Ｓ６０２で取得した「第１秘匿認証情報」が流用検出用テーブル３４に追加された結果、流用検出用テーブル３４の秘匿認証情報は、「第０秘匿認証情報、第１秘匿認証情報、第２秘匿認証情報」へと更新される。
【００８３】
認証情報検証部３２は、Ｓ６０２で取得した認証情報プロパティから認証情報の脆弱度を計算する（Ｓ６１１）。そのため、まず、認証情報がパスワードであるときには、その文字列の長さ、使用している文字の種類、などの特徴ごとに脆弱値を計算し、それらの脆弱値の合計を脆弱度として算出する。
認証情報検証部３２は、Ｓ６１１で算出した脆弱度が閾値を超えているか否か（脆弱度≦閾値）を判定する（Ｓ６１２）。Ｓ６１２でＹｅｓならＳ６１３へ進み、ＮｏならＳ６０５へ進む。
【００８４】
Ｓ６１３として、認証情報検証部３２は、検証結果（非脆弱を示す「invulnerable」）を作成する。
Ｓ６１６として、通信部３３は、Ｓ６０５またはＳ６１３で作成した検証結果を含む検証応答を作成し、認証連携サーバ２へ送信する。なお、Ｓ６１６として、ケース２の場合は、Ｓ３１６の検証応答が送信され、ケース４の場合は、Ｓ４１２の検証応答が送信される。
【００８５】
以上、第１実施形態で説明した認証連携システムでは、認証情報検証サーバ３が第１秘匿認証情報と第２秘匿認証情報とを照合することによって、同じユーザによって使用される２つの認証情報（第１認証情報、第２認証情報）間の流用を検証する。これにより、流用が検知された脆弱な認証情報によるユーザ認証を無効にすることで、複数のユーザ認証の結果を組み合わせて用いるときに、セキュリティ強度の低下を防止することができる。
【００８６】
以下、第２実施形態について、説明する。第２実施形態は、複数のシングルサインオンシステムを連携させる形態である。
【００８７】
図８は、第２実施形態の認証サーバ連携システムの構成図である。認証サーバ連携システムは、ドメインをまたがったシングルサインオンを提供する形態である。
ユーザ端末８が認証サーバ４に対して認証を行うときに、そのユーザ端末８と認証サーバ４とが異なるドメインに属している場合、ユーザ端末８が属するドメインの認証プロキシサーバ６が、そのユーザ端末８を代行して他ドメインの認証サーバ４と認証を行う。
以下、ユーザ端末８がドメインＡ（ネットワーク５ａ）に属し、認証サーバ４がドメインＢ（ネットワーク５ｂ）に属している例を示す。認証サーバ４ｂとの認証に成功したユーザ端末８は、ドメインＢ内のアプリケーションサーバ１からサービスを受けることができる。
【００８８】
第１実施形態と第２実施形態とで共通する構成については、同じ符号を付し、説明を省略する。また、第１実施形態と同様に、以下の説明では、図１と同様に、２つのドメインで同じ構成要素が存在するときには、その構成要素の符号末尾の「ａ，ｂ」が所属するドメインを示す。第１実施形態と第２実施形態とを比較すると、以下のように構成の（相違点１）〜（相違点３）がある。
【００８９】
（相違点１）として、アプリケーションサーバ１の接続先を、ドメインＡからドメインＢに変更する。
【００９０】
（相違点２）として、認証情報検証サーバ３を省略する。さらに、認証連携サーバ２内の認証連携サーバ２と通信するための認証情報検証依頼部２６も併せて省略する。
よって、第１実施形態で記載されていた認証連携サーバ２による検証処理は、第２実施形態では、省略される。具体的には、検証要求（Ｓ３１４，Ｓ４１０）→検証処理（Ｓ３１５，Ｓ４１１）→検証応答（Ｓ３１６，Ｓ４１２）を省略するとともに、Ｓ５０２に含まれる認証結果が成功であるときには（Ｓ５１０，Ｙｅｓ）、検証要求を行うことなく（Ｓ５１１，Ｓ５１２の省略）、その認証結果をユーザの認証状態として更新する（Ｓ５１３）。
【００９１】
（相違点３）として、認証プロキシサーバ６を新たにドメインＡに追加する。なお、認証プロキシサーバ６は、ドメインＡに１台配置される構成の他に、ドメインごとに１台ずつ配置されていてもよいし、認証プロキシサーバ６と認証連携サーバ２とが同じ筐体内に配備されていてもよい。
【００９２】
図９は、第２実施形態の認証サーバ連携システムを構成する各装置の構成図である。第１実施形態と同じ構成の装置については、図示を省略する。
【００９３】
認証プロキシサーバ６は、ネットワーク５ａからネットワーク５ｂへのアクセスを制御することで、ユーザ端末８の代理としてネットワーク５ｂ上でユーザ認証を実施する。
このため、認証プロキシサーバ６は、ＳＡＭＬ  ＳＰ部６１と、認証情報連携部６２と、ＳＡＭＬ  ＥＣＰ部６３と、認証連携テーブル６４とを有する。
ＳＡＭＬ  ＳＰ部６１は、認証連携サーバ２から認可判定結果を取得し、ネットワーク５ａからネットワーク５ｂへのアクセスを制御する。
認証情報連携部６２は、認証連携サーバ２から認証結果や秘匿認証情報を取得し、ネットワーク５ｂにおけるユーザ認証でそれらを使用する。
ＳＡＭＬ  ＥＣＰ部６３は、ユーザ端末８に代わりネットワーク５ｂ上でのユーザ認証を実施する。
【００９４】
さらに、認証連携サーバ２に対して、認証情報提供部７６を新たに追加する。この認証情報提供部７６は、認証サーバ４が発行した認証結果や秘匿認証情報を認証プロキシサーバ６へ送信する。
【００９５】
【表９】
2012212211.tif 000011
【００９６】
表９に示す認証連携テーブル６４には、アクセス制御に必要な情報やネットワーク５ｂ上でのユーザ認証で使用する情報として、ユーザＩＤと、アプリケーションサーバ１のＵＲＬと、認証連携と、提供種別と、認証方式と、認可判定結果との対応情報が格納される。
項目「ユーザＩＤ」は、アプリケーションサーバ１を利用する際に使用するユーザＩＤを格納する。
項目「アプリケーションサーバＵＲＬ」は、アプリケーションサーバ１のＵＲＬを格納する。
項目「認証連携有無」は、ネットワーク５ａ上の認証サーバ４における認証結果や認証サーバ４ａに登録されている認証情報を、別のネットワーク上の認証サーバ４に提供するか否かを示すフラグを格納する。
項目「提供種別」は、別のネットワーク上の認証サーバ４に対して提供する情報の種類（認証情報/認証結果）を格納する。
項目「認証方式」は、アプリケーションサーバ１が要求するユーザ認証の認証方式を格納する。
項目「認可判定結果」は、認証連携サーバ２ａが発行した認可判定結果を格納する。
【００９７】
【表１０】
2012212211.tif 000012
【００９８】
表１０は、第２実施形態での説明用パラメータ例を示す。表１と比較すると、第１ユーザＩＤおよび第２ユーザＩＤそれぞれの認証情報とその秘匿認証情報が、表１では互いに異なるデータであるのに対し、表１０では互いに同じデータである。
つまり、第１実施形態では、双方の秘匿認証情報が不一致であることが望ましい（同一ユーザについて認証情報の流用を行っていない）のに対し、第２実施形態では、双方の秘匿認証情報が一致であることが望ましい（同一ユーザが複数のドメインについて、それぞれ認証に成功する）。
さらに、第２実施形態では、認証プロキシサーバ６の外部記憶装置には、認証サーバ４ａの第１公開鍵証明書、および、認証サーバ４ｂの第２公開鍵証明書が、それぞれ保管されている。
【００９９】
認証プロキシサーバ６は、以下の（手順１）〜（手順３）で、ユーザ端末８がアプリケーションサーバ１のサービスを利用できるように制御する（図８参照）。これにより、ユーザ端末８は、自らの認証情報を認証サーバ４ｂに入力しなくても済む。
（手順１）ネットワーク５ａ（ユーザ端末８）からネットワーク５ｂ（アプリケーションサーバ１）へのアクセス（サービス利用）において、ユーザ認証が必要と判断する。
（手順２）認証連携サーバ２ａおよび認証サーバ４ａと連携してユーザ認証を実施する。
（手順３）認証サーバ４ａから取得した秘匿認証情報を認証サーバ４ｂへ提示することにより、ネットワーク５ｂ上で、ユーザ端末８に代わり認証サーバ４ｂとの間でユーザ認証を実施する。
【０１００】
【表１１】
2012212211.tif 000013
【０１０１】
表１１は、第２実施形態でやりとりされる通信メッセージ種別のリストを示す。
【０１０２】
表１１の１行目に示される秘匿認証情報要求は、<assertionRequest>〜</assertionRequest>内に、以下の順序でタグが列挙されて構成される。
<samlp:ArtifactResolve>「チケット格納データ（認証連携サーバ２が発行した認証チケットを含む）」</samlp:ArtifactResolve>
<pkCertificate>「認証サーバ４の公開鍵証明書」</pkCertificate>
ここで、認証チケットとは、例えば、ＳＡＭＬ２．０で規定されたアーティファクトであり、その認証チケットごとにあらかじめ対応付けされているチケット対応データ（ユーザ端末８の認証情報など）の取得処理に使用される。
また、表１１の３行目に示される秘匿化要求は、<credentialRequest>〜</credentialRequest>内に、秘匿認証情報要求と同じデータ（チケット格納データ、公開鍵証明書）が含まれる。
【０１０３】
表１１の４行目に示される秘匿化応答は、<credentialResponse>〜</credentialResponse>内に、以下の順序でタグが列挙されて構成される。
<result>「秘匿認証情報の取得に成功したか否かを示す情報（成功なら「success」、失敗なら「fail」）」</result>
<credential>「秘匿認証情報」</credential>
【０１０４】
表１１の２行目に示される秘匿認証情報応答は、<assertionResponse>〜</assertionResponse>内に、以下の順序でタグが列挙されて構成される。
<result>「秘匿認証情報の取得に成功したか否かを示す情報（成功なら「success」、失敗なら「fail」）」</result>
<type>「下記のcredentialタグ内に含まれる情報の種類（認証結果を示す「assertion」または秘匿認証情報を示す「credential」）」</type>
<credential>「認証結果または秘匿認証情報」</credential>
【０１０５】
図１０は、第２実施形態におけるドメインＡ側で開始される処理を示すフローチャートである。このフローチャートの開始時点では、表９の認証連携テーブル６４内のユーザＩＤ「taro」の認可判定結果は、記載されていない。ユーザＩＤ「taro」とは、アプリケーションサーバ１が提供するサービス用のユーザＩＤである。
【０１０６】
【表１２】
2012212211.tif 000014
【０１０７】
表１２は、後記する図１０での各ステップごとの通信メッセージの内容（種別、クエリ、セッションＩＤ）を示す。
【０１０８】
Ｓ９０１として、ユーザ端末８のＷｅｂブラウザ８１は、ユーザ端末８のユーザからの操作を受け付けて作成した処理要求を認証プロキシサーバ６に送信する。
Ｓ９０２として、認証プロキシサーバ６のＳＡＭＬ  ＳＰ部６１は、転送応答をユーザ端末８に送信する。
Ｓ９０３として、Ｗｅｂブラウザ８１は、処理要求を認証連携サーバ２ａに送信する。
Ｓ９０４として、認証連携サーバ２ａのＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ａは、Ｓ３０４と同様にして、呼び出す認証サーバ４ａを決定する。
Ｓ９０５として、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ａは、転送応答をユーザ端末８に送信する。
【０１０９】
Ｓ９０６として、Ｗｅｂブラウザ８１は、処理要求を認証サーバ４ａに送信する。
Ｓ９０７として、認証サーバ４ａの認証部４３ａは、ユーザ端末８から認証情報を取得し、ユーザ認証を実施する。ユーザ認証では、認証情報テーブル４５ａから、第１ユーザＩＤと、対応する認証情報（ユーザ端末８から取得）との組み合わせのレコードが発見できたときに、認証成功とする。
Ｓ９０８として、ＳＡＭＬ  ＩｄＰ部４４ａは、転送応答（認証結果Ａ１、認証チケットＴ１、第１ユーザＩＤを含む）をユーザ端末８に送信する。認証結果Ａ１とは、ＳＡＭＬ２．０で規定された認証アサーションである。認証チケットＴ１とは、ＳＡＭＬ２．０で規定されたアーティファクトである。認証部４３ａは、認証チケットＴ１とユーザ端末８の認証情報とを結び付けて、メモリへ一時保存する。
【０１１０】
Ｓ９０９として、Ｗｅｂブラウザ８１は、処理要求を認証連携サーバ２ａに送信する。ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ａは、ユーザ端末８から処理要求を受信すると、第１実施形態におけるＳ３１７やＳ４１３と同様に、認証プロキシサーバ６に対する認可判定結果（認可）を生成する。また、認証情報連携部６２ａは、ＳＡＭＬ２．０で規定されたアーティファクトを認証チケットＴ２として生成すると共に、メモリへ認証チケットＴ２と認証サーバ４ａが発行した認証結果とを結び付けて一時保存する。
【０１１１】
Ｓ９１０として、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ａは、転送応答をユーザ端末８に送信する。
Ｓ９１１として、Ｗｅｂブラウザ８１は、処理要求を認証プロキシサーバ６に送信する。ＳＡＭＬ  ＳＰ部６１は、その処理要求を受信し、メッセージパラメータを取得して、メモリへ保存する。
Ｓ９１２として、ＳＡＭＬ  ＳＰ部６１は、ドメインＢへのサービス要求をネットワーク５ｂに送信し、アプリケーションサーバ１からサービスの実行結果であるサービスコンテンツを取得する。
Ｓ９１３として、ＳＡＭＬ  ＳＰ部６１は、成功応答をユーザ端末８に送信する。Ｗｅｂブラウザ８１は、受信した成功応答内のサービスコンテンツを処理し、ユーザ端末８の画面に表示する。
【０１１２】
図１１は、第２実施形態におけるドメインＢへのサービス要求（Ｓ９１２）を契機に、ドメインＢ側で開始される処理を示すフローチャートである。
【０１１３】
【表１３】
2012212211.tif 000015
【０１１４】
表１３は、後記する図１１での各ステップごとの通信メッセージの内容（種別、クエリ、セッションＩＤ）を示す。
【０１１５】
Ｓ１００１として、ＳＡＭＬ  ＥＣＰ部６３は、処理要求をアプリケーションサーバ１に送信する。
Ｓ１００２として、ＳＡＭＬ  ＳＰ部１１は、ユーザＩＤおよびその認可判定結果がアクセステーブル１３には登録されていない（つまり、ユーザ端末８が認証済ではない）ことを確認すると、転送応答を認証プロキシサーバ６に送信する。
Ｓ１００３として、ＳＡＭＬ  ＥＣＰ部６３は、処理要求を認証連携サーバ２に送信する。
Ｓ１００４として、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ｂは、Ｓ４０４と同様にして、呼び出す認証サーバ４ｂを決定する。
Ｓ１００５として、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ｂは、転送応答を認証プロキシサーバ６に送信する。
【０１１６】
認証情報連携部６２は、Ｓ１００５の転送応答を受信すると、認証連携テーブル６４のうち、ユーザＩＤおよびアプリケーションサーバ１のＵＲＬが格納されている行について、認証連携有無レコードのセルが「有」、かつ提供種別レコードのセルが「認証情報」であるか否かを判定する。このＳ１００５の受信時には、認証連携テーブル６４に該当する行が存在する（判定がＹｅｓ）なので、認証情報連携部６２は、認証プロキシサーバ６の外部記憶装置に保存されている、認証サーバ４ｂの公開鍵証明書を取得する。
ＳＡＭＬ  ＳＰ部６１は認証チケットＴ２を含めたＳＡＭＬ２．０ Artifact Resolution Protocolのチケット格納データを作成する。
【０１１７】
Ｓ１００６として、ＳＡＭＬ  ＳＰ部６１は、秘匿認証情報要求（作成したチケット格納データを含む）を認証連携サーバ２ａに送信する。
ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ａは、受信した秘匿認証情報要求に公開鍵証明書が含まれていることを解析すると、認証サーバ４ａから取得した認証チケットＴ１を含めたチケット格納データを作成する。
一方、秘匿認証情報要求に公開鍵証明書が含まれていない場合、認証情報連携部６２ａは、認証チケット２に結び付けてメモリに一次保存している認証結果を取得し、認証プロキシサーバ６へ返信する。
【０１１８】
Ｓ１００７として、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ａは、秘匿化要求（作成したチケット格納データを含む）を認証サーバ４ａに送信する。
ＳＡＭＬ  ＩｄＰ部４４ａは、認証連携サーバ２ａから秘匿化要求を取得すると、認証チケットＴ１に結び付けてメモリに一次保存しているユーザ端末８の認証情報を取得する。
Ｓ１００８として、認証情報秘匿化部４２ａは、秘匿化要求に含まれる認証サーバ４ｂの公開鍵証明書内にある公開鍵を用い、ユーザ端末８の認証情報を暗号化することにより、秘匿認証情報を生成する。
【０１１９】
ＳＡＭＬ  ＩｄＰ部４４ａは、Ｓ１００８で作成された秘匿認証情報を含めたＳＡＭＬ２．０ Artifact Resolution Protocolのチケット対応データを作成する。
Ｓ１００９として、ＳＡＭＬ  ＩｄＰ部４４ａは、秘匿化応答（作成したチケット対応データを含む）を認証連携サーバ２ａに送信する。
【０１２０】
ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ａは、受信した秘匿化応答内の秘匿認証情報を含めたチケット対応データを新たに作成する。
Ｓ１０１０として、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ａは、秘匿認証情報応答（作成したチケット対応データを含む）を認証プロキシサーバ６に送信する。
Ｓ１０１１として、ＳＡＭＬ  ＳＰ部６１は、処理要求（ＳＡＭＬ  ＳＰ部６１が秘匿認証情報応答内のチケット対応データから取得した秘匿認証情報を含む）を認証サーバ４ｂに送信する。
【０１２１】
Ｓ１０１２として、認証部４３ｂは、認証プロキシサーバ６から取得した秘匿認証情報を認証サーバ４ｂの秘密鍵を用いて復号し、得られた認証情報を用いてユーザ認証を実施する。認証情報テーブル４５ａに登録されているユーザ端末８の認証情報（パスワード）と、秘匿認証情報を復号して得られた認証情報（パスワード）とが同じであるときには、ユーザ認証に成功する。認証部４３ｂは、認証に成功したときには、認証結果Ａ２を含める認証アサーションを作成する。
【０１２２】
Ｓ１０１３として、ＳＡＭＬ  ＩｄＰ部４４ｂは、転送応答を認証プロキシサーバ６に送信する。
Ｓ１０１４として、ＳＡＭＬ  ＥＣＰ部６３は、処理要求を認証連携サーバ２に送信する。
Ｓ１０１５として、Ｓ３１７やＳ４１３と同様に、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ｂは、認可判定を実施する。
Ｓ１０１６として、ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部２５ｂは、転送応答を認証プロキシサーバ６に送信する。
Ｓ１０１７として、ＳＡＭＬ  ＥＣＰ部６３は、処理要求をアプリケーションサーバ１に送信する。
Ｓ１０１８として、ＳＡＭＬ  ＳＰ部１１は、成功応答（Ｗｅｂサーバ１２がＳ１０１７の処理要求に含まれるサービス実行パラメータから作成したサービスコンテンツを含む）を認証プロキシサーバ６に送信する。
ＳＡＭＬ  ＥＣＰ部６３は、アプリケーションサーバ１から成功応答を受信すると、その成功応答内のサービスコンテンツを含めて成功応答を生成し、ユーザ端末８へ送信する（Ｓ９１３）。
【０１２３】
なお、Ｓ９０１〜Ｓ９１２を実行した後で、Ｓ１００１を開始する代わりに、以下の（手順１）〜（手順４）を順に実行してもよい。
（手順１）Ｓ９０１を実行
（手順２）Ｓ１００１からＳ１００５までを実行
（手順３）Ｓ９０２からＳ９１１までを実行
（手順４）Ｓ１００６以降を実行
【０１２４】
図１２は、ＳＡＭＬ  ＳＰ部６１が実行する各処理を示すフローチャートである。この図１２の説明では、動作主体がすべてＳＡＭＬ  ＳＰ部６１であるので、その旨を各処理の説明から省略する。
以下に示すように、ＳＡＭＬ  ＳＰ部６１は、Ｓ１１０１〜Ｓ１１０７を実行することで、Ｓ９０１の処理要求の受信を契機にアクセス制御が必要か否かを判定し、必要であれば認可判定結果を認証連携サーバ２から要求し、取得した認可判定結果を基にアクセス制御を実施する。
【０１２５】
Ｓ１１０１では、ユーザ端末８からＳ９０１の処理要求を受信する。
Ｓ１１０２では、処理要求内で指定されるユーザＩＤ「taro」およびアプリケーションサーバ１のＵＲＬ「http://demosite2.com/sp1/」の組み合わせのレコードが、認証連携テーブル６４内に登録されているか否かを判定する（Ｓ１１０２）。Ｓ１１０２でＹｅｓならＳ１１０３へ進み、ＮｏならＳ１１０５へ進む。
【０１２６】
Ｓ１１０３では、Ｓ１１０２で検索したレコード内に、認可判定結果が存在するか否かを判定する。Ｓ１１０３でＹｅｓならＳ１１０４へ進み、ＮｏならＳ１１０７へ進む。
Ｓ１１０４では、Ｓ１１０３で判定した認可判定結果が認可「OK」か否かを判定する。Ｓ１１０４でＹｅｓならＳ１１０５へ進み、ＮｏならＳ１１０６へ進む。
Ｓ１１０５では、処理要求をアプリケーションサーバ１へ送信する。
Ｓ１１０６では、認証失敗を示す禁止応答をユーザ端末８へ送信する。
【０１２７】
Ｓ１１０７では、認可判定結果がユーザ端末８から受信したメッセージに添付されているか否かを判定する。Ｓ１１０７でＹｅｓならＳ１１０８へ進み、ＮｏならＳ１１１６へ進む。
Ｓ１１０８では、認可判定結果を認証連携テーブル６４へ登録する。
Ｓ１１０９では、認可判定結果は「OK（認可成功）」か否かを判定する。Ｓ１１０９でＹｅｓならＳ１１１０へ進み、ＮｏならＳ１１０６へ進む。
【０１２８】
Ｓ１１１０では、認証連携は「有？」か否かを判定する。Ｓ１１１０でＹｅｓならＳ１１１１へ進み、ＮｏならＳ１１１３へ進む。
Ｓ１１１１では、Ｓ１００６の秘匿認証情報要求を認証連携サーバ２ｂへ送信する。
Ｓ１１１２では、Ｓ１０１０の秘匿認証情報応答を認証連携サーバ２ｂから受信する。
Ｓ１１１３では、認証結果or認証情報（秘匿認証情報応答に含まれる）をメモリへ保存し、Ｓ１１０５へ進む。
Ｓ１１１６では、Ｓ９０２の転送応答を作成し、ユーザ端末８へ送信する。
【０１２９】
以上説明した第２実施形態でのシングルサインオンシステムでは、ドメインＡのシングルサインオンシステムが、別のドメインＢのシングルサインオンシステム内の認証サーバ４に対し、ユーザに代わりユーザの認証情報を送信し、認証サーバ４が認証情報を取得してユーザ認証を実施する。これにより、複数のシステムにまたがったシングルサインオンを実現する。
【０１３０】
一方、従来のシングルサインオンシステムは、同一ドメイン間での単一のシングルサインオンシステムとしての認証連携にとどまる。その原因は技術的制約、物理的制約、セキュリティポリシによる制約など様々である。この場合、ユーザは利用しているシングルサインオンシステムと連携しているサービスについては認証情報の入力操作および認証情報の管理による負担を軽減できるが、それ以外のサービスについてはシングルサインオンによる恩恵を受けることができない。また、ユーザが複数のシングルサインオンシステムを利用できるとしても、シングルサインオンシステムごとに認証情報の入力操作が必要となるため、シングルサインオンの適用前に存在したパスワード管理の問題が浮上する。
【０１３１】
ここで、シングルサインオンに関連して、ユーザがサービスごとに利用するＩＤや属性情報を一元的に管理し、必要に応じてサービスに提供するＩＤ管理技術が利用されつつある。特開２０１０−１１３４６２号公報には、ユーザＩＤやアサーションを含む、ユーザに関わる情報（ユーザのＩＤや属性情報）を、必要な相手にだけ安全に提供する方法が示されている。
しかし、特開２０１０−１１３４６２号公報には、第２実施形態のように、本人の信頼性の拠り所である認証情報を認証サーバ４から第三者へ提供する点は、記載されていない。
【符号の説明】
【０１３２】
１      アプリケーションサーバ
２      認証連携サーバ
３      認証情報検証サーバ
８      ユーザ端末
４      認証サーバ
５      ネットワーク
６      認証プロキシサーバ
１１    ＳＡＭＬ  ＳＰ部
１２    Ｗｅｂサーバ
１３    アクセステーブル
２１    認証状態管理部
２２    ロケーション管理部
２３    ＩＤ管理部
２４    認可判定部
２５    ＳＡＭＬ  ＩｄＰ  Ｐｒｏｘｙ部
２６    認証情報検証依頼部
２７    認証状態テーブル
２８    認証要求ポリシテーブル
２９    認証サーバリスト
３１    流用検出管理部
３２    認証情報検証部
３３    通信部
３４    流用検出用テーブル
４１    認証情報管理部
４２    認証情報秘匿化部
４３    認証部
４４    ＳＡＭＬ  ＩｄＰ部
４５    認証情報テーブル
６１    ＳＡＭＬ  ＳＰ部
６２    認証情報連携部
６３    ＳＡＭＬ  ＥＣＰ部
６４    認証連携テーブル
７６    認証情報提供部
８１    Ｗｅｂブラウザ
【図１】
2012212211.tif 000016
【図２】
2012212211.tif 000017
【図３】
2012212211.tif 000018
【図４】
2012212211.tif 000019
【図５】
2012212211.tif 000020
【図６】
2012212211.tif 000021
【図７】
2012212211.tif 000022
【図８】
2012212211.tif 000023
【図９】
2012212211.tif 000024
【図１０】
2012212211.tif 000025
【図１１】
2012212211.tif 000026
【図１２】
2012212211.tif 000027