説明

認証連携システム、および、認証連携方法

【課題】複数のWebサービスを連携させた連携サービスを低コストで実現すること。
【解決手段】認証連携システムの認証サーバ4は、認証処理で扱う認証情報を入力として、秘匿化演算処理を行うことにより、認証情報ごとの秘匿認証情報を生成し、認証情報検証サーバ3は、認証サーバ4により生成された秘匿認証情報とその生成元である認証情報を使用するユーザ端末8のユーザを一意に特定するユーザIDとの組み合わせを複数組取得して互いに照合することで、その組み合わせについての流用が発生した複数の認証情報を抽出し、認証連携サーバ2は、ユーザ認証状態を構成する認証結果として、認証情報の流用が発生した認証結果を除外した後のユーザ認証状態が、ポリシを満たしているときにサービスを認可する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、認証連携システム、および、認証連携方法の技術に関する。
【背景技術】
【0002】
近年、インターネットにおけるサービスや企業内ネットワークにおける各種システムにおいて、ID/パスワードを登録している一人あたりのサービスの数は、年々増加している。ユーザは多数のID/パスワードを管理するのに負担が非常に大きく、サービスごとに異なるパスワードを設定し把握するのは困難である。
そこで、特許文献1などのシングルサインオンでは、ユーザ認証を一度受けるだけで、ユーザ認証を必要とする複数のサービスへアクセスできる。これにより、ユーザが管理するパスワードの数を削減することで、より安全にパスワードを管理することが可能となる。
【0003】
非特許文献1は、SAML(Security Assertion Markup Language)と呼ばれるシングルサインオン技術であり、標準化団体OASISにおいて策定され、認証結果やアクセス認可判定結果などのセキュリティデータを安全に伝達する方法をXML(Extensible Markup Language)で記述するマークアップ言語仕様である。SAMLでは、IdP(Identity Provider)と呼ばれる、ユーザ認証の結果をアサーションと呼ばれるメッセージとして発行し、SP(Service Provider)と呼ばれるサービスへ提供する。そしてSPは、アサーションを信頼することで、ユーザが認証済か否かを検知できる。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2010−113462号公報
【非特許文献】
【0005】
【非特許文献1】「Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0.」,OASIS Standard,March 2005
【発明の概要】
【発明が解決しようとする課題】
【0006】
一方、オンラインバンキングや公的な手続きなど、高い安全性が求められるサービスでは、1つのサービスを受けるために、複数のユーザ認証の結果を組み合わせて用いるシステム形態(多要素認証)も考えられる。これにより、多要素認証のうちの1つのユーザ認証が不正な攻撃者によって成功したとしても、多要素認証のうちの他のユーザ認証が成功しない限り、サービスは許可されないため、セキュリティ強度を高めることができる。
【0007】
しかし、ユーザによっては、多要素認証で同じパスワードを使いまわす(流用する)などにより、多要素認証それぞれのパスワード管理を横着してしまう場合もある。そのときには、1つのユーザ認証が攻撃者に解読されてしまうと、連鎖的に他のユーザ認証も解読されてしまい、多要素認証を用いたとしても、充分なセキュリティ強度を保証できない。
【0008】
そこで、本発明は、前記した問題を解決し、複数のユーザ認証の結果を組み合わせて用いるときに、セキュリティ強度の低下を防止することを、主な目的とする。
【課題を解決するための手段】
【0009】
前記課題を解決するために、本発明は、ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムであって、
ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、
前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、
前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、
前記認証サーバが、前記認証処理で扱う前記認証情報を入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、
前記認証情報検証サーバが、前記認証サーバにより生成された前記秘匿認証情報とその生成元である前記認証情報を使用する前記ユーザ端末のユーザを一意に特定するユーザIDとの組み合わせを複数組取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、
前記認証連携サーバが、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする。
その他の手段は、後記する。
【発明の効果】
【0010】
本発明によれば、複数のユーザ認証の結果を組み合わせて用いるときに、セキュリティ強度の低下を防止することができる。
【図面の簡単な説明】
【0011】
【図1】本発明の第1実施形態に関する認証連携システムの構成図である。
【図2】本発明の第1実施形態に関する認証連携システムを構成する各装置の詳細を示す構成図である。
【図3】本発明の第1実施形態に関する認証連携システムを構成する各計算機のハードウェア構成図である。
【図4】本発明の第1実施形態に関するユーザID「taro」が第1サービスIDのサービスコンテンツを使用する処理を示すフローチャートである。
【図5】本発明の第1実施形態に関する図4の実行後に、ユーザID「taro」が第2サービスIDのサービスコンテンツを使用する処理を示すフローチャートである。
【図6】本発明の第1実施形態に関する図4および図5の処理における認証連携サーバの動作を示すフローチャートである。
【図7】本発明の第1実施形態に関する図4および図5の処理における認証情報検証サーバの動作を示すフローチャートである。
【図8】本発明の第2実施形態に関する認証連携システムの構成図である。
【図9】本発明の第2実施形態に関する認証連携システムを構成する各装置の詳細を示す構成図である。
【図10】本発明の第2実施形態に関するドメインA側で開始される処理を示すフローチャートである。
【図11】本発明の第2実施形態に関するドメインBへのサービス要求を契機に、ドメインB側で開始される処理を示すフローチャートである。
【図12】本発明の第2実施形態に関するSAML SP部が実行する各処理を示すフローチャートである。
【発明を実施するための形態】
【0012】
以下、本発明の一実施形態を、図面を参照して詳細に説明する。
【0013】
図1は、認証連携システムの構成図である。認証連携システムは、2つのドメインA,B間がネットワーク5a,5bで接続されて構成される。ネットワーク5a,5bは、企業内LAN(Local Area Network)のようなプライベートネットワークでも、インターネットのようなオープンネットワークでもよい。
なお、以下の説明では、2つのドメインで同じ構成要素が存在するときには、その構成要素の符号末尾の「a,b」が所属するドメインを示す。例えば、認証連携サーバ2は、ドメインA内の認証連携サーバ2aと、ドメインB内の認証連携サーバ2bとがそれぞれ存在する。
【0014】
SAMLを用いる認証連携システムは、認証用の構成として、認証連携サーバ2a、認証連携サーバ2b、認証情報検証サーバ3、認証サーバ4b、認証サーバ4aを含む。
さらに、その認証結果を利用する装置として、ユーザ端末8、アプリケーションサーバ1x、および、アプリケーションサーバ1yが存在する。ユーザ端末8は、認証連携システムの他装置との通信を行う装置であり、その通信を実施するWebブラウザ81を備えている。
なお、これらの装置構成については、各装置が物理的に1台の筐体に収容されていてもよいし、複数の装置(認証連携サーバ2や認証情報検証サーバ3など)が物理的に1台の筐体に収容されていてもよい。
以下、本実施形態で使用される各用語を定義する。
【0015】
【表1】

