JP4303130B2 - シングルサインオンサービスのためのシステム、方法、および装置 - Google Patents

Description

本発明は、一般に、複数のユーザに対して提供可能なシングルサインオンサービスに係り、とりわけ、移動通信ネットワークオペレータ網の加入者である複数のユーザに対して提供可能なシングルサインオン型のウェブベースサービスを提供する手段、システム、および方法に関する。

ウェブサービスの出現は、ユーザが容易かつ便利にウェブサービスにアクセスできるようにする新規のサービス、いわゆるシングルサインオン（ＳＳＯ）をもたらした。現在のＳＳＯの原理によれば、ユーザは、一度認証されれば、そのレベルの認証を受け入れる全ての加入サービスへのアクセス権を取得できる。この原理は、エンドユーザの利便性について着目してはいるが、ＳＳＯを実現する際の端末およびネットワークの機能については何ら定めてはいない。現在のトレンドとしては、ＳＳＯ原理を実行する２つの手法が存在する。

第１の手法、すなわち、「端末中心」手法では、ユーザが一度端末に対して認証を実行すると、端末はサービスを発信するネットワークアクセスを自動的に追跡する。そして、これ以上のユーザの助けを必要とすることなく、透過的に、適切な信用証明書を要求するサービスを発信するネットワークに、この証明を提示する。

第２の手法、すなわち、「ネットワーク中心」手法では、ユーザが一度ネットワーク中の認証プロバイダ（ＡＰ）に対して認証を実行する。認証プロバイダは、そのサービスに対する適切な信用証明書を処理する。

いわゆる「ネットワーク中心」手法は、認証プロバイダおよびサービスプロバイダ間にドメインの信頼関係が存在する場合に適している。一方、端末中心手法は、この信頼関係が存在せず、端末が異種のドメインまたはサービスに対して認証を追跡することができる場合に適している。

両手法を組み合わせてもよい。ネットワークオペレータは、デジタル証明書、短時間証明書、または一時チケットなどの信用証明書、あるいは、端末またはアクセス可能な読取り書込みカードに格納されるであろうトークンを発行してもよい。これらは、認証手順または許可手順の際にユーザにより使用される。
米国特許出願 ＵＳ２００２／００１０７７６Ａ１号公報 欧州特許出願 ＥＰ１０８９５１６号公報

従来のセルラーオペレータは、認証サービスを使用して音声・データサービスを提供しており、当該サービスへ加入者がアクセスする際には、そのアクセスを許可していた。セルラーオペレータがバリューチェーンを上昇させるにつれて、加入者との相互の信頼関係を強化することができるであろう。サービスドメインおよび認証サービスが異なる管理エンティティに属している新興のビジネスモデルの加入者らに対しては、認証プロバイダが、新規の役割を果たすことになる。ここで、両アクセス、すなわち、ＩＰ接続とサービスとを提供できるオペレータは、アクセスレベルで実行される認証が、サービスドメインでの認証として有効となるように、加入者に対して「アクセス認証ＳＳＯ」を追加的に提供することになろう。これが、本発明の目的を説明する際の適切なスタート地点となる。

より詳細に、上述の手法の利点および欠点を考察するためには、ユーザに提供されるであろうサービスだけでなく、サービスドメインと認証プロバイダとの間の関係を考慮に入れなければならない。一般的に言って、認証プロバイダは、サービスを提供するサービスプロバイダと同じ管理ドメインに属していてもよいし、信頼できる第三者または分散型の連盟に委任されてもよい。

本発明の第１の目的は、移動通信ネットワークオペレータ（ＭＮＯ）の連盟の加入者、すなわち、異なるサービスプロバイダ（ＳＰ）のユーザである加入者に対して、シングルサインオン（ＳＳＯ）サービスをサポートすることである。ユーザ、移動通信ネットワークのオペレータの連盟、およびこの連盟の少なくとも１つのメンバと契約を結んでいるサービスプロバイダが、本発明によるアーキテクチャ／ビジネス参照モデルによって、追加の利点および付加価値サービスを得られるように、ＳＳＯサービスがサポートされる。

具体的には、参照モデル契約内における任意のサービスプロバイダ（ＳＰ）においては、任意のサービスにアクセスできるといったＳＳＯサービスの利点を、ユーザは得られることになる。移動通信ネットワークオペレータ（ＭＮＯ）は、移動通信への加入価値を高めることで、加入者の解約を低減できることに加え、ＳＳＯサービス、特に、認証サービスおよび許可サービスを第三者に提供することによって収益を得られるであろう。最終的に、サービスプロバイダは、多様なユーザによる多様なメカニズムに対するサポートを最小限にする、より簡単で安全な認証／許可メカニズムを備えることにより、潜在的なユーザ、すなわち、移動通信への加入者を増加させることができるだろう。このシナリオによれば、認証プロバイダおよびサービスプロバイダは、異なる管理ドメインに所属する。同時に、これらの利点は、いわゆるモバイルコマース（ｍ−コマース）を増加させる点で好都合である。これを本発明のさらなる目的と考えることができる。

「ネットワーク中心」手法は、上述のように、認証プロバイダの処理を担当することを希望する移動通信ネットワークオペレータの加入者でもある、サービスプロバイダのユーザを関与させるシナリオに適しているようにも思える。しかし、ここでは、認証プロバイダとして機能するネットワークの種別に関係なく、一般的なネットワーク中心手法におけるＳＳＯサービスを参照しながら、最も近い周知の従来技術について考察する。

例えば、Lerner氏の米国特許出願ＵＳ２００２／００１０７７６Ａ１号は、認証／許可サービスのために、シングルサインオン（ＳＳＯ）分散型アプリケーションサービスを統合する方法およびシステムについて記載している。この出願の関連する教示によれば、第１アプリケーションのブラウザを指定するユーザからの第１の指示が、ユーザ端末に接続された中央サーバにおいて受信されると、処理が開始される。ユーザに対応するクッキーファイルも、第１アプリケーションのブラウザから送信され、中央サーバにおいて受信される。中央サーバはブラウザから受信されたクッキーファイルを更新する。

クッキーファイルは可変長のデータセグメントであり、通常、数百バイトのサイズを有する。これらのクッキーは、中央サーバに対してローカルか、あるいは、リモートの相手側のサイトに常駐するかに関わらず、各加入ウェブサーバに常駐するアプリケーションインタフェースライブラリにより書き込まれ、読み出され、そして修正される。具体的に、受信されたクッキーファイルの更新処理には、クッキーファイルに含まれるいくつかの所定のパラメータとの比較処理と、この比較処理に基づくクッキーファイルの最終的な変更処理が含まれる。

ユーザがサーバに第２アプリケーションを指定していることを示すユーザからの第２の指示が、中央サーバにおいて受信されると、中央サーバは第２アプリケーションにこの更新されたクッキーファイルを供給する。

この出願によれば、クッキーファイルに対して書込み、読出し、および変更を行なう役割を果たす上述のアプリケーションインタフェースライブラリが、他のアプリケーション間でも認証を行なうように構成されていることが記載されている。従って、当業者は全てのユーザに対する認証データおよび対応する機能が、ローカルまたはリモートの相手側のサイトにおいて、各加入ウェブサーバに常駐することをすぐに理解できるであろう。これは管理上、さらに不利となる。具体的には、ユーザが、ＳＳＯサービスの利点を得ている場合でも、加入ウェブサーバの任意のアプリケーションにおいて、ユーザの認証に関する特定の動作が実行される。当該アプリケーションのブラウザはユーザにより指定されたものである。このため、このメカニズムは、認証プロバイダおよびサービスプロバイダが同じ管理ドメインに属するシナリオの一例として理解できよう。

上述の教示は、移動通信ネットワークオペレータの連盟、当該連盟の少なくとも１つのメンバと恐らく契約を結んだであろう複数の異なるサービスプロバイダ、および当該連盟のいずれかのメンバの移動通信加入者など、多数の潜在的なユーザから構成される大規模な通信システムにおいては、適切でないように思われる。

また、加入者認証データおよびアルゴリズムが非常に注意を要するような情報である場合、ＭＮＯは、自己の設備外にあるエンティティを介してこの情報を頒布することには、非常に抵抗感を感じるであろう。

シングルサインオンによるユーザアクセスのための方法およびシステムの別の重要な例が、Grandcolas氏等の欧州特許出願第ＥＰ−１０８９５１６号に記載されている。この出願によれば、ユーザは複数のウェブサーバへのアクセス権を取得することができる。

この出願によれば、望ましいサービスを提供する第２ウェブサーバをユーザが選択できるようにする第１ウェブサーバにおいて、ユーザを認証する方法について記載する。ユーザが効果的に第２ウェブサーバを選択すると、第１ウェブサーバは暗号化された認証トークンを生成し、それを第２ウェブサーバへと送信する。第２ウェブサーバは、受信されたトークンを認証し、ユーザがこの第２ウェブサーバにおいてセッションを所有できるようにする。また、第１ウェブサーバおよび第２ウェブサーバの双方は、サブドメインを共有する。すなわち、この出願のシナリオは、認証プロバイダ、すなわち、第１ウェブサーバとサービスプロバイダ（すなわち、第２ウェブサーバ）との双方が同じ管理ドメインに所属する場合のものである。

このため、この出願の教示は、認証プロバイダおよびサービスプロバイダが異なる管理ドメインに所属するシナリオには適用できない。すなわち、この出願における第１ウェブサーバである認証プロバイダが、サービスを提供される第２ウェブサーバにアクセスするユーザにとっての最初の連絡装置となる。

従って、この手法は認証プロバイダおよびサービスプロバイダが異なる管理ドメインに所属するシナリオにおいては、実用に適さないようである。このようなシナリオでは、認証局にユーザを認証するよう要求するサービスプロバイダにユーザが直接アクセスし、一度この認証に成功すると、ユーザに対して選択されたサービスをサービスプロバイダが提供することを、認証局はサービスプロバイダに許可する。

認証プロバイダおよびサービスプロバイダが異なる管理／商用ドメインに所属するシナリオを表す現在の周知のソリューションは、マイクロソフト（Ｒ） ．ＮＥＴ Ｐａｓｓｐｏｒｔ製品である（http://www.passport.comに記載される通りであり、以下「．ＮＥＴ Ｐａｓｓｐｏｒｔ」と称す。）。この製品は、広範囲のインターネット信頼ネットワークを構築することを意図するもので、対応する規格をサポートする任意の組織に対してオープンとなっている技術／操作ガイドラインの共通のセットを使用する。

しかしながら、この手法では、移動通信ネットワークオペレータの連盟の少なくとも１つのメンバと提携するサービスプロバイダにアクセスする移動通信加入者について認証処理を担当するために、連盟を結成するといった問題は解決されていない。さらに、非常に大規模なインターネット認証システムとなることを意図している ．ＮＥＴ Ｐａｓｓｐｏｒｔのような手法は、中央集権化認証局に基づく複雑な解決法であり、中央集権化認証局は、移動通信ネットワークオペレータおよび加入者に有利な取引を提案するものではない。

