JP2017523508A - セキュアな統合型クラウドストレージ - Google Patents

Abstract

クライアントが、第１のサービスプロバイダと関連を持ち得る第１のクラウドストレージサーバによって認証されることを要求する。識別子連携要求が、クライアントから第１のクラウドストレージサーバに送信され、識別子連携要求は、第１のクラウドストレージサーバ上のクライアントのユーザアカウントを、第２のサービスプロバイダと関連を持ち得る第２のクラウドストレージサーバ上のクライアントのユーザアカウントと連携するよう求める。クライアントは、第１のクラウドストレージサーバから第２のクラウドストレージサーバへとリダイレクトされる。クライアントが、第２のクラウドストレージサーバによって認証されることを要求し、認証されれば、第２のクラウドストレージサーバが、第１のクラウドストレージサーバ上のユーザアカウントを第２のクラウドストレージサーバのユーザアカウントとマッピングし、それらの間に識別子連携を成立させる。

Description

本出願は、概してデータストレージシステムに関し、より詳細には、セキュアな統合型クラウドストレージを実装するための技法に関する。

本項では、本発明をより良く理解するのに有用であり得る諸態様を紹介する。よって本項の記述は、かかる観点から読まれるべきであり、先行技術が含む要素の有無に関する自認として理解されてはならない。

「クラウド」という用語は、通常、クラウドコンピューティングの枠組みを実装する集合的なコンピューティングインフラを指す。たとえば、米国国立標準技術研究所（ＮＩＳＴ Ｓｐｅｃｉａｌ Ｐｕｂｌｉｃａｔｉｏｎ Ｎｏ．８００−１４５）によれば、クラウドコンピューティングとは、構成可能なコンピューティングリソース（たとえば、ネットワーク、サーバ、ストレージ、アプリケーション、およびサービス）の共有プールに対する、ユビキタスかつオンデマンドの利便性の高いネットワークアクセスを可能にするためのモデルとみなすことができる。こうしたコンピューティングリソースは、最低限の管理作業またはサービスプロバイダとの対話により、迅速にプロビジョニングし、リリースすることが可能である。

また、クラウドベースのコンピューティングシステムは、通例、ハイパーバイザを利用することによって「仮想化」機能を実装することができる。ハイパーバイザとは、物理的なコンピューティングシステムの最上位で実行され、仮想マシンや論理（ストレージ）ユニットといった仮想資産を作成および管理するソフトウェアプログラムである。ハイパーバイザは、その物理的コンピューティングシステムが持つハードウェアリソースを、動的かつ透過的な形で仮想資産に割り当てる。

よって、「クラウドストレージ」とは、仮想化されたストレージプールにデータが格納される、ネットワーク化されたオンラインストレージであるとみなされる。たとえば、こうしたクラウドストレージを備えたデータセンタをサービスプロバイダが運営し、そのサービスプロバイダを通じて自身のデータをホスティングしたいと思う顧客が同プロバイダからストレージ容量を購入またはリースするといったことが考えられる。サービスプロバイダは、必要な分のリソースを動的かつ透過的に仮想化し、ストレージプールとして公開する。顧客はそのストレージプールをデータ格納のために利用する。限定するものではないが、企業レベルのクラウドデータストレージサービスから顧客レベルのファイルホスティングサービスまで、種々のクラウドストレージサービスが数多くのサービスプロバイダによって提供されていることは知られている（このようなサービスはＳａａＳ（Ｓｔｏｒａｇｅ−ａｓ−ａ−Ｓｅｒｖｉｃｅ）としても知られている）。しかしながら、サービスプロバイダが提供するさまざまなクラウドストレージサービスの１つ１つに対し、通例は異なるＳａａＳアプリケーションプログラミングインタフェース（ＡＰＩ）が存在していることも認識されている。このＡＰＩに関する不統一性により、こうした種々のクラウドストレージサービスへのアクセスに必要なＡＰＩの数は、法外なほど多くなる。

上記の問題を解決する試みとして、Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ（ＯＭＡ）は、Ｕｎｉｆｉｅｄ Ｃｌｏｕｄ Ｄｉｓｋ（ＵＣＤ）という手法を提案している。これについては、たとえば、ＯＭＡ Ｗｏｒｋ Ｉｔｅｍ ＤｏｃｕｍｅｎｔのＷ０２７３番、２０１２年９月４日付けのＵｎｉｆｉｅｄ Ｃｌｏｕｄ Ｄｉｓｋ Ｖ１．０と題された文書に概説されている。ＵＣＤのフレームワークは、モバイルオペレータ（ここではサービスプロバイダ）のモバイルクラウドコンピューティング環境に、統合型クラウドストレージシステムを提供するものである。このＵＣＤフレームワークでは、モバイルユーザまたはアプリケーションは、標準ＳａａＳアプリケーションプログラミングインタフェース（ＡＰＩ）の使用を通じて、複数のモバイルオペレータにまたがる連携型（統合型）クラウドストレージにデータを格納することが可能となる。

ＮＩＳＴ Ｓｐｅｃｉａｌ Ｐｕｂｌｉｃａｔｉｏｎ Ｎｏ．８００−１４５ ＯＭＡ Ｗｏｒｋ Ｉｔｅｍ Ｄｏｃｕｍｅｎｔ、Ｗ０２７３、Ｕｎｉｆｉｅｄ Ｃｌｏｕｄ Ｄｉｓｋ Ｖ１．０、２０１２年９月４日 Ｃａｎｔｏｒ、Ｓｃｏｔｔ、Ｋｅｍｐ、Ｊｏｈｎ、Ｃｈａｍｐａｇｎｅ、Ｄａｒｒｙｌ編、「Ｌｉｂｅｒｔｙ ＩＤ−ＦＦ Ｂｉｎｄｉｎｇｓ ａｎｄ Ｐｒｏｆｉｌｅｓ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」、Ｖｅｒｓｉｏｎ１．２−ｅｒｒａｔａ−ｖ２．０、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ Ｐｒｏｊｅｃｔ、２００４年９月１２日 Ｃａｎｔｏｒ、Ｓｃｏｔｔ、Ｋｅｍｐ、Ｊｏｈｎ編、「Ｌｉｂｅｒｔｙ ＩＤ−ＦＦ Ｐｒｏｔｏｃｏｌｓ ａｎｄ Ｓｃｈｅｍａ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」、Ｖｅｒｓｉｏｎ１．２−ｅｒｒａｔａ−ｖ３．０、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ Ｐｒｏｊｅｃｔ、２００４年９月１２日

本発明の例示的実施形態は、セキュアな統合型クラウドストレージのための技法および装置を提供するものである。各実施形態は多種多様なデータストレージシステムに適用可能であるが、１つ以上の実施形態はＵＣＤフレームワークでの使用に特によく適合する。

たとえば、一実施形態では、方法が以下のステップを含む。クライアントが、第１のサービスプロバイダと関連を持ち得る、第１のクラウドストレージサーバによって認証されることを要求する。識別子連携要求が、クライアントから第１のクラウドストレージサーバに送信される。このとき、識別子連携要求は、第１のクラウドストレージサーバ上のクライアントのユーザアカウントを、第２のサービスプロバイダと関連を持ち得る第２のクラウドストレージサーバ上のクライアントのユーザアカウントと連携するよう求める。クライアントは、第１のクラウドストレージサーバから第２のクラウドストレージサーバへとリダイレクトされる。クライアントが、第２のクラウドストレージサーバによって認証されることを要求し、認証されれば、第２のクラウドストレージサーバが、第１のクラウドストレージサーバ上のユーザアカウントを第２のクラウドストレージサーバのユーザアカウントとマッピングし、それらの間に識別子連携を成立させる。クライアントは、第２のクラウドストレージサーバから第１のクラウドストレージサーバへとリダイレクトされ、このとき、識別子連携が成立したことの確認を受信してもよい。他の実施形態は、シングルサインオン方法、シングルログアウト方法、および識別子連携解除方法を含む。

別の実施形態では、１つ以上のソフトウェアプログラムの実行可能コードが内部に符号化されたプロセッサ可読記憶媒体を備えた、製品が提供される。この１つ以上のソフトウェアプログラムは、少なくとも１つの処理デバイスによって実行されると、上記の方法のステップを実施する。

さらに別の実施形態では、装置が、メモリと、上記の方法に含まれるステップを遂行するように構成されたプロセッサとを備える。

ＵＣＤの一例では、クライアントはＵＣＤクライアントを含み、第１のクラウドストレージサーバはスレーブＵＣＤサーバを含み、第２のクラウドストレージサーバはマスタＵＣＤサーバを含む。

