JP2008506139A - ユーザ認証及びサービス承認を管理し、シングル・サイン・オンを実現して、複数のネットワーク・インタフェースにアクセスするためのシステム及び方法 - Google Patents

Abstract

【課題】複数のドメインに存在する複数のネットワークにアクセスするためのシングル・サイン・オンを可能にする。
【解決手段】シングル・サイン・オンの特徴は、特に、異なるネットワーク管轄ドメイン間で行われる認証及び承認のプロセスであり、エンド・サービスを利用する端末は、新しいサービスにアクセスするたびに認証プロセスを明示的に始める必要がない。また、本発明のシングル・サイン・オンの特徴は、連携ドメイン環境と非連携ドメイン環境とにおける使用に拡張可能である。非連携ドメインは、本発明を用いるために、他のドメインを介して間接な連携チェーンを形成できる。また、訪問ドメインが認証を行うことを可能にするユーザ資格の管理に関しても、本発明の適用が可能である。
【選択図】図１

Description

本発明は、データ通信ネットワークの分野に適用され、特に、より単純なクロスドメイン・サービスを提供するための移動通信ネットワークにおけるアクセス制御に関する。通常、ユーザは、異なる管轄ドメインの異なるネットワークによって提供されるサービスにアクセスするために、複数のログインを行う必要がある。本発明は、直接的に又は間接的に連携した複数のドメイン環境のユーザが、すべてのネットワークによって提供されるサービスにシングル・サイン・オンでアクセスすることを可能にする。また、この特徴が提供されることにより、本発明は、ユーザが、任意のときに同一サービスを提供するネットワークへの切り換えを容易に行えるようにする高速ハンドオーバに使用可能である。本発明は、特に、マルチモード端末が許容される環境において、シングル・ログイン・プロセスによって、すべてのネットワーク・インタフェースを介したユーザ・アクセス・サービスを可能にするという点で有用である。

今日の世界におけるビジネスと消費者のネットワーク・アイデンティティの管理に関する非効率性と複雑さとに対処するために、ユーザの個人情報のすべてを集中して保存せずに、ユーザが、アカウント間でユーザの識別要素をリンクできるようにする連携したネットワーク・アイデンティティ・インフラストラクチャに対する強いニーズがある。現在、モバイル・コンピューティング技術によれば、ユーザ端末は、ユーザ端末のホーム・ドメイン内のアクセス・サービスに限定せずに、ユーザ端末のホーム・ドメイン外のサービスにアクセスすることが可能となっている。したがって、複数のドメイン・アクセスは、ユーザ端末が、複数のネットワーク・プロバイダに加入するものであり、このとき、ユーザが複数の加入情報を維持することは非常に厄介となる。シングル・サイン・オンの特徴によれば、ユーザは１つの識別情報だけ保持すればよく、他の外部ドメインが提供するサービスを明示的に登録する必要がないので、特に、絶えず動きながら、任意のときに任意の場所でモバイルサービスにアクセスする必要のあるユーザにとっては非常に魅力的である。

従来、シングル・サイン・オンの特徴は、暗号化キーの管理に重点を置くパスワード管理技術によって提供される（下記の特許文献１、２参照）。このような従来のアプリケーションとしては、現在、ケルベロスが存在する。ケルベロスは、秘密キーによる暗号化を用いて、クライアント／サーバ・アプリケーションに強固な認証を提供するようにデザインされたネットワーク認証プロトコルである。ケルベロス・プロトコルは強固な暗号化を利用しているので、クライアントは、あるサーバへの識別情報を探すとともに、逆に、安全ではないネットワーク接続を横断して、サーバもその識別情報を探すことができる。ケルベロスは、オープン・ネットワーク環境のシングル・サイン・オンと認証の双方に適したプラットフォームを提供できる。Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）２０００オペレーティング・システムは、シングル・サイン・オン用のケルベロスを用いるシステムの一例である。しかしながら、このシングル・サイン・オン・サービスは、オペレーティング・システムより高いレイヤのアプリケーション用のサポートを提供するだけである。複数のネットワーク・インタフェース及び複数のドメイン用のシングル・サイン・オンのサポートは、まだ提供されていない。

連携したネットワーク・アイデンティティ・インフラストラクチャを提供してシングル・サイン・オン・サービスを提供する将来に向けた研究は、現在、他にも数多く存在している。このような研究の１つとして、リバティ・アライアンス・プロジェクトがあり、複数のサービス・プロバイダからの認証及び承認の分散化を提供することに重点を置いている。リバティ・アライアンス・プロジェクトで言及されているサービス・プロバイダは、ユーザにウェブ・ベースのサービスを提供する組織である。しかしながら、複数のネットワーク・アクセス技術のためのシングル・サイン・オンに関しては、リバティ・アライアンス・プロジェクトでは言及されていない。

別のこのような研究として、シボレス・プロジェクトが存在している。このシボレス・プロジェクトは、アクセス・コントロールの決定に使用できる相互動作可能な認証情報を確実に交換することに重点を置いている。シボレス・プロジェクトは、アクセス・コントロールを条件とした機関同士のコンテンツの共有をサポートするフレームワークの構築を意図している。しかしながら、リバティ・アライアンス・プロジェクトと同様に、シボレス・プロジェクトでは、複数のネットワーク・アクセス技術のためのシングル・サイン・オンに関する言及はなされていない。

リバティ・アライアンス・プロジェクトとシボレス・プロジェクトは、シングル・サイン・オンを実現するために、アサーションクエリを生成するセキュリティアサーションマークアップ言語（ＳＡＭＬ）を活用している。

連携されたネットワーク・アイデンティティ・インフラストラクチャには、次に示すように多くの利点がある。
・個人化、セキュリティ、識別情報のコントロールの新たなレベルの提供だけではなく、さらに満足できるオンラインの体験をエンド・ユーザに提供する。
・サービス・プロバイダがリソースをより簡単に提供することを可能にするとともに、適切なリソースに対するアクセスを可能にする。
・新しい相互関係を構築するとともに、迅速、かつ確実に低コストでビジネス目標を実現するビジネスを可能にする。

したがって、複数のドメインにわたる単一ネットワークのアクセス管理は、アクセス権利情報を信頼ドメインに配布することを可能にし、信頼ドメインがアクセス管理ジョブの一部を行うことを認めることにより、認証及び承認のプロセスを単純にするものである。さらに、異なるネットワーク技術にアクセスするためのシングル・サイン・オンの特徴は、異なるネットワーク技術上で動作する異なるデバイスに接続する必要があるマルチモード端末にとって、特に有用である。この特徴により、マルチモード端末は、異なる基本的なネットワークを経由して接続するデバイスにアクセスするたびに、異なるネットワークにアクセスするための複数のサイン・オンを行う必要がない。しかしながら、シングル・サイン・オンに係る現在の技術は、アプリケーション・リソースにアクセスする際の課題について言及しているが、基本となるネットワーク技術にアクセスするための認証及び承認をサポートする機能に欠けている。
米国特許第６２４３８１６号公報 米国特許第５６８４９５０号公報

新しいネットワークにアクセスするために、ユーザは、再度、認証及び承認のプロセスを行うことが要求される。これらの２つのプロセスでは、通常、端末とネットワークとの間で数回のメッセージ交換が行われる。そのため、遅延が生じ、特にユーザがそのホーム・ドメインから離れている外部ドメインに存在する場合には、遅延は大きくなる。あるリアルタイム・アプリケーションでは、この種の遅延は、ハンドオーバ・プロセスで受け入れられないことも考えられる。したがって、サービス・アクセスのためにユーザを承認するためのより迅速な方法が必要になる。特に、連携した複数のドメイン環境では、ネットワークには既に信頼関係があるので、遅延を少なくする方法が必要であり、端末にネットワークのそれぞれにおいて認証を行うように依頼することは、最初の場所で連携を設定するという趣旨を損ねることになる。

現在のモバイル・コンピューティング環境では、ますます多くの端末が、例えば、ワイヤレスＬＡＮカード及びＧＰＲＳインタフェースを搭載するなど、複数のアクセスの機能を搭載するようになってきている。これらのタイプの端末では、複数のネットワークに同時にアクセスすることが要望され、端末が、インタフェースのそれぞれにおいてログインを行うことは無意味である。すべてのインタフェースに対するアクセスを可能にする統合された認証プロセスが、まさに端末に要求されるものである。

昨今、モバイル・ネットワークでは、モバイル・ネットワーク同士のローミング構成が複雑になってきている。また、ネットワーク・ドメインの連携が、メッシュを構築することも考えられる。例えば、ドメインＡはドメインＢとＣとの連携を持ち、ドメインＢとＣは共にドメインＤと連携を持つことにより、ドメインＡはドメインＤに間接的にリンクされる。このとき、ドメインＡは、それが別のドメインと間接的にリンクしているかどうかを発見する方法に係る問題に直面し、簡潔なドメイン発見方法が要求される。

前述の問題点を解決するために、連携を形成するネットワーク・ドメインは、あらかじめ定められたインタフェースとプロトコルとに関する同意を行い、端末からの認証及び承認のリクエストを協力して処理する必要がある。連携したドメインは、ユーザ端末に関与するネットワークに向けてユーザ承認情報を伝搬するので、後のアクセス制御で用いられる時間は短縮されることになる。

ユーザ端末が認証をリクエストするたびに、連携したネットワーク・ドメインの１つが、アンカ・ポイントとして取り出される。このドメインは、リクエストを処理するとともに、端末のホーム・ドメインと通信を行ってサービスを承認する。端末に対して、仮の証明書、ユーザ・トークンが、アンカ・ポイントとして機能するドメインによって発行された後、端末は、仮の証明書を用いて連携したドメインが提供する任意のサービスにアクセスすることが可能となる。サービスを提供するローカル・ネットワークは、そのホーム・ドメインよりも端末の近くに位置するアンカ・ポイントのドメインで証明書をチェックする必要があるだけである。これにより、アクセス・プロセスは単純化され迅速に行われる。ユーザは、その資格を一度だけ提示、すなわち、シングル・サイン・オンのみを実施して、異なるドメインの複数のサービスにアクセスすることが可能となる。それは、サービスリクエストごとにユーザ識別情報を複数回提示しなければならない可能性を大幅に低減させ、優れたセキュリティ機能を提供することになる。

また、トークンをユーザに発行することにより、ネットワークに特有のサービスコントロール情報をネットワーク間で伝搬する必要がなくなる。ネットワークは、新しいサービスをドメイン連携ユーザに対して容易に紹介でき、ローカル・ネットワークは、連携に対して定められたポリシーに基づいて、サービスの提供を決定することができる。

直接連携していないドメインに対して、連携チェーンで互いを発見することが、アクセス・コントロール時には重要である。この問題を解決するために、端末と接続されるローカル・ドメインは、所定のインタフェースを経由して直接連携するすべてのドメインに、クエリメッセージを送り出す必要がある。メッセージを受け取るすべてのドメインは協力をして、前述のローカル・ドメインに対して、自らがホーム・ドメインと直接連携しているか否かを明らかにすることにより、間接的に連携したドメインも、シングル・サイン・オン・サービスをユーザに提供することが可能となる。このような探索は、最初のユーザがホーム・ドメインと直接連携していないローカル・ドメインに入る場合にのみ生じるものである。最初のユーザと同一のホーム・ドメインに属するその後のユーザに対しては、探索プロセスで識別されたパスが再び用いられる。したがって、探索に起因するオーバヘッドは、システム全体のパフォーマンス特性に影響を与えるものではない。

＜発明の作用＞
端末が、例えば、ＵＭＴＳネットワークなどのドメイン連携に入ると、まず、通常の認証プロセスが行われ、ユーザ資格がローカル・ドメインの認証コントローラに提供される。認証コントローラは、このユーザ資格と関連した従来のトークンがあるかどうかをチェックし、何も存在しない場合には、端末のホーム・ドメインに存在するアクセス・コントロール・オーソリティの呼び出しを行う。ホーム・ドメインのアクセス・コントロール・オーソリティは、このリクエストを認証して、ローカル・ドメインの認証コントローラにアサーションによって回答する。このアサーションには、このローカル・ドメインに認可されたサービスを示す加入ケーパビリティ情報が含まれている。