本発明の主要な目的は、移動通信ネットワークオペレータ（ＭＮＯ）の連盟における任意のＭＮＯの加入者に、シングルサインオン（ＳＳＯ）サービスを提供する提携サービスプロバイダ（ＳＰ）に対して、認証局として機能する連盟を構築するシステム、手段、および方法を提供することである。本発明の他の目的は、認証局として機能する連盟が、移動通信ネットワークオペレータが現在使用するのと同等以上のレベルでセキュリティ／プライバシー関連の要件を充足させることである。本発明のさらなる目的は、上述の目的のシステム、手段、および方法に従って、実行装置、役割、関係、および基本的な使用ケースに関するアーキテクチャやビジネスの参照モデルを確立することである。

とりわけ、上述の目的は、本発明によると第１移動通信ネットワークのオペレータに加入しかつ選択されたサービスプロバイダにアクセスするユーザに、シングルサインオンサービスを提供するシステム、方法、および装置の提供により達成される。

第１移動通信ネットワークオペレータに所属する第１移動通信ネットワークと、第２移動通信ネットワークオペレータに所属する少なくとも１つの第２移動通信ネットワークと、複数のサービスプロバイダの少なくとも１つであって、認証局により前記少なくとも１つのサービスプロバイダに対して前記移動通信ネットワークオペレータの加入者が一度認証されると、前記加入者にサービスを提供するサービスプロバイダとを含む通信システム。

本発明の一側面によると、前記第１移動通信ネットワークオペレータおよび前記少なくとも１つの第２移動通信ネットワークオペレータは、前記認証局として機能する移動通信ネットワークオペレータのセルラー連盟に従うか、または所属する。

さらに、前記通信システムは、前記連盟において、前記少なくとも１つのサービスプロバイダに対して前記ユーザを認証する権原を有する唯一のメンバとして、前記第１移動通信ネットワークに所属する認証プロバイダと、第２移動通信ネットワークに所属しかつ前記第２移動通信ネットワークオペレータと契約を結んでいるサービスプロバイダから前記連盟へのエントリーポイントとして機能するように構成される認証仲介局とを含む。ここで、この種の契約は「エントリーポイント」契約と呼ばれる。

すなわち、前記通信システムは、第１移動通信ネットワークオペレータに加入しかつサービスプロバイダにアクセスするユーザを前記サービスプロバイダと契約を結んでいる第２移動通信ネットワークオペレータの認証仲介局に向けてリダイレクト（転送）する手段と、前記認証仲介局にアクセスする前記ユーザを前記ユーザのホームとなる第１移動通信ネットワークオペレータの認証プロバイダに向けてリダイレクトする手段とを含む。また、前記通信システムは、前記サービスプロバイダが前記第１移動通信ネットワークに所属する前記認証プロバイダからユーザについて認証表明の有効性検証処理を要求できるようにするために、前記認証仲介局においてユーザのホーム解析（解決）を実行する手段を含む。

特に、前記通信システムは、前記第１移動通信ネットワークオペレータの前記認証プロバイダが、認証仲介局を伴わずに、前記第１移動通信ネットワークオペレータと契約を結んでいるサービスプロバイダから直接アクセスできるようにする。このために、前記通信システムは、認証仲介局を伴わずに、前記ユーザのホームとなる第１移動通信ネットワークオペレータと契約を結んでいるサービスプロバイダにアクセスするユーザを、前記ホームとなる第１移動通信ネットワークオペレータの認証プロバイダに向けてリダイレクトする手段を含む。さらに、このようなサービスプロバイダは、認証仲介局を伴わずに、前記認証プロバイダからユーザについて認証表明の有効性検証処理を要求してもよい。

一般的に、上述の通信システムは、前記セルラー連盟の加入者でありかつサービスプロバイダにアクセスするユーザから、前記サービスプロバイダに対して前記ユーザを認証する役割を果たす前記セルラー連盟の認証プロバイダに向けてシングルサインオン認証要求を発行する手段と、受信された結果を前記サービスプロバイダへと提示する手段とを含む。

第１移動通信ネットワークオペレータに加入しかつ選択されたサービスプロバイダにアクセスするユーザへシングルサインオンサービスを提供し、各選択されたサービスプロバイダが第２移動通信ネットワークオペレータと提携する方法も本発明により提案される。この方法は：
（ａ）前記第１移動通信ネットワークオペレータと前記第２移動通信ネットワークオペレータとの間で認証信頼関係を確立し、移動通信ネットワークオペレータの連盟を形成するステップと、
（ｂ）前記選択されたサービスプロバイダから前記第１移動通信ネットワークオペレータのセルラーネットワークに向けて、前記ユーザにより生成されるアクセス要求をリダイレクトするステップと、
（ｃ）前記ユーザのアクセス要求がリダイレクトされる前記第１移動通信ネットワークオペレータの認証プロバイダにおいて、前記サービスプロバイダにアクセスする該ユーザに対して有効な認証表明を生成し、前記認証表明についての結果を該ユーザに返送するステップと、
（ｄ）前記サービスプロバイダから前記第１移動通信ネットワークオペレータの前記認証プロバイダに対して、前記ユーザにより提示される前記結果に含まれる前記認証表明の有効性の検証を要求するステップと、
（ｅ）前記サービスプロバイダにおいて成功検証応答を受信した際に前記ユーザへのサービスアクセスを受諾するステップとを含む。

上述の通信システムおよび方法の双方において、ユーザと前記セルラー連盟の認証プロバイダとの間で使用される認証識別情報および前記ユーザとサービスプロバイダとの間で使用されるユーザ識別情報から独立している共有識別情報を用いて、前記認証プロバイダと前記サービスプロバイダとの間でユーザは識別される。

前記電子通信システム内で、上述の方法において有効な部分となり、第１移動通信ネットワークオペレータに加入するユーザと通信を行なう第１インタフェース手段と、第２移動通信ネットワークオペレータと提携するサービスプロバイダと通信を行なう第２インタフェース手段とを含む認証仲介局が存在する。これらの第１および第２インタフェース手段は、前記認証仲介局が前記ユーザを前記ユーザのホームネットワークへとリダイレクトし、前記サービスプロバイダに対する前記ユーザのホームネットワークを解析できるようにする仲介局チャネルを形成するものと理解してもよい。このような認証仲介局は、ユーザおよびサービスプロバイダとの前記第１および第２インタフェース手段を含むウェブフロントエンドを具備していてもよい。また、前記認証仲介局は、前記セルラー連盟に含まれる移動通信ネットワークオペレータごとに前記セルラー連盟の全ての認証プロバイダに対する記憶装置と、記憶装置からユーザのホーム関係のアドレスデータを取得する手段とをさらに含む。さらに、前記認証仲介局ウェブフロントエンドは、前記セルラー連盟のセキュリティ／プライバシー要件を充足させるために、前記認証仲介局を有する前記移動通信ネットワークオペレータと提携するサービスプロバイダに、公開鍵インフラストラクチャサービスを提供する手段をさらに含むことで、本発明の他の目的を達成する。

前記通信システム内には、上述の方法に積極的に参加し、フロントチャネルおよびバックチャネルを含む認証プロバイダが存在する。

この認証プロバイダのフロントチャネルは、ユーザと前記認証プロバイダとの間の認証セッションを可能とする第１インタフェース手段を含むウェブフロントエンドを含む。このフロントチャネルは、前記ユーザに対するセッション状態を処理するためのセッションマネージャおよび記憶装置と、前記ユーザに対して指定の認証メカニズムを実行するためのフロントエンド認証サーバとをさらに含む。

この認証プロバイダのバックチャネルは、前記認証プロバイダと前記ユーザがアクセスするサービスプロバイダとの間で、ユーザ認証表明に関する情報を交換する第２インタフェース手段を含むプロトコル結合手段を含む。このバックチャネルは、ユーザに対する認証表明を生成するためのセキュリティ表明マークアップ言語（ＳＡＭＬ）エンジンと、認証表明のための記憶装置とをさらに含む。また、ユーザに対する認証表明を生成・格納するために、フロントチャネルとバックチャネルとの間にインターワーキング手段も提供される。

上述のシステム、方法、および装置、すなわち、認証仲介局および認証プロバイダを有するさらなる利点として、少なくとも２つの移動通信ネットワークオペレータが移動通信ネットワークオペレータの連盟に従う、あるいは、前記連盟の一部であり、シングルサインオンサービスをサポートするために前記連盟において認証信頼関係を確立する、ビジネス方法が提供される。前記連盟は、これに含まれる移動通信ネットワークオペレータの加入者にサービスを提供するサービスプロバイダに対して認証局として機能し、各サービスプロバイダは、この連盟にアクセスするために加盟移動通信ネットワークオペレータと提携する。このビジネス方法では、各移動通信ネットワークオペレータは、自身のネットワークおよび提携サービスプロバイダにより提供されるサービスに貢献する。各ネットワークは、そのネットワークの加入者を認証するための認証プロバイダと、前記提携サービスプロバイダを、前記連盟のある特定のユーザを認証する役割を果たす認証プロバイダへとリダイレクトするための認証仲介局とを含む。さらに、このビジネス方法の各サービスプロバイダは、前記連盟に含まれる任意の移動通信ネットワークオペレータの加入者にサービスを提供するよう構成される。前記サービスプロバイダは、前記サービスプロバイダと契約を結んでおり、前記連盟と認証信頼関係を有している移動通信ネットワークオペレータの周知の認証仲介局を介して前記連盟にアクセスしてもよい。

以下の説明では、連盟に属する任意の移動通信ネットワークオペレータ（ＭＮＯ）の加入者に、サービスを提供する提携サービスプロバイダ（ＳＰ）に対して、認証局として機能する移動通信ネットワークオペレータ（ＭＮＯ）連盟を構築する手段、方法、およびシステムに関する、現在のところ好適な実施形態について述べる。これらの好適な実施形態は、実行主体、役割、関係、および基本的な使用ケースの観点から、本発明により提供されるアーキテクチャ／ビジネス参照モデルに従って説明する。

本発明の一側面によると、シングルサインオンサービス用のセルラー連盟（ＦＳＳＯ）が提供される。図１は、第１連盟（ＦＳＳＯ−１）に関する実行主体、役割、関係、および幾つかの例示的な使用ケースの観点から説明されるアーキテクチャ／ビジネス参照モデルを示している。