有利には、例示的実施形態は、各セキュリティ技法をＵＣＤフレームワークにおいて統合する。

本発明が有する、これらおよび他の特徴や利点は、添付図面および以下の詳細な説明から、より明白なものとなろう。

本発明の１つ以上の実施形態が実装された統合型データストレージシステム環境を示す図である。 本発明の一実施形態による、識別子連携要求に関する方法体系を示す図である。 本発明の一実施形態による、シングルサインオンに関する方法体系を示す図である。 本発明の一実施形態による、シングルログアウトに関する方法体系を示す図である。 本発明の一実施形態による、識別子連携解除要求に関する方法体系を示す図である。 本発明の１つ以上の実施形態による統合型データストレージシステムおよび方法体系が実装された、処理プラットフォームを示す図である。

本明細書では、例示的なコンピューティングシステム、データストレージシステム、通信システム、処理プラットフォーム、ネットワーク、ユーザデバイス、ネットワークノード、ネットワーク要素、クライアント、サーバ、および関連する通信プロトコルを参照しながら、本発明の例示的実施形態について記述する。たとえば、例示する実施形態は、とりわけ統合型クラウドディスク（ＵＣＤ）環境での使用によく適する。とはいえ、本発明の実施形態は、記述される特定の構成による使用に限定されることはなく、より一般的にはセキュアな統合型データストレージ機能の提供によってパフォーマンスを向上させることが望ましい、あらゆる環境に広く適用可能であることを理解すべきである。

本明細書で用いられる場合、「クライアント」という用語は、エンドユーザ（たとえば顧客）向けの機能やサービスを実行するようにプログラミングおよび／または構成された、ソフトウェア、ハードウェア、またはそれらの組合せを例示的に指している。「サーバ」という用語は、サービスプロバイダ向けの機能やサービスを、通常はエンドユーザ（たとえば顧客）からの要求に応答して実行するようにプログラミングおよび／または構成された、ソフトウェア、ハードウェア、またはそれらの組合せを例示的に指している。処理デバイスは、ある目的のためにはクライアントとして動作し、また別の目的のためにはサーバとして動作するようにプログラミングおよび／または構成されてもよいし、あるいは専用クライアントや専用サーバとして動作するようにプログラミングおよび／または構成されてもよい。以降、こうした文脈において、「ＵＣＤクライアント」や「ＵＣＤサーバ」が参照される（たとえば、以下でさらに説明するように、マスタＵＣＤサーバ、スレーブＵＣＤサーバなど）。これらは、ＵＣＤ環境において動作するクライアント要素およびサーバ要素である。

上述したように、ＵＣＤが提供するクラウドストレージのフレームワークは、顧客が異なるクラウドストレージサービスおよびプロバイダにまたがってデータを格納することを選択する際に、顧客が多くの異なるＡＰＩを利用しなくてはならないという問題を克服するために提案されたものである。例として、異なるサービスプロバイダが維持する異なるクラウドストレージサービス間を横断してファイルを格納することを望む顧客を考えたい。ＵＣＤフレームワークの登場以前であれば、顧客のクライアントデバイスは、異なるサービスプロバイダのサーバにアクセスするために別々の異種のインタフェースを使用することになっただろう。しかし、ＵＣＤフレームワークを用いれば、顧客は標準インタフェースを介して、複数の異なるサービスプロバイダにアクセスすることができる。

図１は、統合型クラウドストレージシステム１００（たとえば、ＵＣＤシステム）を示しており、顧客（たとえば、顧客１０２−１、１０２−２、…、１０２−Ｍ）はクライアントを介して、各々が１つ以上のサーバを備える複数の異なるクラウドストレージシステム（１０４−１、１０４−２、…、１０４−Ｎ）に、標準ＳａａＳ ＡＰＩ１０６を通じてアクセスすることができる。たとえば、初めに顧客１０２−１のクライアント（ＵＣＤクライアント）が、ＡＰＩ１０６を通じて、各クラウドストレージシステム１０４−１、１０４−２、…、１０４−Ｎのサーバ（ＵＣＤサーバ）に登録を行うと仮定する。その後、顧客１０２−１のクライアントは、単一の標準インタフェース、すなわち標準ＳａａＳＡＰＩ１０６を通じて、さまざまなクラウドストレージシステムの各々に含まれるデータにアクセス（たとえば、格納や取得）することが可能となる。かかるシステムは「連携型クラウドストレージ」と呼ばれる。その理由は、クライアントは、共通のインタフェースを通じて、異なるクラウドストレージシステムの組合せにまたがって格納されたデータにアクセスすることができ、したがってそれらのストレージシステムが統合型クラウドストレージシステムを形成するためである。

ただし、他のあらゆるデータストレージに関するシナリオと同様に、ＵＣＤフレームワークにおいても、セキュリティが重要な問題となる。よって、ＵＣＤフレームワーク内の連携型クラウドストレージにアクセスしようとするＵＣＤクライアントの識別子を認証するためのセキュリティ技法が望まれる。

セキュリティ技法の１つに、「識別子連携（アイデンティティフェデレーション）」と呼ばれるものがある。識別子連携では、ユーザは、各サービスプロバイダ用に作成されているローカルな「識別子」（たとえば、ユーザ識別子、パスワード、電子メールアドレス、個人の選好など）を連携（たとえば、リンク、接続、または結合）することができる。リンクされたローカルな識別子（「連携型識別子」と呼ばれる）を用いることで、ユーザはあるサービスプロバイダのウェブサイトにログインできるとともに、クリックして他の提携しているサービスプロバイダにアクセスすることができる。よって、識別子連携は、別個のサービスプロバイダのアカウントを１つ以上の識別子プロバイダのアカウントと統合することをユーザが選択した際に発生する。ユーザは、各プロバイダに伴う個別のアカウント情報を保持しつつ、プロバイダ間での情報のやりとりを可能にするリンクを同時に確立する。識別子連携プロトコルの一例がＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ Ｐｒｏｊｅｃｔであり、識別子連携に関するオープン標準ベースの仕様を定義している。たとえば、Ｃａｎｔｏｒ、Ｓｃｏｔｔ、Ｋｅｍｐ、Ｊｏｈｎ、Ｃｈａｍｐａｇｎｅ、Ｄａｒｒｙｌが編集した「Ｌｉｂｅｒｔｙ ＩＤ−ＦＦ Ｂｉｎｄｉｎｇｓ ａｎｄ Ｐｒｏｆｉｌｅｓ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」、Ｖｅｒｓｉｏｎ１．２−ｅｒｒａｔａ−ｖ２．０、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ Ｐｒｏｊｅｃｔ、２００４年９月１２日（本明細書では「ＬｉｂｅｒｔｙＢｉｎｄＰｒｏｆ」と呼ぶ）や、Ｃａｎｔｏｒ、Ｓｃｏｔｔ、Ｋｅｍｐ、Ｊｏｈｎが編集した「Ｌｉｂｅｒｔｙ ＩＤ−ＦＦ Ｐｒｏｔｏｃｏｌｓ ａｎｄ Ｓｃｈｅｍａ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」、Ｖｅｒｓｉｏｎ１．２−ｅｒｒａｔａ−ｖ３．０、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ Ｐｒｏｊｅｃｔ、２００４年９月１２日（本明細書では「ＬｉｂｅｒｔｙＰｒｏｔＳｃｈｅｍａ」と呼ぶ）を参照されたい。これらの開示内容は、その全体が参照により本明細書に組み込まれる。

しかし、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ Ｐｒｏｊｅｃｔによる仕様は、ＵＣＤフレームワークに重大なオーバヘッド負荷を課すことも、本明細書では認識されている。したがって、本発明の例示的実施形態は、ＵＣＤフレームワークなどの統合型クラウドストレージシステムでの使用を目的とした、改良型の識別子連携管理方法体系を提供する。

図２から図５に関する以下の文脈で説明されるように、本発明の例示的実施形態は、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ Ｐｒｏｊｅｃｔによる識別子連携メッセージの適合された態様のいくつかを利用することができるＵＣＤ環境の中で実装される識別子連携方法体系を提供するものである。とはいえ、本明細書に提供される本発明の教示を踏まえれば、そのように適応した特定のＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ Ｐｒｏｊｅｃｔメッセージをそのままの方法で用いることなく、本発明の代替的実施形態が実装され得ることを理解されたい。