アサーションを受け取ると、認証コントローラは、そのユーザ用のユーザ・トークンの発行に関して、関連する承認コントローラに問い合わせを行うとともに、更なる使用のためにケーパビリティ情報の格納も行う。ユーザ・トークンが取得可能になると、ユーザ・トークンはユーザ端末に送られ、このトークンにより、ユーザ端末は、ドメイン連携におけるすべてのネットワークのサービスにアクセスすることが可能となる。

端末がサービスにアクセスする必要がある場合には、端末は、いつでもネットワークに対して、リクエストと共にトークンの提供を行う。ネットワークは、発行者である承認コントローラによってトークンを検証する。トークンが有効で、ケーパビリティ情報がサービスリクエストに対するアクセスを認可するものである場合には、ネットワークはサービスを直ちに提供できる。

また、新しいサービスがネットワークに導入されたが、ケーパビリティ情報内に含まれていない場合には、トークン発行者は、ホーム・ドメインのアクセス・コントロール・オーソリティに問い合わせを行う。アクセス・コントロール・オーソリティは、連携ポリシーとユーザの加入情報とに基づいて、ユーザに対してサービスが認可されるかどうかを決定する。そして、更新されたケーパビリティ情報が、回答としてトークン発行者に送られ、トークン発行者において、次のサービスリクエストが直接認可可能となる。

本発明によれば、端末が、異なるネットワーク・ドメインが提供する種々のネットワーク・サービスにアクセスする場合におけるシングル・サイン・オンの特徴を生かすことが可能となる。サービス・プロバイダは、連携を形成して、この連携の任意のドメインに加入したユーザにサービスを提供でき、ネットワークリソースの共有を可能とするとともに、別のネットワークにローミングするユーザに簡単にアクセスすることが可能となる。ユーザは、一度だけネットワーク・ドメインに登録又はサイン・インする必要があるだけであり、これを行えば、ユーザ（彼／彼女）は、前述のドメインと連携関係を有するサービス・プロバイダ又はネットワークが提供するサービスを楽しむことができる。また、本発明では、認証を実施する一方、複数の加入を管理することも可能である。アフィリエイトドメインは、ユーザに“チャレンジ”を発行する前に、自らの内部で、ユーザ認証のステータスをチェックして確認でき、アクセス制御のための処理オーバヘッドを軽減させるとともに、同一ユーザに対してネットワーク間の迅速なハンドオーバを容易にする。

また、本発明は、ユーザにシングル・サイン・オン・サービスを提供する。これによって、端末は、複数のセッション始動を行わずに済むようになり、より下位レイヤに適用される場合には、ネットワーク・インタフェース間の切り換えも簡単に実現できる。また、これによって、ユーザが、アクティブなセッション中に低コストのネットワーク・インタフェースに切り換えることも可能となる。例えば、ＵＭＴＳネットワーク及びＷＬＡＮネットワークの両方のネットワークが本発明の構成を有する場合には、ＵＭＴＳネットワークを用いる音声の会話中に、端末が、セッションを再開することなく、ＷＬＡＮネットワークへの切り換えを行うオプションを有することになる。

また、本発明の構成によれば、ドメインは、直接連携していないドメインにも関係を拡大することが可能である。本発明の探索メカニズムを用いると、ドメインは、連携チェーンを動的に形成して、シングル・サイン・オン・サービスを広範囲のユーザに提供することが可能となる。

ここでは、ユーザ認証とサービス承認とを管理して、シングル・サイン・オンを実現し、複数のネットワーク・インタフェースにアクセスするシステムが開示されている。本発明の理解を助けるために、下記の用語が定義されている。
“ＷＬＡＮ”は、ワイヤレス・ローカル・エリア・ネットワークを意味する。ＷＬＡＮには、ワイヤレス技術を介して移動端末にＬＡＮサービスを提供するために、任意の数のデバイスが含まれている。
“３Ｇネットワーク”は、第３世代のパブリック・アクセス・ネットワークを意味する。一例としては、３ＧＰＰ又は３ＧＰＰ２で定義されたシステムが挙げられる。
“移動端末又はＭＴ”は、ＷＬＡＮや他のワイヤレス技術を介した他のネットワークによって提供されるサービスにアクセスするために用いられるデバイスを意味する。
“ホーム・ドメイン”は、相互接続のシナリオにおいて、ＭＴが本来由来しているネットワークを意味する。ホーム・ドメインは、ＭＴのサービス加入情報が保存されている場所である。
“訪問ドメイン”は、ＭＴが接続されるネットワークを意味する。訪問ドメインは、移動端末にアクセス・サービスを提供するネットワークである。
“ＱｏＳ”は、データ・ストリーム又はトラフィックのサービス品質（Quality of Service）という用語を意味する。
“メッセージ”は、相互接続の制御のためにネットワーク要素間で交換される情報を意味する。
“上位層”は、現在のエンティティから渡されたパケットを処理する、現在のエンティティの上位の任意のエンティティを意味する。
“ＡＡＡ”は、移動端末にサービスを提供する際に伴う認証、承認、アカウンティングの機能を意味する。
“ＡＡ”は、移動端末にサービスを提供する際に伴う認証、承認の機能を意味する。
“ＡＡＡサーバ”は、ホーム・ドメインに常駐するＡＡＡサービス・プロバイダを意味する。ＡＡＡサーバは、ホーム・ドメインにおけるアクセス・コントロール・オーソリティの一例である。
“ＡＡコントローラ”は、訪問ドメインに提供されるＡＡサービスのコントローラを意味する。
“連携ドメイン”は、信頼関係によって連携（federation）又は連合（alliance）を形成するいくつかのネットワーク・サービス・プロバイダを意味する。
“グローバル認証”は、“連携”ネットワークによって提供されるすべての他のネットワーク・サービスにユーザがアクセスすることを可能にする、あるネットワークに対する認証を意味する。
“訪問ドメイン１”は、ホーム・ドメインと連携している訪問ドメインを意味する。
“訪問ドメイン２”は、ホーム・ドメインと連携していない訪問ドメインを意味する。

以降、説明のために、特定の番号、時間、構造、プロトコル名や、その他のパラメータが、本発明を十分に理解可能とするために設定されている。しかし、本発明は、これらの特定の詳細がなくても実施できることは当業者には自明のことである。なお、本発明を不必要に不明瞭としないために、周知のコンポーネントやモジュールがブロック図で図示されることもある。

＜第１の実施の形態＞
図１には、連携ネットワーク・サービス環境でグローバル認証を実現する、本発明の実施の形態が図示されている。なお、類似の認証アーキテクチャを持つ任意のサービスに本発明を適用できることは、当業者には自明のことである。

各端末（１．３）は、そのホーム・ドメイン（１．１）内に、固有のユーザ識別情報を有している。この識別情報は、グローバルに一意であり、また、ホーム・ドメインの情報を含んでいる。この識別情報は、ユーザがドメインと協定関係にある場合に、ユーザに配布されるものである。例えば、ユーザがあるオペレータに加入する場合、この識別情報は、ユーザに与えられたＳＩＭ／ＵＳＩＭカード内に記録される。ユーザは、ホーム・ドメインに認証させる必要がある場合に、例えば、ハンドセットや、ＳＩＭリーダを有するラップトップなどの異なるデバイスとすることが可能である。また、ユーザは、いくつかのデバイスを用いて同時認証も実施できる。したがって、ユーザの認証セッションを一意に識別するためには、別の認証セッション識別情報が、認証手順で作成されて用いられる。新しい識別情報は、ホーム・ドメイン用のユーザ識別情報と、ノード識別子と、インタフェース識別子とを含んでいる。この認証セッション識別子が用いられることによって、同一ユーザの同時認証手順が、明確に区別される。

端末（１．３）は、明示的な又は暗示的なログインを実施できるログイン・コンポーネントを有している。そのログイン・コンポーネントは、認証用のユーザ資格を提供するだけで明示的なログインを実施する。明示的ログインの戻り値は、“認証成功”又はエラー・コードを持つ“認証失敗”である。また、暗示的ログインが行われる場合には、ユーザ資格及びリクエストされるサービスの両方が送り出される必要がある。暗示的ログインの戻り値は、“承認成功”又はエラー・コードを持つ“承認失敗”である。“承認成功”は、成功した認証も意味している。

端末（１．３）が、例えば、ＷＬＡＮアクセス・ポイントになり得るアクセス・ポイント（１．４）と接続する場合に、認証プロセスが自動的に開始される。端末に対してサービスを行うＷＬＡＮアクセス・ポイント（ＡＰ１）（１．４）は、ＡＡコントローラ（１．６）に接続されている。ＡＡコントローラ（１．６）は、認証コントローラと承認コントローラとを備えている。なお、アクセス・ポイント（１．４、１．５）は、端末（１．３）の接続のデータ・パス（１．４ｂ、１．５ｂ）上に存在しても存在していなくてもよい。また、認証コントローラ及び承認コントローラは、統合されたエンティティでもよく、２つのエンティティに分かれていてもよい。このとき、認証コントローラはユーザ識別情報を処理する一方、承認コントローラは認可制御の役割と端末に対するリソースへのアクセス承認の役割とを担っている。

ローカル・オーソライザ（１．４ａ、１．５ａ）は、アクセス・ポイント（１．４、１．５）、又は端末（１．３）に対するデータ接続を直接制御する何らかの場所にあることが想定される。ローカル・オーソライザ（１．４ａ、１．５ａ）は、端末（１．３）からの認証リクエストを訪問ドメイン（１．２）のＡＡコントローラ（１．６）に転送する。ローカル・オーソライザ（１．４ａ、１．５ａ）は、ＡＡコントローラ（１．６）のアドレスを備えている。また、ローカル・オーソライザ（１．４ａ、１．５ａ）は、ブートストラップやＤＨＣＰやＤＮＳなどのような方法を介して、動的にＡＡコントローラ（１．６）のアドレスを取得することも可能である。ＡＡコントローラ（１．６）は、執行者（enforcer）であり、ローカル・オーソライザ（１．４ａ、１．５ａ）にポートの開閉や他のリソースの割当／解除を指令する。また、ＡＡコントローラ（１．６）は、リソースも供給し、どの程度のリソースを各端末に供給すべきかについての決定を行う。ローカル・オーソライザ（１．４ａ、１．５ａ）は、承認コントローラからの指令を実行する。なお、後の論述のため、ＡＡコントローラ（１．６）との端末信号通信はローカル・オーソライザ（１．４ａ、１．５ａ）によって認識可能であると仮定する。ＡＡコントローラ（１．６）は、その管轄ドメイン内で複数のローカル・オーソライザ（１．４ａ、１．５ａ）に対して指令を行う。

ホーム・ドメイン（１．１）には、対応するＡＡＡサーバ（１．７）が存在し、このＡＡＡサーバ（１．７）は、認証コントローラと承認コントローラとを具備している。ホーム・ドメインのＡＡＡサーバ（１．７）は、本発明のフレームワーク（１．９）を利用して、訪問ドメイン（１．２）のＡＡコントローラ（１．６）との通信を行う。ホーム・ドメインのＡＡＡサーバ（１．７）は、中心となるデータベースに存在する、ユーザのサービス・レベル規約とユーザ加入情報とを得るために、ＳＬＡマネージャ（１．８）として機能するアプリケーション・サーバとインタフェースにより接続する。ＳＬＡマネージャ（１．８）は、中心となるデータベースに保存されている、サービス・レベル規約情報に対するすべてのエンティティ間のインタフェース・ポイントとなる。また、ＳＬＡマネージャ（１．８）が必要な情報の位置を特定できる場合には、分散データベースを使用することも可能である。