図１の参照モデルにおける実行主体は、ユーザ（Ｕｓｅｒ＠ＭＮＯ−Ａ、Ｕｓｅｒ＠ＭＮＯ−Ｃ）、サービスプロバイダ（ＳＰ−１、ＳＰ−２）、および加入者ホームサイトである。この加入者ホームサイトとは、加入者と契約を結んでいる移動通信ネットワークオペレータ（ＭＮＯ−Ａ、ＭＮＯ−Ｂ、ＭＮＯ−Ｃ）である。本発明では、ユーザは加入者識別モジュールまたはＷＡＰ識別モジュール（ＳＩＭ／ＷＩＭ）と、ウェブ／ＷＡＰブラウザとを備える移動通信加入者であり、サービスプロバイダはユーザが要求したサービスのあるターゲットであり、ホームサイトはユーザと契約を結んでいる移動通信ネットワークオペレータである。

図１の参照モデルにおいて実行される役割は、ユーザ（Ｕｓｅｒ＠ＭＮＯ−Ａ、Ｕｓｅｒ＠ＭＮＯ−Ｃ）、宛先サイト、認証仲介局（ＡＢ）、および認証プロバイダ（ＡＰ）である。この説明において、ユーザはＳＰにサービスを要求するクライアント装置である。宛先サイトは特定のサービスをクライアントに提供することが可能なサイトであり、一般的に、ＭＮＯを介するＳＰが一部のサービスに関してこの役割を実行してもよい。認証仲介局（１、２）は連盟（ＦＳＳＯ−１）のメンバであり、提携ＳＰ（ＳＰ−１、ＳＰ−２）用の連盟への入場ポイントとして機能するように意図されている。認証プロバイダ（４、５、６）は連盟（ＦＳＳＯ−１）のメンバであり、ユーザデータを所有するように意図されている。認証プロバイダは、ユーザ情報を宛先サイトに対して認証・提供することができる唯一の存在である。特に、ＳＰ（ＳＰ−１、ＳＰ−２）は、提携のＡＢ（１、２）を介して連盟に常時アクセスする（Ｓ−１００、Ｓ−２００）。説明を簡潔にするために、ＳＰは連盟のメンバとは考えない。このため、ＳＰは提携エンティティと呼ばれる。

ビジネスの観点から見ると、各ＭＮＯ（ＭＮＯ−Ａ、ＭＮＯ−Ｂ、ＭＮＯ−Ｃ）が連盟に貢献するのは、独自のセルラーネットワークに関してだけではない。特定の契約を結んだ提携ＳＰ（ＳＰ−１、ＳＰ−２）に関しても貢献する。これらの提携ＳＰは、各ＳＰ（ＳＰ−１、ＳＰ−２）が契約を結んだ特定のＭＮＯ（ＭＮＯ−Ａ、ＭＮＯ−Ｂ）の認証仲介局（１、２）を介して連盟に常時アクセスするであろう。これは、セルラーオペレータが連盟（ＦＳＳＯ−１、ＦＳＳＯ−２）に加盟または連盟を構築した後であっても、既に確立しているＳＰとの業務契約を維持することを希望する可能性があるためであり、とりわけ重要である。さらに、ネットワークオペレータは、優位にある市場での各ＳＰのサービスを強化することができる。これは、サービスプロバイダがローカルオペレータとサービスレベル契約（ＳＬＡ）を結ぶ傾向にあるセルラー多国籍連盟に関して当て嵌まろう。

ビジネスの観点から見て、この参照モデルの根拠は、連盟を結成するか、または連盟に加盟する際にセルラーオペレータに平等な機会が与えられるという事実に基づいている。すなわち、連盟のメンバは常に加入者に対して認証プロバイダの役割を実行するからである。必ずしも必要ではないが、連盟のメンバは、その提携ＳＰについて、連盟の他のメンバからの加入者に対する認証仲介局の機能を実行してもよい。

具体的には、認証仲介局（１、２）は、ユーザのホームサイトの解析処理を実行する。すなわち、ＡＢは、提携ＳＰに十分な情報を提供し、ユーザと契約を結んでいるＭＮＯとＳＰとの間でのユーザデータの交換を可能にする処理を実行する。ユーザのホームサイトが解析されると、ＡＢはユーザのホームサイトへとユーザをリダイレクトできるようになる。オプションとして、ＡＢは、移動通信ネットワークオペレータ特有のセキュリティ／プライバシー要件を充足するために、公開鍵インフラストラクチャ（ＰＫＩ）サービスを提携ＳＰに提供してもよい。

アーキテクチャエンティティ／インタフェース、および現在のところ好適な実施形態の正当性とについてさらに説明する前に、図１の参照モデルにおける様々な関係を説明しておく。ここでは、ユーザ（Ｕｓｅｒ＠ＭＮＯ−Ａ）（Ｕｓｅｒ＠ＭＮＯ−Ｃ）は、ホームサイト（ＭＮＯ−Ａ）（ＭＮＯ−Ｃ）と信頼関係（Ｒ−１１０、Ｒ−１２０）（Ｒ−３２０）にある。ユーザがＳＰ（ＳＰ−１）（ＳＰ−２）に登録すると、ユーザ（Ｕｓｅｒ＠ＭＮＯ−Ａ）（Ｕｓｅｒ＠ＭＮＯ−Ｃ）・ＳＰ（ＳＰ−１）（ＳＰ−２）間と同様に、直接の信頼関係（Ｒ−１１０）が生じる。説明を分かりやすくし、かつＳＰと連盟との関係を簡潔にするために、各ＳＰ（ＳＰ−１）（ＳＰ−２）は唯一の連盟のメンバと単一の信頼関係（Ｓ−１００）を有するものとする。この連盟メンバとは、すなわち、ＳＰが業務契約を結んだ移動通信ネットワークオペレータ（ＭＮＯ−Ａ）（ＭＮＯ−Ｂ）におけるＡＢ（１）（２）である。

従って、ユーザ（Ｕｓｅｒ＠ＭＮＯ−Ａ、Ｕｓｅｒ＠ＭＮＯ−Ｃ）が特定のＳＰ（ＳＰ−１、ＳＰ−２）において、セルラーＳＳＯサービスを利用することを希望する場合、ＳＰは自動的にユーザの要求をセルラー連盟へのＳＰの入場ポイント、すなわち、ＡＢ（１、２）を介して連盟のサイト、すなわち、ユーザの要求を適切に処理することができるＡＰ（４、６）へとリダイレクトする。これにより、ユーザをどこにリダイレクトすべきかに関して、複雑な決定を行なう必要がなくなる。また、ＳＰと連盟との間のインターワーキング（相互動作）を大幅に簡略化し、ＳＰへの影響を低減できるので、連盟との提携を促すことになる。より一般的かつ実際的なシナリオでは、ＳＰ（ＳＰ−２）が、例えば、セルラー連盟（ＦＳＳＯ−１）およびｅバンク連盟（ＦＳＳＯ−２）のような様々な連盟との信頼関係を有していてもよい。

本発明の別の実施形態によれば、特定のＭＮＯ（ＭＮＯ−Ａ）と提携するＳＰ（ＳＰ−１）は、このＳＰ（ＳＰ−１）におけるサービスを要求したユーザ（Ｕｓｅｒ＠ＭＮＯ−Ａ）と契約を結んでいるＭＮＯにおいてＡＰ（４）にアクセスするために、このＭＮＯのＡＢ（１）を経由する必要がない。これは、ＭＮＯ（ＭＮＯ−Ａ）と提携ＳＰ（ＳＰ−１）との間の信頼関係（Ｒ−１１０）にとって特に有利であり、ネットワークアクセスと性能とを最適化することができる。

この別の実施形態にも関わらず、一般的には、認証仲介局の機能を実行することを希望する全てのホームサイトは、全ての連盟メンバと信頼関係を有する。これらのホームサイトも連盟のメンバであるからである。上述のように、ＳＰは全てのユーザを、そのエントリーポイント、すなわち、セルラー連盟内のセルラーオペレータ（ＭＮＯ）またはホームサイトへとリダイレクトすることができる。従って、認証仲介局（ＡＢ）は全ての加盟ホームサイトについて知る必要がある。

しかしながら、ＡＢは、通常、連盟の各ホームサイトのユーザを知らない。このためには、各ＡＢは連盟の全てのユーザを収容可能でなければならず、ユーザ収容能力または可用性の制御のために追加の手段を提供することが必要だからである。しかしながら、本発明により説明される現在好適な実施形態を読み通すことによって、大量の加入者用のデータベース設備のみならず、ユーザ収容能力または可用性の制御のための追加の手段を備えた唯一の、または少数のＡＢ（１、２）が、ある種のセルラー連盟に適している可能性があることを理解できるであろう。例えば、このようなセルラー連盟は、世界中に設備が分散している多国籍企業に所属する複数の国内のＭＮＯから構成される連盟であろう。

図１に示されるシナリオを参照して２つの主だった代表的な使用ケースを説明する。より正確な詳細について、アーキテクチャの観点から例示的な実施形態においてさらに説明する。

第１使用ケースは、例えば、書店サービスプロバイダなど、ある特定のサービスプロバイダ（ＳＰ−１）にアクセスするユーザ（Ｕｓｅｒ＠ＭＮＯ−Ａ）であろう。ここで、サービスプロバイダ（ＳＰ−１）は、ＭＮＯ−Ａなど、特定の移動通信ネットワークオペレータを介して、セルラーＳＳＯ連盟（ＦＳＳＯ−１）と提携している。図２に示すように、ＭＮＯ−Ａの加入者（Ｕｓｅｒ＠ＭＮＯ−Ａ）が書店サービスプロバイダ（ＳＰ−１）へのアクセスを要求すると、このユーザを認証し、サービスを許可するプロセスが開始される。このＳＰは、ＭＮＯ−Ａと業務契約を結んでいるので、ＭＮＯ−Ａが所属するセルラー連盟（ＦＳＳＯ−１）において、ＳＰ−１は、要求をＭＮＯ−Ａホームサイトへとリダイレクトする。ＭＮＯ−Ａホームサイトにおいて、ユーザのＳＰサービス（Ｃ−２３）へのアクセス要求を受信すると、ユーザは自身のＭＮＯ−Ａ識別情報を、例えば、クッキーを用いて提示する。ここで、既に説明したような２つの可能な実施形態を適用してもよい。具体的には、認証仲介局として機能するＭＮＯ−Ａは、自身がユーザに対する認証プロバイダでもあるかどうかを判定する。より一般的な使用ケースでは、後述するように、ＭＮＯ−ＡにおけるＡＢおよびＡＰの双方が関与している。