あるエンドユーザ（たとえば、図１の顧客１０２−１）が、第１のクラウドストレージサービスプロバイダ（すなわち、この例ではマスタＵＣＤサーバ）と関連付けられた第１のクラウドストレージシステム（たとえば、図１のクラウドストレージシステム１０４−１）に識別子連携手順の実行を望んでいると仮定する。マスタＵＣＤサーバは、識別子プロバイダの機能を持つＵＣＤサーバであり（以下でさらに説明する）、マスタＵＣＤアカウントの登録のためにエンドユーザによって選択される。一実施形態による、こうした識別子連携のための方法体系２００が、ＵＣＤクライアント２０２、マスタＵＣＤサーバ２０４、およびスレーブＵＣＤサーバ２０６に関連して、図２に示されている。スレーブＵＣＤサーバは、識別子プロバイダの機能を備える場合も備えない場合もあるＵＣＤサーバであり、スレーブＵＣＤアカウントの登録のためにエンドユーザによって選択される。なお、説明を簡略化するため、マスタＵＣＤサーバ２０４から開始される識別子連携要求手順に関する説明は、ここでは省略する。ただし、図２についての本明細書の記述を踏まえれば、かかる手順は明白なものであり、造作なく実現することが可能である。

１つ以上の例示的実施形態において、図２に関する以下の文脈で例示的に示され説明される識別子連携手順は、図３に関する以下の文脈で例示的に示され説明されるシングルサインオン手順、図４に関する以下の文脈で例示的に示され説明されるシングルログアウト手順、および図５に関する以下の文脈で例示的に示され説明される識別子連携解除手順を実行するための前提条件となることを理解されたい。つまり、エンドユーザは、自身がシングルサインオン、シングルログアウト、および／または識別子連携解除を実行する前に、スレーブＵＣＤサーバ内の自身のアカウントをマスタＵＣＤサーバと連携する必要がある。ただし、本発明の個々の実施形態は、それぞれ図２から図５に描かれる、各別個の方法体系を含むことを理解されたい。

この例示的実施形態では、識別子連携の実行のためのいくつかの前提は下記の通りである：（ｉ）ＩｄＰ機能を含むＵＣＤサーバのサービスプロバイダが、ＵＣＤサービスを提供する他のサービスプロバイダとの間で、サービスに関する契約を締結する（なお、識別子プロバイダ（ＩｄＰ）は、識別子アサーションプロバイダとしても知られ、所与のシステムとの対話／サービスを提供しようとするサービスプロバイダに対し識別情報を発行する責務を負うものである）。（ｉｉ）エンドユーザが、自身のスレーブＵＣＤサーバとするために、ＩｄＰ機能を持つ場合も持たない場合もあるＵＣＤサーバを決定し、登録してある。

方法体系２００は、以下に記述する、スレーブＵＣＤサーバ２０４から開始される識別子連携手順を表す（なお、以下で用いる１．、１．１、１．２、２．、…、９．、といったステップの参照番号は、図２に描かれた方法体系が有する各ステップの番号に対応する）：

１．エンドユーザが、スレーブＵＣＤサーバ２０６へのログインを要求する。したがって、ＵＣＤクライアント２０２が、ユーザ識別子（たとえば、スレーブＵＣＤサーバ２０６におけるユーザアカウント識別子）を含むメッセージＵｓｅｒＬｏｇｉｎＲｅｑｕｅｓｔ（ＨＴＴＰ要求）を、スレーブＵＣＤサーバ２０６に送信する。エンドユーザがスレーブＵＣＤサーバ２０６によって既に認証済みであり、ログイン状態を保っている場合、方法体系２００は直接ステップ３へと進む。エンドユーザが認証済みでなければ、本方法体系は以下の通りに進行する：
１．１ スレーブＵＣＤサーバ２０６がユーザの認証を要求する。メッセージには、ユーザ認証に使用するチャレンジ値またはランダム値が含まれ得る。
１．２ ＵＣＤクライアント２０２が、スレーブＵＣＤサーバ２０４に返信する。メッセージには、ユーザ認証情報（たとえば、クレデンシャルのダイジェスト）が含まれる。

２．スレーブＵＣＤサーバ２０６が、認証情報（たとえば、スレーブＵＣＤサーバにおけるユーザアカウント識別子、クレデンシャルのユーザダイジェストなど）に従って、ユーザを認証する。

スレーブＵＣＤサーバ２０６は、ＵＣＤクライアント２０２に対し、応答が成功したという表示と、ＩｄＰ機能を持つＵＣＤサーバのリスト（少なくとも１つのＵＣＤサーバが含まれる）を含む、メッセージＵｓｅｒＬｏｇｉｎＲｅｓｐｏｎｓｅを用いて返信する。なお、エンドユーザが自身のマスタＵＣＤサーバにログインするのであれば、このサーバリストは、スレーブＵＣＤサーバ候補のリストとなる。しかし、ユーザが自身のスレーブＵＣＤサーバにログインするのであれば、このサーバリストは、ＩｄＰ機能をサポートする、マスタＵＣＤサーバ候補のリストとなる。

３．エンドユーザが、ＵＣＤサーバのうちの１つを、連携を行うのに用いる自身のマスタＵＣＤサーバとして選択する（選択されるサーバには、ユーザが既にマスタＵＣＤアカウントを登録している）。ＵＣＤクライアント２０２が、スレーブＵＣＤサーバ２０６に、メッセージＩｄｅｎｔｉｔｙＦｅｄｅｒａｔｉｏｎＲｅｑｕｅｓｔを送信する。この要求メッセージには、スレーブＵＣＤサーバにおけるユーザアカウント識別子、マスタＵＣＤサーバにおけるユーザアカウント識別子、およびマスタＵＣＤサーバに関する情報（たとえば、マスタＵＣＤサーバのアドレス）が含まれる。

つまり、スレーブユーザアカウントをマスタユーザアカウントと連携するために、ＵＣＤクライアント２０２がスレーブＵＣＤサーバ２０６に識別子連携要求を送信する。メッセージフォーマットの一例は、ＩｄｅｎｔｉｔｙＦｅｄｅｒａｔｉｏｎＲｅｑｕｅｓｔ（ｕｓｅｒＩｄＭ，ｕｓｅＩｄＳ，ｓｅｒｖｅｒＩｄＭ，ｓｅｒｖｅｒＩｄＳ）である。このとき、ｕｓｅｒＩｄＭは、マスタＵＣＤサーバ２０４におけるユーザ識別子であり、ｕｓｅｒＩｄＳは、スレーブＵＣＤサーバ２０６におけるユーザ識別子であり、ｓｅｒｖｅｒＩｄＭは、スレーブＵＣＤサーバ２０６に対する連携要求時のマスタＵＣＤサーバ２０４の統一資源識別子（ＵＲＩ）であり、ｓｅｒｖｅｒＩｄＳは、マスタＵＣＤサーバ２０４に対する連携要求時のスレーブＵＣＤサーバ２０６のＵＲＩである。

４．スレーブＵＣＤサーバ２０６が、マスタＵＣＤサーバ２０４の位置情報を取得する。

５．スレーブＵＣＤサーバ２０６が、メッセージＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ（ステータスコードが３０２のＨＴＴＰメッセージ）を用いて、ＵＣＤクライアント２０２をマスタＵＣＤサーバ２０４へとリダイレクトする。メッセージＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔには、マスタＵＣＤサーバ２０４のアドレス、スレーブＵＣＤサーバ２０６のアドレス、マスタＵＣＤサーバ２０４におけるユーザアカウント識別子、スレーブＵＣＤサーバ２０６におけるユーザアカウント識別子、およびスレーブＵＣＤサーバ証明書が含まれる。

より具体的には、この要求メッセージのフォーマットの一例は、ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｑｕｅｓｔ（ＩＤＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ，ＳＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒ，ＰｒｏｖｉｄｅｒＩＤ）、である。このとき、ＩＤＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒフィールドは、マスタＵＣＤサーバにおけるユーザ識別子ｕｓｅｒＩｄＭであり、ＳＰＰｒｏｖｉｄｅｄＮａｍｅＩｄｅｎｔｉｆｉｅｒフィールドは、スレーブＵＣＤサーバにおけるユーザ識別子ｕｓｅｒＩｄＳであり、ＰｒｏｖｉｄｅｒＩＤフィールドは、（ｉ）ｓｅｒｖｅｒＩｄＭ、すなわちスレーブＵＣＤサーバに対する連携要求時のマスタＵＣＤサーバのＵＲＩ、または（ｉｉ）ｓｅｒｖｅｒＩｄＳ、すなわちマスタＵＣＤサーバに対する連携要求時のスレーブＵＣＤサーバのＵＲＩのいずれか一方である。この要求メッセージは、スレーブＵＣＤサーバ２０６により、デジタル的に署名される。スレーブＵＣＤサーバ２０６が、マスタＵＣＤサーバ２０４のデジタル署名を検証する。