図２には、図１で導入されたシステムの利用例が図示されている。なお、単純化のため、この図では、ＳＬＡマネージャ、ローカル・オーソライザ、データ・パスは不図示である。認証コントローラ（１．６ａ）及び承認コントローラ（１．６ｂ）は、異なるネットワーク・インタフェースの認証プロセス及び承認プロセスをそれぞれ制御している。本図では、それらは、異なるコントローラによって行われる異なる役割を示すために分離されている。また、本図では、訪問ドメイン（１．２）のＡＡコントローラ（１．６）が管理している３つのサブシステムが図示されている。３つのサブシステムは、ＵＭＴＳサブシステム（２．１）とＷＬＡＮサブシステム（２．２）とブルートゥース・サブシステム（２．３）である。しかしながら、このフレームワークは、同時に他の種類のサブシステムをサポートするために拡張できることは、当業者には自明のことである。ユーザは、これらのサブシステムのいずれかに接続するための、任意の、又はすべてのネットワーク・アクセス技術を有する端末（１．３）を用いて、これらのインタフェースのうちのいずれかを介して認証プロセスを始動することが可能である。

また、図３には、端末（１．３）に連携ネットワーク・インタフェース・サービス環境を提供する訪問ドメイン（１．２）に関するメッセージ交換シーケンスが図示されている。例えば、同じ近接部内で、３Ｇセルラ・ネットワーク（ＵＭＴＳ）やブルートゥースのような他のサービスがすべて連携しており、かつ、端末が任意のサービスを使用している場合には、端末は初回に認証されるだけでよい。このフレームワークによって、連携認証ネットワーク技術環境のためのシングル・サイン・オンを特徴とする手段が提供される。

本実施の形態では、端末（１．３）がＷＬＡＮサブシステム（ＷＬＡＮインタフェース）（２．２）を介して訪問ドメイン（１．２）と最初に接続する場合に、端末（１．３）は、訪問ドメイン（１．２）の認証コントローラ（１．６ａ）に対して、その資格をログイン・メッセージ（３．１）に埋め込んで提示する。認証コントローラ（１．６ａ）は、ログインリクエストメッセージを解析して、ユーザ資格を含んでいる資格タグ（credentials tag）を抽出する。ユーザ資格は暗号化されており、訪問ドメイン（１．２）の認証コントローラ（１．６ａ）が読むことはできない。訪問ドメイン（１．２）の認証コントローラ（１．６ａ）に見える情報は、ユーザのホーム・ドメイン（１．１）情報である。訪問ドメイン（１．２）の認証コントローラに対する端末（１．３）からのメッセージ・フォーマットの一例が、フォーマット１として図９に図示されている。

メッセージ・フォーマットはＸＭＬである。ユーザ識別子は、ホーム・ドメイン情報とユーザ資格とを有している。資格に係る要素全体は暗号化されるが、ホーム・ドメイン情報は読み取り可能な状態にある。なお、暗号化方法に関しては前述のフォーマット１には示されていない。また、暗号アルゴリズムは、ユーザとそのホーム・ドメインとの間で交渉される。この情報としては、ユーザ加入時にＳＩＭ／ＵＳＩＭカードに格納される情報が使用可能であり、また、ホーム・ドメインとの接続が確立された後に、ダウンロード可能なモジュールを介して更新できるようにすることも可能である。また、端末とネットワークの相互認証が望まれる場合には、資格の部分にチャレンジ又は回答情報が含まれるようにすることも可能である。

訪問ドメインの認証コントローラ（１．６ａ）は、“Home_domain_info”の情報を用いて、ホーム・ドメイン（１．１）のＡＡＡサーバ（１．７）と相互に作用する。認証コントローラ（１．６ａ）は、オリジナルのログインリクエストメッセージを抽出し、それを“認証アサーションクエリ”に再びパッケージする。これにより、“暗号化されたユーザ資格”が“認証アサーションクエリ”に埋め込まれる。前述の“認証アサーションクエリ”はホーム・ドメイン（１．１）のＡＡＡサーバ（１．７）に転送される（３．２）。例えば、発行者タグ（issuer tag）が訪問ドメインの情報となる。“認証アサーションクエリ”メッセージ・フォーマットの一例が、フォーマット２として図１０に図示されている。

ＡＡＡサーバ（１．７）は、“認証アサーションクエリ”メッセージを受け取ると、メッセージを解析し、資格がそのパブリック・キーで暗号化されている場合に、ある事前設定済みのセキュリティ協定、例えば、そのプライベート・キーを用いてユーザ資格を復号する。そして、その加入プロファイル・データベースに対するユーザ資格のチェックを行い、ユーザを認証する。ユーザ加入プロファイルは、ユーザ識別情報、その個人的な情報、その使用が認められているサービス、サービス・サポート・レベルの品質などを含んでおり、さらに、ドメイン連携の要請に従って適用されるべき、あるポリシー情報も含んでいる。連携ポリシーには、オペレータ構成、例えば、ドメイン間のサービス・サポート・レベル、連携ドメインが加入者の承認に関して認められているサービスの数などが含まれている。

認証コントローラ（１．６ａ）に対するＡＡＡサーバ（１．７）からの回答が、アサーション成功又はアサーション失敗になるものとする。アサーション成功は“加入ケーパビリティ”（３．３）に関する情報と共に返送され、ＡＡＡサーバ（１．７）において、加入ケーパビリティ情報は後の使用のためにデータベースに保存される（３．４）。各加入ケーパビリティは、リクエストを発する端末（１．３）と“認証アサーションクエリ”を発行する訪問ドメイン（１．２）を示す固有の識別子を有している。“加入ケーパビリティ”情報は、ホーム・ドメイン（１．１）との連携又は連合を形成する訪問ドメイン（１．２）を意図しているだけであり、この訪問ドメイン（１．２）はホーム・ドメイン（１．１）からは “信頼”サイトになることを意味している。訪問ドメイン（１．２）の承認コントローラ（１．６ｂ）は、“加入ケーパビリティ”情報を検討して、端末に提示すべきサービス・タイプ、サービス属性、サービスの品質の決定を行う。

訪問ドメインの認証コントローラ（１．６ａ）は、“アサーション成功”回答を受け取ると、ケーパビリティ情報を抽出してデータベースに保存する（３．４）。前述の加入ケーパビリティは、タグで記された有効期間を有している。有効期間は、訪問ドメイン（１．２）がユーザ・アカウントに対して請求を行うことができる期間のブロックである。承認コントローラ（１．６ｂ）は、“アサーション成功”（３．５）について認証コントローラ（１．６ａ）から通知を受け、認証コントローラ（１．６ａ）に送り返される（３．７）ユーザ・トークンを生成（発行）する（３．６）。そして、認証コントローラ（１．６ａ）は、ユーザ・トークンを端末（１．３）に送り返し（３．８）、端末（１．３）は、後のリソースリクエストに備えて、このユーザ・トークンをローカル・データベースに保存する。

前述のトークンのフォーマットは、“加入ケーパビリティｉｄ”を格納する“token_info”フィールドを具備する。“token_info”フィールド全体は、トークン・メッセージ内で暗号化されており、トークン発行者だけが、加入ケーパビリティｉｄを含んでいる“token_info”フィールドを解釈することができる。また、ユーザ・トークンには、開始時間と終了時間、トークン発行者のアドレスも有しており、トークン発行者だけが、 “加入ケーパビリティｉｄ”を復号するキーを有しており、セキュリティがより高くなるようになっている。端末で必要なことは、後で行う任意のリクエストのために、ユーザ・トークンをオリジナルのフォーマットで送り返すことだけであり、このメッセージ・フォーマットのために、加入ケーパビリティｉｄに関する“token_info”タグを含む情報が暗号化されている。

その他のタグはすべて暗号化されていない。ユーザ・トークンのフォーマットの一例が、フォーマット３として図１１に図示されている。

悪意のあるエンティティがトークンを使用することを防ぐために、あるセキュリティ・メカニズムと共に、このフォーマットが使用されることが望ましい。ユーザ・トークンを保護する一例は、トークン発行者が、初期乱数をトークンと共に提供することである。この乱数は、トークンを用いるためのシーケンス・ナンバーとして機能する。ユーザは、トークンを送り出す必要があるたびに、ある暗号化方法を用いて、乱数及びそれ自体の資格に基づくセキュリティ・コードを作成する。例えば、ユーザは、資格とリンクしたそのセキュリティ協定に初期乱数を追記して、固有のナンバーを生成する。セキュリティ・コードは、ハッシュ関数、例えば、ＭＤ５を前述の固有のナンバーに適用することによって生成可能である。なお、ユーザとトークン発行者との間で事前に同意されていれば、他の任意の暗号化方法を使用できることは、当業者には自明のことである。また、トークン内にあるフィールドを設けて、ユーザに対して、セキュリティ・コード生成のために用いるアルゴリズムを示すことも可能である。さらに、このフィールドにアルゴリズムのリストを含めることも可能である。ユーザは、コード生成のために、任意のアルゴリズムをリストから取り出して、トークン発行者に送られるリクエストにおいて、選択されたアルゴリズムを指示することが可能である。

セキュリティ・コードは、検証のために、ネットワークに対してユーザ・トークンと共に送られる。トークン発行者は、認証アサーションで取得したものと同一アルゴリズム及び同一の情報を用いて、検証コードを作成する。そして、検証コードと一致するセキュリティ・コードを有するトークンだけが、トークン発行者によって有効であるとみなされる。リプレイ・アタックを回避するためには、ユーザ及びトークン発行者は、サービスリクエストの成功のたびに、事前に同意済みの方法に基づいて乱数を変更することができる。例えば、ユーザ及びトークン発行者は、トークンと共に初期に取得した前述のセキュリティ協定の最後の４ビットだけ初期乱数をインクリメントすることが可能である。

別の代替方式は、端末のホーム・ドメインが、セキュリティ検証コードのベクトルと、認証アサーション回答に埋め込まれている加入ケーパビリティ情報内の対応する初期乱数とを提供することである。トークン発行者は、前述のように、トークンと共に乱数を送り、セキュリティ・ベクトルからの検証コードを用いて、ユーザ・トークンを有効にする。このオプションは、アルゴリズムがホーム・ドメイン及び端末にしか分からないという点が長所である。また、更新も容易であり、トークン発行者に対して、あまり多くのことを要求しない。

端末（１．３）は、有効ユーザ・トークンを持つと、承認コントローラ（１．６ｂ）に対して直接、リソース承認に関する問い合わせを行う（３．９）。承認コントローラ（１．６ｂ）は、ユーザ・トークンの“加入ケーパビリティｉｄ”を復号して、それを以前に取得した加入ケーパビリティと比較する。ケーパビリティが端末（１．３）のリクエストに対して承認を与えるものである場合には、承認コントローラ（１．６ａ）は、それに応じたリソースの割り当てを行い（３．１０）、端末（１．３）への回答を行う（３．１１）。また、ホーム・ドメイン（１．１）のＡＡＡサーバ（１．７）からの回答が“アサーション失敗”である場合には、“失敗コード”が“アサーション失敗”メッセージに付記されて、前述の端末（１．３）に送り返される必要がある。

訪問ドメイン（１．２）の認証コントローラ（１．６ａ）とホーム・ドメイン（１．１）のＡＡＡサーバ（１．７）との間でやり取りされるメッセージは、セキュア・チャンネルを介しており、例えば、ＳＳＬ／ＴＬＳ、ＩＰｓｅｃなどのようなセキュリティ・メカニズムを用いて、必要なトランスポートレイヤのセキュリティが提供可能である。認証に成功しない場合に、ユーザには、その試みが成功しなかったことが通知される。これには、“失敗コード”に由来する表示可能のメッセージ、又は所定の事前に構成されたメッセージの使用が可能であり、ユーザに対して、例えば、別のホーム・ドメインで認証を試みるように依頼が行われる。