ユーザがＭＮＯ−Ａにおいて未だに認証されていない場合、認証手順が実行される。既に認証されている場合、ＭＮＯ−Ａが特定ユーザのセッション状態をチェックできるように、ユーザは、ＭＮＯ−Ａにクッキーを送信して提示する。ＳＰが指定の認証機構の実行を要求しない限り、認証は各ＳＰ特有のものではない。ＭＮＯ−Ａは、そのユーザに対してＳＰだけを宛先とした認証表明を作成する（Ｃ−２４）。他の認証情報を含むであろうユーザの認証表明を指し示す結果がユーザに送り返される（Ｃ−２５）。この結果は、一度だけ使用可能なものであり、宛先である指定ＳＰに対してのみ有効である。ユーザは単独でこの結果をＳＰ−１へと送信して提示する（Ｃ−２６）。ＳＰは、結果のソースが有効であることを検証し、指し示されたユーザの認証表明をホームサイト（ＭＮＯ−Ａ）へと要求する（Ｃ−２７）。ＭＮＯ−Ａは、少なくとも認証情報を含む、所要のユーザデータを伴った完全なユーザの表明を送り返す（Ｃ−２８）。ＳＰ−１は、ユーザの表明を分析し、ユーザのホームサイト（ＭＮＯ−Ａ）により実行された認証を信頼する。最終的に、ＳＰ−１はユーザにサービスアクセスの受諾を通知する（Ｃ−２９）。

第２使用ケースは、例えば、旅行代理店サービスプロバイダなどのある特定のサービスプロバイダ（ＳＰ−２）にアクセスするユーザ（Ｕｓｅｒ＠ＭＮＯ−Ａ）であろう。このサービスプロバイダ（ＳＰ−２）は、ＭＮＯ−Ｂなどの特定のセルラーオペレータを介して、セルラーＳＳＯ連盟（ＦＳＳＯ−１）と提携している。一方、ユーザは、連盟のメンバである別のセルラーオペレータ（ＭＮＯ−Ａ）の加入者である。図３に示すように、ＭＮＯ−Ａの加入者（Ｕｓｅｒ＠ＭＮＯ−Ａ）が、例えば、旅行代理店サービスプロバイダ（ＳＰ−２）のようなサービスプロバイダへのアクセスを要求すると、このユーザを認証し、サービスを許可するためのプロセスを開始する。このＳＰ−２は、ＭＮＯ−Ｂと業務契約を結んでおり、それ自体のユーザとセルラー連盟の他のメンバ（ＭＮＯ−Ａ、ＭＮＯ−Ｃ）とにＳＳＯサービスを提供する。ＳＰ−２がＳＳＯに対するユーザの要求を受信すると（Ｃ−２１）、ＳＰ−２は要求をＭＮＯ−Ｂサイトへとリダイレクトする。ＭＮＯ−Ｂは、このＳＰの連盟へのエントランスポイントの１つであるからである。このため、ＭＮＯ−Ｂはこの使用ケースにおいて認証仲介局の機能を実行し、ＳＰ−２からユーザのリダイレクトを受信する（Ｃ−３３）。ＳＰの簡略化のため、ＳＰは連盟に属する全てのホームサイトの情報を有してはいない。従って、ユーザのホームサイトに関する情報がリダイレクトメッセージによって渡されることはない。次に、ＭＮＯ−Ｂはユーザのホームサイト名を要求する（Ｃ−３４）。この参照モデルによれば、ユーザの識別情報は、ユーザ自身のホームサイトにおいてのみ把握されているものとする。代替的な例としては、セルラー連盟内でユーザの識別情報を共有することであるが、この場合、対応する管理タスクを伴う巨大な中央ディレクトリを含む必要がある。

要求（Ｃ−３４）に対して、ユーザは、ホームドメイン名を伴ってＭＮＯ−Ｂサイト、すなわち、現在の認証仲介局（２）へと返答する（Ｃ−３５）。認証仲介局（ＡＢ）は、ユーザをユーザ自身のホームサイト、すなわち、ＭＮＯ−Ａへとリダイレクトする（Ｃ−３６）。これに続いて、ユーザはＳＰ−２へのアクセスをホームサイトへと要求する（Ｃ−２３）。前述の使用ケースと同様に、ユーザがＭＮＯ−Ａにおいて未だ認証されていない場合、認証手順が実行され（Ｃ−２４）、認証情報を伴うユーザの表明を指し示す結果がユーザに送り返される（Ｃ−２５）。ここで、ユーザはこの結果をＳＰ−２へと送信して提示することができる（Ｃ−２６）。ＳＰ−２は結果のソースを検証し、ユーザのホームを解析しなければならない。ＳＰ−２は、この情報をＡＢ（２）に要求する。ＡＢ（２）は、ＳＰ−２がユーザのホームサイト（ＭＮＯ−Ａ）にコンタクトし、指し示されたユーザの表明を取得できるように、ユーザのホーム解析応答を送り返す（Ｃ−３８）。ＭＮＯ−Ａは、少なくとも認証情報を含む所要のユーザデータを伴った完全なユーザの表明を送り返す（Ｃ−２８）。ＳＰ−２はユーザの表明を分析し、ユーザのホームサイトにより実行された認証を信頼する。最終的に、ＳＰ−２はユーザがサービスにアクセスすることを許可する（Ｃ−２９）。

実行主体、機能、信頼関係、および図１から図３において示される幾つかの例示的な使用ケースの観点から、アーキテクチャ／ビジネス参照モデルの概要を示した。複数のＭＮＯの連盟に含まれる各移動通信ネットワークオペレータ（ＭＮＯ）において、加盟シングルサインオン（ＦＳＳＯ）サービスをサポートするのに好適なアーキテクチャに関して、さらなる詳細な実施形態が導入されるであろう。

連盟のメンバと、サービスプロバイダと、ユーザとの間の外部インタフェースを参照して、このアーキテクチャを説明する。これらのインタフェースは、（ユーザというよりむしろ）ユーザ機器（ＵＥ）と認証仲介局との間のインタフェース（以降ＵＥ−ＡＢインタフェース）と、ユーザまたはＵＥと認証プロバイダとの間の別のインタフェース（以降ＵＥ−ＡＰインタフェース）と、サービスプロバイダと認証プロバイダとの間の別のインタフェース（以降ＳＰ−ＡＰインタフェース）と、サービスプロバイダと認証仲介局との間の別のインタフェース（以降ＳＰ−ＡＢインタフェース）とを含む。

これらのインタフェース、あるいは、その組み合わせは、関係する複数のエンティティ間で通信を行なうためのチャネルを提供する。図４に示すこれらのチャネルは、適切なアーキテクチャのためのベースを提供する。

ＵＥ−ＡＢインタフェースにより、ＡＢはユーザの認証を担当するＡＰへとユーザを転送できるようになる。このインタフェースは、例えば、ユーザがＡＰ名をＡＢに提供し、ＡＢがそれをＡＰサイトのエントランスポイントへと変換することによってこのようなリダイレクト機能をサポートする。当業者は、同様の結果を達成するための他の手法または技術を容易に認識するであろう。この通信インタフェースは、ホームサイトのいわゆる「仲介局チャネル（ＡＢ）」の一部である。

ＵＥ−ＡＰインタフェースは、双方の実行主体間、すなわち、ユーザと認証プロバイダ（４、５、６）との間の認証セッションをサポートする。一度認証されると、ユーザは一種のトークンまたは信用証明とともにＳＰへとリダイレクトされる。この通信インタフェースは、ホームサイトの「フロントチャネル（ＡＰ）」（４’）と呼ばれる。

ＳＰ−ＡＰインタフェースは、認証、属性、許可、表明などのユーザ情報を交換するために主に使用される。この通信はユーザにとって透過的に実行されるため、以降はホームサイトの「バックチャネル（ＡＰ）」（４”）と呼ばれる。

ＳＰ−ＡＢインタフェースは、バックチャネルの確立をサポートする。ここで、例えば、ＡＢは認証結果に含まれるソースＩＤを、ユーザのＡＰまたはＰＫＩサポートのエントランスポイントへと変換する。また、このインタフェースは、ホームサイトのいわゆる「仲介局チャネル（ＡＢ）」（１、２）の一部である。

図４は、Ｆ−ＳＳＯソリューションのＡＰおよびＡＢになるためにＭＮＯがサポートするであろう機能の構成要素も示している。図４に示すように、アーキテクチャは、フロントチャネルビュー、バックチャネルビュー、および仲介局チャネルビューから構成されるものと理解できる。このため、認証プロバイダ（４、５、６）は、フロントチャネル（４’）およびバックチャネル（４”）を含むものと見なしてもよい。フロントチャネルは、ユーザの認証を制御し、ユーザとＡＰとの間のマスタセッションを管理するように意図されている。Ｆ−ＳＳＯサービスを導入するために必要な相当量の制御論理が、フロントチャネルのエンティティに配置される。バックチャネルは、ユーザ情報を交換するためのＳＰとＡＰとの間の直接通信を処理するように意図されている。仲介局チャネルには、ＳＰおよびユーザのアドレス解決ニーズをサポートする機能がある。

上述のマスタセッションにおいて、セッション処理に関しては、追加の詳細な考察が必要である。ユーザがＦ−ＳＳＯサービスを要求する場合、以下に示すように幾つかのセッションを作成・維持する必要がある：
−ユーザとＡＰとの間のマスタセッション。ＡＰが一度ユーザを認証すると、ＡＰはセッションを作成し、後述の認証問合せのためにユーザのブラウザに暗号化されたクッキーを残す。
−ＳＰにおいて提供されるサービスを利用できるようにするためのユーザとＳＰとの間のサービスセッション。このセッション管理でも、クッキーが使用されるであろう。

ＡＰは、ユーザと各ＳＰとの間で確立されるサービスセッションを監視する必要がある。このため、本発明の一面によると、図４に示すように、ＡＰはＳＳＯセッションマネージャ（４１）を含む。ＳＳＯセッションマネージャは、フロントチャネルに位置するのが好ましく、バックチャネルと相互に作用し、同様にフロントチャネルに位置するＡＰウェブフロントエンド（４２）に相互接続される。さらに、ＡＰはこのような情報を格納・維持するためのセッションデータベース（４３）を含む。セッションデータベースは、フロントチャネルに配置され、ＳＳＯセッションマネージャ（４１）に相互接続されるのが好ましい。

図２および図３を参照して提示・記載された使用ケースに対して現在好適な実施形態についてより詳細な説明を行なう前に、様々な実行主体がこのアーキテクチャモデルにおいて処理する種々のユーザ識別子について説明する。

