JP2009541817A - システム間シングルサインオン - Google Patents

Abstract

システム間シングルサインオンのための技術は、システム間ユーザＩＤマッピングを使用して複数のシステムのユーザＩＤをマップする。一実装では、方法は、第１のシステムに関するユーザのＩＤ情報を取得し、システム間ユーザＩＤマッピングテーブルに従い、該第１のシステムに関する該ユーザのＩＤ情報から、第２のシステムに関する該ユーザのＩＤ情報を取得する。該第１のシステムは、該第２のシステムに関するユーザのＩＤ情報を該第２のシステムに送信し、該第２のシステムは、ユーザＩＤ認証に成功すると、該ユーザが自動的にログオンすることを許可することができる。システム間で通信される該ユーザＩＤ情報を、デジタル署名技術を使用して、暗号化および復号化してもよい。また、該方法を達成するためのシステムも提供する。

Description

本開示は、概してコンピュータおよびインターネット技術、特にシステム間シングルサインオン（ＳＳＯ）のシステムおよび方法に関する。

多くのインターネット系アプリケーションは、互いに連携しているが、依然として独立している、複数のシステムに渡る一連のステップを実行することをユーザに要求する。例えば、インターネット商用アプリケーションにおいて、消費者は、販売者のウェブサイトで購入する製品を選択してもよいが、支払いサービス業者が所有する別のウェブサイトを通して支払いを行う必要がある。この手順は、消費者対消費者（Ｃ２Ｃ）電子商取引アプリケーションにおいて特に一般的であり、販売者は、電子決済を受け取る態勢ではない、または直接支払いを行うのに信用があるとの評判をまだ受けていない。インターネットオークションでは、例えば、買手がＣ２Ｃウェブサイト（オークションサイト）で購入セレクションを作成するが、販売者に直接支払う代わりに、買手は、多くの場合、その安全で、信頼性があり、かつ便利な即時電子決済で知られる場合がある、第３者であるサービス業者の支払いウェブサイトから支払うことを好む。本実施例では、Ｃ２Ｃウェブサイトおよび第３者の支払いウェブサイトは、２つの独立した会社により維持される、２つの独立したウェブサイトであり、それぞれは独自のユーザＩＤドメインおよびＩＤ認証メカニズムを有する。購入取引を完了するには、買手は、２回（Ｃ２Ｃウェブサイトで１回、第３者の支払いウェブサイトでもう１回）ログオンする必要がある場合がある。しかし、ユーザ（買手）の視点から見ると、１つの購入取引中に、２つの異なるウェブサイトにサインオンすることなく、速やかで簡易化された買い物体験が通常望ましい。

ＳＳＯは、ユーザが、ＩＤ認証のために、１回のみユーザＩＤ情報を入力すればよく、その結果、ユーザＩＤ認証を必要とする複数のシステムまたはアプリケーションプログラムに自動的にサインオンすることができる、ログオン環境を指す。ユーザＩＤ情報の１回限りの入力は、複数のシステムまたはアプリケーションプログラムの１つで行われる。ユーザは、他のシステムまたはアプリケーションプログラムから、ユーザＩＤ情報を再度入力する必要はない。

従来のＳＳＯ方法およびシステムは、（１）ユニバーサルユーザビューを維持するための集中ユーザ管理システム、（２）統一されたユーザＩＤ認証を実行するための共通ユーザＩＤ認証システムの２つの基本的なソフトウェアおよびハードウェアコンポーネントに基づく。ユーザは最初に、ユニバーサルユーザＩＤを使用して、共通ユーザＩＤ認証システムにサインオンし、それによって加入しているシステムにユーザのＩＤを証明するための承認トークンを取得する。ユーザが同一ユーザＩＤ管理ドメイン内の加入しているシステムを訪問することを要求すると、隠し「パスワード」として認証トークンがユーザのログオン要求に含まれる。対象の加入しているシステムは、共通ユーザＩＤ認証システムにトークンの妥当性を検証するよう問い合わせ、問い合わせの結果に基づき、ユーザＩＤが有効であるかを判断する。

図１は、従来のＳＳＯ方法およびシステムの例を図示する。図１の方法およびシステムによる、シングルサインオンのための手順を以下に記載する。

ステップ１では、ユーザ（図示せず）は、ユーザのブラウザ１００を介してアプリケーションシステム１１０にその特定のリソースにアクセスするための最初の要求を行う。ユーザが承認ＩＤトークンを有していないことが発見されると、アプリケーションシステム１１０は、ＩＤ認証のために、ユーザを共通ＩＤ認証および承認システム１２０にリダイレクトする。共通ＩＤ認証および承認システム１２０は、ユーザＩＤ管理に共通ユーザＩＤライブラリ１３０を利用する。

ステップ２では、ユーザは、共通ＩＤ認証および認証システム１２０でＩＤ認証プロセスを通過し、承認ＩＤトークンを受信する。

ステップ３では、ユーザは共通ＩＤ認証および承認システム１２０によって、アプリケーションシステム１１０にリダイレクトされ、承認ＩＤトークンをアプリケーションシステム１１０に送信する。

ステップ４では、アプリケーションシステム１１０は、ＩＤトークンの妥当性を検証するために、承認ＩＤトークンを共通ＩＤ認証および承認システム１２０に送信する。ＩＤトークンが有効であることが証明されると、アプリケーションシステム１１０は、ユーザが要求したリソースにアクセスすることを許可し、そうでなければ、アプリケーションシステム１１０は、ユーザによるアクセスを拒否する。

図示されるように、従来のＳＳＯ方法は、複数のアプリケーションシステムにより共有される共通ＩＤ認証および承認システムを必要とし、共通ユーザＩＤライブラリをさらに必要とする。複数のアプリケーションシステムが様々な管理システムを使用する多様なウェブサイトにホストされるため、共通ユーザＩＤライブラリおよび共通ＩＤ認証ならびに承認システムを確立することは、管理戦略および技術的導入の両方に困難をもたらす。そのような困難の代表的な例には、以下が挙げられる。
１．異なるウェブサイトは、異なるユーザグループを有する。これらのユーザグループは、それぞれにセットを構成する。これらのセットは、互いに交差する場合があるが、通常、互いと同一ではない。結果として、異なるユーザグループを共通ユーザＩＤライブライに一体化し、一元管理することは難しい。
２．異なるウェブサイトは、ユーザ登録および管理のための独自の固有な方法ならびに手順を有する。異なるウェブサイトにそれらのシステムを共通ユーザＩＤ管理システムに変換することを要求することは、多くの場合、ビジネス要件と両立しない。
３．共通ユーザＩＤライブラリが複数のシステムに共有されるとしても、それぞれのシステムは、個々にアップグレードする必要がある場合がある。結果として、使用される標準規格に関して合意を得ることは難しく、共通ユーザＩＤライブラリの確立および維持において、どのシステムが優位性を有するべきかを判断することは、さらに難しい。
４．インターネット上で、ＩＤトークンは、通常、一般に同一ＳＳＯログオンドメインのすべてのウェブサイトが同一ネットワークドメインに属することを要求する、クッキーを使用して通信される。可能であるとしても、異なるネットワークドメインに渡りＳＳＯを確立することは、非常に複雑な手順を必要とする。
５．共通ユーザＩＤ認証システムは、集中セッション管理ユニットであり、典型的に、単一障害点であり、性能においてボトルネックとなる問題点である。そのような問題の解決には、費用の掛かる、複雑なクラスタ技術が必要である場合があり、システムの構築および維持費用を大幅に増加する。
６．複数の個別ユーザＩＤ認証および管理システムを共通ユーザＩＤ認証および管理システムに変更するために、既存のシステムの相当な変更および改造が必要となる場合がある。これは、費用を増大するだけでなく、大きなリスクも伴う。