図４には、明示的な承認段階中に行われたメッセージのシーケンスが示されている。端末（１．３）が訪問ドメイン（１．２）に対して新しいサービスをリクエストした場合、例えば、端末（１．３）がブルートゥース・サブシステム（ブルートゥース・インタフェース）（２．３）を介して接続するプリント・サービスの使用をリクエストした場合には、端末（１．３）は、初期認証段階中に取得したユーザ・トークンが埋め込まれた承認リクエストを開始する。ここでは、端末（１．３）が、例えば、ＷＬＡＮインタフェース（２．２）などの別のインタフェースを用いて、認証に関する図３の前半部に記載されたステップを行うことが想定される。また、いったん端末（１．３）がユーザ・トークンを持った場合には、異なるネットワーク・インタフェースにアクセスしていても、再び認証段階を行う必要がない。

新しいリクエストは承認コントローラ（１．６ｂ）に対して行われる必要がある。ユーザ・トークンの埋め込まれたリソースリクエストメッセージが承認コントローラ（１．６ｂ）に提示された場合には（４．１）、承認コントローラ（１．６ｂ）はトークンの信頼性を最初にチェックする。承認コントローラ（１．６ｂ）は、別のネットワーク・インタフェースを介しているが、認証段階において自らトークンを生成しているので、トークンの信頼性を検証することが可能である。このトークンの情報に基づいて、承認コントローラ（１．６ｂ）は、データベースに既に保存されている加入ケーパビリティの情報と、リソースリクエストを比較し、ユーザ又は他者に対するアクセスを承認するかどうかを決定する（４．２）。承認リクエストが許可された場合には、訪問ドメイン（１．２）の承認コントローラ（１．６ｂ）は、必要なローカル・リソースの許可をローカル・オーソライザ（１．５ａ）に命じるとともに、リソースが許可されたことを端末（１．３）に回答する（４．３）。一方、そうでない場合は、リクエスト失敗が端末（１．３）に送り返される。

ユーザ・トークンの有効期間を決定して有効にするためには、各トークンに関連付けられた “開始時間”及び“終了時間”が決定される。過剰レベルの保護に対して、訪問ドメイン（１．２）の承認コントローラ（１．６ｂ）は、トークンがタイムリミットに達している場合に、端末（１．３）に対して新しいユーザ・トークンを発行できる。すなわち、トークン満了時には、新しいリクエストに対して再認証プロセスが開始される。また、ユーザが明示的にログアウトした場合には、トークンが取り消され、すなわち、端末（１．３）は、そのトークンを更なる任意のサービスリクエストに使用することはできない。さらに、訪問ドメイン（１．２）の承認コントローラ（１．６ｂ）の加入ケーパビリティが削除される。

図５には、別のシナリオに対するシステム構成の一例が示されている。ここでは、複数の訪問ドメインが存在し、訪問ドメイン（５．１）とホーム・ドメイン（５．８）との間で端点間の連携は存在しないものの、シングル・サイン・オンが実現されている。各訪問ドメイン（５．１、５．４）は、各訪問ドメイン（５．１、５．４）の認証コントローラ（５．２ａ、５．５ａ）及び承認コントローラ（５．２ｂ、５．５ｂ）によって管理されている。図５には、２つの異なる管轄ドメインのみが図示されている。なお、ここで説明する解決方法を複数の訪問ドメインに対しても適用できることは、当業者には自明のことである。訪問ドメイン１（５．４）は、ホーム・ドメイン（５．８）と訪問ドメイン２（５．１）の両方とそれぞれ連携しているドメインである。訪問ドメイン２（５．１）は、訪問ドメイン１（５．４）と連携しているが、ホーム・ドメインとは連携していない。図２に示した構成と同様に、ＡＡコントローラ（５．２、５．５）の認証コントローラ（５．２ａ、５．５ａ）と承認コントローラ（５．２ｂ、５．５ｂ）は、コントロールにおいて異なる役割を担う２つの依存したエンティティである。しかし、実施時には、これら２つのエンティティは、通常は同じデバイスに共存しているので、統合可能である。

図５に示すように、訪問ドメイン１（５．４）はＷＬＡＮ（５．６）と第３世代（３Ｇ）のＵＭＴＳ（５．７）サブシステムとにより構成され、訪問ドメイン２（５．１）は、ブルートゥース・サブシステム（５．３）を含んでいる。なお、これら２つのドメインが他のサブシステムの任意の組み合わせを含むことができることは、当業者には自明のことである。端末（５．１０）は、訪問ドメイン１（５．４）及び訪問ドメイン２（５．１）の両方が提供するネットワーク・インタフェースにアクセスできる。

図５の訪問ドメイン１（５．４）が図２の訪問ドメイン（１．２）として動作する、図３に示すプロセスと同様の認証プロセスによって、端末（５．１０）が、訪問ドメイン１（５．４）を介した認証プロセスを既に行っているものとする。例えば、端末（５．１０）は、訪問ドメイン１（５．４）にＷＬＡＮ（５．６）ネットワーク・インタフェースを介して元々ログオンしており、図３に示したものと同一の認証手順を既に行っている。

端末（５．１０）が、“サード・パーティ”ネットワーク・インタフェースを介したサービスへのアクセスを試みる状況、すなわち、ユーザ・トークンを発行する承認コントローラが制御するドメイン外のネットワーク・インタフェースからリソースをリクエストする状況がある。これは、例えば、端末（５．１０）が、訪問ドメイン２（５．１）が提供するブルートゥース・インタフェース（５．３）を介してプリント・サービスにアクセスを望む状況などである。この場合には、図６に示した手順がトリガされる。

端末（５．１０）は、訪問ドメイン２（５．１）の承認コントローラ２（５．２ｂ）にユーザ・トークン（６．１）が埋め込まれた“リソースリクエスト”メッセージを提示する。また、端末（５．１０）が訪問ドメイン２（５．１）との接続ポイントを１つしか有していない場合には、リソースリクエストは認証コントローラ２（５．２ａ）から転送されることとなる。

ユーザ・トークンは、図３に示すように認証段階の初期に得られている。このトークンには、発行者のアドレスによるタグが付されており、この場合には、訪問ドメイン１（５．４）の承認コントローラ１（５．５ｂ）のアドレスになる。承認コントローラ２（５．２ｂ）は、承認コントローラ１（５．５ｂ）がトークンの発行者であり、共に連合しているので、承認コントローラ１（５．５ｂ）に対して問い合わせを行う（６．２）。

承認コントローラ１（５．５ｂ）は、有効期間とトークンにタグ付けされたｉｄなどをチェックして、トークンの認証について検証する（６．３）。このとき、承認コントローラ１（５．５ｂ）は、端末（５．１０）がリクエストしたサービスの使用を承認されているかどうかを検討（６．３）するために、ホーム・ドメイン（５．８）から初期に取得した加入ケーパビリティによってチェックを行い、承認コントローラ１（５．５ｂ）は、承認のステータスについて承認コントローラ２（５．２ｂ）に回答する。訪問ドメイン１と訪問ドメイン２とは連携しているので、回答は訪問ドメイン２によって信頼される。なお、これら２つのドメイン間のメッセージ交換は、それらの間で交渉された任意のスキームを用いて保証されなければならない。

加入ケーパビリティ情報が、端末（５．１０）に対して、ネットワーク・インタフェースを認可しないものである場合には、承認コントローラ１（５．５ｂ）は、ホーム・ドメイン（５．８）のＡＡＡサーバ（５．９）に“承認アサーションクエリ”のフォーマットで再認可を発行する（６．４）。図１２には、“承認アサーションクエリ”のフォーマットが、フォーマット４として図示されている。

ＡＡＡサーバ（５．９）は、新しいリクエストをチェックして、端末（５．１０）が特定のネットワーク・インタフェースを用いるための加入情報を有しているかどうかについて回答する（６．５）。“加入ケーパビリティｉｄ”に基づいて、ＡＡＡサーバ（５．９）は、既に発行済みの加入ケーパビリティの位置を突き止めて、ユーザ加入プロファイルを検索する。端末（５．１０）がリクエストされたネットワーク・インタフェースの使用を認められている場合、ＡＡＡサーバ（５．９）は、付加的なケーパビリティが埋め込まれた承認成功による回答を行う。

訪問ドメイン１（５．４）の承認コントローラ１（５．５ｂ）が格納する加入ケーパビリティには、通常、ユーザ加入プロファイル情報全体ではなく、訪問ドメイン１（５．４）が提供するネットワーク・インタフェース・サービスのみが含まれている（６．３）。訪問ドメイン１（５．４）が新しいケーパビリティを受信した場合には、データベースが更新される（６．６）。なお、ステップ６．４〜６．６は、ケーパビリティに関する事前のチェック（６．３）から、端末（５．１０）がネットワーク・インタフェースを使用することを既に認められていることが明らかとなっている場合にはスキップされる。“リソースリクエスト”の結果は、承認コントローラ１（５．５ｂ）から承認コントローラ２（５．２ｂ）に送り返される（６．７）。承認コントローラ２（５．２ｂ）は、この結果に基づいて“リソースリクエスト”に対するアクセスを認可するかどうかを決定するとともに、リソースリクエストのステータスに関する結果を端末（５．１０）に転送する（６．８）。

本発明は、訪問ドメイン２（５．１）がホーム・ドメイン（５．８）と連携している場合に適用可能であり、同一のメッセージ・プロトコルが適用される。

また、本発明は、ホーム・ドメインがトークン発行者である場合にも機能する。このような場合には、後に、ホーム・ドメインと連携している訪問ドメインに対してアクセスするために、同一のメッセージ・プロトコルが適用される。また、認証がホーム・ドメインを経由する場合には、ホーム・ドメインは、端末に対してトークンを発行する。また、端末がホーム・ドメインと連携している訪問ドメインにアクセスを試みる場合には、トークンはトークン発行者（この場合には、ホーム・ドメイン）によって検証される。

本発明は、トークン発行者が連携ドメインに存在する場合や、端末がホーム・ドメインのリソースにアクセスを試みる場合にも適用される。この場合には、端末は、ホーム・ドメインに対して、サービスリクエストを有するユーザ・トークンを提示する。ホーム・ドメインは、ユーザ・トークンを受け取ると、端末のホーム・ドメイン情報を含むユーザ・トークンを解明する。端末のホーム・ドメイン情報がそれ自体である場合には、ホーム・ドメインは、トークン発行者によってユーザ・トークンの信頼性について検証する必要がある。検証に成功した場合には、ホーム・ドメインは、加入ケーパビリティ情報を有するトークン発行者からの承認を取得する代わりに、ユーザ加入プロファイルに従って、サービスの使用を認可する。

図７には、端末（５．１０）が訪問ドメイン２（５．１）にリソースリクエストを発する前に、訪問ドメイン１（５．４）による認証プロセスを完了していなかった場合の、図５のシステム構成に基づく別のシナリオが図示されている。端末（５．１０）が有効なトークンなしにネットワーク・インタフェースへのアクセスを開始する場合には、認証プロセスを行う必要がある。また、端末（５．１０）がアクセスを試みる訪問ドメインが、ホーム・ドメイン（５．８）と連携していない場合には、訪問ドメインは、信頼サイトとみなされないので、“加入ケーパビリティ”情報の内容によって提示されるべきではなく、認証プロセスはやや異なるものとなる。しかしながら、訪問ドメインは、端末（５．１０）のホーム・ドメイン（５．８）との連合を作っている他のネットワークと連合を有していることもあり、何らかの方法によって、ホーム・ドメイン（５．８）との間接的な連合を作ることが可能な場合もある。

このシナリオにおける認証のためのステップが、図７に図示されている。訪問ドメイン１（５．４）は、ホーム・ドメイン（５．８）及び訪問ドメイン２（５．１）の両方と連携しており、訪問ドメイン２（５．１）はホーム・ドメイン（５．８）と連携していない。端末（５．１０）は、暗号化されたユーザ資格を認証コントローラ２（５．２ａ）に提示する（７．１）。訪問ドメイン２（５．１）の認証コントローラ２（５．２ａ）は、ホーム・ドメイン（５．８）のアドレスをチェックして、それがホーム・ドメイン（５．８）と直接連合していないことを見いだす。次いで、探索プロセスが実施され、訪問ドメイン１（５．４）が端末（５．１０）のホーム・ドメイン（５．８）と直接連合していることが見いだされる。