ユーザは、ＳＳＯサービス要求を実行するために、認証プロバイダに明確な識別情報、いわゆる「シングルサインオン認証識別情報」（以降ＳＳＯ＿ａｕｔｈ＿ＩＤと呼ぶ）を提示しなければならない。この識別情報は、本発明においては以下の形式の少なくとも１つを有するであろう：
−携帯電話へのアクセスおよび携帯電話からのアクセスに関するＭＳＩＳＤＮ／ＩＭＳＩ
−Ｕｓｅｒ＠ｄｏｍａｉｎまたはｕｓｅｒ＠ｒｅａｌｍ（例えば、ｕｓｅｒ＠ｍｎｏ．ｃｏｍ）
−Ｕｓｅｒｎａｍｅ（文字列）
認証プロバイダ（ＡＰ）は、ユーザごとに複数のＳＳＯ＿ａｕｔｈ＿ＩＤを管理するかもしれないが、複数のＳＳＯ＿ａｕｔｈ＿ＩＤを相関させるユーザごとにいわゆる「メインシングルサインオン識別情報」（以降ＳＳＯ＿ＭＡＩＮ＿ＩＤ）を定義する必要がある。このＳＳＯ＿ＭＡＩＮ＿ＩＤは、オペレータの目的のための、より具体的にはＡＰのためのものである。その形式はオペレータに任されている。すなわち、ユーザに関係するＳＳＯ＿ａｕｔｈ＿ＩＤと一致しても、一致しなくてもよい。

一方、インターネットに関与するユーザは、様々なサービスプロバイダにおいて幅広いユーザ識別情報を有する。ユーザは、各サイトのアカウントにアクセスするために、サービスプロバイダごとの現在の多様な識別情報を維持することを希望するかもしれない。本発明では、このような識別情報は「サービスプロバイダユーザ識別情報」（ＳＰ＿ｕｓｅｒ＿ＩＤ）と呼ばれ、ある特定のサービスプロバイダ（ＳＰ）におけるユーザの識別情報を表現する。このＳＰ＿ｕｓｅｒ＿ＩＤは所有ユーザとある特定のＳＰとの間のみで意味を有する。

これまでの段落では、ユーザのホームオペレータ、すなわち、ＡＰにおいてユーザを一意的に認証する、少なくとも１つのＳＳＯ＿ａｕｔｈ＿ＩＤの相関キーとしてユーザのＳＳＯ＿ＭＡＩＮ＿ＩＤを説明するとともに、ある特定のサービスプロバイダにおけるユーザを識別するＳＰ＿ｕｓｅｒ＿ＩＤについて説明してきた。一般的なシナリオでは、ＳＳＯ＿ＭＡＩＮ＿ＩＤ、ＳＳＯ＿ａｕｔｈ＿ＩＤ、およびＳＰ＿ｕｓｅｒ＿ＩＤは相互に一致することはなく、ユーザはいずれかの識別情報を他の実行主体に提供することを希望しない。この場合、双方で共有されるＩＤ、いわゆるＳＨＡＲＥ＿ＩＤにより、ユーザはＳＰおよびＡＰに把握されているだろう。このＳＨＡＲＥ＿ＩＤは永続的なものであっても、考慮される指定のシナリオによる一時的なものであってもよい。この識別情報は、ＳＰおよびＡＰが同じユーザを指し示すために使用する不透明な処理として考えることができる。

このため、本発明の一面によると、認証プロバイダは、ＳＳＯ＿ａｕｔｈ＿ＩＤ、ＳＳＯ＿ＭＡＩＮ＿ＩＤ、およびＳＨＡＲＥ＿ＩＤを相関演算する。一方、サービスプロバイダは、ＳＰ＿ｕｓｅｒ＿ＩＤおよびＳＨＡＲＥ＿ＩＤを相関演算する。これらの識別情報間の例示的な関係が非限定的に図１０に示される。様々な実行主体がこれらの識別情報を管理する方法、および、これらの識別情報を相互にリンクさせる方法については、本発明ではこれ以上の説明を行なわない。

上述の図４に示されるアーキテクチャモデルによると、図２および図３の各シーケンスを参照して説明した使用ケースの特定の側面に関して、さらに詳細な実施形態が提供される。これらの使用ケースについて既に説明しているように、ユーザがＳＰにアクセスするためにＳＳＯ認証を自身のホームサイトに要求する（Ｃ−２３）場合、ユーザが予め認証されているか否かによって異なる動作が要求されるであろう。

図５Ａから図５Ｃにそれぞれ示される３つのシーケンス化された動作のセット（シーケンスＩ、II、およびIII）を含め、図６の実施形態は、図４のアーキテクチャモデルにおける図２の使用ケースの詳細を説明するものである。ここでは、ＳＰにアクセスするユーザは未だ自身のホームネットワークにより認証されていないものとする。

図６のメカニズムは、ユーザがＳＰにアクセスし（Ｃ−２１）、自身のホームサイトへとリダイレクトされる（Ｃ−２２）と開始される。図５Ａの第１シーケンス（I）は、ユーザが自身のウェブサーバからＳＳＯ認証ｈｔｔｐ要求を発行する（Ｃ−２３’）状況を示している。以前に発生したＳＳＯセッションからユーザのウェブエージェントに格納されたものがある場合、ユーザ識別は、暗号化されたクッキーにより行なうことができるだろう（Ｃ−２３”）。ＳＳＯセッションに使用されるコンピュータに物理的にアクセスすることによって、あるいは、ウェブブラウザからクッキーを盗むことを意図したスクリプトによって、第三者がクッキーを取得することがないよう、ユーザ識別情報であるＳＳＯ＿ＭＡＩＮ＿ＩＤの漏洩を防ぐために、クッキーの暗号化が推奨される。クッキーはＡＰにより生成・暗号化され、後でＡＰにより復号化されるので、暗号化アルゴリズムおよびキー管理は完全にＡＰに任せられている。ユーザのウェブブラウザはクッキーの内容を理解する必要はない。このプロセスを安全にし、ウェブサーバへのネットワークパスにおけるクッキーを盗むことを防止するために、接続は常にｈｔｔｐｓを介して行なわれるべきであろう。そのクッキーに格納されるユーザ識別情報は、ＳＳＯ＿ＭＡＩＮ＿ＩＤとして選択されるべきである。プライバシー上の理由からＭＳＩＳＤＮまたはＩＭＳＩ以外の識別情報を使用するのが便利であろう。

具体的には、ユーザのウェブブラウザは、ＡＰフロントチャネルに位置するウェブフロントエンド（４２）（以降ウェブＦ／Ｅ）に向けられる。ユーザが始めてこれにアクセスすると、ＳＯＡＰ（Simple Object Access Protocol）クライアントなどの認証ウェブサービスのクライアント側を実現するソフトウェアとともにプラグインが自動的にダウンロードされる。続いて、ウェブＦ／Ｅは、ＳＳＯセッションマネージャ（４１）とインタフェースし、関連のＩＭＳＩまたは同様の目的で使用されるほかのユーザ識別情報と関連付けられているアクティブなセッションが存在するか否かを判定する。この考慮中のケースでは、ユーザは予め認証されていないので、この時点でアクティブなセッションは存在しない。

図６のプロセスは、図５Ｂに示すような第２シーケンス（II）を使用して継続することになる。ここで、ＳＳＯセッションマネージャ（４１）は、アクティブなセッションがないことをウェブＦ／Ｅに通知する（Ｃ−５０１）。ユーザは、自身の認証が必要であることを通知される（Ｃ−５０２）。ＡＰフロントチャネルのウェブＦ／Ｅに到達すると、ユーザは利用可能な様々な認証メカニズムの中からＳＩＭカードを介して認証されることを選択するかもしれない（Ｃ−５０３）。ＳＯＡＰクライアントがこのようなサービスを呼び出す。尚、ＳＯＡＰクライアントは、ユーザがこの認証メカニズムを選択する前ではなく、選択した後にダウンロードされてもよく、このことは本発明の趣旨に影響しない。ユーザがＳＩＭカードを用いて認証されることを希望する場合、ウェブＦ／Ｅに提示すべき識別情報（Ｃ−５０５）はＩＭＳＩであり、これはＳＩＭに格納されていることが想定される。必要なセキュリティを損なうことなく安全な接続、すなわち、ｈｔｔｐｓを介してダイアログ処理が行なわれるものと想定すると、ＩＭＳＩは、好ましくは、ＳＯＡＰ要求に含まれて送信されるべきである。ＳＳＯセッションマネージャは再度コンタクトを受ける（Ｃ−５０６）。ユーザがアクティブなセッションを確立させていないことを検出すると、ＲＡＤＩＵＳクライアントとして機能し、認証／許可／アカウント処理（ＡＡＡ）サーバ（４４）へのアクセスを要求する（Ｃ−５０７、Ｃ−５０８）。ＳＩＭベースの認証が選択されているものとすると、ＩＭＳＩは適用可能な識別情報として使用され、ＥＡＰ（Extensible Authentication Protocol）の属性値ペア（ＡＶＰ）およびユーザ名ＡＶＰに埋め込まれる。

この段階では、使用する認証メカニズムに依存して、ＡＡＡサーバ（４４）は、バックエンド認証サーバ（７２）（以降Ｂ／Ｅ認証サーバ）に対し、認証チャレンジの提供を要求してもよい（Ｃ−５０９、Ｃ−５１０）。この「Ｂ／Ｅ認証サーバ」は、ネットワークアクセス識別子（ＮＡＩ）の領域部分の観点からルーティングが行なわれるであろうＲＡＤＩＵＳメッセージを介して、到達するのが好ましい。ＲＡＤＩＵＳクライアントとして機能するＳＳＯセッションマネージャは、このようなＮＡＩ領域を修正することができる。一度ユーザ認証識別情報およびＥＡＰ ＡＰＶの信用証明を含むアクセス要求メッセージを受信すると、「Ｂ／Ｅ認証サーバ」はさらなる信用証明を必要としてもよい（Ｃ−５１０からＣ−５１７）。このプロセスはさらなるＥＡＰ往復を伴う。

一度ユーザの認証に成功すると、ＡＡＡサーバ（４４）は、ＳＳＯセッションマネージャにアクセス受諾メッセージを送り返す（Ｃ−５１８）。ＳＳＯセッションマネージャ（４１）は、セッションデータベースにおいて、ＳＳＯ＿ａｕｔｈ＿ＩＤおよびＳＳＯ＿ＭＡＩＮ＿ＩＤを含むそのユーザに対するエントリを作成しなければならない。ＳＳＯセッションマネージャが未だＳＳＯ＿ＭＡＩＮ＿ＩＤを把握していない場合は、ユーザに対するルックアップキーとしてＳＳＯ＿ａｕｔｈ＿ＩＤを提供することによって、識別マネージャ（７０）に問い合わせ（クエリー）を実行する（Ｃ−５１９）。ＳＳＯ＿ＭＡＩＮ＿ＩＤを格納し、識別マネージャを介する要求により、ＳＳＯセッションマネージャにＳＳＯ＿ＭＡＩＮ＿ＩＤを供給する（Ｃ−５２２）ために、共通ディレクトリサービス（以降ＣＤＳと呼ぶ）を備えることによって、さらなる利点が生じよう（Ｃ−５２０、Ｃ−５２１）。ここで、ＳＳＯセッションマネージャ（４１）は、ユーザ認証中に使用される特定のＳＳＯ＿ａｕｔｈ＿ＩＤおよびＳＳＯ＿ＭＡＩＮ＿ＩＤを含めることによって、そのユーザに対するエントリ、すなわち、セッションをセッションデータベース（４３）に作成する。このエントリが一度ＳＳＯセッションマネージャにおいて作成されると、図５Ｂでは不図示のウェブＦ／Ｅにおける追加ロジックが、例えば、ユーザのウェブブラウザにクッキーを送信することによって、後続するｈｔｔｐ要求らの間のセッション状態を維持しなければならない。