連携情報を記録する前に（たとえば、マスタＵＣＤサーバとスレーブＵＣＤサーバの間でユーザアカウントをマッピングする前に）、マスタＵＣＤサーバ２０４がユーザを認証して、マスタＵＣＤサーバ２０４のユーザアカウントをスレーブＵＣＤサーバ２０６のユーザアカウントと連携する権利を同ユーザが有することを保証する。いくつかの認証手続が利用可能である。１つの例示的かつ非限定的な認証手続を以下に示す：
５．１ マスタＵＣＤサーバ２０４が、ユーザ認証のためにＵＣＤクライアント２０２に応答する。メッセージには、ユーザ認証に使用するチャレンジ値またはランダム値が含まれ得る。
５．２ ＵＣＤクライアント２０２が、マスタＵＣＤサーバ２０４に返信する。メッセージには、ユーザ認証情報（たとえば、ユーザクレデンシャルのダイジェスト）が含まれる。
５．３ マスタＵＣＤサーバ２０４がユーザを認証する。マスタＵＣＤサーバ２０４が、ＨＴＴＰメッセージ２００ ＯＫを用いて、ＵＣＤクライアント２０２に返信する。

６．マスタＵＣＤサーバ２０４が、連携情報（すなわち、マスタＵＣＤサーバ２０４とスレーブＵＣＤサーバ２０６の間におけるユーザアカウントのマッピング）を記録する。

７．マスタＵＣＤサーバ２０４が、メッセージＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ（ステータスコードが３０２のＨＴＴＰメッセージ）を用いて、ＵＣＤクライアント２０２をスレーブＵＣＤサーバ２０６へとリダイレクトする。メッセージＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅには、シングルサインオントークン（ＳＳＯＴｏｋｅｎ）、マスタＵＣＤサーバ識別子、スレーブＵＣＤサーバにおけるユーザアカウント識別子、マスタＵＣＤサーバにおけるユーザアカウント識別子、およびマスタＵＣＤサーバ証明書が含まれる。このメッセージは、マスタＵＣＤサーバ２０４により、デジタル的に署名される。

ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅメッセージのフォーマットの一例は、ＲｅｇｉｓｔｅｒＮａｍｅＩｄｅｎｔｉｆｉｅｒＲｅｓｐｏｎｓｅ（ＰｒｏｖｉｄｅｒＩＤ，Ｓｔａｔｕｓ，Ａｓｓｅｒｔｉｏｎ）、である。ＰｒｏｖｉｄｅｒＩＤフィールドは、（ｉ）ｓｅｒｖｅｒＩｄＭ、すなわちマスタＵＣＤサーバからスレーブＵＣＤサーバへのログアウト要求を用いて応答するときのマスタＵＣＤサーバのＵＲＩ、または（ｉｉ）ｓｅｒｖｅｒＩｄＳ、すなわちスレーブＵＣＤサーバからマスタＵＣＤサーバへのログアウト要求に応答するときのスレーブＵＣＤサーバのＵＲＩ、のいずれか一方とすることができる。Ｓｔａｔｕｓフィールドは、要求された処理の結果を含んでいる。識別子連携に成功した場合、ＳＳＯＴｏｋｅｎを含む認証アサーションが生成され、Ａｓｓｅｒｔｉｏｎフィールドに入れられる。スレーブＵＣＤサーバ２０６が、マスタＵＣＤサーバ２０４のデジタル署名を検証する。

８．スレーブＵＣＤサーバ２０６が、連携情報（すなわち、マスタＵＣＤサーバ２０４とスレーブＵＣＤサーバ２０６の間におけるユーザアカウントのマッピング）を記録する。

９．スレーブＵＣＤサーバ２０６が、メッセージＩｄｅｎｔｉｔｙＦｅｄｅｒａｔｉｏｎＲｅｓｐｏｎｓｅを用いて、ＵＣＤクライアント２０２に応答する。このメッセージが持ち得るフォーマットの一例は、ＩｄｅｎｔｉｔｙＦｅｄｅｒａｔｉｏｎＲｅｓｐｏｎｓｅ（Ｒｅｓｕｌｔ，ＳＳＯＴｏｋｅｎ）、である。このとき、Ｒｅｓｕｌｔフィールドは、要求処理の結果であり、識別子連携に成功した場合には、ＳＳＯＴｏｋｅｎが生成され、ＳＳＯＴｏｋｅｎフィールドでＵＣＤクライアント２０２に提供される。

この例示的実施形態において、クライアントとサーバ間でのハイパーテキスト転送プロトコル（ＨＴＴＰ）メッセージングは、機密性およびメッセージの完全性を保つため、トランスポートレイヤセキュリティ（ＴＬＳ）を用いて実装することが好ましい。ＴＬＳ１．２プロトコルについては、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ （ＩＥＴＦ） Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔ ｓｔａｎｄａｒｄ ５２４６に記述されており、その開示内容全体が参照により本明細書に組み込まれる。ただし、代替的実施形態では、ＨＴＴＰやＴＬＳ以外のメッセージプロトコルおよびセキュリティプロトコルが採用されてもよい。

図３は、例示的一実施形態による、シングルサインオン（ＳＳＯ）方法体系３００を示している（なお、以下で用いる１．、２．、…、６．、といったステップの参照番号は、図３に描かれた方法体系が有する各ステップの番号に対応する）：

１．ＵＣＤクライアント２０２が、サービスにアクセスするために、ＳＳＯＬｏｇｉｎ要求（ＨＴＴＰ要求）をスレーブＵＣＤサーバ２０６に送信する。このメッセージには、スレーブＵＣＤサーバ２０６におけるユーザ識別子が含まれる。また、このメッセージには、有効なＳＳＯＴｏｋｅｎも含まれ得る。一例として、同メッセージが持ち得るフォーマットは、ＳＳＯＬｏｇｉｎＲｅｑｕｅｓｔ（ｕｓｅｒＩｄＳ，ＳＳＯＴｏｋｅｎ）であり、このときｕｓｅｒＩｄＳは、スレーブＵＣＤサーバにおけるユーザ識別子であり、ＳＳＯＴｏｋｅｎフィールドにはＳＳＯ Ｔｏｋｅｎが含まれる。ＳＳＯトークンが入っていないか無効の場合、ＵＣＤサーバは、クラウドストレージサービスへのアクセスを許可する前に、有効なＳＳＯトークンを取得させるためにＵＣＤクライアントをリダイレクトする。

２．スレーブＵＣＤサーバ２０６がマスタＵＣＤサーバ２０４のアドレスを取得し、ＨＴＴＰ要求に、マスタＵＣＤサーバ２０４が生成した有効な認証アサーション（ＳＳＯＴｏｋｅｎを含む）が含まれているかどうかをチェックする。含まれていれば、本方法体系は直接ステップ６へと進む。

３．ステップ２において、有効な認証アサーションが見つからない場合、スレーブＵＣＤサーバ２０６が、ＡｕｔｈｎＲｅｑｕｅｓｔを含むＨＴＴＰ応答メッセージ（ステータスコードが３０２のＨＴＴＰメッセージ）を用いて、ＵＣＤクライアント２０２をマスタＵＣＤサーバ２０４へとリダイレクトする。なお、一例として、ＡｕｔｈＲｅｑｕｅｓｔは、ＡｕｔｈｎＲｅｑｕｅｓｔ（ＮａｍｅＩｄｅｎｔｉｆｉｅｒ，ＰｒｏｖｉｄｅｒＩＤ）、のフォーマットを持ち得る。ＰｒｏｖｉｄｅｒＩＤフィールドはマスタＵＣＤサーバ２０４のＵＲＩであり、ＮａｍｅＩｄｅｎｔｉｆｉｅｒフィールドには、スレーブＵＣＤサーバ２０６におけるユーザ識別子が含まれる。

認証アサーションを発行する前に、マスタＵＣＤスレーブ２０４は、以下のようにしてエンドユーザを認証する：
３．１ マスタＵＣＤサーバ２０４が、ユーザを認証するためにＵＣＤクライアント２０２に応答する（ステータスコード４０１を伴うＨＴＴＰメッセージ）。メッセージには、ユーザ認証に使用するチャレンジ値またはランダム値が含まれ得る。
３．２ ＵＣＤクライアント２０２が、マスタＵＣＤサーバ２０４に返信する。メッセージには、ユーザ認証情報（たとえば、ユーザクレデンシャルのダイジェスト）が含まれる。
３．３ マスタＵＣＤサーバ２０４がユーザを認証する。マスタＵＣＤサーバ２０４が、ＨＴＴＰメッセージ２００ ＯＫを用いて、ＵＣＤクライアント２０２に返信する。