【0016】
表1は、認証チェック用パラメータを示す。この表の列要素は、ユーザ端末8を操作する人間であるユーザごとのパラメータと、認証サーバ4aごとのパラメータと、認証サーバ4bごとのパラメータとを示す。
【0017】
項目「ユーザID」は、ユーザを識別するためのIDであり、ユーザごとの(ユーザ端末8ごとの)ユーザID「taro」の他に、そのユーザID「taro」が使用する認証サーバ4a上の第1ユーザID「taroauth1」と、同じユーザID「taro」が使用する認証サーバ4b上の第2ユーザID「taroauth2」とがそれぞれ登録される。なお、表1の各セル値の2行目以降の英数字表記(taroなど)は、各セル値の1行目で示すパラメータ名称(ユーザID)の具体例である。
【0018】
項目「流用検出用ユーザID」は、ユーザIDのハッシュ値として構成される。このように人間が可読なデータ(taro)から、そのハッシュ値を作成することにより、ハッシュ値がもともと意味する情報を残しつつ、攻撃者による盗み見を困難にする。
【0019】
項目「認証情報」は、認証サーバ4ごとのユーザIDに対応する認証用の入力情報である。
・認証方式が「パスワード認証」のときには、その認証情報が「パスワード(文字列)」である。
・認証方式が「電子証明書認証」のときには、その認証情報が「電子証明書」である。
・認証方式が「生体認証」のときには、その認証情報が「ユーザの生体から(生体センサで測定された値をもとに)生成される情報」である。
【0020】
項目「認証情報ハッシュ値」は、項目「流用検出用ユーザID」と同様に、認証情報をハッシュ化することにより、難読性を高める。第1認証情報から第1ハッシュ値が生成され、第2認証情報から第2ハッシュ値が生成される。
【0021】
項目「秘匿認証情報」は、認証情報またはその認証情報ハッシュ値を入力データとして、秘匿化演算を行うことにより生成されるパラメータである。秘匿化演算は、認証方式により規定される。
・認証方式が「パスワード認証」または「電子証明書認証」のときには、秘匿化演算として「一方向性関数(sha-1やMD5などのハッシュ関数)」の計算結果が秘匿認証情報である。そして、生成された第1秘匿認証情報と第2秘匿認証情報とが一致するときに、同じユーザが複数の認証情報として同じデータを用いていることにより、第1認証情報と第2認証情報が脆弱な認証情報として検出される。
・認証方式が「生体認証」のときには、秘匿化演算「生体情報の相関不変な一方向性変換処理」の計算結果が秘匿認証情報である。なお、一方向性変換処理には、変換用の秘密鍵(認証サーバ4の秘密鍵に流出検出用ユーザIDを加えた文字列)が使用される。そして、生成された第1秘匿認証情報と第2秘匿認証情報との画像処理における類似度が所定値以上であるときに、同じユーザが複数の認証情報として同じデータを用いていることにより、第1認証情報と第2認証情報が脆弱な認証情報として検出される。
【0022】
このように、生成された秘匿認証情報は、通信メッセージに含められ、装置間で伝達される。ユーザのIDや属性情報といったプライバシ情報を別のサービスへ提供するときに、ユーザ認証に使用するパスワードなどの認証情報については特に第三者に漏れないように注意する必要がある。
認証情報ハッシュ値が認証サーバ上で管理されている場合、第三者には内容が分からないようになっていたとしても、第三者はこの状態の認証情報を認証サーバ4に送りつけることで、認証情報の所有者になりすましてユーザ認証を成功させてしまう。
そこで、認証情報を外部へ提供する際に、認証情報や認証情報ハッシュ値の代わりに、表1の秘匿認証情報を提供する。これにより、その秘匿認証情報を第三者が取得したとしても、その秘匿認証情報から認証サーバ4の管理する認証情報を得られず、認証情報の所有者へのなりすましを防止できる。
【0023】
【表2】

【0024】
表2は、表1で定義した各パラメータをもとにした、4種類の認証チェック項目(認可、認証、流用検証、単体検証)を示す。
表2の2行目に示す「認証」は、認証サーバ4ごとに、入力された認証情報をもとに、そのユーザが正当か否かを認証する処理であり、その認証に成功したときには、認証アサーションが発行される。
表2の1行目に示す「認可」は、発行された認証アサーションで示されるユーザ認証状態が、サービスに要するポリシを満たしているときに、サービスの実行を認可する。この「認可」について、1つのサービスを受けるために、複数の認証アサーションを要するポリシとしてもよいし、複数のサービスを受けるために必要な認証アサーションを、サービス間で共有するポリシとしてもよい。
表2の4行目に示す「単体検証」は、「認証」で使用される認証情報を単体としてみたときに、他者に攻撃されやすい認証情報を用いているか否かを検証する処理である。なお、「認可」で使用される認証アサーションは、「単体検証」に合格した認証アサーションだけを「認可」で使用することで、セキュリティ強度を向上できる。
表2の3行目に示す「流用検証」は、「認証」で使用される同じユーザによる複数の認証情報として、同じデータを使い回しているか否かを検証する処理である。「流用検証」に合格した認証アサーションだけを「認可」で使用することで、セキュリティ強度を向上できる。
【0025】
図2は、認証連携システムを構成する各装置の詳細を示す構成図である。なお、以下の説明では、図1と同様に、2つのドメインで同じ構成要素が存在するときには、その構成要素の符号末尾の「a,b」が所属するドメインを示す。例えば、認証状態管理部21aは、ドメインA内の認証連携サーバ2aに含まれ、認証状態管理部21bは、ドメインB内の認証連携サーバ2bに含まれる。
【0026】
アプリケーションサーバ1は、ユーザ端末8からの処理要求を受信し、認証連携サーバ2から認可がでたときに、その処理要求に対応するサービスコンテンツをユーザ端末8へ提供する装置である。なお、図2では、2台のアプリケーションサーバ1x,1yを例示しており、以下のフローチャートなどの説明で、どちらのアプリケーションサーバ1内の構成要素かを示すために、アプリケーションサーバ1内の構成要素を示す符号の末尾に「x」または「y」を付加する。
【0027】
アプリケーションサーバ1は、ユーザ端末8との間で通信を実施し、認可判定結果に基づきアクセス制御を実施するSAML SP部11、ユーザ端末8からのサービス実行パラメータに基づきサービスを実行し、サービスコンテンツをユーザ端末8へ提示したりするWebサーバ12、およびアクセス制御に使用する認可判定結果を格納するアクセステーブル13を備えている。
【0028】
認証連携サーバ2は、ネットワーク5単位で存在し、ユーザ端末8からの処理要求の受信を契機に、認証サーバ4からの認証結果に基づいてユーザ端末8に対するアプリケーションサーバ1へのアクセス認可の可否を判定する装置である。どの認証サーバ4から認証結果を取得するかは、認証連携サーバ2が選択して決定し、ユーザ端末8へ認証の実施を促す。
【0029】
このため、認証連携サーバ2は、認証状態管理部21と、ロケーション管理部22と、ID管理部23と、認可判定部24と、SAML IdP Proxy部25と、認証情報検証依頼部26と、認証状態テーブル27と、認証要求ポリシテーブル28と、認証サーバリスト29とを備えている。
認証状態管理部21は、ユーザ端末8の認証状態およびアプリケーションサーバ1のポリシを管理する。
ロケーション管理部22は、連携する認証サーバ4のURLを管理する。
ID管理部23は、アプリケーションサーバ1上で使用するユーザIDと各々の認証サーバ上で使用するユーザIDを結び付けて管理する。
認可判定部24は、ユーザ端末8の認証状態とアプリケーションサーバ1のポリシを比較することによりアプリケーションサーバ1へのアクセス可否を判定する。
SAML IdP Proxy部25は、ユーザ端末8との通信を実施し他の認証連携サーバ2や認証サーバ4に対しユーザ認証処理を依頼する。
認証情報検証依頼部26は、認証情報検証サーバ3との通信を実施し、認証情報検証サーバ3に対し認証情報の脆弱度判定を依頼する。
認証状態テーブル27は、ユーザ端末8の認証状態を格納する。
認証要求ポリシテーブル28は、アプリケーションサーバ1のポリシを格納する。
認証サーバリスト29は、連携する認証サーバ4のURLを格納する。
【0030】
認証情報検証サーバ3は、ドメイン単位で存在し、認証連携サーバ2から取得した秘匿認証情報および認証情報プロパティにより、ユーザが認証に使用した認証情報が脆弱でないか検証(表2の流用検証、単体検証)するための装置である。なお、認証情報プロパティとは、認証情報が所有する特徴を集めたリストである。特徴の例としては、パスワードの長さやパスワードに使用した文字の種別(英字、数字、記号)などが挙げられる。
【0031】
このため、認証情報検証サーバ3は、流用検出管理部31と、認証情報検証部32と、通信部33と、流用検出用テーブル34とを備えている。
流用検出管理部31は、脆弱度判定の結果脆弱でないと判定した秘匿認証情報を管理する。
認証情報検証部32は、認証連携サーバ2から取得した秘匿認証情報、認証プロパティおよび後記の流用検出用テーブル34に格納されている秘匿認証情報を基に、ユーザが認証に使用した認証情報が脆弱でないか検証する。
通信部33は、認証連携サーバ2との間の通信を実施する。
流用検出用テーブル34は、認証連携サーバ2から取得した秘匿認証情報を格納する。
【0032】
認証サーバ4は、ドメイン単位で存在し、ユーザ端末8との間でユーザ認証を実施し、認証結果および認証を実施したユーザの秘匿認証情報、および認証プロパティを認証連携サーバ経由で認証情報検証サーバ3へ提供する装置である。
【0033】
このため、認証サーバ4は、認証情報管理部41と、認証情報秘匿化部42と、認証部43と、SAML IdP部44と、認証情報テーブル45とを備えている。
認証情報管理部41は、ユーザの認証情報を管理する。
認証情報秘匿化部42は、ユーザの認証情報から秘匿認証情報および認証プロパティを生成する。
認証部43は、ユーザ端末8から取得した認証情報と、後記の認証情報テーブル45に格納されている認証情報とを照合することによりユーザ認証を実施する。
SAML IdP部44は、ユーザ端末8との通信を実施し、認証結果をユーザ端末8経由で認証連携サーバ2へ送信する。
認証情報テーブル45は、ユーザの認証情報を格納する。
【0034】
なお、複数の秘匿認証情報間の照合処理(表2の流用検証)において、<認証情報に対応するユーザ、認証情報から生成された秘匿認証情報>の組み合わせが一致する複数の組が存在したときに、同一の認証情報の流用検出を行うこととしたが、流用検出用の照合対象として、この組み合わせのデータ以外にも、<ユーザを特定できる情報と、そのユーザの認証情報を特定できる情報>であれば、他のデータを用いてもよい。
【0035】
例えば、以下の(手順1〜3)により、<ユーザを特定できる情報と、そのユーザの認証情報を特定できる情報>を生成してもよい。
(手順1)ユーザを特定できる情報として、ユーザID、または、そのユーザが使用するユーザ端末8と認証サーバ4との間で共有するセッションIDを一時ユーザIDとする。なお、セッションIDとは、メッセージの送受信により取得したパラメータを管理する際に必要となるIDである。
(手順2)前記(手順1)で取得したユーザを特定できる情報と認証情報との文字をコロンなどの接続用文字列で連結した文字列を生成する。
(手順3)前記(手順2)で生成した文字列に対して、認証情報秘匿化部42が秘匿化処理を行うことで、ユーザを特定できる情報を含む秘匿認証情報を生成する。
【0036】
なお、(手順1)において、ある認証サーバ4で生成したセッションIDを、別の認証サーバ4でも使用することにより、セッションIDがユーザを特定できるユーザIDの代替データ(一時ユーザID)としての役割を果たす。そのため、ユーザ端末8は新たに認証サーバ4との間でセッションを確立する前に、その確立先とは別の認証サーバ4によって既に生成されたセッションIDを新たなセッションでも使用するように、ユーザ端末8から認証サーバ4への処理要求内(Set-cookieヘッダ)に既に生成されたセッションIDを含めることとする。
【0037】
そして、以下の(手順4)により、複数の秘匿認証情報間の照合処理を実施する。
(手順4)前記(手順3)で生成された秘匿認証情報どうしを認証情報検証部32が照合し、一致する秘匿認証情報を検出したときに、同一ユーザによる認証情報の流用とする。一方、あるユーザと別のユーザとで、偶然に同じ認証情報(パスワード文字列など)を用いていたとしても、(手順2)で生成される文字列は、複数のユーザで互いに異なるため、(手順4)では別々のユーザ間での流用という誤検出は発生しない。
これにより、認証情報検証サーバ3の管理者が不正に同一の秘匿認証情報を結びつけ、ユーザの認証情報を推定し成りすます、といった秘匿認証情報の悪用を防止することができる。
【0038】
【表3】