この認証プロセス中、ＡＰバックチャネルとの関係は存在せず、未だ表明情報も生成されていないことは明らかであろう。ＳＳＯ＿ＭＡＩＮ＿ＩＤ、ＳＳＯ＿ａｕｔｈ＿ＩＤ、選択された認証メカニズム、およびユーザに属するＩＰアドレスまたはＭＳＩＳＤＮのようなアドレス情報を含む新規のセッションのみが、ある特定のユーザに対して作成される。

シーケンスIIに続いて、図６のプロセスが、図５Ｃに示すような第３のシーケンス（III）を用いて継続される。ある特定のユーザに対して有効なセッションを確立した後で、ＳＳＯセッションマネージャ（４１）は、識別マネージャ（７０）から対応するサービスプロバイダ（ＳＰ）に対するユーザの識別情報、すなわち、ＳＨＡＲＥ＿ＩＤを取得する（Ｃ−５５０、Ｃ−５５１）。このＳＰは、ユーザを自身のホーム認証プロバイダ（ＡＰ）にリダイレクトすることによって最初の要求を発信したＳＰである。図５Ｃには示されていないが、このＳＨＡＲＥ＿ＩＤおよびこの識別情報が使用されている対応ＳＰは、ユーザに対するマスタセッションエントリと関連付けられたセッションデータベース（４３）に格納される。

上述の識別情報マッピングが一度行なわれると、ＳＳＯセッションマネージャ（４１）は、ある特定のＳＨＡＲＥ＿ＩＤおよびある特定のサービスプロバイダに対して認証表明を生成するために、セキュリティ表明マークアップ言語（ＳＡＭＬ）エンジン４５におけるサービスを呼び出す（Ｃ−５５２）。認証表明は、認証プロセスの発生日時など、他の関連データと、具体的な認証メカニズムに関連するセキュリティ強度とを含む。認証表明は、表明データベース（４６）に格納されるが、その際には表明参照によってインデックス化されていてもよい（Ｃ−５５３）。このため、認証表明には後で一意的に識別するための「表明参照」が付与されている。表明参照は、ＳＡＭＬエンジンにおいて符号化された上で、認証結果に搭載される。認証結果は、ＡＰウェブＦ／Ｅを介する（Ｃ−５５５）ユーザへのさらなる送信（Ｃ−２５）のために、ＳＳＯセッションマネージャへと戻される（Ｃ−５５４）。

このような認証結果は、ＵＲＬの一部、すなわち、パラメータとして符号化されてユーザに戻されるのが好ましい。同時に、ユーザのウェブブラウザはＳＰに送信された最初のＵＲＬにリダイレクトされる。実際には、この情報は、ＳＰからＡＰへの最初のリダイレクトによって受信されたＵＲＬ中のパラメータとして取得されたものである。従って、ＳＰから取得された最初のＵＲＬ、すなわち、ターゲットリソースはＡＰウェブＦ／Ｅに格納されているべきである。

その後、ユーザは最初に接触したＳＰに認証結果を送信して提示する（Ｃ−２６）。ＳＰは認証結果を受信して、復号化した後に表明参照と、表明を発行したＡＰの識別情報とを抽出する。ＳＰはこの情報を使用してＳＰバックチャネル（４”）とＳＡＭＬダイアログを確立し（Ｃ−２７）、ＳＡＭＬ表明要求メッセージにおいて認証結果を提示することによってオリジナルの表明を要求する。表明に対する要求を受信すると（Ｃ−２７）、ＡＰバックチャネルのＳＡＭＬエンジン（４５）は、表明データベース（４６）から表明を取得し（Ｃ−５５６、Ｃ−５５７）、デジタル署名を施し、ＳＰに送り返す（Ｃ−２８）。

ＳＰは、好ましくは独自の公開鍵インフラストラクチャ（ＰＫＩ）を利用するか、あるいは、さらに説明されるより一般的なケースでは、信頼できる認証仲介局のＰＫＩを利用することによって、表明の有効性をチェックする。

一度表明がＳＰにおいて有効であると証明され、発信元が信頼できるものであることが判明すると、ＳＰは表明内容を解析し、表明に含まれる認証事実に従ってローカルポリシーの実施へと処理を進めることができる。最終的に、ユーザはサービスアクセス受諾を通知される（Ｃ−２９）。

図６に関する上記説明は、図５Ａから図５Ｃにおいて説明された好適な実施形態とともに、図２に関して予め提示された使用ケースに対してアーキテクチャの詳細を提供するものであることが明らかであろう。このアーキテクチャの詳細は、説明目的のために提供するのであって、限定のために提供するものではない。

図５Ａから図５Ｃにそれぞれ示す３つのシーケンス化された動作のセット（シーケンスI、II、およびIII）を含めることによって、図７Ａおよび図７Ｂの実施形態と、図４のアーキテクチャモデルにおける図２の使用ケースの詳細を説明する。ここでは、ＳＰにアクセスするユーザは既に自身のホームネットワークにより認証されているものとする。具体的には、図７Ａはホームネットワークにおける認証プロバイダの前に、ユーザの分離認証を示している。一方、図７ＢはユーザがＳＰにアクセスし、自身のホームネットワークに一度リダイレクトされて、ユーザが既に認証され、かつアクティブな有効なセッションを有していることが判明した場合に、実行される動作を示している。

図７Ａのメカニズムは、図５Ａに示す第１シーケンス（I）を使用して直接的に開始される。第１シーケンス（I）において、ユーザは自身のウェブサーバからＳＳＯ認証ｈｔｔｐ要求を発行する（Ｃ−２３’）。利用可能であれば、続いて、図６の使用ケースに関して示された対応するシーケンスのように、ＡＰフロントチャネルのウェブＦ／Ｅに対して送信される暗号化されたクッキー（Ｃ−２３”）を用いてユーザ識別を行なう。ウェブＦ／ＥはＳＳＯセッションマネージャ（４１）とインタフェース処理を実行し（Ｃ−５００）、ユーザと関連付けられるアクティブなセッションが存在するか否かをチェックする。シーケンスのフローは、図５Ｂに示す第２シーケンス（II）へと続く。ここで、ユーザにより選択された認証手順が実行されてもよい。特に、ＳＳＯセッションマネージャ（４１）がセッションデータベース（４３）においてユーザに対するセッションを一度作成すると、実際に特定のＳＳＯ＿ａｕｔｈ＿ＩＤおよびＳＳＯ＿ＭＡＩＮ＿ＩＤを含むことによって、ＳＳＯセッションマネージャはＡＰウェブＦ／Ｅに通知する。ここで、図５Ｂでは不図示の追加ロジックが後続のｈｔｔｐ要求に対するセッション状態を維持する。最終的には、図７Ａに示すように、ＡＰウェブＦ／Ｅはユーザのウェブブラウザに対してサインオンが成功したことを承認する（Ｃ−７０）。

既に認証されているこのユーザは、ＳＰへのサービスアクセスを要求してもよい（Ｃ−２１）。このＳＰは、認証仲介局が必要でない図２の使用ケースに関して述べた想定下で、ユーザを自身のホームサイトへとリダイレクトする（Ｃ−２２）。図５Ａのシーケンスに続いて、ユーザは再度ＡＰウェブＦ／Ｅ（４２）にアクセスする。有効なセッションが活きているか否かをチェックするために、ＡＰウェブＦ／Ｅ（４２）からは、ＳＳＯセッションマネージャ（４１）に対して指示が発行される。次に、セッションデータベース（４３）と協働するであろうＳＳＯセッションマネージャ（４１）は、そのユーザに対してセッションが既に存在することを探索する。図５Ｃの第３のシーケンス（III）に示すように、ＳＳＯセッションマネージャ（４１）は、そのＳＰに使用すべきＳＨＡＲＥ＿ＩＤを取得し（Ｃ−５５０、Ｃ−５５１）、前記ＳＨＡＲＥ＿ＩＤに対する表明の生成・格納と認証結果への搭載を命令する（Ｃ−５５２、Ｃ−５５３、Ｃ−５５４）。認証結果はウェブＦ／Ｅを介して（Ｃ−５５５）ユーザに戻され（Ｃ−２５）、前述の使用ケースのようにＳＰに提示される（Ｃ−２６）。ＳＰは、ＡＰバックチャネル（４”）を用いてオリジナルの表明をチェックし（Ｃ−２７、Ｃ−５５６、Ｃ−５５７、Ｃ−２８）、最終的にユーザに対してサービスアクセス受諾を提供する（Ｃ−２９）。

これまでの段落では、図２に示した使用ケースに関する詳細な実施形態を説明してきた。ここでは、ユーザが認証されていない状態でＳＰにアクセスする図６に示す第１動作と、最初に認証されてからユーザがサービス受諾を与えられる図７Ａおよび図７Ｂに示す第２動作とを区別している。

本発明の別の側面によると、図３を参照して先に説明した使用ケースを、図４に示したアーキテクチャモデルに関してさらに説明する。特に、実施形態らは認証仲介局および対応する新規のインタフェースを含んでおり、これにより差別化されている。

図３に示すように、ＭＮＯ−Ｂなどの特定のセルラーオペレータを介してセルラーＳＳＯ連盟（ＦＳＳＯ−１）と提携する、ある特定のサービスプロバイダ（ＳＰ−２）にアクセスするユーザ（Ｕｓｅｒ＠ＭＮＯ−Ａ）が、連盟のメンバである別のセルラーオペレータ（ＭＮＯ−Ａ）の加入者である場合には、第２使用ケースが発生する。この第２使用ケースでは、本発明の一側面によると、ＳＰ（ＳＰ−２）からの転送を受信し、ユーザのホームサイトを解析し、ユーザが所属するＭＮＯへとリダイレクトするために、認証仲介局（ＡＢ）が必要となる。