複数のドメインが相互接続されている場合、すなわち、ホーム・ドメイン（５．８）にもアフィリエイトしているアフィリエイトネットワークのリストが存在するなどの場合には、探索プロセスから複数の結果が生じる場合もある。例えば、訪問ドメイン２（５．１）は、ホーム・ドメイン（５．８）と連合している他のドメインに対して接続することもできる。訪問ドメイン２（５．１）は、任意の事前設定済みのポリシーを用いて、リクエストを送るドメインを決定する。例えば、異なるドメインを介する接続によって異なるチャージを示す結果が得られる場合もあり、この場合には、訪問ドメイン２（５．１）は、最低コストのドメインを選ぶべきである。また、ドメインを選ぶ際に、例えば、負荷バランス、領域、物理的又は地理的距離、規制の考慮、又は入手可能な情報のすべてに関して重みが設定された組み合わせなどの他の基準を使用できることが明らかである。別の代替方式として、訪問ドメイン２（５．１）が、使用の可能性のあるすべての訪問ドメインが記載されたメッセージによって端末（５．１０）に回答し、端末（５．１０）に選択を促すことも可能である。探索プロセスは、例えば、すべての接続ドメインに対する単純な問い合わせ、ＤＮＳの調査、又はＭＩＢに対する問い合わせなどの多くの方式によって実施できることは、当業者には自明のことである。

利用するドメイン、例えば、訪問ドメイン１（５．４）を特定した後、認証コントローラ２（５．２ａ）は、ホーム・ネットワーク（５．８）と連合している訪問ドメイン１（５．４）の認証コントローラ１（５．５ａ）に対して“認証及び承認リクエスト”を発する（７．２）。また、認証コントローラ１（５．５ａ）は、“認証アサーションクエリ”をホーム・ドメイン（５．８）のＡＡＡサーバ（５．９）に発する（７．３）。認証アサーションクエリが成功すると、加入ケーパビリティがＡＡＡサーバ（５．９）から認証コントローラ１（５．５ａ）に送られる（７．４）。認証コントローラ１は、認証段階の完了を承認コントローラ１（５．５ｂ）に通知する（７．６）前に、この加入情報をデータベースに保存する（７．５）。また、承認コントローラ１（５．５ａ）は、“加入ケーパビリティ”から、端末（５．１０）が訪問ドメイン２（５．１）が提供するサービスの使用を承認されているかどうかを検討する。認証コントローラ１と承認コントローラ１は共に“加入ケーパビリティ”を保存するデータベースにアクセスできる。なお、実施時には、認証コントローラ１（５．５ａ）、承認コントローラ１（５．５ｂ）、データベースは、同じ場所に配置することも可能であり、物理的に分離することも可能である。

承認コントローラ１（５．５ｂ）は、サービスリクエストに対する加入ケーパビリティのチェックを行う（７．７）。加入ケーパビリティ・メッセージが、端末（５．１０）がアクセスを希望するネットワーク・インタフェースを含んでいない場合には、承認コントローラ１（５．５ｂ）は、端末（５．１０）がサード・パーティ・ネットワークでネットワーク・インタフェースの使用を承認されているかどうかを再検討するように、ＡＡＡサーバ（５．９）に問い合わせる（７．８）。そして、アサーション成功を受け取ると（７．９）、承認コントローラ１（５．５ｂ）は、データベースの新しいケーパビリティを更新して、端末用の新しいユーザ・トークンを生成（発行）する（７．１０）。

加入ケーパビリティ・メッセージに、リクエストを行ったネットワーク端末に関して端末が承認されているという情報が既に含まれている場合には、ステップ７．８及び７．９は行われない。また、ステップ７．１０では、新しいユーザ・トークンの生成のみが行われ、データベースの更新は、この場合には行われない。

端末（５．１０）に対して承認が与えられた場合には、ユーザ・トークンが端末（５．１０）に送り返される必要がある。ユーザ・トークンの生成後、承認コントローラ１（５．５ｂ）は、ユーザ・トークンを認証コントローラ１（５．５ａ）に送り返す（７．１１）。認証コントローラ１（５．５ａ）は、リクエストが成功している場合には、ユーザ・トークンが埋め込まれた“認証及び承認リクエスト”に関して、認証コントローラ２（５．２ａ）に回答する（７．１２）。続いて、認証コントローラ２（５．２ａ）は、リクエストのステータスを承認コントローラ２（５．２ｂ）に通知し（７．１３）、承認コントローラ２（５．２ｂ）は、必要なリソースを割り当てて（７．１４）、認証コントローラ２（５．２ａ）に回答する（７．１５）。認証コントローラ２（５．２ａ）は、そのリクエストのステータスに関して、端末（５．１０）に通知する（７．１６）。新しいネットワーク・インタフェースに対するその後のアクセス及び手順は、図６のものと同一である。

システムの通常の動作とユーザ情報の機密性とを保護するために、セキュリティ保護、例えば、トランスポートレイヤセキュリティ（ＴＬＳ）におけるセキュリティ・ソケット・レイヤ（ＳＳＬ）、ＩＰセキュリティ（ＩＰｓｅｃ）などに基づいて、メッセージがやり取りされる。また、セキュア・トンネリングが、異なるドメインのＡＡコントローラと異なるＡＡＡサーバとの間で、認証及び承認の両方に対してメッセージの交換前に設定されることが想定される。なお、メッセージ交換において、十分なセキュリティ保護が提供されている限り、任意のセキュリティ形態が、このフレームワークに適用できることは、当業者には自明のことである。

例えば、端末は、そのＭＭＳをＵＭＴＳインタフェースを介して受信すると同時に、あるファイルをＷＬＡＮを介してダウンロードするなど、同時に複数の接続を作動させることが可能である。これは、デュアル／マルチモード端末においてのみ可能となる。別のネットワークからより安いレートにアクセスする場合には、端末は代替方式に関する通知を受け、ネットワーク・プロバイダが端末のサービス・プロバイダ・オペレータと同一の連携にあるアフィリエイト状態の場合には、端末は、このような他のネットワーク・プロバイダに登録される必要はない。連携したネットワークは、デバイスがこうしたネットワークの対象エリア内に存在する場合には、極めて狭域のネットワークの形態であってもよい。例えば、封鎖エリアでは、端末がＷＬＡＮサービスに対してログオンしていて、ブルートゥース又は赤外線デバイスの使用を決定する場合に、端末は、異なるサービスにそれぞれログインする必要はない。

図７に示されるステップは１段（single-tier）の連携の発見の場合にのみ実行可能であり、すなわち、ここでは、端末が接続を試みる新しいドメインが、ホーム・ドメインと連携したドメインに直接接続されている。こうした仮定がなされない場合には、多段（multi-tier）の発見を行う必要がある。多段の発見をサポートするために、発見に関して、さらにステップを実施する必要がある。１つの方法としては、徹底的な調査を行うことであるが、ここでは、複数の中間訪問ドメインがプロキシとして機能することが要求される。

図８には、多段のドメイン連携シナリオにおける本発明のシーケンス・ダイアグラムの一例が示されている。図８において、まず、端末（８．１）は “ログイン及びリソースリクエスト”を発し（８．６）、そのユーザ資格を訪問ドメインＡ（８．２）に提供する。なお、訪問ドメインＡ（８．２）は、端末（８．１）がそのリソースにアクセスを所望するドメインである。なお、認証コントローラ及び承認コントローラは、図示を単純にするために、ここでは区別されていない。

訪問ドメインＡ（８．２）は、多段の連携プロセスの検索（ＡＡパスの検索）を開始する（８．７）。検索を行うために可能な方法は、訪問ドメインＡ（８．２）が、特定のホーム・ドメイン情報を含んでいる特別なメッセージを相互接続したすべてのドメインに送ることである。このメッセージにはライフリミットが含まれており、限られた数のドメインを通った後に破棄される。ドメインがこのメッセージを受け取ると、ホーム・ドメイン（８．５）と連携した接続を有しているかどうかのチェックを行う。そして、ホーム・ドメイン（８．５）と連携した接続を有している場合には、このドメインは、訪問ドメインＡ（８．２）に対して、リクエストを転送するように通知を行う。

メッセージを受け取るドメインが、ホーム・ドメイン（８．５）と全く関係を有していない場合には、ローカルポリシーに応じて、メッセージを破棄するか、又は別のドメインに更に転送するかについての決定を行う。メッセージを転送する前に、ドメインは、ドメイン自体の情報をメッセージに付記するので、メッセージは、通過するすべてのドメインに関する情報を運ぶことになる。この情報を用いることによって、循環的な転送を回避することができ、さらに、訪問ドメインＡ（８．２）が後でその情報を使用して、ユーザリクエストを転送する（８．６）ことも可能となる。

例えば、ドメイン名サービス（ＤＮＳ）を用いたり、セントラルサーバに問い合わせたりするなどのパスの検索を行う他の方法が存在することは、当業者には自明のことである。パス検索手順（８．７）では、いくつかの結果が導かれることがある。この場合には、訪問ドメインＡ（８．２）は、あるポリシールールを用いて、どのパスを使用するか、例えば、最も近いもの、最も知られているものなどを決定する。使用するパスを選択する上で可能な方法は、例えば、下記に基づいている。
■リクエストがホーム・ドメインに届く前に通過する必要がある認証コントローラの数
■訪問ドメインと対応する認証コントローラとの間の物理的及び地理的距離
■訪問ドメイン及びノードにアクセスすることによって生じるコスト
■訪問ドメインの負荷状態
■訪問ドメイン及び対応する認証コントローラのサービス・ケーパビリティ
■訪問ドメインで規定された制約
■上述の情報に関して重み付けされた組み合わせ
また、訪問ドメインＡ（８．２）が、関連情報のすべてを含むエラー・メッセージをユーザに戻して、ユーザに所望のパスを選択させることも可能である。

送信パスの特定後、訪問ドメインＡ（８．２）は、“ログイン及びリソースリクエスト”を１つ又は複数の中間訪問ドメイン（８．３）に転送する（８．６）。これは、単にリクエストを次のドメイン・ノードに転送するものである（８．８）。次のドメイン・ノードのパスは、検索及び発見において決まったパスであることが分かっている。パス・テーブルは、転送すべき次のノードを中間ノードが知ることができるように、転送の際に“ログイン及びリソースリクエスト”内に埋め込まれてもよい。

リクエストがホーム・ドメイン（８．５）と直接連携している訪問ドメインＢ（８．４）に最終的に達する（８．９）と、認証及び承認を行うためのステップが行われる（８．１０）。このステップは、図７に示したように、訪問ドメイン１（５．４）とホーム・ドメイン（５．８）との間のメッセージ交換と同様のものとすることができる。“承認回答”が、逆の順序でパス・テーブルを用いてホーム・ドメイン（８．５）から訪問ドメインＡ（８．２）に送り返される（８．１１、８．１２）。訪問ドメインＡ（８．２）は、回答の処理（リソース認証及びリソース割り当て）を行って（８．１３）、その後、端末（８．１）に回答する（８．１４）。連携と同じ概念が、このマルチ・ドメイン連携環境においても適用される。

＜第２の実施の形態＞
ＡＡＡサーバによってリターン・メッセージに埋め込まれる加入ケーパビリティ（３．３、７．４）には、認可されたインタフェース・タイプ情報と、ＡＡＡサーバから訪問ドメインにおける端末に、各インタフェース・タイプに対して認可されたＱｏＳレベル情報とが含まれている。