４．マスタＵＣＤサーバ２０４が、ユーザに関する認証アサーション（ＳＳＯＴｏｋｅｎを含む）を生成し、ＡｕｔｈｎＲｅｐｏｎｓｅを含むＨＴＴＰ応答メッセージ（認証アサーションを含む）を用いて、マスタＵＣＤサーバ２０４がＵＣＤクライアント２０２をスレーブＵＣＤサーバ２０６にリダイレクトする。なお、一例として、ＡｕｔｈＲｅｓｐｏｎｓｅは、ＡｕｔｈｎＲｅｓｐｏｎｓｅ（ＰｒｏｖｉｄｅｒＩＤ，Ａｓｓｅｒｔｉｏｎ）、のフォーマットを持ち得る。ＰｒｏｖｉｄｅｒＩＤフィールドはマスタＵＣＤサーバ２０４のＵＲＩであり、Ａｓｓｅｒｔｉｏｎフィールドが追加され、Ａｓｓｅｒｔｉｏｎフィールドには、要求された処理の結果と、認証成功後に生成されたＳＳＯＴｏｋｅｎを含む認証アサーションとが含まれる。

５．スレーブＵＣＤサーバが認証アサーションを検証する。あくまで一例として、この検証は、上述したＬｉｂｅｒｔｙＢｉｎｄＰｒｏｆおよびＬｉｂｅｒｔｙＰｒｏｔＳｃｈｅｍａに記述された検証を用いて行われる。認証アサーションの検証には、その他の方法が採用されてもよい。

６．スレーブＵＣＤサーバ２０６が、初めに要求されたリソース（たとえばクラウドストレージ）へのアクセスを許可または拒否するメッセージである、ＳＳＯＬｏｇｉｎ応答を用いて、ＵＣＤクライアント２０２に応答する。このメッセージが持つフォーマットの一例は、ＳＳＯＬｏｇｉｎＲｅｓｐｏｎｓｅ（Ｒｅｓｕｌｔ，ＳＳＯＴｏｋｅｎ）である。このとき、Ｒｅｓｕｌｔフィールドは要求処理の結果であり、ＳＳＯＴｏｋｅｎフィールドは、スレーブＵＣＤサーバ２０６がマスタＵＣＤサーバ２０４から有効なＳＳＯＴｏｋｅｎを受け取った場合にはオプションである。ＵＣＤクライアント２０２は、ＳＳＯＴｏｋｅｎの抽出および格納を行うことになる。

この例示的実施形態でも同様に、クライアントとサーバ間でのＨＴＴＰメッセージングは、機密性およびメッセージの完全性を保つため、トランスポートレイヤセキュリティ（ＴＬＳ）を用いて実装することが好ましい。

図４は、例示的一実施形態による、マスタＵＣＤサーバ２０４において開始されるシングルログアウト方法体系４００を示している（なお、以下で用いる１．、１．１、１．２．、…、８．、といったステップの参照番号は、図４に描かれた方法体系が有する各ステップの番号に対応する）。なお、説明を簡略化するため、スレーブＵＣＤサーバ２０６において開始される、シングルログアウト手順に関する記述は、ここでは省略する。ただし、図４についての本明細書の記述を踏まえれば、かかる手順は明白なものであり、造作なく実現することが可能である。

方法体系４００は、以下の通りに進行する：

１．ユーザが、マスタＵＣＤサーバ２０４へのログインを要求する。ＵＣＤクライアント２０２が、ユーザ識別子（たとえば、マスタＵＣＤサーバ２０４におけるユーザアカウント識別子）を含むメッセージＵｓｅｒＬｏｇｉｎＲｅｑｕｅｓｔを、たとえばＵｓｅｒＬｏｇｉｎＲｅｑｕｅｓｔ（ＵｓｅｒＩｄ）といったフォーマットで送信する。ユーザがマスタＵＣＤサーバ２０４によって既に認証済みであり、ログイン状態を保っている場合、本方法体系はステップ３へと進む。それ以外の場合は、：
１．１ マスタＵＣＤサーバ２０４が、ユーザ認証のためＵＣＤクライアント２０２に応答する。メッセージには、ユーザ認証に使用するチャレンジ値またはランダム値が含まれ得る。
１．２ ＵＣＤクライアント２０２が、マスタＵＣＤサーバ２０４に要求を送信する。メッセージには、ユーザ認証情報（たとえば、ユーザクレデンシャルのダイジェスト）が含まれる。

２．マスタＵＣＤサーバ２０４が、認証情報（たとえば、マスタＵＣＤサーバ２０４におけるユーザアカウント識別子、クレデンシャルのユーザダイジェスト、など）に従ってユーザを認証し、マスタＵＣＤサーバ２０４は図２に関し上述したようにメッセージＵｓｅｒＬｏｇｉｎＲｅｓｐｏｎｓｅを用いて、ＵＣＤ２０２クライアントに返信する。

３．ＵＣＤクライアント２０２が、マスタＵＣＤサーバ２０４にメッセージＳｉｎｇｌｅＬｏｇｏｕｔＲｅｑｕｅｓｔを送信する。この要求メッセージには、マスタＵＣＤサーバ２０４におけるユーザアカウント識別子、スレーブＵＣＤサーバ２０６におけるユーザアカウント識別子、およびスレーブＵＣＤサーバ２０６に関する情報（たとえば、スレーブＵＣＤサーバのアドレス）が含まれる。ＳｉｎｇｌｅＬｏｇｏｕｔＲｅｑｕｅｓｔのメッセージフォーマットの一例として、ＳｉｎｇｌｅＬｏｇｏｕｔＲｅｑｅｓｔ（ＵｓｅｒＩｄ，ＳｅｒｖｅｒＩｄ）を示す。このとき、ｕｓｅｒＩｄフィールドは、（ｉ）ｕｓｅｒＩｄＭ、すなわちマスタＵＣＤサーバからスレーブＵＣＤサーバへのログアウト要求時のマスタＵＣＤサーバにおけるユーザ識別子、または（ｉｉ）ｕｓｅｒＩｄＳ、すなわちスレーブＵＣＤサーバからマスタＵＣＤサーバへのログアウト要求時のスレーブＵＣＤサーバにおけるユーザ識別子、のいずれか一方である。ＳｅｒｖｅｒＩｄフィールドは、ｕｓｅｒＩｄＭまたはｕｓｅｒＩｄＳに関連付けられた、マスタＵＣＤサーバのアドレス（ＳｉｎｇｌｅＬｏｇｏｕｔＲｅｑｕｅｓｔがスレーブＵＣＤサーバからの場合）、またはスレーブＵＣＤサーバのアドレス（ＳｉｎｇｌｅＬｏｇｏｕｔＲｅｑｕｅｓｔがマスタＵＣＤサーバからの場合）である。

４．マスタＵＣＤサーバ２０４が、マスタＵＣＤサーバ２０４によって発行されたＳＳＯＴｏｋｅｎを用いてエンドユーザがログインしている、すべてのスレーブＵＣＤサーバを発見（たとえば、アドレスを取得）する。

５．次いで、マスタＵＣＤサーバ２０４が、メッセージＬｏｇｏｕｔＲｅｑｕｅｓｔを、ＵＣＤクライアント２０２からこれらのスレーブＵＣＤサーバ（この例ではスレーブＵＣＤサーバ２０６）へと別個にリダイレクトする。リダイレクトステップ５．１、５．２、および５．３は、上記の図２に関する文脈で説明したものと同様である。メッセージＬｏｇｏｕｔＲｅｑｕｅｓｔは、マスタＵＣＤサーバ２０４によって署名される。このメッセージには、スレーブＵＣＤサーバ２０６のアドレス、マスタＵＣＤサーバ２０４のアドレス、マスタＵＣＤサーバ２０４におけるユーザアカウント識別子、スレーブＵＣＤサーバ２０６におけるユーザアカウント識別子、およびマスタＵＣＤサーバ証明書が含まれる。なお、ＬｏｇｏｕｔＲｅｑｕｅｓｔメッセージの持ち得るフォーマットの一例は、ＬｏｇｏｕｔＲｅｑｕｅｓｔ（ＮａｍｅＩｄｅｎｔｉｆｉｅｒ，ＰｒｏｖｉｄｅｒＩＤ）である。このとき、ＮａｍｅＩｄｅｎｔｉｆｉｅｒフィールドは、（ｉ）ｕｓｅｒＩｄＭ、すなわちマスタＵＣＤサーバからスレーブＵＣＤサーバへのログアウト要求時のマスタＵＣＤサーバにおけるユーザ識別子、または（ｉｉ）ｕｓｅｒＩｄＳ、すなわちスレーブＵＣＤサーバからマスタＵＣＤサーバへのログアウト要求時のスレーブＵＣＤサーバにおけるユーザ、のいずれか一方である。ＰｒｏｖｉｄｅｒＩＤフィールドは、（ｉ）ｓｅｒｖｅｒＩｄＭ、すなわちマスタＵＣＤサーバからスレーブＵＣＤサーバへのログアウト要求時のマスタＵＣＤサーバのＵＲＩ、または（ｉｉ）ｓｅｒｖｅｒＩｄＳ、すなわちスレーブＵＣＤサーバからマスタＵＣＤサーバへのログアウト要求時のスレーブＵＣＤサーバのＵＲＩ、のいずれか一方である。