前述の理由のため、ＳＳＯ方法およびシステムの改善に対する重大な必要性が存在する。

従来の集中モデルの代わりに、ユーザＩＤ管理の分散モデルを使用するシングルサインオン（ＳＳＯ）技術を記載する。システム間シングルサインオンは、複数のシステムのユーザＩＤをマップするためのユーザＩＤマッピング概念を使用することにより可能になる。

一側面によると、第１のシステムと第２のシステムとの間のシングルサインオンの方法が提供される。第１のシステムは、第１のシステムに関するユーザのＩＤ情報を取得する。その後第１のシステムは、システム間ユーザＩＤマッピング関係に従い、第１のシステムに関するユーザのＩＤ情報から第２のシステムに関するユーザのＩＤ情報を取得し、第２のシステムに関するユーザのＩＤ情報を第２のシステムに送信する。ユーザのＩＤ情報を受信した上で、第２のシステムは、ユーザが第２のシステムにサインオンできるようにする。

一実施形態では、システム間で通信されるユーザＩＤ情報は、デジタル署名技術を使用して暗号化される。例えば、第１のシステムは、第２のシステムに関するユーザのＩＤ情報に添付される署名を作成し、第２のシステムに関するユーザのＩＤ情報と共に該署名を第２のシステムに送信する。第２のシステムは、受信した署名を審査することによって、ユーザＩＤ情報を認証する。１つの例示的なアプリケーションでは、ユーザは、最初に第１のシステムにサインオンする。第２のシステムは、ユーザのＩＤ情報が認証された場合、ユーザが第２のシステムにサインオンできるようにする。ユーザが第１のシステムにまだサインオンしていない場合、第１のシステムは、ユーザのＩＤを認証するために、ユーザにサインオンすることを要求する場合がある。

第１のシステムは、ユーザが第２のシステムにサインオンしようとしたという知らせを受けた上で、署名を作成するように設定されていてもよい。この知らせは、第１のシステムでユーザにより起動されたログオン要求、または第２のシステムによって第１のシステムにリダイレクトされたログオン要求のいずれかである場合がある。

該方法の一実施形態では、第１のシステムは、ユーザが第１のシステムから来たことを第２のシステムに知らせる。第２のシステムは、この認識を使用して、第２のシステムにサインオンする際のユーザの権限を絞り込む、例えば制限してもよい。

署名は、第１のシステムにより、暗号デジタル署名で暗号化されてもよい。従って、第２のシステムは、署名を認証するために、暗号デジタル署名を復号化する。暗号化および復号化は、公開鍵暗号化および秘密鍵暗号化などのいずれの適した暗号化技術を使用して行われてもよい。また、ハッシング技術を使用してもよい。第１のシステムは、ユーザＩＤ情報を第２のシステムに送信する前に、第２のシステムに関するユーザＩＤ情報の少なくとも一部分からハッシュを作成してもよい。

一実施形態では、第１のシステムは、署名および／またはユーザのＩＤ情報を第２のシステムに送信する前に、署名および／または第２のシステムに関するユーザのＩＤ情報にタイムスタンプを押す。第２のシステムは、タイムスタンプ情報を確認することによって、署名および／またはユーザのＩＤ情報を認証する。例えば、タイムスタンプ情報は、現行のタイムスタンプと同一ユーザに関する以前のタイムスタンプとを比較することにより、確認されてもよい。署名および／またはユーザのＩＤ情報は、現行のタイムスタンプが以前のタイムスタンプの後続である場合にのみ認証される。第２のシステムは、署名のログ記録および受信したユーザのＩＤ情報を保持する場合がある。

別の側面によると、システム間ユーザサインオンを認証するためのシステムが提供される。該システムは、データストレージ、およびデータストレージに保存されたユーザ情報を使用して、ログオンを要求しているユーザのＩＤを認証するためのＩＤ認証デバイスを有する。該システムは、データストレージに保存されるユーザＩＤマッピングデータをさらに有する。ユーザＩＤマッピングデータは、現行システムに関するユーザＩＤ情報とパートナーシステムに関するユーザＩＤ情報との間のマッピング関係を定義する。該システムは、マッチング関係を使用して、システムに関するユーザＩＤ情報からパートナーシステムに関するユーザＩＤ情報を取得するように適応される。

一実施形態では、該システムは、パートナーシステムに関するユーザＩＤ情報に添付される署名を生成するための署名ジェネレータを有する。署名ジェネレータは、暗号化アルゴリズムを使用してもよい。

別の側面によると、システム間ユーザサインオンを認証するためのシステムは、現行システムに関するユーザＩＤ情報を保存するデータストレージ、およびデータストレージに保存されたユーザＩＤ情報を使用してユーザＩＤを認証するためのＩＤ認証デバイスを有する。該システムは、パートナーシステムから受信したユーザＩＤに添付された署名を復号化し、データストレージに保存されたユーザＩＤ情報を判断することによって、受信したユーザＩＤを認証するための署名認証デバイスをさらに有する。該システムは、署名認証デバイスによる署名の認証が成功した上で、ユーザがログオンすることを許可することができる。一実施形態では、該システムは、ユーザのログオン方法に従い、ユーザの権限を制限するためのユーザ権限コントローラをさらに有する。

従来のＳＳＯ方法およびシステムとは異なり、本開示に記載される技術は、集中モデルの代わりに、分散ユーザ管理モデルを使用する。システム間ＩＤマッピング概念を使用し、異なるシステムに関するユーザＩＤ情報を統合するために、直接ユーザＩＤマッピングテーブルが構築されてもよい。安全性を強化するために、デジタル署名技術を使用することができる。ユーザＩＤマッピングおよびデジタル署名技術の両方は、既存のシステムの単純な拡張であり、既存のユーザＩＤ認証システムの根本的な変更を必要としない。複数の独立したシステムを含む、大きな共同システムは、相互信頼関係に基づき、それぞれのシステムを大幅に変更したり、その独立性を放棄したりする必要なく、構築される場合がある。