前述の認可されたインタフェース・タイプ情報には、端末が訪問ドメインで使用を承認されているネットワーク・インタフェース・タイプのリストが含まれている。ＡＡＡサーバは、“認証アサーションクエリ”を開始する訪問ドメインによって提供されるネットワーク・インタフェース・タイプと、ユーザが加入しているネットワーク・インタフェース・タイプとを含ませるにすぎない。例えば、図２のシステム構成の場合、訪問ドメイン（１．２）に返される加入ケーパビリティ情報には“ブルートゥース、ＷＬＡＮ、ＵＭＴＳ”が含まれているが、ユーザは前述の３つのネットワーク・インタフェースに加えてＧＰＲＳにも加入している場合もある。しかしながら、訪問ドメイン（１．２）は、単に３つのネットワーク・インタフェース・サービスを提供するだけなので、このＧＰＲＳは訪問ドメイン（１．２）には分からない。各インタフェース・タイプに関係するＱｏＳレベルも、この加入ケーパビリティ情報に埋め込まれている。

図７のシステム構成の別の例では、訪問ドメイン１（５．４）に返される加入ケーパビリティ・メッセージには、“ＷＬＡＮ及びＵＭＴＳ”のみが含まれる。なお、この場合、訪問ドメイン１（５．４）は、これら２つのネットワーク・インタフェースのみを提供する。端末（５．１０）が別のネットワーク（訪問ドメイン２（５．１））によって提供されるブルートゥース・インタフェース（５．３）へのアクセスを試みる場合には、訪問ドメイン１（５．４）の承認コントローラ１（５．５ｂ）は、ブルートゥース・インタフェース（５．３）に特定した別の“承認アサーションクエリ”を探す。そして、それが承認アサーション成功である場合には、訪問ドメイン２（５．１）は、訪問ドメイン１（５．４）に、端末（５．１０）に対してアクセスを認めるように通知する。

図１３のフォーマット５には、加入ケーパビリティ・メッセージ・フォーマットのフォーマットの一例が示されている。加入ケーパビリティ情報全体は、安全な方式で受取者に配布されるべきであり、例えば、安全なチャンネルを用いて、この情報が配布されることが望ましい。また、チャンネルが安全でない場合には、暗号を用いればセキュリティを提供できる。この加入ケーパビリティは“authentication_assertion_reply（AuthN_assertion_reply）”（３．３、７．４）メッセージに埋め込まれて、“authentication_assertion_query”を発する信頼されるエンティティに対して、ＡＡＡサーバ（１．７、５．９）から送り返される。

また、加入ケーパビリティ情報は、フィリエイトネットワークが“authorisation_assertion_query（AuthZ_assertion_query）”メッセージを発する際に取得することもできる。ＡＡＡサーバ（１．７、５．９）は、この加入ケーパビリティを“authorisation_assertion_reply” （６．５、７．９）に埋め込む。“authorisation_assertion_reply”で戻る加入ケーパビリティ情報は、通常、あるネットワーク・インタフェースリソース上の“authorisation_assertion_query”に応答するものである。

加入ケーパビリティ情報に埋め込まれたセキュリティ・ベクトル・フィールドは、必要に応じて、受信ドメインによるユーザの識別情報の検証を支援するためのものであり、例えば、承認コントローラが、ユーザ・トークンを用いてサービスリクエストの妥当性を検証するために使用可能なものである。セキュリティ・ベクトルは、１つのセキュリティ情報、又はホーム・ドメインが作成した検証コードのリストを含むことができる。

図７を一例として考えてみる。ステップ７．４において、加入ケーパビリティには、図５のシステム構成に関連して、ＷＬＡＮ（５．６）及びＵＭＴＳ（５．７）のインタフェース・タイプが含まれている。これは、訪問ドメイン１（５．４）が２つのネットワーク・インタフェースのみを提供することを、ＡＡＡサーバ（５．９）が、連携ポリシーから把握することによるものである。なお、ユーザが、他のネットワーク技術にアクセスする他のサービスに加入しているかもしれないということとは無関係であり、ユーザ加入情報全体ではなく、アフィリエイト訪問ドメイン（この場合には、訪問ドメイン１（５．４））に対して限られたユーザ加入情報を提示するだけである。

加入ケーパビリティは、図１４のフォーマット６に示されるように、フォーマット５に示されるテンプレート・フォーマットを用いている。

返信されるネットワーク・インタフェースごとに対して、ＱｏＳレベル情報も埋め込まれる。例えば、ＷＬＡＮネットワーク・インタフェースは、値Ａと等しいＱｏＳレベルを有する。値Ａは、最低保証帯域幅、最大送信レート、バースト・レート、ジッタ、最長遅延などのようなＱｏＳ情報のリストを備えている。なお、上述のインタフェース・タイプとそのＱｏＳレベルは図解だけを意図するものである。また、他の種類のネットワーク・インタフェースとＱｏＳレベルも本発明に適用できることは、当業者には自明のことである。

ステップ７．８の場合には、リクエストはブルートゥース・インタフェースにアクセスするためのものである。したがって、承認コントローラ１（５．５ｂ）は、ブルートゥースがＷＬＡＮ及びＵＭＴＳを備えている初期リストには存在しないので、“authorisation_assertion_reply”を発する。したがって、“authorisation_assertion_reply”に埋め込まれた加入ケーパビリティは、ブルートゥース・インタフェースのアサーションだけ含むことになる。この情報は、図１５のフォーマット７に図示するとおりである。

後のＷＬＡＮ又はＵＭＴＳへのアクセスのために、端末（５．１０）のサービス加入情報を既に把握している承認コントローラ１（５．５ｂ）は、端末（５．１０）がＷＬＡＮ又はＵＭＴＳを介して接続する他のサービスにアクセスを試みる場合に、端末（５．１０）に対する承認を認めるべきかどうかについて決定する。

端末が“authentication_assertion_query”を発する訪問ドメインによって提供されるサービスに加入していない場合、加入ケーパビリティには、端末が加入していないサービスは含まれないことになる。すなわち、この好適な実施の形態における加入ケーパビリティは、訪問ドメインによって提供されるネットワーク・サービスと端末が加入するネットワーク・サービスとが結合された情報を有している。

＜第３の実施の形態＞
複数のドメイン・サービスのアクセス時に、ユーザは複数の加入情報を有することが可能である。この場合、ユーザ端末は、特にネットワーク共有用に、複数のホーム・ドメインのシナリオを満たす必要がある。例えば、ユーザのホーム・ドメイン１と連携するドメインは、ＷＬＡＮホットスポットを所有できるが、そのＷＬＡＮホットスポットをユーザのホーム・ドメイン２も共有できる。したがって、ユーザ端末は、認証用の加入情報を選択できなければならない。

これを解決する方法の１つは、例えば、ユーザに与えられたＵＳＩＭカードに保存するなど、ユーザのホーム・ドメインが、関連情報を加入プロファイルの一部としてユーザに提供することである。ユーザ端末は、ホーム・ドメインのリストを保持しており、ユーザ端末がネットワークにアクセスする必要がある場合には、ネットワークに関連したドメイン情報を取得して、ホーム・ドメイン・リスト内の情報との比較を行う。そのホーム・ドメインの１つがネットワークを所有していた場合には、ユーザ端末は、そのドメインからの対応する加入情報を用いて認証を試みる。なお、ユーザ端末は、同じネットワークを共有する複数のホーム・ドメインがある場合には、ホーム・ドメインを選択する際にその選択基準もセットできることは、当業者には自明のことである。基準として、加入情報を用いたネットワークへのアクセス・レート、ドメイン加入情報の容量、ドメインとその連携から取得できるサービス、規制情報、事前設定優先権などがあり、これらの基準に関して重み付けされた組み合わせも使用可能である。ユーザ端末は、これらの基準を用いて、例えば、ローミング・ユーザとしてネットワークにアクセスすることが、更に安くなるなどの、ある事前に設定されたポリシーに応じて、ネットワークを直接所有していないドメインを選択することも可能である。

通常の場合、ユーザ端末のホーム・ドメインがアクセス・ネットワークを所有していないときには、ローカルの訪問ドメインのユーザ認証は、より迅速に行われる。したがって、ホーム・ドメインと連携するとともにユーザ端末の近くに存在するドメインにおける認証コントローラ及び承認コントローラは、例えば、セントラルデータベースなどのホーム・ドメインから、あるユーザ加入情報をダウンロードして、ユーザ認証及びサービス承認をローカルに実施することができる。この場合、ユーザ端末は、例えば、ユーザ端末がサービスに加入するホーム・ドメインの代わりにホーム・ドメインとして連携ドメインを用いることを、その認証リクエストにおいて使用することによって、ローカルの認証を望むことをサービスリクエストで示すべきである。

ユーザ端末は、例えば、ＵＳＩＭカードに保存したリストなどの静的な構成、又は、例えば過去の認証手順による学習などの動的な探索によって、“代用のホーム・ドメイン”として用いるためのドメインに関する情報を取得することができる。端末に保存された情報は、各ホーム・ドメインが連携しているドメインのリスト、ドメインの使用コストや規制情報などの対応するステータス情報を含んでいる。ユーザ端末が“代用のホーム・ドメイン”候補を動的に学習する方法の１つは、今までに受けたユーザ・トークンの発行ドメインのすべてを保存することである。ユーザ・トークンをユーザ端末に発行するためには、ドメインは、ユーザの加入情報をダウンロードしており、ユーザのホーム・ドメインと連携関係を有していなければならない。したがって、このドメインで再び認証されるようにリクエストすることが確実である。なお、これらのドメインを発見するために可能な他の方法が存在することは、当業者には自明のことであり、例えば、加入したユーザ端末のホーム・ドメインは、認証リクエスト回答内に自らと連携するすべてのドメインを埋め込むことができる。端末は、そのドメイン・リストをメッセージから検索して、それをホーム・ドメイン・リストに保存できる。また、リスト内に複数の“代用ホーム・ドメイン”候補が存在する場合には、適切なホーム・ドメインを選択するための前述の方法を再度用いて、適切な“代用ホーム・ドメイン”を特定することができる。

ユーザ端末が認証リクエストを送る場合、認証リクエストには、そのホーム・ドメインと“代用ホーム・ドメイン”のリストとが共に含まれており、このリクエストを受けた認証コントローラは、適切なドメインを選択して、ユーザ端末を認証することができる。認証コントローラでのドメインの選択は、ローカル・ドメインのポリシーや連携規約などに準じている。これを可能にするために、認証リクエストに埋め込まれたユーザ識別情報（Ｕｓｅｒ＿ＩＤ）は、対応する情報を含めるように拡張されなければならない。Ｕｓｅｒ＿ＩＤフィールドのフォーマットの一例が、図１６のフォーマット８に記されている。

ユーザ識別情報は、通常、ユーザ資格とその対応するホーム・ドメイン情報により構成される。ネットワークがどのドメインに認証を行うかについて決定可能とする特徴をサポートするために、“代用ホーム・ドメイン”のリストが認証リクエストに含まれている。フォーマット８の＜Sub_Home_Domain＞フィールドは“代用ホーム・ドメイン”リストを表している。“ｎｕｍ”属性は、このリストの要素の数を示す。この“代用ホーム・ドメイン”の第１の要素はタグ“＜１＞”が付記されて保存され、第２の要素は“＜２＞”とし、数字が増加する順で、リストの最後の要素には“＜Ｎ＞”のラベルが付される。なお、ここではＮを最後の数とする。なお、リストを保存するための任意のフォーマットが本発明で適用されることは、当業者には自明のことである。この認証リクエストを受けたドメインが、自らを“代用ホーム・ドメイン”リストに見いだした場合には、認証がローカルで実行可能であることを把握する。一方、このドメインが自らをこのリスト内に見いだせない場合には、ある事前設定済みの基準、例えば、選択するドメインと自らとの間の距離、連携ポリシーのルールなどに基づいて、最適なドメインを選択する。