図８は、ホームサイトの適切な認証プロバイダ（ＡＰ）へとユーザリダイレクトする前に、ユーザとＡＢとの間で実行される動作を示している。具体的に、図８は、図４に示すアーキテクチャモデルに関連して、これらの動作を示している。一方、図３はＡＢが含むであろう全ての装置を考慮に入れていない。このため、図３のように、ユーザが認証仲介局（ＡＢ）に向けてＳＰ−２に対する認証要求（Ｃ−３３）を発行する場合、図８が示すように、仲介局チャネル（２）のＡＢウェブＦ／Ｅ（２１）において受信されるｈｔｔｐ転送が実際に存在する。ユーザのホームサイト名がＡＢウェブＦ／Ｅから要求される（Ｃ−３４、Ｃ−３５）。この要求は、例えば、連盟の全てのＡＰを伴ってユーザに対してウェブページを提示することによって行なわれるであろう。ここで、ユーザは自身のホームオペレータのロゴ上をクリックするだけでよい。続いて、認証プロバイダ（ＡＰ）データベース（２２）からユーザのホームサイトに対するＵＲＩが取得される（Ｃ−８４、Ｃ−８５）。最終的に、ＡＢウェブＦ／Ｅ（２１）はユーザのｈｔｔｐを自身のホームサイトの適切なＡＰへとリダイレクトする（Ｃ−３６）。ＡＢは、ユーザのホームに関連する問合せについて、今後の連続的な繰り返しを避けるために、ユーザのウェブブラウザにクッキーを残してもよい。フローシーケンスは、図６または図７Ａおよび図７Ｂに示す使用ケースに関して説明したように、ＡＰウェブＦ／Ｅ（４２）に対するＳＳＯ認証要求（Ｃ−２３、Ｃ−２３’、Ｃ−２３”）を使用して、継続される。

図９は、どこで認証表明の有効性検証処理がなされるべきかを探索するために、ユーザのホーム解析に関してサービスプロバイダとＡＢとの間で実行される動作を示す。具体的に、図９は、図４に示すアーキテクチャモデルに関連するこれらの動作を示している。なお、図３はＡＢが含むであろう全ての装置を考慮に入れていない。ユーザが図３および図９に示すように、認証結果をＳＰ（ＳＰ−２）に提示した後、ユーザのホーム解析がＡＢに要求される（Ｃ−３７）。この要求は仲介局チャネル（２）のＡＢウェブＦ／Ｅ（２１）で受信される。ＡＢウェブＦ／Ｅ（２１）は、ＳＰに送り返されたホームサイトのＡＰのＵＲＩをＡＰデータベース（２２）に要求する（Ｃ−９１、Ｃ−９２）。好ましくは、ＳＰが、ＤＮＳ技術を使用することによって、ホームＵＲＩを解析し、最終的に認証表明を有効性を検証する（Ｃ−２７、Ｃ−２８）。この認証表明は、図３に示すように、予め取得されている（Ｃ−２３、Ｃ−２４、Ｃ−２５）ものである。具体的には、図６または図７Ａおよび図７Ｂの使用ケースに関して説明したとおりである。認証表明の有効性検証（Ｃ−２７、Ｃ−２８）は、プロトコル結合部（４７）を介してＳＡＭＬエンジン（４５）に向けてＳＰ（ＳＰ−２）から発行されてもよい。このプロトコル結合部（４７）は、ＳＡＭＬエンジンとＳＰとの間に配置されるのが有利である。プロトコル結合部（４７）の構成要素は、例えば、ｈｔｔｍｓのようなトランスポートプロトコルからＸＭＬインスタンスを解き、これを、ＳＡＭＬエンジンを介して渡すよう構成されている。ＳＰはＳＡＭＬ基準で定義されるいかなる型の問合せも作成することができる。

後者の使用ケースにおける表明の有効性のチェックに関して、ＳＰは全てのＰＫＩの複雑な構造を実装する必要もないし、連盟の全ての認証プロバイダから証明をローカルでインストールするよう実装する必要もない。なお、ＳＰは連盟の信頼できるエンティティの証明、すなわち、この認証仲介局のホストを務めるＡＰの証明をインストールするために、全てのＰＫＩの複雑な構造を実装する必要がある。

以上の教示から、本発明の変更および変形の多くが可能であることは明らかである。従って、開示された概念の範囲内であれば、本発明は説明された特定のものと異なるように実施されてもよいことは、理解されるべきである。

本発明の特徴、目的、および利点は、添付の図面と共に本明細書を読むことで明白になるであろう。
図１は、シングルサインオンサービス用のセルラー連盟のアーキテクチャ／ビジネス参照モデルを概略的に表す図である。 図２は、サービスプロバイダが、ユーザと契約を結んでいる移動通信ネットワークオペレータと業務契約を結んでいる基本的なシナリオにおいて、ユーザを認証しかつサービスプロバイダにより提供されるサービスへのアクセスを認証するプロセスを示す簡易なシーケンス図である。 図３は、より一般的なシナリオにおいて、ユーザを認証しかつサービスプロバイダにより提供されるサービスへのアクセスを認証するプロセスを表現する別の簡易シーケンス図である。このシナリオでは、サービスプロバイダは、ユーザと契約を結んでいる移動通信ネットワークオペレータ以外の移動通信ネットワークオペレータと業務契約を結んでいる。両移動通信ネットワークオペレータはセルラー連盟に含まれる。 図４は、一般的に、ユーザ、サービスプロバイダ、認証仲介局、および認証プロバイダを伴う例示の内部アーキテクチャおよびメインインタフェースを提示することを示す図である。 図５Ａは、予め有効な認証が行なわれていた場合に、ユーザが新規の認証プロセスを開始する、あるいは、表明プロセスを引き起こすためにいわゆるフロントチャネルを介して認証プロバイダ（ＡＰ）にアクセスするときの動作に係る第１シーケンス（I）を示す図である。 図５Ｂは、ＡＰにおけるいわゆるフロントチャネルを介して、認証バックエンド（以降、「認証Ｂ／Ｅ」と呼ぶ）の力を借りて予め認証されていないユーザを認証するために実行されるアクションの第２シーケンス（II）を示す図である。 図５Ｃは、ユーザが予め認証されており、従ってアクティブなセッションを確立していることが判明した場合に表明プロセスを達成するのに実行されるアクションの第３のシーケンス（III）を示す図である。 図６は、ユーザ、サービスプロバイダ、および認証プロバイダの間で予め認証されることなくサービスプロバイダにアクセスしたユーザを認証するために実行されるアクションのシーケンスを図５Ａから図５Ｃにおける参照を含むことにより示す概略的な構成を提示する図である。 図７Ａは、ユーザと認証プロバイダとの間でユーザの孤立した認証中に実行されるアクションのシーケンスを図５Ａおよび図５Ｂにおける参照を含むことにより示す概略的な構成を提示する図である。 図７Ｂは、既に認証されており、サービスプロバイダにアクセスしているユーザと、サービスプロバイダと、ユーザに対する認証プロバイダとの間で実行されるアクションのシーケンスを図５Ａおよび図５Ｃにおける参照を含むことにより示す概略的な構成を提示する図である。 図８は、好適なアーキテクチャモデルに従った図３の一部のステップに関する詳細な実施形態を示す図である。 図９は、好適なアーキテクチャモデルに従った図３における他の一部のステップに関するより詳細な実施形態を示す図である。 図１０は、認証プロバイダにおいて管理されるＳＳＯ＿ａｕｔｈ＿ＩＤと、ＳＳＯ＿ＭＡＩＮ＿ＩＤと、ＳＨＡＲＥＤ＿ＩＤとの間の例示の関係を示す図である。

Claims (24)

1. 選択されたサービスプロバイダにアクセスするユーザにシングルサインオンサービスを提供する通信システムにおいて、該ユーザは、第１移動通信ネットワークオペレータに加入しており、
   第１移動通信ネットワークと少なくとも１つの第２移動通信ネットワークと、
   複数のサービスプロバイダの少なくとも１つのサービスプロバイダであって、認証局により前記少なくとも１つのサービスプロバイダに対して前記移動通信ネットワークオペレータの加入者が一度認証されると前記加入者にサービスを提供するサービスプロバイダとを含む通信システムであって、
   前記第１移動通信ネットワークと前記少なくとも１つの第２移動通信ネットワークとを含むセルラー連盟の移動通信ネットワークオペレータが、前記認証局として機能するものであり、前記通信システムは、
   前記少なくとも１つのサービスプロバイダに対して前記ユーザを認証する権原を有する前記セルラー連盟の唯一のメンバとして、前記第１移動通信ネットワークに所属する認証プロバイダと、
   前記第２移動通信ネットワークらのうち特定の第２移動通信ネットワークに所属し、かつ該特定の第２移動通信ネットワークのオペレータとエントリーポイント契約を結んでいる前記サービスプロバイダらから、前記セルラー連盟へのエントリーポイントとして機能するよう構成される認証仲介局と、
   前記ユーザが、前記サービスプロバイダにアクセスする際に、前記認証仲介局に関与されることなく、該ユーザのホームとなる移動通信ネットワークオペレータとエントリーポイント契約を結んでいるサービスプロバイダにアクセスする該ユーザを、該ユーザのホームとなる移動通信ネットワークオペレータの認証プロバイダに向けてリダイレクトする手段と
   を含み、
   前記第１移動通信ネットワークオペレータに所属する前記認証プロバイダは、前記認証仲介局に関与されることなく、前記第１移動通信ネットワークオペレータとエントリーポイント契約を結んでいる前記サービスプロバイダらから直接的にアクセスされ、
   前記第１移動通信ネットワークオペレータと契約を結んでいるサービスプロバイダは、ユーザについて認証表明の有効性の検証を、認証仲介局に関与されることなく、前記第１移動通信ネットワークオペレータの認証プロバイダに要求する
   ことを特徴とする通信システム。
2. 前記ユーザがサービスプロバイダにアクセスする際に、該ユーザによりアクセスされる該サービスプロバイダとエントリーポイント契約を結んでいる第２ネットワークのオペレータの認証仲介局に向けて、該ユーザをリダイレクトする手段と、
   前記認証仲介局にアクセスする前記ユーザを、前記ユーザのホームネットワークに存在する認証プロバイダに向けてリダイレクトする手段と
   をさらに含むことを特徴とする請求項１に記載の通信システム。
3. サービスプロバイダとエントリーポイント契約を結んでいる第２移動通信ネットワークオペレータの認証仲介局においてユーザのホーム解析を実行し、前記第１移動通信ネットワークに所属する前記認証プロバイダに対して該ユーザに係る認証表明の有効性の検証を該サービスプロバイダが要求することを許可する手段をさらに含むことを特徴とする請求項２に記載の通信システム。
4. 前記セルラー連盟の加入者である前記ユーザが特定のサービスプロバイダにアクセスする際に、該特定のサービスプロバイダについて該ユーザの認証処理を担当している認証プロバイダに対して、該ユーザから、シングルサインオンの認証要求を発行する手段と、
   受信した認証結果を前記特定のサービスプロバイダに対して提示する手段と
   をさらに含むことを特徴とする請求項３に記載の通信システム。