記載される技術の他の特徴および利点は、以下の詳細な説明および図から、より容易に理解されるだろう。

添付の図を参照しながら、詳細な説明を記載する。図では、参照番号の最も左の数字により、参照番号が最初に表示される図を識別する。同一参照番号の異なる図での使用は、同様または同一事項を示す。

以下の代表的な実施例に実証されるように、本明細書に記載の技術は、既存のシングルサインオン（ＳＳＯ）方法に見られるユーザＩＤ管理の集中モデルから離れ、ユーザＩＤ管理の分散モデルを導入する。この設計は、高度な技術的複雑性の問題および管理の困難性に対処する。

本開示の一側面によると、複数のシステムのユーザＩＤをマップするためにシステム間ユーザＩＤマッピングを使用する、システム間シングルサインオンのための方法が提供される。Ｃ２Ｃウェブサイトまたは支払いウェブサイトのような、それぞれが独立したウェブサイトである場合がある、別個のパートナーシステムは、独自のユーザＩＤおよびユーザＩＤ管理システムを保持することが可能であり、共通ユーザＩＤライブラリおよび共通ユーザＩＤ管理システムに準拠する必要はない。

異なるシステムに関するユーザＩＤは、たとえ同一ユーザであっても異なる可能性があるため、本開示は、異なるシステム間で調整するためのシステム間ユーザＩＤマッピング技術を導入する。マッピングは、異なるシステム間における同一ユーザのＩＤのマッチング対応を定義する。特定のユーザのそれぞれのＩＤは、異なるシステムにおいて異なる場合がある、ユーザ名およびパスワードなどの基本属性を有する場合があるが、生年月日、住所、および選好などのその他の属性が含まれている場合もある。マッピングは、いずれの適した方法で行われてもよいが、好ましくは、システムがそれぞれのユーザを一意的に識別することができ、別のシステムに関連するユーザのＩＤ情報の認識に基づき、１つのシステムに関するそれぞれのユーザのＩＤ情報が識別可能であるべきである。

図２は、本開示によるインターネット電子商取引においてシングルサインオンを達成するための例示的なシステム２００の概略図である。図２に示されるように、ユーザＣは、ユーザのブラウザ２１０を介して、ウェブサイトＡおよびウェブサイトＢに代表される２つのパートナーシステムに関連するインターネット取引を試みる。シングルサインオンは、ウェブサイトＡとウェブサイトＢとの間で行われる。ウェブサイトＡおよびウェブサイトＢは、インターネット上の２つの独立したウェブサイトである。それらは、インターネット上のどこに位置してもよく、ネットワークドメインＡおよびネットワークドメインＢの２つの異なるドメインに属していてもよく、同一のネットワークドメインに属していてもよい。

ウェブサイトＡは、データストレージ２２０に保存されたユーザライブラリ２２４によって定義される、独自のユーザグループを有する。またウェブサイトＢも、データストレージ２３０に保存されたユーザライブラリ２３４によって定義される、独自のユーザグループを有する。データストレージ２２０および２３０のそれぞれは、単一ストレージデバイスまたは複合ストレージシステムであってもよい。

ウェブサイトＡは、ログオンを要求しているユーザのＩＤを認証するためのＩＤ認証デバイス２２１をさらに有する。認証プロセスは、データストレージ２２０に保存されるユーザライブラリ２２４のユーザＩＤ情報を利用する。ユーザのＩＤが認証されると、ユーザは、ウェブサイトＡの要求したリソースにアクセスすることが許可される。

ウェブサイトＡは、データストレージ２２０に保存されたユーザＩＤマッピングデータ２２６をさらに有する。ユーザＩＤマッピングデータ２２６は、ウェブサイトＡに関するユーザＩＤ情報とウェブサイトＢに関するユーザＩＤ情報との間のマッピング関係を定義する。ユーザＩＤマッピングデータ２２６は、ウェブサイトＡが、ウェブサイトＡに関する同一ユーザのＩＤ情報から、ウェブサイトＢに関するユーザのＩＤ情報を取得できるようにする。

ウェブサイトＡは、ウェブサイトＢに関するユーザＩＤ情報に添付される署名を生成するためのＩＤ署名ジェネレータ２２２をさらに有する。ＩＤ署名ジェネレータ２２２およびＩＤ認証デバイス２２１は、２つの別個のユニットまたは単一ユニットのいずれかに統合されてもよい。

またウェブサイトＢは、データストレージ２３０に保存されるユーザライブラリ２３４のユーザＩＤ情報を使用して、ユーザＩＤを認証するためのＩＤ認証デバイス２３１も有する。ウェブサイトＢは、ウェブサイトＡから受信したユーザＩＤ情報に添付される署名を復号化するための署名認証デバイス２３２をさらに含む。ＩＤ認証デバイス２３１およびＩＤ署名認証デバイス２３２は、２つの個別ユニットまたは単一ユニットのいずれかに実装することができる。

署名の復号化は、ウェブサイトＡから受信したユーザＩＤの信頼性および完全性を検証するために使用される。ユーザのＩＤが認証された場合、ユーザは、ウェブサイトＢの要求したリソースにアクセスすることを許可される場合がある。

例示的なアプリケーションでは、ウェブサイトＡおよびウェブサイトＢは、電子商取引のためのパートナーシップを確立する。パートナーシップは、ウェブサイトＡおよびウェブサイトＢがユーザ情報を交換し、その結果、マッピングテーブル形式である場合がある、ユーザＩＤマッピングデータ２２６を回収することを可能にする。ユーザＣは、ウェブサイトＡおよびウェブサイトＢの両方の顧客である。典型的に、ユーザＣは、別々に、および独立して、ウェブサイトＡおよびウェブサイトＢの顧客になった可能性がある。同一ユーザＣは、ウェブサイトＡおよびウェブサイトＢに関する異なるユーザＩＤ情報（例えば、異なるユーザ名またはパスワード）を有する場合がある。例えば、ウェブサイトＡに関するユーザＣのＩＤがＣＡであり、ウェブサイトＢに関するユーザＣのＩＤがＣＡである場合、ユーザＩＤマッピングデータ２２６（マッピングテーブルのような）は、ＣＡとＣＢとの間のマッピング関係を、ＣＡ→ＣＢとして示す入力を含み、ウェブサイトＡ上でのＩＤがＣＡであるユーザが、ウェブサイトＢ上でＣＢというＩＤを有することを意味する。適切に構築されている場合、ユーザＩＤマッピングデータ２２６は、ウェブサイトＡがそれぞれのユーザを一意的に識別することを可能にし、ウェブサイトＡに関する同一ユーザのＩＤ情報の認識に基づき、ウェブサイトＢに関するそれぞれのユーザのＩＤ情報が特定できるようにする。