６．スレーブＵＣＤサーバ２０６が、ログアウト要求を処理する。つまり、スレーブＵＣＤサーバ２０６が、マスタＵＣＤサーバのデジタル署名を検証する。この署名が、プリンシパルの現在のセッションについて認証を行ったマスタＵＣＤサーバ２０４の署名であれば、スレーブＵＣＤサーバ２０６は、＜ＮａｍｅＩｄｅｎｔｉｆｉｅｒ＞要素が指すユーザのセッション、およびメッセージで供給されたあらゆるＳｅｓｓｉｏｎＩｎｄｅｘ要素を無効化する。スレーブＵＣＤサーバ２０６が、特定の要件を満たすあらゆるアサーションにログアウト要求メッセージを適用する。特定の要件の例は、（ａ）アサーションのＳｅｓｓｉｏｎＩｎｄｅｘがログアウト要求内の特定のＳｅｓｓｉｏｎＩｎｄｅｘとマッチする、かつ／または（ｂ）アサーションがログアウト要求後に到着した場合でも、その他の形で有効である、などである。

７．スレーブＵＣＤサーバ２０６が、メッセージＬｏｇｏｕｔＲｅｓｐｏｎｓｅを用いて、ＵＣＤクライアント２０２をマスタＵＣＤサーバ２０４へとリダイレクトする。このメッセージは、スレーブＵＣＤサーバ２０６により、デジタル的に署名される。Ｌｏｇｏｕｔ Ｒｅｓｐｏｎｓｅメッセージが持ち得るフォーマットの一例は、ＬｏｇｏｕｔＲｅｓｐｏｎｓｅ（ＰｒｏｖｉｄｅｒＩＤ，Ｓｔａｔｕｓ）である。このとき、ＰｒｏｖｉｄｅｒＩＤフィールドは、（ｉ）ｓｅｒｖｅｒＩｄＭ、すなわちマスタＵＣＤサーバからスレーブＵＣＤサーバへのログアウトに応答するときのマスタＵＣＤサーバのＵＲＩ、または（ｉｉ）ｓｅｒｖｅｒＩｄＳ、すなわちスレーブＵＣＤサーバからマスタＵＣＤサーバへのログアウトに応答するときのスレーブＵＣＤサーバのＵＲＩのうち、いずれか一方を持つ。Ｓｔａｔｕｓフィールドには、要求処理の結果が含まれる。

８．スレーブＵＣＤサーバ２０６の各々（上記ステップ４で説明したもの）からメッセージＬｏｇｏｕｔＲｅｓｐｏｎｓｅを受信した後、マスタＵＣＤサーバ２０４が、ＳｉｎｇｌｅＬｏｇｏｕｔＲｅｓｐｏｎｓｅをＵＣＤクライアント２０２へと送信し、ＵＣＤクライアント２０２がスレーブＵＣＤサーバ２０６からログアウトしたことを確認する。メッセージフォーマットの一例は、ＳｉｎｇｌｅＬｏｇｏｕｔＲｅｓｐｏｎｓｅ（Ｒｅｓｕｌｔ）であり、Ｒｅｓｕｌｔフィールドは要求処理の結果である。

この例示的実施形態でも同様に、クライアントとサーバ間でのＨＴＴＰメッセージングは、機密性およびメッセージの完全性を保つため、トランスポートレイヤセキュリティ（ＴＬＳ）を用いて実装することが好ましい。

次に、ユーザがマスタＵＣＤサーバとの識別子連携解除の実行を望むと仮定する。図５は、そのような識別子連携解除の方法体系を示している。なお、説明を簡略化するために、スレーブＵＣＤサーバ２０６から開始される識別子連携解除要求手順に関する記述は、ここでは省略する。ただし、図５についての本明細書の記述を踏まえれば、かかる手順は明白なものであり、造作なく実現することが可能である。

方法体系５００は、以下に記述する、マスタＵＣＤサーバ２０４から開始される識別子連携解除手順を表す（なお、以下で用いる１．、１．１、１．２、２．、…、９．、といったステップの参照番号は、図５に描かれた方法体系が有する各ステップの番号に対応する）。

１．ユーザが、マスタＵＣＤサーバ２０４へのログインを要求する。ＵＣＤクライアント２０２が、ユーザ識別子（たとえば、マスタＵＣＤサーバ２０４におけるユーザアカウント識別子）を含むメッセージＵｓｅｒＬｏｇｉｎＲｅｑｕｅｓｔ（前出）を送信する。ユーザがマスタＵＣＤサーバ２０４によって既に認証済みであり、ログイン状態を保っている場合、本方法体系は直接ステップ３へと進む。それ以外の場合は、：
１．１ マスタＵＣＤサーバ２０４が、ユーザ認証のためＵＣＤクライアント２０２に応答する。メッセージには、ユーザ認証に使用するチャレンジ値またはランダム値が含まれ得る。
１．２ ＵＣＤクライアント２０２が、マスタＵＣＤサーバ２０４に要求を送信する。メッセージには、ユーザ認証情報（たとえば、ユーザクレデンシャルのダイジェスト）が含まれる。

２．マスタＵＣＤサーバ２０４が、認証情報（たとえば、マスタＵＣＤサーバにおけるユーザアカウント識別子、ユーザクレデンシャルのダイジェスト、など）に従ってユーザを認証し、スレーブＵＣＤサーバのアドレスリストを含むメッセージＵｓｅｒＬｏｇｉｎＲｅｓｐｏｎｓｅ（前出）を用いてＵＣＤクライアント２０２に返信する。

３．ユーザが、連携解除するスレーブＵＣＤサーバを選択する（すなわち、ここでは連携解除要求がスレーブＵＣＤサーバ２０６に関連したものであると仮定する）。ＵＣＤクライアント２０２が、マスタＵＣＤサーバ２０４に向けて、メッセージＩｄｅｎｔｉｔｙＤｅｆｅｄｅｒａｔｉｏｎＲｅｑｕｅｓｔを送信する。この要求メッセージには、マスタＵＣＤサーバにおけるユーザアカウント識別子、スレーブＵＣＤサーバにおけるユーザアカウント識別子、およびスレーブＵＣＤサーバに関する情報（たとえば、スレーブＵＣＤサーバのアドレス）が含まれる。

連携解除要求メッセージのフォーマットの一例は、ＩｄｅｎｔｉｔｙＤｅｆｅｄｅｒａｔｉｏｎＲｅｑｕｅｓｔ（ｕｓｅｒＩｄＭ，ｕｓｅＩｄＳ，ｓｅｒｖｅｒＩｄＭ，ｓｅｒｖｅｒＩｄＳ）である。このとき、ｕｓｅｒＩｄＭは、マスタＵＣＤサーバにおけるユーザ識別子であり、ｕｓｅｒＩｄＳは、スレーブＵＣＤサーバにおけるユーザ識別子であり、ｓｅｒｖｅｒＩｄＭは、スレーブＵＣＤサーバｕｓｅｒＩｄＳに対する連携解除要求時のマスタＵＣＤサーバのＵＲＩであり、ｓｅｒｖｅｒＩｄＳは、マスタＵＣＤサーバに対する連携要求時のスレーブＵＣＤサーバのＵＲＩである。

４．マスタＵＣＤサーバ２０４が、スレーブＵＣＤサーバ２０６の位置情報を取得する。

５．マスタＵＣＤサーバ２０４が、ＵＣＤクライアント２０２をスレーブＵＣＤサーバ２０６へとリダイレクトする。このリダイレクトは、メッセージＦｅｄｅｒａｔｉｏｎＴｅｒｍｉｎａｔｉｏｎＮｏｔｉｆｉｃａｔｉｏｎを用いて遂行され、これにはスレーブＵＣＤサーバのアドレス、マスタＵＣＤサーバのアドレス、マスタＵＣＤサーバにおけるユーザアカウント識別子、スレーブＵＣＤサーバにおけるユーザアカウント識別子、およびマスタＵＣＤサーバ証明書が含まれる。このメッセージは、マスタＵＣＤサーバにより、デジタル的に署名される。