【0039】
表3は、認証連携サーバ2内の各テーブルのデータ内容の一例を示す。
【0040】
認証要求ポリシテーブル28は、サービスIDと、アプリケーションサーバ1と、ポリシとの対応情報を格納する。
項目「サービスID」は、アプリケーションサーバ1が提供するサービスを特定するためIDを示す。
項目「アプリケーションサーバ」は、項目「サービスID」のサービスを提供するアプリケーションサーバ1を示す。例えば、アプリケーションサーバ1xは、サービスID「第1サービスID」のサービスを提供し、アプリケーションサーバ1yは、サービスID「第2サービスID」のサービスを提供する。
項目「ポリシ」は、認証要求ポリシの略であり、項目「サービスID」のサービスをユーザ端末8に提供するために必要な認証方式(パスワード認証、電子証明書認証、生体認証など)の種別とその認証回数との組を示す。
【0041】
認証状態テーブル27は、ユーザIDと、そのユーザが認証(表2の認証)に成功した結果(ユーザ認証状態)を管理する。例えば、ユーザ「taro」には、2回の認証に成功した結果である認証アサーション(第1パスワード認証、第2パスワード認証)が対応づけられている。
認証サーバリスト29は、認証サーバ4のURLと、その認証サーバ4が提供する認証方式と、対応サービス数とを対応づけて管理する。項目「対応サービス数」とは、認証サーバ4を利用可能なアプリケーションサーバ1の数を示し、このアプリケーションサーバ1の数が多い順に、どの認証サーバ4を利用するか決定される。
【0042】
【表4】

【0043】
表4は、流用検出用テーブル34のデータ内容の一例を示す。流用検出用テーブル34は、ユーザIDに対応する流用検出用ユーザIDごとに、そのユーザが認証を実施した認証方式と、その認証結果から生成された秘匿認証情報とを対応づけている。なお、ユーザIDと流用検出用ユーザIDとの対応情報は、ID管理部23によって管理される。
【0044】
【表5】

【0045】
表5は、認証サーバ4ごとに格納される認証情報テーブル45のデータ内容の一例を示す。認証情報テーブル45には、認証サーバ4のユーザIDごとに、そのユーザIDに対応する認証情報から生成されたハッシュ値が対応づけられている。
認証情報テーブル45aには、第1ユーザIDと第1認証情報から生成された第1ハッシュ値との対応データが格納されている。
認証情報テーブル45bには、第2ユーザIDと第2認証情報から生成された第2ハッシュ値との対応データが格納されている。
この第1ユーザIDと第2ユーザIDとは、同じユーザID「taro」によって使用されている。
【0046】
図3は、認証連携システムを構成する各計算機を示すハードウェア構成図である。
計算機9は、CPU91と、メモリ92と、ハードディスクなどの外部記憶装置93と、インターネットやLANなどのネットワーク99aを介して他の装置と通信を行うための通信装置94と、キーボードやマウスなどの入力装置95と、モニタやプリンタなどの出力装置96と、可搬性を有する記憶媒体99bの読取装置97とが、内部バス98を介して接続されている。記憶媒体99bは、例えば、ICカードやUSBメモリである。
【0047】
計算機9は、図2で示した各処理部の機能を実現するためのプログラムをメモリ92上にロードし、CPU91により実行する。そのプログラムは、あらかじめ、計算機9の外部記憶装置93に格納されていてもよいし、実行時に、読取装置97や通信装置94を介して、他の装置から外部記憶装置93にダウンロードされてもよい。
そして、プログラムは一旦外部記憶装置93に格納された後、そこからメモリ上にロードされてCPU91に実行されてもよいし、あるいは外部記憶装置93に格納されることなく、直接メモリ上にロードされて、CPU91に実行されてもよい。
【0048】
図4は、ユーザID「taro」が第1サービスIDのサービスコンテンツを使用する例を示すフローチャートである。図4の詳細は後記するが、図4の処理の概要は、以下の通りである。
まず、認証要求ポリシテーブル28で「1回のパスワード認証」が必要であるので、その「パスワード認証」を得るための認証サーバ4として、認証サーバリスト29から対応サービス数が最も多い(79個)認証サーバ4bのURL「http://demosite2.com/idpw/」を取得する。
そして、認証サーバ4bによる第2パスワード認証に成功し(表2の認証)、かつ、その第2パスワード認証に使用された第2認証情報への検証(表2の単体検証、流用検証)が成功したときには、認証状態テーブル27内のユーザID「taro」に対応するユーザ認証状態が「(未認証)」から「第2パスワード認証」へと更新される。これにより、ユーザ認証状態「第2パスワード認証」がポリシ「1回のパスワード認証」を満たすので、ユーザID「taro」は、第1サービスIDのサービスコンテンツをアプリケーションサーバ1xから使用できる。
【0049】
【表6】

【0050】
表6は、図4以降で説明する各フローチャート内で使用される通信メッセージごとの仕様を示す。
表6の名称で示される各データは、そのプロトコルの種別とそのプロトコルのタイプで特定されるフォーマットの通信メッセージに含まれて送信される。
プロトコルの種別として、HTTP(Hypertext Transfer Protocol)は、標準化団体IETFにおいてRFC2616で定義されている。
SOAP(Simple Object Access Protocol)は、標準化団体W3Cによって策定され、他の通信機器上にあるデータやサービスを呼び出すための通信プロトコルであり、通信機器間で送受されるメッセージはXML(Extensible Markup Language)で記述される。
【0051】
検証要求は、<authResultVerifyRequest>〜</authResultVerifyRequest>内に、以下の順序でタグが列挙されて構成される。
<authUserID>「第1ユーザID(taroauth1)」</authUserID>
<SAML:Assertion>「認証サーバ4が発行した認証結果」</SAML:Assertion>
<credential>「秘匿認証情報」</credential>
<credentialProperties>「認証情報プロパティ」</credentialProperties>
【0052】
検証応答は、<authResultVerifyResponse>〜</authResultVerifyResponse>内に、以下の順序でタグが列挙されて構成される。
<result>「脆弱性検証の結果」</result>
なお、脆弱性検証の結果には、脆弱でない「invulnerable」または脆弱である「vulnerable」の値が格納される。
【0053】
【表7】