一致したＩＤ情報は、ログオンユーザ名およびパスワードなどの属性を含む場合があるが、システム間で異なる追加属性を含む場合がある。さらに、ユーザＩＤの認証、およびユーザ権限の制御ならびに制限に使用される追加情報もユーザＩＤ情報に添付される場合がある。

例示的なプロセスでは、ウェブサイトＡは、ユーザＣが、ユーザのブラウザ２１０を介してウェブサイトＡにサインオンする際、ウェブサイトＡに関するユーザＣのＩＤ情報を取得する。ＩＤマッピングデータ２２６を適切に使用することにより、ウェブサイトＡは、ウェブサイトＡに関する同一ユーザＣのＩＤ情報から、ウェブサイトＢに関するユーザＣのＩＤ情報を取得する。その後、ウェブサイトＡは、ウェブサイトＢに関するユーザのＩＤ情報をウェブサイトＢに送信する。ユーザのＩＤ情報を受信した上で、受信したＩＤ情報が満足できるものである場合、第２のシステムは、ユーザＣが第２のシステムにサインオンすることを可能にすることができる。

ウェブサイトＡとウェブサイトＢとの間で通信されるユーザＩＤ情報は、安全性を有するために、デジタル署名技術を使用して暗号化されてもよい。ウェブサイトＡは、この目的のために、ＩＤ署名ジェネレータ２２２を有する。例えば、ユーザＣがウェブサイトＡに正常にサインオンした後、ウェブサイトＡは、ウェブサイトＡおよびウェブサイトＢに関するユーザＣのＩＤ情報をＣＡおよびＣＢとそれぞれ定義し、ＩＤ署名ジェネレータ２２２は、ウェブサイトＢに送信する前に、ユーザＩＤ情報ＣＢにデジタル署名する場合がある。いずれの適した暗号化技術を使用して、ユーザＩＤ情報ＣＢにデジタル署名するための署名を生成してもよい。一般的に、署名アルゴリズムは、ウェブサイトＡでの暗号化およびウェブサイトＢでの復号化を調整するために、ウェブサイトＡおよびウェブサイトＢの両方で取り決める必要がある。適した署名アルゴリズムの一実施例は、公開鍵署名アルゴリズムであり、ウェブサイトＡは、それを使用して、その秘密鍵を使用してユーザＩＤ情報に署名し、ウェブサイトＢがウェブサイトＡの秘密鍵と一致する公開鍵を使用して署名を復号化できるようにしてもよい。

ウェブサイトＡでＩＤ署名ジェネレータ２２２により生成されるデジタル署名は、第２のシステムに関するユーザのＩＤ情報ＣＢに添付される。そしてデジタル署名およびＩＤ情報ＣＢは、ウェブサイトＢへのログオンを要求するために、両方ともウェブサイトＢに送信される。

ウェブサイトＢは、ウェブサイトＡからログオン要求を受信し、ログオン要求が認証を必要とする署名を含むことを検出する。ウェブサイトＢは、この目的のために、ＩＤ署名ベリファイア２３２を有する。ＩＤ署名ベリファイア２３２は、署名を復号化し、受信した署名およびユーザのＩＤ情報の信頼性ならびに完全性などの妥当性を検証する。署名およびユーザのＩＤ情報が妥当性テストに合格した場合、ウェブサイトＢは、ウェブサイトＡから送信されたＩＤ情報から、ユーザＣのＩＤを判断する。ウェブサイトＢは、ＣＢをウェブサイトＢに関するユーザＣの有効なＩＤとして承認し、その結果、ユーザＣに適切な役割およびセッションを確立する。

署名およびＩＤ情報が妥当性テストに不合格となった場合、ウェブサイトＢは、ユーザＣによるログオン要求を否認することになるであろう。場合によっては、署名およびＩＤ情報が妥当性テストに合格したとしても、特定のユーザＩＤであるＣＢは、ウェブサイトＢで導入される特定の追加制限により、まだログオンを許可されない場合がある。例えば、特定のユーザＩＤであるＣＢは、失効している可能性があるか、または誤ったステータスを持つ、あるいはウェブサイトＢに維持されるブラックリスト中に発見される。そのような状況下において、ウェブサイトＢは、ユーザＣのログオン要求を依然として否認することができる。

ウェブサイトＢは、ウェブサイトＢ上のリソースにアクセスする訪問者としてのユーザＣに与えられる権限を制御するための権限コントローラ２３３をさらに有する。通常、特定のユーザＩＤを有するユーザは、ユーザＩＤが作成される際に定められる、権限の固有セットを有する。しかしながら、ユーザがログオンを要求する方法により、ユーザの権限をさらに制御することが望ましい場合がある。例えば、ウェブサイトＢに直接ログオンするユーザは、固有の権限を与えられる一方、別のウェブサイト（例えば、本実施例のウェブサイトＡ）からリダイレクトされるユーザは、より少ない権限が与えられる場合がある。ログオンを要求しているユーザの固有の権限を判断するために、権限コントローラ２３３は、データストレージ２３０に保存されるユーザライブラリ２３４を調べてもよい。ユーザのログイン方法を判断するために、権限コントローラ２３３は、ウェブサイトＡから送信されるログオン要求情報（署名およびユーザＩＤと共に含まれる）を調べてもよい。あるいは、権限コントローラ２３２は、ユーザのログオン方法の情報を含むウェブサイトＢに記録されたセッション情報を調べてもよい。セッション情報は、通常、ユーザＣがサインオンし、セッションを確立した後、ウェブサイトＢ上のログファイルに記録される。

例示的なアプリケーションでは、ウェブサイトＡは、Ｃ２Ｃウェブサイトであり、ウェブサイトＢは、支払いウェブサイトである。ユーザＣがウェブサイトＡ（Ｃ２Ｃウェブサイト）で起動されるウェブサイトＢ（支払いウェブサイト）にサインオンする際、ユーザＣは、現行のセッション中、ウェブサイトＡに関連する支払い取引のみを行い、他のウェブサイトに関連する支払い取引を行わないように、権限コントローラ２３３がユーザＣの現行のセッションの権限を制限してもよい。一般に、支払いウェブサイトは、Ｃ２Ｃウェブサイトより高度な安全性を有する。権限コントローラ２３３の使用は、安全性と便利性との適切なバランスを有する、よりよいパートナーシップを達成することを助長する。例えば、適切な権限制御により、Ｃ２Ｃウェブサイトに関するユーザＩＤ情報（ユーザ名、およびパスワードまたはセキュリティコードなど）が盗まれる、あるいは危険にさらされる場合でも、ユーザとＣ２Ｃウェブサイトとの間のトランザクションのみに影響する。