この連携終了通知メッセージのフォーマットの一例は、ＦｅｄｅｒａｔｉｏｎＴｅｒｍｉｎａｔｉｏｎＮｏｔｉｆｉｃａｔｉｏｎ（ＮａｍｅＩｄｅｎｔｉｆｉｅｒ，ＰｒｏｖｉｄｅｒＩＤ）である。このとき、ＮａｍｅＩｄｅｎｔｉｆｉｅｒフィールドは、（ｉ）ｕｓｅｒＩｄＭ、すなわちマスタＵＣＤサーバからスレーブＵＣＤサーバへの連携解除要求時のマスタＵＣＤサーバにおけるユーザ識別子、または（ｉｉ）ｕｓｅｒＩｄＳ、すなわちスレーブＵＣＤサーバからマスタＵＣＤサーバへの連携解除要求時のスレーブＵＣＤサーバにおけるユーザ識別子、のいずれか一方である。ＰｒｏｖｉｄｅｒＩＤフィールドは、（ｉ）ｓｅｒｖｅｒＩｄＭ、すなわちマスタＵＣＤサーバからスレーブＵＣＤサーバへの連携解除要求時のマスタＵＣＤサーバのＵＲＩ、または（ｉｉ）ｓｅｒｖｅｒＩｄＳ、すなわちスレーブＵＣＤサーバからマスタＵＣＤサーバへの連携解除要求時のスレーブＵＣＤサーバのＵＲＩ、のいずれか一方である。

スレーブＵＣＤサーバ２０６が、マスタＵＣＤサーバ２０４のデジタル署名を検証する。

連携に関する情報（たとえば、マスタＵＣＤサーバとスレーブＵＣＤサーバの間におけるユーザアカウントのマッピング）を無効化する前に、スレーブＵＣＤサーバ２０６がユーザを認証して、同ユーザがその連携解除を実行する認可を有することを保証する。いくつかの認証手続が利用可能である。１つの例示的かつ非限定的な認証手続を以下に示す：
５．１ スレーブＵＣＤサーバ２０６が、ユーザ認証のためＵＣＤクライアント２０２に応答する。メッセージには、ユーザ認証に使用するチャレンジ値またはランダム値が含まれ得る。
５．２ ＵＣＤクライアント２０２が、スレーブＵＣＤサーバ２０６に返信する。メッセージには、ユーザ認証情報（たとえば、ユーザクレデンシャルのダイジェスト）が含まれる。
５．３ スレーブＵＣＤサーバ２０６がユーザを認証する。スレーブＵＣＤサーバ２０６が、ＨＴＴＰメッセージ２００ ＯＫを用いて、ＵＣＤクライアント２０２に返信する。

６．スレーブＵＣＤサーバ２０６が、自身とマスタＵＣＤサーバ２０４の間におけるユーザアカウントのマッピングを無効化（および除去／削除してもよい）する。

７．スレーブＵＣＤサーバ２０６が、ＵＣＤクライアント２０２をマスタＵＣＤサーバ２０４へとリダイレクトする。応答メッセージには、マスタＵＣＤサーバ２０４を指し示すＵＲＩが含まれる。

８．マスタＵＣＤサーバが、マスタＵＣＤサーバ２０４とスレーブＵＣＤサーバ２０６の間におけるユーザアカウントのマッピングを無効化（および除去／削除してもよい）する。

９．マスタＵＣＤサーバ２０４が、メッセージＩｄｅｎｔｉｔｙＤｅｆｅｄｅｒａｔｉｏｎＲｅｓｐｏｎｓｅを用いて、ＵＣＤクライアント２０２に応答する。メッセージフォーマットの一例は、ＩｄｅｎｔｉｔｙＤｅｆｅｄｅｒａｔｉｏｎＲｅｓｐｏｎｓｅ（Ｒｅｓｕｌｔ）であり、Ｒｅｓｕｌｔフィールドは要求処理の結果である。

この例示的実施形態でも同様に、クライアントとサーバ間でのＨＴＴＰメッセージングは、機密性およびメッセージの完全性を保つため、トランスポートレイヤセキュリティ（ＴＬＳ）を用いて実装することが好ましい。

図６は、本発明の１つ以上の実施形態によるデータストレージシステムおよび方法体系が実装される処理プラットフォームを示している。本実施形態における処理プラットフォーム６００は、６１０、６２０、および６３０と表記する複数の処理デバイスを含むものであり、これらの処理デバイスはネットワーク６４０を介して相互に通信する。図示の通り、処理デバイス６１０はＵＣＤクライアント（たとえば、図２から図５のＵＣＤクライアント２０２）を表し、処理デバイス６２０はマスタＵＣＤサーバ（たとえば、図２から図５のマスタＵＣＤサーバ２０４）を表し、処理デバイス６３０はスレーブＵＣＤサーバ（たとえば、図２から図５のスレーブＵＣＤサーバ２０６）を表す。明示しない追加の処理デバイスが、処理プラットフォーム６００の一部をなしてもよい。ＵＣＤフレームワークに含まれる１つ以上の要素（ＵＣＤクライアントやＵＣＤサーバ）は、各々が１つ以上のコンピュータまたは他の処理プラットフォーム要素（これらは本明細書で広く「処理デバイス」と呼ばれるものの一例とみなすことができる）において動作し得ることは理解されよう。図６に示すように、こうしたデバイスは通常、少なくとも１つのプロセッサおよび関連付けられたメモリを備えており、本明細書で記述したシステムの機能および各方法体系を、インスタンス化かつ／または制御するための１つ以上の機能モジュールを実装するものである。所与の実施形態において、複数の要素またはモジュールが、単一の処理デバイスによって実装されてもよい。

処理プラットフォーム６００における処理デバイス６１０は、メモリ６１６と結合されたプロセッサ６１４を備える。プロセッサ６１４は、マイクロプロセッサ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または他のタイプの処理回路、さらには、こうした回路要素の部分または組合せを備え得る。本明細書に開示するようなシステムの構成要素は、メモリに記憶され、プロセッサ６１４などのプロセッサによって実行される１つ以上のソフトウェアプログラムという形で、少なくとも部分的に実装可能なものである。こうしたプログラムコードが内部に具現化されたメモリ６１６（または他のストレージデバイス）は、本明細書で広く非一時的プロセッサ可読（またはコンピュータ可読）記憶媒体と呼ばれるものの一例である。こうしたプロセッサ可読記憶媒体を備える製品は、本発明の実施形態とみなされる。かかる所与の製品は、たとえば、ストレージディスク、ストレージアレイ、メモリを含む集積回路など、あるストレージデバイスを備え得る。本明細書で用いる場合、「製品」という用語は、一時的な伝播信号を含まないことを理解されたい。

さらに、メモリ６１６は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、または他のタイプのメモリといった電子メモリを、任意の組合せで備え得る。１つ以上のソフトウェアプログラムは、処理デバイス（６１０など）によって実行されると、システム／方法体系２００、３００、４００、および／または５００が持つ構成要素／ステップのうち、１つ以上と関連付けられた機能を、そのデバイスに実行させる。当業者であれば、本明細書が提供した教示を踏まえ、かかるソフトウェアを容易に実装することが可能である。本発明の実施形態を具現化した、プロセッサ可読記憶媒体の他の例として、たとえば、光学ディスクや磁気ディスクも挙げられる。

また、処理デバイス６１０には、Ｉ／Ｏデバイス／ネットワークインタフェース回路６１２も含まれる。Ｉ／Ｏデバイスには、処理デバイスにデータを入力するための１つ以上の入力デバイス（たとえば、キーボード、キーパッド、マウス、タッチスクリーン、など）、ならびに、処理デバイスに関連付けられた結果を提供するための１つ以上の出力デバイス（たとえば、コンピュータディスプレイ、スクリーン、グラフィカルユーザインタフェース、など）が含まれる。ネットワークインタフェースには、処理デバイスをネットワーク（たとえば６４０）および他のネットワーク構成要素（たとえば６２０と６３０）とインタフェースするのに用いられる回路が含まれる。こうした回路には、当技術分野でよく知られているタイプの従来型送受信機が含まれ得る。