【0054】
表7は、後記する図4での各ステップごとの通信メッセージの内容(種別、クエリ、セッションID)を示す。なお、図4での「サービスID」とは、アプリケーションサーバ1xが提供する第1サービス用のIDである。
本実施形態では、ユーザ端末8と他装置との間のデータのやりとりに、HTTPバインディングを用いた一例を説明する。
セッションIDは、ユーザ端末8との間で共有される接続識別子(Set-Cookieの値)であり、転送応答の送信元装置が新たに作成してユーザ端末8に通知した後(例えば、S302で最初に登場する「c1」)、ユーザ端末8からそのセッションIDの通知を受ける(例えば、S319で処理要求に含まれる「c1」)。
なお、本明細書の各フローチャートでは、セッションごとに、そのセッションの活性化期間を示す破線の矩形も図示している。例えば、図4のユーザ端末8の動作において、開始点(S301)から終了点(S320)までの期間を破線矩形で示しているが、この破線矩形で示される期間には、セッションID=「c1」のセッションが活性化している。
【0055】
転送応答の送信元装置は、転送応答の受信装置(ユーザ端末8)に対して、次に送信する処理要求の送信先を転送先(Locationヘッダの値)として指定する。転送応答の受信装置は、その転送応答の送信元装置の識別子を次に送信する処理要求の転送元(Refererヘッダの値)として指定する。これにより、処理要求の受信装置は、転送元の装置を特定することができる。
【0056】
図4に戻り、S301として、ユーザ端末8のWebブラウザ81は、ユーザからの操作にしたがって、処理要求をアプリケーションサーバ1xに送信する。
S302として、アプリケーションサーバ1xのSAML SP部11xは、転送応答をWebブラウザ81に送信する。この転送応答は、ユーザ端末8が認証済みでないことを示すメッセージであり、認証済みでないことは、アプリケーションサーバ1xがアクセステーブル13xから、ユーザ端末8のユーザIDおよび認可判定結果の登録を見つけられなかったことで確認される。
【0057】
S303として、Webブラウザ81は、処理要求を認証連携サーバ2aに送信する。
S304として、ロケーション管理部22aは、連携する認証サーバ4の認証方式を基に、認証サーバ4のURLについて認証サーバリスト29aを検索することで、呼び出す認証サーバ4を決定する。この決定された認証サーバ4は、S303の処理要求を実現するために不足分の認証を行う相手である。
S305として、認証連携サーバ2aのSAML IdP Proxy部25aは、転送応答をWebブラウザ81に送信する。
【0058】
S306として、Webブラウザ81は、処理要求を認証連携サーバ2bに送信する。
S307として、SAML IdP Proxy部25bは、転送応答をWebブラウザ81に送信する。なお、ロケーション管理部22bは、認証サーバ4bのURLを解析することで、認証サーバ4bのドメインが他ドメイン(ドメインB)上に存在する旨を確認する。
【0059】
S308として、Webブラウザ81は、処理要求を認証サーバ4bに送信する。
S309として、認証サーバ4bの認証部43bは、ユーザ端末8から認証情報を取得し、ユーザ認証を実施する。認証部43bは、認証情報テーブル45b内に第2ユーザIDと第2ハッシュ値との対応データが存在するので、認証成功の旨を示すSAML2.0で規定された認証アサーションを作成し、これに第2認証結果を含める。
認証情報秘匿化部42bは、認証情報テーブル45bの第2ハッシュ値を秘匿化することで、第2秘匿認証情報を生成する。
認証情報管理部41bは、第2認証情報から特徴量を抽出し、第2認証情報プロパティを生成する。
S310として、SAML IdP部44bは、転送応答(生成された第2秘匿認証情報と、第2認証情報プロパティとを含む)をWebブラウザ81に送信する。
【0060】
S311として、Webブラウザ81は、処理要求を認証連携サーバ2bに送信する。
S312として、SAML IdP Proxy部25bは、転送応答をWebブラウザ81に送信する。
S313として、Webブラウザ81は、処理要求を認証連携サーバ2aに送信する。
S314として、認証情報検証依頼部26aは、検証要求を認証情報検証サーバ3に送信する。
S315として、流用検出管理部31は、脆弱性の検証を実施する。
S316として、通信部33は、検証応答を認証連携サーバ2aに送信する。
S317として、認可判定部24aは、認可の判定を実施する。
【0061】
S318として、SAML IdP Proxy部25aは、転送応答をWebブラウザ81に送信する。
S319として、Webブラウザ81は、処理要求をアプリケーションサーバ1xに送信する。
S320として、SAML SP部11xは、成功応答をWebブラウザ81に送信する。成功応答のBODY部には、S301のサービス実行パラメータからWebサーバ12xによって生成されるサービスコンテンツが含まれている。Webブラウザ81は、受信した成功応答内のサービスコンテンツを処理し、Webブラウザ81上の画面に表示する。
【0062】
図5は、図4の実行後に、ユーザID「taro」が第2サービスIDのサービスコンテンツを使用する例を示すフローチャートである。図5は、ユーザが自ドメインの認証サーバ4aを利用して認証を実施し、アプリケーションサーバ1yが提供するサービスを利用する場合の動作を示すフローチャートである。図5の詳細は後記するが、図5の処理の概要は、以下の通りである。
まず、認証要求ポリシテーブル28で「2回のパスワード認証」が必要であるので、ユーザ認証状態「第2パスワード認証」だけでは、1回分のパスワード認証が不足する。そこで、2回目のパスワード認証として、認証サーバリスト29(表3)から対応サービス数が2番目に多い(57個)認証サーバ4aのURL「http://demosite1.com/idpw/」を取得する。
そして、認証サーバ4aによる第1パスワード認証に成功し(表2の認証)、かつ、その第1パスワード認証に使用された第2認証情報への単体検証と、第1認証情報および第2認証情報の組み合わせへの流用検証が成功したときには、認証状態テーブル27(表3)内のユーザID「taro」に対応するユーザ認証状態が「第2パスワード認証」から「第1パスワード認証、第2パスワード認証」へと更新される。これにより、ユーザ認証状態「第1パスワード認証、第2パスワード認証」がポリシ「2回のパスワード認証」を満たすので、ユーザID「taro」は、第2サービスIDのサービスコンテンツをアプリケーションサーバ1yから使用できる。
【0063】
【表8】