上記に示されるように、ウェブサイトＡとウェブサイトＢとの間のシングルサインオンは、ユーザＩＤマッピングデータにより可能となり、デジタルＩＤ署名技術により、さらに安全になる。デジタルＩＤ署名に使用される署名アルゴリズムは、本開示によるシングルサインオンに安全性を提供するための重要なコンポーネントである。好ましくは、署名アルゴリズムは、以下のセキュリティ要件の側面を満足するべきである。
（１）情報（ウェブサイトＢに関するユーザＩＤ情報に署名される署名、およびその他の追加署名情報を含む）が確かにウェブサイトＡから送信されたものであることを証明するための信頼性。
（２）ＩＤ情報が署名された後、署名およびＩＤ情報が不正者により改ざんされていないことを証明する完全性。
（３）ウェブサイトＡ以外、ウェブサイトＢおよびいかなるその他の第３者を含む誰もが有効な署名をレコード上に作成することができないことを保証する、非否認。適切な非否認手段により、妥当性および安全性の疑問に議論が生じた場合、ウェブサイトＡは、レコード上の署名の作成者であることを否定できない。
（４）ＩＤ署名が有効に使用されるのは、１回のみであることを保証する、リプレイ防止。１度使用されると、ＩＤ署名は、もはや有効ではなくなり、従って、再び使用することができない。これは、第３盗聴者がユーザＩＤ署名を盗み、署名を再適用してウェブサイトＢへのログオンアクセスを手に入れることを防止する。

上記に記載の安全対策（信頼性、完全性、および非否認）を達成するためのある例示的な技術は、公開鍵デジタル署名アルゴリズムである。このアルゴリズムを使用するために、ウェブサイトＡおよびウェブサイトＢは、事前に公開鍵および秘密鍵の組を取り決める。秘密鍵は、ウェブサイトＡによってウェブサイトＢを含むその他のエンティティから隠されて保管される。秘密鍵と一致する公開鍵は、公開され、特にウェブサイトＢに既知である。実際のアプリケーションでは、ウェブサイトＡのＩＤ署名ジェネレータ２２２は、公開鍵デジタル署名アルゴリズムを適用し、秘密鍵を使用してウェブサイトＢに関するユーザＩＤ情報に署名する。署名されたユーザＩＤの受信した上で、ウェブサイトＢのＩＤ署名ベリファイア２３２は、同一の公開鍵デジタル署名アルゴリズムに従って、公開鍵を使用して受信した署名を復号化する。この暗号化−復号化手順は、ウェブサイトＡにより署名されたＩＤ署名の信頼性および完全性を検証するための基盤を提供する。同時に、ウェブサイトＢは、非否認手段を提供するために、セッションログの認証されたＩＤ署名を記録する。記録されたセッションログにより、議論が生じた際にウェブサイトＡが記録されたＩＤ署名を実行したことを否認することを避けられる。

リプレイを防止するための１つの例示的な技術は、タイムスタンプの使用である。ウェブサイトＡからウェブサイトＢに通信されるユーザＩＤには、タイムスタンプが押され、またログオン要求には、ユーザＩＤにタイムスタンプが押されていること、および受信者であるシステムウェブサイトＢによる確認および認証が必要であることを示す情報が含まれてもよい。好ましい実施形態では、タイムスタンプは、デジタル署名の署名手順における不可欠な部分として実装される。例えば、署名の作成に選択されるデジタル署名アルゴリズムは、ウェブサイトＡで署名されるＩＤ情報にタイムスタンプが添付されていることを必要とし、タイムスタンプとＩＤ情報は、一緒に署名される場合がある。これは、ＩＤ情報およびタイムスタンプ情報の両方の信頼性および完全性を保証する。ウェブサイトＢにおいて、署名の復号化は、ＩＤ情報およびタイムスタンプ情報の両方の信頼性および完全性を同時に検証する。

タイムスタンプ情報は、様々な方法でリプレイ防止に使用されてもよい。以下は、２つの実施例である。

１．ウェブサイトＢでは、ＩＤ署名ベリファイア２３２がウェブサイトＡから受信したＩＤ署名を認証すると同時に、現行のＩＤ署名のタイムスタンプと、同一ユーザ（ユーザＣ）のウェブサイトＡから送信された以前のＩＤ署名のタイムスタンプを比較する。同一ユーザによる継続的なログオン要求は、常に時間が増加するため、現行のタイムスタンプが以前のタイムスタンプより古いか、以前のタイムスタンプと同一であるかのいずれかの場合、リプレイの試みが検出される可能性がある。そのような検出を行った上で、ＩＤ署名認証は、失敗し、ウェブサイトＢはユーザＣによるアクセスを否認する。

ユーザＣが初めてウェブサイトＢを訪問している場合、タイムスタンプは、以前のタイムスタンプと比較することなく承認される必要がある場合があるが、署名およびユーザＩＤ情報が初めて適用されるため、この特別な状況において、リプレイのリスクは無い。ユーザＣが正真正銘の正当な繰り返し訪問を行っている場合、異なる、唯一の継続的なタイムスタンプを有する、現行の署名および以前の署名が別々に作成される。この技術を使用し、ユーザＣが特定の署名で正真正銘の訪問を行った場合、同一署名は、事実上失効する。この技術では、ウェブサイトＢが、タイムスタンプなどの追加添付情報を含む、すべてのログオン要求のログ記録を保持する必要がある。

２．ウェブサイトＡおよびウェブサイトＢは、作成後の署名の妥当性の期限を取り決める。例えば、ウェブサイトＡおよびウェブサイトＢは、署名は、作成後１分間のみ有効であると取り決めてもよい。署名を受信した上で、ウェブサイトＢは、署名のタイムスタンプと、現在の時間（実際の時刻）を比較して、署名がまだ有効であるかどうかを判断する。この技術を使用することで、署名が盗まれる、または漏れる、いかなる事象においても、その妥当性は１分間のみに制限される。従って、安全性侵害がもたらす結果は最小化される。実際には、ウェブサイトＡが、署名されたユーザＩＤ情報の署名作成後、即座に送信することが望ましい場合がある。これは、１分間を大幅に下回る失効期限を取り決めることにより、可能となる場合がある。