ユーザ加入プロファイルが、連携訪問ドメインにダウンロードされることが承認されていない場合には、加入ケーパビリティ情報をサービス承認に使用できる。端末が以前に訪問したことのあるドメインごとに、訪問の記録が訪問ドメイン内に維持されている場合がある。前述の訪問ドメインの認証コントローラが認証を行うために、端末は、自らを訪問ドメインに対して識別する必要があり、このために、端末の加入ケーパビリティの検索が可能である。端末の本来の資格を識別情報として用いる場合、訪問ドメインの認証コントローラは、本来の資格の暗号を解読する手段を有していなければならない。したがって、ホーム・ドメインは、ユーザ資格を復号するためのキーを訪問ドメインに提供する必要がある。ユーザ資格とそれに関連するユーザ加入ケーパビリティが、端末の最初の訪問後に訪問ドメインに保存されており、ユーザが同じ資格を用いて認証リクエストを提示する場合には、訪問ドメインの認証コントローラは、そのデータベースを調べて、前述の資格を認識することができる。したがって、認証はこの訪問ドメイン内でローカルに行われ、承認コントローラは、端末の以前の訪問中に得られた加入ケーパビリティ情報に基づいて、サービス承認を行うことができる。

本来のユーザ加入プロファイル又はユーザ資格を明らかにする必要無しにローカル認証を迅速に提供する際の代替方法は、訪問ドメインがローカル・ユーザ資格を端末に提供することである。認証コントローラは、別のローカル資格を端末に発行できる。このローカル・ユーザ資格は、認証リクエストの回答メッセージと共に端末に返送可能であり、端末は、そのローカル・データ・ストア又はＵＳＩＭに、このローカル・ユーザ資格を保存することができる。このローカル資格は、ユーザ・トークンとは異なる目的のために機能する。ユーザ・トークンは、その有効ライフタイム全体にわたって用いられ、ユーザ・トークンがサービスリクエスト及びシングル・サイン・オンに用いられた場合には、認証は成功によって完了することが想定されている。一方、ローカル・ユーザ資格は、この端末がこの訪問ドメインを再び訪問して、再び認証を求める場合に用いられる。この解決方法では、ユーザ加入プロファイル又は本来のユーザ資格が訪問ドメインに明らかにされることは要求されない。例えば、端末が、訪問ドメインとの接続を試みる場合に、以前にこのドメインを訪問したことがあるかどうかを調べる。この場合、端末は、認証のために、この訪問ドメインが提供するローカルｉｄの使用を試みてもよい。訪問ドメイン内において、その認証コントローラは、このローカルｉｄに関連したユーザ加入ケーパビリティを検索して、ホーム・ドメインからの検証を求めずに認証を実行する。

本発明は、データ通信ネットワークの分野に適用され、特に、移動通信ネットワークにおける移動端末のアクセス制御に係る技術に適用可能である。

連携ネットワーク・サービス環境のシステム構成の例を示す図 ホーム・ドメインと連携する訪問ドメインに対するアクセスのシステム構成を示す図 連携した訪問ドメイン環境でシングル・サイン・オンを実現する認証と承認プロセスのシーケンス・ダイアグラムを示す図 認証プロセス中に得たユーザ・トークンを用いる承認プロセスのシーケンス・ダイアグラムを示す図 ホーム・ドメインに間接的に連携する訪問ドメインに対するアクセスのシステム構成を示す図 間接的に連携する環境における承認プロセスのシーケンス・ダイアグラムを示す図。このシーケンス・ダイアグラムは、認証が既に行われていることと、連携した訪問ドメインから得たユーザ・トークンとを想定している。ダイアグラムは、ホーム・ドメインと連携していない別の訪問ドメインのネットワークリソースに対するアクセスを示している。 間接的に連携する環境における認証及び承認プロセスのシーケンス・ダイアグラムを示す図。このシーケンス・ダイアグラムは、ユーザがホーム・ドメインと連携していないドメインにアクセスしているときに、認証及び承認の両方のプロセスのメッセージ交換を示している。このシーケンス・ダイアグラムは、端末がアクセスを試みている非連携ドメインと端末のホーム・ドメインとの両方と連携しているドメインが存在する、１段のドメイン連携を示している。 間接的に連携する環境における、他の認証及び承認プロセスのシーケンス・ダイアグラムを示す図。このシーケンス・ダイアグラムは、ユーザがホーム・ドメインと連携していないドメインにアクセスしているときの、認証及び承認の両方のプロセスのメッセージ交換を示している。このシーケンス・ダイアグラムは、端末がアクセスを試みているドメインとホーム・ドメインとの両方と直接連携しているドメインが存在しない、多段のドメイン連携を示している。連携のチェーンは、複数の中間ノードを介して接続する必要がある。 認証リクエストに係るメッセージ・フォーマット（フォーマット１）の一例を示す図 認証アサーションクエリに係るメッセージ・フォーマット（フォーマット２）の一例を示す図 ユーザ・トークンに係るメッセージ・フォーマット（フォーマット３）の一例を示す図 承認アサーションクエリに係るメッセージ・フォーマット（フォーマット４）の一例を示す図 加入ケーパビリティに係るメッセージ・フォーマット（フォーマット５）の一例を示す図 図７のステップ７．４で訪問ドメイン１に返される加入ケーパビリティに係るメッセージ・フォーマット（フォーマット６）の一例を示す図 図７のステップ７．９で訪問ドメイン１に返される加入ケーパビリティに係るメッセージ・フォーマット（フォーマット７）の一例を示す図 ネットワークによる認証ドメインの選択を可能とするユーザ識別情報に係るメッセージ・フォーマット（フォーマット８）の一例を示す図

Claims (32)

1. ビジネス関係にある複数の管轄ドメインにおける複数のネットワークにアクセスするためのシングル・サイン・オンを実現するために、ユーザの認証及び承認を管理するシステムであって、
   （１）ユーザ加入情報、ドメインポリシー、相互ドメイン規約、ユーザリクエストに基づいて、ユーザの認証及び承認の状態を管理する機能を有するユーザのホーム・ドメインにおけるアクセス・コントロール・オーソリティと、
   （２）ユーザ認証を行うとともに、ユーザ情報及びドメインポリシーを取得するために前記アクセス・コントロール・オーソリティとの通信を行う前記ユーザのホーム・ドメインとビジネス関係にある管轄ドメインにおける認証コントローラと、
   （３）ユーザ加入情報、ドメインポリシー、相互ドメイン規約に基づいて、ビジネス関係にある管轄ドメイン及びローカル管轄ドメインにおけるネットワークを介したユーザによるサービスへのアクセスの制御を行う前記アクセス・コントロール・オーソリティと同一の管轄ドメインにおける承認コントローラを有するシステム。
2. 請求項１に記載のユーザ認証及び承認を管理するシステムであって、前記ユーザのホーム・ドメインとの間でビジネス関係にない管轄ドメインにおけるネットワークにアクセスするユーザをサポートし、
   （１）前記ユーザのホーム・ドメインと直接ビジネス関係にある管轄ドメインの認証コントローラを探索し、前記ホーム・ドメインと直接ビジネス関係にある前記認証コントローラに認証リクエストを送ることが可能なローカル管轄ドメインにおける認証コントローラと、
   （２）同じ管轄ドメインの前記認証コントローラとの通信結果に基づいて、前記ユーザに対するネットワーク・アクセス及びリソースを制御することが可能なローカル管轄ドメインにおける承認コントローラとを更に有するシステム。
3. ユーザの加入情報、ステータス情報、ドメインポリシー、相互ドメイン規約を保存するホーム・ドメインのセントラルデータベースを更に有する請求項１又は２に記載の複数の管轄ドメインにおける複数のネットワークにアクセスするためのシングル・サイン・オンを実現するために、ユーザ認証及び承認を管理するシステム。
4. 複数のホーム・ドメイン加入情報を保存するホーム・ドメイン・リストを有するユーザ装置を更に有しており、複数の加入を可能とする請求項１に記載の複数の管轄ドメインにおける複数のネットワークにアクセスするユーザをサポートするシステム。
5. 複数の管轄ドメインにおける複数のネットワークにアクセスするシングル・サイン・オンを実現するために、ユーザ認証及び承認を管理する方法であって、
   （１）ユーザのホーム・ドメインのアクセス・コントロール・オーソリティが、受信された認証リクエストに埋め込まれているユーザ資格で識別されたユーザ加入プロファイルから加入ケーパビリティ情報を導くステップと、
   （２）ユーザのホーム・ドメインとビジネス関係にあるドメインの承認コントローラが、同じドメインの承認コントローラがアクセスできるローカル・データベースに、前記アクセス・コントロール・オーソリティから受信した前記加入ケーパビリティ情報を保存するステップと、
   （３）前記承認コントローラが、前記加入ケーパビリティ情報、ドメインポリシー、相互ドメイン規約に基づいて、ユーザ・トークンを作成するステップと、
   （４）ユーザ端末が、前記ユーザ・トークン及びドメイン情報を受信して保存し、それを用いて後のネットワーク・アクセスリクエストを行うステップとを有する方法。
6. 前記承認コントローラが自分だけが分かっているセキュリティ・キーでユーザ・トークンを暗号化するステップを更に有する請求項５に記載の複数の管轄ドメインにおける複数のネットワークにアクセスするためのシングル・サイン・オンを実現するために、ユーザ認証及び承認を管理する方法。
7. （１）認証コントローラが、認証リクエストを受信し、リクエストに示されるホーム・ドメインと、前記認証コントローラが属している管轄ドメインとの間の関係を検証するステップと、
   （２）ユーザのホーム・ドメインとビジネス関係にあるドメインの認証コントローラが、同じドメインの承認コントローラにユーザ・トークンの作成を通知するステップと、
   （３）前記承認コントローラが、作成したユーザ・トークンを同じドメインの認証コントローラに送るステップとを更に有する請求項５に記載の複数の管轄ドメインにおける複数のネットワークにアクセスするためのシングル・サイン・オンを実現するために、ユーザ認証及び承認を管理する方法。
8. シングル・サイン・オンにより複数の管轄ドメインにおける複数のネットワークからサービスにアクセスする方法であって、
   （１）端末が、ローカル管轄ドメインの承認コントローラに、請求項５に記載のプロセスで得たユーザ・トークンが埋め込まれているサービス承認リクエストを送るステップと、
   （２）ユーザ・トークンを作成した承認コントローラが、前記ユーザ・トークンを確認して暗号を解読し、前記ユーザ・トークンに埋め込まれている識別情報を用いてローカル・データベースからユーザ加入ケーパビリティ情報を検索するステップと、
   （３）ユーザ・トークンを作成した前記承認コントローラが、前記加入ケーパビリティ情報、ドメインポリシー、相互ドメイン規約に基づいて、サービス承認リクエストの承認を行うステップとを有する方法。
9. 承認コントローラが、ユーザ・トークンに埋め込まれている情報を用いて、受信したユーザ・トークンを生成した承認コントローラの識別情報を取得し、対応するサービス承認リクエストを、前記ユーザ・トークンを作成した前記承認コントローラに送るステップとを更に有する請求項８に記載のシングル・サイン・オンにより複数の管轄ドメインにおける複数のネットワークからサービスにアクセスする方法。
10. （１）前記認証リクエストメッセージのホーム・ドメイン情報を抽出して、前記ホーム・ドメインとビジネス関係にあるドメインに到達するために、認証コントローラの組み合わせの検索を開始するステップと、
    （２）検索結果から認証コントローラの組み合わせを選択し、ローカル選択基準を用いて、前記ホーム・ドメインとビジネス関係にあるドメインに到達するステップとを有する認証コントローラが認証リクエストメッセージを処理するための請求項７に記載の方法。
11. 認証コントローラの前記選択された組み合わせに基づいて、ホーム・ドメインとビジネス関係にあるドメインの認証コントローラに、前記リクエストメッセージを送るステップを更に有する認証コントローラが認証リクエストメッセージを処理するための請求項１０に記載の方法。
12. （１）前記組み合わせにおける認証コントローラの数
    （２）前記組み合わせにおける認証コントローラ間の距離
    （３）前記組み合わせにおける認証コントローラに対するアクセスに起因するコスト
    （４）前記組み合わせにおける認証コントローラが属するドメインの負荷状態
    （５）前記組み合わせにおける認証コントローラの機能
    （６）規制情報
    （７）任意の事前設定済みのドメインポリシー
    （８）すべての関連情報に関して重み付けされた組み合わせを有する情報
    に基づいて、認証コントローラが、検索結果から認証コントローラの組み合わせを選択するための請求項１０に記載の方法。
