"ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムであって、ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、前記認証サーバは、前記認証処理で扱う前記認証情報を入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報とその生成元である前記認証情報を使用する前記ユーザ端末のユーザを一意に特定するユーザIDとの組み合わせを複数組取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする認証連携システム。ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムであって、ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、前記認証サーバは、前記認証処理で扱う前記認証情報と、前記ユーザ端末のユーザを一意に特定するユーザIDとを入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報を複数個取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする認証連携システム。ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムであって、ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、前記認証サーバは、同じ前記ユーザ端末が複数の前記認証サーバとそれぞれセッションを確立するときに、そのセッションを識別するセッションIDとして、同じセッションIDを使用するものとし、前記認証処理で扱う前記認証情報と、セッションIDとを入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報を複数個取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする認証連携システム。前記認証サーバは、実行する前記認証処理の認証方式がパスワード認証または電子証明書認証であるときには、前記秘匿化演算処理として、入力値を引数とするハッシュ関数を呼び出すことで、前記秘匿認証情報を生成し、前記認証情報検証サーバは、流用が発生した複数の前記認証情報を抽出するための照合処理として、複数の前記秘匿認証情報の値が一致することにより、複数の前記認証情報間に流用が発生したと判定することを特徴とする請求項1ないし請求項3のいずれか1項に記載に認証連携システム。前記認証サーバは、実行する前記認証処理の認証方式が生体認証であるときには、前記秘匿化演算処理として、生体の前記認証情報および秘密鍵を入力とし、生体情報の相関を不変に変換する関数を呼び出すことで、前記秘匿認証情報を生成し、前記認証情報検証サーバは、流用が発生した複数の前記認証情報を抽出するための照合処理として、複数の前記秘匿認証情報間の類似度が所定値以上であるときに、複数の前記認証情報間に流用が発生したと判定することを特徴とする請求項1ないし請求項3のいずれか1項に記載に認証連携システム。ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムが実行する認証連携方法であって、前記認証連携システムは、ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、前記認証サーバは、前記認証処理で扱う前記認証情報を入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報とその生成元である前記認証情報を使用する前記ユーザ端末のユーザを一意に特定するユーザIDとの組み合わせを複数組取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする認証連携方法。ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムが実行する認証連携方法であって、前記認証連携システムは、ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、前記認証サーバは、前記認証処理で扱う前記認証情報と、前記ユーザ端末のユーザを一意に特定するユーザIDとを入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報を複数個取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする認証連携方法。ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムが実行する認証連携方法であって、前記認証連携システムは、ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、前記認証サーバは、同じ前記ユーザ端末が複数の前記認証サーバとそれぞれセッションを確立するときに、そのセッションを識別するセッションIDとして、同じセッションIDを使用するものとし、前記認証処理で扱う前記認証情報と、セッションIDとを入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報を複数個取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする認証連携方法。前記認証サーバは、実行する前記認証処理の認証方式がパスワード認証または電子証明書認証であるときには、前記秘匿化演算処理として、入力値を引数とするハッシュ関数を呼び出すことで、前記秘匿認証情報を生成し、前記認証情報検証サーバは、流用が発生した複数の前記認証情報を抽出するための照合処理として、複数の前記秘匿認証情報の値が一致することにより、複数の前記認証情報間に流用が発生したと判定することを特徴とする請求項6ないし請求項8のいずれか1項に記載に認証連携方法。前記認証サーバは、実行する前記認証処理の認証方式が生体認証であるときには、前記秘匿化演算処理として、生体の前記認証情報および秘密鍵を入力とし、生体情報の相関を不変に変換する関数を呼び出すことで、前記秘匿認証情報を生成し、前記認証情報検証サーバは、流用が発生した複数の前記認証情報を抽出するための照合処理として、複数の前記秘匿認証情報間の類似度が所定値以上であるときに、複数の前記認証情報間に流用が発生したと判定することを特徴とする請求項6ないし請求項8のいずれか1項に記載に認証連携方法。一方、オンラインバンキングや公的な手続きなど、高い安全性が求められるサービスでは、1つのサービスを受けるために、複数のユーザ認証の結果を組み合わせて用いるシステム形態多要素認証も考えられる。これにより、多要素認証のうちの1つのユーザ認証が不正な攻撃者によって成功したとしても、多要素認証のうちの他のユーザ認証が成功しない限り、サービスは許可されないため、セキュリティ強度を高めることができる。しかし、ユーザによっては、多要素認証で同じパスワードを使いまわす流用するなどにより、多要素認証それぞれのパスワード管理を横着してしまう場合もある。そのときには、1つのユーザ認証が攻撃者に解読されてしまうと、連鎖的に他のユーザ認証も解読されてしまい、多要素認証を用いたとしても、充分なセキュリティ強度を保証できない。そこで、本発明は、前記した問題を解決し、複数のユーザ認証の結果を組み合わせて用いるときに、セキュリティ強度の低下を防止することを、主な目的とする。前記課題を解決するために、本発明は、ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムであって、ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、前記認証サーバが、前記認証処理で扱う前記認証情報を入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、前記認証情報検証サーバが、前記認証サーバにより生成された前記秘匿認証情報とその生成元である前記認証情報を使用する前記ユーザ端末のユーザを一意に特定するユーザIDとの組み合わせを複数組取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、前記認証連携サーバが、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする。その他の手段は、後記する。本発明によれば、複数のユーザ認証の結果を組み合わせて用いるときに、セキュリティ強度の低下を防止することができる。以下、本発明の一実施形態を、図面を参照して詳細に説明する。図1は、認証連携システムの構成図である。認証連携システムは、2つのドメインA,B間がネットワーク5a,5bで接続されて構成される。ネットワーク5a,5bは、企業内LANLocalAreaNetworkのようなプライベートネットワークでも、インターネットのようなオープンネットワークでもよい。なお、以下の説明では、2つのドメインで同じ構成要素が存在するときには、その構成要素の符号末尾のa,bが所属するドメインを示す。例えば、認証連携サーバ2は、ドメインA内の認証連携サーバ2aと、ドメインB内の認証連携サーバ2bとがそれぞれ存在する。SAMLを用いる認証連携システムは、認証用の構成として、認証連携サーバ2a、認証連携サーバ2b、認証情報検証サーバ3、認証サーバ4b、認証サーバ4aを含む。さらに、その認証結果を利用する装置として、ユーザ端末8、アプリケーションサーバ1x、および、アプリケーションサーバ1yが存在する。ユーザ端末8は、認証連携システムの他装置との通信を行う装置であり、その通信を実施するWebブラウザ81を備えている。なお、これらの装置構成については、各装置が物理的に1台の筐体に収容されていてもよいし、複数の装置認証連携サーバ2や認証情報検証サーバ3などが物理的に1台の筐体に収容されていてもよい。以下、本実施形態で使用される各用語を定義する。表1は、認証チェック用パラメータを示す。この表の列要素は、ユーザ端末8を操作する人間であるユーザごとのパラメータと、認証サーバ4aごとのパラメータと、認証サーバ4bごとのパラメータとを示す。項目ユーザIDは、ユーザを識別するためのIDであり、ユーザごとのユーザ端末8ごとのユーザIDtaroの他に、そのユーザIDtaroが使用する認証サーバ4a上の第1ユーザIDtaroauth1と、同じユーザIDtaroが使用する認証サーバ4b上の第2ユーザIDtaroauth2とがそれぞれ登録される。なお、表1の各セル値の2行目以降の英数字表記taroなどは、各セル値の1行目で示すパラメータ名称ユーザIDの具体例である。項目流用検出用ユーザIDは、ユーザIDのハッシュ値として構成される。このように人間が可読なデータtaroから、そのハッシュ値を作成することにより、ハッシュ値がもともと意味する情報を残しつつ、攻撃者による盗み見を困難にする。項目認証情報は、認証サーバ4ごとのユーザIDに対応する認証用の入力情報である。認証方式がパスワード認証のときには、その認証情報がパスワード文字列である。認証方式が電子証明書認証のときには、その認証情報が電子証明書である。認証方式が生体認証のときには、その認証情報がユーザの生体から生体センサで測定された値をもとに生成される情報である。項目認証情報ハッシュ値は、項目流用検出用ユーザIDと同様に、認証情報をハッシュ化することにより、難読性を高める。第1認証情報から第1ハッシュ値が生成され、第2認証情報から第2ハッシュ値が生成される。項目秘匿認証情報は、認証情報またはその認証情報ハッシュ値を入力データとして、秘匿化演算を行うことにより生成されるパラメータである。秘匿化演算は、認証方式により規定される。認証方式がパスワード認証または電子証明書認証のときには、秘匿化演算として一方向性関数sha1やMD5などのハッシュ関数の計算結果が秘匿認証情報である。そして、生成された第1秘匿認証情報と第2秘匿認証情報とが一致するときに、同じユーザが複数の認証情報として同じデータを用いていることにより、第1認証情報と第2認証情報が脆弱な認証情報として検出される。認証方式が生体認証のときには、秘匿化演算生体情報の相関不変な一方向性変換処理の計算結果が秘匿認証情報である。なお、一方向性変換処理には、変換用の秘密鍵認証サーバ4の秘密鍵に流出検出用ユーザIDを加えた文字列が使用される。そして、生成された第1秘匿認証情報と第2秘匿認証情報との画像処理における類似度が所定値以上であるときに、同じユーザが複数の認証情報として同じデータを用いていることにより、第1認証情報と第2認証情報が脆弱な認証情報として検出される。このように、生成された秘匿認証情報は、通信メッセージに含められ、装置間で伝達される。ユーザのIDや属性情報といったプライバシ情報を別のサービスへ提供するときに、ユーザ認証に使用するパスワードなどの認証情報については特に第三者に漏れないように注意する必要がある。認証情報ハッシュ値が認証サーバ上で管理されている場合、第三者には内容が分からないようになっていたとしても、第三者はこの状態の認証情報を認証サーバ4に送りつけることで、認証情報の所有者になりすましてユーザ認証を成功させてしまう。そこで、認証情報を外部へ提供する際に、認証情報や認証情報ハッシュ値の代わりに、表1の秘匿認証情報を提供する。これにより、その秘匿認証情報を第三者が取得したとしても、その秘匿認証情報から認証サーバ4の管理する認証情報を得られず、認証情報の所有者へのなりすましを防止できる。表2は、表1で定義した各パラメータをもとにした、4種類の認証チェック項目認可、認証、流用検証、単体検証を示す。表2の2行目に示す認証は、認証サーバ4ごとに、入力された認証情報をもとに、そのユーザが正当か否かを認証する処理であり、その認証に成功したときには、認証アサーションが発行される。表2の1行目に示す認可は、発行された認証アサーションで示されるユーザ認証状態が、サービスに要するポリシを満たしているときに、サービスの実行を認可する。この認可について、1つのサービスを受けるために、複数の認証アサーションを要するポリシとしてもよいし、複数のサービスを受けるために必要な認証アサーションを、サービス間で共有するポリシとしてもよい。表2の4行目に示す単体検証は、認証で使用される認証情報を単体としてみたときに、他者に攻撃されやすい認証情報を用いているか否かを検証する処理である。なお、認可で使用される認証アサーションは、単体検証に合格した認証アサーションだけを認可で使用することで、セキュリティ強度を向上できる。表2の3行目に示す流用検証は、認証で使用される同じユーザによる複数の認証情報として、同じデータを使い回しているか否かを検証する処理である。流用検証に合格した認証アサーションだけを認可で使用することで、セキュリティ強度を向上できる。図2は、認証連携システムを構成する各装置の詳細を示す構成図である。なお、以下の説明では、図1と同様に、2つのドメインで同じ構成要素が存在するときには、その構成要素の符号末尾のa,bが所属するドメインを示す。例えば、認証状態管理部21aは、ドメインA内の認証連携サーバ2aに含まれ、認証状態管理部21bは、ドメインB内の認証連携サーバ2bに含まれる。アプリケーションサーバ1は、ユーザ端末8からの処理要求を受信し、認証連携サーバ2から認可がでたときに、その処理要求に対応するサービスコンテンツをユーザ端末8へ提供する装置である。なお、図2では、2台のアプリケーションサーバ1x,1yを例示しており、以下のフローチャートなどの説明で、どちらのアプリケーションサーバ1内の構成要素かを示すために、アプリケーションサーバ1内の構成要素を示す符号の末尾にxまたはyを付加する。アプリケーションサーバ1は、ユーザ端末8との間で通信を実施し、認可判定結果に基づきアクセス制御を実施するSAMLSP部11、ユーザ端末8からのサービス実行パラメータに基づきサービスを実行し、サービスコンテンツをユーザ端末8へ提示したりするWebサーバ12、およびアクセス制御に使用する認可判定結果を格納するアクセステーブル13を備えている。認証連携サーバ2は、ネットワーク5単位で存在し、ユーザ端末8からの処理要求の受信を契機に、認証サーバ4からの認証結果に基づいてユーザ端末8に対するアプリケーションサーバ1へのアクセス認可の可否を判定する装置である。どの認証サーバ4から認証結果を取得するかは、認証連携サーバ2が選択して決定し、ユーザ端末8へ認証の実施を促す。このため、認証連携サーバ2は、認証状態管理部21と、ロケーション管理部22と、ID管理部23と、認可判定部24と、SAMLIdPProxy部25と、認証情報検証依頼部26と、認証状態テーブル27と、認証要求ポリシテーブル28と、認証サーバリスト29とを備えている。認証状態管理部21は、ユーザ端末8の認証状態およびアプリケーションサーバ1のポリシを管理する。ロケーション管理部22は、連携する認証サーバ4のURLを管理する。ID管理部23は、アプリケーションサーバ1上で使用するユーザIDと各々の認証サーバ上で使用するユーザIDを結び付けて管理する。認可判定部24は、ユーザ端末8の認証状態とアプリケーションサーバ1のポリシを比較することによりアプリケーションサーバ1へのアクセス可否を判定する。SAMLIdPProxy部25は、ユーザ端末8との通信を実施し他の認証連携サーバ2や認証サーバ4に対しユーザ認証処理を依頼する。認証情報検証依頼部26は、認証情報検証サーバ3との通信を実施し、認証情報検証サーバ3に対し認証情報の脆弱度判定を依頼する。認証状態テーブル27は、ユーザ端末8の認証状態を格納する。認証要求ポリシテーブル28は、アプリケーションサーバ1のポリシを格納する。認証サーバリスト29は、連携する認証サーバ4のURLを格納する。認証情報検証サーバ3は、ドメイン単位で存在し、認証連携サーバ2から取得した秘匿認証情報および認証情報プロパティにより、ユーザが認証に使用した認証情報が脆弱でないか検証表2の流用検証、単体検証するための装置である。なお、認証情報プロパティとは、認証情報が所有する特徴を集めたリストである。特徴の例としては、パスワードの長さやパスワードに使用した文字の種別英字、数字、記号などが挙げられる。このため、認証情報検証サーバ3は、流用検出管理部31と、認証情報検証部32と、通信部33と、流用検出用テーブル34とを備えている。流用検出管理部31は、脆弱度判定の結果脆弱でないと判定した秘匿認証情報を管理する。認証情報検証部32は、認証連携サーバ2から取得した秘匿認証情報、認証プロパティおよび後記の流用検出用テーブル34に格納されている秘匿認証情報を基に、ユーザが認証に使用した認証情報が脆弱でないか検証する。通信部33は、認証連携サーバ2との間の通信を実施する。流用検出用テーブル34は、認証連携サーバ2から取得した秘匿認証情報を格納する。認証サーバ4は、ドメイン単位で存在し、ユーザ端末8との間でユーザ認証を実施し、認証結果および認証を実施したユーザの秘匿認証情報、および認証プロパティを認証連携サーバ経由で認証情報検証サーバ3へ提供する装置である。このため、認証サーバ4は、認証情報管理部41と、認証情報秘匿化部42と、認証部43と、SAMLIdP部44と、認証情報テーブル45とを備えている。認証情報管理部41は、ユーザの認証情報を管理する。認証情報秘匿化部42は、ユーザの認証情報から秘匿認証情報および認証プロパティを生成する。認証部43は、ユーザ端末8から取得した認証情報と、後記の認証情報テーブル45に格納されている認証情報とを照合することによりユーザ認証を実施する。SAMLIdP部44は、ユーザ端末8との通信を実施し、認証結果をユーザ端末8経由で認証連携サーバ2へ送信する。認証情報テーブル45は、ユーザの認証情報を格納する。なお、複数の秘匿認証情報間の照合処理表2の流用検証において、<認証情報に対応するユーザ、認証情報から生成された秘匿認証情報>の組み合わせが一致する複数の組が存在したときに、同一の認証情報の流用検出を行うこととしたが、流用検出用の照合対象として、この組み合わせのデータ以外にも、<ユーザを特定できる情報と、そのユーザの認証情報を特定できる情報>であれば、他のデータを用いてもよい。例えば、以下の手順1~3により、<ユーザを特定できる情報と、そのユーザの認証情報を特定できる情報>を生成してもよい。手順1ユーザを特定できる情報として、ユーザID、または、そのユーザが使用するユーザ端末8と認証サーバ4との間で共有するセッションIDを一時ユーザIDとする。なお、セッションIDとは、メッセージの送受信により取得したパラメータを管理する際に必要となるIDである。手順2前記手順1で取得したユーザを特定できる情報と認証情報との文字をコロンなどの接続用文字列で連結した文字列を生成する。手順3前記手順2で生成した文字列に対して、認証情報秘匿化部42が秘匿化処理を行うことで、ユーザを特定できる情報を含む秘匿認証情報を生成する。なお、手順1において、ある認証サーバ4で生成したセッションIDを、別の認証サーバ4でも使用することにより、セッションIDがユーザを特定できるユーザIDの代替データ一時ユーザIDとしての役割を果たす。そのため、ユーザ端末8は新たに認証サーバ4との間でセッションを確立する前に、その確立先とは別の認証サーバ4によって既に生成されたセッションIDを新たなセッションでも使用するように、ユーザ端末8から認証サーバ4への処理要求内Setcookieヘッダに既に生成されたセッションIDを含めることとする。そして、以下の手順4により、複数の秘匿認証情報間の照合処理を実施する。手順4前記手順3で生成された秘匿認証情報どうしを認証情報検証部32が照合し、一致する秘匿認証情報を検出したときに、同一ユーザによる認証情報の流用とする。一方、あるユーザと別のユーザとで、偶然に同じ認証情報パスワード文字列などを用いていたとしても、手順2で生成される文字列は、複数のユーザで互いに異なるため、手順4では別々のユーザ間での流用という誤検出は発生しない。これにより、認証情報検証サーバ3の管理者が不正に同一の秘匿認証情報を結びつけ、ユーザの認証情報を推定し成りすます、といった秘匿認証情報の悪用を防止することができる。表3は、認証連携サーバ2内の各テーブルのデータ内容の一例を示す。認証要求ポリシテーブル28は、サービスIDと、アプリケーションサーバ1と、ポリシとの対応情報を格納する。項目サービスIDは、アプリケーションサーバ1が提供するサービスを特定するためIDを示す。項目アプリケーションサーバは、項目サービスIDのサービスを提供するアプリケーションサーバ1を示す。例えば、アプリケーションサーバ1xは、サービスID第1サービスIDのサービスを提供し、アプリケーションサーバ1yは、サービスID第2サービスIDのサービスを提供する。項目ポリシは、認証要求ポリシの略であり、項目サービスIDのサービスをユーザ端末8に提供するために必要な認証方式パスワード認証、電子証明書認証、生体認証などの種別とその認証回数との組を示す。認証状態テーブル27は、ユーザIDと、そのユーザが認証表2の認証に成功した結果ユーザ認証状態を管理する。例えば、ユーザtaroには、2回の認証に成功した結果である認証アサーション第1パスワード認証、第2パスワード認証が対応づけられている。認証サーバリスト29は、認証サーバ4のURLと、その認証サーバ4が提供する認証方式と、対応サービス数とを対応づけて管理する。項目対応サービス数とは、認証サーバ4を利用可能なアプリケーションサーバ1の数を示し、このアプリケーションサーバ1の数が多い順に、どの認証サーバ4を利用するか決定される。表4は、流用検出用テーブル34のデータ内容の一例を示す。流用検出用テーブル34は、ユーザIDに対応する流用検出用ユーザIDごとに、そのユーザが認証を実施した認証方式と、その認証結果から生成された秘匿認証情報とを対応づけている。なお、ユーザIDと流用検出用ユーザIDとの対応情報は、ID管理部23によって管理される。表5は、認証サーバ4ごとに格納される認証情報テーブル45のデータ内容の一例を示す。認証情報テーブル45には、認証サーバ4のユーザIDごとに、そのユーザIDに対応する認証情報から生成されたハッシュ値が対応づけられている。認証情報テーブル45aには、第1ユーザIDと第1認証情報から生成された第1ハッシュ値との対応データが格納されている。認証情報テーブル45bには、第2ユーザIDと第2認証情報から生成された第2ハッシュ値との対応データが格納されている。この第1ユーザIDと第2ユーザIDとは、同じユーザIDtaroによって使用されている。図3は、認証連携システムを構成する各計算機を示すハードウェア構成図である。計算機9は、CPU91と、メモリ92と、ハードディスクなどの外部記憶装置93と、インターネットやLANなどのネットワーク99aを介して他の装置と通信を行うための通信装置94と、キーボードやマウスなどの入力装置95と、モニタやプリンタなどの出力装置96と、可搬性を有する記憶媒体99bの読取装置97とが、内部バス98を介して接続されている。記憶媒体99bは、例えば、ICカードやUSBメモリである。計算機9は、図2で示した各処理部の機能を実現するためのプログラムをメモリ92上にロードし、CPU91により実行する。そのプログラムは、あらかじめ、計算機9の外部記憶装置93に格納されていてもよいし、実行時に、読取装置97や通信装置94を介して、他の装置から外部記憶装置93にダウンロードされてもよい。そして、プログラムは一旦外部記憶装置93に格納された後、そこからメモリ上にロードされてCPU91に実行されてもよいし、あるいは外部記憶装置93に格納されることなく、直接メモリ上にロードされて、CPU91に実行されてもよい。図4は、ユーザIDtaroが第1サービスIDのサービスコンテンツを使用する例を示すフローチャートである。図4の詳細は後記するが、図4の処理の概要は、以下の通りである。まず、認証要求ポリシテーブル28で1回のパスワード認証が必要であるので、そのパスワード認証を得るための認証サーバ4として、認証サーバリスト29から対応サービス数が最も多い79個認証サーバ4bのURLhttpdemosite2comidpwを取得する。そして、認証サーバ4bによる第2パスワード認証に成功し表2の認証、かつ、その第2パスワード認証に使用された第2認証情報への検証表2の単体検証、流用検証が成功したときには、認証状態テーブル27内のユーザIDtaroに対応するユーザ認証状態が未認証から第2パスワード認証へと更新される。これにより、ユーザ認証状態第2パスワード認証がポリシ1回のパスワード認証を満たすので、ユーザIDtaroは、第1サービスIDのサービスコンテンツをアプリケーションサーバ1xから使用できる。表6は、図4以降で説明する各フローチャート内で使用される通信メッセージごとの仕様を示す。表6の名称で示される各データは、そのプロトコルの種別とそのプロトコルのタイプで特定されるフォーマットの通信メッセージに含まれて送信される。プロトコルの種別として、HTTPHypertextTransferProtocolは、標準化団体IETFにおいてRFC2616で定義されている。SOAPSimpleObjectAccessProtocolは、標準化団体W3Cによって策定され、他の通信機器上にあるデータやサービスを呼び出すための通信プロトコルであり、通信機器間で送受されるメッセージはXMLExtensibleMarkupLanguageで記述される。検証要求は、~内に、以下の順序でタグが列挙されて構成される。第1ユーザIDtaroauth1認証サーバ4が発行した認証結果秘匿認証情報認証情報プロパティ検証応答は、~内に、以下の順序でタグが列挙されて構成される。脆弱性検証の結果なお、脆弱性検証の結果には、脆弱でないinvulnerableまたは脆弱であるvulnerableの値が格納される。表7は、後記する図4での各ステップごとの通信メッセージの内容種別、クエリ、セッションIDを示す。なお、図4でのサービスIDとは、アプリケーションサーバ1xが提供する第1サービス用のIDである。本実施形態では、ユーザ端末8と他装置との間のデータのやりとりに、HTTPバインディングを用いた一例を説明する。セッションIDは、ユーザ端末8との間で共有される接続識別子SetCookieの値であり、転送応答の送信元装置が新たに作成してユーザ端末8に通知した後例えば、S302で最初に登場するc1、ユーザ端末8からそのセッションIDの通知を受ける例えば、S319で処理要求に含まれるc1。なお、本明細書の各フローチャートでは、セッションごとに、そのセッションの活性化期間を示す破線の矩形も図示している。例えば、図4のユーザ端末8の動作において、開始点S301から終了点S320までの期間を破線矩形で示しているが、この破線矩形で示される期間には、セッションID=c1のセッションが活性化している。転送応答の送信元装置は、転送応答の受信装置ユーザ端末8に対して、次に送信する処理要求の送信先を転送先Locationヘッダの値として指定する。転送応答の受信装置は、その転送応答の送信元装置の識別子を次に送信する処理要求の転送元Refererヘッダの値として指定する。これにより、処理要求の受信装置は、転送元の装置を特定することができる。図4に戻り、S301として、ユーザ端末8のWebブラウザ81は、ユーザからの操作にしたがって、処理要求をアプリケーションサーバ1xに送信する。S302として、アプリケーションサーバ1xのSAMLSP部11xは、転送応答をWebブラウザ81に送信する。この転送応答は、ユーザ端末8が認証済みでないことを示すメッセージであり、認証済みでないことは、アプリケーションサーバ1xがアクセステーブル13xから、ユーザ端末8のユーザIDおよび認可判定結果の登録を見つけられなかったことで確認される。S303として、Webブラウザ81は、処理要求を認証連携サーバ2aに送信する。S304として、ロケーション管理部22aは、連携する認証サーバ4の認証方式を基に、認証サーバ4のURLについて認証サーバリスト29aを検索することで、呼び出す認証サーバ4を決定する。この決定された認証サーバ4は、S303の処理要求を実現するために不足分の認証を行う相手である。S305として、認証連携サーバ2aのSAMLIdPProxy部25aは、転送応答をWebブラウザ81に送信する。S306として、Webブラウザ81は、処理要求を認証連携サーバ2bに送信する。S307として、SAMLIdPProxy部25bは、転送応答をWebブラウザ81に送信する。なお、ロケーション管理部22bは、認証サーバ4bのURLを解析することで、認証サーバ4bのドメインが他ドメインドメインB上に存在する旨を確認する。S308として、Webブラウザ81は、処理要求を認証サーバ4bに送信する。S309として、認証サーバ4bの認証部43bは、ユーザ端末8から認証情報を取得し、ユーザ認証を実施する。認証部43bは、認証情報テーブル45b内に第2ユーザIDと第2ハッシュ値との対応データが存在するので、認証成功の旨を示すSAML2.0で規定された認証アサーションを作成し、これに第2認証結果を含める。認証情報秘匿化部42bは、認証情報テーブル45bの第2ハッシュ値を秘匿化することで、第2秘匿認証情報を生成する。認証情報管理部41bは、第2認証情報から特徴量を抽出し、第2認証情報プロパティを生成する。S310として、SAMLIdP部44bは、転送応答生成された第2秘匿認証情報と、第2認証情報プロパティとを含むをWebブラウザ81に送信する。S311として、Webブラウザ81は、処理要求を認証連携サーバ2bに送信する。S312として、SAMLIdPProxy部25bは、転送応答をWebブラウザ81に送信する。S313として、Webブラウザ81は、処理要求を認証連携サーバ2aに送信する。S314として、認証情報検証依頼部26aは、検証要求を認証情報検証サーバ3に送信する。S315として、流用検出管理部31は、脆弱性の検証を実施する。S316として、通信部33は、検証応答を認証連携サーバ2aに送信する。S317として、認可判定部24aは、認可の判定を実施する。S318として、SAMLIdPProxy部25aは、転送応答をWebブラウザ81に送信する。S319として、Webブラウザ81は、処理要求をアプリケーションサーバ1xに送信する。S320として、SAMLSP部11xは、成功応答をWebブラウザ81に送信する。成功応答のBODY部には、S301のサービス実行パラメータからWebサーバ12xによって生成されるサービスコンテンツが含まれている。Webブラウザ81は、受信した成功応答内のサービスコンテンツを処理し、Webブラウザ81上の画面に表示する。図5は、図4の実行後に、ユーザIDtaroが第2サービスIDのサービスコンテンツを使用する例を示すフローチャートである。図5は、ユーザが自ドメインの認証サーバ4aを利用して認証を実施し、アプリケーションサーバ1yが提供するサービスを利用する場合の動作を示すフローチャートである。図5の詳細は後記するが、図5の処理の概要は、以下の通りである。まず、認証要求ポリシテーブル28で2回のパスワード認証が必要であるので、ユーザ認証状態第2パスワード認証だけでは、1回分のパスワード認証が不足する。そこで、2回目のパスワード認証として、認証サーバリスト29表3から対応サービス数が2番目に多い57個認証サーバ4aのURLhttpdemosite1comidpwを取得する。そして、認証サーバ4aによる第1パスワード認証に成功し表2の認証、かつ、その第1パスワード認証に使用された第2認証情報への単体検証と、第1認証情報および第2認証情報の組み合わせへの流用検証が成功したときには、認証状態テーブル27表3内のユーザIDtaroに対応するユーザ認証状態が第2パスワード認証から第1パスワード認証、第2パスワード認証へと更新される。これにより、ユーザ認証状態第1パスワード認証、第2パスワード認証がポリシ2回のパスワード認証を満たすので、ユーザIDtaroは、第2サービスIDのサービスコンテンツをアプリケーションサーバ1yから使用できる。表8は、後記する図5での各ステップごとの通信メッセージの内容種別、クエリ、セッションIDを示す。なお、図5でのサービスIDとは、アプリケーションサーバ1yが提供する第2サービス用のIDである。S401として、ユーザ端末8のWebブラウザ81は、処理要求をアプリケーションサーバ1yに送信する。S402として、アプリケーションサーバ1yのSAMLSP部11yは、転送応答をWebブラウザ81に送信する。ここで、SAMLSP部11yは、S302と同様に、アクセステーブル13yを参照し、ユーザ端末8が認証済でないことを確認する。S403として、Webブラウザ81は、処理要求を認証連携サーバ2aに送信する。S404として、認証連携サーバ2aのロケーション管理部22aは、呼び出す認証サーバ4を決定する。S405として、SAMLIdPProxy部25aは、転送応答をWebブラウザ81に送信する。S406として、Webブラウザ81は、処理要求を認証サーバ4aに送信する。S407として、認証サーバ4aの認証部43aはユーザ端末8から認証情報を取得し、ユーザ認証を実施する。認証部43aは、認証情報テーブル45a内に第1ユーザIDと第1ハッシュ値との対応データが存在するので、認証成功の旨を示すSAML2.0で規定された認証アサーションを作成し、これに第1認証結果を含める。S408として、SAMLIdP部44aは、転送応答をWebブラウザ81に送信する。なお、S408の転送応答に含まれる各パラメータは、以下に示すように作成される。認証情報秘匿化部42aは、認証情報テーブル45aの第1ハッシュ値を秘匿化することで、第1秘匿認証情報を生成する。認証情報管理部41aは、第1認証情報から特徴量を抽出し、第1認証情報プロパティを生成する。S409として、Webブラウザ81は、処理要求を認証連携サーバ2aに送信する。S410として、SAMLIdPProxy部25aは、検証要求を認証情報検証サーバ3に送信する。S411として、流用検出管理部31は、脆弱性の検証を実施する。S412として、通信部33は、検証応答を認証連携サーバ2aに送信する。S413として、認可判定部24aは、認可の判定を実施する。S414として、SAMLIdPProxy部25aは、転送応答をWebブラウザ81に送信する。S415として、Webブラウザ81は、処理要求をアプリケーションサーバ1yに送信する。S416として、Webサーバ12yは、サービスを実行する。S417として、SAMLSP部11yは、成功応答をWebブラウザ81に送信する。成功応答のBODY部には、S401のサービス実行パラメータからWebサーバ12yによって生成されるサービスコンテンツが含まれている。Webブラウザ81は、受信した成功応答内のサービスコンテンツを処理し、Webブラウザ81上の画面に表示する。図6は、図4および図5の処理における認証連携サーバ2の動作を示すフローチャートである。認証連携サーバ2は、ユーザ端末8に認証が必要か否かを判定し、その結果に基づきアプリケーションサーバへのアクセス認可判定を実施する。図6では、図4および図5で説明した以下の4つのケースについて、説明する。ケース1S303の処理要求からS312の転送応答までケース2S313の処理要求からS318の転送応答までケース3S403の処理要求からS408の転送応答までケース4S409の処理要求からS414の転送応答まで認証連携サーバ2のSAMLIdPProxy部25は、4つの各ケースの処理要求を受信しS501、その処理要求に含まれるメッセージパラメータを取得しS502、メモリ上に格納された内部状態が認証結果待ちであるか否かを判定するS503。S503でYesならケース2,ケース4S509に進み、Noならケース1,ケース3S504へ進む。S504として、認証状態管理部21は、サービスID第1サービスIDを基に、ポリシについて認証要求ポリシテーブル28を検索し、アプリケーションサーバ1のポリシケース1なら1回のパスワード認証、ケース3なら2回のパスワード認証を取得する。S505として、認証状態管理部21は、ユーザIDtaroを基に、認証状態テーブル27を検索し、ユーザ端末8の認証状態ケース1では未認証、ケース3では第2パスワード認証を取得する。S506として、認可判定部24は、S505の認証状態がS504のポリシを満足しているか否かを判定する。この判定は、認証状態テーブル27のポリシに記載されているすべての認証認証種別ごとの認証回数を、ユーザ認証状態が満足しているか否かにより、判定される。S506でYesならケース2、ケース4S507へ進み、Noならケース1、ケース3S518へ進む。S507では、認可判定部24は、認可判定結果認可を生成し、処理を終了する。S509では、SAMLIdPProxy部25は、S501のメッセージから認証結果を取得し、その取得した認証結果が認証成功か否かを判定するS510。S510でYesなら、SAMLIdPProxy部25は、ID管理部23に対して、ユーザ端末8のユーザIDを認証情報検証サーバ3用の流出検出用ユーザIDに変換する処理を実行させてから、S511へ進む。S510でNoならS514へ進む。S511では、SAMLIdPProxy部25は、認証情報検証依頼部26を呼び出す。認証情報検証依頼部26は、検証要求を作成し、認証情報検証サーバ3へ送信することで問い合わせるケース2ではS314、ケース4ではS410の処理。認証情報検証依頼部26は、認証情報検証サーバ3から検証応答を受信するケース2ではS316、ケース4ではS412の処理。認証状態管理部21は、検証応答内の検証結果が成功か否かを判定するS512。S512でYesならS513へ進み、NoならS514へ進む。S513では、認証状態管理部21は、認証状態テーブル27にユーザ端末8の認証状態に関するレコードを追加することで、ユーザ端末8の認証状態を更新する。認証状態管理部21は、認証を依頼した各認証サーバ4から、認証結果が全て戻ってきたか否かを判定するS514。S514でYesなら、認証状態管理部21は、内部状態をリセットしS515、認証回数カウンタの値を1増やしS516、S504へ進む。S514でNoなら、終了する。S518として、認証状態管理部21は、メモリ上に格納された認証回数カウンタが規定値例えば3回以上であるか否かを判定する。S518でYesならS519へ進み、NoならS520へ進む。S519では、認証状態管理部21は、認可判定結果不認可を作成し、終了する。S520では、認可判定部24は、不足している認証方式を算出するS520。S520として、例えば、ポリシ1回の電子証明書認証と、2回のパスワード認証に対して、現在のユーザ認証状態第1パスワード認証であるときには、不足分の認証は、1回の電子証明書認証と、1回のパスワード認証である。S521として、ロケーション管理部22は、不足している認証方式のうち最も対応サービス数の多い認証サーバ4既に認証結果を取得した認証サーバ4を除外のURLを取得する。S522として、ID管理部23は、ユーザ端末8から取得したユーザIDを、S521で決定した認証サーバ4用のユーザID例えば、第1ユーザIDに変換する。S523として、SAMLIdPProxy部25は、転送応答を作成して、ユーザ端末8へ送信して認証依頼するとともにケース1ではS305、ケース3ではS405の処理、S503で判定される内部状態の値を認証結果待ちと設定するS524。図7は、図4および図5の処理における認証情報検証サーバ3の動作を示すフローチャートである。このフローチャートの概要は、認証情報検証サーバ3は、検証要求図6の説明でのケース2ではS314で送信、図6の説明でのケース4ではS410で送信への検証処理を実行しケース2ではS315で実行、ケース4ではS411で実行、その結果を検証応答ケース2ではS316で送信、ケース4ではS412で送信として送信する処理である。通信部33は、認証連携サーバ2から検証要求を受信しS601、その検証要求内のメッセージパラメータを取得するS602。S601の検証要求として、ケース2の場合は、認証結果A2、流用検出用ユーザID、第2秘匿認証情報、第2認証情報プロパティというメッセージパラメータが取得される表7参照。S601の検証要求として、ケース4の場合は、認証結果A3、流用検出用ユーザID、第1秘匿認証情報、第1認証情報プロパティというメッセージパラメータが取得される表8参照。流用検出管理部31は、S602で取得した流用検出用ユーザIDを検索キーとして流用検出用テーブル34から検索し、該当するレコードの秘匿認証情報列に格納されている秘匿認証情報を検索結果として取得するS603。そして、流用検出管理部31は、S602で取得した秘匿認証情報と、S603で取得した秘匿認証情報とを照合することで、検証要求内の秘匿認証情報が流用検出用テーブル34内に存在するか否かを判定するS604。このS604の判定処理は、換言すると、同じユーザによる同じ認証情報の流用の有無を判定する処理である。S604でYesなら、S605へ進み、S604でNoなら、S610へ進む。S604の判定結果として、ケース2の場合は、S602で取得した第2秘匿認証情報が、S603で取得した秘匿認証情報第0秘匿認証情報内には存在しないので、S604でNoである。S604の判定結果として、ケース4の場合は、S602で取得した第1秘匿認証情報が、S603で取得した秘匿認証情報第0秘匿認証情報、第2秘匿認証情報内には存在しないので、S604でNoである。S605として、流用検出管理部31は、検証結果脆弱を示すvulnerableを作成し、S616へ進む。S610では、流用検出管理部31は、流用検出用テーブル34に、S602で取得したメッセージパラメータに関するレコード秘匿認証結果を追加する。S610の追加処理として、ケース2の場合は、S602で取得した第2秘匿認証情報が流用検出用テーブル34に追加された結果、流用検出用テーブル34の秘匿認証情報は、第0秘匿認証情報、第2秘匿認証情報へと更新される。S610の追加処理として、ケース4の場合は、S602で取得した第1秘匿認証情報が流用検出用テーブル34に追加された結果、流用検出用テーブル34の秘匿認証情報は、第0秘匿認証情報、第1秘匿認証情報、第2秘匿認証情報へと更新される。認証情報検証部32は、S602で取得した認証情報プロパティから認証情報の脆弱度を計算するS611。そのため、まず、認証情報がパスワードであるときには、その文字列の長さ、使用している文字の種類、などの特徴ごとに脆弱値を計算し、それらの脆弱値の合計を脆弱度として算出する。認証情報検証部32は、S611で算出した脆弱度が閾値を超えているか否か脆弱度≦閾値を判定するS612。S612でYesならS613へ進み、NoならS605へ進む。S613として、認証情報検証部32は、検証結果非脆弱を示すinvulnerableを作成する。S616として、通信部33は、S605またはS613で作成した検証結果を含む検証応答を作成し、認証連携サーバ2へ送信する。なお、S616として、ケース2の場合は、S316の検証応答が送信され、ケース4の場合は、S412の検証応答が送信される。以上、第1実施形態で説明した認証連携システムでは、認証情報検証サーバ3が第1秘匿認証情報と第2秘匿認証情報とを照合することによって、同じユーザによって使用される2つの認証情報第1認証情報、第2認証情報間の流用を検証する。これにより、流用が検知された脆弱な認証情報によるユーザ認証を無効にすることで、複数のユーザ認証の結果を組み合わせて用いるときに、セキュリティ強度の低下を防止することができる。以下、第2実施形態について、説明する。第2実施形態は、複数のシングルサインオンシステムを連携させる形態である。図8は、第2実施形態の認証サーバ連携システムの構成図である。認証サーバ連携システムは、ドメインをまたがったシングルサインオンを提供する形態である。ユーザ端末8が認証サーバ4に対して認証を行うときに、そのユーザ端末8と認証サーバ4とが異なるドメインに属している場合、ユーザ端末8が属するドメインの認証プロキシサーバ6が、そのユーザ端末8を代行して他ドメインの認証サーバ4と認証を行う。以下、ユーザ端末8がドメインAネットワーク5aに属し、認証サーバ4がドメインBネットワーク5bに属している例を示す。認証サーバ4bとの認証に成功したユーザ端末8は、ドメインB内のアプリケーションサーバ1からサービスを受けることができる。第1実施形態と第2実施形態とで共通する構成については、同じ符号を付し、説明を省略する。また、第1実施形態と同様に、以下の説明では、図1と同様に、2つのドメインで同じ構成要素が存在するときには、その構成要素の符号末尾のa,bが所属するドメインを示す。第1実施形態と第2実施形態とを比較すると、以下のように構成の相違点1~相違点3がある。相違点1として、アプリケーションサーバ1の接続先を、ドメインAからドメインBに変更する。相違点2として、認証情報検証サーバ3を省略する。さらに、認証連携サーバ2内の認証連携サーバ2と通信するための認証情報検証依頼部26も併せて省略する。よって、第1実施形態で記載されていた認証連携サーバ2による検証処理は、第2実施形態では、省略される。具体的には、検証要求S314,S410→検証処理S315,S411→検証応答S316,S412を省略するとともに、S502に含まれる認証結果が成功であるときにはS510,Yes、検証要求を行うことなくS511,S512の省略、その認証結果をユーザの認証状態として更新するS513。相違点3として、認証プロキシサーバ6を新たにドメインAに追加する。なお、認証プロキシサーバ6は、ドメインAに1台配置される構成の他に、ドメインごとに1台ずつ配置されていてもよいし、認証プロキシサーバ6と認証連携サーバ2とが同じ筐体内に配備されていてもよい。図9は、第2実施形態の認証サーバ連携システムを構成する各装置の構成図である。第1実施形態と同じ構成の装置については、図示を省略する。認証プロキシサーバ6は、ネットワーク5aからネットワーク5bへのアクセスを制御することで、ユーザ端末8の代理としてネットワーク5b上でユーザ認証を実施する。このため、認証プロキシサーバ6は、SAMLSP部61と、認証情報連携部62と、SAMLECP部63と、認証連携テーブル64とを有する。SAMLSP部61は、認証連携サーバ2から認可判定結果を取得し、ネットワーク5aからネットワーク5bへのアクセスを制御する。認証情報連携部62は、認証連携サーバ2から認証結果や秘匿認証情報を取得し、ネットワーク5bにおけるユーザ認証でそれらを使用する。SAMLECP部63は、ユーザ端末8に代わりネットワーク5b上でのユーザ認証を実施する。さらに、認証連携サーバ2に対して、認証情報提供部76を新たに追加する。この認証情報提供部76は、認証サーバ4が発行した認証結果や秘匿認証情報を認証プロキシサーバ6へ送信する。表9に示す認証連携テーブル64には、アクセス制御に必要な情報やネットワーク5b上でのユーザ認証で使用する情報として、ユーザIDと、アプリケーションサーバ1のURLと、認証連携と、提供種別と、認証方式と、認可判定結果との対応情報が格納される。項目ユーザIDは、アプリケーションサーバ1を利用する際に使用するユーザIDを格納する。項目アプリケーションサーバURLは、アプリケーションサーバ1のURLを格納する。項目認証連携有無は、ネットワーク5a上の認証サーバ4における認証結果や認証サーバ4aに登録されている認証情報を、別のネットワーク上の認証サーバ4に提供するか否かを示すフラグを格納する。項目提供種別は、別のネットワーク上の認証サーバ4に対して提供する情報の種類認証情報認証結果を格納する。項目認証方式は、アプリケーションサーバ1が要求するユーザ認証の認証方式を格納する。項目認可判定結果は、認証連携サーバ2aが発行した認可判定結果を格納する。表10は、第2実施形態での説明用パラメータ例を示す。表1と比較すると、第1ユーザIDおよび第2ユーザIDそれぞれの認証情報とその秘匿認証情報が、表1では互いに異なるデータであるのに対し、表10では互いに同じデータである。つまり、第1実施形態では、双方の秘匿認証情報が不一致であることが望ましい同一ユーザについて認証情報の流用を行っていないのに対し、第2実施形態では、双方の秘匿認証情報が一致であることが望ましい同一ユーザが複数のドメインについて、それぞれ認証に成功する。さらに、第2実施形態では、認証プロキシサーバ6の外部記憶装置には、認証サーバ4aの第1公開鍵証明書、および、認証サーバ4bの第2公開鍵証明書が、それぞれ保管されている。認証プロキシサーバ6は、以下の手順1~手順3で、ユーザ端末8がアプリケーションサーバ1のサービスを利用できるように制御する図8参照。これにより、ユーザ端末8は、自らの認証情報を認証サーバ4bに入力しなくても済む。手順1ネットワーク5aユーザ端末8からネットワーク5bアプリケーションサーバ1へのアクセスサービス利用において、ユーザ認証が必要と判断する。手順2認証連携サーバ2aおよび認証サーバ4aと連携してユーザ認証を実施する。手順3認証サーバ4aから取得した秘匿認証情報を認証サーバ4bへ提示することにより、ネットワーク5b上で、ユーザ端末8に代わり認証サーバ4bとの間でユーザ認証を実施する。表11は、第2実施形態でやりとりされる通信メッセージ種別のリストを示す。表11の1行目に示される秘匿認証情報要求は、~内に、以下の順序でタグが列挙されて構成される。チケット格納データ認証連携サーバ2が発行した認証チケットを含む認証サーバ4の公開鍵証明書ここで、認証チケットとは、例えば、SAML2.0で規定されたアーティファクトであり、その認証チケットごとにあらかじめ対応付けされているチケット対応データユーザ端末8の認証情報などの取得処理に使用される。また、表11の3行目に示される秘匿化要求は、~内に、秘匿認証情報要求と同じデータチケット格納データ、公開鍵証明書が含まれる。表11の4行目に示される秘匿化応答は、~内に、以下の順序でタグが列挙されて構成される。秘匿認証情報の取得に成功したか否かを示す情報成功ならsuccess、失敗ならfail秘匿認証情報表11の2行目に示される秘匿認証情報応答は、~内に、以下の順序でタグが列挙されて構成される。秘匿認証情報の取得に成功したか否かを示す情報成功ならsuccess、失敗ならfail下記のcredentialタグ内に含まれる情報の種類認証結果を示すassertionまたは秘匿認証情報を示すcredential認証結果または秘匿認証情報図10は、第2実施形態におけるドメインA側で開始される処理を示すフローチャートである。このフローチャートの開始時点では、表9の認証連携テーブル64内のユーザIDtaroの認可判定結果は、記載されていない。ユーザIDtaroとは、アプリケーションサーバ1が提供するサービス用のユーザIDである。表12は、後記する図10での各ステップごとの通信メッセージの内容種別、クエリ、セッションIDを示す。S901として、ユーザ端末8のWebブラウザ81は、ユーザ端末8のユーザからの操作を受け付けて作成した処理要求を認証プロキシサーバ6に送信する。S902として、認証プロキシサーバ6のSAMLSP部61は、転送応答をユーザ端末8に送信する。S903として、Webブラウザ81は、処理要求を認証連携サーバ2aに送信する。S904として、認証連携サーバ2aのSAMLIdPProxy部25aは、S304と同様にして、呼び出す認証サーバ4aを決定する。S905として、SAMLIdPProxy部25aは、転送応答をユーザ端末8に送信する。S906として、Webブラウザ81は、処理要求を認証サーバ4aに送信する。S907として、認証サーバ4aの認証部43aは、ユーザ端末8から認証情報を取得し、ユーザ認証を実施する。ユーザ認証では、認証情報テーブル45aから、第1ユーザIDと、対応する認証情報ユーザ端末8から取得との組み合わせのレコードが発見できたときに、認証成功とする。S908として、SAMLIdP部44aは、転送応答認証結果A1、認証チケットT1、第1ユーザIDを含むをユーザ端末8に送信する。認証結果A1とは、SAML2.0で規定された認証アサーションである。認証チケットT1とは、SAML2.0で規定されたアーティファクトである。認証部43aは、認証チケットT1とユーザ端末8の認証情報とを結び付けて、メモリへ一時保存する。S909として、Webブラウザ81は、処理要求を認証連携サーバ2aに送信する。SAMLIdPProxy部25aは、ユーザ端末8から処理要求を受信すると、第1実施形態におけるS317やS413と同様に、認証プロキシサーバ6に対する認可判定結果認可を生成する。また、認証情報連携部62aは、SAML2.0で規定されたアーティファクトを認証チケットT2として生成すると共に、メモリへ認証チケットT2と認証サーバ4aが発行した認証結果とを結び付けて一時保存する。S910として、SAMLIdPProxy部25aは、転送応答をユーザ端末8に送信する。S911として、Webブラウザ81は、処理要求を認証プロキシサーバ6に送信する。SAMLSP部61は、その処理要求を受信し、メッセージパラメータを取得して、メモリへ保存する。S912として、SAMLSP部61は、ドメインBへのサービス要求をネットワーク5bに送信し、アプリケーションサーバ1からサービスの実行結果であるサービスコンテンツを取得する。S913として、SAMLSP部61は、成功応答をユーザ端末8に送信する。Webブラウザ81は、受信した成功応答内のサービスコンテンツを処理し、ユーザ端末8の画面に表示する。図11は、第2実施形態におけるドメインBへのサービス要求S912を契機に、ドメインB側で開始される処理を示すフローチャートである。表13は、後記する図11での各ステップごとの通信メッセージの内容種別、クエリ、セッションIDを示す。S1001として、SAMLECP部63は、処理要求をアプリケーションサーバ1に送信する。S1002として、SAMLSP部11は、ユーザIDおよびその認可判定結果がアクセステーブル13には登録されていないつまり、ユーザ端末8が認証済ではないことを確認すると、転送応答を認証プロキシサーバ6に送信する。S1003として、SAMLECP部63は、処理要求を認証連携サーバ2に送信する。S1004として、SAMLIdPProxy部25bは、S404と同様にして、呼び出す認証サーバ4bを決定する。S1005として、SAMLIdPProxy部25bは、転送応答を認証プロキシサーバ6に送信する。認証情報連携部62は、S1005の転送応答を受信すると、認証連携テーブル64のうち、ユーザIDおよびアプリケーションサーバ1のURLが格納されている行について、認証連携有無レコードのセルが有、かつ提供種別レコードのセルが認証情報であるか否かを判定する。このS1005の受信時には、認証連携テーブル64に該当する行が存在する判定がYesなので、認証情報連携部62は、認証プロキシサーバ6の外部記憶装置に保存されている、認証サーバ4bの公開鍵証明書を取得する。SAMLSP部61は認証チケットT2を含めたSAML2.0ArtifactResolutionProtocolのチケット格納データを作成する。S1006として、SAMLSP部61は、秘匿認証情報要求作成したチケット格納データを含むを認証連携サーバ2aに送信する。SAMLIdPProxy部25aは、受信した秘匿認証情報要求に公開鍵証明書が含まれていることを解析すると、認証サーバ4aから取得した認証チケットT1を含めたチケット格納データを作成する。一方、秘匿認証情報要求に公開鍵証明書が含まれていない場合、認証情報連携部62aは、認証チケット2に結び付けてメモリに一次保存している認証結果を取得し、認証プロキシサーバ6へ返信する。S1007として、SAMLIdPProxy部25aは、秘匿化要求作成したチケット格納データを含むを認証サーバ4aに送信する。SAMLIdP部44aは、認証連携サーバ2aから秘匿化要求を取得すると、認証チケットT1に結び付けてメモリに一次保存しているユーザ端末8の認証情報を取得する。S1008として、認証情報秘匿化部42aは、秘匿化要求に含まれる認証サーバ4bの公開鍵証明書内にある公開鍵を用い、ユーザ端末8の認証情報を暗号化することにより、秘匿認証情報を生成する。SAMLIdP部44aは、S1008で作成された秘匿認証情報を含めたSAML2.0ArtifactResolutionProtocolのチケット対応データを作成する。S1009として、SAMLIdP部44aは、秘匿化応答作成したチケット対応データを含むを認証連携サーバ2aに送信する。SAMLIdPProxy部25aは、受信した秘匿化応答内の秘匿認証情報を含めたチケット対応データを新たに作成する。S1010として、SAMLIdPProxy部25aは、秘匿認証情報応答作成したチケット対応データを含むを認証プロキシサーバ6に送信する。S1011として、SAMLSP部61は、処理要求SAMLSP部61が秘匿認証情報応答内のチケット対応データから取得した秘匿認証情報を含むを認証サーバ4bに送信する。S1012として、認証部43bは、認証プロキシサーバ6から取得した秘匿認証情報を認証サーバ4bの秘密鍵を用いて復号し、得られた認証情報を用いてユーザ認証を実施する。認証情報テーブル45aに登録されているユーザ端末8の認証情報パスワードと、秘匿認証情報を復号して得られた認証情報パスワードとが同じであるときには、ユーザ認証に成功する。認証部43bは、認証に成功したときには、認証結果A2を含める認証アサーションを作成する。S1013として、SAMLIdP部44bは、転送応答を認証プロキシサーバ6に送信する。S1014として、SAMLECP部63は、処理要求を認証連携サーバ2に送信する。S1015として、S317やS413と同様に、SAMLIdPProxy部25bは、認可判定を実施する。S1016として、SAMLIdPProxy部25bは、転送応答を認証プロキシサーバ6に送信する。S1017として、SAMLECP部63は、処理要求をアプリケーションサーバ1に送信する。S1018として、SAMLSP部11は、成功応答Webサーバ12がS1017の処理要求に含まれるサービス実行パラメータから作成したサービスコンテンツを含むを認証プロキシサーバ6に送信する。SAMLECP部63は、アプリケーションサーバ1から成功応答を受信すると、その成功応答内のサービスコンテンツを含めて成功応答を生成し、ユーザ端末8へ送信するS913。なお、S901~S912を実行した後で、S1001を開始する代わりに、以下の手順1~手順4を順に実行してもよい。手順1S901を実行手順2S1001からS1005までを実行手順3S902からS911までを実行手順4S1006以降を実行図12は、SAMLSP部61が実行する各処理を示すフローチャートである。この図12の説明では、動作主体がすべてSAMLSP部61であるので、その旨を各処理の説明から省略する。以下に示すように、SAMLSP部61は、S1101~S1107を実行することで、S901の処理要求の受信を契機にアクセス制御が必要か否かを判定し、必要であれば認可判定結果を認証連携サーバ2から要求し、取得した認可判定結果を基にアクセス制御を実施する。S1101では、ユーザ端末8からS901の処理要求を受信する。S1102では、処理要求内で指定されるユーザIDtaroおよびアプリケーションサーバ1のURLhttpdemosite2comsp1の組み合わせのレコードが、認証連携テーブル64内に登録されているか否かを判定するS1102。S1102でYesならS1103へ進み、NoならS1105へ進む。S1103では、S1102で検索したレコード内に、認可判定結果が存在するか否かを判定する。S1103でYesならS1104へ進み、NoならS1107へ進む。S1104では、S1103で判定した認可判定結果が認可OKか否かを判定する。S1104でYesならS1105へ進み、NoならS1106へ進む。S1105では、処理要求をアプリケーションサーバ1へ送信する。S1106では、認証失敗を示す禁止応答をユーザ端末8へ送信する。S1107では、認可判定結果がユーザ端末8から受信したメッセージに添付されているか否かを判定する。S1107でYesならS1108へ進み、NoならS1116へ進む。S1108では、認可判定結果を認証連携テーブル64へ登録する。S1109では、認可判定結果はOK認可成功か否かを判定する。S1109でYesならS1110へ進み、NoならS1106へ進む。S1110では、認証連携は有か否かを判定する。S1110でYesならS1111へ進み、NoならS1113へ進む。S1111では、S1006の秘匿認証情報要求を認証連携サーバ2bへ送信する。S1112では、S1010の秘匿認証情報応答を認証連携サーバ2bから受信する。S1113では、認証結果or認証情報秘匿認証情報応答に含まれるをメモリへ保存し、S1105へ進む。S1116では、S902の転送応答を作成し、ユーザ端末8へ送信する。以上説明した第2実施形態でのシングルサインオンシステムでは、ドメインAのシングルサインオンシステムが、別のドメインBのシングルサインオンシステム内の認証サーバ4に対し、ユーザに代わりユーザの認証情報を送信し、認証サーバ4が認証情報を取得してユーザ認証を実施する。これにより、複数のシステムにまたがったシングルサインオンを実現する。一方、従来のシングルサインオンシステムは、同一ドメイン間での単一のシングルサインオンシステムとしての認証連携にとどまる。その原因は技術的制約、物理的制約、セキュリティポリシによる制約など様々である。この場合、ユーザは利用しているシングルサインオンシステムと連携しているサービスについては認証情報の入力操作および認証情報の管理による負担を軽減できるが、それ以外のサービスについてはシングルサインオンによる恩恵を受けることができない。また、ユーザが複数のシングルサインオンシステムを利用できるとしても、シングルサインオンシステムごとに認証情報の入力操作が必要となるため、シングルサインオンの適用前に存在したパスワード管理の問題が浮上する。ここで、シングルサインオンに関連して、ユーザがサービスごとに利用するIDや属性情報を一元的に管理し、必要に応じてサービスに提供するID管理技術が利用されつつある。特開2010-113462号公報には、ユーザIDやアサーションを含む、ユーザに関わる情報ユーザのIDや属性情報を、必要な相手にだけ安全に提供する方法が示されている。しかし、特開2010-113462号公報には、第2実施形態のように、本人の信頼性の拠り所である認証情報を認証サーバ4から第三者へ提供する点は、記載されていない。"