タイムスタンプ情報を使用するための上記の２つの技術は、互いに排他的ではない。それらを、実践に組み合わせてもよい。例えば、第１の技術は、単独で使用される場合、ウェブサイトＡで作成された署名が、ウェブサイトＢに伝達される前に盗まれる、または漏れるという事象において、損なわれる場合がある。この場合、ウェブサイトＢは、ユーザＣのタイムスタンプの適切な記録を有さず、盗まれたまたは漏れた署名を所有する犯人がタイムスタンプテストに合格し得る。しかしながら、上記に記載される第１の技術と第２の技術の両方の組み合わせは、盗まれたまたは漏れた署名は、かなりの時間が経過するまで適用される可能性が低いため、問題が解決される可能性がある。

署名の作成および認証に使用可能な署名アルゴリズムには、デジタル署名アルゴリズム（ＤＳＡ）などの公開鍵署名アルゴリズムが挙げられるが、それに限定されない。様々な技術が使用可能であり、パートナーウェブサイトの必要性に最も適するものを選択してもよい。例えば、ウェブサイトＡおよびウェブサイトＢが十分な程度の相互信頼を有する場合、非否認のためのメカニズムは必要ない場合がある。この場合、ウェブサイトＡは、ユーザＩＤ情報およびタイムスタンプ情報の暗号化に秘密鍵アルゴリズムを使用し、ウェブサイトＢに暗号文（暗号テキスト文字列）を送信して、信頼性、完全性、およびリプレイ防止を保証する。

あるいは、ＩＤ情報およびタイムスタンプ情報の署名に、ハッシュアルゴリズムＳＨＡＩ（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｓｍ、ｖｅｒｓｉｏｎ１．０）またはＭＤ５（Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ、ｖｅｒｓｉｏｎ５）、などのより単純なアルゴリズムを使用してもよい。ハッシュアルゴリズムにより選択され、両者（ウェブサイトＡおよびウェブサイトＢ）で取り決めたシードを使用して、第３者がユーザＩＤ情報に有効な署名を作成することを防止してもよい。

図３は、本開示による、例示的なシングルサインオンプロセスのフロー図を示す。プロセスは、ブロックのコレクションとして論理フローグラフに示され、ハードウェア、ソフトウェア、またはその組み合わせに実装可能な一連の動作を示す。ソフトウェアの文脈において、ブロックは、コンピュータ実行可能指示を示し、１つ以上のプロセッサで実行される場合、記載される動作を実行する。一般的に、コンピュータ実行可能指示は、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含み、特定の機能を実行する、または特定の抽象データ型を導入する。動作が記載される順序は、構文解析のための制限を意図するものではなく、ブロックに記載されるいずれの番号も、いずれの順序で組み合わせることが可能であり、かつ／または平行してプロセスに導入することができる。検討目的のために、図２のシステム２００を参照してプロセスを記載する。

本実施例では、ユーザは、最初にウェブサイトＡにサインオンする。ウェブサイトＡは、ウェブサイトＢへの自動ログオンを達成するためのユーザＩＤ署名の作成プロセスを開始する。例示的なシングルサインオンプロセスを以下のブロックに記載する。

ブロック３００では、ユーザＣは、ウェブサイトＡにログオンすることを要求し、ＩＤ認証のためのＩＤ情報（ユーザ名およびパスワードなど）を入力する。

ブロック３０１では、ウェブサイトＡのＩＤ認証デバイス２２１がデータストレージ２２０に保存されるユーザライブラリ２２４からユーザＩＤ情報を読み出し、ユーザＣにより提供されるユーザＩＤ情報を認証する。

ブロック３０２では、ユーザＩＤ認証が成功した上で、ユーザＣがウェブサイトＡのリソースにアクセスすることを許可される。

ブロック３０３では、ウェブサイトＡがウェブサイトＢに関するユーザＣのＩＤ情報を判断し、ユーザＩＤ情報に基づき、ユーザＩＤ署名を生成する。場合によっては、ユーザＣのＩＤ情報が判断され、署名される前に、ウェブサイトＡが、ユーザＣがウェブサイトＢでサインオンしているかを検出することを可能にするメカニズムが採用されてもよい。これは、自動的に行われるか、またはユーザＣにより明確に指示された上で行われる。例えば、ウェブサイトＡは、ユーザＣがウェブサイトＢからのサービスまたはサポートを必要とするウェブサイトＡのリソースを要求した場合に、ユーザＣがウェブサイトＢにサインオンしようとしていることを自動的に検出してもよい。

ウェブサイトＢに関するユーザＣのＩＤ情報は、データストレージ２２０に保存されるＩＤマッピングデータ２２６を使用して、ウェブサイトＡで判断される。例えば、ユーザＩＤマッピングデータ２２６がウェブサイトＡ／ウェブサイトＢ（Ａ／Ｂ）マッピングテーブルを含む場合、ＩＤ署名ジェネレータ２２２は、ウェブサイトＢに関するユーザＣのＩＤ情報を、マッピングテーブルを読み込むことによって取得してもよい。そしてＩＤ署名ジェネレータ２２２は、取り決められた署名アルゴリズムを使用して、ウェブサイトＢに関するユーザＣのＩＤ情報、およびその他の追加情報（タイムスタンプ情報など）に署名する。ＩＤ署名ジェネレータ２２２は、ウェブサイトＢへのログオン要求にＩＤ署名をさらに添付する。

ブロック３０４では、ウェブサイトＡは、ユーザＩＤ署名を含むログオン要求をウェブサイトＢに誘導する。ログオン要求では、ウェブサイトＡはさらに、ユーザＣにウェブサイトＡから来ているというラベルを付けてもよい。そのようなラベリングは、異なるサブドメイン名または追加添付パラメータのような形であってもよい。

ブロック３０５では、ウェブサイトＢは、ウェブサイトＡから受信したユーザＩＤ署名が有効であるかを判断する。これは、取り決められた署名アルゴリズムを使用して署名を復号化する、ＩＤ署名ベリファイア２３２によって行われる。ユーザＩＤ署名が無効な場合、ウェブサイトＢは、ユーザＣのログオン要求を否認する。ユーザＩＤ署名が有効な場合、プロセスは次のステップ３０６に進む。

ブロック３０６では、ウェブサイトＡからのユーザＩＤ署名が有効であると判断されたことにより、ウェブサイトＢは、ユーザＣが信頼できるウェブサイトＡにすでにサインオンしており、従って、ウェブサイトＢにログオンするための許可も与えられるべきであると判断する。従って、ウェブサイトＢは、ユーザＣのセッションを確立し、ユーザＣがウェブサイトＢの要求するリソースにアクセスすることを許可する。セッションは、ウェブサイトＡから受信したユーザＩＤ情報から識別される、ウェブサイトＢに関するユーザＩＤ情報に従って確立される。ウェブサイトＢはさらに、今後のログオン要求のタイムスタンプの比較など、その他の目的のために使用される場合がある、ユーザＩＤ署名をセッションログに記録してもよい。