【0064】
表8は、後記する図5での各ステップごとの通信メッセージの内容(種別、クエリ、セッションID)を示す。なお、図5での「サービスID」とは、アプリケーションサーバ1yが提供する第2サービス用のIDである。
【0065】
S401として、ユーザ端末8のWebブラウザ81は、処理要求をアプリケーションサーバ1yに送信する。
S402として、アプリケーションサーバ1yのSAML SP部11yは、転送応答をWebブラウザ81に送信する。ここで、SAML SP部11yは、S302と同様に、アクセステーブル13yを参照し、ユーザ端末8が認証済でないことを確認する。
【0066】
S403として、Webブラウザ81は、処理要求を認証連携サーバ2aに送信する。
S404として、認証連携サーバ2aのロケーション管理部22aは、呼び出す認証サーバ4を決定する。
S405として、SAML IdP Proxy部25aは、転送応答をWebブラウザ81に送信する。
【0067】
S406として、Webブラウザ81は、処理要求を認証サーバ4aに送信する。
S407として、認証サーバ4aの認証部43aはユーザ端末8から認証情報を取得し、ユーザ認証を実施する。認証部43aは、認証情報テーブル45a内に第1ユーザIDと第1ハッシュ値との対応データが存在するので、認証成功の旨を示すSAML2.0で規定された認証アサーションを作成し、これに第1認証結果を含める。
S408として、SAML IdP部44aは、転送応答をWebブラウザ81に送信する。なお、S408の転送応答に含まれる各パラメータは、以下に示すように作成される。認証情報秘匿化部42aは、認証情報テーブル45aの第1ハッシュ値を秘匿化することで、第1秘匿認証情報を生成する。認証情報管理部41aは、第1認証情報から特徴量を抽出し、第1認証情報プロパティを生成する。
【0068】
S409として、Webブラウザ81は、処理要求を認証連携サーバ2aに送信する。
S410として、SAML IdP Proxy部25aは、検証要求を認証情報検証サーバ3に送信する。
S411として、流用検出管理部31は、脆弱性の検証を実施する。
S412として、通信部33は、検証応答を認証連携サーバ2aに送信する。
S413として、認可判定部24aは、認可の判定を実施する。
S414として、SAML IdP Proxy部25aは、転送応答をWebブラウザ81に送信する。
【0069】
S415として、Webブラウザ81は、処理要求をアプリケーションサーバ1yに送信する。
S416として、Webサーバ12yは、サービスを実行する。
S417として、SAML SP部11yは、成功応答をWebブラウザ81に送信する。成功応答のBODY部には、S401のサービス実行パラメータからWebサーバ12yによって生成されるサービスコンテンツが含まれている。Webブラウザ81は、受信した成功応答内のサービスコンテンツを処理し、Webブラウザ81上の画面に表示する。
【0070】
図6は、図4および図5の処理における認証連携サーバ2の動作を示すフローチャートである。認証連携サーバ2は、ユーザ端末8に認証が必要か否かを判定し、その結果に基づきアプリケーションサーバへのアクセス認可判定を実施する。図6では、図4および図5で説明した以下の4つのケースについて、説明する。
(ケース1)S303の処理要求からS312の転送応答まで
(ケース2)S313の処理要求からS318の転送応答まで
(ケース3)S403の処理要求からS408の転送応答まで
(ケース4)S409の処理要求からS414の転送応答まで
【0071】
認証連携サーバ2のSAML IdP Proxy部25は、4つの各ケースの処理要求を受信し(S501)、その処理要求に含まれるメッセージパラメータを取得し(S502)、メモリ上に格納された内部状態が認証結果待ちであるか否かを判定する(S503)。S503でYesなら(ケース2,ケース4)S509に進み、Noなら(ケース1,ケース3)S504へ進む。
【0072】
S504として、認証状態管理部21は、サービスID(第1サービスID)を基に、ポリシについて認証要求ポリシテーブル28を検索し、アプリケーションサーバ1のポリシ(ケース1なら「1回のパスワード認証」、ケース3なら「2回のパスワード認証」)を取得する。
S505として、認証状態管理部21は、ユーザID(taro)を基に、認証状態テーブル27を検索し、ユーザ端末8の認証状態(ケース1では「未認証」、ケース3では「第2パスワード認証」)を取得する。
S506として、認可判定部24は、S505の認証状態がS504のポリシを満足しているか否かを判定する。この判定は、認証状態テーブル27のポリシに記載されているすべての認証(認証種別ごとの認証回数)を、ユーザ認証状態が満足しているか否かにより、判定される。S506でYesなら(ケース2、ケース4)S507へ進み、Noなら(ケース1、ケース3)S518へ進む。
S507では、認可判定部24は、認可判定結果(認可)を生成し、処理を終了する。
【0073】
S509では、SAML IdP Proxy部25は、S501のメッセージから認証結果を取得し、その取得した認証結果が認証成功か否かを判定する(S510)。S510でYesなら、SAML IdP Proxy部25は、ID管理部23に対して、ユーザ端末8のユーザIDを認証情報検証サーバ3用の流出検出用ユーザIDに変換する処理を実行させてから、S511へ進む。S510でNoならS514へ進む。
【0074】
S511では、SAML IdP Proxy部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の認証状態を更新する。
【0075】
認証状態管理部21は、認証を依頼した各認証サーバ4から、認証結果が全て戻ってきたか否かを判定する(S514)。S514でYesなら、認証状態管理部21は、内部状態をリセットし(S515)、認証回数カウンタの値を1増やし(S516)、S504へ進む。S514でNoなら、終了する。
【0076】
S518として、認証状態管理部21は、メモリ上に格納された認証回数カウンタが規定値(例えば3回)以上であるか否かを判定する。S518でYesならS519へ進み、NoならS520へ進む。
S519では、認証状態管理部21は、認可判定結果(不認可)を作成し、終了する。
【0077】
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として、SAML IdP Proxy部25は、転送応答を作成して、ユーザ端末8へ送信して認証依頼するとともに(ケース1ではS305、ケース3ではS405の処理)、S503で判定される内部状態の値を認証結果待ちと設定する(S524)。
【0078】
図7は、図4および図5の処理における認証情報検証サーバ3の動作を示すフローチャートである。このフローチャートの概要は、認証情報検証サーバ3は、検証要求(図6の説明でのケース2ではS314で送信、図6の説明でのケース4ではS410で送信)への検証処理を実行し(ケース2ではS315で実行、ケース4ではS411で実行)、その結果を検証応答(ケース2ではS316で送信、ケース4ではS412で送信)として送信する処理である。
【0079】
通信部33は、認証連携サーバ2から検証要求を受信し(S601)、その検証要求内のメッセージパラメータを取得する(S602)。
・S601の検証要求として、ケース2の場合は、「認証結果A2、流用検出用ユーザID、第2秘匿認証情報、第2認証情報プロパティ」というメッセージパラメータが取得される(表7参照)。
・S601の検証要求として、ケース4の場合は、「認証結果A3、流用検出用ユーザID、第1秘匿認証情報、第1認証情報プロパティ」というメッセージパラメータが取得される(表8参照)。
【0080】
流用検出管理部31は、S602で取得した流用検出用ユーザIDを検索キーとして流用検出用テーブル34から検索し、該当するレコードの秘匿認証情報列に格納されている秘匿認証情報を検索結果として取得する(S603)。そして、流用検出管理部31は、S602で取得した秘匿認証情報と、S603で取得した秘匿認証情報とを照合することで、検証要求内の秘匿認証情報が流用検出用テーブル34内に存在するか否かを判定する(S604)。このS604の判定処理は、換言すると、同じユーザによる同じ認証情報の流用の有無を判定する処理である。
【0081】
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へ進む。
【0082】
S610では、流用検出管理部31は、流用検出用テーブル34に、S602で取得したメッセージパラメータに関するレコード(秘匿認証結果)を追加する。
・S610の追加処理として、ケース2の場合は、S602で取得した「第2秘匿認証情報」が流用検出用テーブル34に追加された結果、流用検出用テーブル34の秘匿認証情報は、「第0秘匿認証情報、第2秘匿認証情報」へと更新される。
・S610の追加処理として、ケース4の場合は、S602で取得した「第1秘匿認証情報」が流用検出用テーブル34に追加された結果、流用検出用テーブル34の秘匿認証情報は、「第0秘匿認証情報、第1秘匿認証情報、第2秘匿認証情報」へと更新される。
【0083】
認証情報検証部32は、S602で取得した認証情報プロパティから認証情報の脆弱度を計算する(S611)。そのため、まず、認証情報がパスワードであるときには、その文字列の長さ、使用している文字の種類、などの特徴ごとに脆弱値を計算し、それらの脆弱値の合計を脆弱度として算出する。
認証情報検証部32は、S611で算出した脆弱度が閾値を超えているか否か(脆弱度≦閾値)を判定する(S612)。S612でYesならS613へ進み、NoならS605へ進む。
【0084】
S613として、認証情報検証部32は、検証結果(非脆弱を示す「invulnerable」)を作成する。
S616として、通信部33は、S605またはS613で作成した検証結果を含む検証応答を作成し、認証連携サーバ2へ送信する。なお、S616として、ケース2の場合は、S316の検証応答が送信され、ケース4の場合は、S412の検証応答が送信される。
【0085】
以上、第1実施形態で説明した認証連携システムでは、認証情報検証サーバ3が第1秘匿認証情報と第2秘匿認証情報とを照合することによって、同じユーザによって使用される2つの認証情報(第1認証情報、第2認証情報)間の流用を検証する。これにより、流用が検知された脆弱な認証情報によるユーザ認証を無効にすることで、複数のユーザ認証の結果を組み合わせて用いるときに、セキュリティ強度の低下を防止することができる。
【0086】
以下、第2実施形態について、説明する。第2実施形態は、複数のシングルサインオンシステムを連携させる形態である。
【0087】
図8は、第2実施形態の認証サーバ連携システムの構成図である。認証サーバ連携システムは、ドメインをまたがったシングルサインオンを提供する形態である。
ユーザ端末8が認証サーバ4に対して認証を行うときに、そのユーザ端末8と認証サーバ4とが異なるドメインに属している場合、ユーザ端末8が属するドメインの認証プロキシサーバ6が、そのユーザ端末8を代行して他ドメインの認証サーバ4と認証を行う。
以下、ユーザ端末8がドメインA(ネットワーク5a)に属し、認証サーバ4がドメインB(ネットワーク5b)に属している例を示す。認証サーバ4bとの認証に成功したユーザ端末8は、ドメインB内のアプリケーションサーバ1からサービスを受けることができる。
【0088】
第1実施形態と第2実施形態とで共通する構成については、同じ符号を付し、説明を省略する。また、第1実施形態と同様に、以下の説明では、図1と同様に、2つのドメインで同じ構成要素が存在するときには、その構成要素の符号末尾の「a,b」が所属するドメインを示す。第1実施形態と第2実施形態とを比較すると、以下のように構成の(相違点1)〜(相違点3)がある。
【0089】
(相違点1)として、アプリケーションサーバ1の接続先を、ドメインAからドメインBに変更する。
【0090】
(相違点2)として、認証情報検証サーバ3を省略する。さらに、認証連携サーバ2内の認証連携サーバ2と通信するための認証情報検証依頼部26も併せて省略する。
よって、第1実施形態で記載されていた認証連携サーバ2による検証処理は、第2実施形態では、省略される。具体的には、検証要求(S314,S410)→検証処理(S315,S411)→検証応答(S316,S412)を省略するとともに、S502に含まれる認証結果が成功であるときには(S510,Yes)、検証要求を行うことなく(S511,S512の省略)、その認証結果をユーザの認証状態として更新する(S513)。
【0091】
(相違点3)として、認証プロキシサーバ6を新たにドメインAに追加する。なお、認証プロキシサーバ6は、ドメインAに1台配置される構成の他に、ドメインごとに1台ずつ配置されていてもよいし、認証プロキシサーバ6と認証連携サーバ2とが同じ筐体内に配備されていてもよい。
【0092】
図9は、第2実施形態の認証サーバ連携システムを構成する各装置の構成図である。第1実施形態と同じ構成の装置については、図示を省略する。
【0093】
認証プロキシサーバ6は、ネットワーク5aからネットワーク5bへのアクセスを制御することで、ユーザ端末8の代理としてネットワーク5b上でユーザ認証を実施する。
このため、認証プロキシサーバ6は、SAML SP部61と、認証情報連携部62と、SAML ECP部63と、認証連携テーブル64とを有する。
SAML SP部61は、認証連携サーバ2から認可判定結果を取得し、ネットワーク5aからネットワーク5bへのアクセスを制御する。
認証情報連携部62は、認証連携サーバ2から認証結果や秘匿認証情報を取得し、ネットワーク5bにおけるユーザ認証でそれらを使用する。
SAML ECP部63は、ユーザ端末8に代わりネットワーク5b上でのユーザ認証を実施する。
【0094】
さらに、認証連携サーバ2に対して、認証情報提供部76を新たに追加する。この認証情報提供部76は、認証サーバ4が発行した認証結果や秘匿認証情報を認証プロキシサーバ6へ送信する。
【0095】
【表9】