5. 前記セルラー連盟の加入者である前記ユーザが特定のサービスプロバイダにアクセスする際に、該特定のサービスプロバイダについて該ユーザの認証処理を担当している認証プロバイダに対して、該ユーザから、シングルサインオンの認証要求を発行する手段と、
   受信した認証結果を前記特定のサービスプロバイダに対して提示する手段と
   さらに含むことを特徴とする請求項１に記載の通信システム。
6. 前記ユーザは、所与の認証プロバイダと所与のサービスプロバイダとの間で共有される識別情報によって識別され、該共有される識別情報は、該ユーザと該所与の認証プロバイダとの間で使用されている認証識別情報から独立しているとともに、該ユーザと該所与のサービスプロバイダとの間で使用されている該ユーザの識別情報からも独立していることを特徴とする請求項１に記載の通信システム。
7. 前記セルラー連盟におけるセキュリティ条件とプライバシー条件とを充足させるための公開鍵インフラストラクチャ手段と、
   前記セルラー連盟の設備内において前記ユーザに係る複数の識別情報間の関係を維持および処理するとともに、該ユーザについての該複数の識別情報を各サービスプロバイダの設備下で維持および処理する識別マネージャと、
   シングルサインオン用の主たる識別処理によってアクセス可能なユーザの識別情報を記憶する共通ディレクトリサービス手段と、
   前記ユーザによって選択された認証メカニズムに依存する認証チャレンジを生成するように意図されたバックエンド認証サーバと
   のうち少なくとも１つを含むことを特徴とする請求項６に記載の通信システム。
8. 第１移動通信ネットワークオペレータに加入しかつ選択されたサービスプロバイダにアクセスするユーザに、シングルサインオンサービスを提供する方法であって、各選択されたサービスプロバイダが第２移動通信ネットワークオペレータと提携しており、前記方法は、
   （ａ）前記第１移動通信ネットワークオペレータと前記第２移動通信ネットワークオペレータとの間で認証信頼関係を確立し、移動通信ネットワークオペレータの連盟を形成するステップと、
   （ｂ）前記選択されたサービスプロバイダから前記第１移動通信ネットワークオペレータのセルラーネットワークに向けて、前記ユーザにより生成されるアクセス要求をリダイレクトするステップと、
   （ｃ）前記ユーザのアクセス要求がリダイレクトされる前記第１移動通信ネットワークオペレータの認証プロバイダにおいて、前記サービスプロバイダにアクセスする該ユーザに対して有効な認証表明を生成し、前記認証表明についての結果を該ユーザに返送するステップと、
   （ｄ）前記サービスプロバイダから前記第１移動通信ネットワークオペレータの前記認証プロバイダに対して、前記ユーザにより提示される前記結果に含まれる前記認証表明について有効性の検証を要求するステップと、
   （ｅ）前記サービスプロバイダにおいて検証成功応答を受信すると、前記ユーザへのサービスアクセスを受諾するステップと
   を含むことを特徴とする方法。
9. 前記第１移動通信ネットワークオペレータと前記第２移動通信ネットワークオペレータはセルラー連盟に含まれており、前記ステップ（ａ）は、前記選択されたサービスプロバイダと提携している該移動通信ネットワークオペレータに依存して、
   （ａ１）前記選択されたサービスプロバイダが、前記第１移動通信ネットワークのオペレータと提携している場合に、前記ユーザについて担当することになる該第１移動通信ネットワークオペレータに係る認証プロバイダを決定するステップと、
   （ａ２）前記選択されたサービスプロバイダが前記第２移動通信ネットワークオペレータと提携している場合に、前記ユーザについて担当する前記第１移動通信ネットワークオペレータに係る認証プロバイダを決定する、前記第２移動通信ネットワークオペレータに係る認証仲介局に、前記ユーザにより生成された前記アクセス要求をリダイレクトするステップと
   のうちいずれかのステップを含むことを特徴とする請求項８に記載の方法。
10. 前記ステップ（ｂ）は、
    （ｂ１）前記ユーザからシングルサインオンの認証要求を受信するステップと、
    （ｂ２）前記ユーザが過去に認証されているかどうかを判定するステップと、
    （ｂ３）前記ユーザが未だに認証されておらず、有効かつアクティブなセッションが存在しない場合に提供される、前記選択されたサービスプロバイダにアクセスする前記ユーザについてのユーザ嗜好に従ってチャレンジ／応答認証処理を実行するステップと、
    （ｂ４）前記選択されたサービスプロバイダにアクセスする前記ユーザについて認証表明を生成するステップと
    を含むことを特徴とする請求項８に記載の方法。
11. 前記第１移動通信ネットワークオペレータと前記第２移動通信ネットワークオペレータはセルラー連盟に含まれており、前記ステップ（ｃ）は、前記選択されたサービスプロバイダと提携している該移動通信ネットワークオペレータに依存して、
    （ｃ１）前記サービスプロバイダが前記第１移動通信ネットワークオペレータと提携している場合に、前記ユーザによって提示された前記認証表明について有効性を検証する、該第１移動通信ネットワークオペレータに係る認証プロバイダを決定するステップと、
    （ａ２）前記選択されたサービスプロバイダが前記第２移動通信ネットワークオペレータと提携している場合に、前記選択されたサービスプロバイダから特定の第２移動通信ネットワークオペレータに係る認証仲介局に対し、前記ユーザのホームサイトの解析処理を要求するステップと
    のうちいずれかのステップを含むことを特徴とする請求項８に記載の方法。
12. 前記ステップ（ｄ）は、
    （ｄ１）前記選択されたサービスプロバイダにアクセスする前記ユーザについて記憶されている認証表明を抽出するステップと、
    （ｄ２）前記選択されたサービスプロバイダに、表明検証応答を返送するステップと
    をさらに含むことを特徴とする請求項８に記載の方法。
13. 前記ユーザは、所与の認証プロバイダと所与のサービスプロバイダとの間で共有される識別情報によって識別され、該共有される識別情報は、該ユーザと該所与の認証プロバイダとの間で使用されている認証識別情報から独立しているとともに、該ユーザと該所与のサービスプロバイダとの間で使用されている該ユーザの識別情報からも独立していることを特徴とする請求項８に記載の方法。
14. 選択されたサービスプロバイダにアクセスするユーザにシングルサインオンサービスを提供する通信システムの認証仲介局であって、前記ユーザは、第１移動通信ネットワークオペレータに加入しており、前記選択されたサービスプロバイダのそれぞれは第２移動通信ネットワークオペレータと提携しており、
    前記認証仲介局は、
    認証仲介局ウェブフロントエンドを含み、
    前記認証仲介局ウェブフロントエンドは、
    第１移動通信ネットワークオペレータに加入しているユーザと通信するための第１インタフェース手段と、
    第２移動通信ネットワークオペレータと提携するサービスプロバイダと通信するための第２インタフェース手段と
    前記第１および第２インタフェース手段から形成される仲介局チャネルであって、前記認証仲介局が前記ユーザを前記ユーザのホームネットワークへとリダイレクトし、前記サービスプロバイダについて前記ユーザのホームネットワークを解析できるようにする仲介局チャネルと、
    前記セルラー連盟に含まれる各移動通信ネットワークオペレータを基準として、前記セルラー連盟内の全ての認証プロバイダに関わる記憶装置と
    を含むことを特徴とする認証仲介局。
15. 前記ユーザと前記認証仲介局とはともに前記第１移動通信ネットワークオペレータに属し、前記選択されたサービスプロバイダのいくつかは前記第１移動通信ネットワークオペレータと提携していることを特徴とする請求項１４に記載の認証仲介局。
16. 前記認証仲介局ウェブフロントエンドは、さらに、前記記憶装置から前記ユーザのホームに関連するアドレスデータを抽出する手段を含むことを特徴とする請求項１４に記載の認証仲介局。
17. 前記認証仲介局ウェブフロントエンドは、さらに、前記認証仲介局を所有する前記移動通信ネットワークオペレータと提携している前記サービスプロバイダらに、公開鍵インフラストラクチャサービスを提案する手段を含むことを特徴とする請求項１４に記載の認証仲介局。
18. 選択されたサービスプロバイダにアクセスするユーザにシングルサインオンサービスを提供する通信システムの認証プロバイダであって、前記ユーザは、第１移動通信ネットワークオペレータに加入しており、前記選択されたサービスプロバイダのそれぞれは第２移動通信ネットワークオペレータと提携しており、
    前記認証プロバイダは、
    前記ユーザと前記認証プロバイダとの間に認証セッションを確立する第１インタフェース手段を含むウェブフロントエンドを有すフロントチャネルと、
    前記ユーザがアクセスする前記選択されたサービスプロバイダと前記認証プロバイダとの間でユーザ認証表明に関する情報を交換する第２インタフェース手段を含むプロトコル結合部を有するバックチャネルと
    を含み、
    前記フロントチャネルはさらに、前記ユーザについてのセッションの状態を取り扱うセッションマネージャおよび記憶装置と、前記ユーザについて特別の認証メカニズムを実行するフロントエンド認証サーバとを含む
    ことを特徴とする認証プロバイダ。
19. 前記認証プロバイダの前記バックチャネルは、前記ユーザについて認証表明を生成するセキュリティ表明マークアップ言語エンジンと、認証表明を記憶する記憶装置とをさらに含むことを特徴とする請求項１８に記載の認証プロバイダ。
20. 前記フロントチャネルと前記バックチャネルとの間に配置される、前記ユーザについて認証表明を生成して記憶するインターワーキング手段をさらに含むことを特徴とする請求項１９に記載の認証プロバイダ。
21. 前記フロントチャネルと前記バックチャネルとの間に配置される前記インターワーキング手段の動作は、前記セッションマネージャと前記セキュリティ表明マークアップ言語エンジンとを介して実行されることを特徴とする請求項２０に記載の認証プロバイダ。
22. 前記セッションマネージャは、共通ディレクトリサービス手段を備える識別マネージャから前記ユーザについて、前記セルラー連盟の設備下におけるの複数の識別情報間の関係を抽出する手段を含み、前記ユーザについての前記複数の識別情報は、それぞれサービスプロバイダの設備下におけるものであり、前記複数の識別情報は、シングルサインオンの主たる識別処理によって相関演算されることを特徴とする請求項２１に記載の認証プロバイダ。
23. 前記フロントエンド認証サーバは前記セルラー連盟内の他のエンティティティとインターワーキング処理を実行し、前記移動通信ネットワークオペレータの設備下で特定のユーザデータを供給するバックエンド認証サーバとして機能することを特徴とする請求項１８に記載の認証プロバイダ。
24. 前記フロントエンド認証サーバは、認証サーバ、許可サーバおよびアカウントサーバであり、通常は、セルラーネットワーク内のネットワークアクセスサーバからアクセス可能であることを特徴とする請求項２３に記載の認証プロバイダ。

Images