ブロック３０７では、ウェブサイトＢは、ユーザＣのステータスを確認し、確立されたセッションに対するその権限を判断する。これは、権限コントローラ２３３によって行われる。特定のユーザＣは、特定の要求されるリソースにアクセスする権限を有さないことが発見された場合、ウェブサイトＢは、ユーザＣのユーザＩＤが有効であるにも関わらず、ユーザＣの要求を否認する。特定のユーザＣが特定の要求するリソースにアクセスする権限を有することが発見された場合、ウェブサイトは該アクセスを許可する。

上記のステップは、同一または同様の目的を達成するために、より少ないステップに一体化されてもよく、またはより多くのステップに拡張されてもよいことが理解される。例えば、ステップ３０６およびステップ３０７は、単一ステップとして同時に実行されてもよい。

上記に記載のシングルサインオンプロセスは、同一ユーザＣによる複数の要求または複数のトランザクションに関係する、閉じていないセッションに対して、１回のみ実行される場合がある。１度ユーザＣとウェブサイトＢが有効なセッションを確立すると、ユーザＣはセッションを継続することを選択し、ウェブサイトＡに戻り、上記に記載のシングルサインオンプロセスを繰り返すことなく、ウェブサイトＢの認可されたリソースに直接アクセスしてもよい。継続的なセッションには、最初にアクセスしたリソースへの繰り返しアクセス、またはその他の認可されたリソースへの新しいアクセスが含まれてもよい。

上記の例示的な実施形態では、ウェブサイトＡが署名プロセスを開始する。署名は、ユーザＣがウェブサイトＢへのログオンを要求する度に生成される必要は無いことに留意されたい。本開示による方法は、ウェブサイトＡは、新しい署名が必要な場合にのみ、ユーザＩＤ情報に署名するように要求されるように設定されていてもよい。例えば、ユーザＣがウェブサイトＡからウェブサイトＢを訪問しようとする度に、ウェブサイトＡが独自の署名プロセスを開始する代わりに、ウェブサイトＢが署名されたユーザＩＤ情報の送信要求を受信した場合にのみ、ウェブサイトＡがこのアクションを行ってもよい。この設計は、不必要な繰り返し、および署名作成ならびに認証の余剰を回避する。署名アルゴリズムの実行は、相当な量のコンピュータ資源を使用するため、そのような実行を削減することは、相当な量の運営費用を節約する可能性がある。さらに、署名作成および認証の発生率がより少ないことにより、保持する記録および署名が漏れるリスクが低くなるという結果がもたらされる。

図４は、例示的なシングルサインオンプロセスを示すフロー図であり、ウェブサイトＢは、いつウェブサイトＡにユーザＩＤ情報に署名するように要求するか決定する。例示的なプロセスを以下のブロックに記載する。

ブロック４００では、ユーザＣがウェブサイトＢにログオンし、特定のリソースにアクセスすることを要求する。これは、ユーザＣにより、ウェブサイトＢで直接開始されてもよいが、ウェブサイトＡがＣ２Ｃサイトである一方、ウェブサイトＢは、支払いサイトである、示される実施例においては、サインオンするための要求は、ウェブサイトＡからウェブサイトＢに向けられる可能性が高い。この場合、ログオン要求は、ウェブサイトＡから来ているものとして、ユーザＣを識別してもよい。そのような識別表示は、ログオン要求情報内に、異なるサブドメイン名、または追加添付パラメータのいずれかを含んでもよい。

ブロック４０１では、ウェブサイトＢは、ユーザＣがすでにウェブサイトＢにサインオンしているかどうかを、シングルサインオンプロセスを介して、ウェブサイトから直接的または間接的に判断する。ユーザＣがすでにウェブサイトＢにサインオンしている場合、プロセスは、署名作成および認証ステップを省略し、ウェブサイトＢが要求するリソースへのアクセスに関するユーザＣの権限を判断する、ステップ４０７に跳ぶ。ユーザＣがウェブサイトＢにまだサインオンしていない場合、プロセスは、ステップ４０２に進む。

ブロック４０２では、ウェブサイトＢは、ユーザＣのログオン要求をウェブサイトＡにリダイレクトする。要求は、ウェブサイトＡがウェブサイトＢにユーザＣのＩＤ情報を送信するための要求を識別するパラメータを含む。ＩＤ情報が署名により保護される場合、要求は、ウェブサイトＡがウェブサイトＢに送信されるＩＤ情報に安全に署名するための要求を識別するパラメータを含む。必要に応じて、要求はまた、ユーザＣがアクセスを要求しているウェブサイトＢの特定のリソースを識別してもよい。

ブロック４０３では、ウェブサイトＡのＩＤ署名ジェネレータ２２２がユーザＩＤマッピングデータ２２６からユーザＣのウェブサイトＢに関するユーザＩＤ情報を読み出し、ウェブサイトＡおよびウェブサイトＢに取り決められた署名アルゴリズムを使用してユーザＩＤ情報からユーザＩＤ署名を生成する。またユーザＩＤ署名は、タイムスタンプ情報などの追加情報もカバーする。好ましくは、ウェブサイトＡは、ステップ４０３の最初の時点で、ユーザＣがすでにウェブサイトＡにサインオンしているかを確認してもよい。ユーザＣがウェブサイトＡにまだサインオンしていない場合、ウェブサイトＡは、通常、ステップ４０３を実行する前に、最初にユーザＣにウェブサイトＡにサインオンするよう要求するべきである。この場合、通常のログオンプロセスは、ＩＤ認証デバイス２２１によりユーザ名およびパスワードが確認され、認証されてから行われる場合がある。

ブロック４０４では、ウェブサイトＡは新しく作成されたユーザＩＤ署名をログオン要求に添付し、ユーザＩＤ署名を含むログオン要求をウェブサイトＢにリダイレクトする。

ブロック４０５では、ウェブサイトＢのＩＤ署名ベリファイア２３２が、ウェブサイトＡおよびウェブサイトＢによって取り決められた署名アルゴリズムを使用して復号化することによって、ＩＤ署名の妥当性を検証する。ＩＤ署名が無効な場合、ウェブサイトＢは、ユーザＣの要求されたリソースへのアクセスを否認する。ＩＤ署名が有効な場合、プロセスは、ステップ４０６に進む。

ブロック４０６では、ウェブサイトＡからのユーザＩＤ署名が有効であることが判断されたことにより、ウェブサイトＢは、ユーザＣがすでに信頼されるウェブサイトＡにサインオンしていると判断し、ユーザＣがウェブサイトＢの要求するリソースにアクセスできるように、ユーザＣのセッションを確立する。セッションは、ウェブサイトＡから受信するウェブサイトＢに関するユーザＩＤ情報に従って確立される。ウェブサイトＢはさらに、ユーザＩＤ署名をセッションログに記録し、今後のログオン要求のタイムスタンプ比較など、その他の目的に使用してもよい。