【0096】
表9に示す認証連携テーブル64には、アクセス制御に必要な情報やネットワーク5b上でのユーザ認証で使用する情報として、ユーザIDと、アプリケーションサーバ1のURLと、認証連携と、提供種別と、認証方式と、認可判定結果との対応情報が格納される。
項目「ユーザID」は、アプリケーションサーバ1を利用する際に使用するユーザIDを格納する。
項目「アプリケーションサーバURL」は、アプリケーションサーバ1のURLを格納する。
項目「認証連携有無」は、ネットワーク5a上の認証サーバ4における認証結果や認証サーバ4aに登録されている認証情報を、別のネットワーク上の認証サーバ4に提供するか否かを示すフラグを格納する。
項目「提供種別」は、別のネットワーク上の認証サーバ4に対して提供する情報の種類(認証情報/認証結果)を格納する。
項目「認証方式」は、アプリケーションサーバ1が要求するユーザ認証の認証方式を格納する。
項目「認可判定結果」は、認証連携サーバ2aが発行した認可判定結果を格納する。
【0097】
【表10】

【0098】
表10は、第2実施形態での説明用パラメータ例を示す。表1と比較すると、第1ユーザIDおよび第2ユーザIDそれぞれの認証情報とその秘匿認証情報が、表1では互いに異なるデータであるのに対し、表10では互いに同じデータである。
つまり、第1実施形態では、双方の秘匿認証情報が不一致であることが望ましい(同一ユーザについて認証情報の流用を行っていない)のに対し、第2実施形態では、双方の秘匿認証情報が一致であることが望ましい(同一ユーザが複数のドメインについて、それぞれ認証に成功する)。
さらに、第2実施形態では、認証プロキシサーバ6の外部記憶装置には、認証サーバ4aの第1公開鍵証明書、および、認証サーバ4bの第2公開鍵証明書が、それぞれ保管されている。
【0099】
認証プロキシサーバ6は、以下の(手順1)〜(手順3)で、ユーザ端末8がアプリケーションサーバ1のサービスを利用できるように制御する(図8参照)。これにより、ユーザ端末8は、自らの認証情報を認証サーバ4bに入力しなくても済む。
(手順1)ネットワーク5a(ユーザ端末8)からネットワーク5b(アプリケーションサーバ1)へのアクセス(サービス利用)において、ユーザ認証が必要と判断する。
(手順2)認証連携サーバ2aおよび認証サーバ4aと連携してユーザ認証を実施する。
(手順3)認証サーバ4aから取得した秘匿認証情報を認証サーバ4bへ提示することにより、ネットワーク5b上で、ユーザ端末8に代わり認証サーバ4bとの間でユーザ認証を実施する。
【0100】
【表11】

【0101】
表11は、第2実施形態でやりとりされる通信メッセージ種別のリストを示す。
【0102】
表11の1行目に示される秘匿認証情報要求は、<assertionRequest>〜</assertionRequest>内に、以下の順序でタグが列挙されて構成される。
<samlp:ArtifactResolve>「チケット格納データ(認証連携サーバ2が発行した認証チケットを含む)」</samlp:ArtifactResolve>
<pkCertificate>「認証サーバ4の公開鍵証明書」</pkCertificate>
ここで、認証チケットとは、例えば、SAML2.0で規定されたアーティファクトであり、その認証チケットごとにあらかじめ対応付けされているチケット対応データ(ユーザ端末8の認証情報など)の取得処理に使用される。
また、表11の3行目に示される秘匿化要求は、<credentialRequest>〜</credentialRequest>内に、秘匿認証情報要求と同じデータ(チケット格納データ、公開鍵証明書)が含まれる。
【0103】
表11の4行目に示される秘匿化応答は、<credentialResponse>〜</credentialResponse>内に、以下の順序でタグが列挙されて構成される。
<result>「秘匿認証情報の取得に成功したか否かを示す情報(成功なら「success」、失敗なら「fail」)」</result>
<credential>「秘匿認証情報」</credential>
【0104】
表11の2行目に示される秘匿認証情報応答は、<assertionResponse>〜</assertionResponse>内に、以下の順序でタグが列挙されて構成される。
<result>「秘匿認証情報の取得に成功したか否かを示す情報(成功なら「success」、失敗なら「fail」)」</result>
<type>「下記のcredentialタグ内に含まれる情報の種類(認証結果を示す「assertion」または秘匿認証情報を示す「credential」)」</type>
<credential>「認証結果または秘匿認証情報」</credential>
【0105】
図10は、第2実施形態におけるドメインA側で開始される処理を示すフローチャートである。このフローチャートの開始時点では、表9の認証連携テーブル64内のユーザID「taro」の認可判定結果は、記載されていない。ユーザID「taro」とは、アプリケーションサーバ1が提供するサービス用のユーザIDである。
【0106】
【表12】

【0107】
表12は、後記する図10での各ステップごとの通信メッセージの内容(種別、クエリ、セッションID)を示す。
【0108】
S901として、ユーザ端末8のWebブラウザ81は、ユーザ端末8のユーザからの操作を受け付けて作成した処理要求を認証プロキシサーバ6に送信する。
S902として、認証プロキシサーバ6のSAML SP部61は、転送応答をユーザ端末8に送信する。
S903として、Webブラウザ81は、処理要求を認証連携サーバ2aに送信する。
S904として、認証連携サーバ2aのSAML IdP Proxy部25aは、S304と同様にして、呼び出す認証サーバ4aを決定する。
S905として、SAML IdP Proxy部25aは、転送応答をユーザ端末8に送信する。
【0109】
S906として、Webブラウザ81は、処理要求を認証サーバ4aに送信する。
S907として、認証サーバ4aの認証部43aは、ユーザ端末8から認証情報を取得し、ユーザ認証を実施する。ユーザ認証では、認証情報テーブル45aから、第1ユーザIDと、対応する認証情報(ユーザ端末8から取得)との組み合わせのレコードが発見できたときに、認証成功とする。
S908として、SAML IdP部44aは、転送応答(認証結果A1、認証チケットT1、第1ユーザIDを含む)をユーザ端末8に送信する。認証結果A1とは、SAML2.0で規定された認証アサーションである。認証チケットT1とは、SAML2.0で規定されたアーティファクトである。認証部43aは、認証チケットT1とユーザ端末8の認証情報とを結び付けて、メモリへ一時保存する。
【0110】
S909として、Webブラウザ81は、処理要求を認証連携サーバ2aに送信する。SAML IdP Proxy部25aは、ユーザ端末8から処理要求を受信すると、第1実施形態におけるS317やS413と同様に、認証プロキシサーバ6に対する認可判定結果(認可)を生成する。また、認証情報連携部62aは、SAML2.0で規定されたアーティファクトを認証チケットT2として生成すると共に、メモリへ認証チケットT2と認証サーバ4aが発行した認証結果とを結び付けて一時保存する。
【0111】
S910として、SAML IdP Proxy部25aは、転送応答をユーザ端末8に送信する。
S911として、Webブラウザ81は、処理要求を認証プロキシサーバ6に送信する。SAML SP部61は、その処理要求を受信し、メッセージパラメータを取得して、メモリへ保存する。
S912として、SAML SP部61は、ドメインBへのサービス要求をネットワーク5bに送信し、アプリケーションサーバ1からサービスの実行結果であるサービスコンテンツを取得する。
S913として、SAML SP部61は、成功応答をユーザ端末8に送信する。Webブラウザ81は、受信した成功応答内のサービスコンテンツを処理し、ユーザ端末8の画面に表示する。
【0112】
図11は、第2実施形態におけるドメインBへのサービス要求(S912)を契機に、ドメインB側で開始される処理を示すフローチャートである。
【0113】
【表13】

