認証システムのメタデータプロビジョニング方法、システム、そのプログラムおよび記録媒体
【課題】ユーザ利用端末からサービス提供サーバへのログイン認証に際し、ユーザが所有しているデバイスを認証デバイスとして利用可能とする。
【解決手段】サービス提供サーバ２１が利用端末１０からのメタデータ登録の要求を受け付け、サービス提供サーバ２１は認証デバイス３１との間でセッションを確立する。認証デバイス３１は自身の公開鍵証明書を含むメタデータをサービス提供サーバ２１に送信する。サービス提供サーバ２１は認証局４０の公開鍵証明書により認証デバイス３１の公開鍵証明書の署名を検証して、真正であることが確認されるとメタデータを登録する。
【解決手段】サービス提供サーバ２１が利用端末１０からのメタデータ登録の要求を受け付け、サービス提供サーバ２１は認証デバイス３１との間でセッションを確立する。認証デバイス３１は自身の公開鍵証明書を含むメタデータをサービス提供サーバ２１に送信する。サービス提供サーバ２１は認証局４０の公開鍵証明書により認証デバイス３１の公開鍵証明書の署名を検証して、真正であることが確認されるとメタデータを登録する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス提供サーバへログインする際の認証処理を認証デバイスを用いて行う場合に、認証デバイスが生成する認証情報の検証に必要な情報をサービス提供サーバにプロビジョニングする方法、システム、そのプログラムおよび記録媒体に関する。
【背景技術】
【０００２】
ネットバンキングなど、様々なサービスが次々とオンライン化されるにつれ、フィッシングやＩＤ盗難などのセキュリティ被害も増加傾向にある。現状、ＰＣなどの利用端末からオンラインサービスを利用する場合、例えば図１０に示すように、ユーザの利用端末１１０からサービス提供者のサービス提供サーバ１２０にログインする際にユーザアカウント／パスワードにより認証を行うという形でセキュリティ対策を行うことが一般的である。しかし、ユーザアカウント／パスワード認証は低コストで容易に導入できるものの、なりすましや盗聴などの脅威が多いというデメリットがある。そこで、より高いセキュリティが求められるオンラインサービスの提供者は、例えば図１１に示すように、ユーザごとにワンタイムパスワードトークンやＵＳＢトークンを配布し、これらのトークンに格納された認証情報を専用の認証サーバ１３０を用いて認証するなどの方法によりセキュリティを高めている。
【０００３】
一方、携帯電話が普及し、ライフスタイルへの浸透が進んでいることを背景に、携帯電話を認証デバイスとして利用する方式が提案されている（例えば、特許文献１参照）。この方式のように、サービス提供サーバに付属して認証機能を提供する認証サーバではなく別の認証デバイスを利用して認証を行う場合には、サービス提供サーバが、認証情報を提供する当該認証デバイスを信頼することが前提となる。
また、携帯電話サービスにおいては、携帯電話の耐タンパな領域に格納された秘密鍵を利用して電子証明書ベースの強固な認証を行う方式も提案されている（例えば、非特許文献１参照）。このような方式の場合、当該携帯電話の認証情報を検証するためサービス提供サーバが、予め当該携帯電話の公開鍵証明書を保持している必要がある。
【特許文献１】特開２００６−１７４３２０号公報
【非特許文献１】ＮＴＴドコモ、“電子認証サービスFirstPass”、［online］、平成１９年、ＮＴＴドコモ、［平成１９年９月２５日検索］、インターネット〈URL：http://www.nttdocomo.co.jp/ service/other/firstpass/〉
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ユーザごとにワンタイムパスワードトークンやＵＳＢトークンを配布するなどの独自の認証デバイスを用いる場合、サービス提供者はユーザへの認証デバイスの配布や専用の認証サーバの導入が必要になり、非常にコストがかかる。また、ユーザもサービス提供サーバごとに独自の認証デバイスを所有しなければならず、デバイスの管理などに手間がかかる。このような課題に対し、もし専用の認証サーバの代わりにユーザが既に持っているデバイス（例えば携帯電話等）を認証デバイスとして利用することができれば、サービス提供者のコスト削減、並びにユーザの管理の手間の軽減及び利便性の向上を図ることができる。
【０００５】
ユーザが既に持っているデバイスを認証デバイスとして利用するには、ユーザのデバイスとサービス提供サーバとの間で認証連携を実現する必要があり、その前提として信頼モデルを構築する必要がある。サービス提供サーバは認証デバイスが生成した認証情報を信頼してサービスを提供することになるためである。しかし、信頼モデルの構築は認証サーバを利用する方法の場合はシステム構築段階で行えばそれで足りるが、ユーザのデバイスを利用する方法の場合はユーザごとにデバイスが異なるためユーザを追加するごとに信頼モデルを構築する必要がある。そこで、このような場合にいかに信頼モデルを構築するかが問題となる。
【０００６】
また、認証サーバを利用する従来の認証方法の場合、サービス提供サーバは認証サーバの認証情報だけを検証すればよく、検証に必要なのは認証サーバの情報（メタデータ）だけである。これに対し、ユーザのデバイスを利用する認証方法の場合、ユーザごとにデバイスが異なるため、サービス提供サーバはユーザごとにそれぞれの認証情報を検証する必要があり、検証に必要なメタデータも各ユーザのものを入手する必要がある。そのため、メタデータのプロビジョニング処理は、認証サーバを利用する認証方法の場合はシステム構築段階で行えばそれで足りるのに対し、ユーザのデバイスを利用する認証方法の場合は運用段階でユーザの追加登録ごとに行う必要がある。しかし、メタデータのプロビジョニング（メンテナンス）の方式は認証サーバを利用する認証方法の場合は単純なＨＴＴＰリクエスト／レスポンスでよいのに対し、ユーザのデバイスを利用する認証方法の場合は、ユーザのデバイスは基本的にＨＴＴＰリクエストを受け取ることができないため、このような場合にいかにメタデータのプロビジョニングを行うかが問題となる。
【０００７】
本発明の目的は、上記の問題点の解決により携帯電話等のユーザが所有しているデバイスを認証デバイスとして利用可能とし、よって、サービス提供者が強固な認証手段を独自の認証デバイスを配布することなく低コストで導入可能とするとともに、ユーザがサービス提供者から配布された独自の認証デバイスを管理する手間を削減可能とする認証システムのメタデータプロビジョニング方法、システムの実現にある。
【課題を解決するための手段】
【０００８】
本発明の認証システムのメタデータプロビジョニング方法においては、利用端末とサービス提供サーバと認証デバイスと認証局とが以下のようなシーケンスにより認証処理を行う。
サービス提供サーバは認証局の公開鍵証明書を予め保持し、認証デバイスは認証局から発行を受けた自身の秘密鍵と、認証局から発行を受けた公開鍵証明書を含む、メタデータとを予め保持する。
まず、サービス提供サーバが、利用端末で入力されたユーザＩＤ及びパスワードによりユーザを認証し、利用端末で入力されたメタデータ登録要求を受け付け、利用端末で入力された認証デバイスのＵＲＬを受信し、セッションＩＤを生成してユーザＩＤと関連付けて記憶すると共に、セッションＩＤをサービス提供サーバのＵＲＬとともに認証デバイスに送信する。
【０００９】
次に、認証デバイスが、サービス提供サーバから送信された情報を受信し、ユーザ認証を行い、セッションＩＤと認証デバイスの公開鍵証明書を含むメタデータとをサービス提供サーバに送信する。
次に、サービス提供サーバが、認証デバイスから送信された情報を受信し、受信したセッションＩＤを確認し、認証デバイスの公開鍵証明書を認証局の公開鍵証明書により検証し、認証デバイスから受信したメタデータを登録し、利用端末にメタデータ登録完了通知を行う。
【発明の効果】
【００１０】
本発明によれば、携帯電話等のユーザが所有しているデバイスを認証デバイスとして利用可能とし、よって、サービス提供者が強固な認証手段を独自の認証デバイスを配布することなく低コストで導入可能とするとともに、ユーザがサービス提供者から配布された独自の認証デバイスを管理する手間を削減可能とする認証システムのメタデータプロビジョニング方法、システムを実現することができる。
【発明を実施するための最良の形態】
【００１１】
図１は本発明に係る認証システムの初期状態の例である。ユーザはサービス提供サーバ２０にユーザＩＤを所持しており、利用端末１０を通じてサービスを利用する。この状態では携帯電話等を認証デバイスとして利用することはできず、ユーザは利用端末からユーザＩＤ／パスワードを入力するなどの認証処理を行ってサービスを利用することになる。
【００１２】
一方、図２は本発明に係る認証システムが携帯電話等を認証デバイス３０として利用可能となった状態の例である。携帯電話等にはＳＩＭ（Subscriber Identity Module）カード等の記録媒体が装着されており、当該カードのチップの耐タンパな領域には認証局から発行された当該携帯電話等の秘密鍵と公開鍵証明書が格納されている。サービス提供サーバ２０は、当該認証デバイス３０が生成した認証情報の検証に必要な当該認証デバイス３０の公開鍵証明書を入手し保持している。また、当該認証デバイス３０と認証連携をするために必要な情報を記述したメタデータも入手し保持している。メタデータの具体的内容はＩＤ連携の標準技術であるＳＡＭＬｖ２．０において定義されており、当該認証デバイス３０を識別するための認証デバイス識別子やメタデータそのものを指すＩＤ等の情報が含まれる。なお、上記公開鍵証明書はメタデータ内に記述してメタデータと一体化することも可能である。ＩＤ連携情報は、ＩＤ連携を行うために認証デバイス３０ごとに付与される識別子で、サービス提供サーバ２０と認証デバイス３０の双方において、ユーザＩＤ及び連携先サーバ・デバイスのＵＲＬ（メタデータの公開先）のそれぞれと関連付けて管理される。なお、ＩＤ連携情報にはデバイスの実名（認証デバイス識別子）を用いる他に、仮名を用いることも可能である。仮名の識別子を用いた連携方法は名寄せ問題の解決に有効であり、またセキュリティ向上にも資する。
【００１３】
図２に示すようにプロビジョニングされた以後は、利用端末１０からサービスを利用する際には、従来の認証処理（利用端末１０からのユーザＩＤ／パスワードの入力による認証）の代わりに、認証デバイス３０が生成する認証情報を利用してサービス提供サーバ２０にログイン（シングルサインオン）することが可能となる。
つまり、図１に示す初期状態を図２に示す状態に移行することができれば携帯電話等を認証デバイスとして利用できることから、本発明は図１に示すような初期状態を図２に示すような状態にプロビジョニングする方法、システムについて明らかにするものである。
【００１４】
〔第１実施形態〕
メタデータの管理は認証デバイスで行う方法やメタデータ公開サーバで行う方法等が考えられるが、本実施形態は認証デバイスで行う方法であり、この場合サービス提供サーバによるメタデータの入手は、認証デバイスからサービス提供サーバへのＰＵＳＨにより実現される。
【００１５】
図３は本実施形態のメタデータプロビジョニング方法のシーケンスの例である。図４はそのシステム構成の例であり、当該メタデータプロビジョニングシステム１は、利用端末１０とサービス提供サーバ２１と認証デバイス３１と認証局４０とから構成される。サービス提供サーバ２１と認証デバイス３１はそれぞれ図２におけるサービス提供サーバ２０と認証デバイス３０に対応するものである。
【００１６】
以下、図３に示すシーケンス及び図４に示すシステムの各構成要素の機能を説明する。なお、サービス提供サーバ２１は認証局４０の公開鍵証明書を予め保持し、認証デバイス３１は認証局４０から発行を受けた自身の秘密鍵を耐タンパな領域に予め格納するとともに認証局４０から発行を受けた自身の公開鍵証明書を含む、自身のメタデータを予め保持していることとする。ユーザは利用端末１０からサービス提供サーバ２１にログインする（Ｓ１）。ユーザは続いて、メタデータの登録を要求し（Ｓ２)、認証デバイス３１のＵＲＬを送信する（Ｓ３）。要求を受けたサービス提供サーバ２１は、セッションＩＤを生成してユーザＩＤと関連付けて記憶し（Ｓ４）、認証デバイス３１のＵＲＬに当該セッションＩＤとサービス提供サーバ２１のＵＲＬとを含むリクエスト情報を送信する（Ｓ５）。認証デバイス３１はリクエスト情報を受信し（Ｓ６）、ユーザ認証（Ｓ７）を行った後、セッションＩＤ及びメタデータを含むレスポンス情報をサービス提供サーバ２１に送信する（Ｓ８）。サービス提供サーバ２１はレスポンス情報を受信し（Ｓ９）、セッションＩＤを確認（Ｓ１０）した後、受信したメタデータに含まれる認証デバイス３１の公開鍵証明書の真正性を認証局４０の公開鍵証明書により検証する（Ｓ１１）。なお、認証デバイス３１の公開鍵証明書の検証の際には、必要に応じ認証局４０に対しＣＲＬ（無効証明書リスト）の確認を行う。これらの検証により公開鍵証明書の真正性が確認されることで、認証端末が信頼できることを確認できる。そして、メタデータを登録し（Ｓ１２）、最後に利用端末に登録の完了を通知する（Ｓ１３）。
【００１７】
以上の処理を認証デバイスごとに行うことにより、サービス提供サーバに各認証デバイスのメタデータを登録することができるため、その後、ＳＡＭＬｖ２．０において定義されたＩＤ連携方法に従ってサービス提供サーバと認証デバイスとの間の信頼関係を確立することで、図２に示すような携帯電話等を認証デバイスとして利用可能な状態に容易にプロビジョニングすることができる。
【００１８】
なお、認証デバイスがＨＴＴＰリクエストを受け取れない場合には、例えばサービス提供サーバ２１と認証デバイス３１との間のリクエスト送受信（Ｓ５、Ｓ６）を電子メールで行うことができる。この場合、Ｓ３ではＵＲＬとして認証デバイス３１のメールアドレスを送信する。また、その他ＱＲコード（登録商標）などを用いた通信手段も考えられ、その場合には認証デバイスにそれ相当の通信機能（コード読み取り機能など）が必要になる。
【００１９】
〔第２実施形態〕
本実施形態はメタデータの管理をメタデータ公開サーバで行う方法であり、サービス提供サーバによるメタデータの入手はサービス提供サーバがメタデータ公開サーバから参照することにより実現される。
【００２０】
図５は本発明のメタデータプロビジョニング方法のシーケンスの例である。図６はそのシステム構成の例であり、当該メタデータプロビジョニングシステム２は、利用端末１０とサービス提供サーバ２２と認証デバイス３２と認証局４０とメタデータ公開サーバ５０とから構成される。サービス提供サーバ２２と認証デバイス３２はそれぞれ図２におけるサービス提供サーバ２０と認証デバイス３０に対応するものである。
以下、図５に示すシーケンス及び図６に示すシステムの各構成要素の機能を説明する。なお、第１実施形態と共通の処理ステップについては以下の説明及び図５において同一符号を付与し、ここでの説明は省略する。
【００２１】
サービス提供サーバ２２は認証局４０の公開鍵証明書を予め保持し、認証デバイス３２は認証局４０から発行を受けた自身の秘密鍵を耐タンパな領域に予め格納し、メタデータ公開サーバ５０は認証局４０から発行を受けた認証デバイス３２の公開鍵証明書を含む、メタデータを予め保持していることとする。Ｓ１〜Ｓ７の処理の後、認証デバイス３２は、セッションＩＤ、メタデータＩＤ、及びメタデータ公開サーバ５０のＵＲＬを含むレスポンス情報をサービス提供サーバ２２に送信する（Ｓ１４）。Ｓ９、Ｓ１０の処理の後、サービス提供サーバ２２は、メタデータ公開サーバ５０のＵＲＬにメタデータＩＤに該当するメタデータを要求し（Ｓ１５）、メタデータ公開サーバ５０は、サービス提供サーバ２２からの要求に応じてメタデータＩＤに該当するメタデータを抽出し、これをサービス提供サーバ２２に返信する（Ｓ１６）。続いて、Ｓ１１〜Ｓ１３の処理を行う。
【００２２】
以上の処理を認証デバイスごとに行うことにより、サービス提供サーバに各認証デバイスのメタデータを登録することができるため、その後、ＳＡＭＬｖ２．０で定義されたＩＤ連携方法に従ってサービス提供サーバと認証デバイスとの間の信頼関係を確立することで、図２に示すような携帯電話等を認証デバイスとして利用可能な状態に容易にプロビジョニングすることができる。
【００２３】
なお、認証デバイスがＨＴＴＰリクエストを受け取れない場合には、例えばサービス提供サーバ２２と認証デバイス３２との間のリクエスト送受信（Ｓ５、Ｓ６）を電子メールで行うことができる。この場合、Ｓ３ではＵＲＬとして認証デバイス３２のメールアドレスを送信する。また、その他ＱＲコード（登録商標）などを用いた通信手段も考えられ、その場合には認証デバイスにそれ相当の通信機能（コード読み取り機能など）が必要になる。
【００２４】
〔第３実施形態〕
第１実施形態は、認証デバイスのメタデータをサービス提供サーバに登録するところまでを行い、両者の信頼関係の確立処理はその後別途行う構成である。第３実施形態は、この信頼関係の確立処理についてもメタデータの登録処理と一体的に行う構成である。
【００２５】
図７は本実施形態のメタデータプロビジョニング方法のシーケンスの例である。図４はそのシステム構成の例であり、当該メタデータプロビジョニングシステム３は、利用端末１０とサービス提供サーバ２３と認証デバイス３３と認証局４０とから構成される。サービス提供サーバ２３と認証デバイス３３はそれぞれ図２におけるサービス提供サーバ２０と認証デバイス３０に対応するものである。なお、第１実施形態と共通の処理ステップについては以下の説明及び図７において同一符号を付与し、ここでの説明は省略する。
【００２６】
サービス提供サーバ２３は認証局４０の公開鍵証明書を予め保持し、認証デバイス３３は認証局４０から発行を受けた自身の秘密鍵を耐タンパな領域に予め格納するとともに認証局４０から発行を受けた自身の公開鍵証明書を含む、メタデータを予め保持していることとする。ユーザは利用端末１０からサービス提供サーバ２３にログインし（Ｓ１）、ＩＤ連携を要求する（Ｓ１７)。Ｓ３〜Ｓ７の処理の後、認証デバイス３３はＩＤ連携情報を含む認証情報を生成する。この時、当該認証情報にユーザ認証に基づいてアクセスが許可される耐タンパな領域に格納された秘密鍵で署名する（Ｓ１８）。そして、署名された認証情報、セッションＩＤ、及びメタデータを含むレスポンス情報をサービス提供サーバ２３に送信する（Ｓ１９）。続いて、Ｓ９、Ｓ１０の処理の後、サービス提供サーバ２３は、認証デバイス３３から受信したメタデータに含まれる公開鍵証明書の真正性を認証局４０の公開鍵証明書により検証するとともに、受信した認証情報の真正性を、真正性が検証された当該認証デバイス３３の公開鍵証明書により検証する（Ｓ２０）。なお、認証デバイス３３の公開鍵証明書の検証の際には、必要に応じ認証局４０に対しＣＲＬ（無効証明書リスト）の確認を行う。これらの検証により公開鍵証明書の真正性が確認されることで、認証端末が信頼できることを確認できる。そして、メタデータを登録するとともに、ＩＤ連携情報をユーザＩＤと関連付けて登録し（Ｓ２１）、最後に利用端末に連携完了を通知する（Ｓ２２）。
【００２７】
以上の処理を認証デバイスごとに行うことにより、サービス提供サーバにメタデータを登録できるとともに、サービス提供サーバと認証デバイスとの間の信頼関係を確立でき、図２に示すような携帯電話等を認証デバイスとして利用可能な状態に容易にプロビジョニングすることができる。
【００２８】
なお、認証デバイスがＨＴＴＰリクエストを受け取れない場合には、例えばサービス提供サーバ２３と認証デバイス３３との間のリクエスト送受信（Ｓ５、Ｓ６）を電子メールで行うことができる。この場合、Ｓ３ではＵＲＬとして認証デバイス３３のメールアドレスを送信する。また、その他ＱＲコード（登録商標）などを用いた通信手段も考えられ、その場合には認証デバイスにそれ相当の通信機能（コード読み取り機能など）が必要になる。
【００２９】
〔第４実施形態〕
第１実施形態は、認証デバイスのメタデータをサービス提供サーバに登録するところまでを行い、両者の信頼関係の確立処理はその後別途行う構成である。第３実施形態は、この信頼関係の確立処理についてもメタデータの登録処理と一体的に行う構成である。
【００３０】
図８は本発明のメタデータプロビジョニング方法のシーケンスの例である。図６はそのシステム構成の例であり、当該メタデータプロビジョニングシステム４は、利用端末１０とサービス提供サーバ２４と認証デバイス３４と認証局４０とメタデータ公開サーバ５０とから構成される。サービス提供サーバ２４と認証デバイス３４はそれぞれ図２におけるサービス提供サーバ２０と認証デバイス３０に対応するものである。なお、第２実施形態と共通の処理ステップについては以下の説明及び図８において同一符号を付与し、ここでの説明は省略する。
【００３１】
サービス提供サーバ２４は認証局４０の公開鍵証明書を予め保持し、認証デバイス３４は認証局４０から発行を受けた自身の秘密鍵を耐タンパな領域に予め格納し、メタデータ公開サーバ５０は認証局４０から発行を受けた認証デバイス３４の公開鍵証明書を含む、メタデータを予め保持していることとする。ユーザは利用端末１０からサービス提供サーバ２４にログインし（Ｓ１）、ＩＤ連携を要求する（Ｓ１７)。Ｓ３〜Ｓ７の処理の後、認証デバイス３４は、ＩＤ連携情報を含む認証情報を生成する。この時、当該認証情報はユーザ認証に基づいてアクセスが許可される耐タンパな領域に格納された秘密鍵で署名される（Ｓ１８）。続いて、署名された認証情報、セッションＩＤ、メタデータＩＤ、及びメタデータ公開サーバ５０のＵＲＬを含むレスポンス情報をサービス提供サーバ２４に送信する（Ｓ２３）。Ｓ９、Ｓ１０、Ｓ１５、Ｓ１６の処理の後、サービス提供サーバ２４は、認証デバイス３４から受信したメタデータに含まれる公開鍵証明書の真正性を認証局４０の公開鍵証明書により検証するとともに、受信した認証情報の真正性を、真正性が検証された当該認証デバイス３４の公開鍵証明書により検証する（Ｓ２０）。なお、認証デバイス３４の公開鍵証明書の検証の際には、必要に応じ認証局４０に対しＣＲＬ（無効証明書リスト）の確認を行う。これらの検証により公開鍵証明書の真正性が確認されることで、認証端末が信頼できることを確認できる。そして、メタデータを登録するとともに、ＩＤ連携情報をユーザＩＤと関連付けて登録し（Ｓ２１）、最後に利用端末に連携完了を通知する（Ｓ２２）。
【００３２】
以上の処理を認証デバイスごとに行うことにより、サービス提供サーバにメタデータを登録できるとともに、サービス提供サーバと認証デバイスとの間の信頼関係を確立でき、図２に示すような携帯電話等を認証デバイスとして利用可能な状態に容易にプロビジョニングすることができる。
なお、認証デバイスがＨＴＴＰリクエストを受け取れない場合には、例えばサービス提供サーバ２４と認証デバイス３４との間のリクエスト送受信（Ｓ５、Ｓ６）を電子メールで行うことができる。この場合、Ｓ３ではＵＲＬとして認証デバイス３４のメールアドレスを送信する。また、その他ＱＲコード（登録商標）などを用いた通信手段も考えられ、その場合には認証デバイスにそれ相当の通信機能（コード読み取り機能など）が必要になる。
【００３３】
〔プロビジョニング後に実現される認証デバイスを用いた認証処理〕
先に説明したように、上記各実施形態の処理により図２に示すようにプロビジョニングされた以後は利用端末１０からサービスを利用する際には、従来の認証処理（利用端末からのユーザＩＤ／パスワードの入力による認証）の代わりに、認証デバイス３０が生成する認証情報を利用してサービス提供サーバ２０にログイン（シングルサインオン）することが可能となる。図９はプロビジョニング後に実現される認証処理シーケンスの例である。なお、この例は認証デバイス３０がＨＴＴＰリクエストを受け付けられない場合でも認証デバイス３０の認証処理を利用可能なように認証デバイス３０とサービス提供サーバ２０との間に中継サーバ６０を挿入し、中継サーバ６０を介して認証デバイス３０との認証待ち受け通信セッションとサービス提供サーバ２０とのＨＴＴＰセッションとをつなぐ構成としたものである。以下、当該シーケンスを説明する。
【００３４】
ユーザは利用端末１０を用いてサービス提供サーバ２０にアクセスし、サービスを要求する（Ｓ１０３）。サービス提供サーバ２０は、利用端末１０に対し認証に必要な情報の提供を要求し（Ｓ１０４）、ユーザは利用端末１０から認証デバイス３０に割り当てられたＵＲＬ（中継サーバ６０のＵＲＬ＋認証デバイス識別子）を返信する（Ｓ１０５）。サービス提供サーバ２０は、利用端末１０との間でセッションＢを確立してセッションＢのセッションＩＤを生成し、このセッションＩＤと認証デバイス識別子とサービス提供サーバ２０のＵＲＬとを含めた認証要求を中継サーバ６０のＵＲＬに送信する（Ｓ１０６）。また、ここまでの間に、認証デバイス３０から中継サーバ６０に認証デバイス識別子を送信し（Ｓ１０１）、中継サーバ６０は、認証端末１０との間にセッションＡを確立するとともに認証デバイス識別子をセッションＡと関連付けて保持しておく（Ｓ１０２）。中継サーバ６０は、サービス提供サーバ２０からの認証要求を受け、認証デバイス識別子をキーにセッションＡを検索し、サービス提供サーバ２０のＵＲＬとセッションＢのセッションＩＤとを認証デバイス３０に転送する（Ｓ１０７）。認証デバイス３０では、ユーザ認証処理を行い（Ｓ１０８）、認証情報を生成する（Ｓ１０９）。ここで、安全性向上のため、当該認証情報に認証デバイス３０の秘密鍵で署名を付与することができる。そして、認証情報とサービス提供サーバのＵＲＬとセッションＢのセッションＩＤとを含む認証結果を中継サーバ６０に返信し（Ｓ１１０）、中継サーバ６０は認証情報とセッションＢのセッションＩＤと含む認証結果をＳ１０６の認証要求に対する返答としてサービス提供サーバのＵＲＬに中継転送する（Ｓ１１１）。サービス提供サーバ２０は、上記各実施形態の処理によりプロビジョニングされたメタデータをＳ１０５で返信された認証デバイス識別子をキーとして検索し、このメタデータを用いて中継サーバ６０から受信した認証情報を検証する（Ｓ１１２）。ここで、Ｓ１０９にて認証情報に署名をした場合は、メタデータに含まれる認証デバイス３０の公開鍵証明書により署名の検証をすることができる。認証されていることが確認できれば、セッションＢに係るユーザのログインを受け付け、サービスを提供する（Ｓ１１３）。
【００３５】
なお、図９の例ではＳ１０５で認証デバイス３０に割り当てられたＵＲＬを返信しているが、この代わりに認証デバイス３０のメタデータＩＤを返信する方法もある。その場合には、サービス提供サーバ２０で保持しているメタデータに認証デバイス３０に割り当てられたＵＲＬを記述しておき、メタデータＩＤにより当該メタデータを検索可能とすることで認証をリクエストする先を解決できるようにしておけばよい。
【産業上の利用可能性】
【００３６】
本発明は、サービス提供サーバへログインする際の認証処理を、認証サーバの代わりに携帯電話等ユーザが所有しているデバイスを認証デバイスとして用いて実現したい場合に有用である。
【図面の簡単な説明】
【００３７】
【図１】本発明の認証システムのプロビジョニング前の状態を示す図。
【図２】本発明の認証システムのプロビジョニング後の状態を示す図。
【図３】本発明の第１実施形態のプロビジョニングシーケンスの例を示す図。
【図４】本発明の第１、第３実施形態のシステム構成の例を示す図。
【図５】本発明の第２実施形態のプロビジョニングシーケンスの例を示す図。
【図６】本発明の第２、第４実施形態のシステム構成の例を示す図。
【図７】本発明の第３実施形態のプロビジョニングシーケンスの例を示す図。
【図８】本発明の第４実施形態のプロビジョニングシーケンスの例を示す図。
【図９】本発明によるプロビジョニング後の認証シーケンスの例を示す図。
【図１０】従来の認証システムの構成の例を示す図。
【図１１】従来の認証システムの別の構成の例を示す図。
【技術分野】
【０００１】
本発明は、サービス提供サーバへログインする際の認証処理を認証デバイスを用いて行う場合に、認証デバイスが生成する認証情報の検証に必要な情報をサービス提供サーバにプロビジョニングする方法、システム、そのプログラムおよび記録媒体に関する。
【背景技術】
【０００２】
ネットバンキングなど、様々なサービスが次々とオンライン化されるにつれ、フィッシングやＩＤ盗難などのセキュリティ被害も増加傾向にある。現状、ＰＣなどの利用端末からオンラインサービスを利用する場合、例えば図１０に示すように、ユーザの利用端末１１０からサービス提供者のサービス提供サーバ１２０にログインする際にユーザアカウント／パスワードにより認証を行うという形でセキュリティ対策を行うことが一般的である。しかし、ユーザアカウント／パスワード認証は低コストで容易に導入できるものの、なりすましや盗聴などの脅威が多いというデメリットがある。そこで、より高いセキュリティが求められるオンラインサービスの提供者は、例えば図１１に示すように、ユーザごとにワンタイムパスワードトークンやＵＳＢトークンを配布し、これらのトークンに格納された認証情報を専用の認証サーバ１３０を用いて認証するなどの方法によりセキュリティを高めている。
【０００３】
一方、携帯電話が普及し、ライフスタイルへの浸透が進んでいることを背景に、携帯電話を認証デバイスとして利用する方式が提案されている（例えば、特許文献１参照）。この方式のように、サービス提供サーバに付属して認証機能を提供する認証サーバではなく別の認証デバイスを利用して認証を行う場合には、サービス提供サーバが、認証情報を提供する当該認証デバイスを信頼することが前提となる。
また、携帯電話サービスにおいては、携帯電話の耐タンパな領域に格納された秘密鍵を利用して電子証明書ベースの強固な認証を行う方式も提案されている（例えば、非特許文献１参照）。このような方式の場合、当該携帯電話の認証情報を検証するためサービス提供サーバが、予め当該携帯電話の公開鍵証明書を保持している必要がある。
【特許文献１】特開２００６−１７４３２０号公報
【非特許文献１】ＮＴＴドコモ、“電子認証サービスFirstPass”、［online］、平成１９年、ＮＴＴドコモ、［平成１９年９月２５日検索］、インターネット〈URL：http://www.nttdocomo.co.jp/ service/other/firstpass/〉
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ユーザごとにワンタイムパスワードトークンやＵＳＢトークンを配布するなどの独自の認証デバイスを用いる場合、サービス提供者はユーザへの認証デバイスの配布や専用の認証サーバの導入が必要になり、非常にコストがかかる。また、ユーザもサービス提供サーバごとに独自の認証デバイスを所有しなければならず、デバイスの管理などに手間がかかる。このような課題に対し、もし専用の認証サーバの代わりにユーザが既に持っているデバイス（例えば携帯電話等）を認証デバイスとして利用することができれば、サービス提供者のコスト削減、並びにユーザの管理の手間の軽減及び利便性の向上を図ることができる。
【０００５】
ユーザが既に持っているデバイスを認証デバイスとして利用するには、ユーザのデバイスとサービス提供サーバとの間で認証連携を実現する必要があり、その前提として信頼モデルを構築する必要がある。サービス提供サーバは認証デバイスが生成した認証情報を信頼してサービスを提供することになるためである。しかし、信頼モデルの構築は認証サーバを利用する方法の場合はシステム構築段階で行えばそれで足りるが、ユーザのデバイスを利用する方法の場合はユーザごとにデバイスが異なるためユーザを追加するごとに信頼モデルを構築する必要がある。そこで、このような場合にいかに信頼モデルを構築するかが問題となる。
【０００６】
また、認証サーバを利用する従来の認証方法の場合、サービス提供サーバは認証サーバの認証情報だけを検証すればよく、検証に必要なのは認証サーバの情報（メタデータ）だけである。これに対し、ユーザのデバイスを利用する認証方法の場合、ユーザごとにデバイスが異なるため、サービス提供サーバはユーザごとにそれぞれの認証情報を検証する必要があり、検証に必要なメタデータも各ユーザのものを入手する必要がある。そのため、メタデータのプロビジョニング処理は、認証サーバを利用する認証方法の場合はシステム構築段階で行えばそれで足りるのに対し、ユーザのデバイスを利用する認証方法の場合は運用段階でユーザの追加登録ごとに行う必要がある。しかし、メタデータのプロビジョニング（メンテナンス）の方式は認証サーバを利用する認証方法の場合は単純なＨＴＴＰリクエスト／レスポンスでよいのに対し、ユーザのデバイスを利用する認証方法の場合は、ユーザのデバイスは基本的にＨＴＴＰリクエストを受け取ることができないため、このような場合にいかにメタデータのプロビジョニングを行うかが問題となる。
【０００７】
本発明の目的は、上記の問題点の解決により携帯電話等のユーザが所有しているデバイスを認証デバイスとして利用可能とし、よって、サービス提供者が強固な認証手段を独自の認証デバイスを配布することなく低コストで導入可能とするとともに、ユーザがサービス提供者から配布された独自の認証デバイスを管理する手間を削減可能とする認証システムのメタデータプロビジョニング方法、システムの実現にある。
【課題を解決するための手段】
【０００８】
本発明の認証システムのメタデータプロビジョニング方法においては、利用端末とサービス提供サーバと認証デバイスと認証局とが以下のようなシーケンスにより認証処理を行う。
サービス提供サーバは認証局の公開鍵証明書を予め保持し、認証デバイスは認証局から発行を受けた自身の秘密鍵と、認証局から発行を受けた公開鍵証明書を含む、メタデータとを予め保持する。
まず、サービス提供サーバが、利用端末で入力されたユーザＩＤ及びパスワードによりユーザを認証し、利用端末で入力されたメタデータ登録要求を受け付け、利用端末で入力された認証デバイスのＵＲＬを受信し、セッションＩＤを生成してユーザＩＤと関連付けて記憶すると共に、セッションＩＤをサービス提供サーバのＵＲＬとともに認証デバイスに送信する。
【０００９】
次に、認証デバイスが、サービス提供サーバから送信された情報を受信し、ユーザ認証を行い、セッションＩＤと認証デバイスの公開鍵証明書を含むメタデータとをサービス提供サーバに送信する。
次に、サービス提供サーバが、認証デバイスから送信された情報を受信し、受信したセッションＩＤを確認し、認証デバイスの公開鍵証明書を認証局の公開鍵証明書により検証し、認証デバイスから受信したメタデータを登録し、利用端末にメタデータ登録完了通知を行う。
【発明の効果】
【００１０】
本発明によれば、携帯電話等のユーザが所有しているデバイスを認証デバイスとして利用可能とし、よって、サービス提供者が強固な認証手段を独自の認証デバイスを配布することなく低コストで導入可能とするとともに、ユーザがサービス提供者から配布された独自の認証デバイスを管理する手間を削減可能とする認証システムのメタデータプロビジョニング方法、システムを実現することができる。
【発明を実施するための最良の形態】
【００１１】
図１は本発明に係る認証システムの初期状態の例である。ユーザはサービス提供サーバ２０にユーザＩＤを所持しており、利用端末１０を通じてサービスを利用する。この状態では携帯電話等を認証デバイスとして利用することはできず、ユーザは利用端末からユーザＩＤ／パスワードを入力するなどの認証処理を行ってサービスを利用することになる。
【００１２】
一方、図２は本発明に係る認証システムが携帯電話等を認証デバイス３０として利用可能となった状態の例である。携帯電話等にはＳＩＭ（Subscriber Identity Module）カード等の記録媒体が装着されており、当該カードのチップの耐タンパな領域には認証局から発行された当該携帯電話等の秘密鍵と公開鍵証明書が格納されている。サービス提供サーバ２０は、当該認証デバイス３０が生成した認証情報の検証に必要な当該認証デバイス３０の公開鍵証明書を入手し保持している。また、当該認証デバイス３０と認証連携をするために必要な情報を記述したメタデータも入手し保持している。メタデータの具体的内容はＩＤ連携の標準技術であるＳＡＭＬｖ２．０において定義されており、当該認証デバイス３０を識別するための認証デバイス識別子やメタデータそのものを指すＩＤ等の情報が含まれる。なお、上記公開鍵証明書はメタデータ内に記述してメタデータと一体化することも可能である。ＩＤ連携情報は、ＩＤ連携を行うために認証デバイス３０ごとに付与される識別子で、サービス提供サーバ２０と認証デバイス３０の双方において、ユーザＩＤ及び連携先サーバ・デバイスのＵＲＬ（メタデータの公開先）のそれぞれと関連付けて管理される。なお、ＩＤ連携情報にはデバイスの実名（認証デバイス識別子）を用いる他に、仮名を用いることも可能である。仮名の識別子を用いた連携方法は名寄せ問題の解決に有効であり、またセキュリティ向上にも資する。
【００１３】
図２に示すようにプロビジョニングされた以後は、利用端末１０からサービスを利用する際には、従来の認証処理（利用端末１０からのユーザＩＤ／パスワードの入力による認証）の代わりに、認証デバイス３０が生成する認証情報を利用してサービス提供サーバ２０にログイン（シングルサインオン）することが可能となる。
つまり、図１に示す初期状態を図２に示す状態に移行することができれば携帯電話等を認証デバイスとして利用できることから、本発明は図１に示すような初期状態を図２に示すような状態にプロビジョニングする方法、システムについて明らかにするものである。
【００１４】
〔第１実施形態〕
メタデータの管理は認証デバイスで行う方法やメタデータ公開サーバで行う方法等が考えられるが、本実施形態は認証デバイスで行う方法であり、この場合サービス提供サーバによるメタデータの入手は、認証デバイスからサービス提供サーバへのＰＵＳＨにより実現される。
【００１５】
図３は本実施形態のメタデータプロビジョニング方法のシーケンスの例である。図４はそのシステム構成の例であり、当該メタデータプロビジョニングシステム１は、利用端末１０とサービス提供サーバ２１と認証デバイス３１と認証局４０とから構成される。サービス提供サーバ２１と認証デバイス３１はそれぞれ図２におけるサービス提供サーバ２０と認証デバイス３０に対応するものである。
【００１６】
以下、図３に示すシーケンス及び図４に示すシステムの各構成要素の機能を説明する。なお、サービス提供サーバ２１は認証局４０の公開鍵証明書を予め保持し、認証デバイス３１は認証局４０から発行を受けた自身の秘密鍵を耐タンパな領域に予め格納するとともに認証局４０から発行を受けた自身の公開鍵証明書を含む、自身のメタデータを予め保持していることとする。ユーザは利用端末１０からサービス提供サーバ２１にログインする（Ｓ１）。ユーザは続いて、メタデータの登録を要求し（Ｓ２)、認証デバイス３１のＵＲＬを送信する（Ｓ３）。要求を受けたサービス提供サーバ２１は、セッションＩＤを生成してユーザＩＤと関連付けて記憶し（Ｓ４）、認証デバイス３１のＵＲＬに当該セッションＩＤとサービス提供サーバ２１のＵＲＬとを含むリクエスト情報を送信する（Ｓ５）。認証デバイス３１はリクエスト情報を受信し（Ｓ６）、ユーザ認証（Ｓ７）を行った後、セッションＩＤ及びメタデータを含むレスポンス情報をサービス提供サーバ２１に送信する（Ｓ８）。サービス提供サーバ２１はレスポンス情報を受信し（Ｓ９）、セッションＩＤを確認（Ｓ１０）した後、受信したメタデータに含まれる認証デバイス３１の公開鍵証明書の真正性を認証局４０の公開鍵証明書により検証する（Ｓ１１）。なお、認証デバイス３１の公開鍵証明書の検証の際には、必要に応じ認証局４０に対しＣＲＬ（無効証明書リスト）の確認を行う。これらの検証により公開鍵証明書の真正性が確認されることで、認証端末が信頼できることを確認できる。そして、メタデータを登録し（Ｓ１２）、最後に利用端末に登録の完了を通知する（Ｓ１３）。
【００１７】
以上の処理を認証デバイスごとに行うことにより、サービス提供サーバに各認証デバイスのメタデータを登録することができるため、その後、ＳＡＭＬｖ２．０において定義されたＩＤ連携方法に従ってサービス提供サーバと認証デバイスとの間の信頼関係を確立することで、図２に示すような携帯電話等を認証デバイスとして利用可能な状態に容易にプロビジョニングすることができる。
【００１８】
なお、認証デバイスがＨＴＴＰリクエストを受け取れない場合には、例えばサービス提供サーバ２１と認証デバイス３１との間のリクエスト送受信（Ｓ５、Ｓ６）を電子メールで行うことができる。この場合、Ｓ３ではＵＲＬとして認証デバイス３１のメールアドレスを送信する。また、その他ＱＲコード（登録商標）などを用いた通信手段も考えられ、その場合には認証デバイスにそれ相当の通信機能（コード読み取り機能など）が必要になる。
【００１９】
〔第２実施形態〕
本実施形態はメタデータの管理をメタデータ公開サーバで行う方法であり、サービス提供サーバによるメタデータの入手はサービス提供サーバがメタデータ公開サーバから参照することにより実現される。
【００２０】
図５は本発明のメタデータプロビジョニング方法のシーケンスの例である。図６はそのシステム構成の例であり、当該メタデータプロビジョニングシステム２は、利用端末１０とサービス提供サーバ２２と認証デバイス３２と認証局４０とメタデータ公開サーバ５０とから構成される。サービス提供サーバ２２と認証デバイス３２はそれぞれ図２におけるサービス提供サーバ２０と認証デバイス３０に対応するものである。
以下、図５に示すシーケンス及び図６に示すシステムの各構成要素の機能を説明する。なお、第１実施形態と共通の処理ステップについては以下の説明及び図５において同一符号を付与し、ここでの説明は省略する。
【００２１】
サービス提供サーバ２２は認証局４０の公開鍵証明書を予め保持し、認証デバイス３２は認証局４０から発行を受けた自身の秘密鍵を耐タンパな領域に予め格納し、メタデータ公開サーバ５０は認証局４０から発行を受けた認証デバイス３２の公開鍵証明書を含む、メタデータを予め保持していることとする。Ｓ１〜Ｓ７の処理の後、認証デバイス３２は、セッションＩＤ、メタデータＩＤ、及びメタデータ公開サーバ５０のＵＲＬを含むレスポンス情報をサービス提供サーバ２２に送信する（Ｓ１４）。Ｓ９、Ｓ１０の処理の後、サービス提供サーバ２２は、メタデータ公開サーバ５０のＵＲＬにメタデータＩＤに該当するメタデータを要求し（Ｓ１５）、メタデータ公開サーバ５０は、サービス提供サーバ２２からの要求に応じてメタデータＩＤに該当するメタデータを抽出し、これをサービス提供サーバ２２に返信する（Ｓ１６）。続いて、Ｓ１１〜Ｓ１３の処理を行う。
【００２２】
以上の処理を認証デバイスごとに行うことにより、サービス提供サーバに各認証デバイスのメタデータを登録することができるため、その後、ＳＡＭＬｖ２．０で定義されたＩＤ連携方法に従ってサービス提供サーバと認証デバイスとの間の信頼関係を確立することで、図２に示すような携帯電話等を認証デバイスとして利用可能な状態に容易にプロビジョニングすることができる。
【００２３】
なお、認証デバイスがＨＴＴＰリクエストを受け取れない場合には、例えばサービス提供サーバ２２と認証デバイス３２との間のリクエスト送受信（Ｓ５、Ｓ６）を電子メールで行うことができる。この場合、Ｓ３ではＵＲＬとして認証デバイス３２のメールアドレスを送信する。また、その他ＱＲコード（登録商標）などを用いた通信手段も考えられ、その場合には認証デバイスにそれ相当の通信機能（コード読み取り機能など）が必要になる。
【００２４】
〔第３実施形態〕
第１実施形態は、認証デバイスのメタデータをサービス提供サーバに登録するところまでを行い、両者の信頼関係の確立処理はその後別途行う構成である。第３実施形態は、この信頼関係の確立処理についてもメタデータの登録処理と一体的に行う構成である。
【００２５】
図７は本実施形態のメタデータプロビジョニング方法のシーケンスの例である。図４はそのシステム構成の例であり、当該メタデータプロビジョニングシステム３は、利用端末１０とサービス提供サーバ２３と認証デバイス３３と認証局４０とから構成される。サービス提供サーバ２３と認証デバイス３３はそれぞれ図２におけるサービス提供サーバ２０と認証デバイス３０に対応するものである。なお、第１実施形態と共通の処理ステップについては以下の説明及び図７において同一符号を付与し、ここでの説明は省略する。
【００２６】
サービス提供サーバ２３は認証局４０の公開鍵証明書を予め保持し、認証デバイス３３は認証局４０から発行を受けた自身の秘密鍵を耐タンパな領域に予め格納するとともに認証局４０から発行を受けた自身の公開鍵証明書を含む、メタデータを予め保持していることとする。ユーザは利用端末１０からサービス提供サーバ２３にログインし（Ｓ１）、ＩＤ連携を要求する（Ｓ１７)。Ｓ３〜Ｓ７の処理の後、認証デバイス３３はＩＤ連携情報を含む認証情報を生成する。この時、当該認証情報にユーザ認証に基づいてアクセスが許可される耐タンパな領域に格納された秘密鍵で署名する（Ｓ１８）。そして、署名された認証情報、セッションＩＤ、及びメタデータを含むレスポンス情報をサービス提供サーバ２３に送信する（Ｓ１９）。続いて、Ｓ９、Ｓ１０の処理の後、サービス提供サーバ２３は、認証デバイス３３から受信したメタデータに含まれる公開鍵証明書の真正性を認証局４０の公開鍵証明書により検証するとともに、受信した認証情報の真正性を、真正性が検証された当該認証デバイス３３の公開鍵証明書により検証する（Ｓ２０）。なお、認証デバイス３３の公開鍵証明書の検証の際には、必要に応じ認証局４０に対しＣＲＬ（無効証明書リスト）の確認を行う。これらの検証により公開鍵証明書の真正性が確認されることで、認証端末が信頼できることを確認できる。そして、メタデータを登録するとともに、ＩＤ連携情報をユーザＩＤと関連付けて登録し（Ｓ２１）、最後に利用端末に連携完了を通知する（Ｓ２２）。
【００２７】
以上の処理を認証デバイスごとに行うことにより、サービス提供サーバにメタデータを登録できるとともに、サービス提供サーバと認証デバイスとの間の信頼関係を確立でき、図２に示すような携帯電話等を認証デバイスとして利用可能な状態に容易にプロビジョニングすることができる。
【００２８】
なお、認証デバイスがＨＴＴＰリクエストを受け取れない場合には、例えばサービス提供サーバ２３と認証デバイス３３との間のリクエスト送受信（Ｓ５、Ｓ６）を電子メールで行うことができる。この場合、Ｓ３ではＵＲＬとして認証デバイス３３のメールアドレスを送信する。また、その他ＱＲコード（登録商標）などを用いた通信手段も考えられ、その場合には認証デバイスにそれ相当の通信機能（コード読み取り機能など）が必要になる。
【００２９】
〔第４実施形態〕
第１実施形態は、認証デバイスのメタデータをサービス提供サーバに登録するところまでを行い、両者の信頼関係の確立処理はその後別途行う構成である。第３実施形態は、この信頼関係の確立処理についてもメタデータの登録処理と一体的に行う構成である。
【００３０】
図８は本発明のメタデータプロビジョニング方法のシーケンスの例である。図６はそのシステム構成の例であり、当該メタデータプロビジョニングシステム４は、利用端末１０とサービス提供サーバ２４と認証デバイス３４と認証局４０とメタデータ公開サーバ５０とから構成される。サービス提供サーバ２４と認証デバイス３４はそれぞれ図２におけるサービス提供サーバ２０と認証デバイス３０に対応するものである。なお、第２実施形態と共通の処理ステップについては以下の説明及び図８において同一符号を付与し、ここでの説明は省略する。
【００３１】
サービス提供サーバ２４は認証局４０の公開鍵証明書を予め保持し、認証デバイス３４は認証局４０から発行を受けた自身の秘密鍵を耐タンパな領域に予め格納し、メタデータ公開サーバ５０は認証局４０から発行を受けた認証デバイス３４の公開鍵証明書を含む、メタデータを予め保持していることとする。ユーザは利用端末１０からサービス提供サーバ２４にログインし（Ｓ１）、ＩＤ連携を要求する（Ｓ１７)。Ｓ３〜Ｓ７の処理の後、認証デバイス３４は、ＩＤ連携情報を含む認証情報を生成する。この時、当該認証情報はユーザ認証に基づいてアクセスが許可される耐タンパな領域に格納された秘密鍵で署名される（Ｓ１８）。続いて、署名された認証情報、セッションＩＤ、メタデータＩＤ、及びメタデータ公開サーバ５０のＵＲＬを含むレスポンス情報をサービス提供サーバ２４に送信する（Ｓ２３）。Ｓ９、Ｓ１０、Ｓ１５、Ｓ１６の処理の後、サービス提供サーバ２４は、認証デバイス３４から受信したメタデータに含まれる公開鍵証明書の真正性を認証局４０の公開鍵証明書により検証するとともに、受信した認証情報の真正性を、真正性が検証された当該認証デバイス３４の公開鍵証明書により検証する（Ｓ２０）。なお、認証デバイス３４の公開鍵証明書の検証の際には、必要に応じ認証局４０に対しＣＲＬ（無効証明書リスト）の確認を行う。これらの検証により公開鍵証明書の真正性が確認されることで、認証端末が信頼できることを確認できる。そして、メタデータを登録するとともに、ＩＤ連携情報をユーザＩＤと関連付けて登録し（Ｓ２１）、最後に利用端末に連携完了を通知する（Ｓ２２）。
【００３２】
以上の処理を認証デバイスごとに行うことにより、サービス提供サーバにメタデータを登録できるとともに、サービス提供サーバと認証デバイスとの間の信頼関係を確立でき、図２に示すような携帯電話等を認証デバイスとして利用可能な状態に容易にプロビジョニングすることができる。
なお、認証デバイスがＨＴＴＰリクエストを受け取れない場合には、例えばサービス提供サーバ２４と認証デバイス３４との間のリクエスト送受信（Ｓ５、Ｓ６）を電子メールで行うことができる。この場合、Ｓ３ではＵＲＬとして認証デバイス３４のメールアドレスを送信する。また、その他ＱＲコード（登録商標）などを用いた通信手段も考えられ、その場合には認証デバイスにそれ相当の通信機能（コード読み取り機能など）が必要になる。
【００３３】
〔プロビジョニング後に実現される認証デバイスを用いた認証処理〕
先に説明したように、上記各実施形態の処理により図２に示すようにプロビジョニングされた以後は利用端末１０からサービスを利用する際には、従来の認証処理（利用端末からのユーザＩＤ／パスワードの入力による認証）の代わりに、認証デバイス３０が生成する認証情報を利用してサービス提供サーバ２０にログイン（シングルサインオン）することが可能となる。図９はプロビジョニング後に実現される認証処理シーケンスの例である。なお、この例は認証デバイス３０がＨＴＴＰリクエストを受け付けられない場合でも認証デバイス３０の認証処理を利用可能なように認証デバイス３０とサービス提供サーバ２０との間に中継サーバ６０を挿入し、中継サーバ６０を介して認証デバイス３０との認証待ち受け通信セッションとサービス提供サーバ２０とのＨＴＴＰセッションとをつなぐ構成としたものである。以下、当該シーケンスを説明する。
【００３４】
ユーザは利用端末１０を用いてサービス提供サーバ２０にアクセスし、サービスを要求する（Ｓ１０３）。サービス提供サーバ２０は、利用端末１０に対し認証に必要な情報の提供を要求し（Ｓ１０４）、ユーザは利用端末１０から認証デバイス３０に割り当てられたＵＲＬ（中継サーバ６０のＵＲＬ＋認証デバイス識別子）を返信する（Ｓ１０５）。サービス提供サーバ２０は、利用端末１０との間でセッションＢを確立してセッションＢのセッションＩＤを生成し、このセッションＩＤと認証デバイス識別子とサービス提供サーバ２０のＵＲＬとを含めた認証要求を中継サーバ６０のＵＲＬに送信する（Ｓ１０６）。また、ここまでの間に、認証デバイス３０から中継サーバ６０に認証デバイス識別子を送信し（Ｓ１０１）、中継サーバ６０は、認証端末１０との間にセッションＡを確立するとともに認証デバイス識別子をセッションＡと関連付けて保持しておく（Ｓ１０２）。中継サーバ６０は、サービス提供サーバ２０からの認証要求を受け、認証デバイス識別子をキーにセッションＡを検索し、サービス提供サーバ２０のＵＲＬとセッションＢのセッションＩＤとを認証デバイス３０に転送する（Ｓ１０７）。認証デバイス３０では、ユーザ認証処理を行い（Ｓ１０８）、認証情報を生成する（Ｓ１０９）。ここで、安全性向上のため、当該認証情報に認証デバイス３０の秘密鍵で署名を付与することができる。そして、認証情報とサービス提供サーバのＵＲＬとセッションＢのセッションＩＤとを含む認証結果を中継サーバ６０に返信し（Ｓ１１０）、中継サーバ６０は認証情報とセッションＢのセッションＩＤと含む認証結果をＳ１０６の認証要求に対する返答としてサービス提供サーバのＵＲＬに中継転送する（Ｓ１１１）。サービス提供サーバ２０は、上記各実施形態の処理によりプロビジョニングされたメタデータをＳ１０５で返信された認証デバイス識別子をキーとして検索し、このメタデータを用いて中継サーバ６０から受信した認証情報を検証する（Ｓ１１２）。ここで、Ｓ１０９にて認証情報に署名をした場合は、メタデータに含まれる認証デバイス３０の公開鍵証明書により署名の検証をすることができる。認証されていることが確認できれば、セッションＢに係るユーザのログインを受け付け、サービスを提供する（Ｓ１１３）。
【００３５】
なお、図９の例ではＳ１０５で認証デバイス３０に割り当てられたＵＲＬを返信しているが、この代わりに認証デバイス３０のメタデータＩＤを返信する方法もある。その場合には、サービス提供サーバ２０で保持しているメタデータに認証デバイス３０に割り当てられたＵＲＬを記述しておき、メタデータＩＤにより当該メタデータを検索可能とすることで認証をリクエストする先を解決できるようにしておけばよい。
【産業上の利用可能性】
【００３６】
本発明は、サービス提供サーバへログインする際の認証処理を、認証サーバの代わりに携帯電話等ユーザが所有しているデバイスを認証デバイスとして用いて実現したい場合に有用である。
【図面の簡単な説明】
【００３７】
【図１】本発明の認証システムのプロビジョニング前の状態を示す図。
【図２】本発明の認証システムのプロビジョニング後の状態を示す図。
【図３】本発明の第１実施形態のプロビジョニングシーケンスの例を示す図。
【図４】本発明の第１、第３実施形態のシステム構成の例を示す図。
【図５】本発明の第２実施形態のプロビジョニングシーケンスの例を示す図。
【図６】本発明の第２、第４実施形態のシステム構成の例を示す図。
【図７】本発明の第３実施形態のプロビジョニングシーケンスの例を示す図。
【図８】本発明の第４実施形態のプロビジョニングシーケンスの例を示す図。
【図９】本発明によるプロビジョニング後の認証シーケンスの例を示す図。
【図１０】従来の認証システムの構成の例を示す図。
【図１１】従来の認証システムの別の構成の例を示す図。
【特許請求の範囲】
【請求項１】
利用端末とサービス提供サーバと認証デバイスと認証局とを用いて認証処理を行う認証システムのメタデータプロビジョニング方法であって、
上記サービス提供サーバは、上記認証局の公開鍵証明書を予め保持し、
上記認証デバイスは、上記認証局から発行を受けた自身の秘密鍵と、上記認証局から発行を受けた自身の公開鍵証明書を含む、メタデータとを予め保持し、
上記サービス提供サーバが、上記利用端末で入力されたユーザＩＤとパスワードによりユーザを認証する第１ユーザ認証ステップと、
上記サービス提供サーバが、上記利用端末で入力されたメタデータ登録要求を受け付けるメタデータ登録要求ステップと、
上記サービス提供サーバが、上記利用端末で入力された上記認証デバイスのＵＲＬを受信するＵＲＬ通知ステップと、
上記サービス提供サーバが、セッションＩＤを生成し上記ユーザＩＤと関連付けて記憶するセッションＩＤ生成ステップと、
上記サービス提供サーバが、当該セッションＩＤを当該サービス提供サーバのＵＲＬとともに上記認証デバイスに送信するリクエスト送信ステップと、
上記認証デバイスが、上記リクエスト送信ステップで送信された情報を受信するリクエスト受信ステップと、
上記認証デバイスが、ユーザ認証を行う第２ユーザ認証ステップと、
上記認証デバイスが、上記セッションＩＤと上記メタデータとを上記サービス提供サーバに送信するレスポンス送信ステップと、
上記サービス提供サーバが、上記レスポンス送信ステップで送信された情報を受信するレスポンス受信ステップと、
上記サービス提供サーバが、上記レスポンス受信ステップで受信したセッションＩＤを確認するセッションＩＤ確認ステップと、
上記サービス提供サーバが、上記認証デバイスの公開鍵証明書を上記認証局の公開鍵証明書により検証する検証ステップと、
上記サービス提供サーバが、上記認証デバイスから受信したメタデータを登録するメタデータ登録ステップと、
上記サービス提供サーバが、上記利用端末にメタデータ登録完了通知をするメタデータ登録完了通知ステップと、
を実行する認証システムのメタデータプロビジョニング方法。
【請求項２】
利用端末とサービス提供サーバと認証デバイスと認証局とメタデータ公開サーバとを用いて認証処理を行う認証システムのメタデータプロビジョニング方法であって、
上記サービス提供サーバは、上記認証局の公開鍵証明書を予め保持し、
上記認証デバイスは、上記認証局から発行を受けた自身の秘密鍵を予め保持し、
上記メタデータ公開サーバは、上記認証局から発行を受けた上記認証デバイスの公開鍵証明書を含む、メタデータを予め保持し、
上記サービス提供サーバが、上記利用端末で入力されたユーザＩＤとパスワードによりユーザを認証する第１ユーザ認証ステップと、
上記サービス提供サーバが、上記利用端末で入力されたメタデータ登録要求を受け付けるメタデータ登録要求ステップと、
上記サービス提供サーバが、上記利用端末で入力された上記認証デバイスのＵＲＬを受信するＵＲＬ通知ステップと、
上記サービス提供サーバが、セッションＩＤを生成し上記ユーザＩＤと関連付けて記憶するセッションＩＤ生成ステップと、
上記サービス提供サーバが、当該セッションＩＤを当該サービス提供サーバのＵＲＬとともに上記認証デバイスに通知するリクエスト送信ステップと、
上記認証デバイスが、上記リクエスト送信ステップで送信された情報を受信するリクエスト受信ステップと、
上記認証デバイスが、ユーザ認証を行う第２ユーザ認証ステップと、
上記認証デバイスが、上記セッションＩＤとメタデータ公開サーバのＵＲＬとメタデータＩＤとを上記サービス提供サーバに送信するレスポンス送信ステップと、
上記サービス提供サーバが、上記レスポンス送信ステップで送信された情報を受信するレスポンス受信ステップと、
上記サービス提供サーバが、上記レスポンス受信ステップで受信したセッションＩＤを確認するセッションＩＤ確認ステップと、
上記サービス提供サーバが、上記メタデータ公開サーバに上記メタデータＩＤの上記メタデータを要求するメタデータリクエストステップと、
上記メタデータ公開サーバが、上記サービス提供サーバからの要求に応じ、上記メタデータＩＤに該当する上記メタデータを抽出し、これを上記サービス提供サーバに返答するメタデータレスポンスステップと、
上記サービス提供サーバが、上記認証デバイスの公開鍵証明書を上記認証局の公開鍵証明書により検証する検証ステップと、
上記サービス提供サーバが、上記認証デバイスから受信したメタデータを登録するメタデータ登録ステップと、
上記サービス提供サーバが、上記利用端末にメタデータ登録完了通知をするメタデータ登録完了通知ステップと、
を実行する認証システムのメタデータプロビジョニング方法。
【請求項３】
利用端末とサービス提供サーバと認証デバイスと認証局とを用いて認証処理を行う認証システムのメタデータプロビジョニング方法であって、
上記サービス提供サーバは、上記認証局の公開鍵証明書を予め保持し、
上記認証デバイスは、上記認証局から発行を受けた自身の秘密鍵と、上記認証局から発行を受けた自身の公開鍵証明書を含む、メタデータとを予め保持し、
上記サービス提供サーバが、上記利用端末で入力されたユーザＩＤとパスワードによりユーザを認証する第１ユーザ認証ステップと、
上記サービス提供サーバが、上記利用端末で入力されたＩＤ連携要求を受け付ける連携要求ステップと、
上記サービス提供サーバが、上記利用端末で入力された上記認証デバイスのＵＲＬを受信するＵＲＬ通知ステップと、
上記サービス提供サーバが、セッションＩＤを生成し上記ユーザＩＤと関連付けて記憶するセッションＩＤ生成ステップと、
上記サービス提供サーバが、当該セッションＩＤを当該サービス提供サーバのＵＲＬとともに上記認証デバイスに送信するリクエスト送信ステップと、
上記認証デバイスが、上記リクエスト送信ステップで送信された情報を受信するリクエスト受信ステップと、
上記認証デバイスが、ユーザ認証を行う第２ユーザ認証ステップと、
上記認証デバイスが、ＩＤ連携情報を含む認証情報を生成し、当該認証デバイスの秘密鍵で署名する認証情報生成ステップと、
上記認証デバイスが、署名された上記認証情報と上記セッションＩＤと上記メタデータとを上記サービス提供サーバに送信するレスポンス送信ステップと、
上記サービス提供サーバが、上記レスポンス送信ステップで送信された情報を受信するレスポンス受信ステップと、
上記サービス提供サーバが、上記レスポンス受信ステップで受信したセッションＩＤを確認するセッションＩＤ確認ステップと、
上記サービス提供サーバが、上記認証デバイスの公開鍵証明書を上記認証局の公開鍵証明書により検証するとともに、上記認証デバイスの公開鍵証明書により上記認証情報を検証する検証ステップと、
上記サービス提供サーバが、検証済の上記認証情報に含まれるＩＤ連携情報と上記ユーザＩＤとを関連付けて登録するとともに、上記認証デバイスから受信したメタデータを登録するメタデータ登録ステップと、
上記サービス提供サーバが、上記利用端末に連携完了通知をする連携完了通知ステップと、
を実行する認証システムのメタデータプロビジョニング方法。
【請求項４】
利用端末とサービス提供サーバと認証デバイスと認証局とメタデータ公開サーバとを用いて認証処理を行う認証システムのメタデータプロビジョニング方法であって、
上記サービス提供サーバは、上記認証局の公開鍵証明書を予め保持し、
上記認証デバイスは、上記認証局から発行を受けた自身の秘密鍵を予め保持し、
上記メタデータ公開サーバは、上記認証局から発行を受けた上記認証デバイスの公開鍵証明書を含む、メタデータを予め保持し、
上記サービス提供サーバが、上記利用端末で入力されたユーザＩＤとパスワードによりユーザを認証する第１ユーザ認証ステップと、
上記サービス提供サーバが、上記利用端末で入力されたＩＤ連携要求を受け付ける連携要求ステップと、
上記サービス提供サーバが、上記利用端末で入力された上記認証デバイスのＵＲＬを受信するＵＲＬ通知ステップと、
上記サービス提供サーバが、セッションＩＤを生成し上記ユーザＩＤと関連付けて記憶するセッションＩＤ生成ステップと、
上記サービス提供サーバが、当該セッションＩＤを当該サービス提供サーバのＵＲＬとともに上記認証デバイスに通知するリクエスト送信ステップと、
上記認証デバイスが、上記リクエスト送信ステップで送信された情報を受信するリクエスト受信ステップと、
上記認証デバイスが、ユーザ認証を行う第２ユーザ認証ステップと、
上記認証デバイスが、ＩＤ連携情報を含む認証情報を生成し当該認証デバイスの秘密鍵で署名する認証情報生成ステップと、
上記認証デバイスが、署名された上記認証情報と上記セッションＩＤとメタデータ公開サーバのＵＲＬとメタデータＩＤとを上記サービス提供サーバに送信するレスポンス送信ステップと、
上記サービス提供サーバが、上記レスポンス送信ステップで送信された情報を受信するレスポンス受信ステップと、
上記サービス提供サーバが、上記レスポンス受信ステップで受信したセッションＩＤを確認するセッションＩＤ確認ステップと、
上記サービス提供サーバが、上記メタデータ公開サーバに上記メタデータＩＤの上記メタデータを要求するメタデータリクエストステップと、
上記メタデータ公開サーバが、上記サービス提供サーバからの要求に応じ、上記メタデータＩＤに該当する上記メタデータを抽出し、これを上記サービス提供サーバに返答するメタデータレスポンスステップと、
上記サービス提供サーバが、上記認証デバイスの公開鍵証明書を上記認証局の公開鍵証明書により検証するとともに、上記認証デバイスの公開鍵証明書により上記認証情報を検証する検証ステップと、
上記サービス提供サーバが、検証済の上記認証情報に含まれるＩＤ連携情報と上記ユーザＩＤとを関連付けて登録するとともに、上記認証デバイスから受信したメタデータを登録するメタデータ登録ステップと、
上記サービス提供サーバが、上記利用端末に連携完了通知をする連携完了通知ステップと、
を実行する認証システムのメタデータプロビジョニング方法。
【請求項５】
請求項３又は４のいずれかに記載の認証システムのメタデータプロビジョニング方法において、上記ＩＤ連携情報は、仮名であることを特徴とする認証システムのメタデータプロビジョニング方法。
【請求項６】
請求項１〜５のいずれかに記載の認証システムのメタデータプロビジョニング方法において、
上記ＵＲＬ通知ステップにおいて上記利用端末で入力される上記認証デバイスのＵＲＬは当該認証デバイスのメールアドレスであり、
上記リクエスト送信ステップと上記リクエスト受信ステップは電子メールの送受信により実行する
ことを特徴とする認証システムのメタデータプロビジョニング方法。
【請求項７】
利用端末とサービス提供サーバと認証デバイスと認証局とを用いて認証処理を行う認証システムのメタデータプロビジョニングシステムであって、
上記利用端末は、メタデータの登録処理に必要な情報の入力・送信機能と、当該サービス提供サーバから送信された情報の受信機能とを有し、
上記サービス提供サーバは、上記認証局の公開鍵証明書を予め保持し、上記利用端末から入力されたユーザＩＤとパスワードによりユーザを認証するユーザ認証機能と、上記認証デバイスとの連携に必要な情報を当該認証デバイスに送信するリクエスト送信機能と、上記認証デバイスから返信された当該認証デバイスの公開鍵証明書を含むメタデータ等の情報を受信するレスポンス受信機能と、上記利用端末とのセッションと上記認証デバイスとのセッションとを関連付けるセッションＩＤを生成・管理するセッションＩＤ生成・管理機能と、上記認証局の公開鍵証明書により上記認証デバイスの公開鍵証明書の検証を行う検証機能と、上記メタデータを登録するメタデータ登録機能とを有し、
上記認証デバイスは、上記認証局から発行を受けた自身の秘密鍵と、上記認証局から発行を受けた自身の公開鍵証明書を含む、メタデータとを予め保持し、上記サービス提供サーバとの連携に必要な情報を当該サービス提供サーバから受信するリクエスト受信機能と、ユーザ認証を行うユーザ認証機能と、上記メタデータその他連携に必要な情報を送信するレスポンス送信機能とを有する
ことを特徴とする認証システムのメタデータプロビジョニングシステム。
【請求項８】
利用端末とサービス提供サーバと認証デバイスと認証局とメタデータ公開サーバとを用いて認証処理を行う認証システムのメタデータプロビジョニングシステムであって、
上記利用端末は、メタデータの登録処理に必要な情報の入力・送信機能と、当該サービス提供サーバから送信された情報の受信機能とを有し、
上記サービス提供サーバは、上記認証局の公開鍵証明書を予め保持し、上記利用端末から入力されたユーザＩＤとパスワードによりユーザを認証するユーザ認証機能と、上記認証デバイスとの連携に必要な情報を当該認証デバイスに送信するリクエスト送信機能と、上記認証デバイスから返信された当該認証デバイスのメタデータＩＤ等の情報を受信するレスポンス受信機能と、上記利用端末とのセッションと上記認証デバイスとのセッションとを関連付けるセッションＩＤを生成・管理するセッションＩＤ生成・管理機能と、上記メタデータ公開サーバに対し、上記認証局が発行した上記認証デバイスの公開鍵証明書を含む、上記メタデータＩＤのメタデータを要求し、当該メタデータを受信するメタデータ解決機能と、上記認証局の公開鍵証明書により上記認証デバイスの公開鍵証明書の検証を行う検証機能と、上記メタデータを登録するメタデータ登録機能とを有し、
上記認証デバイスは、上記認証局から発行を受けた秘密鍵を予め保持し、上記サービス提供サーバとの連携に必要な情報を当該サービス提供サーバから受信するリクエスト受信機能と、ユーザ認証を行うユーザ認証機能と、上記メタデータＩＤその他連携に必要な情報を送信するレスポンス送信機能とを有し、
上記メタデータ公開サーバは、上記メタデータを予め保持し、上記サービス提供サーバからの要求に応じ上記メタデータＩＤに該当する上記メタデータを返信するメタデータ管理機能を有する
ことを特徴とする認証システムのメタデータプロビジョニングシステム。
【請求項９】
認証局の公開鍵証明書を予め保持し、利用端末から入力されたユーザＩＤとパスワードによりユーザを認証するユーザ認証機能と、認証デバイスとの連携に必要な情報を当該認証デバイスに送信するリクエスト送信機能と、上記認証デバイスから返信された当該認証デバイスの公開鍵証明書を含むメタデータ等の情報を受信するレスポンス受信機能と、上記利用端末とのセッションと上記認証デバイスとのセッションとを関連付けるセッションＩＤを生成・管理するセッションＩＤ生成・管理機能と、上記認証局の公開鍵証明書により上記認証デバイスの公開鍵証明書の検証を行う検証機能と、上記メタデータを登録するメタデータ登録機能と、を有するサービス提供サーバ。
【請求項１０】
認証局の公開鍵証明書を予め保持し、利用端末から入力されたユーザＩＤとパスワードによりユーザを認証するユーザ認証機能と、認証デバイスとの連携に必要な情報を当該認証デバイスに送信するリクエスト送信機能と、上記認証デバイスから返信された当該認証デバイスのメタデータＩＤ等の情報を受信するレスポンス受信機能と、上記利用端末とのセッションと上記認証デバイスとのセッションとを関連付けるセッションＩＤを生成・管理するセッションＩＤ生成・管理機能と、メタデータ公開サーバに対し、上記認証局が発行した上記認証デバイスの公開鍵証明書を含む、上記メタデータＩＤのメタデータを要求し、当該メタデータを受信するメタデータ解決機能と、上記認証局の公開鍵証明書により上記認証デバイスの公開鍵証明書の検証を行う検証機能と、上記メタデータを登録するメタデータ登録機能と、
を有するサービス提供サーバ。
【請求項１１】
請求項７〜１０のいずれかに記載したシステムとしてコンピュータを機能させるためのプログラム。
【請求項１２】
請求項１１に記載したプログラムを記録したコンピュータが読み取り可能な記録媒体。
【請求項１】
利用端末とサービス提供サーバと認証デバイスと認証局とを用いて認証処理を行う認証システムのメタデータプロビジョニング方法であって、
上記サービス提供サーバは、上記認証局の公開鍵証明書を予め保持し、
上記認証デバイスは、上記認証局から発行を受けた自身の秘密鍵と、上記認証局から発行を受けた自身の公開鍵証明書を含む、メタデータとを予め保持し、
上記サービス提供サーバが、上記利用端末で入力されたユーザＩＤとパスワードによりユーザを認証する第１ユーザ認証ステップと、
上記サービス提供サーバが、上記利用端末で入力されたメタデータ登録要求を受け付けるメタデータ登録要求ステップと、
上記サービス提供サーバが、上記利用端末で入力された上記認証デバイスのＵＲＬを受信するＵＲＬ通知ステップと、
上記サービス提供サーバが、セッションＩＤを生成し上記ユーザＩＤと関連付けて記憶するセッションＩＤ生成ステップと、
上記サービス提供サーバが、当該セッションＩＤを当該サービス提供サーバのＵＲＬとともに上記認証デバイスに送信するリクエスト送信ステップと、
上記認証デバイスが、上記リクエスト送信ステップで送信された情報を受信するリクエスト受信ステップと、
上記認証デバイスが、ユーザ認証を行う第２ユーザ認証ステップと、
上記認証デバイスが、上記セッションＩＤと上記メタデータとを上記サービス提供サーバに送信するレスポンス送信ステップと、
上記サービス提供サーバが、上記レスポンス送信ステップで送信された情報を受信するレスポンス受信ステップと、
上記サービス提供サーバが、上記レスポンス受信ステップで受信したセッションＩＤを確認するセッションＩＤ確認ステップと、
上記サービス提供サーバが、上記認証デバイスの公開鍵証明書を上記認証局の公開鍵証明書により検証する検証ステップと、
上記サービス提供サーバが、上記認証デバイスから受信したメタデータを登録するメタデータ登録ステップと、
上記サービス提供サーバが、上記利用端末にメタデータ登録完了通知をするメタデータ登録完了通知ステップと、
を実行する認証システムのメタデータプロビジョニング方法。
【請求項２】
利用端末とサービス提供サーバと認証デバイスと認証局とメタデータ公開サーバとを用いて認証処理を行う認証システムのメタデータプロビジョニング方法であって、
上記サービス提供サーバは、上記認証局の公開鍵証明書を予め保持し、
上記認証デバイスは、上記認証局から発行を受けた自身の秘密鍵を予め保持し、
上記メタデータ公開サーバは、上記認証局から発行を受けた上記認証デバイスの公開鍵証明書を含む、メタデータを予め保持し、
上記サービス提供サーバが、上記利用端末で入力されたユーザＩＤとパスワードによりユーザを認証する第１ユーザ認証ステップと、
上記サービス提供サーバが、上記利用端末で入力されたメタデータ登録要求を受け付けるメタデータ登録要求ステップと、
上記サービス提供サーバが、上記利用端末で入力された上記認証デバイスのＵＲＬを受信するＵＲＬ通知ステップと、
上記サービス提供サーバが、セッションＩＤを生成し上記ユーザＩＤと関連付けて記憶するセッションＩＤ生成ステップと、
上記サービス提供サーバが、当該セッションＩＤを当該サービス提供サーバのＵＲＬとともに上記認証デバイスに通知するリクエスト送信ステップと、
上記認証デバイスが、上記リクエスト送信ステップで送信された情報を受信するリクエスト受信ステップと、
上記認証デバイスが、ユーザ認証を行う第２ユーザ認証ステップと、
上記認証デバイスが、上記セッションＩＤとメタデータ公開サーバのＵＲＬとメタデータＩＤとを上記サービス提供サーバに送信するレスポンス送信ステップと、
上記サービス提供サーバが、上記レスポンス送信ステップで送信された情報を受信するレスポンス受信ステップと、
上記サービス提供サーバが、上記レスポンス受信ステップで受信したセッションＩＤを確認するセッションＩＤ確認ステップと、
上記サービス提供サーバが、上記メタデータ公開サーバに上記メタデータＩＤの上記メタデータを要求するメタデータリクエストステップと、
上記メタデータ公開サーバが、上記サービス提供サーバからの要求に応じ、上記メタデータＩＤに該当する上記メタデータを抽出し、これを上記サービス提供サーバに返答するメタデータレスポンスステップと、
上記サービス提供サーバが、上記認証デバイスの公開鍵証明書を上記認証局の公開鍵証明書により検証する検証ステップと、
上記サービス提供サーバが、上記認証デバイスから受信したメタデータを登録するメタデータ登録ステップと、
上記サービス提供サーバが、上記利用端末にメタデータ登録完了通知をするメタデータ登録完了通知ステップと、
を実行する認証システムのメタデータプロビジョニング方法。
【請求項３】
利用端末とサービス提供サーバと認証デバイスと認証局とを用いて認証処理を行う認証システムのメタデータプロビジョニング方法であって、
上記サービス提供サーバは、上記認証局の公開鍵証明書を予め保持し、
上記認証デバイスは、上記認証局から発行を受けた自身の秘密鍵と、上記認証局から発行を受けた自身の公開鍵証明書を含む、メタデータとを予め保持し、
上記サービス提供サーバが、上記利用端末で入力されたユーザＩＤとパスワードによりユーザを認証する第１ユーザ認証ステップと、
上記サービス提供サーバが、上記利用端末で入力されたＩＤ連携要求を受け付ける連携要求ステップと、
上記サービス提供サーバが、上記利用端末で入力された上記認証デバイスのＵＲＬを受信するＵＲＬ通知ステップと、
上記サービス提供サーバが、セッションＩＤを生成し上記ユーザＩＤと関連付けて記憶するセッションＩＤ生成ステップと、
上記サービス提供サーバが、当該セッションＩＤを当該サービス提供サーバのＵＲＬとともに上記認証デバイスに送信するリクエスト送信ステップと、
上記認証デバイスが、上記リクエスト送信ステップで送信された情報を受信するリクエスト受信ステップと、
上記認証デバイスが、ユーザ認証を行う第２ユーザ認証ステップと、
上記認証デバイスが、ＩＤ連携情報を含む認証情報を生成し、当該認証デバイスの秘密鍵で署名する認証情報生成ステップと、
上記認証デバイスが、署名された上記認証情報と上記セッションＩＤと上記メタデータとを上記サービス提供サーバに送信するレスポンス送信ステップと、
上記サービス提供サーバが、上記レスポンス送信ステップで送信された情報を受信するレスポンス受信ステップと、
上記サービス提供サーバが、上記レスポンス受信ステップで受信したセッションＩＤを確認するセッションＩＤ確認ステップと、
上記サービス提供サーバが、上記認証デバイスの公開鍵証明書を上記認証局の公開鍵証明書により検証するとともに、上記認証デバイスの公開鍵証明書により上記認証情報を検証する検証ステップと、
上記サービス提供サーバが、検証済の上記認証情報に含まれるＩＤ連携情報と上記ユーザＩＤとを関連付けて登録するとともに、上記認証デバイスから受信したメタデータを登録するメタデータ登録ステップと、
上記サービス提供サーバが、上記利用端末に連携完了通知をする連携完了通知ステップと、
を実行する認証システムのメタデータプロビジョニング方法。
【請求項４】
利用端末とサービス提供サーバと認証デバイスと認証局とメタデータ公開サーバとを用いて認証処理を行う認証システムのメタデータプロビジョニング方法であって、
上記サービス提供サーバは、上記認証局の公開鍵証明書を予め保持し、
上記認証デバイスは、上記認証局から発行を受けた自身の秘密鍵を予め保持し、
上記メタデータ公開サーバは、上記認証局から発行を受けた上記認証デバイスの公開鍵証明書を含む、メタデータを予め保持し、
上記サービス提供サーバが、上記利用端末で入力されたユーザＩＤとパスワードによりユーザを認証する第１ユーザ認証ステップと、
上記サービス提供サーバが、上記利用端末で入力されたＩＤ連携要求を受け付ける連携要求ステップと、
上記サービス提供サーバが、上記利用端末で入力された上記認証デバイスのＵＲＬを受信するＵＲＬ通知ステップと、
上記サービス提供サーバが、セッションＩＤを生成し上記ユーザＩＤと関連付けて記憶するセッションＩＤ生成ステップと、
上記サービス提供サーバが、当該セッションＩＤを当該サービス提供サーバのＵＲＬとともに上記認証デバイスに通知するリクエスト送信ステップと、
上記認証デバイスが、上記リクエスト送信ステップで送信された情報を受信するリクエスト受信ステップと、
上記認証デバイスが、ユーザ認証を行う第２ユーザ認証ステップと、
上記認証デバイスが、ＩＤ連携情報を含む認証情報を生成し当該認証デバイスの秘密鍵で署名する認証情報生成ステップと、
上記認証デバイスが、署名された上記認証情報と上記セッションＩＤとメタデータ公開サーバのＵＲＬとメタデータＩＤとを上記サービス提供サーバに送信するレスポンス送信ステップと、
上記サービス提供サーバが、上記レスポンス送信ステップで送信された情報を受信するレスポンス受信ステップと、
上記サービス提供サーバが、上記レスポンス受信ステップで受信したセッションＩＤを確認するセッションＩＤ確認ステップと、
上記サービス提供サーバが、上記メタデータ公開サーバに上記メタデータＩＤの上記メタデータを要求するメタデータリクエストステップと、
上記メタデータ公開サーバが、上記サービス提供サーバからの要求に応じ、上記メタデータＩＤに該当する上記メタデータを抽出し、これを上記サービス提供サーバに返答するメタデータレスポンスステップと、
上記サービス提供サーバが、上記認証デバイスの公開鍵証明書を上記認証局の公開鍵証明書により検証するとともに、上記認証デバイスの公開鍵証明書により上記認証情報を検証する検証ステップと、
上記サービス提供サーバが、検証済の上記認証情報に含まれるＩＤ連携情報と上記ユーザＩＤとを関連付けて登録するとともに、上記認証デバイスから受信したメタデータを登録するメタデータ登録ステップと、
上記サービス提供サーバが、上記利用端末に連携完了通知をする連携完了通知ステップと、
を実行する認証システムのメタデータプロビジョニング方法。
【請求項５】
請求項３又は４のいずれかに記載の認証システムのメタデータプロビジョニング方法において、上記ＩＤ連携情報は、仮名であることを特徴とする認証システムのメタデータプロビジョニング方法。
【請求項６】
請求項１〜５のいずれかに記載の認証システムのメタデータプロビジョニング方法において、
上記ＵＲＬ通知ステップにおいて上記利用端末で入力される上記認証デバイスのＵＲＬは当該認証デバイスのメールアドレスであり、
上記リクエスト送信ステップと上記リクエスト受信ステップは電子メールの送受信により実行する
ことを特徴とする認証システムのメタデータプロビジョニング方法。
【請求項７】
利用端末とサービス提供サーバと認証デバイスと認証局とを用いて認証処理を行う認証システムのメタデータプロビジョニングシステムであって、
上記利用端末は、メタデータの登録処理に必要な情報の入力・送信機能と、当該サービス提供サーバから送信された情報の受信機能とを有し、
上記サービス提供サーバは、上記認証局の公開鍵証明書を予め保持し、上記利用端末から入力されたユーザＩＤとパスワードによりユーザを認証するユーザ認証機能と、上記認証デバイスとの連携に必要な情報を当該認証デバイスに送信するリクエスト送信機能と、上記認証デバイスから返信された当該認証デバイスの公開鍵証明書を含むメタデータ等の情報を受信するレスポンス受信機能と、上記利用端末とのセッションと上記認証デバイスとのセッションとを関連付けるセッションＩＤを生成・管理するセッションＩＤ生成・管理機能と、上記認証局の公開鍵証明書により上記認証デバイスの公開鍵証明書の検証を行う検証機能と、上記メタデータを登録するメタデータ登録機能とを有し、
上記認証デバイスは、上記認証局から発行を受けた自身の秘密鍵と、上記認証局から発行を受けた自身の公開鍵証明書を含む、メタデータとを予め保持し、上記サービス提供サーバとの連携に必要な情報を当該サービス提供サーバから受信するリクエスト受信機能と、ユーザ認証を行うユーザ認証機能と、上記メタデータその他連携に必要な情報を送信するレスポンス送信機能とを有する
ことを特徴とする認証システムのメタデータプロビジョニングシステム。
【請求項８】
利用端末とサービス提供サーバと認証デバイスと認証局とメタデータ公開サーバとを用いて認証処理を行う認証システムのメタデータプロビジョニングシステムであって、
上記利用端末は、メタデータの登録処理に必要な情報の入力・送信機能と、当該サービス提供サーバから送信された情報の受信機能とを有し、
上記サービス提供サーバは、上記認証局の公開鍵証明書を予め保持し、上記利用端末から入力されたユーザＩＤとパスワードによりユーザを認証するユーザ認証機能と、上記認証デバイスとの連携に必要な情報を当該認証デバイスに送信するリクエスト送信機能と、上記認証デバイスから返信された当該認証デバイスのメタデータＩＤ等の情報を受信するレスポンス受信機能と、上記利用端末とのセッションと上記認証デバイスとのセッションとを関連付けるセッションＩＤを生成・管理するセッションＩＤ生成・管理機能と、上記メタデータ公開サーバに対し、上記認証局が発行した上記認証デバイスの公開鍵証明書を含む、上記メタデータＩＤのメタデータを要求し、当該メタデータを受信するメタデータ解決機能と、上記認証局の公開鍵証明書により上記認証デバイスの公開鍵証明書の検証を行う検証機能と、上記メタデータを登録するメタデータ登録機能とを有し、
上記認証デバイスは、上記認証局から発行を受けた秘密鍵を予め保持し、上記サービス提供サーバとの連携に必要な情報を当該サービス提供サーバから受信するリクエスト受信機能と、ユーザ認証を行うユーザ認証機能と、上記メタデータＩＤその他連携に必要な情報を送信するレスポンス送信機能とを有し、
上記メタデータ公開サーバは、上記メタデータを予め保持し、上記サービス提供サーバからの要求に応じ上記メタデータＩＤに該当する上記メタデータを返信するメタデータ管理機能を有する
ことを特徴とする認証システムのメタデータプロビジョニングシステム。
【請求項９】
認証局の公開鍵証明書を予め保持し、利用端末から入力されたユーザＩＤとパスワードによりユーザを認証するユーザ認証機能と、認証デバイスとの連携に必要な情報を当該認証デバイスに送信するリクエスト送信機能と、上記認証デバイスから返信された当該認証デバイスの公開鍵証明書を含むメタデータ等の情報を受信するレスポンス受信機能と、上記利用端末とのセッションと上記認証デバイスとのセッションとを関連付けるセッションＩＤを生成・管理するセッションＩＤ生成・管理機能と、上記認証局の公開鍵証明書により上記認証デバイスの公開鍵証明書の検証を行う検証機能と、上記メタデータを登録するメタデータ登録機能と、を有するサービス提供サーバ。
【請求項１０】
認証局の公開鍵証明書を予め保持し、利用端末から入力されたユーザＩＤとパスワードによりユーザを認証するユーザ認証機能と、認証デバイスとの連携に必要な情報を当該認証デバイスに送信するリクエスト送信機能と、上記認証デバイスから返信された当該認証デバイスのメタデータＩＤ等の情報を受信するレスポンス受信機能と、上記利用端末とのセッションと上記認証デバイスとのセッションとを関連付けるセッションＩＤを生成・管理するセッションＩＤ生成・管理機能と、メタデータ公開サーバに対し、上記認証局が発行した上記認証デバイスの公開鍵証明書を含む、上記メタデータＩＤのメタデータを要求し、当該メタデータを受信するメタデータ解決機能と、上記認証局の公開鍵証明書により上記認証デバイスの公開鍵証明書の検証を行う検証機能と、上記メタデータを登録するメタデータ登録機能と、
を有するサービス提供サーバ。
【請求項１１】
請求項７〜１０のいずれかに記載したシステムとしてコンピュータを機能させるためのプログラム。
【請求項１２】
請求項１１に記載したプログラムを記録したコンピュータが読み取り可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００９−１１８１１０（Ｐ２００９−１１８１１０Ａ）
【公開日】平成２１年５月２８日（２００９．５．２８）
【国際特許分類】
【出願番号】特願２００７−２８８０８５（Ｐ２００７−２８８０８５）
【出願日】平成１９年１１月６日（２００７．１１．６）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２１年５月２８日（２００９．５．２８）
【国際特許分類】
【出願日】平成１９年１１月６日（２００７．１１．６）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]