ブロック４０７では、ウェブサイトＢの権限コントローラ２３３は、ユーザＣのステータスを確認し、確立されたセッションに対するその権限を判断する。ユーザＣが特定の要求されたリソースにアクセスする権限を持たないことが発見された場合、ウェブサイトＢは、ユーザＣの要求を否認する。ユーザＣが要求されるリソースにアクセスする権限を有することが発見された場合、ウェブサイトＢは、該アクセスを許可する。

上記技術は、コンピュータ実行可能指示を含む、コンピュータ可読媒体を１つ以上用いて実装してもよい。コンピュータ実行可能指示は、プロセッサが本明細記載の技術による、システム間シングルサインオン（ＳＳＯ）手順を実行できるようにする。コンピュータ可読媒体は、コンピュータデータを保存するためのいずれの適したメモリデバイスであってもよいことが理解される。そのようなメモリデバイスには、ハードディスク、フラッシュメモリデバイス、光学データストレージ、およびフロッピー（登録商標）ディスクが挙げられるが、それらに限定されない。さらに、コンピュータ実行可能指示を含むコンピュータ可読媒体は、ローカルシステムのコンポーネント、または複数のリモートシステム上に分散するコンポーネントで構成されてもよい。コンピュータ事後完了指示のデータは、有形である物理メモリデバイスに伝達されるか、または電子的に伝送されてもよい。

本明細書に示されるように、本開示は、システム間ユーザＩＤマッピング概念を導入することによって、シングルサインオンのための分散モデルを提案する。分散モデルは、シングルサインオン方法の従来の集中モデルに固有である、いくつかの管理リスクおよび技術的リスクを回避する。パートナーシステム（例えば、例示的な実施形態のウェブサイトＡおよびウェブサイトＢ）は、それらの独立性を保つ一方、パートナーシステム間のユーザＩＤマッピングコンポーネントは、柔軟であり、その時点での実際の必要性に応じて、構築、修正、または取り外すことができる。

分散モデルにより、ＩＤ署名ジェネレータおよびＩＤ署名ベリファイアは、集中ユーザＩＤ認証システムを使用することなく、相互に信頼されるシステム間（例えば、相互間ウェブサイト）シングルサインオンメカニズムを確立し、従って、集中ユーザＩＤ認証システムにより引き起こされる、可能性のある性能ボトルネックおよび単一障害点問題を回避する。本開示によるＩＤ署名ジェネレータおよびＩＤ署名ベリファイアは、既存のウェブサイトの単純な拡張である。集中ＩＤ認証システムと比較し、本開示に記載される技術は、既存のウェブサイトの元のＩＤ認証システムの大幅な修正を必要としない。これは、従来のシングルサインオン方法の高運営費用および高リスクの問題を軽減することを助長する。また安全対策も、既存のシステムの単純な拡張である。シングルサインオンプロセスの信頼性、完全性、非否認、およびリプレイ防止を保証する者が、適した署名アルゴリズムを手軽に選択し、実装してもよい。安全性のレベルは、電子商取引を実施するウェブサイトの厳しいセキュリティ要件のほとんどを満足することができる。本開示によるシングルサインオン手順は、署名生成および認証を最小化するために、最適化し、その結果として、速度および便利性の設計目的を達成してもよい。

例示的な実施形態は、２つのパートナーウェブサイトであるウェブサイトＡおよびウェブサイトＢを用いて示されるが、本開示に記載される技術は、この種類のアプリケーションに限定されないことが理解される。例えば、ウェブサイトＢとのウェブサイトＡ／ＢのユーザＩＤマッピングテーブルの確立に加え、ウェブサイトＡは、ウェブサイトＣとウェブサイトＡ／ＣのユーザＩＤマッピングテーブルを確立してもよい。同様に、またウェブサイトＢは、ウェブサイトＣとウェブサイトＢ／ＣのユーザＩＤマッピングテーブルを確立してもよい。すなわち、ウェブサイトＣは、複数のウェブサイトとパートナー関係を確立してもよい。さらに、ウェブサイトＢは、ウェブサイトＢ／ＡのユーザＩＤマッピングテーブルも確立し、本明細書に記載されるようなウェブサイトＡ／ＢのユーザＩＤマッピングテーブルを使用して実行されるトランザクションと逆のトランザクションを実行してもよい。実装の複雑性および関係者の数に関係なく、ユーザＩＤマッピングテーブルを確立した２つのウェブサイトは、本明細書に記載されるものと同一の方法でトランザクションを実行してもよい。

さらに、例示的な実施形態は、電子商取引の文脈でウェブサイトを用いて示されるが、本開示に記載される技術は、この種類のアプリケーションに限定されない。技術は、パートナーシステムの少なくとも一方がシステム内のリソースにアクセスするためにユーザＩＤ認証を必要とするインスタントメッセージシステムなど、いずれのネットワークシステムおよび通信システムに適用されてもよい。

「ユーザＩＤ署名」という用語は、本明細書で使用される際、特定のユーザＩＤ情報に署名された、または添付された署名を指し、該署名がユーザＩＤの所有者によって署名されたことを意味しないことに留意されたい。本明細書に記載される例示的な実施形態では、例えば、ユーザ自身がユーザのＩＤ情報に署名する代わりに、第１のシステム（例えば、ウェブサイトＡ）がユーザ（ユーザＣ）のユーザＩＤ情報に署名することが好ましい。

明細書および図面を含む上記の説明は、例証的なものであり、制限的なものではない。本開示を検証することによって、当技術分野に精通する者により、多くの多様な技術が明らかとなるであろう。上記に記載の開示の様々な特徴および側面は、別個または共同で使用されてもよい。さらに、本開示は、本明細書の最も広義の精神および範囲から逸脱することなく、これら本明細書に記載するものを超えて、いずれの数の環境およびアプリケーションにおいても利用することができる。従って、本開示の範囲は、上記説明を参照して判断されるべきではなく、代わりに、それらの同等物の全範囲に加えて、添付の特許請求の範囲を参照して判断されるべきである。

従来のＳＳＯ方法およびシステムの例を示す図である。 インターネット電子商取引においてシングルサインオンを達成するための例示的なシステムの概略図である。 例示的なシングルサインオンプロセスを示す、フロー図である。 ウェブサイトＢが、いつウェブサイトＡにユーザＩＤ情報に署名するように要求するかを定義する、例示的なシングルサインオンプロセスを示す図である。

Claims (28)

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. 前記ユーザのログオン方法に従い、前記ユーザの権限を制限するためのユーザ権限コントローラをさらに含むことを特徴とする請求項２７に記載のシステム。

Images