【0114】
表13は、後記する図11での各ステップごとの通信メッセージの内容(種別、クエリ、セッションID)を示す。
【0115】
S1001として、SAML ECP部63は、処理要求をアプリケーションサーバ1に送信する。
S1002として、SAML SP部11は、ユーザIDおよびその認可判定結果がアクセステーブル13には登録されていない(つまり、ユーザ端末8が認証済ではない)ことを確認すると、転送応答を認証プロキシサーバ6に送信する。
S1003として、SAML ECP部63は、処理要求を認証連携サーバ2に送信する。
S1004として、SAML IdP Proxy部25bは、S404と同様にして、呼び出す認証サーバ4bを決定する。
S1005として、SAML IdP Proxy部25bは、転送応答を認証プロキシサーバ6に送信する。
【0116】
認証情報連携部62は、S1005の転送応答を受信すると、認証連携テーブル64のうち、ユーザIDおよびアプリケーションサーバ1のURLが格納されている行について、認証連携有無レコードのセルが「有」、かつ提供種別レコードのセルが「認証情報」であるか否かを判定する。このS1005の受信時には、認証連携テーブル64に該当する行が存在する(判定がYes)なので、認証情報連携部62は、認証プロキシサーバ6の外部記憶装置に保存されている、認証サーバ4bの公開鍵証明書を取得する。
SAML SP部61は認証チケットT2を含めたSAML2.0 Artifact Resolution Protocolのチケット格納データを作成する。
【0117】
S1006として、SAML SP部61は、秘匿認証情報要求(作成したチケット格納データを含む)を認証連携サーバ2aに送信する。
SAML IdP Proxy部25aは、受信した秘匿認証情報要求に公開鍵証明書が含まれていることを解析すると、認証サーバ4aから取得した認証チケットT1を含めたチケット格納データを作成する。
一方、秘匿認証情報要求に公開鍵証明書が含まれていない場合、認証情報連携部62aは、認証チケット2に結び付けてメモリに一次保存している認証結果を取得し、認証プロキシサーバ6へ返信する。
【0118】
S1007として、SAML IdP Proxy部25aは、秘匿化要求(作成したチケット格納データを含む)を認証サーバ4aに送信する。
SAML IdP部44aは、認証連携サーバ2aから秘匿化要求を取得すると、認証チケットT1に結び付けてメモリに一次保存しているユーザ端末8の認証情報を取得する。
S1008として、認証情報秘匿化部42aは、秘匿化要求に含まれる認証サーバ4bの公開鍵証明書内にある公開鍵を用い、ユーザ端末8の認証情報を暗号化することにより、秘匿認証情報を生成する。
【0119】
SAML IdP部44aは、S1008で作成された秘匿認証情報を含めたSAML2.0 Artifact Resolution Protocolのチケット対応データを作成する。
S1009として、SAML IdP部44aは、秘匿化応答(作成したチケット対応データを含む)を認証連携サーバ2aに送信する。
【0120】
SAML IdP Proxy部25aは、受信した秘匿化応答内の秘匿認証情報を含めたチケット対応データを新たに作成する。
S1010として、SAML IdP Proxy部25aは、秘匿認証情報応答(作成したチケット対応データを含む)を認証プロキシサーバ6に送信する。
S1011として、SAML SP部61は、処理要求(SAML SP部61が秘匿認証情報応答内のチケット対応データから取得した秘匿認証情報を含む)を認証サーバ4bに送信する。
【0121】
S1012として、認証部43bは、認証プロキシサーバ6から取得した秘匿認証情報を認証サーバ4bの秘密鍵を用いて復号し、得られた認証情報を用いてユーザ認証を実施する。認証情報テーブル45aに登録されているユーザ端末8の認証情報(パスワード)と、秘匿認証情報を復号して得られた認証情報(パスワード)とが同じであるときには、ユーザ認証に成功する。認証部43bは、認証に成功したときには、認証結果A2を含める認証アサーションを作成する。
【0122】
S1013として、SAML IdP部44bは、転送応答を認証プロキシサーバ6に送信する。
S1014として、SAML ECP部63は、処理要求を認証連携サーバ2に送信する。
S1015として、S317やS413と同様に、SAML IdP Proxy部25bは、認可判定を実施する。
S1016として、SAML IdP Proxy部25bは、転送応答を認証プロキシサーバ6に送信する。
S1017として、SAML ECP部63は、処理要求をアプリケーションサーバ1に送信する。
S1018として、SAML SP部11は、成功応答(Webサーバ12がS1017の処理要求に含まれるサービス実行パラメータから作成したサービスコンテンツを含む)を認証プロキシサーバ6に送信する。
SAML ECP部63は、アプリケーションサーバ1から成功応答を受信すると、その成功応答内のサービスコンテンツを含めて成功応答を生成し、ユーザ端末8へ送信する(S913)。
【0123】
なお、S901〜S912を実行した後で、S1001を開始する代わりに、以下の(手順1)〜(手順4)を順に実行してもよい。
(手順1)S901を実行
(手順2)S1001からS1005までを実行
(手順3)S902からS911までを実行
(手順4)S1006以降を実行
【0124】
図12は、SAML SP部61が実行する各処理を示すフローチャートである。この図12の説明では、動作主体がすべてSAML SP部61であるので、その旨を各処理の説明から省略する。
以下に示すように、SAML SP部61は、S1101〜S1107を実行することで、S901の処理要求の受信を契機にアクセス制御が必要か否かを判定し、必要であれば認可判定結果を認証連携サーバ2から要求し、取得した認可判定結果を基にアクセス制御を実施する。
【0125】
S1101では、ユーザ端末8からS901の処理要求を受信する。
S1102では、処理要求内で指定されるユーザID「taro」およびアプリケーションサーバ1のURL「http://demosite2.com/sp1/」の組み合わせのレコードが、認証連携テーブル64内に登録されているか否かを判定する(S1102)。S1102でYesならS1103へ進み、NoならS1105へ進む。
【0126】
S1103では、S1102で検索したレコード内に、認可判定結果が存在するか否かを判定する。S1103でYesならS1104へ進み、NoならS1107へ進む。
S1104では、S1103で判定した認可判定結果が認可「OK」か否かを判定する。S1104でYesならS1105へ進み、NoならS1106へ進む。
S1105では、処理要求をアプリケーションサーバ1へ送信する。
S1106では、認証失敗を示す禁止応答をユーザ端末8へ送信する。
【0127】
S1107では、認可判定結果がユーザ端末8から受信したメッセージに添付されているか否かを判定する。S1107でYesならS1108へ進み、NoならS1116へ進む。
S1108では、認可判定結果を認証連携テーブル64へ登録する。
S1109では、認可判定結果は「OK(認可成功)」か否かを判定する。S1109でYesならS1110へ進み、NoならS1106へ進む。
【0128】
S1110では、認証連携は「有?」か否かを判定する。S1110でYesならS1111へ進み、NoならS1113へ進む。
S1111では、S1006の秘匿認証情報要求を認証連携サーバ2bへ送信する。
S1112では、S1010の秘匿認証情報応答を認証連携サーバ2bから受信する。
S1113では、認証結果or認証情報(秘匿認証情報応答に含まれる)をメモリへ保存し、S1105へ進む。
S1116では、S902の転送応答を作成し、ユーザ端末8へ送信する。
【0129】
以上説明した第2実施形態でのシングルサインオンシステムでは、ドメインAのシングルサインオンシステムが、別のドメインBのシングルサインオンシステム内の認証サーバ4に対し、ユーザに代わりユーザの認証情報を送信し、認証サーバ4が認証情報を取得してユーザ認証を実施する。これにより、複数のシステムにまたがったシングルサインオンを実現する。
【0130】
一方、従来のシングルサインオンシステムは、同一ドメイン間での単一のシングルサインオンシステムとしての認証連携にとどまる。その原因は技術的制約、物理的制約、セキュリティポリシによる制約など様々である。この場合、ユーザは利用しているシングルサインオンシステムと連携しているサービスについては認証情報の入力操作および認証情報の管理による負担を軽減できるが、それ以外のサービスについてはシングルサインオンによる恩恵を受けることができない。また、ユーザが複数のシングルサインオンシステムを利用できるとしても、シングルサインオンシステムごとに認証情報の入力操作が必要となるため、シングルサインオンの適用前に存在したパスワード管理の問題が浮上する。
【0131】
ここで、シングルサインオンに関連して、ユーザがサービスごとに利用するIDや属性情報を一元的に管理し、必要に応じてサービスに提供するID管理技術が利用されつつある。特開2010−113462号公報には、ユーザIDやアサーションを含む、ユーザに関わる情報(ユーザのIDや属性情報)を、必要な相手にだけ安全に提供する方法が示されている。
しかし、特開2010−113462号公報には、第2実施形態のように、本人の信頼性の拠り所である認証情報を認証サーバ4から第三者へ提供する点は、記載されていない。
【符号の説明】
【0132】
1 アプリケーションサーバ
2 認証連携サーバ
3 認証情報検証サーバ
8 ユーザ端末
4 認証サーバ
5 ネットワーク
6 認証プロキシサーバ
11 SAML SP部
12 Webサーバ
13 アクセステーブル
21 認証状態管理部
22 ロケーション管理部
23 ID管理部
24 認可判定部
25 SAML IdP Proxy部
26 認証情報検証依頼部
27 認証状態テーブル
28 認証要求ポリシテーブル
29 認証サーバリスト
31 流用検出管理部
32 認証情報検証部
33 通信部
34 流用検出用テーブル
41 認証情報管理部
42 認証情報秘匿化部
43 認証部
44 SAML IdP部
45 認証情報テーブル
61 SAML SP部
62 認証情報連携部
63 SAML ECP部
64 認証連携テーブル
76 認証情報提供部
81 Webブラウザ