処理プラットフォーム６００の他の処理デバイス６２０（Ｉ／Ｏデバイス／ネットワークインタフェース６２２、プロセッサ６２４、およびメモリ６２６を備える）と、処理デバイス６３０（Ｉ／Ｏデバイス／ネットワークインタフェース６３２、プロセッサ６３４、およびメモリ６３６を備える）とは、図示の処理デバイス６１０に関して示したものと同様に構成されると仮定する。

本明細書では、いくつかの例示的実施形態について、特定の通信プロトコルを利用する通信ネットワークおよびシステムに関連した文脈で説明したが、他の実施形態では、異なるタイプのネットワークおよびシステムが使用され得る。よって先に触れたように、本明細書で用いた「ネットワーク」または「システム」という用語は、広義に解釈されることを意図している。さらに、上述の各実施形態は例示のためのものにすぎず、いかなる形においても限定と解釈すべきでないことを強調しなければならない。他の実施形態では、ネットワーク、システム、デバイス、およびモジュールの構成は多種多様であってよく、また、セキュリティ機能を実装するために、代替的な通信プロトコル、処理ステップ、および操作が利用されてよい。他の実施形態では、ユーザデバイスおよびネットワークノードの通信方法の詳細は異なり得る。また、例示的実施形態を説明する文脈でなされた特定の仮定は、本発明の要件と解釈すべきではないことも理解されたい。本発明は、これら特定の仮定が適用されない他の実施形態においても実装可能である。以上の実施形態、および添付する特許請求の範囲に含まれる他の多数の代替的実施形態は、当業者であれば容易に理解できるものであろう。

Claims (20)

1. クライアントが、第１のクラウドストレージサーバによる認証を要求するステップと、
   クライアントから、識別子連携要求を第１のクラウドストレージサーバに送信するステップであって、識別子連携要求が、第１のクラウドストレージサーバ上のクライアントのユーザアカウントを、第２のクラウドストレージサーバ上のクライアントのユーザアカウントと連携することを求める、送信するステップと、
   クライアントを、第１のクラウドストレージサーバから第２のクラウドストレージサーバへとリダイレクトするステップと、
   クライアントが認証されれば、第２のクラウドストレージサーバが、第１のクラウドストレージサーバ上のユーザアカウントを第２のクラウドストレージサーバのユーザアカウントとマッピングし、それらの間に識別子連携を成立させるように、クライアントが第２のクラウドストレージサーバによる認証を要求するステップと、
   クライアントを、第２のクラウドストレージサーバから第１のクラウドストレージサーバへとリダイレクトするステップとを含み、
   ステップの１つ以上が、処理デバイスによって実行される、方法。
2. クライアントにおいて、第２のクラウドストレージサーバから、クライアントが第１のクラウドストレージサーバのサービスにサインオンするためのサインオントークンを受信するステップをさらに含む、請求項１に記載の方法。
3. サインオントークンが第２のクラウドストレージサーバによって証明されている、請求項２に記載の方法。
4. クライアントから第１のクラウドストレージサーバにサインオントークンを送信するステップをさらに含む、請求項２に記載の方法。
5. サインオントークンが有効であることが検証された場合、クライアントにおいて、第１のクラウドストレージサーバから、クラウドストレージサービスにアクセスする認可を受け取るステップをさらに含む、請求項４に記載の方法。
6. サインオントークンが有効でない場合、クライアントにおいて、第１のクラウドストレージサーバから、クラウドストレージサービスにアクセスする認可の拒否を受信し、別のサインオントークンを取得するために、第１のクラウドストレージサーバから第２のクラウドストレージサーバへとクライアントをリダイレクトするステップをさらに含む、請求項４に記載の方法。
7. クラウドストレージサービスへのアクセスを試みるために、クライアントから第１のクラウドストレージサーバに別のサインオントークンを送信するステップをさらに含む、請求項６に記載の方法。
8. クライアントから第２のクラウドストレージサーバに、クラウドストレージサービスからログアウトする要求を送信するステップをさらに含む、請求項５に記載の方法。
9. 第２のクラウドストレージサーバから第１のクラウドストレージサーバへとクライアントをリダイレクトし、クライアントが第１のクラウドストレージサーバによって認証され、認証されるとクラウドストレージサービスからログアウトするステップをさらに含む、請求項８に記載の方法。
10. クライアントにおいて、第１のクラウドストレージサーバから、クラウドストレージサービスからログアウトしたことの確認を受信するステップをさらに含む、請求項９に記載の方法。
11. クライアントから、識別子連携解除要求を第２のクラウドストレージサーバに送信するステップであって、識別子連携解除要求は、第１のクラウドストレージサーバ上のクライアントのユーザアカウントと、第２のクラウドストレージサーバ上のクライアントのユーザアカウントとを、連携解除するよう求める、送信するステップと、
    クライアントを、第２のクラウドストレージサーバから第１のクラウドストレージサーバへとリダイレクトするステップと、
    クライアントが認証されれば、第１のクラウドストレージサーバが、第１のクラウドストレージサーバ上のユーザアカウントと、第２のクラウドストレージサーバのユーザアカウントとのマッピングを無効化または削除することにより、第１および第２のクラウドストレージサーバ上のユーザアカウント間の識別子連携を終了させるように、クライアントが第１のクラウドストレージサーバによる認証を要求する、ステップと、
    クライアントを、第１のクラウドストレージサーバから第２のクラウドストレージサーバへとリダイレクトするステップと
    をさらに含む、請求項１に記載の方法。
12. クライアント、第１のクラウドストレージサーバ、および第２のクラウドストレージサーバが、統合型クラウドディスク（ＵＣＤ）フレームワークの一部であり、クライアントがＵＣＤクライアントを含み、第１のクラウドストレージサーバがスレーブＵＣＤサーバを含み、第２のクラウドストレージサーバがマスタＵＣＤサーバを含む、請求項１に記載の方法。
13. 処理デバイスによって実行されると請求項１に記載の方法のステップを処理デバイスに遂行させる実行可能プログラムコードを内部に具現化したプロセッサ可読記憶媒体を備える、製品。
14. メモリと、メモリに動作可能に結合され、請求項１に記載の方法のステップを遂行するように構成されたプロセッサとを備える、装置。
15. 第１のクラウドストレージサーバにおいて、認証対象となるクライアントからの要求を受信するステップと、
    第１のクラウドストレージサーバにおいて、クライアントから、識別子連携要求を受信するステップであって、識別子連携要求が、第１のクラウドストレージサーバ上のクライアントのユーザアカウントを、第２のクラウドストレージサーバ上のクライアントのユーザアカウントと連携するよう求める、受信するステップと、
    クライアントが第２のクラウドストレージサーバによる認証を要求し、クライアントが認証された後に第２のクラウドストレージサーバが、第１のクラウドストレージサーバ上のユーザアカウントを第２のクラウドストレージサーバ上のユーザアカウントとマッピングするとともにそれらの間に識別子連携を成立させ、さらに第２のクラウドストレージサーバから第１のクラウドストレージサーバへとクライアントをリダイレクトするように、第１のクラウドストレージサーバから第２のクラウドストレージサーバへとクライアントをリダイレクトするステップとを含み、
    上記ステップの１つ以上が、処理デバイスによって実行される、方法。
16. 処理デバイスによって実行されると請求項１５に記載の方法のステップを処理デバイスに遂行させる実行可能プログラムコードを内部に具現化したプロセッサ可読記憶媒体を備える、製品。
17. メモリと、メモリに動作可能に結合され、請求項１５に記載の方法のステップを遂行するように構成されたプロセッサとを備える、装置。
18. 第１のクラウドストレージサーバに対するクライアントからの識別子連携要求に応答して、第２のクラウドストレージサーバにおいて、認証対象のクライアントから要求を受信するステップであって、識別子連携要求が、第１のクラウドストレージサーバ上のクライアントのユーザアカウントを、第２のクラウドストレージサーバ上のクライアントのユーザアカウントと連携するよう求める、受信するステップと、
    クライアントが認証された後、第１のクラウドストレージサーバ上のユーザアカウントを、第２のクラウドストレージサーバのユーザアカウントとマッピングし、それらの間に識別子連携を成立させるステップと、
    クライアントを、第２のクラウドストレージサーバから第１のクラウドストレージサーバへとリダイレクトするステップとを含み、
    上記ステップの１つ以上が、処理デバイスによって実行される、方法。
19. 処理デバイスによって実行されると請求項１８に記載の方法のステップを処理デバイスに遂行させる実行可能プログラムコードを内部に具現化したプロセッサ可読記憶媒体を備える、製品。
20. メモリと、メモリに動作可能に結合され、請求項１８に記載の方法のステップを遂行するように構成されたプロセッサとを備える、装置。

Images