13. （１）前記認証コントローラが、すべての組み合わせ及び関連情報を含んでいるメッセージをユーザに送るステップと、
    （２）ユーザが、組み合わせを選択して、選んだ組み合わせを認証コントローラに示すステップとを有する認証コントローラが検索結果から認証コントローラの組み合わせを選択するための請求項１０に記載の方法。
14. （１）請求項５に記載の認証コントローラが保存する加入ケーパビリティとユーザのサービス承認リクエストのサービスリクエストとを比較するステップと、
    （２）サービスリクエストが前記加入ケーパビリティ内に見いだせない場合には再承認を実施するステップと、
    （３）前記再承認の結果が新しいケーパビリティを含んでいる場合、ローカル・データベースの加入ケーパビリティを更新するステップとを有する、ユーザ・トークンを生成する承認コントローラがサービス承認リクエストメッセージを処理するための請求項８に記載の方法。
15. ユーザのホーム・ドメインとビジネス関係にあるドメインの承認コントローラが、ユーザのホーム・ドメインから承認を明示的に求めずに、サービス承認を実施するための方法であって、
    （１）ユーザ・トークンが埋め込まれたサービスリクエストを受け取った場合に、請求項５に記載の認証プロセスにおいてユーザのホーム・ドメインから取得されたユーザの加入ケーパビリティを検索するステップと、
    （２）前記ユーザ加入ケーパビリティのサービス情報、ドメインポリシー、相互ドメイン規約に基づいて、前記サービスリクエストを承認するステップを有する方法。
16. ユーザのホーム・ドメインとビジネス関係にあるドメインの認証及び承認コントローラが、ユーザのホーム・ドメインから検証を明示的に求めずに、認証及びサービス承認を実施するための方法であって、
    （１）加入ケーパビリティ情報を保存するユーザのホーム・ドメインのデータベースにアクセスすることにより、前記ユーザのホーム・ドメインから前記加入ケーパビリティ情報を取得するステップと、
    （２）前記ユーザがユーザ・トークン無しにサービスにアクセスする場合に、前記ユーザにユーザ・トークンを発行するステップと、
    （３）ユーザのホーム・ドメインに問い合わせを行うことなく、加入ケーパビリティのサービス情報、ドメインポリシー、相互ドメイン規約に基づいて、ユーザからのサービスリクエストを認証して承認するステップを有する方法。
17. ユーザのホーム・ドメインとビジネス関係にないドメインの認証コントローラが、ユーザを認証するための方法であって、
    （１）ユーザのホーム・ドメインとビジネス関係にあるドメインに関して、自らとビジネス関係にあるドメインの中から照会するステップと、
    （２）ユーザのホーム・ドメインとビジネス関係にある前記ドメインに対して、サービス・ブローカとして機能し、かつユーザのサービスリクエストの承認を実施するように要求するステップと、
    （３）前記サービス・ブローカからの情報を利用して、前記ユーザを認証すべきかどうかを決定するステップとを有する方法。
18. ユーザのホーム・ドメインとビジネス関係にないドメインの認証コントローラが、請求項１０に記載されているユーザのホーム・ドメインとビジネス関係にあるドメインへのパスを探索するための方法であって、
    （１）前記認証コントローラは、ローカル構成に基づいて、自らとビジネス関係にあるドメインの認証コントローラに、メッセージのライフタイムとユーザのホーム・ドメインとを示すクエリメッセージを送るステップと、
    （２）前記クエリメッセージを受け取った認証コントローラが、自らが前記クエリメッセージに記載されたユーザのホーム・ドメインとビジネス関係にない場合に、自らの識別情報をメッセージに付記し、自らとビジネス関係にあるドメインの認証コントローラにクエリメッセージを送るステップと、
    （３）前記クエリメッセージに記載されたユーザのホーム・ドメインとビジネス関係にあるドメインの認証コントローラが、その識別情報をメッセージに付記し、メッセージに添付された情報を用いて元の認証コントローラにメッセージを戻すステップとを更に有する方法。
19. 請求項５に記載のユーザ・トークンを保護する方法であって、
    （１）トークン発行者が、ユーザに送る認証メッセージ回答内に前記ユーザ・トークンと共に乱数を含ませるステップと、
    （２）ユーザ端末が、乱数を用いてセキュリティ・コードを生成し、それをサービスリクエスト内の前記トークンと共に送るステップと、
    （３）トークン発行者が、同じアルゴリズムを用いて検証コードを生成し、それを前記サービスリクエスト内の前記トークンと共に受け取った前記セキュリティ・コードによって検証するステップと、
    （４）トークン発行者及びユーザ端末が、それぞれサービスリクエストの後に同じ方法を用いて、乱数を変更するステップとを有する方法。
20. 請求項５に記載のユーザ・トークンを保護する方法であって、
    （１）トークン発行者が、ホーム・ドメインから乱数を取得し、ユーザに送るメッセージ回答内の前記ユーザ・トークンと共に前記乱数を転送するステップと、
    （２）前記トークン発行者が、サービスリクエスト内の前記トークンと共にセキュリティ・コードを検証するために、ホーム・ドメインから受け取った加入ケーパビリティ情報に含まれている検証コードのリストを取得するステップと、
    （３）前記トークン発行者が、それぞれサービスリクエストの後に適切な検証コードを取得するために、前記リストを詳しく調べるステップとを更に有する方法。
21. ユーザのホーム・ドメインのアクセス・コントロール・オーソリティが、請求項５及び１６に記載されているユーザの限られた加入プロファイル情報を、ビジネス関係にあるドメインの認証コントローラに提供するための方法であって、
    （１）相互ドメイン規約から、ビジネス関係にあるドメインが提供するネットワーク・サービスを検索するステップと、
    （２）ユーザ加入プロファイルから、前記ユーザが加入するネットワーク・サービスの情報を検索するステップと、
    （３）前記の相互ドメイン規約で認可されていないが、前記ユーザ加入プロファイル内に存在するネットワーク・サービスを除外するステップとを更に有する方法。
22. 請求項５に記載されている複数の管轄ドメインの複数のネットワークにアクセスするためにシングル・サイン・オンを実現する方法で用いられる加入ケーパビリティ情報のためのフォーマットであって、
    （１）このメッセージを受け取る承認コントローラが承認されているネットワーク・インタフェースの数と、
    （２）前記承認コントローラが承認されているインタフェース・タイプごとに与えられるサービス品質に関連するサービス・プロファイルの識別子と、
    （３）端末からのその後のメッセージを確認するためのセキュリティ情報を含むセキュリティ・コード・ベクトルとを有するフォーマット。
23. 請求項５に記載されている複数の管轄ドメインの複数のネットワークにアクセスするためにシングル・サイン・オンを実現する方法で用いられるユーザ・トークンのためのフォーマットであって、
    （１）トークン発行者のアドレスと、
    （２）ユーザのホーム・ドメイン情報と、
    （３）前記トークンのタイムリミットと、
    （４）トークン発行者が加入ケーパビリティを特定するための加入ケーパビリティｉｄとを有するフォーマット。
24. 請求項５に記載されている複数の管轄ドメインの複数のネットワークにアクセスするためにシングル・サイン・オンを実現する方法において、ユーザのホーム・ドメインとビジネス関係にあるドメインが認証アサーションをリクエストするためのフォーマットであって、
    （１）サービスをリクエストするユーザの資格と、
    （２）ユーザのホーム・ドメインとビジネス関係にあるドメインの情報と、
    （３）ユーザのホーム・ドメインの情報とを有するフォーマット。
25. 請求項５に記載されている複数の管轄ドメインの複数のネットワークにアクセスするためにシングル・サイン・オンを実現する方法において、ユーザのホーム・ドメインとビジネス関係にあるドメインが、承認アサーションをリクエストするためのフォーマットであって、
    （１）加入ケーパビリティ発行者がユーザ加入プロファイルと連携ポリシーとを定めるための加入ケーパビリティｉｄと、
    （２）ユーザがリクエストするサービス・タイプ情報と、
    （３）ユーザのホーム・ドメインとビジネス関係にあるドメインの情報と、
    （４）ユーザのホーム・ドメインの情報とを有するフォーマット。
26. 請求項５及び１６に記載されている複数の管轄ドメインにおける複数のネットワークにアクセスするため、その資格を示すことができるようにする、ユーザ端末の認証リクエストに用いられるフォーマットであって、
    （１）ユーザ加入情報を検索するためのユーザのホーム・ドメイン以外のドメインの情報と、
    （２）認証プロセスが行われるユーザのホーム・ドメイン以外のドメインのリストとを有するフォーマット。
27. 請求項５及び１６に記載されている複数の管轄ドメインにおける複数のネットワークにアクセスするためにシングル・サイン・オンを実現する方法において、迅速な認証及び承認を実現するための方法であって、ユーザが更なるサービスリクエストのためにホーム・ドメイン・リストのトークン発行者のドメイン情報を保存するステップを更に有する方法。
28. 請求項５及び１６に記載されている複数の管轄ドメインにおける複数のネットワークにアクセスするためにシングル・サイン・オンを実現する方法において、迅速な認証及び承認を実現するための方法であって、
    （１）ユーザ・トークンを生成したドメインの認証コントローラが、端末が前記ユーザ・トークンを生成した前記ドメインを訪問する場合に、前記端末が認証リクエストを行うためのローカル識別子を提供するステップと、
    （２）前記端末が、ローカル・ドメインを訪問する場合に、その認証リクエストにおいて、当該生成されたローカル識別子を用いるステップとを更に有する方法。
29. 請求項５及び１６に記載されている複数の管轄ドメインにおける複数のネットワークにアクセスするためにシングル・サイン・オンを実現する方法において、迅速な認証及び承認を実現するための方法であって、
    （１）ユーザのホーム・ドメインが、前記ホーム・ドメインがビジネス関係にあるドメインに、ユーザ資格の暗号を解読するためのセキュリティ協定を提供するステップと、
    （２）ユーザのホーム・ドメインとビジネス関係にある前記ドメインが、このユーザ資格と、請求項５に記載したステップで取得されたユーザの加入ケーパビリティ情報との関連付けを行うステップと、
    （３）ローカル・ドメインが、ユーザ資格及び関連付けられたユーザ加入ケーパビリティに基づいて、認証及び承認を実施するステップとを更に有する方法。
30. 請求項５及び１６に記載されている複数の管轄ドメインにおける複数のネットワークにアクセスするためにシングル・サイン・オンを実現する方法において、迅速な認証及び承認を実現するための方法であって、ユーザが、その認証リクエストにおけるホーム・ドメインを、その実際のホーム・ドメインとビジネス関係にある別の管轄ドメインに置き換えるステップを更に有する方法。
31. 請求項５及び１６に記載されている複数の管轄ドメインにおける複数のネットワークにアクセスするためにシングル・サイン・オンを実現する方法であって、
    （１）ユーザのホーム・ドメインのアクセス・コントロール・オーソリティが、ビジネス関係にあるドメインを認証回答メッセージに埋め込むステップと、
    （２）ユーザが、更なるサービスリクエストのために、ユーザ装置のホーム・ドメイン・リストに前記ドメイン情報を保存するステップとを更に有する方法。
32. 請求項５及び１６に記載されている複数の管轄ドメインにおける複数のネットワークにアクセスするためにシングル・サイン・オンを実現する方法であって、
    （１）ユーザが、アクセスしているネットワークからローカル管轄ドメイン情報を取得するステップと、
    （２）ユーザが、前記ローカル管轄ドメイン情報とホーム・ドメイン・リストのドメイン情報とを比較するステップと、
    （３）ユーザが、この比較結果と一部の構成可能なポリシーとに基づいて、ホーム・ドメインとして認証リクエスト又はサービス承認リクエストのホーム・ドメイン・リストのドメインの１つを用いるステップとを更に有する方法。

Images