【特許請求の範囲】
【請求項1】
ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムであって、
ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、
前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、
前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、
前記認証サーバは、前記認証処理で扱う前記認証情報を入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、
前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報とその生成元である前記認証情報を使用する前記ユーザ端末のユーザを一意に特定するユーザIDとの組み合わせを複数組取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、
前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする
認証連携システム。
【請求項2】
ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムであって、
ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、
前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、
前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、
前記認証サーバは、前記認証処理で扱う前記認証情報と、前記ユーザ端末のユーザを一意に特定するユーザIDとを入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、
前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報を複数個取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、
前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする
認証連携システム。
【請求項3】
ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムであって、
ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、
前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、
前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、
前記認証サーバは、同じ前記ユーザ端末が複数の前記認証サーバとそれぞれセッションを確立するときに、そのセッションを識別するセッションIDとして、同じセッションIDを使用するものとし、前記認証処理で扱う前記認証情報と、セッションIDとを入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、
前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報を複数個取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、
前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする
認証連携システム。
【請求項4】
前記認証サーバは、実行する前記認証処理の認証方式がパスワード認証または電子証明書認証であるときには、前記秘匿化演算処理として、入力値を引数とするハッシュ関数を呼び出すことで、前記秘匿認証情報を生成し、
前記認証情報検証サーバは、流用が発生した複数の前記認証情報を抽出するための照合処理として、複数の前記秘匿認証情報の値が一致することにより、複数の前記認証情報間に流用が発生したと判定することを特徴とする
請求項1ないし請求項3のいずれか1項に記載に認証連携システム。
【請求項5】
前記認証サーバは、実行する前記認証処理の認証方式が生体認証であるときには、前記秘匿化演算処理として、生体の前記認証情報および秘密鍵を入力とし、生体情報の相関を不変に変換する関数を呼び出すことで、前記秘匿認証情報を生成し、
前記認証情報検証サーバは、流用が発生した複数の前記認証情報を抽出するための照合処理として、複数の前記秘匿認証情報間の類似度が所定値以上であるときに、複数の前記認証情報間に流用が発生したと判定することを特徴とする
請求項1ないし請求項3のいずれか1項に記載に認証連携システム。
【請求項6】
ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムが実行する認証連携方法であって、
前記認証連携システムは、
ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、
前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、
前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、
前記認証サーバは、前記認証処理で扱う前記認証情報を入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、
前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報とその生成元である前記認証情報を使用する前記ユーザ端末のユーザを一意に特定するユーザIDとの組み合わせを複数組取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、
前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする
認証連携方法。
【請求項7】
ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムが実行する認証連携方法であって、
前記認証連携システムは、
ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、
前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、
前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、
前記認証サーバは、前記認証処理で扱う前記認証情報と、前記ユーザ端末のユーザを一意に特定するユーザIDとを入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、
前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報を複数個取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、
前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする
認証連携方法。
【請求項8】
ユーザの使用するユーザ端末に対して、アプリケーションサーバが提供するサービスの実行を認可する際に、そのサービスの認可に関するポリシとして、ユーザに対する複数回の認証結果をユーザ認証状態として要する認証連携システムが実行する認証連携方法であって、
前記認証連携システムは、
ユーザに対応する認証情報が自装置の記憶手段内に登録されているデータであるときに、認証処理が成功したとして、前記ユーザ認証状態を構成する前記認証結果を出力する認証サーバと、
前記認証サーバが出力した前記認証結果の集合である前記ユーザ認証状態がサービスごとに規定されている前記ポリシを満たしているときにサービスを認可する認証連携サーバと、
前記認証サーバが前記認証処理で扱う前記認証情報について、複数の前記認証情報間における流用を検証する認証情報検証サーバとを含めて構成され、
前記認証サーバは、同じ前記ユーザ端末が複数の前記認証サーバとそれぞれセッションを確立するときに、そのセッションを識別するセッションIDとして、同じセッションIDを使用するものとし、前記認証処理で扱う前記認証情報と、セッションIDとを入力として、秘匿化演算処理を行うことにより、前記認証情報ごとの秘匿認証情報を生成し、
前記認証情報検証サーバは、前記認証サーバにより生成された前記秘匿認証情報を複数個取得して互いに照合することで、その組み合わせについての流用が発生した複数の前記認証情報を抽出し、
前記認証連携サーバは、前記サービスを認可する処理において、前記ユーザ認証状態を構成する前記認証結果として、前記認証情報の流用が発生した前記認証結果を除外した後の前記ユーザ認証状態が、前記ポリシを満たしているか否かを判定することを特徴とする
認証連携方法。
【請求項9】
前記認証サーバは、実行する前記認証処理の認証方式がパスワード認証または電子証明書認証であるときには、前記秘匿化演算処理として、入力値を引数とするハッシュ関数を呼び出すことで、前記秘匿認証情報を生成し、
前記認証情報検証サーバは、流用が発生した複数の前記認証情報を抽出するための照合処理として、複数の前記秘匿認証情報の値が一致することにより、複数の前記認証情報間に流用が発生したと判定することを特徴とする
請求項6ないし請求項8のいずれか1項に記載に認証連携方法。
【請求項10】
前記認証サーバは、実行する前記認証処理の認証方式が生体認証であるときには、前記秘匿化演算処理として、生体の前記認証情報および秘密鍵を入力とし、生体情報の相関を不変に変換する関数を呼び出すことで、前記秘匿認証情報を生成し、
前記認証情報検証サーバは、流用が発生した複数の前記認証情報を抽出するための照合処理として、複数の前記秘匿認証情報間の類似度が所定値以上であるときに、複数の前記認証情報間に流用が発生したと判定することを特徴とする
請求項6ないし請求項8のいずれか1項に記載に認証連携方法。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate


【公開番号】特開2012−212211(P2012−212211A)
【公開日】平成24年11月1日(2012.11.1)
【国際特許分類】
【出願番号】特願2011−76270(P2011−76270)
【出願日】平成23年3月30日(2011.3.30)
【国等の委託研究の成果に係る記載事項】(出願人による申告)国等の委託研究の成果に係る特許出願(平成20年度 独立行政法人情報通信研究機構「次世代ネットワーク(NGN)基盤技術の研究開発」委託研究、産業技術力強化法第19条の適用を受ける特許出願)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】