非信頼アクセスネットワークを介してシングルサインオン認証を行なう装置及び方法
本発明は、アクセスネットワークがデータ発信元認証を提供しないときに、シングルサインオン認証を行なうことを目的とした通信装置、ユーザ機器及び方法を提供する。本発明は、コアネットワーク、すなわち、ユーザが加入しているホームネットワークまたはユーザがローミングしている訪問先のネットワークに対して実行された最初のアクセス認証を再利用することを提案する。従って、コアネットワークに対するユーザの認証が成功した際に取得されたアクセス証明書が、ユーザ機器側で、アクセスネットワークを介してサービスネットワークに対して確立されたセキュアトンネルにリンクされる。サービスネットワークのエンティティにおいて受信されたアクセス証明書も、セキュアトンネルにリンクされる。双方のアクセス証明書が内部ＩＰアドレスにリンクされ、サービスネットワークにおいて、ユーザを安全に識別する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、信用されていないアクセスネットワークを介してサービスネットワークにアクセスする複数のユーザに対するシングルサインオンサービスに関する。特に、本発明は、アクセスネットワークがデータ発信元認証を提供しないときにシングルサインオン認証を行なう通信装置、ユーザ機器及び方法に関する。
【背景技術】
【０００２】
シングルサインオン（以下、ＳＳＯ）は、特定の異なるサービスごとに明示的にユーザを認証することなく、これらの異なるサービスに対するユーザのアクセスを許可する新しい原理である。この原理の基礎は、ユーザがある認証プロバイダ（以下、アイデンティティ・プロバイダ：ＩｄＰ）エンティティにおいて１度認証されれば、その認証結果が他のサービスまたはサービスプロバイダ（ＳＰ）への入口に対しても有効となる。換言すると、ＳＳＯの目的は、毎回、認証及び許可を受けることなく、ユーザが異なるサービスやアプリーションに安全にアクセスできるようにすることである。
【０００３】
基本的には、ＳＳＯをサポートする２つの方法が存在する。すなわち、いわゆる端末中心手法といわゆるネットワーク中心手法である。
【０００４】
端末中心手法の場合、ユーザの端末は、異なるサービスにアクセスするのに必要な異なる複数の認証機構をサポートする。例えば、端末は、ユーザの代わりに異なる複数のパスワードを格納する。この点で、この方法は、ユーザまたは端末側が、異なる複数の認証機構をサポートしていなければならない。さらに、ユーザは、サービスプロバイダ（ＳＰ）の役割を果たす全てのエンティティにユーザ自身を登録する必要がある。そのため、全てのエンティティは、例えば、ユーザ識別及びパスワード、メール配信のためのアドレス、連絡先情報、支払い方法等のユーザに関する必要な情報を有している。
【０００５】
ネットワーク中心手法の場合、ユーザは、そのユーザに対する識別プロバイダ（ＩｄＰ）の役割を果たす１つの中央エンティティに対してのみ認証される。ユーザが所与のサービスにアクセスしたい場合、対応するサービスプロバイダ（ＳＰ）は、新しい認証を必要としない。その代わり、サービスプロバイダ（ＳＰ）は、識別プロバイダ（ＩｄＰ）から１つ以上のサービス証明書が提供される。サービス証明書は、ユーザが認証されていることを示し、かつ、ユーザに関する必要な情報を提供するものである。当然、この機構は、ＳＰとＩｄＰとの間のビジネス関係を必要とする。
【０００６】
特別な例は、例えばモバイルネットワークオペレータ（以下、ＭＮＯ）等、同一のエンティティがアクセス認証を制御するとともに、ＩｄＰの役割を果たす場合である。例えば、ユーザは、汎用パケット無線サービス（ＧＰＲＳ）認証または回線交換認証等の際に、ネットワークにアクセスするため、コアネットワーク（ＣＮ）に対して認証を実行する。ＩｄＰがＣＮからその情報を取得する手段を有する場合、ＩｄＰがＣＮによる認証を信用することできるため、ＩｄＰに対する新しい認証は必要ない。
【０００７】
この特別な例において、ユーザがアクセスする時に経由するアクセスネットワークがデータ発信元認証を提供する場合、識別プロバイダ（ＩｄＰ）は、コアネットワーク（ＣＮ）認証のみを信頼する。例えば、これは、ユーザがＧＰＲＳアクセスネットワークを介してアクセスする場合である。
【０００８】
この説明において、データ発信元認証は、アクセスネットワークから受信した任意のデータに対して、発信元がどこであっても、そのデータの要求発信元が信頼できると考えられることを意味する。
【特許文献１】米国特許第６，２５３，３２７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかし、無線ローカルエリアネットワーク（ＷＬＡＮ）等の他のアクセスネットワークがデータ発信元認証を提供しない。そのため、ネットワークにアクセスした時に実行された最初の認証をＳＳＯ認証の目的のためには再利用できない。換言すると、ＳＳＯのためにアクセス認証は再利用できない。
【００１０】
従来、モバイルの世界において、ＳＳＯの原理は、ユーザがコアネットワーク（ＣＮ）認証を実行すると、シングルサインオン（ＳＳＯ）のサポートによって、さらなる明確な認証を行なうことなく、ユーザが種々のネットワークのサービスにアクセスすることができた。この原理において、ユーザが加入しているホームネットワークは、そのようなユーザに対してＩｄＰの役割を果たす。一般に、ユーザは、ユーザが加入しているユーザのホームコアネットワーク、またはユーザがローミングしている訪問先のコアネットワークにより認証されてもよい。簡単にするために、ユーザを認証したネットワークがホームネットワークかまたは訪問先のネットワークかに関わらず、本明細書ではコアネットワーク認証と呼ぶことにする。この説明において、データ発信元認証が保証されているものとする。すなわち、モバイルネットワークオペレータのコアネットワーク（ＣＮ）が信頼できるネットワークであり、そのため、ＣＮにより割り当てられたＩＰアドレスを有する移動局（あるいは、ユーザ機器またはユーザ端末側）は、その信頼されたＩＰアドレスを介して識別されるからである。よって、移動局からの任意のデータは、信頼できるものと判断される。さらに、ＩＰアドレスがユーザの移動局に割り当てられている間、当該ＩＰアドレスはユーザの擬似識別として使用される。この原理は、移動加入者ディレクトリ番号（以下、ＭＳＩＳＤＮ）等の他のユーザの識別を取得するために、ＳＳＯ方法において使用される。
【００１１】
現在、シングルサインオンに関して、２つの主なビジネスモデルが存在する。第１のモデルは、いわゆるウォールドガーデン（Walled Garden）ＳＳＯである。本明細書ではローカルサービスと呼ばれるＳＳＯを提供する同一のエンティティにより提供されるサービスに対するＳＳＯの使用法をこのように呼ぶことにする。このビジネスモデルをサポートするための公開された仕様書または標準技術は存在しない。
【００１２】
第２のモデルは、いわゆる連携型（Federated）ＳＳＯである。このモデルにおいて、ＳＳＯサービスは識別プロバイダ（ＩｄＰ）により提供される。また、本明細書では外部サービスと呼ばれるサービスが１つ以上のサービスプロバイダ（ＳＰ）により提供されるものとする。シングルサインオン認証業界団体（ＬＡＰ：Liberty Alliance Project）として知られる業界フォーラムは、いわゆる連携型ＳＳＯをサポートするためのプロトコル一式を開発した。ＬＡＰは、特定の認証機構を指定してはいない。ＬＡＰは、認証結果を、識別プロバイダ（ＩｄＰ）からサービスプロバイダ（ＳＰ）に転送することを指定している。そして、ＬＡＰは、サービスプロバイダ（ＳＰ）がエンドユーザにサービスを供給する方法を指定している。しかし、ＬＡＰは、ユーザが非信頼アクセスネットワークを介してアクセスしている時のＩｄＰの動作方法については提案していない。
【００１３】
シングルサインオン（ＳＳＯ）に対して上述のようなウォールドガーデンＳＳＯ及び連携型ＳＳＯを使用する場合において、モバイルネットワークオペレータ（ＭＮＯ）が、コアネットワーク（ＣＮ）の認証プロバイダとＳＳＯの識別プロバイダ（ＩｄＰ）との双方の役割を果たす。アクセスネットワークがデータ発信元認証を提供するという条件の下では、ユーザがアクセス認証を実行すると、新しい認証処理を行なうことなく、多数のサービスへのアクセスが可能となるＳＳＯが利用可能となる。
【００１４】
例えば、アクセスネットワークがＧＰＲＳネットワークであるという条件の下では、ＧＰＲＳ認証が正常に実行されると、識別プロバイダ（ＩｄＰ）の役割を果たすエンティティは、あるＩＰアドレスを有するユーザから受信したサービス証明書の要求がＩＰスプーフィングを実行する攻撃者からのものではなく、確かにそのユーザからのものであるという保証をする。従って、ＩｄＰは、追加の認証を実行せずに、要求されたサービス証明書をユーザに対して提供できる。この好適な例に従って、米国特許第６，２５３，３２７号は、ネットワークにより１度認証されたＩＰアドレスをユーザに割り当て、それにより、ユーザが公衆ネットワークエリアまたは専用ネットワークエリアにアクセスする際のさらなる認証の必要をなくす装置及び方法を開示している。ここで、そのＩＰアドレスは、取り決められたポイント・ツー・ポイントプロトコルセッションを介して認証された証明として使用される。ポイント・ツー・ポイントプロトコルセッションが許可するようなデータ発信元認証をアクセスネットワークが提供するのであれば、これは好ましい解決策である。
【００１５】
しかし、当該技術の現在の状況においては、ユーザを識別するための所与のＩＰアドレスが、モバイルネットワークオペレータ（ＭＮＯ）の制御下になく、ＩＰスプーフィングを実行する攻撃者により使用されている恐れがある。そのため、アクセスネットワークがデータ発信元認証を提供しない場合、シングルサインオン認証に対する安全策が欠けていることになる。この点において、米国特許第６，５７１，２８９号に示されるように、アクセスネットワークから専用ネットワークへの直接アクセスを回避するために、セキュアゲートウェイを介するトンネリング機構を使用してまう場合、アクセスネットワークがデータ発信元認証を提供しない時は有用でないし、また、ＩＰスプーフィングを実行する攻撃者からの命令を排除できない。ちなみに、セキュアゲートウェイは、専用ネットワークにアクセスするユーザを認証し、さらに、専用ネットワークのネットワークエンティティに対するＩＰアドレスを削除し、要求の発信元を、対応する応答の送信先に関連付ける処理を行なうものである。
【００１６】
従って、本発明は、この課題を克服するものであり、ＷＬＡＮ等のデータ発信元認証を提供できないアクセスネットワークを介したアクセスを提供するモバイルネットワークオペレータ（ＭＮＯ）が、ＳＳＯに対して最初のアクセス認証を再利用できるようにすることを目的とする。さらに、本発明は、少なくともネットワーク中心手法の下、この課題を克服することに対処する。
【課題を解決するための手段】
【００１７】
本発明によると、上述の目的は、請求項１の装置、請求項１４のユーザの機器、及び請求項１８の方法によって達成される。これらは、コアネットワークに対して実行された最初のアクセス認証を再利用することにより、データ発信元認証を提供しないアクセスネットワークを介してサービスネットワークにアクセスしているユーザに対して、シングルサインオンサービスを提供するものである。装置、ユーザの機器及び方法は、発明に関する単一の概念を形成する。
【００１８】
本発明に係る装置は、データ発信元認証を提供しないアクセスネットワークを介して、通信サービスネットワークにおけるシングルサインオンサービスの要求をユーザから受信するように構成される。一方で、ユーザは、コアネットワークにより認証された結果、アクセス証明書を受信する。本装置は：
アクセスネットワークにより割り当てられた外部（アウター）ＩＰアドレスを使用することにより、アクセスネットワークを介してユーザとのセキュアトンネルを確立する手段と；
セキュアトンネルが確立している間、ユーザから受信したアクセス証明書の有効性をチェックする手段と；
アクセス証明書の有効性チェックが成功すると、ユーザとの有効セッションを確立する手段と；
セキュアトンネル内で内側（インナー）ＩＰアドレスとして使用される内部（インターナル）ＩＰアドレスを割り当てる手段と；
ユーザに対して、セッションのデータ、アクセス証明書及び割り当てられた内部ＩＰアドレスをリンクさせる（関連付ける）手段とを具備する。
【００１９】
本装置は、特定の許可証明を必要とするあるサービスにアクセスするユーザが使用可能なサービス証明書を生成する手段により構成されることが好ましい。さらに、この手段は、サービスが要求されると、サービス単位で、ユーザに対してサービス証明書を生成するように構成される。
【００２０】
サービスネットワークに提供されたアクセス証明書が署名されるかまたは署名されない可能性があると仮定する。装置には、ホームネットワークの認証サーバと通信する手段が提供されることが好ましい。これは、認識された認証エンティティによりアクセス証明書が署名されないときに、ユーザから受信したアクセス証明書の有効性をチェックするためである。
【００２１】
装置は、異なる構成要素により好適に実現されてもよい。すなわち、本装置において、ユーザとのセキュアトンネルを確立する手段が、セキュアサービスエントリポイントと呼ばれる第１のデバイスに含まれ、ユーザに対して、セッションのデータ、アクセス証明書及び割り当てられた内部ＩＰアドレスをリンクさせる手段が、シングルサインオンサーバと呼ばれる第２のデバイスに含まれる。このような手法の下で、本装置は、第１のデバイスと第２のデバイス、すなわち、セキュアサービスエントリポイントとシングルサインオンサーバとが通信する手段をさらに具備する。
【００２２】
これに対し、ユーザがアクセスするサービスネットワークが、ユーザが加入しているホームネットワークとは異なる可能性があると仮定する。本発明に係る装置は、ホームネットワークのユーザを管理する認証プロバイダとの別の連携手段を具備するのが好ましい。別の連携手段は、セキュアサービスエントリポイントに配置されてもよいが、シングルサインオンサーバに配置されるのが好ましいだろう。
【００２３】
動作中、ユーザがローカルＨＴＴＰサービスまたは現在アクセスしているサービスネットワークとは異なるネットワーク上の外部サービスにアクセスしているときなど、好適な使用例の場合、本装置は、ユーザが既に認証されているか否かをチェックする手段を含む。従って、本装置は、ＨＴＴＰローカルサービスまたは外部ネットワーク上の外部（エクスターナル）サービスへのユーザのアクセスをインターセプト（傍受して阻止）するように構成された仲介エンティティと通信する手段が提供されてもよい。特に、この仲介エンティティは、ＨＴＴＰプロキシでもよく、またはこの目的のために構成される汎用ファイアウォールでもよい。
【００２４】
ユーザが非ＨＴＴＰローカルサービスにアクセスしているときの他の好適な使用例において、本装置は、ユーザが既に認証されているか否かをチェックする手段をさらに含む。しかし、この手法の下では、このチェックする手段がサービスと装置自体との間で共用されるため、ユーザとサービスとの間に仲介エンティティを介在させることは、重要な利点とはならない可能性がある。なお、ＨＴＴＰサービスであるかまたは非ＨＴＴＰサービスであるかは、仲介エンティティを有することの利点または欠点を議論するためではなく、むしろ、本発明に係る装置と互換性を有する他の構成を示しているにすぎない。
【００２５】
本発明に係るユーザ機器は、コアネットワークに対して認証処理を実行するように構成され、データ発信元認証を提供しないアクセスネットワークを介して、サービスネットワークとのセキュアトンネルを確立する手段を含む。セキュアトンネルは、アクセスネットワークにより割り当てられた外部ＩＰアドレスを使用する。ユーザ機器は：
コアネットワークにより認証された結果、アクセス証明書を取得する手段と；
アクセス証明書をセキュアトンネルにリンクさせる手段とを具備する。
【００２６】
ユーザ機器は、トンネルトラフィック内で内側ＩＰアドレスとして受信した内部ＩＰアドレスをアクセス証明書及びセキュアトンネルにリンクさせる手段を含む。このように、特定のサービスへのさらなるアクセスする際に、特定のサービスに直接アクセスするための擬似識別として、既に割り当てられているＩＰアドレスをユーザ機器が使用してもよい。
【００２７】
アクセス証明書を取得するために異なる機構が使用されてもよいが、ユーザ機器を提供することにより、さらなるセキュリティ上の利点が得られると考えられる。アクセス証明書を取得する手段は：
コアネットワークから認証チャレンジを受信する手段と；
認証応答を生成しかつコアネットワークに返信する手段と；
１組の公開鍵及び秘密鍵を生成する手段と；
秘密鍵の所有権を証明するデジタル署名とともに公開鍵をコアネットワークに対して送信する手段とを含む。
【００２８】
あるいは、簡易化されたユーザ機器及びコアネットワークにおいて、ユーザ機器でアクセス証明書を取得する手段は：
コアネットワークから認証チャレンジを受信する手段と；
認証応答を生成しかつコアネットワークに返信する手段と；
コアネットワークから取得可能なデジタル証明書を要求する手段とを含む。
【００２９】
本発明によると、通信サービスネットワークおいて、コアネットワークにより認証されかつデータ発信元認証を提供できないアクセスネットワークを介してサービスネットワークにアクセスするユーザに対して、シングルサインオンサービスをサポートする方法がさらに提供される。本方法は：
コアネットワークにより認証された結果、アクセス証明書をユーザ機器側に提供するステップと；
アクセスネットワークにより割り当てられた外部ＩＰアドレスを使用することにより、アクセスネットワークを介して、サービスネットワークのエンティティとユーザ機器側との間にセキュアトンネルを確立するステップと；
ユーザ機器側で、アクセス証明書をセキュアトンネルにリンクするステップと；
セキュアトンネルが確立している間、サービスネットワークにおいてユーザ機器側から受信したアクセス証明書の有効性をチェックするステップと；
アクセス証明書の有効性チェックが成功した際に、ユーザとの有効セッションを確立するステップと；
サービスネットワークにおいて、トンネルトラフィック内で内側ＩＰアドレスとして使用されるユーザに対する内部ＩＰアドレスを割り当てるステップと；
サービスネットワークのエンティティにおいて、ユーザに対して、セッションのデータ、アクセス証明書及び割り当てられた内部ＩＰアドレスをリンクするステップとを含む。
【００３０】
ユーザの機器における好適な対応する機能に従って、本方法は、トンネルトラフィック内で内側ＩＰアドレスとして受信した内部ＩＰアドレスを、アクセス証明書及びユーザ機器側のセキュアトンネルにリンクするステップをさらに含む。
【００３１】
上述の装置における好適な対応する機能に従って、本方法は、ユーザに対してサービス証明書を生成するステップをさらに含む。このステップは、サービスが要求されると、サービス単位で、ユーザに対してサービス証明書を生成するステップをさらに含んでもよい。
【００３２】
サービスネットワークにおいてユーザから受信したアクセス証明書の有効性をチェックするステップは、認識された認証エンティティによりアクセス証明書が署名されていない場合にホームネットワークの認証サーバと通信するステップをさらに含むことが好ましい。
【００３３】
これに対し、本発明に従って装置に付与される特定の構成によれば、本方法は、セキュアトンネルを管理するセキュアサービスエントリポイントと呼ばれる第１のデバイスが、ユーザに対してセッションのデータ、アクセス証明書及び割り当てられた内部ＩＰアドレスをリンクするステップが実行されるシングルサインオンサーバ（Ｎ ４２）と呼ばれる第２のデバイスと通信するステップをさらに含んでもよい。
【００３４】
例示的な使用方法によれば、ユーザがローカルサービスまたは現在アクセスしているサービスネットワークとは異なるネットワーク上にある外部サービスにアクセスしている場合、本方法は、ユーザが既に認証されているか否かをチェックする手段をさらに含む。
【発明を実施するための最良の形態】
【００３５】
本発明の特徴、目的及び利点については、添付の図面を参照しながら本明細書を読むことによりさらに明瞭に理解できるであろう。
【００３６】
以下において、無線ローカルエリアネットワーク（ＷＬＡＮ）を介してアクセスする場合などのように、データ発信元認証を提供しないアクセスネットワークを介してユーザがアクセスする場合にも、ユーザがシングルサインオン（ＳＳＯ）サービスを享受できるようにする装置、ユーザ機器及び方法の現時点で好適な実施形態を説明する。
【００３７】
本発明は、ユーザ機器、訪問先のサービスネットワーク、及びデータ発信元認証を提供しないアクセスネットワークを介したユーザ端末と訪問先のサービスネットワークとの間のセキュアトンネルを確立するための手法について、いくつかの手法を提案する。なお、、訪問先のサービスネットワークは、ホームサービスネットワークであってもよい。
【００３８】
本発明の第１の手法によると、コアネットワーク認証の処理中にユーザ端末側（Ｎ １０）がコアネットワーク（Ｎ ３０）から認証またはアクセス証明書を取得し、かつ、ユーザ端末側（Ｎ １０）が、サービスネットワーク（Ｎ ４０）に対する特定のセキュアトンネル（Ｓ−２４）に認証またはアクセス証明書をリンクする新しい機構を具備する。ここで、サービスネットワークは、ホームサービスネットワークや訪問先のサービスネットワークであってもよい。明瞭かつ簡潔に説明するために、以下において、認証証明書またはアクセス証明書を「アクセス証明書」と呼ぶことにする。
【００３９】
従って、図２及び図３に示されるように、認証自体は、拡張認証プロトコルフレームワーク（以下、ＥＡＰと称す。ＩＥＴＦ ＲＦＣ ２２８４に準拠する。）を使用してユーザ端末（Ｎ １０）とコアネットワーク（Ｎ ３０）に位置する認証サーバ（Ｎ ３１）との間で相互に実行される。しかしながら、アクセス認証は、アクセスネットワーク（Ｎ ２０）における汎用アクセスサーバ（以下、ＧＡＳ）（Ｎ ２２）により実行される。拡張認証プロトコルは、認証フレームワークを提供する。認証フレームワークは、複数の認証機構をサポートする。現在に至るまで、ＥＡＰは、ポイント・ツー・ポイントプロトコル（ＰＰＰ）を使用して、回線交換網またはダイヤルアップ回線を介して相互に接続するホスト及びルータにより実現されてきた。さらに、ＥＡＰは、例えばＥＡＰメッセージがカプセル化される８０２．１Ｘ ２００１等のＩＥＥＥ８０２規格に準拠するスイッチによっても実現されてきた。
【００４０】
ＥＡＰアーキテクチャの１つの利点は、その柔軟性にある。例えば、図１に示すようなネットワークアクセスサーバ（Ｎ ２１）（一般にＮＡＳとして知られる）は、非ローカルのユーザに対してだけでなく、ＮＡＳにおいてローカルに実現されていない認証方法についてのパススルーエンティティとして動作しつつ、同時に、ローカルのユーザを認証してもよい。ここで、ネットワークアクセスサーバ（Ｎ ２１）は、ＰＰＰまたはＩＥＥＥ８０２を使用するＥＡＰを介して、ネットワークへのアクセス権が付与される前に認証を必要とするユーザ（Ｎ １１）に接続される。
【００４１】
図２に示される現時点で好適な実施形態において、ユーザ（Ｎ １０）は、ネットワークへのアクセスを試みる。ＰＰＰまたはＩＥＥＥ８０２に基づく接続（コネクション）（Ｓ ２１）は、クライアントとアクセスネットワーク（Ｎ ２０）のＧＡＳ（Ｎ ２２）との間に確立される。ＧＡＳは、「認証、許可及び課金」（以下、ＡＡＡ）を行なうのに適切なプロトコル（Ｓ ２２）を使用して、コアネットワーク（Ｎ ３０）の認証サーバ（Ｎ ３１）と通信することにより認証実行し、また、ＥＡＰメッセージに対するパススルーとして動作する。
【００４２】
従来の適切なＡＡＡプロトコル（Ｓ １２；Ｓ ２２）は、リモート認証ダイヤルインユーザサービス（以下、ＲＡＤＩＵＳ。ＩＥＴＦ ＲＦＣ ２８６５に準拠。）プロトコルでもよい。ＲＡＤＩＵＳプロトコルは、図１に示すように、ネットワークアクセスサーバ（ＮＡＳ）（Ｎ ２１；Ｎ ２２）と認証サーバ（Ｎ ３１）との間で認証、許可及び構成情報を伝送するために、クライアント／サーバモデルを使用する。通常、通信ネットワークに対する接続性を保証するプロバイダは、ユーザの識別情報を確認するためにＲＡＤＩＵＳを使用する。従って、ユーザが周知の電話番号にダイヤルすることで、両側のモデム、すなわちユーザ及び接続性プロバイダが接続を確立する。サーバ側のモデムは、ネットワークアクセスサーバ（ＮＡＳ）に接続される。ＮＡＳは、ログイン名及びパスワードを要求する（Ｓ １１）ことにより、ネットワークへのアクセス権を付与する前にユーザの認証を要求する。ネットワークアクセスサーバ（ＮＡＳ）（Ｎ ２１；Ｎ ２２）は、ネットワークを介してＲＡＤＩＵＳサーバ（Ｎ ３１）と通信し、ユーザを認証するために、ＲＡＤＩＵＳプロトコルを使用する。ＲＡＤＩＵＳサーバ（Ｎ ３１）は、ログイン名及びパスワードなど、ＮＡＳから転送されたユーザに関する情報を収集する。認証処理は、ＲＡＤＩＵＳサーバがＮＡＳに多数のチャレンジを送信することを要求してもよいし、要求しなくてもよい。ユーザは、ＮＡＳに対して応答できる必要がある。認証処理の結果、ＲＡＤＵＩＳサーバ（Ｎ ３１）は、ユーザ（Ｎ １０；Ｎ １１）がネットワークへのアクセスを許可されたか否かをＮＡＳ（Ｎ ２１；Ｎ ２２）に対して示す。使用するのに適切な別のＡＡＡプロトコルは、ＲＡＤＩＵＳの進化型であるＤＩＡＭＥＴＥＲでもよい。
【００４３】
図２に示されるように、ＥＡＰ認証は、アクセスネットワーク（Ｎ ２０）の汎用アクセスサーバ（Ｎ ２２）を介して、ユーザ（Ｎ １０）と認証サーバ（Ｎ ３１）との間で相互に実行される（Ｓ ２３）。例えば、汎用アクセスサーバ（Ｎ ２２）は、図１のネットワークアクセスサーバ（Ｎ ２１）でもよい。
【００４４】
図２に示されるこのＥＡＰ認証の処理中、１つ以上のアクセス証明書が、ユーザ（Ｎ １０）とホームネットワーク（Ｎ ３０）との間、またはさらに一般的には、ユーザとコアネットワークとの間で、配布されるかまたは同意される。この時、ユーザを認証するコアネットワークがホームネットワークであるかまたは訪問先のネットワークであるかは関係ない。
【００４５】
これらのアクセス証明書は、ユーザ（Ｎ １０）とホームネットワークまたは訪問先のネットワークであるサービスネットワーク（Ｎ ４０）との間にセキュアトンネル（Ｓ ２４）を設定するためにも使用される。本発明に係る第１の面が目的としているように、このセキュアトンネル（Ｓ ２４）、すなわち、セキュア通信チャネルは、少なくともデータ発信元認証またはそれと同等の機能を提供する必要がある。
【００４６】
アクセス証明書の配布処理や同意処理についての機構は、セキュアトンネルにリンクまたは関連付けるために適正に使用されるため、本発明の目的を達成する上でも適切な機構といえるだろう。
【００４７】
しかしながら、現時点で好適な実施形態によれば、図３が示すように、本発明の目的を達成する上で適切な、一時的な証明書を取得するための新しい機構が提供される。
【００４８】
このシーケンス図において、認証チャレンジがユーザ端末側（Ｎ １０）で受信されると、認証応答を生成することに加え、１組の公開鍵及び秘密鍵が生成される。秘密鍵の所有権を証明するデジタル署名に加え、公開鍵が、認証応答とともにコアネットワークの認証サーバ（Ｎ ３１）へ送信される。
【００４９】
ユーザの認証が成功すると、受信したデジタル署名がチェックされる。デジタル署名が適正なものである場合、一時的なデジタル証明書がユーザの公開鍵に対して生成される。この証明書は、認証の成功を示すメッセージとともに、認証サーバ（Ｎ ３１）からユーザの端末側（Ｎ １０）に返信される。
【００５０】
図示しないが、ユーザの端末側（Ｎ １０）は、１組の公開鍵及び秘密鍵を生成する代わりに、認証チャレンジの応答とともに送信されるべきデジタル証明書の要求を生成してもよい。
【００５１】
本発明の第１の面によれば、好適な本実施形態の利点またはその他の利点により一時的なデジタル証明書が取得されるが、これは、ユーザの端末側でセキュアトンネルとリンクされるアクセス証明書の一種である。
【００５２】
しかし、本発明の目的に対して有効なコアネットワークからアクセス証明書を取得するために、他の機構が使用されてもよい。図２の好適な実施形態に示される１つの例によれば、上述した一時的な証明書のようなアクセス証明書が認証サーバ（Ｎ ３１）からユーザ端末（Ｎ １０）に配布されるが、アクセス証明書は別の証明書プロバイダ（Ｎ ３２）から取得されてもよい。別の例においては、認証サーバ（Ｎ ３１）自体がそのようなアクセス証明書を生成する。認証サーバ（Ｎ ３１）または証明書プロバイダ（Ｎ ３２）が、アクセス証明書に電子署名してもよい。他の実施形態においては、いくつかの暗号データが認証サーバ（Ｎ ３１）及びユーザ機器（Ｎ １０）において取得され、その後、それらの暗号データがアクセス証明書として使用されてもよい。最後の例の場合、アクセス証明書を認証サーバからユーザに対して配布する必要はないため、その結果、アクセス証明書は、コアネットワーク（Ｎ ３０）により署名されることはないだろう。
【００５３】
図２に戻ると、アクセス認証を実行している間にコアネットワーク（Ｎ ３０）から取得されたアクセス証明書は、ユーザ（Ｎ １０）とホームサービスネットワークまたは訪問先のサービスネットワーク（Ｎ ４０）のエンティティ（Ｎ ４１）との間にセキュアトンネル（Ｓ ２４）を設定するために使用される。本明細書においては、エンティティ（Ｎ ４１）をセキュアサービスエントリポイント（以下、ＳＳＥＰ）と呼ぶ。アクセス証明書がコアネットワークにより署名されない場合、ＳＳＥＰ（Ｎ ４１）と認証サーバ（Ｎ ３１）との間に通信チャネル（Ｓ ２５）が必要とされる。それにより、ユーザ（Ｎ １０）により提供されたアクセス証明書を受入れ可能であるかを、ＳＳＥＰが認証サーバに確認できることが好ましい。これに対し、アクセス証明書が署名される場合、ＳＳＥＰ（Ｎ ４１）は、認証サーバ（Ｎ ３１）または証明書プロバイダ（Ｎ ３２）により署名された有効なアクセス証明書として、それらアクセス証明書を受け入れるように構成されるのが好ましい。いずれの場合においても、ユーザ端末（Ｎ １０）とＳＳＥＰ（Ｎ ４１）との間のセキュア通信チャネル（Ｓ ２４）は、少なくともデータ発信元認証を提供する必要がある。このように、このセキュア通信チャネルを介して受信された全てのトラフィックは、要求したユーザからのものであり、ユーザのふりをした攻撃者からのものではないとみなすことができる。
【００５４】
本発明に係る第２の面によれば、ユーザに関連するセッション情報を保持し、そのセッション情報をセキュアトンネルの確立及び切断にリンクさせる新しい機構が、ホームサービスネットワークまたは訪問先のサービスネットワークのエンティティにおいて提供される。現時点で好適な実施形態において、このエンティティは、上述したセキュアサービスエントリポイント（ＳＳＥＰ）と協働するシングルサインオン（ＳＳＯ）サーバ（Ｎ ４２）であることが好ましいが、いずれか一方であってもよい。このように、ユーザ端末（Ｎ １０）がセキュア通信チャネル（Ｓ ２４）を介してサービスにアクセスしようとする（Ｓ ２４）場合、ユーザにシングルサインオンをサポートするために、ユーザ端末（Ｎ １０）から、サービス自体から、またはこの目的のためにサービスと協働するエンティティから、ＳＳＯサーバ（Ｎ ４２）にサービス証明書が要求される。ＳＳＯサーバ（Ｎ ４２）は、ユーザ端末（Ｎ １０）に対するサービス証明書の要求が確かにサービスにアクセスするためのユーザの試みからのものであり、ユーザのふりをした攻撃者からのものではないという保証を有する。従って、ＳＳＯサーバ（Ｎ ４２）は、追加の認証を実行することなく、要求されたサービス証明書を要求者に提供できる。
【００５５】
図２をさらに参照すると、トンネルトラフィックにおいて使用されるように、ＩＰアドレスをユーザに割り当てるために、ＳＳＥＰは、ＳＳＯサーバ（Ｎ ４２）と情報を交換する（Ｓ ２６）。このＩＰアドレスは、サービスネットワークにより処理されるＩＰアドレスのプールに含まれていてもよい。その後、ＳＳＥＰ（Ｎ ４１）は、ユーザ（Ｎ １０）がセッションを確立したことを、ＳＳＯサーバ（Ｎ ４２）に知らせる。
【００５６】
これが達成されると、すなわち、ユーザに割り当てられたＩＰアドレスがユーザアクセス証明書及び対応するセッション情報にリンクされると、ＳＳＯサーバ（Ｎ ４２）は、内部ＩＰアドレスとともに受信したサービス証明書に対する要求が確かに対応するユーザからのものであるということを保証できる。
【００５７】
図示しないが、ユーザが訪問先のサービスネットワークとのセキュア通信チャネルを確立した場合、ＳＳＯサーバは、ユーザを管理する識別プロバイダ（ＩｄＰ）、すなわち、ＩｄＰの役割を果たすホームサービスネットワークのエンティティとのさらなる連携動作を必要とする。簡単にするため、以下の説明においては、ＩｄＰの役割を果たすホームサービスネットワークにユーザ端末が接続されていると仮定する。
【００５８】
この段階で、ユーザは、データ発信元認証を提供できないアクセスネットワークを介してアクセスしている場合においても、ユーザの都合のいい時にシングルサインオン（ＳＳＯ）サービスを楽しむことができる。特に、ユーザ端末（Ｎ １０）は、以下に説明する現時点で好適な各実施形態に従って、上述した任意のビジネスモデルの下で、すなわちウォールドガーデンモデルまたは連携型シングルサインオンモデルの下で動作してもよい。
【００５９】
第１の実施形態において、図４に示されるウォールドガーデンの場合、ユーザがＨＴＴＰローカルサービス（Ｎ ４４）にアクセスする時、中間ノード（Ｎ ４３）は、ＨＴＴＰローカルサービスへのアクセスを傍受して阻止する（Ｓ ３０，Ｓ ２９）。この中間ノード（Ｎ ４３）は、ユーザが既に認証されているか否かをＳＳＯサーバ（Ｎ ４２）に問い合わせる（Ｓ ２８）。中間ノード（Ｎ ４３）は、汎用ファイアウォールがこの目的のために構成されてもよいが、ＨＴＴＰプロキシであることが好ましいだろう。この場合にユーザを識別するための擬似識別は、データ発信元認証を保証可能な事前に割り当てられたＩＰアドレスである。そのような問合せを受信するＳＳＯサーバ（Ｎ ４２）は、ＩＰアドレスのタグが付けられた使用可能なセッションが存在することをチェックし、確認応答またはサービス証明書を、中間ノードであるＨＴＴＰプロキシ（Ｎ ４３）に送信する。サービス証明書は、ＨＴＴＰローカルサービス（Ｎ ４４）に対するユーザ端末（Ｎ １０）のアクセスを許可し、任意で、ユーザ端末のブラウザにクッキーを割り当てる。クッキーが提供された場合、ＨＴＴＰサービスに対して次の要求があった時、ＳＳＯサーバ（Ｎ ４２）に確認することなく、ユーザ端末（Ｎ １０）を認識するために、このクッキーが使用されうる。
【００６０】
第２の実施形態において、図５に示されるウォールドガーデンの場合、ユーザが非ＨＴＴＰサービス（Ｎ ４５）にアクセスする時、または、一般的には、ユーザが上述のＨＴＴＰプロキシを必要としないローカルサービス（Ｎ ４５）にアクセスする時、ローカルサービス（Ｎ ４５）は、恐らくＳＳＥＰ（Ｎ ４１）を介して、ユーザ端末側（Ｎ １０）から直接アクセスされてもよい（Ｓ ２４，Ｓ ３１）。要求されたローカルサービス（Ｎ ４５）は、事前に割り当てられたＩＰアドレスを擬似識別情報として使用し、ユーザが既に認証されているかをＳＳＯサーバ（Ｎ ４２）に直接問い合わせる（Ｓ ３２）。そのような問合せを受信するＳＳＯサーバ（Ｎ ４２）は、ＩＰアドレスによりタグ付けされた使用可能なセッションが存在することをチェックし、ユーザ（Ｎ １０）のアクセスを許可するために、確認応答またはサービス証明書をローカルサービス（Ｎ ４５）に送信する。
【００６１】
第３の実施形態において、図６に示される連携型ＳＳＯの場合、ユーザ（Ｎ １０）は、外部サービス（Ｎ ５１）へのアクセスを試み、ＬＡＰプロトコルに従って、ユーザのブラウザ（Ｎ １０）は、サードパーティＳＰ（Ｎ ５１）、すなわち外部サービスにリダイレクトされる（Ｓ ３０，Ｓ ３３）。サードパーティＳＰ（Ｎ ５１）は、ユーザがアクセス証明書を提供した時に事前に割り当てられたＩＰアドレスを使用して、ＳＳＯサーバ（Ｎ ４２）にサービスの許可を要求する（Ｓ ３３、Ｓ ２８）。ＳＳＯサーバ（Ｎ ４２）は、ＳＳＯ条件の下、当該ＩＰアドレスを擬似識別情報として割り当てられているユーザについて、認証及び許可状態をチェックし、その後、要求したサードパーティＳＰにサインオンするために使用できるサービス証明書を返信する。ＳＳＯサーバは、上述した第１の実施形態と同様に、クッキーを割り当ててもよい。
【００６２】
最後に、ユーザ端末がセキュアトンネルを切断する場合、ＳＳＥＰは、内部ＩＰアドレスの割り当てを解除しかつＳＳＯサーバのユーザ関連セッション情報を削除するために、ＳＳＯサーバと通信する。
【００６３】
例示的かつ非限定的な手法で、いくつかの実施形態に関連して本発明を説明してきた。上述した説明に鑑みて、これらの実施形態の変形したり変更したりすることは可能であり、これらは特許請求の範囲に含まれることが意図されている。
【図面の簡単な説明】
【００６４】
【図１】図１は、拡張認証プロトコルに基づくアクセス制御に対する周知のアーキテクチャの基本的な概略を示す図である。
【図２】図２は、ユーザがユーザのホームネットワークにより認証され、データ発信元認証を提供しないアクセスネットワークを介して、アクセス認証を再利用するサービスネットワークにさらにアクセスしている時に関わるエンティティ及びインタフェースに焦点を当て、アーキテクチャ及びインタフェースの一例の概略を示す図である。
【図３】図３は、ユーザがユーザのホームコアネットワークにより認証された結果、アクセス証明書を取得する現時点で好適な実施形態を説明するシーケンス図である。
【図４】図４は、ユーザがローカルＨＴＴＰサービスにアクセスする時の好適な動作に焦点を当て、図２に示されるアーキテクチャ及びインタフェースの第１の概略を示す図である。
【図５】図５は、ユーザがローカル非ＨＴＴＰサービスにアクセスするか、あるいは、ＨＴＴＰプロキシまたはファイアウォール等の任意の仲介エンティティの援助なしでローカルＨＴＴＰサービスにアクセスしている時の好適な動作に焦点を当て、図２に示されるアーキテクチャ及びインタフェースの第２の概略を示す図である。
【図６】図６は、ユーザが現在アクセスしているサービスネットワークとは異なるネットワーク上の外部サービスにアクセスしている時の好適な動作に焦点を当て、図２に示されるアーキテクチャ及びインタフェースの第３の概略を示す図である。
【技術分野】
【０００１】
本発明は、一般に、信用されていないアクセスネットワークを介してサービスネットワークにアクセスする複数のユーザに対するシングルサインオンサービスに関する。特に、本発明は、アクセスネットワークがデータ発信元認証を提供しないときにシングルサインオン認証を行なう通信装置、ユーザ機器及び方法に関する。
【背景技術】
【０００２】
シングルサインオン（以下、ＳＳＯ）は、特定の異なるサービスごとに明示的にユーザを認証することなく、これらの異なるサービスに対するユーザのアクセスを許可する新しい原理である。この原理の基礎は、ユーザがある認証プロバイダ（以下、アイデンティティ・プロバイダ：ＩｄＰ）エンティティにおいて１度認証されれば、その認証結果が他のサービスまたはサービスプロバイダ（ＳＰ）への入口に対しても有効となる。換言すると、ＳＳＯの目的は、毎回、認証及び許可を受けることなく、ユーザが異なるサービスやアプリーションに安全にアクセスできるようにすることである。
【０００３】
基本的には、ＳＳＯをサポートする２つの方法が存在する。すなわち、いわゆる端末中心手法といわゆるネットワーク中心手法である。
【０００４】
端末中心手法の場合、ユーザの端末は、異なるサービスにアクセスするのに必要な異なる複数の認証機構をサポートする。例えば、端末は、ユーザの代わりに異なる複数のパスワードを格納する。この点で、この方法は、ユーザまたは端末側が、異なる複数の認証機構をサポートしていなければならない。さらに、ユーザは、サービスプロバイダ（ＳＰ）の役割を果たす全てのエンティティにユーザ自身を登録する必要がある。そのため、全てのエンティティは、例えば、ユーザ識別及びパスワード、メール配信のためのアドレス、連絡先情報、支払い方法等のユーザに関する必要な情報を有している。
【０００５】
ネットワーク中心手法の場合、ユーザは、そのユーザに対する識別プロバイダ（ＩｄＰ）の役割を果たす１つの中央エンティティに対してのみ認証される。ユーザが所与のサービスにアクセスしたい場合、対応するサービスプロバイダ（ＳＰ）は、新しい認証を必要としない。その代わり、サービスプロバイダ（ＳＰ）は、識別プロバイダ（ＩｄＰ）から１つ以上のサービス証明書が提供される。サービス証明書は、ユーザが認証されていることを示し、かつ、ユーザに関する必要な情報を提供するものである。当然、この機構は、ＳＰとＩｄＰとの間のビジネス関係を必要とする。
【０００６】
特別な例は、例えばモバイルネットワークオペレータ（以下、ＭＮＯ）等、同一のエンティティがアクセス認証を制御するとともに、ＩｄＰの役割を果たす場合である。例えば、ユーザは、汎用パケット無線サービス（ＧＰＲＳ）認証または回線交換認証等の際に、ネットワークにアクセスするため、コアネットワーク（ＣＮ）に対して認証を実行する。ＩｄＰがＣＮからその情報を取得する手段を有する場合、ＩｄＰがＣＮによる認証を信用することできるため、ＩｄＰに対する新しい認証は必要ない。
【０００７】
この特別な例において、ユーザがアクセスする時に経由するアクセスネットワークがデータ発信元認証を提供する場合、識別プロバイダ（ＩｄＰ）は、コアネットワーク（ＣＮ）認証のみを信頼する。例えば、これは、ユーザがＧＰＲＳアクセスネットワークを介してアクセスする場合である。
【０００８】
この説明において、データ発信元認証は、アクセスネットワークから受信した任意のデータに対して、発信元がどこであっても、そのデータの要求発信元が信頼できると考えられることを意味する。
【特許文献１】米国特許第６，２５３，３２７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかし、無線ローカルエリアネットワーク（ＷＬＡＮ）等の他のアクセスネットワークがデータ発信元認証を提供しない。そのため、ネットワークにアクセスした時に実行された最初の認証をＳＳＯ認証の目的のためには再利用できない。換言すると、ＳＳＯのためにアクセス認証は再利用できない。
【００１０】
従来、モバイルの世界において、ＳＳＯの原理は、ユーザがコアネットワーク（ＣＮ）認証を実行すると、シングルサインオン（ＳＳＯ）のサポートによって、さらなる明確な認証を行なうことなく、ユーザが種々のネットワークのサービスにアクセスすることができた。この原理において、ユーザが加入しているホームネットワークは、そのようなユーザに対してＩｄＰの役割を果たす。一般に、ユーザは、ユーザが加入しているユーザのホームコアネットワーク、またはユーザがローミングしている訪問先のコアネットワークにより認証されてもよい。簡単にするために、ユーザを認証したネットワークがホームネットワークかまたは訪問先のネットワークかに関わらず、本明細書ではコアネットワーク認証と呼ぶことにする。この説明において、データ発信元認証が保証されているものとする。すなわち、モバイルネットワークオペレータのコアネットワーク（ＣＮ）が信頼できるネットワークであり、そのため、ＣＮにより割り当てられたＩＰアドレスを有する移動局（あるいは、ユーザ機器またはユーザ端末側）は、その信頼されたＩＰアドレスを介して識別されるからである。よって、移動局からの任意のデータは、信頼できるものと判断される。さらに、ＩＰアドレスがユーザの移動局に割り当てられている間、当該ＩＰアドレスはユーザの擬似識別として使用される。この原理は、移動加入者ディレクトリ番号（以下、ＭＳＩＳＤＮ）等の他のユーザの識別を取得するために、ＳＳＯ方法において使用される。
【００１１】
現在、シングルサインオンに関して、２つの主なビジネスモデルが存在する。第１のモデルは、いわゆるウォールドガーデン（Walled Garden）ＳＳＯである。本明細書ではローカルサービスと呼ばれるＳＳＯを提供する同一のエンティティにより提供されるサービスに対するＳＳＯの使用法をこのように呼ぶことにする。このビジネスモデルをサポートするための公開された仕様書または標準技術は存在しない。
【００１２】
第２のモデルは、いわゆる連携型（Federated）ＳＳＯである。このモデルにおいて、ＳＳＯサービスは識別プロバイダ（ＩｄＰ）により提供される。また、本明細書では外部サービスと呼ばれるサービスが１つ以上のサービスプロバイダ（ＳＰ）により提供されるものとする。シングルサインオン認証業界団体（ＬＡＰ：Liberty Alliance Project）として知られる業界フォーラムは、いわゆる連携型ＳＳＯをサポートするためのプロトコル一式を開発した。ＬＡＰは、特定の認証機構を指定してはいない。ＬＡＰは、認証結果を、識別プロバイダ（ＩｄＰ）からサービスプロバイダ（ＳＰ）に転送することを指定している。そして、ＬＡＰは、サービスプロバイダ（ＳＰ）がエンドユーザにサービスを供給する方法を指定している。しかし、ＬＡＰは、ユーザが非信頼アクセスネットワークを介してアクセスしている時のＩｄＰの動作方法については提案していない。
【００１３】
シングルサインオン（ＳＳＯ）に対して上述のようなウォールドガーデンＳＳＯ及び連携型ＳＳＯを使用する場合において、モバイルネットワークオペレータ（ＭＮＯ）が、コアネットワーク（ＣＮ）の認証プロバイダとＳＳＯの識別プロバイダ（ＩｄＰ）との双方の役割を果たす。アクセスネットワークがデータ発信元認証を提供するという条件の下では、ユーザがアクセス認証を実行すると、新しい認証処理を行なうことなく、多数のサービスへのアクセスが可能となるＳＳＯが利用可能となる。
【００１４】
例えば、アクセスネットワークがＧＰＲＳネットワークであるという条件の下では、ＧＰＲＳ認証が正常に実行されると、識別プロバイダ（ＩｄＰ）の役割を果たすエンティティは、あるＩＰアドレスを有するユーザから受信したサービス証明書の要求がＩＰスプーフィングを実行する攻撃者からのものではなく、確かにそのユーザからのものであるという保証をする。従って、ＩｄＰは、追加の認証を実行せずに、要求されたサービス証明書をユーザに対して提供できる。この好適な例に従って、米国特許第６，２５３，３２７号は、ネットワークにより１度認証されたＩＰアドレスをユーザに割り当て、それにより、ユーザが公衆ネットワークエリアまたは専用ネットワークエリアにアクセスする際のさらなる認証の必要をなくす装置及び方法を開示している。ここで、そのＩＰアドレスは、取り決められたポイント・ツー・ポイントプロトコルセッションを介して認証された証明として使用される。ポイント・ツー・ポイントプロトコルセッションが許可するようなデータ発信元認証をアクセスネットワークが提供するのであれば、これは好ましい解決策である。
【００１５】
しかし、当該技術の現在の状況においては、ユーザを識別するための所与のＩＰアドレスが、モバイルネットワークオペレータ（ＭＮＯ）の制御下になく、ＩＰスプーフィングを実行する攻撃者により使用されている恐れがある。そのため、アクセスネットワークがデータ発信元認証を提供しない場合、シングルサインオン認証に対する安全策が欠けていることになる。この点において、米国特許第６，５７１，２８９号に示されるように、アクセスネットワークから専用ネットワークへの直接アクセスを回避するために、セキュアゲートウェイを介するトンネリング機構を使用してまう場合、アクセスネットワークがデータ発信元認証を提供しない時は有用でないし、また、ＩＰスプーフィングを実行する攻撃者からの命令を排除できない。ちなみに、セキュアゲートウェイは、専用ネットワークにアクセスするユーザを認証し、さらに、専用ネットワークのネットワークエンティティに対するＩＰアドレスを削除し、要求の発信元を、対応する応答の送信先に関連付ける処理を行なうものである。
【００１６】
従って、本発明は、この課題を克服するものであり、ＷＬＡＮ等のデータ発信元認証を提供できないアクセスネットワークを介したアクセスを提供するモバイルネットワークオペレータ（ＭＮＯ）が、ＳＳＯに対して最初のアクセス認証を再利用できるようにすることを目的とする。さらに、本発明は、少なくともネットワーク中心手法の下、この課題を克服することに対処する。
【課題を解決するための手段】
【００１７】
本発明によると、上述の目的は、請求項１の装置、請求項１４のユーザの機器、及び請求項１８の方法によって達成される。これらは、コアネットワークに対して実行された最初のアクセス認証を再利用することにより、データ発信元認証を提供しないアクセスネットワークを介してサービスネットワークにアクセスしているユーザに対して、シングルサインオンサービスを提供するものである。装置、ユーザの機器及び方法は、発明に関する単一の概念を形成する。
【００１８】
本発明に係る装置は、データ発信元認証を提供しないアクセスネットワークを介して、通信サービスネットワークにおけるシングルサインオンサービスの要求をユーザから受信するように構成される。一方で、ユーザは、コアネットワークにより認証された結果、アクセス証明書を受信する。本装置は：
アクセスネットワークにより割り当てられた外部（アウター）ＩＰアドレスを使用することにより、アクセスネットワークを介してユーザとのセキュアトンネルを確立する手段と；
セキュアトンネルが確立している間、ユーザから受信したアクセス証明書の有効性をチェックする手段と；
アクセス証明書の有効性チェックが成功すると、ユーザとの有効セッションを確立する手段と；
セキュアトンネル内で内側（インナー）ＩＰアドレスとして使用される内部（インターナル）ＩＰアドレスを割り当てる手段と；
ユーザに対して、セッションのデータ、アクセス証明書及び割り当てられた内部ＩＰアドレスをリンクさせる（関連付ける）手段とを具備する。
【００１９】
本装置は、特定の許可証明を必要とするあるサービスにアクセスするユーザが使用可能なサービス証明書を生成する手段により構成されることが好ましい。さらに、この手段は、サービスが要求されると、サービス単位で、ユーザに対してサービス証明書を生成するように構成される。
【００２０】
サービスネットワークに提供されたアクセス証明書が署名されるかまたは署名されない可能性があると仮定する。装置には、ホームネットワークの認証サーバと通信する手段が提供されることが好ましい。これは、認識された認証エンティティによりアクセス証明書が署名されないときに、ユーザから受信したアクセス証明書の有効性をチェックするためである。
【００２１】
装置は、異なる構成要素により好適に実現されてもよい。すなわち、本装置において、ユーザとのセキュアトンネルを確立する手段が、セキュアサービスエントリポイントと呼ばれる第１のデバイスに含まれ、ユーザに対して、セッションのデータ、アクセス証明書及び割り当てられた内部ＩＰアドレスをリンクさせる手段が、シングルサインオンサーバと呼ばれる第２のデバイスに含まれる。このような手法の下で、本装置は、第１のデバイスと第２のデバイス、すなわち、セキュアサービスエントリポイントとシングルサインオンサーバとが通信する手段をさらに具備する。
【００２２】
これに対し、ユーザがアクセスするサービスネットワークが、ユーザが加入しているホームネットワークとは異なる可能性があると仮定する。本発明に係る装置は、ホームネットワークのユーザを管理する認証プロバイダとの別の連携手段を具備するのが好ましい。別の連携手段は、セキュアサービスエントリポイントに配置されてもよいが、シングルサインオンサーバに配置されるのが好ましいだろう。
【００２３】
動作中、ユーザがローカルＨＴＴＰサービスまたは現在アクセスしているサービスネットワークとは異なるネットワーク上の外部サービスにアクセスしているときなど、好適な使用例の場合、本装置は、ユーザが既に認証されているか否かをチェックする手段を含む。従って、本装置は、ＨＴＴＰローカルサービスまたは外部ネットワーク上の外部（エクスターナル）サービスへのユーザのアクセスをインターセプト（傍受して阻止）するように構成された仲介エンティティと通信する手段が提供されてもよい。特に、この仲介エンティティは、ＨＴＴＰプロキシでもよく、またはこの目的のために構成される汎用ファイアウォールでもよい。
【００２４】
ユーザが非ＨＴＴＰローカルサービスにアクセスしているときの他の好適な使用例において、本装置は、ユーザが既に認証されているか否かをチェックする手段をさらに含む。しかし、この手法の下では、このチェックする手段がサービスと装置自体との間で共用されるため、ユーザとサービスとの間に仲介エンティティを介在させることは、重要な利点とはならない可能性がある。なお、ＨＴＴＰサービスであるかまたは非ＨＴＴＰサービスであるかは、仲介エンティティを有することの利点または欠点を議論するためではなく、むしろ、本発明に係る装置と互換性を有する他の構成を示しているにすぎない。
【００２５】
本発明に係るユーザ機器は、コアネットワークに対して認証処理を実行するように構成され、データ発信元認証を提供しないアクセスネットワークを介して、サービスネットワークとのセキュアトンネルを確立する手段を含む。セキュアトンネルは、アクセスネットワークにより割り当てられた外部ＩＰアドレスを使用する。ユーザ機器は：
コアネットワークにより認証された結果、アクセス証明書を取得する手段と；
アクセス証明書をセキュアトンネルにリンクさせる手段とを具備する。
【００２６】
ユーザ機器は、トンネルトラフィック内で内側ＩＰアドレスとして受信した内部ＩＰアドレスをアクセス証明書及びセキュアトンネルにリンクさせる手段を含む。このように、特定のサービスへのさらなるアクセスする際に、特定のサービスに直接アクセスするための擬似識別として、既に割り当てられているＩＰアドレスをユーザ機器が使用してもよい。
【００２７】
アクセス証明書を取得するために異なる機構が使用されてもよいが、ユーザ機器を提供することにより、さらなるセキュリティ上の利点が得られると考えられる。アクセス証明書を取得する手段は：
コアネットワークから認証チャレンジを受信する手段と；
認証応答を生成しかつコアネットワークに返信する手段と；
１組の公開鍵及び秘密鍵を生成する手段と；
秘密鍵の所有権を証明するデジタル署名とともに公開鍵をコアネットワークに対して送信する手段とを含む。
【００２８】
あるいは、簡易化されたユーザ機器及びコアネットワークにおいて、ユーザ機器でアクセス証明書を取得する手段は：
コアネットワークから認証チャレンジを受信する手段と；
認証応答を生成しかつコアネットワークに返信する手段と；
コアネットワークから取得可能なデジタル証明書を要求する手段とを含む。
【００２９】
本発明によると、通信サービスネットワークおいて、コアネットワークにより認証されかつデータ発信元認証を提供できないアクセスネットワークを介してサービスネットワークにアクセスするユーザに対して、シングルサインオンサービスをサポートする方法がさらに提供される。本方法は：
コアネットワークにより認証された結果、アクセス証明書をユーザ機器側に提供するステップと；
アクセスネットワークにより割り当てられた外部ＩＰアドレスを使用することにより、アクセスネットワークを介して、サービスネットワークのエンティティとユーザ機器側との間にセキュアトンネルを確立するステップと；
ユーザ機器側で、アクセス証明書をセキュアトンネルにリンクするステップと；
セキュアトンネルが確立している間、サービスネットワークにおいてユーザ機器側から受信したアクセス証明書の有効性をチェックするステップと；
アクセス証明書の有効性チェックが成功した際に、ユーザとの有効セッションを確立するステップと；
サービスネットワークにおいて、トンネルトラフィック内で内側ＩＰアドレスとして使用されるユーザに対する内部ＩＰアドレスを割り当てるステップと；
サービスネットワークのエンティティにおいて、ユーザに対して、セッションのデータ、アクセス証明書及び割り当てられた内部ＩＰアドレスをリンクするステップとを含む。
【００３０】
ユーザの機器における好適な対応する機能に従って、本方法は、トンネルトラフィック内で内側ＩＰアドレスとして受信した内部ＩＰアドレスを、アクセス証明書及びユーザ機器側のセキュアトンネルにリンクするステップをさらに含む。
【００３１】
上述の装置における好適な対応する機能に従って、本方法は、ユーザに対してサービス証明書を生成するステップをさらに含む。このステップは、サービスが要求されると、サービス単位で、ユーザに対してサービス証明書を生成するステップをさらに含んでもよい。
【００３２】
サービスネットワークにおいてユーザから受信したアクセス証明書の有効性をチェックするステップは、認識された認証エンティティによりアクセス証明書が署名されていない場合にホームネットワークの認証サーバと通信するステップをさらに含むことが好ましい。
【００３３】
これに対し、本発明に従って装置に付与される特定の構成によれば、本方法は、セキュアトンネルを管理するセキュアサービスエントリポイントと呼ばれる第１のデバイスが、ユーザに対してセッションのデータ、アクセス証明書及び割り当てられた内部ＩＰアドレスをリンクするステップが実行されるシングルサインオンサーバ（Ｎ ４２）と呼ばれる第２のデバイスと通信するステップをさらに含んでもよい。
【００３４】
例示的な使用方法によれば、ユーザがローカルサービスまたは現在アクセスしているサービスネットワークとは異なるネットワーク上にある外部サービスにアクセスしている場合、本方法は、ユーザが既に認証されているか否かをチェックする手段をさらに含む。
【発明を実施するための最良の形態】
【００３５】
本発明の特徴、目的及び利点については、添付の図面を参照しながら本明細書を読むことによりさらに明瞭に理解できるであろう。
【００３６】
以下において、無線ローカルエリアネットワーク（ＷＬＡＮ）を介してアクセスする場合などのように、データ発信元認証を提供しないアクセスネットワークを介してユーザがアクセスする場合にも、ユーザがシングルサインオン（ＳＳＯ）サービスを享受できるようにする装置、ユーザ機器及び方法の現時点で好適な実施形態を説明する。
【００３７】
本発明は、ユーザ機器、訪問先のサービスネットワーク、及びデータ発信元認証を提供しないアクセスネットワークを介したユーザ端末と訪問先のサービスネットワークとの間のセキュアトンネルを確立するための手法について、いくつかの手法を提案する。なお、、訪問先のサービスネットワークは、ホームサービスネットワークであってもよい。
【００３８】
本発明の第１の手法によると、コアネットワーク認証の処理中にユーザ端末側（Ｎ １０）がコアネットワーク（Ｎ ３０）から認証またはアクセス証明書を取得し、かつ、ユーザ端末側（Ｎ １０）が、サービスネットワーク（Ｎ ４０）に対する特定のセキュアトンネル（Ｓ−２４）に認証またはアクセス証明書をリンクする新しい機構を具備する。ここで、サービスネットワークは、ホームサービスネットワークや訪問先のサービスネットワークであってもよい。明瞭かつ簡潔に説明するために、以下において、認証証明書またはアクセス証明書を「アクセス証明書」と呼ぶことにする。
【００３９】
従って、図２及び図３に示されるように、認証自体は、拡張認証プロトコルフレームワーク（以下、ＥＡＰと称す。ＩＥＴＦ ＲＦＣ ２２８４に準拠する。）を使用してユーザ端末（Ｎ １０）とコアネットワーク（Ｎ ３０）に位置する認証サーバ（Ｎ ３１）との間で相互に実行される。しかしながら、アクセス認証は、アクセスネットワーク（Ｎ ２０）における汎用アクセスサーバ（以下、ＧＡＳ）（Ｎ ２２）により実行される。拡張認証プロトコルは、認証フレームワークを提供する。認証フレームワークは、複数の認証機構をサポートする。現在に至るまで、ＥＡＰは、ポイント・ツー・ポイントプロトコル（ＰＰＰ）を使用して、回線交換網またはダイヤルアップ回線を介して相互に接続するホスト及びルータにより実現されてきた。さらに、ＥＡＰは、例えばＥＡＰメッセージがカプセル化される８０２．１Ｘ ２００１等のＩＥＥＥ８０２規格に準拠するスイッチによっても実現されてきた。
【００４０】
ＥＡＰアーキテクチャの１つの利点は、その柔軟性にある。例えば、図１に示すようなネットワークアクセスサーバ（Ｎ ２１）（一般にＮＡＳとして知られる）は、非ローカルのユーザに対してだけでなく、ＮＡＳにおいてローカルに実現されていない認証方法についてのパススルーエンティティとして動作しつつ、同時に、ローカルのユーザを認証してもよい。ここで、ネットワークアクセスサーバ（Ｎ ２１）は、ＰＰＰまたはＩＥＥＥ８０２を使用するＥＡＰを介して、ネットワークへのアクセス権が付与される前に認証を必要とするユーザ（Ｎ １１）に接続される。
【００４１】
図２に示される現時点で好適な実施形態において、ユーザ（Ｎ １０）は、ネットワークへのアクセスを試みる。ＰＰＰまたはＩＥＥＥ８０２に基づく接続（コネクション）（Ｓ ２１）は、クライアントとアクセスネットワーク（Ｎ ２０）のＧＡＳ（Ｎ ２２）との間に確立される。ＧＡＳは、「認証、許可及び課金」（以下、ＡＡＡ）を行なうのに適切なプロトコル（Ｓ ２２）を使用して、コアネットワーク（Ｎ ３０）の認証サーバ（Ｎ ３１）と通信することにより認証実行し、また、ＥＡＰメッセージに対するパススルーとして動作する。
【００４２】
従来の適切なＡＡＡプロトコル（Ｓ １２；Ｓ ２２）は、リモート認証ダイヤルインユーザサービス（以下、ＲＡＤＩＵＳ。ＩＥＴＦ ＲＦＣ ２８６５に準拠。）プロトコルでもよい。ＲＡＤＩＵＳプロトコルは、図１に示すように、ネットワークアクセスサーバ（ＮＡＳ）（Ｎ ２１；Ｎ ２２）と認証サーバ（Ｎ ３１）との間で認証、許可及び構成情報を伝送するために、クライアント／サーバモデルを使用する。通常、通信ネットワークに対する接続性を保証するプロバイダは、ユーザの識別情報を確認するためにＲＡＤＩＵＳを使用する。従って、ユーザが周知の電話番号にダイヤルすることで、両側のモデム、すなわちユーザ及び接続性プロバイダが接続を確立する。サーバ側のモデムは、ネットワークアクセスサーバ（ＮＡＳ）に接続される。ＮＡＳは、ログイン名及びパスワードを要求する（Ｓ １１）ことにより、ネットワークへのアクセス権を付与する前にユーザの認証を要求する。ネットワークアクセスサーバ（ＮＡＳ）（Ｎ ２１；Ｎ ２２）は、ネットワークを介してＲＡＤＩＵＳサーバ（Ｎ ３１）と通信し、ユーザを認証するために、ＲＡＤＩＵＳプロトコルを使用する。ＲＡＤＩＵＳサーバ（Ｎ ３１）は、ログイン名及びパスワードなど、ＮＡＳから転送されたユーザに関する情報を収集する。認証処理は、ＲＡＤＩＵＳサーバがＮＡＳに多数のチャレンジを送信することを要求してもよいし、要求しなくてもよい。ユーザは、ＮＡＳに対して応答できる必要がある。認証処理の結果、ＲＡＤＵＩＳサーバ（Ｎ ３１）は、ユーザ（Ｎ １０；Ｎ １１）がネットワークへのアクセスを許可されたか否かをＮＡＳ（Ｎ ２１；Ｎ ２２）に対して示す。使用するのに適切な別のＡＡＡプロトコルは、ＲＡＤＩＵＳの進化型であるＤＩＡＭＥＴＥＲでもよい。
【００４３】
図２に示されるように、ＥＡＰ認証は、アクセスネットワーク（Ｎ ２０）の汎用アクセスサーバ（Ｎ ２２）を介して、ユーザ（Ｎ １０）と認証サーバ（Ｎ ３１）との間で相互に実行される（Ｓ ２３）。例えば、汎用アクセスサーバ（Ｎ ２２）は、図１のネットワークアクセスサーバ（Ｎ ２１）でもよい。
【００４４】
図２に示されるこのＥＡＰ認証の処理中、１つ以上のアクセス証明書が、ユーザ（Ｎ １０）とホームネットワーク（Ｎ ３０）との間、またはさらに一般的には、ユーザとコアネットワークとの間で、配布されるかまたは同意される。この時、ユーザを認証するコアネットワークがホームネットワークであるかまたは訪問先のネットワークであるかは関係ない。
【００４５】
これらのアクセス証明書は、ユーザ（Ｎ １０）とホームネットワークまたは訪問先のネットワークであるサービスネットワーク（Ｎ ４０）との間にセキュアトンネル（Ｓ ２４）を設定するためにも使用される。本発明に係る第１の面が目的としているように、このセキュアトンネル（Ｓ ２４）、すなわち、セキュア通信チャネルは、少なくともデータ発信元認証またはそれと同等の機能を提供する必要がある。
【００４６】
アクセス証明書の配布処理や同意処理についての機構は、セキュアトンネルにリンクまたは関連付けるために適正に使用されるため、本発明の目的を達成する上でも適切な機構といえるだろう。
【００４７】
しかしながら、現時点で好適な実施形態によれば、図３が示すように、本発明の目的を達成する上で適切な、一時的な証明書を取得するための新しい機構が提供される。
【００４８】
このシーケンス図において、認証チャレンジがユーザ端末側（Ｎ １０）で受信されると、認証応答を生成することに加え、１組の公開鍵及び秘密鍵が生成される。秘密鍵の所有権を証明するデジタル署名に加え、公開鍵が、認証応答とともにコアネットワークの認証サーバ（Ｎ ３１）へ送信される。
【００４９】
ユーザの認証が成功すると、受信したデジタル署名がチェックされる。デジタル署名が適正なものである場合、一時的なデジタル証明書がユーザの公開鍵に対して生成される。この証明書は、認証の成功を示すメッセージとともに、認証サーバ（Ｎ ３１）からユーザの端末側（Ｎ １０）に返信される。
【００５０】
図示しないが、ユーザの端末側（Ｎ １０）は、１組の公開鍵及び秘密鍵を生成する代わりに、認証チャレンジの応答とともに送信されるべきデジタル証明書の要求を生成してもよい。
【００５１】
本発明の第１の面によれば、好適な本実施形態の利点またはその他の利点により一時的なデジタル証明書が取得されるが、これは、ユーザの端末側でセキュアトンネルとリンクされるアクセス証明書の一種である。
【００５２】
しかし、本発明の目的に対して有効なコアネットワークからアクセス証明書を取得するために、他の機構が使用されてもよい。図２の好適な実施形態に示される１つの例によれば、上述した一時的な証明書のようなアクセス証明書が認証サーバ（Ｎ ３１）からユーザ端末（Ｎ １０）に配布されるが、アクセス証明書は別の証明書プロバイダ（Ｎ ３２）から取得されてもよい。別の例においては、認証サーバ（Ｎ ３１）自体がそのようなアクセス証明書を生成する。認証サーバ（Ｎ ３１）または証明書プロバイダ（Ｎ ３２）が、アクセス証明書に電子署名してもよい。他の実施形態においては、いくつかの暗号データが認証サーバ（Ｎ ３１）及びユーザ機器（Ｎ １０）において取得され、その後、それらの暗号データがアクセス証明書として使用されてもよい。最後の例の場合、アクセス証明書を認証サーバからユーザに対して配布する必要はないため、その結果、アクセス証明書は、コアネットワーク（Ｎ ３０）により署名されることはないだろう。
【００５３】
図２に戻ると、アクセス認証を実行している間にコアネットワーク（Ｎ ３０）から取得されたアクセス証明書は、ユーザ（Ｎ １０）とホームサービスネットワークまたは訪問先のサービスネットワーク（Ｎ ４０）のエンティティ（Ｎ ４１）との間にセキュアトンネル（Ｓ ２４）を設定するために使用される。本明細書においては、エンティティ（Ｎ ４１）をセキュアサービスエントリポイント（以下、ＳＳＥＰ）と呼ぶ。アクセス証明書がコアネットワークにより署名されない場合、ＳＳＥＰ（Ｎ ４１）と認証サーバ（Ｎ ３１）との間に通信チャネル（Ｓ ２５）が必要とされる。それにより、ユーザ（Ｎ １０）により提供されたアクセス証明書を受入れ可能であるかを、ＳＳＥＰが認証サーバに確認できることが好ましい。これに対し、アクセス証明書が署名される場合、ＳＳＥＰ（Ｎ ４１）は、認証サーバ（Ｎ ３１）または証明書プロバイダ（Ｎ ３２）により署名された有効なアクセス証明書として、それらアクセス証明書を受け入れるように構成されるのが好ましい。いずれの場合においても、ユーザ端末（Ｎ １０）とＳＳＥＰ（Ｎ ４１）との間のセキュア通信チャネル（Ｓ ２４）は、少なくともデータ発信元認証を提供する必要がある。このように、このセキュア通信チャネルを介して受信された全てのトラフィックは、要求したユーザからのものであり、ユーザのふりをした攻撃者からのものではないとみなすことができる。
【００５４】
本発明に係る第２の面によれば、ユーザに関連するセッション情報を保持し、そのセッション情報をセキュアトンネルの確立及び切断にリンクさせる新しい機構が、ホームサービスネットワークまたは訪問先のサービスネットワークのエンティティにおいて提供される。現時点で好適な実施形態において、このエンティティは、上述したセキュアサービスエントリポイント（ＳＳＥＰ）と協働するシングルサインオン（ＳＳＯ）サーバ（Ｎ ４２）であることが好ましいが、いずれか一方であってもよい。このように、ユーザ端末（Ｎ １０）がセキュア通信チャネル（Ｓ ２４）を介してサービスにアクセスしようとする（Ｓ ２４）場合、ユーザにシングルサインオンをサポートするために、ユーザ端末（Ｎ １０）から、サービス自体から、またはこの目的のためにサービスと協働するエンティティから、ＳＳＯサーバ（Ｎ ４２）にサービス証明書が要求される。ＳＳＯサーバ（Ｎ ４２）は、ユーザ端末（Ｎ １０）に対するサービス証明書の要求が確かにサービスにアクセスするためのユーザの試みからのものであり、ユーザのふりをした攻撃者からのものではないという保証を有する。従って、ＳＳＯサーバ（Ｎ ４２）は、追加の認証を実行することなく、要求されたサービス証明書を要求者に提供できる。
【００５５】
図２をさらに参照すると、トンネルトラフィックにおいて使用されるように、ＩＰアドレスをユーザに割り当てるために、ＳＳＥＰは、ＳＳＯサーバ（Ｎ ４２）と情報を交換する（Ｓ ２６）。このＩＰアドレスは、サービスネットワークにより処理されるＩＰアドレスのプールに含まれていてもよい。その後、ＳＳＥＰ（Ｎ ４１）は、ユーザ（Ｎ １０）がセッションを確立したことを、ＳＳＯサーバ（Ｎ ４２）に知らせる。
【００５６】
これが達成されると、すなわち、ユーザに割り当てられたＩＰアドレスがユーザアクセス証明書及び対応するセッション情報にリンクされると、ＳＳＯサーバ（Ｎ ４２）は、内部ＩＰアドレスとともに受信したサービス証明書に対する要求が確かに対応するユーザからのものであるということを保証できる。
【００５７】
図示しないが、ユーザが訪問先のサービスネットワークとのセキュア通信チャネルを確立した場合、ＳＳＯサーバは、ユーザを管理する識別プロバイダ（ＩｄＰ）、すなわち、ＩｄＰの役割を果たすホームサービスネットワークのエンティティとのさらなる連携動作を必要とする。簡単にするため、以下の説明においては、ＩｄＰの役割を果たすホームサービスネットワークにユーザ端末が接続されていると仮定する。
【００５８】
この段階で、ユーザは、データ発信元認証を提供できないアクセスネットワークを介してアクセスしている場合においても、ユーザの都合のいい時にシングルサインオン（ＳＳＯ）サービスを楽しむことができる。特に、ユーザ端末（Ｎ １０）は、以下に説明する現時点で好適な各実施形態に従って、上述した任意のビジネスモデルの下で、すなわちウォールドガーデンモデルまたは連携型シングルサインオンモデルの下で動作してもよい。
【００５９】
第１の実施形態において、図４に示されるウォールドガーデンの場合、ユーザがＨＴＴＰローカルサービス（Ｎ ４４）にアクセスする時、中間ノード（Ｎ ４３）は、ＨＴＴＰローカルサービスへのアクセスを傍受して阻止する（Ｓ ３０，Ｓ ２９）。この中間ノード（Ｎ ４３）は、ユーザが既に認証されているか否かをＳＳＯサーバ（Ｎ ４２）に問い合わせる（Ｓ ２８）。中間ノード（Ｎ ４３）は、汎用ファイアウォールがこの目的のために構成されてもよいが、ＨＴＴＰプロキシであることが好ましいだろう。この場合にユーザを識別するための擬似識別は、データ発信元認証を保証可能な事前に割り当てられたＩＰアドレスである。そのような問合せを受信するＳＳＯサーバ（Ｎ ４２）は、ＩＰアドレスのタグが付けられた使用可能なセッションが存在することをチェックし、確認応答またはサービス証明書を、中間ノードであるＨＴＴＰプロキシ（Ｎ ４３）に送信する。サービス証明書は、ＨＴＴＰローカルサービス（Ｎ ４４）に対するユーザ端末（Ｎ １０）のアクセスを許可し、任意で、ユーザ端末のブラウザにクッキーを割り当てる。クッキーが提供された場合、ＨＴＴＰサービスに対して次の要求があった時、ＳＳＯサーバ（Ｎ ４２）に確認することなく、ユーザ端末（Ｎ １０）を認識するために、このクッキーが使用されうる。
【００６０】
第２の実施形態において、図５に示されるウォールドガーデンの場合、ユーザが非ＨＴＴＰサービス（Ｎ ４５）にアクセスする時、または、一般的には、ユーザが上述のＨＴＴＰプロキシを必要としないローカルサービス（Ｎ ４５）にアクセスする時、ローカルサービス（Ｎ ４５）は、恐らくＳＳＥＰ（Ｎ ４１）を介して、ユーザ端末側（Ｎ １０）から直接アクセスされてもよい（Ｓ ２４，Ｓ ３１）。要求されたローカルサービス（Ｎ ４５）は、事前に割り当てられたＩＰアドレスを擬似識別情報として使用し、ユーザが既に認証されているかをＳＳＯサーバ（Ｎ ４２）に直接問い合わせる（Ｓ ３２）。そのような問合せを受信するＳＳＯサーバ（Ｎ ４２）は、ＩＰアドレスによりタグ付けされた使用可能なセッションが存在することをチェックし、ユーザ（Ｎ １０）のアクセスを許可するために、確認応答またはサービス証明書をローカルサービス（Ｎ ４５）に送信する。
【００６１】
第３の実施形態において、図６に示される連携型ＳＳＯの場合、ユーザ（Ｎ １０）は、外部サービス（Ｎ ５１）へのアクセスを試み、ＬＡＰプロトコルに従って、ユーザのブラウザ（Ｎ １０）は、サードパーティＳＰ（Ｎ ５１）、すなわち外部サービスにリダイレクトされる（Ｓ ３０，Ｓ ３３）。サードパーティＳＰ（Ｎ ５１）は、ユーザがアクセス証明書を提供した時に事前に割り当てられたＩＰアドレスを使用して、ＳＳＯサーバ（Ｎ ４２）にサービスの許可を要求する（Ｓ ３３、Ｓ ２８）。ＳＳＯサーバ（Ｎ ４２）は、ＳＳＯ条件の下、当該ＩＰアドレスを擬似識別情報として割り当てられているユーザについて、認証及び許可状態をチェックし、その後、要求したサードパーティＳＰにサインオンするために使用できるサービス証明書を返信する。ＳＳＯサーバは、上述した第１の実施形態と同様に、クッキーを割り当ててもよい。
【００６２】
最後に、ユーザ端末がセキュアトンネルを切断する場合、ＳＳＥＰは、内部ＩＰアドレスの割り当てを解除しかつＳＳＯサーバのユーザ関連セッション情報を削除するために、ＳＳＯサーバと通信する。
【００６３】
例示的かつ非限定的な手法で、いくつかの実施形態に関連して本発明を説明してきた。上述した説明に鑑みて、これらの実施形態の変形したり変更したりすることは可能であり、これらは特許請求の範囲に含まれることが意図されている。
【図面の簡単な説明】
【００６４】
【図１】図１は、拡張認証プロトコルに基づくアクセス制御に対する周知のアーキテクチャの基本的な概略を示す図である。
【図２】図２は、ユーザがユーザのホームネットワークにより認証され、データ発信元認証を提供しないアクセスネットワークを介して、アクセス認証を再利用するサービスネットワークにさらにアクセスしている時に関わるエンティティ及びインタフェースに焦点を当て、アーキテクチャ及びインタフェースの一例の概略を示す図である。
【図３】図３は、ユーザがユーザのホームコアネットワークにより認証された結果、アクセス証明書を取得する現時点で好適な実施形態を説明するシーケンス図である。
【図４】図４は、ユーザがローカルＨＴＴＰサービスにアクセスする時の好適な動作に焦点を当て、図２に示されるアーキテクチャ及びインタフェースの第１の概略を示す図である。
【図５】図５は、ユーザがローカル非ＨＴＴＰサービスにアクセスするか、あるいは、ＨＴＴＰプロキシまたはファイアウォール等の任意の仲介エンティティの援助なしでローカルＨＴＴＰサービスにアクセスしている時の好適な動作に焦点を当て、図２に示されるアーキテクチャ及びインタフェースの第２の概略を示す図である。
【図６】図６は、ユーザが現在アクセスしているサービスネットワークとは異なるネットワーク上の外部サービスにアクセスしている時の好適な動作に焦点を当て、図２に示されるアーキテクチャ及びインタフェースの第３の概略を示す図である。
【特許請求の範囲】
【請求項１】
データ発信元認証を提供しないアクセスネットワーク（Ｎ−２０）を介して、通信サービスネットワーク（Ｎ−４０）におけるシングルサインオンサービスの要求をユーザ（Ｎ−１０）から受信するように構成された装置（Ｎ−４１、Ｎ４２）であって、前記ユーザ（Ｎ−１０）は、コアネットワーク（Ｎ−３０）により認証された結果としてアクセス証明書（デジタル証明書）を受信済みであり、
前記装置は、
前記アクセスネットワーク（Ｎ−２０）を介して前記ユーザ（Ｎ−１０）から前記アクセス証明書を受信する手段（Ｓ−２４）と、
前記ユーザ（Ｎ−１０）から受信された前記アクセス証明書の有効性をチェックする手段（Ｎ−４１、Ｓ−２５、Ｎ−３１）と、
前記アクセス証明書の有効性のチェックに成功すると、前記ユーザ（Ｎ−１０）との有効なセッションを確立する手段と、
前記通信サービスネットワーク（Ｎ−４０）において前記ユーザを識別するための内部ＩＰアドレスを割り当てる手段と、
前記内部ＩＰアドレスと、前記セッションのデータと、前記アクセス証明書とをリンクさせる手段（Ｎ−４１、Ｓ−２６、Ｎ−４２）と
を含み、さらに、
前記アクセスネットワーク（Ｎ−２０）により前記ユーザ（Ｎ−１０）に割り当てられた外部ＩＰアドレスを使用し、かつ、セキュアトンネル化されたトラフィックにおける内側ＩＰアドレスとして前記通信サービスネットワーク（Ｎ−４０）において前記ユーザ（Ｎ−１０）を識別するために割り当てられた前記内部ＩＰアドレスを使用することにより、前記アクセスネットワーク（Ｎ−２０）を通じて前記アクセス証明書が受信されたときに、前記ユーザ（Ｎ−１０）とのセキュアトンネル（Ｓ−２４）確立する手段をさらに含むことを特徴とする装置。
【請求項２】
前記通信サービスネットワーク（Ｎ−４０）におけるサービスにアクセスすることを、前記ユーザに許可するためのサービス証明書を生成する手段をさらに含むことを特徴とする請求項１に記載の装置。
【請求項３】
前記サービス証明書は、サービスの要求があると前記ユーザ（Ｎ−１０）に対して該サービスごとに生成される（Ｎ−４１、Ｓ−２６、Ｎ−４２）ことを特徴とする請求項２に記載の装置。
【請求項４】
認識された認証エンティティ（Ｎ−３１）により前記アクセス証明書が署名されていないときに、前記ユーザ（Ｎ−１０）から受信された前記アクセス証明書の有効性をチェックするために、前記ホームネットワーク（Ｎ−３０）の認証サーバ（Ｎ−３１）と通信する手段をさらに含むことを特徴とする請求項１に記載の装置。
【請求項５】
前記ユーザ（Ｎ−１０）との前記セキュアトンネルを確立する手段は、セキュアサービスエントリポイントと呼ばれる第１のデバイスに含まれ、
前記ユーザ（Ｎ−１０）に対して、前記セッションのデータ、前記アクセス証明書及び前記内部ＩＰアドレスをリンクさせる手段は、シングルサインオンサーバと呼ばれる第２のデバイスに含まれることを特徴とする請求項１に記載の装置。
【請求項６】
前記セキュアサービスエントリポイントと前記シングルサインオンサーバとを通信させるための手段をさらに含むことを特徴とする請求項５に記載の装置。
【請求項７】
前記ホームネットワーク（Ｎ−３０）が、前記装置のエントリーポイントとなっている前記通信サービスネットワーク（Ｎ−４０）と異なるときに、前記ホームネットワークにおいて前記ユーザを管理する識別プロバイダ（Ｎ−３１）と前記装置とを連携させる追加の手段をさらに含むことを特徴とする請求項１に記載の装置。
【請求項８】
前記ユーザ（Ｎ−１０）がローカルのＨＴＴＰサービス（Ｎ−４４）、または現在アクセスしているサービスネットワーク（Ｎ−４０）とは異なるネットワーク（Ｎ−５０）上の外部サービス（Ｎ−５１）にアクセスしているときに、前記装置は、前記ユーザ（Ｎ−１０）が既に認証されているか否かをチェックする手段（Ｎ−４１、Ｓ−３０、Ｎ−４３、Ｓ−２８、Ｎ−４２）をさらに含むことを特徴とする請求項１に記載の装置。
【請求項９】
前記ローカルのＨＴＴＰサービス（Ｎ−４４）または前記外部ネットワーク（Ｎ−５０）上の前記外部サービス（Ｎ−５１）への前記ユーザ（Ｎ−１０）のアクセス（Ｓ−２９）を傍受して阻止するように構成された仲介エンティティ（Ｎ−４３）と通信する手段（Ｓ−３０、Ｓ−２８）をさらに含むことを特徴とする請求項８に記載の装置。
【請求項１０】
前記仲介エンティティは、ＨＴＴＰプロキシであることを特徴とする請求項９に記載の装置。
【請求項１１】
前記仲介エンティティは、ファイアウォールであることを特徴とする請求項９に記載の装置。
【請求項１２】
前記ユーザ（Ｎ−１０）が非ＨＴＴＰのローカルサービス（Ｎ−４５）にアクセスしているときに、前記ユーザ（Ｎ−１０）が既に認証されているか否かをチェックする手段（Ｎ−４１、ｓ−３１、Ｎ−４５、Ｓ−３２、Ｎ−４２）をさらに含むことを特徴とする請求項１に記載の装置。
【請求項１３】
前記アクセス証明書を受信する手段は、前記ユーザ（Ｎ−１０）の認証に成功したことを示すために前記コアネットワーク（Ｎ−３０）によって発行されたデジタル証明書が存在しているか否かをチェックする手段を含むことを特徴とする請求項１に記載の装置。
【請求項１４】
コアネットワーク（Ｎ−３０）との認証手続を実行するとともに、データ発信元認証を提供しないアクセスネットワーク（Ｎ−２０）を介して通信サービスネットワーク（Ｎ−４０）にアクセスするユーザ機器（Ｎ−１０、Ｎ−１１）であって、
前記コアネットワーク（Ｎ−３０）によって認証された結果としてアクセス証明書を取得する手段（Ｓ−２３）と、
前記アクセスネットワーク（Ｎ−２０）を介してアクセスするときに、前記通信サービスネットワーク（Ｎ−４０）に向けて前記アクセス証明書を送信する手段（Ｓ−２４）と
を含み、さらに、
前記通信サービスネットワークとのセキュアトンネルであって、前記アクセスネットワークにより前記ユーザ機器に割り当てられた外部ＩＰアドレスを利用するセキュアトンネルを、前記アクセスネットワークを介して確立する手段と、
前記通信サービスネットワークにおいて前記ユーザ機器（Ｎ−１０）を識別するために、トンネル化されたトラフィックでは内側ＩＰアドレスとして使用される、前記通信サービスネットワークによって割り当てられた内部ＩＰアドレスを受信する手段（Ｓ−２４）と、
前記アクセス証明書を、前記内部ＩＰアドレスと前記セキュアトンネルとにリンクさせる手段と
を含むことを特徴とするユーザ機器。
【請求項１５】
前記アクセス証明書を取得する手段は、
前記コアネットワークから認証チャレンジを受信する手段と、
認証応答を生成して前記コアネットワークに該認証応答を返信する手段と、
１組の公開鍵及び秘密鍵を生成する手段と、
前記秘密鍵の所有権を証明するデジタル署名とともに前記公開鍵を前記コアネットワークに対して送信する手段と
を含むことを特徴とする請求項１４に記載のユーザ機器。
【請求項１６】
前記アクセス証明書を取得する手段は、
前記コアネットワークから認証チャレンジを受信する手段と、
認証応答を生成して前記コアネットワークに該認証応答を返信する手段と、
前記コアネットワークから取得可能なデジタル証明書を要求する手段と
を含むことを特徴とする請求項１４に記載のユーザ機器。
【請求項１７】
前記アクセス証明書を取得する手段は、
前記デジタル証明書を取得可能な公開鍵を生成する手段を含むことを特徴とする請求項１６に記載のユーザ機器。
【請求項１８】
データ発信元認証を提供できないアクセスネットワーク（Ｎ−２０）を介して通信サービスネットワーク（Ｎ−４０）にアクセスするユーザ（Ｎ−１０）に対してシングルサインオンサービスをサポートする方法であって、前記ユーザ（Ｎ−１０）がコアネットワークにより認証された結果としてアクセス証明書を受信済みである場合に、
前記方法は、
前記通信サービスネットワーク（Ｎ−４０）において、前記アクセスネットワーク（Ｎ−２０）を通じて前記ユーザ（Ｎ−１０）から前記アクセス証明書を受信するステップ（Ｓ−２４）と、
前記通信サービスネットワーク（Ｎ−４０）において、受信された前記アクセス証明書の有効性をチェックするステップ（Ｎ−４１、Ｓ−２５、Ｎ−３１）と、
前記アクセス証明書の有効性のチェックが成功すると、前記ユーザ（Ｎ−１０）との有効セッションを確立するステップ（Ｎ−４１、Ｓ−２６、Ｎ−４２）と、
前記通信サービスネットワーク（Ｎ−４０）において、該通信サービスネットワーク内のサービスにアクセスする際に、前記ユーザ（Ｎ−１０）を識別するため、前記ユーザに内部ＩＰアドレスを割り当てるステップ（Ｎ−４１、Ｓ−２６、Ｎ−４２）と、
前記通信サービスネットワーク（Ｎ−４０）のエンティティ（Ｎ−４１、Ｎ−４２）において、前記ユーザ（Ｎ−１０）に対して、セッションのデータ、アクセス証明書及び割り当てられた前記内部ＩＰアドレスをリンクさせるステップと
を含むことを特徴とする方法。
【請求項１９】
前記通信サービスネットワーク（Ｎ−４０）におけるサービスへアクセスすることを前記ユーザに許可するためのサービス証明書を生成するステップ（Ｎ−４１、Ｓ−２６、Ｎ−４２）をさらに含むことを特徴とする請求項１８に記載の方法。
【請求項２０】
前記サービス証明書を生成するステップには、前記サービスの要求があると該サービスごとに前記ユーザに対して前記サービス証明書を生成するステップを含むことを特徴とする請求項１９に記載の方法。
【請求項２１】
前記通信サービスネットワーク（Ｎ−４０）において、受信された前記アクセス証明書の有効性をチェックするステップ（Ｎ−４１、Ｓ−２５、Ｎ−３１）は、
認識された認証エンティティ（Ｎ−３１）により前記アクセス証明書が署名されていないときに、前記ユーザ（Ｎ−１０）から受信された前記アクセス証明書の有効性をチェックするために、前記ホームネットワーク（Ｎ−３０）の認証サーバ（Ｎ−３１）と通信するステップをさらに含むことを特徴とする請求項２０に記載の方法。
【請求項２２】
前記通信サービスネットワーク（Ｎ−４０）のエンティティ（Ｎ−４１、Ｎ−４２）において、前記ユーザ（Ｎ−１０）に対して、セッションのデータ、アクセス証明書及び割り当てられた前記内部ＩＰアドレスをリンクさせるステップは、
前記セキュアトンネル（Ｓ−２４）として機能する、セキュアサービスエントリポイント（Ｎ−４１）と呼ばれる第１のデバイスと通信するステップ（Ｓ−２６）と、
前記リンクさせるステップを実行する、シングルサインオンサーバ（Ｎ−４２）と呼ばれる第２のデバイスと通信するステップと
を含むことを特徴とする請求項１８に記載の方法。
【請求項２３】
前記ユーザ（Ｎ−１０）がローカルのＨＴＴＰサービス（Ｎ−４４、Ｎ−４５）、または現在アクセスしているサービスネットワーク（Ｎ−４０）とは異なるネットワーク（Ｎ−５０）上の外部サービス（Ｎ−５１）にアクセスしているときに、前記ユーザが既に認証されているか否かをチェックするステップ（Ｎ−４１、Ｓ−３０、Ｎ−４３、Ｓ−２８、Ｎ−４２）をさらに含むことを特徴とする請求項１８に記載の方法。
【請求項１】
データ発信元認証を提供しないアクセスネットワーク（Ｎ−２０）を介して、通信サービスネットワーク（Ｎ−４０）におけるシングルサインオンサービスの要求をユーザ（Ｎ−１０）から受信するように構成された装置（Ｎ−４１、Ｎ４２）であって、前記ユーザ（Ｎ−１０）は、コアネットワーク（Ｎ−３０）により認証された結果としてアクセス証明書（デジタル証明書）を受信済みであり、
前記装置は、
前記アクセスネットワーク（Ｎ−２０）を介して前記ユーザ（Ｎ−１０）から前記アクセス証明書を受信する手段（Ｓ−２４）と、
前記ユーザ（Ｎ−１０）から受信された前記アクセス証明書の有効性をチェックする手段（Ｎ−４１、Ｓ−２５、Ｎ−３１）と、
前記アクセス証明書の有効性のチェックに成功すると、前記ユーザ（Ｎ−１０）との有効なセッションを確立する手段と、
前記通信サービスネットワーク（Ｎ−４０）において前記ユーザを識別するための内部ＩＰアドレスを割り当てる手段と、
前記内部ＩＰアドレスと、前記セッションのデータと、前記アクセス証明書とをリンクさせる手段（Ｎ−４１、Ｓ−２６、Ｎ−４２）と
を含み、さらに、
前記アクセスネットワーク（Ｎ−２０）により前記ユーザ（Ｎ−１０）に割り当てられた外部ＩＰアドレスを使用し、かつ、セキュアトンネル化されたトラフィックにおける内側ＩＰアドレスとして前記通信サービスネットワーク（Ｎ−４０）において前記ユーザ（Ｎ−１０）を識別するために割り当てられた前記内部ＩＰアドレスを使用することにより、前記アクセスネットワーク（Ｎ−２０）を通じて前記アクセス証明書が受信されたときに、前記ユーザ（Ｎ−１０）とのセキュアトンネル（Ｓ−２４）確立する手段をさらに含むことを特徴とする装置。
【請求項２】
前記通信サービスネットワーク（Ｎ−４０）におけるサービスにアクセスすることを、前記ユーザに許可するためのサービス証明書を生成する手段をさらに含むことを特徴とする請求項１に記載の装置。
【請求項３】
前記サービス証明書は、サービスの要求があると前記ユーザ（Ｎ−１０）に対して該サービスごとに生成される（Ｎ−４１、Ｓ−２６、Ｎ−４２）ことを特徴とする請求項２に記載の装置。
【請求項４】
認識された認証エンティティ（Ｎ−３１）により前記アクセス証明書が署名されていないときに、前記ユーザ（Ｎ−１０）から受信された前記アクセス証明書の有効性をチェックするために、前記ホームネットワーク（Ｎ−３０）の認証サーバ（Ｎ−３１）と通信する手段をさらに含むことを特徴とする請求項１に記載の装置。
【請求項５】
前記ユーザ（Ｎ−１０）との前記セキュアトンネルを確立する手段は、セキュアサービスエントリポイントと呼ばれる第１のデバイスに含まれ、
前記ユーザ（Ｎ−１０）に対して、前記セッションのデータ、前記アクセス証明書及び前記内部ＩＰアドレスをリンクさせる手段は、シングルサインオンサーバと呼ばれる第２のデバイスに含まれることを特徴とする請求項１に記載の装置。
【請求項６】
前記セキュアサービスエントリポイントと前記シングルサインオンサーバとを通信させるための手段をさらに含むことを特徴とする請求項５に記載の装置。
【請求項７】
前記ホームネットワーク（Ｎ−３０）が、前記装置のエントリーポイントとなっている前記通信サービスネットワーク（Ｎ−４０）と異なるときに、前記ホームネットワークにおいて前記ユーザを管理する識別プロバイダ（Ｎ−３１）と前記装置とを連携させる追加の手段をさらに含むことを特徴とする請求項１に記載の装置。
【請求項８】
前記ユーザ（Ｎ−１０）がローカルのＨＴＴＰサービス（Ｎ−４４）、または現在アクセスしているサービスネットワーク（Ｎ−４０）とは異なるネットワーク（Ｎ−５０）上の外部サービス（Ｎ−５１）にアクセスしているときに、前記装置は、前記ユーザ（Ｎ−１０）が既に認証されているか否かをチェックする手段（Ｎ−４１、Ｓ−３０、Ｎ−４３、Ｓ−２８、Ｎ−４２）をさらに含むことを特徴とする請求項１に記載の装置。
【請求項９】
前記ローカルのＨＴＴＰサービス（Ｎ−４４）または前記外部ネットワーク（Ｎ−５０）上の前記外部サービス（Ｎ−５１）への前記ユーザ（Ｎ−１０）のアクセス（Ｓ−２９）を傍受して阻止するように構成された仲介エンティティ（Ｎ−４３）と通信する手段（Ｓ−３０、Ｓ−２８）をさらに含むことを特徴とする請求項８に記載の装置。
【請求項１０】
前記仲介エンティティは、ＨＴＴＰプロキシであることを特徴とする請求項９に記載の装置。
【請求項１１】
前記仲介エンティティは、ファイアウォールであることを特徴とする請求項９に記載の装置。
【請求項１２】
前記ユーザ（Ｎ−１０）が非ＨＴＴＰのローカルサービス（Ｎ−４５）にアクセスしているときに、前記ユーザ（Ｎ−１０）が既に認証されているか否かをチェックする手段（Ｎ−４１、ｓ−３１、Ｎ−４５、Ｓ−３２、Ｎ−４２）をさらに含むことを特徴とする請求項１に記載の装置。
【請求項１３】
前記アクセス証明書を受信する手段は、前記ユーザ（Ｎ−１０）の認証に成功したことを示すために前記コアネットワーク（Ｎ−３０）によって発行されたデジタル証明書が存在しているか否かをチェックする手段を含むことを特徴とする請求項１に記載の装置。
【請求項１４】
コアネットワーク（Ｎ−３０）との認証手続を実行するとともに、データ発信元認証を提供しないアクセスネットワーク（Ｎ−２０）を介して通信サービスネットワーク（Ｎ−４０）にアクセスするユーザ機器（Ｎ−１０、Ｎ−１１）であって、
前記コアネットワーク（Ｎ−３０）によって認証された結果としてアクセス証明書を取得する手段（Ｓ−２３）と、
前記アクセスネットワーク（Ｎ−２０）を介してアクセスするときに、前記通信サービスネットワーク（Ｎ−４０）に向けて前記アクセス証明書を送信する手段（Ｓ−２４）と
を含み、さらに、
前記通信サービスネットワークとのセキュアトンネルであって、前記アクセスネットワークにより前記ユーザ機器に割り当てられた外部ＩＰアドレスを利用するセキュアトンネルを、前記アクセスネットワークを介して確立する手段と、
前記通信サービスネットワークにおいて前記ユーザ機器（Ｎ−１０）を識別するために、トンネル化されたトラフィックでは内側ＩＰアドレスとして使用される、前記通信サービスネットワークによって割り当てられた内部ＩＰアドレスを受信する手段（Ｓ−２４）と、
前記アクセス証明書を、前記内部ＩＰアドレスと前記セキュアトンネルとにリンクさせる手段と
を含むことを特徴とするユーザ機器。
【請求項１５】
前記アクセス証明書を取得する手段は、
前記コアネットワークから認証チャレンジを受信する手段と、
認証応答を生成して前記コアネットワークに該認証応答を返信する手段と、
１組の公開鍵及び秘密鍵を生成する手段と、
前記秘密鍵の所有権を証明するデジタル署名とともに前記公開鍵を前記コアネットワークに対して送信する手段と
を含むことを特徴とする請求項１４に記載のユーザ機器。
【請求項１６】
前記アクセス証明書を取得する手段は、
前記コアネットワークから認証チャレンジを受信する手段と、
認証応答を生成して前記コアネットワークに該認証応答を返信する手段と、
前記コアネットワークから取得可能なデジタル証明書を要求する手段と
を含むことを特徴とする請求項１４に記載のユーザ機器。
【請求項１７】
前記アクセス証明書を取得する手段は、
前記デジタル証明書を取得可能な公開鍵を生成する手段を含むことを特徴とする請求項１６に記載のユーザ機器。
【請求項１８】
データ発信元認証を提供できないアクセスネットワーク（Ｎ−２０）を介して通信サービスネットワーク（Ｎ−４０）にアクセスするユーザ（Ｎ−１０）に対してシングルサインオンサービスをサポートする方法であって、前記ユーザ（Ｎ−１０）がコアネットワークにより認証された結果としてアクセス証明書を受信済みである場合に、
前記方法は、
前記通信サービスネットワーク（Ｎ−４０）において、前記アクセスネットワーク（Ｎ−２０）を通じて前記ユーザ（Ｎ−１０）から前記アクセス証明書を受信するステップ（Ｓ−２４）と、
前記通信サービスネットワーク（Ｎ−４０）において、受信された前記アクセス証明書の有効性をチェックするステップ（Ｎ−４１、Ｓ−２５、Ｎ−３１）と、
前記アクセス証明書の有効性のチェックが成功すると、前記ユーザ（Ｎ−１０）との有効セッションを確立するステップ（Ｎ−４１、Ｓ−２６、Ｎ−４２）と、
前記通信サービスネットワーク（Ｎ−４０）において、該通信サービスネットワーク内のサービスにアクセスする際に、前記ユーザ（Ｎ−１０）を識別するため、前記ユーザに内部ＩＰアドレスを割り当てるステップ（Ｎ−４１、Ｓ−２６、Ｎ−４２）と、
前記通信サービスネットワーク（Ｎ−４０）のエンティティ（Ｎ−４１、Ｎ−４２）において、前記ユーザ（Ｎ−１０）に対して、セッションのデータ、アクセス証明書及び割り当てられた前記内部ＩＰアドレスをリンクさせるステップと
を含むことを特徴とする方法。
【請求項１９】
前記通信サービスネットワーク（Ｎ−４０）におけるサービスへアクセスすることを前記ユーザに許可するためのサービス証明書を生成するステップ（Ｎ−４１、Ｓ−２６、Ｎ−４２）をさらに含むことを特徴とする請求項１８に記載の方法。
【請求項２０】
前記サービス証明書を生成するステップには、前記サービスの要求があると該サービスごとに前記ユーザに対して前記サービス証明書を生成するステップを含むことを特徴とする請求項１９に記載の方法。
【請求項２１】
前記通信サービスネットワーク（Ｎ−４０）において、受信された前記アクセス証明書の有効性をチェックするステップ（Ｎ−４１、Ｓ−２５、Ｎ−３１）は、
認識された認証エンティティ（Ｎ−３１）により前記アクセス証明書が署名されていないときに、前記ユーザ（Ｎ−１０）から受信された前記アクセス証明書の有効性をチェックするために、前記ホームネットワーク（Ｎ−３０）の認証サーバ（Ｎ−３１）と通信するステップをさらに含むことを特徴とする請求項２０に記載の方法。
【請求項２２】
前記通信サービスネットワーク（Ｎ−４０）のエンティティ（Ｎ−４１、Ｎ−４２）において、前記ユーザ（Ｎ−１０）に対して、セッションのデータ、アクセス証明書及び割り当てられた前記内部ＩＰアドレスをリンクさせるステップは、
前記セキュアトンネル（Ｓ−２４）として機能する、セキュアサービスエントリポイント（Ｎ−４１）と呼ばれる第１のデバイスと通信するステップ（Ｓ−２６）と、
前記リンクさせるステップを実行する、シングルサインオンサーバ（Ｎ−４２）と呼ばれる第２のデバイスと通信するステップと
を含むことを特徴とする請求項１８に記載の方法。
【請求項２３】
前記ユーザ（Ｎ−１０）がローカルのＨＴＴＰサービス（Ｎ−４４、Ｎ−４５）、または現在アクセスしているサービスネットワーク（Ｎ−４０）とは異なるネットワーク（Ｎ−５０）上の外部サービス（Ｎ−５１）にアクセスしているときに、前記ユーザが既に認証されているか否かをチェックするステップ（Ｎ−４１、Ｓ−３０、Ｎ−４３、Ｓ−２８、Ｎ−４２）をさらに含むことを特徴とする請求項１８に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公表番号】特表２００９−５１４２５６（Ｐ２００９−５１４２５６Ａ）
【公表日】平成２１年４月２日（２００９．４．２）
【国際特許分類】
【出願番号】特願２００６−５１６１８０（Ｐ２００６−５１６１８０）
【出願日】平成１６年６月２３日（２００４．６．２３）
【国際出願番号】ＰＣＴ／ＥＰ２００４／０５１２１７
【国際公開番号】ＷＯ２００５／００２１６５
【国際公開日】平成１７年１月６日（２００５．１．６）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２１年４月２日（２００９．４．２）
【国際特許分類】
【出願日】平成１６年６月２３日（２００４．６．２３）
【国際出願番号】ＰＣＴ／ＥＰ２００４／０５１２１７
【国際公開番号】ＷＯ２００５／００２１６５
【国際公開日】平成１７年１月６日（２００５．１．６）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]