カスタマイズ可能なサインオンサービス
カスタマイズ可能なサインオン機能性を提供する手法について記載する。カスタマイズ可能なサインオン機能性は、他のサービスのユーザと使用されるシングルサイン機能性および他の機能性を他のサービスに提供するアクセスマネージャシステムを介するなどして提供される。アクセスマネージャシステムは、様々なユーザの様々なサインオン情報および他のアカウント情報を保持し、それらのユーザが対話する複数の互いに無関係なサービスの代理として、その保持されている情報を使用して、それらのユーザにシングルサインオン機能性を提供することが可能である。アクセスマネージャは、アクセスマネージャから利用可能なシングルサインオン機能性および/または他の機能性に対する様々なタイプのカスタマイズを(たとえば、サービスの運営者による構成によって、サービスごとに)可能にすることが可能であり、そのようなカスタマイズのタイプとして、コブランディングカスタマイズ、ユーザから収集される情報のカスタマイズ、ユーザの代理として動作するために他のサービスに委譲されることが可能な権限のカスタマイズなどがあり、これらの利用可能なカスタマイズは、個々のサービスに固有なように決定される。
【発明の詳細な説明】
【技術分野】
【0001】
以下の開示は、主に、カスタマイズ可能なユーザサインオン機能性を提供する手法に関し、たとえば、この機能性は、シングルサインオンサービスのカスタマである他のサービスのユーザに、カスタマイズ可能なサインオンプロセスを提供するシングルサインオンサービスにより提供される。
【背景技術】
【0002】
日常生活におけるコンピュータの利用が広く普及しつつあり、たとえば、ユーザが、インターネット経由で(たとえば、Webサイトを介して)、あるいは、他のアクセスメカニズム(たとえば、携帯電話網)を介して、様々なタイプのリモートサービスにアクセスしてこれを利用することが可能になっている。たとえば、そのようなサービスは、様々なタイプの情報(たとえば、最新ニュースや参考資料)を提供することが可能なものもあれば、様々なタイプのアクティビティや機能(たとえば、オンラインバンキング、オンラインショッピング、電子メールまたは他のメッセージングサービスなど)を提供することが可能なものもある。一部のサービスは情報および機能を誰にでも提供することが可能であるが、他の多くのサービスは、許可されたユーザのみに制限されており、たとえば、許可されたユーザのみがユーザ情報を利用できるようにすることにより、ユーザ情報のプライバシが保護され(たとえば、ユーザが自分の電子メールを読むためには電子メールサービスにログインしなければならない)、実行されるアクティビティに使用されるユーザデータが管理され(たとえば、ユーザのショッピングを便利にするために、ユーザの金銭情報および出荷先情報(たとえば、ユーザに対して保持されているアカウントの一部)をオンライン商店側が保存する)、ユーザがしかるべき支払いを完了したことや、ユーザがそのサービスの利用に関する他の条件に満足していることが確認される。
【0003】
サービスにサインオン(または「ログオン」または「ログイン」)して、制限された情報または機能性へのアクセスを許可されていることを示すことが可能であるためには、典型的には、ユーザはまず、そのサービスに登録し、そのサービスに固有の、しかるべきサインオン情報(たとえば、ユーザ名およびパスワード)を取得しなければならない。しかしながら、それぞれが固有のサインオン情報を有するサービスが急増しているため、ユーザは、異なるインターネットサイトごとに異なる、多数のサインオン情報のセットを覚えなければならない不便さを強いられている。さらに、インターネットサイトおよびそのようなサービスの他のプロバイダの多くの運営者が、そのようなユーザサインオンを可能にすること、ならびにユーザサインオンデータおよび他の認証データを保持することの機能性を提供する負担から解放されることを望んでいる。
【0004】
こうした状況に対処すべく、提携する複数のサービスまたはシステムの群へのアクセスを可能にするサインオン情報の単一セットをユーザが作成するシングルサインオンシステムが生み出された。残念なことに、現在のシングルサインオンシステムには様々な問題がある。たとえば、サービス運営者の多くが、別の運営者によって提供されるサインオン機能性を使用することに対して億劫である。この億劫さは、利用できるサインオンシステムが所望の機能性を提供できないことなどにより、サインオンシステムと対話する際のユーザエクスペリエンスに一貫性がないため(たとえば、一貫したブランディング、あるいは他の一貫した外観や機能性がないため)であると考えられる。さらに、サービス運営者およびユーザは、セキュリティに関して懸念がある場合がある。それは、たとえば、詐欺師が、シングルサインオンシステムとの対話においてユーザまたはサービス運営者になりすまして、制限された情報または機能性へのアクセス権を不正に取得することが可能なのではないかという恐れである。
【0005】
したがって、シングルサインオンサービスを改善する手法および他の利点を提供することが有益であろう。
【発明を実施するための最良の形態】
【0006】
ユーザと対話するための、カスタマイズ可能な機能性を提供する手法について説明する。カスタマイズ可能な機能性は、他のサービスにシングルサインオン機能性および他の機能性を提供するアクセスマネージャシステムを介するなどして提供される。実施形態によっては、ユーザが利用できるWebサイトまたは他のサービスの運営者が、アクセスマネージャシステムと対話することにより、アクセスマネージャシステムがサービスのユーザに対して利用可能にするシングルサインオン機能性および/または他の機能性をカスタマイズしたり、他の方法で構成したりすることが可能である。アクセスマネージャシステムは、そのような機能性を、様々な実施形態において様々な形式で他のサービスに提供することが可能であり、これは、たとえば、サービスの運営者が初期構成を対話形式で行うことを可能にすることによって、かつ、カスタマイズされた機能性が、アクセスマネージャシステムのAPI(「アプリケーションプログラミングインターフェース」)によるプログラム形式でサービスのユーザに提供されることを可能にすることによって、可能である。少なくとも一部のそのような実施形態では、アクセスマネージャシステムは、様々なユーザの様々なサインオン情報および他のアカウント情報を保持し、それらのユーザが対話する複数の互いに無関係なサービスの代理として、その保持されている情報を使用して、それらのユーザにシングルサインオン機能性を提供する。さらに、少なくとも一部の実施形態では、アクセスマネージャシステムが、その代理として、カスタマイズされた機能性を提供するところのサービス群は、それぞれが、アクセスマネージャシステムのカスタマ(カスタマサービス)であり、これは、たとえば、既にアクセスマネージャシステムに登録しているカスタマサービスが、(たとえば、料金と引き替えに)カスタマイズされた機能性を提供されるようにするためのものである。
【0007】
実施形態によっては、アクセスマネージャは、アクセスマネージャから利用できるシングルサインオン機能性および/または他の機能性に対する様々なタイプのカスタマイズを可能にすることが可能である。カスタマサービスの代理であるアクセスマネージャとのユーザ対話が、個々のカスタマサービスに合わせてカスタマイズされるように、カスタマサービスの運営者が、様々なタイプのカスタマイズを構成することが可能である。たとえば、少なくとも一部の実施形態では、そのようなタイプのカスタマイズとして、サービスのユーザとの対話時にアクセスマネージャによって使用される、そのサービスに対する様々なタイプのコブランディングが含まれることが可能であり、たとえば、ユーザに提示される1つまたは複数の情報群(たとえば、ユーザに対して表示される1つまたは複数のWebページ)のそれぞれに、そのサービスのために構成された様々な情報が含まれ、そのような情報として、たとえば、1つまたは複数の指示された画像(たとえば、ロゴ)、指示されたテキスト、指示されたユーザ選択可能リンク、指示された他のユーザ選択可能コントロール(たとえば、指示されたURL(「ユニフォームリソースロケータ」)から入手できるか、または指示されたコードを実行することにより入手できるような、表示されるメニューバー)、指示されたコードを実行することにより提供される機能などがある。さらに、少なくとも一部の実施形態では、アクセスマネージャから利用可能な機能性のカスタマイズには、アクセスマネージャとの対話時にサービスのユーザから収集される様々なタイプの情報が含まれ、たとえば、サービスの運営者によって選択された1つまたは複数のあらかじめ定義された質問および/またはサービス運営者によって指定された1つまたは複数の質問に基づいてユーザから情報(たとえば、ユーザに関するデモグラフィック情報、嗜好情報、サービスがその操作の実行時に使用する、ユーザに固有の情報、その他)が収集される。コブランディングおよび情報収集のカスタマイズの詳細については、後述する。
【0008】
実施形態によっては、ユーザがアクセスマネージャと対話して、あるサービスのカスタマイズされたサインオンプロセスを完了した後、アクセスマネージャは、そのユーザについての信用証明書(credential)をそのサービスに提供し、これは、たとえば、そのサービスが、その後、ユーザの代理としてアクションを実行する(たとえば、ユーザの代わりに支払いを行う、ユーザの代わりに、保存されているアカウント情報を修正する、など)ための要求を行うことができるように、ユーザがそのサービスの許可されたユーザであることを示すものであり、かつ/または、ユーザを表すものである。この信用証明書は、様々な実施形態において様々な形式をとることが可能であり、たとえば、ユーザに固有の情報(たとえば、ユーザの一意のユーザ名または他の識別子、ユーザの実名または他の識別情報、カスタマイズされたサインオンプロセスにおいてユーザから収集された情報、その他)を、暗号化形式であれ、非暗号化形式であれ、含むことが可能であり、あるいは、単に、アクセスマネージャが後で(返された場合に)ユーザにマッピングできる情報(たとえば、アクセスマネージャまたはサービスに対して一意の番号)であることが可能である。さらに、少なくとも一部の実施形態では、ユーザの代理であるサービスに与えられた信用証明書が、アクセスマネージャによって、そのサービスに固有のものであるとして扱われ、これによって、後で、ユーザの代理として信用証明書を使用する要求が行われた場合には、その要求は、そのサービスによって行われたか、そのサービスの代理で行われた場合に限り、有効として扱われる。さらに、少なくとも一部の実施形態では、信用証明書は、他の様々なタイプの特性を有することが可能である。たとえば、特定の信用証明書が、ある限られた期間においてのみ有効であったり、かつ/または、ユーザの代理での特定のタイプのアクティビティまたは操作についてのみ有効であったりしてよい。その場合、アクセスマネージャは、そのような特性に基づいて、信用証明書の使用を制限することが可能である。信用証明書の詳細については、後述する。
【0009】
実施形態によっては、少なくともいくつかのサービスについて、サービスが実行することを許可されているアクティビティのタイプに関連する、さらなるタイプのカスタマイズがアクセスマネージャによって許可される。たとえば、いくつかのサービスがそれらのサインオンしたユーザに対して実行することを許可されているアクションのタイプを、様々な形式で限定することが可能であり、これは、たとえば、アクセスマネージャによってサービスに付与されている信頼度を反映させることによって可能であり、一例として、信用証明書は、実施形態によっては、限定された期間のみ有効であることが可能であり、その場合、サービスによっては、有効期間を延長するために、それらのユーザの信用証明書を(たとえば、指定された回数まで、指定された全有効期間まで、無期限かつ無制限に)リフレッシュすることを、少なくとも状況によっては、許可されることが可能である。さらに、少なくとも一部の実施形態では、少なくともいくつかのサービスについてアクセスマネージャによって許可されるカスタマイズは、プライマリサービスが、ユーザの代理としてアクションを実行するために、別のセカンダリサービスに対して行うことが可能であってよい、1つまたは複数のタイプの権限委譲を含み、これは、たとえば、アクセスマネージャによって付与された信頼度をプライマリサービスおよび/またはセカンダリサービスに反映させるためのものである。たとえば、信用証明書が与えられた少なくともいくつかのプライマリサービスは、そのような信用証明書を様々な形式で使用する権限を他のサービスに委譲することを許可されることが可能であり、そのような形式として、信用証明書を使用して、少なくともいくつかのタイプのアクションを、表されたユーザの代理として実行すること、少なくとも状況によっては、限定された有効期間で信用証明書をリフレッシュすること、当該ユーザについての、セカンダリサービス専用の新しい信用証明書の発行を要求すること(たとえば、信用証明書がオリジナルの発行先のサービスについてのみ有効である場合)などが含まれる。権限委譲のタイプの詳細については、後述する。
【0010】
アクセスマネージャによって、サービスが利用できるようにされるカスタマイズのタイプは、様々な実施形態において様々な形式で決定されることが可能であり、たとえば、サービスおよび/またはサービス運営者に関して取得可能な情報に基づく自動的な形式で決定されることが可能である。たとえば、悪意のあるサービス(または、悪意のないサービスになりすまそうとするか、その他の方法で悪意のないサービスの代理として動作しようとする、悪意のあるパーティ)が、あるタイプのカスタマイズを許可された場合、それらのタイプのカスタマイズは、大きなセキュリティリスクおよび不利益リスクをもたらしうる。コブランディングタイプのカスタマイズの場合、ユーザに対して表示されるテキストおよび/またはイメージを追加することをサービスに許可することは、(テキストのコンテキストが攻撃的でも違法でもない限り)比較的リスクが少ない。逆に、アクセスマネージャが、ユーザに与えられる情報を生成する際に使用する実行可能コード、またはユーザに与えられる情報に含まれる実行可能コード(たとえば、ユーザに送られるWebページの一部として含まれるJava(登録商標)アプレット)を指定することをサービスに許可することは、比較的高いリスクをもたらす可能性がある(たとえば、サービスの指定するコードが、(監視しない限りサービス側にはわからない)ユーザからアクセスマネージャに提供されるサインオン情報を監視するなどして、ユーザに関する情報を不適切に取得することを可能にするリスクをもたらす可能性がある)。サービスが利用できるようにするカスタマイズのタイプの決定方法の詳細については、後述する。
【0011】
さらに、実施形態によっては、悪意のあるパーティが実際の許可されたパーティになりすまそうとするフィッシング詐欺の企てを阻止するなど、悪意のあるパーティが不正なアクティビティを行うのを阻止するために、様々な手法が用いられる。たとえば、悪意のあるユーザが、アクセスマネージャと対話することを許可されたサービスになりすまして、アクセスマネージャと対話しようとするのを阻止するために、追加のセキュリティ手法を用いて、少なくとも一部のサービスから送られる一部またはすべてのメッセージを認証することが可能である。具体的には、実施形態によっては、アクセスマネージャと対話することを許可された各サービスが、サービスおよびアクセスマネージャには知られている、少なくとも1つの一意の秘密アクセス鍵を与えられ、その後、サービスが、メッセージまたは他の連絡をアクセスマネージャに送る際に、そのサービスの秘密アクセス鍵を使用し、これによって、アクセスマネージャは、メッセージの送信者が実際にそのサービスであることを検証することが可能である。たとえば、サービスからのそのような各メッセージが、そのサービスの一意識別子の通知を含むことが可能であり、また、メッセージ内容の少なくとも一部に基づき、秘密アクセス鍵を用いて生成されたデジタル署名を含むことも可能である。アクセスマネージャは、そのようなメッセージを受け取ると、サービス識別子を用いて、そのサービスを識別し、そのサービスに対応する秘密アクセス鍵を取り出すことが可能であり、その後、取り出した秘密アクセス鍵と、メッセージ内容の同じ部分とを用いて、同じ方法で、デジタル署名を独自に生成することが可能である。アクセスマネージャによって生成されたデジタル署名が、送信者によってメッセージに含められたデジタル署名と一致すれば、アクセスマネージャは、送信者が一意識別子およびそのサービスの秘密アクセス鍵の両方にアクセスできることを確認することが可能であり、したがって、送信者が実際にそのサービスであることが非常に確からしいことを検証することが可能である。秘密アクセス鍵は、様々な実施形態において様々な形式をとることが可能であり、たとえば、共有秘密鍵、PKI(「公開鍵インフラストラクチャ」)鍵ペア、X.509証明書、ハードトークンを使用して生成された秘密鍵などの形式をとることが可能である。少なくとも一部の実施形態では、さらに他のセキュリティ手法を用いることが可能であり、秘密アクセス鍵の使用に関する詳細については、後述する。
【0012】
以下、例示を目的として、いくつかの実施形態を説明する。それらの実施形態においては、特定タイプのサービスが、アクセスマネージャシステムによって、そのサービスの特定タイプのユーザに特定の形式で提供された特定タイプの機能性の特定タイプのカスタマイズを構成する。しかしながら、説明される手法が、他の多様な状況で使用されることが可能であること、ならびに本発明が、与えられる例示的詳細に限定されないことを理解されたい。
【0013】
図1Aは、アクセスマネージャシステム、サービス、およびユーザの間で行われる様々なタイプの対話の例を示す。具体的には、図1Aは、アクセスマネージャシステム114と、アクセスマネージャのカスタマであるサービス110と、カスタマサービスのユーザ112と、カスタマサービスと提携している他のセカンダリサービス118(オプション)と、アカウントマネージャシステム116との間で行われる対話を示している。この例では、アカウントマネージャ116およびアクセスマネージャ114は、両方とも、単一エンティティによって与えられたシステム115のグループの一部として与えられており(たとえば、アカウントマネージャは、許可されたパーティからの要求があった場合に、アクセスマネージャとともに、アカウントを有するユーザの代理として様々なアクションを実行する)、実施形態によっては、提携サービス118の少なくともいくつかがシステム115に含まれることも可能である。図示されたシステム、サービス、およびユーザの間では、様々なメッセージが発生する。そのようなメッセージとして、ユーザのアカウントを確立することの一部である、ユーザとアクセスマネージャシステムとの間のメッセージ(たとえば、サインオン情報を含む)、カスタマサービスのためのカスタマイズされた機能性を構成する、カスタマサービスとアクセスマネージャとの間のメッセージ、ユーザとカスタマサービスとの間のメッセージ(ユーザが、カスタマサービスに合わせてカスタマイズされたサインオンプロセスに参加するために、アクセスマネージャとの対話にリダイレクトされる初期対話を含む)、カスタマサービスとアカウントマネージャシステムとの間のメッセージ(たとえば、カスタマサービスにサインオンしたユーザの代理としてアクティビティを実行するためのメッセージ)、カスタマサービスと提携セカンダリサービスとの間のメッセージ(たとえば、カスタマサービスにサインオンしたユーザの代理としてアクティビティを実行するためのメッセージ)、提携サービスとアクセスマネージャとアカウントマネージャシステムとの間のメッセージ(たとえば、カスタマサービスにサインオンしたユーザの代理としてのメッセージ)などがある。さらに、サービスに関与するメッセージ(たとえば、カスタマサービス110および/または提携サービス118と、アクセスマネージャ114、アカウントマネージャ116、および他のカスタマサービスまたは提携サービスとの間のメッセージ)の少なくともいくつかは、サービスの秘密アクセス鍵に基づくデジタル署名(図示せず)を使用することが可能である。
【0014】
図1Bは、アクセスマネージャシステム、サービス、およびユーザの間の様々なタイプの対話の1つの具体例を示し、特に、カスタマサービスが、Webサイトではなくアプリケーション開発者のアプリケーションによって与えられている実施形態を示している。具体的には、アプリケーション開発者120(この例では「ボブ」という名前である)が最初に、開発者のアプリケーション122によって与えられるサービスに関して、アクセスマネージャシステム150に登録180する。この登録は、たとえば、この例では(たとえば、カスタマ登録マネージャコンポーネントで与えられることが可能な)カスタマ登録プロセス158と対話することによって行われる。この例では、アプリケーション122は、アプリケーションのエンドユーザにサービスおよび/または他の機能性を提供する(たとえば、汎用パーソナルコンピュータで実行されるための)アプリケーションプログラムであるが、他の実施形態では、そのようなアプリケーションは、他の様々な形式をとることが可能であり、そのような形式としては、Webアプリケーション、ダウンロード可能なアプレットまたは他の実行可能コード、クライアントおよび/またはサーバアプリケーション、モバイルアプリケーション(たとえば、携帯電話または他の形態のモバイルコンピューティング装置で実行されるアプリケーション)などがある。ステップ180の一環として、開発者は、様々な情報を供給することが可能であり、それには、連絡先情報およびアプリケーション122に関する情報(およびオプションでアプリケーションのコピー)が含まれる。登録対話180の一環として、開発者は、後でアプリケーションのエンドユーザが使用する様々なカスタマイズを構成することが可能であり、それらは、アクセスマネージャシステムによって開発者に付与されているパーミッションのレベルに応じたコブランディング、情報収集、権限委譲などである。代替として、一部のカスタマイズが使用されない場合がある。たとえば、アプリケーションがエンドユーザと直接対話してサインオン情報を取得し、取得されたサインオン情報がプログラムによって、検証のためにアクセスマネージャシステムに送られる場合には、コブランディングが構成されない。さらに、アプリケーションのエンドユーザが、アプリケーション122によって与えられたグラフィカルユーザインターフェースと対話する、図示されたような実施形態では、アプリケーションは、少なくともいくつかの情報を特定の形式のグラフィカルユーザインターフェースからエンドユーザに提供することを、契約により、または他の形式で義務づけられることが可能である。そのような情報は、たとえば、アクセスマネージャのブランドとコブランディングされる形式でエンドユーザに提示されているアクセスマネージャシステムにサインオンすることに関連付けられることが可能である。代替として、アプリケーションは、他のタイプの、アクセスマネージャに固有の情報または機能性を提供すること、および/またはエンドユーザのサインオン情報を保護するために、様々な指定のセキュリティ対策を採用することを義務づけられることも可能である。開発者は、登録後に、アクセスマネージャ158から様々な情報181を受け取ることが可能であり、たとえば、使用される秘密鍵の通知(または対話180の一環として開発者から指定された秘密鍵の確認)およびアプリケーションの非秘密の一意識別子(たとえば、秘密アクセス鍵に関連付けられた識別子)を受け取ることが可能である。開発者が様々なエンドユーザ130にアプリケーションを配布182した後、エンドユーザが、そのアプリケーションを使用して様々なタイプの機能性を取得することが可能である。
【0015】
次に、ユーザ例130が、アプリケーションと対話183し、たとえば、リモートサードパーティWebサービスプロバイダ140(たとえば、ユーザが既成のアカウントを有するWebサービスプロバイダ)から提供される1つまたは複数のWebサービスを利用するためにユーザがサインオンを行う動作を要求する。Webサービスは、異種のアプリケーションおよびコンピュータ同士が対話することを可能にすることが可能であり、様々な下位プロトコルおよび手法を用いて定義および実装されることが可能である。たとえば、一部のWebサービス実装は、URI(たとえば、指定された動作および1つまたは複数のクエリパラメータを含むURL)として指定されるWebサービス呼び出し要求への応答として、HTTP (「HyperText Transport Protocol」)を用いてXML(「eXtensible Markup Language」)フォーマットのデータを返す。他の実装では、さらなる下位プロトコルが様々な目的で使用され、たとえば、標準メッセージ交換のためにSOAP(「Simple Object Access Protocol」)が使用され、サービス呼び出しの記述のためにWSDL(「Web Services Description Language」)が使用され、利用可能サービスの発見のためにUDDI(「Universal Description,Discovery,and Integration service」)が使用される。状況によっては、アプリケーション122およびWebサービスプロバイダ140は、あらかじめ定義された関係を有することが可能である。他の実施形態では、アプリケーションは、そのようなあらかじめ定義された関係を有することなく、単に、アプリケーションのエンドユーザの代理として、提供されたWebサービスの定義済みAPIと対話することが可能であり、これは、たとえば、Webサービスプロバイダがアクセスマネージャシステムのカスタマでもあり、ユーザを表すために、アクセスマネージャシステムの信用証明書を受け取って使用するように構成されている場合である。
【0016】
ユーザが、サインオンをトリガする動作を要求すると、(たとえば、要求者がアプリケーションであることの検証のために、アプリケーションの秘密鍵を使用して生成されたデジタル署名を有する)サインオン要求メッセージが、アプリケーションによって生成され、ユーザ対話マネージャプロセス152へ送られる184。このメッセージが検証された場合、アクセスマネージャは、オプションで、ユーザからサインオン情報を収集する際にアプリケーションによって使用されるサインオン情報(たとえば、情報を収集するためにユーザに対して行う質問、または、アプリケーションが1つまたは複数のページまたはスクリーンをユーザに対して表示するように設計されている場合は、それらのページまたはスクリーン)を返す185ことが可能であり、アプリケーションは、(この例では、アクセスマネージャシステムにあるユーザの既成アカウントを反映する)様々なサインオン情報を収集するために、ユーザとのサインオンプロセスを実行することが可能である。収集された情報は、次に、アクセスマネージャユーザ対話マネージャ152へ送られる186。他の実施形態では、アプリケーションは、(たとえば、アプリケーションに付与されているパーミッションのレベルに応じて)アクセスマネージャシステムとの初期対話を行うことなく、ユーザからサインオン情報を収集し、その、ユーザのサインオン情報を、初期要求184とともに送ることが可能であるが、そのような状況では、エンドユーザのサインオン情報がアプリケーションにさらされる可能性がある。アクセスマネージャユーザ対話マネージャ152は、サインオン情報を受け取ると、このサインオン情報をアカウントマネージャシステム160へ送り187、アカウントマネージャシステム160は、ユーザアカウントデータベース(「DB」)162内の情報を使用してそのサインオン情報を検証する。次に、ユーザ認証の通知(たとえば、ユーザIDまたはエラーメッセージ)がアクセスマネージャユーザ対話マネージャに返される188。サインオン情報が有効だった場合は、信用証明書マネージャ156へ要求が(たとえば、ユーザIDとともに)送られ189、信用証明書マネージャは、アプリケーションによって使用されるための、そのユーザを表す信用証明書を生成し、この信用証明書をアクセスマネージャユーザ対話マネージャへ返す190。アクセスマネージャユーザ対話マネージャは、信用証明書を受け取ると、その信用証明書をアプリケーションに送り返す191。
【0017】
次に、アプリケーションは、Webサービス要求を生成し、これをWebサービスプロバイダ140へ送る192。この要求には、オプションで、アプリケーションの秘密アクセス鍵を使用して生成されたデジタル署名が含まれる。Webサービスプロバイダ140は、要求を受け取ると、オプションで、デジタル署名が添付されている場合にはデジタル署名を使用して、(要求をアクセスマネージャに送って検証を要求すること(図示せず)などにより)要求者の身元を検証する。さらに、Webサービスプロバイダは、ユーザの信用証明書を検証する。これは、この例では、Webサービスプロバイダが信用証明書を信用証明書マネージャに送り193、信用証明書マネージャが(たとえば、信用証明書の正当性を立証する)適切な応答を生成し、これをWebサービスプロバイダに送る194ことによって行われる。信用証明書の正当性が立証されると、Webサービスプロバイダは、要求されたWebサービスをユーザに提供し、応答をアプリケーションへ送る195。次に、アプリケーションは、その応答に基づいて、対応する情報および/または機能性をユーザに提供することが可能である。実施形態によっては、アプリケーションはさらに、さらなる様々なタイプのWebサービス要求および他の要求を行うことが可能であり、たとえば、アカウントマネージャシステムと直接対話して、ユーザアカウントを変更したり、ユーザアカウントデータベース162からデータを取り出したりする要求を行うことが可能である。すべての要求が行われた後、ユーザは、アプリケーションを介してサインアウトするか、単に、信用証明書の限られた有効期限が切れるのを許容することが可能である。
【0018】
図1Cは、単一のサインオンWebサービス101と、カスタマWebサイト例103と、このカスタマWebサイトと対話しているエンドユーザ(図示せず)によって使用されるWebブラウザ105との間の様々なタイプの対話の一例を示す。この例では、図示された対話の第1のステップとして、エンドユーザは、指示された機能性を取得するために、ブラウザ105を使用して、HTTPベースの要求121をカスタマWebサイト103へ送る。Webサイトは、要求された機能性はサインオンしたユーザだけが利用できることを決定し、したがって、サインオンプロセスを実行するために、サインオン要求123をエンドユーザへ送る。この図示された実施形態では、サインオン要求に(たとえば、X.509証明書を使用して)デジタル署名が添付されており、これを生成する方法については、別の場所で詳述する。この例では、サインオンプロセスは、シングルサインオンサービスによって多数のカスタマWebサイトに提供され、サインオン要求123がブラウザ105に送られると、ブラウザ105は、要求123の指示により、(たとえば、HTTP 301ステータスコードを介するなどしてリダイレクトURLを送ることにより)デジタル署名を含む要求125をシングルサインオンサービスに転送する。次に、シングルサインオンサービス101は、要求125のデジタル署名の検証を試行し(詳細については、別の場所で詳述する)、検証が成功すれば、次に、サインオンページをブラウザ105に返す127。次に、エンドユーザは、ブラウザ105にサインオンページが表示された際に、自分のサインオン情報(たとえば、ユーザ名およびパスワード)をサインオンページに入力する。サインオンページは、対応するユーザアカウントを作成するために、ユーザとシングルサインオンサービスとの間で行われた登録の際に提供された情報に基づいて(または、対話型登録プロセス(図示せず)の後に)生成されることが可能である。次に、サインオン情報は、(たとえば、エンドユーザが「完了」コントロールまたは他の同様のコントロールを選択した際に)シングルサインオンサービスに返される129。この例では、エンドユーザは、シングルサインオンサービスプロバイダを信頼して、自分のサインオン情報を進んでシングルサインオンサービスに送っている。これは特に、この例では、サインオン情報がカスタマWebサイト103と共有されないためである。シングルサインオンサービス101は、サインオン情報を受け取った後、受け取ったサインオン情報が有効かどうかを判定し、有効であれば、そのエンドユーザのサインオンを実行し、そのユーザをサインオンしたエンドユーザとして表す信用証明書を生成する。生成された信用証明書は、ブラウザ105に送られ131、そこから(カスタマWebサイト用クッキーまたはリダイレクトURLを介するなどして)カスタマWebサイト103へ転送される133。カスタマWebサイト103は、エンドユーザのサインオンの成功を示す信用証明書を受け取ると、最初に要求された機能性(図示せず)をエンドユーザに提供する。また、ここでは図示されていないが、カスタマWebサイトは、信用証明書を使用して、様々な後続のアクションをエンドユーザの代理として実行することも可能である。たとえば、信用証明書が、ユーザのアカウントに関連する要求とともに(たとえば、ユーザアカウントに保存されている金銭情報に基づいて支払いを行うために)、シングルサインオンサービスに返されることが可能である。そのような、信用証明書に基づく利用は、カスタマWebサイト103とシングルサインオンサービス101との間で直接行われる対話に基づくことが可能であり、あるいは、1つまたは複数の提携中間サービス(図示せず)および/またはエンドユーザとの対話を介することも可能である。さらに、様々なメッセージの少なくともいくつかが、セキュリティ上の理由から、HTTP/Sにより有利に転送されることも可能である。
【0019】
図2A〜2Eは、カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャとWebサイトまたは他の、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す。具体的には、図2Aは、アクセスマネージャのカスタマになる見込みのあるサービスの担当者に対して表示されることが可能な第1の情報群を示しており、これは、たとえば、サービスのユーザの代理として、カスタマイズされた機能性を取得するために、アクセスマネージャに登録しようとしているサービスの運営者に対して表示されるWebページによって示される。この例では、初期登録情報は、指示情報201およびセクション202を含んでおり、セクション202では、アクセスマネージャカスタマが様々なタイプの情報を指定することが可能であり、たとえば、名前およびインターネットアドレス202a(たとえば、サービスを提供するWebサイトのURL)、管理用連絡先情報202b、サービスの少々の概要情報202cなどを指定することが可能である。サービスおよびサービス運営者に関する他の様々なタイプの情報が、他の実施形態において様々な方法で取得されることが可能であり、たとえば、カスタマが利用できるようにするカスタマイズのタイプを制限するなど、アクセスマネージャがアクセスマネージャカスタマに付与する信頼度およびこれに対応するパーミッションを決定するための要素として使用されることが可能である。入力された情報は、この例では、ユーザ選択可能な「登録」コントロール203をクリックすることにより、アクセスマネージャに送られる。また、ユーザ選択可能な「リセット」コントロール204を使用すると、フォームに入力した情報をリセットすることが可能である。「登録」コントロール203が選択されると、この例では、見込みのあるカスタマに対して、アクセスマネージャへの登録を続行するための、図2Bに示されるような、後続の情報群(たとえば、次のWebページ)が表示される。他の実施形態では、すべての情報要求およびカスタマイズ制御が、別の形式で(たとえば、まとめて表示される単一情報群の一部として)表示されることが可能である。
【0020】
図2Bは、コブランディングのカスタマイズの1つまたは複数のタイプを指定するための、カスタマになる見込みのあるサービスの担当者に対して表示されることが可能な第2の情報群の例を示している。この例では、コブランディングのカスタマイズの利用可能なタイプは、比較的最小限であり、これは、たとえば、カスタマに付与されたパーミッションが比較的低レベルであることを反映するためである(たとえば、高い信頼度が検証可能でない限り、どのカスタマにも適用される初期デフォルトとして、または図2Aに対して入力された情報および/またはサービスまたはサービス運営者に関して利用可能な他の情報に基づいて(たとえば、サービスまたは運営者との、過去の対話エクスペリエンスに基づいて))。この例では、カスタマは、複数のブランドを指定すること、および情報をブランドごとに異なるようにカスタマイズすることを許可される。他の実施形態では、そのようなブランドを使用しないことや、サービスとブランドとの各組合せを別個のカスタマとして扱うことが可能である。同様に、ここでは図示されていないが、他の実施形態では、カスタマは、指定および使用される異なるコブランディングまたは他のカスタマイズに関する他のタイプの区別を指定することが可能であってよい(たとえば、ユーザが関連付けられることが可能な複数の地理的ロケールまたは他のユーザグループ)。複数のブランド、ロケール、または他の異なるグルーピングを指定する場合、そのようなグルーピングのそれぞれは、実施形態によっては、別々の識別子と、オプションで、別々の秘密アクセス鍵とを与えられることが可能であり、これは、たとえば、使用される個々のグルーピングへの参照を可能にするためである。この例では、表示される情報は、構成されるブランドを示すセクション206(異なる複数のブランドが使用されない場合、または、カスタマイズがすべてのブランドに適用される場合には、空白のままにされる)と、指示情報205と、カスタマが1つまたは複数のカスタマイズを指定するための様々な質問および情報選択/指定の領域を有する領域207と、を含んでいる。たとえば、カスタマは、ユーザに対して表示される、サービスの1つまたは複数のロゴイメージを(たとえば、対応するファイルをアップロードすること、またはイメージを取り出すことが可能なネットワークアドレスを指定することにより)指定することが可能であり、この例では、指定されたロゴイメージのプレビュー208が、使用されるロゴロケーション、ユーザに対して表示されるテキスト、およびユーザに対して表示されるリンクとともに表示される。他の実施形態では、他の様々なタイプのコブランディングカスタマイズを利用可能にすることが可能であることが理解されよう。さらに、この例では、カスタマは、ユーザ選択可能な「プレビュー」コントロール209とユーザ選択可能な「保存」コントロール210とを与えられ、「プレビュー」コントロール209を使用すると、指定されたコブランディングカスタマイズの結果である1つまたは複数のサインオンページまたはスクリーンをプレビューすることが可能であり、「保存」コントロール210を使用すると、指定されたコブランディングカスタマイズを保存することが可能である。この例では、カスタマは、単一グループのコブランディングカスタマイズのみを実行するように図示されているが、他の実施形態では、コブランディングカスタマイズの異なる複数のセットを指定することが可能である。たとえば、アクセスマネージャによって、ユーザに対して表示される複数のページまたは他の情報群(たとえば、サインオンプロセスに使用される複数のページ、および/または他の関連するタイプのアクティビティ(たとえば、サインオフまたはサインアウトプロセス、ユーザからの情報収集、エラーの提示、信用証明書のリフレッシュ、プライマリサービスに対して発行された信用証明書に基づく、セカンダリサービス用の新しい信用証明書の生成(信用証明書の「クローニング」と呼ばれる)など)に使用されるページ)を反映するために、単一ブランドに対して、コブランディングカスタマイズの異なる複数のセットを提供することが可能である。
【0021】
図2Cは、図2Bの場合と同様に、コブランディングカスタマイズの1つまたは複数のタイプを指定するための、カスタマになる見込みのあるサービスの担当者に対して表示されることが可能な第2の情報群の別の例を示している。この例では、カスタマに付与された比較的高レベルのパーミッションを反映するために、(たとえば、図2Aのように提供された情報および/またはサービスまたはサービス運営者に関して利用可能な他の情報に基づいて)さらなるタイプのコブランディングカスタマイズがカスタマに対して利用可能になっている。他の実施形態では、他の理由で、さらなるタイプのコブランディングカスタマイズを利用可能にすることが可能である(たとえば、プレミアムカスタマに対し、追加料金と引き替えで)。この例では、表示される情報は、図2Bの情報205〜208からなる通知211を含み、さらに、追加のコブランディングカスタマイズ212を含む。この例における追加タイプのコブランディングカスタマイズは、ユーザに対して表示される情報の外観を追加指定する機能と、ページの見出しに含まれるユーザ選択可能コントロールおよび/または他の情報、またはユーザに対して表示される他の情報を指定する機能と、ページの一部として含まれる他の実行可能コード、またはユーザに対して表示または提供される他の情報と、を含んでいる。これらの追加のコブランディングカスタマイズのタイプは、単に例示的であって、代替実施形態では、他の追加タイプのカスタマイズを利用可能にすることも可能である。
【0022】
この例では、カスタマサービスの運営者または他の担当者が、様々なカスタマイズを、対応するプロンプトに応じて個々に指定するが、他の実施形態では、別の手法でコブランディングカスタマイズを指定することも可能である。たとえば、実施形態によっては、ユーザに対して表示または他の方法で提示されるカスタマイズされたサインオンページまたは他の情報の外観をカスタマがグラフィカルに指定するWYSWYG(「What You See is What You Get(見たものが、手に入るもの)」)システムを用いることが可能であり、あるいは、適切なフォーマット(たとえば、XMLまたは(X)HTML(「(eXtensible)HyperText Markup Language(拡張可能ハイパーテキストマークアップ言語)」)フラグメント)を使用して、コブランディングカスタマイズをファイルのかたちで指定して、アクセスマネージャに送ることも可能である。
【0023】
図2Dは、サービスのユーザとの対話時に実行される情報収集の1つまたは複数のタイプを指定するために、カスタマサービス担当者に対して表示されることが可能な、第3の情報群の例を示す。実施形態によっては、一部またはすべてのタイプの情報収集が、十分に高いレベルのパーミッションを有するカスタマだけが利用できるようにされることが可能であり、かつ/または、他の条件に基づいて(たとえば、プレミアムカスタマだけが)利用できるようにすることが可能である。この例では、(たとえば、それぞれが、ユーザに対して表示される、対応する質問(図示せず)を有する)様々な定義済みタイプの収集対象情報に対して、定義済み情報タイプの1つまたは複数を選択するためのチェックボックス213が利用可能になっている。ここでは図示されていないが、少なくとも一部の実施形態では、ユーザに対して行われるカスタマ指定質問の1つまたは複数のセットをカスタマサービスが構成することがさらに可能であり、たとえば、行われる質問を入力すること、およびオプションで、質問に対する可能な答えを列挙または他の方法で表示することを構成することが可能である。さらに、この例では、カスタマは、アクセスマネージャが追跡するユーザアクティビティの1つまたは複数のタイプ215をさらに指定することが可能であり、そのようなタイプとして、たとえば、サインオン試行(成功および/または失敗)、サインオフ試行、表示または他の方法で提示された契約条件(たとえば、登録プロセス(図示せず)においてカスタマによって指定され、「同意」コントロールを選択すること、または他のユーザ同意の提示によってユーザに受け入れられる契約条件)に対する同意を与えることなどがある。この例では、カスタマはさらに、(ユーザ選択可能タイミング制御214で示されるように)定義済みおよび/またはカスタマ指定のタイプの情報をユーザに尋ねるタイミングを指定することが可能であるが、他の実施形態では、タイミングを固定することも可能である(たとえば、サービスに対するユーザの最初のサインオン(または他のアクティビティ)の間に1回のみ、またはサインオンごとに、など)。この例では、フォーマッティング情報216がカスタマによって指定されることも可能であり、これは、たとえば、定義済みタイプの収集対象情報の少なくともいくつかについて可能なタイプの答えを示すためである。実施形態によっては、情報収集の構成時に他のタイプの情報も与えられることが可能であり、たとえば、与えられるユーザの答えが許容可能かどうかを動的に判定する際に使用される論理や、いくつかの質問(たとえば、ユーザに配偶者または子供がいるかどうかを示すユーザからの答えに基づく、ユーザの配偶者または子供に関する詳細についての質問)が特定のユーザに対して行われるべきかどうかを判定する際に使用される論理などが与えられることが可能である。
【0024】
図2Eは、他の提携セカンダリサービスに対する1つまたは複数のタイプの権限委譲(たとえば、プライマリカスタマサービスのユーザの代理として特定タイプのアクションを実行する権限の委譲)を指定するために、カスタマサービス担当者に対して表示されることが可能な、第4の情報群を示しているが、実施形態によっては、そのようなカスタマイズは、十分に高レベルのパーミッションを有するカスタマにのみ与えられることが可能である(そして、権限委譲の個々のタイプは、パーミッションレベルおよび/または他の要因に応じて変わってよい)。この例では、図2Eは、指示情報217と、権限の委譲を受けるサービスをカスタマが指定することが可能なセクション219、221、および223とを含んでいる。ここでは図示されていないが、実施形態によっては、カスタマはさらに、権限委譲のデフォルトセットを修正することなどにより、提携セカンダリサービスのそれぞれに対する、特定タイプの権限の委譲を指定することが可能である。カスタマはさらに、提携サービスがアクセスする情報に対する制御(たとえば、利用可能なユーザ情報の指定されたサブセット)を指定することが可能である。この例では、セクション219は、アクセスマネージャと提携している他の様々なサービス((たとえば、ユーザのアカウントに対して、かつ/または、ユーザのアカウントから行われる支払いを有効にする)支払サービスや、(たとえば、ユーザに関して既に指定された嗜好に従うなどして、ユーザの代理として、推薦を取得および/または付与する)推薦サービスなど)を(たとえば、同じエンティティによって与えられることを前提として)利用可能にする。さらに、セクション221は、他の様々な一般サービス(この例では、人気または信頼性の格付けのような、そのサービスに関する情報を含む)を利用可能にし、セクション223は、カスタマが他のサービスを指定することを可能にする。
【0025】
実施形態によっては、プライマリカスタマサービスと提携しているセカンダリサービス自体が、ユーザの代理としてアクセスマネージャと対話するために、アクセスマネージャに登録されることが必要な場合があり、したがって、一般サービスは、アクセスマネージャに既に登録されているサービスに基づくことが可能である。代替として、指定されたサービスがまだアクセスマネージャに登録されていない場合、アクセスマネージャは、その指定されたサービスに自動的に照会して、登録機能を提供することが可能である。カスタマサービスがユーザと対話しているときには、別のサービスへの権限の委譲は、ユーザによって開始される場合(たとえば、セカンダリサービスを介して提供される機能に対応する、プライマリカスタマサービスによって表示されるリンクまたはコントロール(たとえば、支払サービスに委譲される、ユーザのアカウントから支払いを行うリンク)をユーザが選択することに基づいて)、および/または、プライマリカスタマサービスによって自動的に実行される場合など、様々なかたちで行われることが可能である。さらに、実施形態によっては、セカンダリサービスとの対話は、ユーザにとって透過的なかたちで実行されることが可能である。たとえば、支払関連機能が要求された場合は、セカンダリ提携支払サービスがページまたは他の情報群を生成してユーザに送ることが可能である。これは、たとえば、対応する情報をユーザから取得するためである(たとえば、1つまたは複数の他のパーティの表示、少なくともいくつかのタイプのアクションに関するユーザのサインオンまたは他の情報の検証など)。さらに、一貫性のあるエクスペリエンスをユーザに提供するために、セカンダリ提携サービスは、少なくとも一部の実施形態では、プライマリカスタマサービスに対して既に指定されたコブランディング情報を、ユーザに対して表示される情報の中で使用することが可能である。そのような既に指定されたコブランディングへのアクセス権を取得するために、セカンダリ提携サービスは、そのコブランディング情報を使用する権限がセカンダリ提携サービスに委譲されている場合には、アクセスマネージャと対話して、コブランディング情報を取得することが可能である。たとえば、プライマリカスタマサービスは、プライマリカスタマサービスのための指定のタイプのコブランディング情報(たとえば、プライマリカスタマサービス用の1つまたは複数のロゴまたは他のイメージ)をセカンダリ提携サービスが指定の形式で使用できるように、セカンダリ提携サービスに権限を委譲することが可能であり、そうであれば、セカンダリサービスは、適切な要求(たとえば、セカンダリサービス、プライマリカスタマサービス、必要な情報のタイプ、およびオプションで、プライマリカスタマサービスの固有のコブランディング情報を指示する要求)をアクセスマネージャに送ることにより、そのようなコブランディング情報の使用権を得ることが可能である。アクセスマネージャは、セカンダリサービスがそのコブランディング情報の使用を許可されたことを確認すると、そのコブランディング情報(または、セカンダリサービスがそのコブランディング情報を取得するために使用できる情報)を返す。
【0026】
図3A〜3Bは、カスタマサービスの代理としてのアクセスマネージャからユーザに提供される、カスタマイズされたサインオンプロセスの例を示す。具体的には、図3Aは、サービスのユーザに対して表示される、カスタマサービスに合わせてカスタマイズされた最初のサインオンページを示している。この例では、サインオンページは、比較的低レベルのパーミッションを有するカスタマ(または、高レベルのパーミッションに関連付けられたカスタマイズを含めることを選択していないカスタマ)向けに、アクセスマネージャ機能性のプロバイダによって生成されることが可能である。この例では、カスタマロゴ301およびカスタマイメージ303が、コブランディングカスタマイズに従って表示され、アクセスマネージャまたはアクセスマネージャを提供するエンティティのロゴ305も表示されている。他の実施形態では、ロゴ305は使用されなくてよい。指示情報307は、(たとえば、ユーザの、アカウントマネージャプロバイダのアカウントに基づいて)アカウントマネージャプロバイダに関するサインオン情報を使用してサインオンプロセスを開始するように、ユーザに通知する。そのサインオン情報は、ユーザによって、しかるべき場所309に入力されることが可能である。さらに、カスタマの使用条件およびカスタマのプライバシポリシーへのアクセスを提供する、カスタマイズされたリンク313が表示されている。さらに、サインオン情報を送るための様々なユーザ選択可能コントロール311も提示されている。
【0027】
図3Bは、このサービスの少なくとも一部のユーザ(たとえば、このカスタマサービスへのサインオンが初めてであるユーザや、指定の条件を満たす後続のサインオン試行を行うユーザ)に対して表示される、カスタマサービスに合わせてカスタマイズされたサインオンプロセスの後続のページを示している。具体的には、この例では、このページは、カスタマによって指定された質問325を行うことによって、カスタマイズされたタイプの情報収集を実行するために提供される。そのような質問としては、出荷先アドレス、電話番号、および他の、ユーザの連絡先情報があり、これらに限定されない。カスタマロゴ321は、情報収集ページの一部として表示可能な、様々なタイプのコブランディングの一例を示している。これは、図3Aのロゴ301であっても、カスタマ固有のロゴであってもよい。さらに、指示情報323をユーザに対して表示して、デフォルトの質問であれ、カスタマサービスによって指定された質問であれ、質問に答えるよう、ユーザに通知することが可能である。質問によっては、(たとえば、電話番号327のように)カスタマによって指定された、カスタマイズされたデータ形式を示すことも可能である。実施形態によっては、クライアントサイドスクリプティング(たとえば、Java(登録商標)Script)を使用して、許容できる値について任意の指定された制限を設けることが可能であり、また、質問のいくつかがユーザに対して行われるべきかどうかを決定する、指定された論理を実装することも可能である。ユーザがカスタマにサインオンするたびに、他の一度きりの情報収集が実行されない場合でも、追加の質問329をユーザに対して行うことが可能である。ユーザは、質問に答え終わったら、ユーザ選択可能コントロールを使用して、その情報を送信することが可能である331。
【0028】
サインオンおよび情報収集は、様々な実施形態において様々な形式で行われることが可能である。たとえば、図3Aおよび3BはWebページを示しているが、実施形態によっては、プログラム的にアクセスされるインターフェースを含め、他のインターフェースを利用することも可能である。さらに、ユーザの情報を収集する際に複数のページを使用することが可能であり(特に、ユーザがカスタマに初めてサインオンする場合)、ユーザインターフェース内で様々なユーザインターフェースウィジェットを使用することが可能である。
【0029】
ここでは図示されていないが、カスタマイズされたサインオンプロセスおよび他のタイプのカスタマイズされたユーザ対話は、他の様々な状況および形式でも使用されることが可能である。たとえば、図3Aおよび3Bでは、カスタマイズ手法は、1つまたは複数のWebページの一部として使用されるものとして示されているが、1つまたは複数の電子メールメッセージ(たとえば、HTML形式で指定された電子メールメッセージ)または他のタイプの、エンドユーザに送られる電子メッセージのような、他の様々なタイプのメッセージおよび情報も、同様にカスタマイズされることが可能である。さらに、カスタマイズ手法は、検索エンジンの出力や、ソーシャルネットワーキングサービスで与えられる情報のような、ユーザに提供される他の様々なタイプの情報をコブランディングするために使用されることも可能である。
【0030】
図4は、アクセスマネージャコンピューティングシステム400、ならびに、様々なユーザコンピューティングシステム450、提携サービスコンピューティングシステム490、およびカスタマサービスコンピューティングシステム470の例示的実施形態を示すブロック図である。図示された実施形態では、アクセスマネージャコンピューティングシステムは、CPU 405、各種I/Oコンポーネント410、ストレージ430、およびメモリ420を含んでおり、I/Oコンポーネントは、ディスプレイ411、ネットワークインターフェース412、コンピュータ可読媒体ドライブ413、および他のI/Oデバイス415を含んでいる。
【0031】
アクセスマネージャシステム423およびアカウントマネージャシステム428の実施形態は、メモリ420内で実行されており、これらは、ネットワーク480を介して(たとえば、インターネットおよび/またはワールドワイドウェブを介して)他のコンピューティングシステムと対話する。ユーザらは、最初に、アカウントを確立して使用するために、(たとえば、各ユーザがユーザコンピュータシステムのメモリ457内で実行されているブラウザ458を使用して)アカウントマネージャシステムと対話することが可能であり、これは、たとえば、ストレージ430上のユーザアカウントデータベース432データ構造に格納されているサインオン情報、連絡先情報、金銭情報などを指定するためであり、実施形態によっては、アカウントマネージャシステムおよび/または1つまたは複数の他の提携システム(図示せず)がさらに、様々なタイプの機能性(オンラインショッピング機能性、メッセージングサービス機能性、情報アクセス機能性など)をユーザに提供することが可能である。アクセスマネージャシステム423の図示された実施形態は、様々な機能性を提供するために複数のマネージャコンポーネントを含んでおり、それらには、カスタマ登録マネージャコンポーネント421、ユーザ対話マネージャコンポーネント422、信用証明書マネージャコンポーネント424、カスタマステータスマネージャコンポーネント425、カスタマ検証マネージャコンポーネント426などが含まれるが、他の実施形態では、これらのマネージャコンポーネントの機能性は、他の形式で編成されてもよい。カスタマ登録マネージャコンポーネントは、サービスの運営者および他の担当者と対話することにより、それらのサービスをアクセスマネージャシステムのカスタマとして登録し、サービスのユーザに提供されるサインオン機能性および他の機能性をカスタマイズし、カスタマによって提供される情報は、ストレージにあるカスタマ情報データベース440データ構造に格納される。カスタマになる見込みのあるサービスがカスタマとして登録されると、1人または複数のユーザが、カスタマサービスコンピューティングシステムによって提供されるサービスおよび他の機能性と対話することが可能であり、カスタマサービスへのサインオンを実行するために、アクセスマネージャシステムにダイレクトされることが可能である。次に、ユーザ対話マネージャコンポーネントは、ユーザと対話して、たとえば、前に保存されたユーザアカウント情報に基づいて、かつ/または、(直接であれ、ユーザをアカウントマネージャシステムと対話することにリダイレクトすることによってであれ)ユーザをアカウントマネージャシステムの新しいユーザとして登録することに基づいて、カスタマサービスのカスタマイズされたサインオンプロセスを提供する。さらに、実施形態によっては、ユーザ対話マネージャコンポーネントは、ユーザに関する様々な情報を、カスタマイズされた形式で収集し、その情報を、収集済みユーザ情報データベース436データ構造に格納する。サインオン試行が成功した場合、信用証明書マネージャコンポーネントは、ユーザを表す信用証明書を生成し、その信用証明書情報を、ストレージにある信用証明書データベース438データ構造に格納し、(たとえば、カスタマサービスへリダイレクトバックされるユーザへの応答として)カスタマサービスのコンピューティングシステムのストレージ471に信用証明書473として格納するため、ならびに、オプションで、ユーザに関して収集されたすべての情報を提供するために、その信用証明書をカスタマサービスに返す。
【0032】
次に、カスタマサービスが、アカウントマネージャシステムおよび/またはアクセスマネージャシステムと対話して、ユーザを表す信用証明書を提供することなどにより、ユーザの代理として様々なアクションを実行すること(たとえば、ユーザのアカウント情報を修正および/または使用すること)が可能である。状況によっては、カスタマサービスがユーザを、提携サービスコンピューティングシステムによって提供されている提携サービスにダイレクトすることが可能であり、この場合は、ユーザに関してカスタマサービスに発行された信用証明書が、提携サービスに与えられ、提携サービスコンピューティングシステムのストレージ491上に信用証明書493とともに格納される。次に、ユーザは、オプションで、ユーザの代理としてアクションを実行するアクセスマネージャシステムおよび/またはアカウントマネージャシステムと対話するために、提携サービスによって同様にリダイレクトされることが可能である。カスタマサービス(またはその担当者)はさらに、カスタマステータスマネージャコンポーネントと対話して、(サービス自身の、アクセスマネージャシステムにおけるカスタマアカウントに関する情報、および収集済みユーザ情報データベースにある収集済みユーザ情報を含む)サービスに関する様々な情報を取得することが可能である。さらに、少なくとも一部の実施形態では、アクセスマネージャシステムおよびアカウントマネージャシステムが、カスタマサービスのユーザのアクションに関する様々なタイプの情報を追跡および提供する、さらなるカスタマイズされた機能性を提供することを、いくつかのカスタマサービスのそれぞれが要求することが可能であり、これは、たとえば、カスタマサービスが自身のサインオンサービスを実装していたとすれば有するであろうユーザ関連情報のほとんどまたはすべてを、カスタマサービスが利用できるようにするためである。その場合、そのようなユーザ情報は、代替ユーザプールデータベース434データ構造に格納され、カスタマステータスマネージャコンポーネントによって、それらのカスタマサービスが利用できるようにされるが、他のユーザ(または、他のサービスと対話している場合の同じユーザ)に関する同様の詳細情報は、図示された実施形態では、それらのカスタマサービスが利用できるようにはされない。
【0033】
少なくとも一部の実施形態では、カスタマサービスとアクセスマネージャシステムおよび/またはアカウントマネージャシステムとの対話に関する様々な追加セキュリティ対策を与えるために、カスタマ検証マネージャコンポーネントが使用される。具体的には、そのような実施形態では、カスタマサービスからの少なくともいくつかのメッセージが、メッセージ内の情報に基づいて、そのサービスおよびカスタマ検証マネージャコンポーネントに知られている秘密アクセス鍵(たとえば、サービスの初期登録時に決定され、サービス情報データベース440に格納されている秘密アクセス鍵)を使用して生成されたデジタル署名を含まなければならず、そのようなデジタル署名は、図示された実施形態では、カスタマサービスのコンピューティングシステム470のメモリ477内で実行されている署名ジェネレータコンポーネント478により、カスタマサービスの秘密アクセス鍵(図示せず)を使用して、カスタマサービスによって生成される。その場合、カスタマ検証マネージャコンポーネントは、他のシステムまたはコンポーネントが、受け取ったメッセージに応答する前に、そのメッセージを認証するために、含まれるデジタル署名を検証する(これは、たとえば、カスタマ検証マネージャコンポーネントに知られている、そのカスタマの秘密アクセス鍵を使用して、一致する別のデジタル署名を生成することにより、デジタル署名を複製することによって行われる)。そのようなメッセージ認証はさらに、少なくとも一部の実施形態および状況においては、少なくとも一部の提携サービスに対して実行されることも可能である。さらに、実施形態によっては、他のタイプのメッセージも、1つまたは複数の関連するサービスの秘密アクセス鍵を使用して同様にデジタル署名されることが可能であり、そのデジタル署名に基づいて認証されることが可能である。たとえば、このようなメッセージとして、受信者サービスによって認証される、アクセスマネージャシステムおよび/またはアカウントマネージャシステムからカスタマサービスまたは提携サービスへのメッセージや、(サービスが他のサービスの秘密アクセス鍵にアクセスできない場合に)カスタマ検証マネージャコンポーネントの支援によって認証される、カスタマサービスと提携サービスとの間のメッセージなどがある。
【0034】
図示されたコンピューティングシステムは、例に過ぎず、本発明の範囲を限定するものではないことを理解されたい。アクセスマネージャコンピューティングシステム400は、インターネットやウェブのような1つまたは複数のネットワークを介することを含め、図示されていない他のデバイスと接続されることが可能である。より一般的には、各種コンピューティングシステムのそれぞれは、説明された形式で対話を行うことが可能なハードウェアおよびソフトウェアの任意の組合せを備えることが可能であり、それらには、コンピュータ、ネットワークデバイス、インターネット電気器具、PDA(「携帯情報端末」)、携帯電話、ページャ、電子手帳、テレビベースのシステム、および他の、相互通信機能を含む様々なコンシューマ製品などが含まれる。さらに、図4に示されたアクセスマネージャシステムコンポーネントによって提供される機能性は、実施形態によっては、より少ないコンポーネントの組合せであったり、別の複数のコンポーネントに分散されたりすることが可能である。同様に、実施形態によっては、図示されたコンポーネントのうちのいくつかの機能性が提供されない場合があり、かつ/または、他の追加の機能性が利用できる場合がある。
【0035】
これも当業者であれば理解されるように、様々なアイテムがメモリ内またはストレージに格納されて使用されているように図示されているが、これらのアイテムまたはその一部は、メモリ管理およびデータ保全のために、メモリと他のストレージデバイスとの間で転送されることが可能である。代替として、他の実施形態では、ソフトウェアコンポーネントの一部またはすべてが、別のデバイスのメモリ内で実行され、相互コンピュータ通信により、図示されたコンピューティングシステムまたはデバイスと通信することが可能である。アクセスマネージャシステムコンポーネントまたはデータ構造の一部またはすべてがさらに、(たとえば、命令または構造化データとして)ハードディスク、メモリ、ネットワーク、または適切なドライバによって読み取られる可搬物のような、コンピュータ可読媒体に格納されることが可能であってよい。また、アクセスマネージャコンポーネントおよびデータ構造は、無線ベースおよび有線/ケーブルベースの媒体を含む、様々なコンピュータ可読伝送媒体上に(たとえば、搬送波の一部として)生成されたデータ信号として、伝送されることが可能である。したがって、本発明は、他のコンピュータシステム構成でも実施されることが可能である。
【0036】
図5は、カスタマ登録マネージャルーチン500の例示的実施形態のフロー図である。このルーチンは、サービスの運営者および他の担当者と対話して、サービスのユーザに提供されるサインオン機能性および他の機能性をカスタマイズするなどのために、たとえば、図4のカスタマ登録マネージャコンポーネント421の実行によって与えられることが可能である。
【0037】
このルーチンはステップ505から始まり、ステップ505では、サービスの運営者または他の担当者から、サービスをカスタマとしてアクセスマネージャに登録する指示を受け取る。ステップ505の後、ルーチンは、ステップ510で、サービス(たとえば、Webサイトによって提供されるサービス、またはWebサイトの一部としてのサービス)に関する情報を受け取る。これは、たとえば、(たとえば、図2Aに示されたような)情報を尋ねるページを表示することによる対話形式で、または、プログラム的にアクセスされるAPIの一部として、受け取られる。ステップ510で情報が受け取られた後、ルーチンは、そのカスタマを受け入れるかどうかを、たとえば、(ステップ510で取得された情報を用いて)そのサービスおよび/または運営者が十分信用できると判断されるかどうかに基づいて、かつ/または他の基準に基づいて、決定する。カスタマが受け入れられない場合、ルーチンは、ステップ520に進み、登録拒否メッセージを送信し、その後、ステップ590に進む。カスタマが受け入れられる場合、ルーチンは、ステップ530で、たとえば、そのサービスおよび/または運営者に関して評価された信頼度に基づいて、かつ、オプションで、(たとえば、サービスのタイプ、サービスのユーザ数、カスタマが使用することを可能にされているコブランディングおよび/または他のカスタマイズのタイプ(たとえば、カスタマが実効可能コードを指定して使用することを許可されているかどうか)、などに基づく)サービスのアクションの結果である、アクセスマネージャの何らかの不利益、過去の、アクセスマネージャとカスタマとの間の何らかのエクスペリエンス、その他の要因に基づいて、カスタマに付与するパーミッションのレベルを決定する。さらに、実施形態によっては、カスタマが、(たとえば、プレミアムサービスの一環として)より高いレベルのパーミッションを受け取り、したがって、追加の機能性を得るために、より多くの料金を課せられることが可能である。割増料金は、機密ユーザ情報を、許可されていないユーザにさらすことや、許可されていないユーザが、ユーザの代理として、金銭取引または他の操作を行うことを許すことなどにより、アクセスマネージャを不利益にさらすことになる、カスタマの能力および/または可能性に、少なくとも部分的に基づくことが可能である。少なくとも一部の実施形態では、カスタマのパーミッションのレベルは、後で見直しおよび変更されることが可能である。ステップ530でパーミッションのレベルが決定された後、ルーチンは、付与されたパーミッションに応じて、カスタマが何らかのブランドを構成することを許可するかどうかを決定し、許可する場合は、カスタマがそのようなブランドを有するかどうかを判定する。有する場合、ルーチンは、ステップ540に進み、ブランドを適宜構成する。
【0038】
有しない場合、またはステップ540の後、ルーチンは、ステップ545に進み、決定されたパーミッションレベルに従って、カスタマが利用できるコブランディングカスタマイズのタイプを(たとえば、それらのブランドのうちの1つ目について、かつ/またはすべてのブランドについて(ブランドがステップ540で構成済みの場合))表示する。実施形態によっては、この表示は、Webページであってよく、図2Bおよび/または2Cのユーザインターフェースと同様のユーザインターフェースを含んでよい。利用可能なコブランディングカスタマイズのタイプを表示した後、オプションで、コブランディングカスタマイズの1つまたは複数の指示を、ステップ550で、ルーチンが受け取り、後で使用するために保存する。実施形態によっては、複数のページまたは他の複数の情報群がコブランディングされることが可能な場合、各ページは、別々に構成されてよい。ステップ555で、決定されたパーミッションレベルに従って、カスタマが利用できる情報収集の定義済みタイプを表示し、オプションで、情報収集のカスタマイズの1つまたは複数の指示を、ステップ560で受け取り、後で使用するために保存する。ステップ565で、決定されたパーミッションレベルに従って、カスタマが利用できる権限委譲の定義済みタイプを表示し、オプションで、権限委譲のカスタマイズの1つまたは複数の指示を受け取り、後で使用するために保存する。ステップ568で、複数のブランドが構成済みであって個別にカスタマイズされる場合、ルーチンは、ステップ545に戻って、次のブランドの構成を開始し、そうでない場合、ルーチンは、ステップ570に進み、必要に応じて追加処理を実行する(たとえば、様々な情報を適切なデータストアに格納したり、一意識別子および秘密アクセス鍵を生成してカスタマに与えたりする)。次に、ルーチンは、ステップ590に進み、続行するかどうかを決定する。続行する場合、ルーチンは、ステップ505に戻り、続行しない場合はステップ599で終了する。
【0039】
図示されたルーチンは、代替実施形態では、別の方法で実行されることが可能である。たとえば、このルーチンは、各ブランドが複数のタイプのカスタマイズに関して構成されることが可能であることを示しているが、実施形態によっては、ブランドは、個別に構成されたコブランディングカスタマイズを有することのみが可能であってよい。他の実施形態では、カスタマイズは、異なる順序で指定されることが可能であり、アクセスマネージャカスタマが特定タイプのカスタマイズを構成するパーミッションを有しない場合は、そのタイプのカスタマイズに関連するステップがスキップされてよい。たとえば、カスタマがユーザから情報を収集するパーミッションを有しない場合、ルーチンは、ステップ550から565をスキップしてよい。ここでは図示されていないが、実施形態によっては、ルーチンは、他の様々なセキュリティ情報および/またはメカニズムを追加で使用することが可能であり、これは、たとえば、カスタマの担当者の識別情報を検証するためである。
【0040】
図6は、ユーザ対話マネージャルーチン600の例示的実施形態のフロー図である。このルーチンは、たとえば、図4のユーザ対話マネージャコンポーネント422の実行によって与えられることが可能であり、たとえば、カスタマサービスによって指定される、カスタマイズされたサインオンプロセスを提供するために、カスタマサービスの代理としてユーザと対話することが可能である。
【0041】
ステップ605で、ルーチンは、カスタマイズサービスの代理として、ユーザに関する(たとえば、ユーザがサービスにサインオンすることの)要求の通知を受け取る。図示された実施形態では、この要求は、カスタマに関連付けられたカスタマ識別子と、カスタマに固有の形式で生成された、この要求に対するデジタル署名とを含む。次に、要求に添付されたデジタル署名は、(図9Bに示されるように)カスタマ検証マネージャルーチンによってチェックされ、ステップ610で、有効ではないと判定された場合には、ルーチンはステップ680に進み、失敗通知を送信して、ステップ690に進む。署名が有効であれば、ルーチンは、ステップ615に進み、要求のタイプを決定する。要求がサインオン以外の何かであれば、要求された操作は、ステップ685で適宜実行される。要求がサインオン要求であれば、受け取られたカスタマ識別子に関連付けられたカスタマに関して既に構成されたカスタマイズを、ステップ620において取り出し、ステップ625で、カスタマイズされたコブランディングがなされたコンテンツを有するサインオンページを生成して、ユーザに送る。次に、ステップ630で、ルーチンは、ユーザがアクセスマネージャにアカウントを有するかどうかを判定し、有しない場合、ルーチンは、ステップ640で、ユーザに関する情報を取得し、ユーザをアクセスマネージャに登録する。ユーザが既にアクセスマネージャプロバイダにアカウントを有する場合は、ステップ635で、ユーザからサインオン情報を受け取り、ステップ645で、サインオン情報が有効かどうか(たとえば、そのユーザについて保存されているサインオン情報と一致するかどうか)を判定する。サインオン情報が有効でない場合、ルーチンは、ステップ680に進み、失敗通知をユーザに送る。
【0042】
サインオン情報が有効な場合、またはステップ640の後、ステップ650で、信用証明書または他の、ユーザのサインオンが有効であることの通知を生成して、サービスに渡す(または、他の実施形態では、ユーザが(たとえば、指定された期間に、または他の指示された条件に従って)1つまたは複数のサービスで使用するために、ユーザに渡す)。次に、ルーチンは、ステップ655で、ユーザに関する追加情報(たとえば、ユーザ名、一意識別子、実名など)を取り出してサービスに渡すかどうかを、以前のカスタマイズおよび現在の状況に基づくなどして決定し、渡す場合は、ステップ660に進み、追加情報を適宜取り出す。実施形態によっては、この追加情報を取得するカスタマサービスの機能は、カスタマに付与されたパーミッションのレベルによって制限されることが可能である。ステップ660の後、または追加情報が取り出されなかった場合、ルーチンは、ステップ665で、ユーザに関して収集すべき情報があるかどうかを、以前のカスタマイズおよび現在の状況に基づくなどして決定し、ある場合は、ステップ670に進み、ユーザに関する情報を適宜収集する。ステップ670の後、または情報が収集されなかった場合は、信用証明書およびオプションで他のデータ(たとえば、取り出された情報および/または収集された情報)を、HTTPリダイレクト機能性を用いてユーザ経由で、カスタマに送る。ステップ675、680、または685の後、ルーチンは、ステップ690で、続行するかどうかを決定する。続行する場合、ルーチンは、ステップ605に戻り、続行しない場合はステップ699で終了する。
【0043】
図7は、信用証明書マネージャルーチン700の例示的実施形態のフロー図である。このルーチンは、たとえば、図4の信用証明書マネージャコンポーネント424の実行によって与えられることが可能であり、たとえば、ユーザを表す信用証明書を生成し、他の信用証明書関連アクティビティを実行することが可能である。
【0044】
ルーチンは、ステップ705から始まり、ステップ705で、信用証明書関連の要求を、要求に応じて、外部サービスや別のアクセスマネージャコンポーネントなどから受け取り、この要求は、要求が実行される際に基づく既存の信用証明書を含む追加パラメータを含むことも可能である。要求を受け取った後、ルーチンは、ステップ710に進み、受け取った要求が、サービスのユーザを表す新しい信用証明書を生成することかどうかを、ユーザ対話マネージャコンポーネントに基づくなどして判定する。そうであれば、ルーチンは、ステップ715で、(たとえば、一意の乱数をユーザにマッピングしたり、ユーザに関する情報を取り出して信用証明書の一部として含めたりすることにより)信用証明書を適宜作成し、ステップ770に進み、その信用証明書を保存し、オプションで要求者に渡す。要求が、信用証明書を生成することではなかった場合、ルーチンは、ステップ720で、要求が既存の信用証明書をリフレッシュしてその有効期間を延長することかどうかを、その信用証明書が最初に発行された対象のサービスに基づくなどして判定する。そうであれば、ルーチンは、ステップ722で、要求者が信用証明書をリフレッシュするパーミッションを有するかどうかを(たとえば、要求者に付与されたパーミッションのレベル、および/または信用証明書で表されるユーザによって(たとえば、サービスへのサインオンの際に)指定された情報に基づいて)判定する。パーミッションが存在する場合は、ルーチンは、ステップ724で、信用証明書をリフレッシュしてから、ステップ770に進む。ユーザの信用証明書をリフレッシュするのに十分なパーミッションがない場合、ルーチンは、ステップ729でエラーメッセージを通知し、ステップ795に進む。
【0045】
ステップ720で、要求が、信用証明書をリフレッシュすることではないと判定された場合、ルーチンは、ステップ730に進み、(たとえば、セカンダリ提携サービスからの、セカンダリ提携サービスが提携しているプライマリカスタマサービスに発行された、ユーザに関する信用証明書の使用権を取得する要求のように)要求が既存の信用証明書をクローニングすることかどうかを判定する。そうであれば、ルーチンは、ステップ732に進み、信用証明書のクローニングが許可されているかどうかを、プライマリサービスからセカンダリサービスに委譲された権限に基づくなどして判定する。さらに、実施形態によっては、ユーザを表す信用証明書のクローニングは、ユーザに対し、情報を提供することと、オプションで、クローニングを承認または他の方法で了解することと、を要求することを必要とする可能性があり、そのような実施形態では、クローニングが許可されているかどうかの判定はさらに、ユーザのアクションに少なくとも部分的に基づくことが可能である。ステップ732で、パーミッションが存在すると判定された場合、ルーチンは、ステップ734で、信用証明書をクローニングして、ステップ770に進み、パーミッションが存在しないと判定された場合、ルーチンは、ステップ739で、エラーが発生したことの通知を送信し、ステップ795に進む。
【0046】
ステップ730で、要求が、信用証明書をクローニングすることではないと判定された場合、ルーチンは、ステップ740に進み、要求が、信用証明書が有効かどうかを検証することかどうかを判定する。そうであれば、ルーチンは、ステップ745で、信用証明書が要求者にとって(かつオプションで、指示されたアクションにとって)現時点で有効かどうかを判定し、信用証明書の有効性の通知を要求者に送る。要求が、信用証明書が有効かどうかを判定することではなかった場合、ルーチンは、ステップ750で、要求が、信用証明書の期限がいつ切れるかを判定することかどうかを判定する。そうであれば、ルーチンは、ステップ755で、期限切れを判定し、それを要求者に通知し、そうでない場合、ルーチンは、ステップ760に進み、他のタイプの要求に適宜応答する。ステップ729、739、745、755、760、または770の後、ルーチンは、ステップ795で、続行するかどうかを決定する。続行する場合、ルーチンは、ステップ705に戻り、続行しない場合はステップ799で終了する。
【0047】
図8は、カスタマステータスマネージャルーチン800の例示的実施形態のフロー図である。このルーチンは、たとえば、図4のカスタマステータスマネージャコンポーネント425の実行によって与えられることが可能であり、たとえば、様々なタイプの情報をカスタマに提供することが可能である。
【0048】
ルーチンは、ステップ805から始まり、ステップ805では、カスタマから要求を受け取る。ステップ810で、ルーチンは、要求が許可されているかどうかを、たとえば、カスタマ検証マネージャコンポーネントと対話することにより、かつ/またはカスタマに付与されたパーミッションのレベルに基づいて、判定する。許可されていない場合、ルーチンはステップ895に進み、許可されている場合は、ステップ815〜860で、様々なタイプの情報を修正することをカスタマが要求したかどうかを判定し、要求した場合は、その修正を適宜実行する。図示された実施形態においてカスタマによって修正されることが可能な情報のタイプとして、コブランディングのカスタマイズ(ステップ815および820)、情報収集のカスタマイズ(ステップ825および830)、権限委譲のカスタマイズ(ステップ835および840)、ブランド(ステップ845および850)、およびカスタマアカウント情報(ステップ855および860)がある。受け取られた要求が、情報を修正することではない場合、ルーチンは、ステップ865で、要求が、ユーザを監視することかどうかを判定する。そうであれば、ルーチンは、ステップ870で、あらかじめ追跡されたユーザ情報を取り出してカスタマに提供し、そうでない場合、ルーチンは、ステップ875に進み、他の要求された機能性を適宜実行する。ステップ820、830、840、850、860、870、および875の後、または、ステップ810で、要求が許可されていないと判定された場合、ルーチンは、ステップ895に進み、続行するかどうかを決定する。続行する場合、ルーチンは、ステップ805に戻り、続行しない場合はステップ899で終了する。
【0049】
図9Aおよび9Bは、受け取ったメッセージを認証するルーチンの例示的実施形態のフロー図であり、図9Bは、検証マネージャルーチン925の例示的実施形態を示しており、図9Aは、対応するクライアントサイド検証ルーチン900を示している。検証マネージャルーチンは、たとえば、図4のカスタマ検証マネージャコンポーネント426の実行によって与えられることが可能であり、たとえば、カスタマサービスおよび他のサービスからの着信メッセージに関する様々な追加セキュリティ対策を与えることが可能である。クライアントサイド検証ルーチンは、たとえば、カスタマサービスのコンピューティングシステムと図4の署名ジェネレータコンポーネント478との組合せによって与えられることが可能であり、たとえば、アクセスマネージャへの送信メッセージに対して追加セキュリティ対策を行うことが可能である。
【0050】
図9Aのクライアントサイドルーチン900は、ステップ905から始まり、ステップ905では、様々な情報を含めるべき送信メッセージを生成する指示をカスタマサービスから受け取り、セキュリティのためにメッセージに添付するカスタマ固有のデジタル署名を生成する際に用いる様々な情報を収集する。実施形態によっては、署名の生成に使用される情報は、メッセージ内容の少なくとも一部と、秘密アクセス鍵のような、メッセージに含まれない他の情報とを含む。さらに、実施形態によっては、署名の生成に使用する情報に、(たとえば、メッセージが傍受された場合に後で再利用されることを避けるための)現在のタイムスタンプのような、他の情報を追加することが可能である。送られるメッセージは、様々な形式を有することが可能であり、たとえば、URLまたは他のURI(「統一資源識別子(Uniform Resource Identifier)」)を使用して送られるHTTP要求であって、メッセージ内容が1つまたは複数のクエリ文字列パラメータ値の一部として含まれ、デジタル署名が別のクエリ文字列パラメータの値として含まれる、HTTP要求の形式を有することが可能である。ステップ910で、ルーチンは、収集された情報に基づいてデジタル署名を生成する。これは、たとえば、あらかじめ選択されたデジタル署名アルゴリズムを使用し、あらかじめ選択されたタイプのメッセージ情報(たとえば、特定の順序の特定のメッセージパラメータ値)を使用することによって行われる。ステップ915で、ルーチンは、署名をメッセージに追加してからメッセージを送信し、次の署名付きメッセージが送られるまで、ステップ920で終了する。
【0051】
図9Bの検証マネージャルーチン925は、ステップ927から始まり、ステップ927では、着信メッセージの検証の要求(たとえば、カスタマサービスまたは提携サービスから受け取ったメッセージに関して、アクセスマネージャシステムまたはそのコンポーネントの1つから受け取った要求)を受け取る。ステップ930で、ルーチンは、最初に、メッセージが十分に最近のものかどうかを、たとえば、メッセージに添付されているタイムスタンプからの経過時間が所定時間を超えていないかどうかに基づいて、判定する。タイムスタンプが古すぎる場合、ルーチンは、ステップ970で、署名が無効であることの通知を送信し、オプションで、ステップ975で、追加の処理を適宜実行する(たとえば、無効なメッセージのパターンが見つかった場合は通知を生成する)。その後、ルーチンはステップ995に進む。
【0052】
タイムスタンプが十分に最近のものであった場合、ルーチンは、ステップ935に進み、受け取ったメッセージの送信元であるカスタマに対応する、保存されていた秘密アクセス鍵を、メッセージに含まれていて、その秘密アクセス鍵に関連付けられている、そのカスタマに割り当てられた識別子に基づくなどして、取り出す。他の実施形態では、カスタマサービスまたは他の提携サービスは、受け取られた要求の送信元のIPアドレスに基づくなど、他の方法で識別されることが可能である。ステップ935で、秘密アクセス鍵およびカスタマに関する任意の追加情報を取り出した後、ルーチンは、図9Aのステップ905および910に関して前述されたものと同じ方法で、ステップ940および945で、メッセージのデジタル署名を生成する。これは、たとえば、(デジタル署名を含まない)メッセージに含まれた情報および取り出された秘密アクセス鍵を使用するためである。ステップ950で、新しく生成した署名を、メッセージに含まれている署名と照合する。ステップ955で、その2つのデジタル署名が同じであると判定した場合は、メッセージを検証し、ステップ960で、対応する確認を送信する。メッセージが正しいことが立証されない場合は、メッセージを偽造と見なし、ステップ965で、対応する通知を送信する。ステップ960、965、または975の後、ルーチンは、ステップ995に進み、続行するかどうかを決定する。続行する場合、ルーチンは、ステップ927に戻り、続行しない場合はステップ999で終了する。
【0053】
ここでは図示されていないが、実施形態によっては、アクセスマネージャからのメッセージを検証するために、同様の手法がサービスによって用いられてよい。さらに、様々な実施形態が、図9Aおよび9Bに示された署名ベースの検証より強力な、追加のセキュリティ機能およびメカニズムを有してよく、これは、たとえば、サービスの担当者が最初にサービスを登録した場合に、その担当者の身元に関する情報を収集することである。
【0054】
このように、様々な手法を用いて、カスタマイズ可能なサインオン機能性および他の機能性をサービスに提供することが可能であり、また、様々な手法を用いて、対話のセキュリティを強化することが可能である。さらに、実施形態によっては、さらに様々な情報および手法を用いることが可能である。たとえば、アクセスマネージャのカスタマが、Webサイト(電子商取引サイトなど)を含むことが可能であり、アクセスマネージャのプロバイダに無関係であることが可能である。アクセスマネージャによってカスタマに付与されるパーミッションのレベルは、たとえば、未知のサイトよりは、よく知られ、評価の高いサイトに、より高いレベルのパーミッションを付与するというように、一定でなくてもよい。さらに、低レベルのコブランディングパーミッションは、使用するイメージおよびテキストを指定することをアクセスマネージャカスタマに許可することだけが可能であるが、高いレベルのパーミッションを有するアクセスマネージャカスタマは、イメージ、イメージマップ(ユーザがイメージの任意の部分または指定部分を選択したときに機能性を提供する)、指定されたタイプのユーザ選択可能機能性(たとえば、ドロップダウンボタンを有する見出し)、テキスト、リンク、バックグラウンドミュージック、Java(登録商標)Scriptコード、Flashアニメーション、Shockwaveムービー、Java(登録商標)アプレット、カスタムCSS(「カスケーディングスタイルシート」)スタイルなどを追加することが可能である。実施形態によっては、パーミッションの付与は、リアルタイムまたはほぼリアルタイムのプロセスで自動的に行われるが、他の実施形態では、このプロセスは(たとえば、サービスの手動見直しを考慮に入れるために)より時間がかかる可能性がある。さらに、実施形態によっては、カスタマに付与されるパーミッションのレベルは、(たとえば、定期的に)見直しおよび修正されることが可能である。たとえば、カスタマに関して問題または懸念が持ち上がった場合は、パーミッションのレベルを下げることが可能である。逆に、そのような問題が発生していない場合は、パーミッションのレベルを上げることが可能である。たとえば、一部またはすべての新規カスタマに低レベルのパーミッションを付与し、カスタマとの継続的なエクスペリエンスによって保証される場合はパーミッションのレベルを徐々に上げていくことが可能である。たとえば、カスタマによる、またはカスタマの代理でのトラフィックおよび/または利用パターンの分析または見直しに基づいて、パーミッションのレベルを上げることが可能である。実施形態によっては、付与されたパーミッションのレベルの見直しは、外部要因(たとえば、カスタマに関するニュースまたはカスタマに起こった変化(たとえば、カスタマの合併または買収、破産など))によってトリガされる場合がある。
【0055】
様々なタイプのサービスが、提携サービスとして行われることが可能であり、そのようなサービスとして、支払処理、クレジットカード検証サービス、コンシューマ調査サービス、広告サービス、履行サービスなどがあり、これらに限定されない。また、実施形態によっては、アクセスマネージャのプロバイダが、そのサービスのいくつかを提携サービスとして提案してもよい。提携サービスは、場合によっては、カスタマまたはユーザがそれぞれのサービスの提供を容易にするための情報のサブセットへのアクセス権を与えられることが可能であり、たとえば、コンシューマ調査サービスは、特定の製品がいつコンシューマに出荷されたか、ならびに、製品およびサービスに関してコンシューマの追跡を実行するための連絡先情報を知ることが必要であろう。
【0056】
サービスからアクセスマネージャへ送られるメッセージまたは他の要求は、様々な実施形態において様々な形式をとることが可能である。実施形態によっては、要求が、クエリ文字列として渡されるメッセージパラメータまたは他のコンテンツを有するHTTPメッセージであることが可能であり、少なくとも一部の情報(たとえば、秘密アクセス鍵、機密のユーザサインオン情報および他のユーザ情報など)が、好ましくは、セキュアな手段(たとえば、セキュアHTTP)または(たとえば、物理メール、電話などを介する)オフライン形式で送られる。同様に、ユーザのサインオン情報または他の識別情報が、様々な形式を有することが可能であり、たとえば、ユーザ名およびパスワード、各種バイオメトリック情報、PKIベースの情報などの形式を有することが可能である。実施形態によっては、信用証明書は、Webブラウザのクッキーとして、または、代替として、WS−Federation Passive Profileで指定される形式(たとえば、WS−Trust RequestSecurityTokenResponse XML要素)で、または別のサインオン仕様標準に基づいて(たとえば、Liberty Alliance ProjectやMicrosoftのPassportサービスなどに基づいて)、交換されることが可能である。同様に、実施形態によっては、サインオンプロセスが、様々な方法で(たとえば、WS−Federation Passive Requestor Profileで指定されたプロセスで)実行されることが可能である。
【0057】
前述のように、実施形態によっては、少なくとも一部のカスタマサービスが、(たとえば、様々なタイプの、ユーザとの対話を追跡するために)代替データプールの開設および使用を、サービスのユーザの代わりに要求することが可能である。たとえば、代替データプールは、購入、表示された製品またはサービス、ログイン時刻、行われた情報修正、さらに場合によっては、カスタマサービスに固有ではない、ユーザの履歴や他のアクティビティの情報などの、ユーザに関する情報を格納することが可能であり、実施形態によっては、カスタマが、どのようなデータを代替データプールに格納するかを構成することを許可されることが可能である。実施形態によっては、カスタマが代替データプールを利用できるかどうかは、カスタマに付与されたパーミッションのレベルに依存することが可能である。
【0058】
実施形態によっては、秘密アクセス鍵を、(たとえば、定期的に、または破損時に)修正または再生成することが可能である。さらに、秘密アクセス鍵の使用方法に関する情報を適正な受信者だけが利用できるように管理することにより、また、さらにオプションで、カスタマごとに異なるプロセスを使用して、セキュリティをさらに強化することが可能である。実施形態によっては、指示されるプロセスは、メッセージに関するパラメータ値が含まれるべき、パラメータのリスト、メッセージパラメータの順序、および使用するエンコードのタイプなどを含むことが可能であり、プロセスが様々な形式でカスタマに指示されることが可能である(たとえば、サービス運営者がサービスにプロセスを手動で組み込む際に使用するドキュメンテーション、プロセスが実行されるように様々な入力を与えられる実行可能コードなどの形式であることが可能である)。デジタル署名は、様々な形式で生成されることが可能であり、たとえば、メッセージ認証コード(たとえば、HMAC(「keyed−Hash Message Authentication Code」)−MD5(「Message Digest algorithm 5」))を使用して生成されることが可能である。
【0059】
当業者であればさらに理解されるように、実施形態によっては、前述の諸ルーチンで与えられる機能性は、別の形式で与えられることも可能であり、たとえば、より多くのルーチンに分割されたり、より少ないルーチンに統合されたりして与えられることも可能である。同様に、実施形態によっては、図示されたルーチンは、説明されたものより多くの機能性または少ない機能性を与える場合があり、それは、たとえば、他の図示されたルーチンがそのような機能性を欠いたり、含んだりする場合や、与えられる機能性の数が変更された場合である。さらに、様々な操作が、特定の形式で(たとえば、シリアルに、またはパラレルに)かつ/または特定の順序で実行されるように示されているが、当業者であれば理解されるように、他の実施形態では、それらの動作が、他の順序で、かつ、他の形式で実行されることが可能である。当業者であればさらに理解されるように、前述のデータ構造は、別の形式で構造化されることも可能であり、これは、たとえば、1つのデータ構造を複数のデータ構造に分割することによって、あるいは、複数のデータ構造を1つのデータ構造に統合することによって可能である。同様に、実施形態によっては、図示されたデータ構造は、説明されたものより多くの情報または少ない情報を格納する場合があり、それは、たとえば、他の図示されたデータ構造がそのような情報を欠いたり、含んだりする場合や、格納される情報の数またはタイプが変更された場合である。
【0060】
以上より理解されるように、本明細書では、例示を目的として特定の実施形態について説明してきたが、本発明の趣旨および範囲から逸脱することなく、様々な修正がなされることが可能である。したがって、本発明は、添付の特許請求項およびその中で記載されている要素によって限定されることを除き、限定されない。さらに、本発明の特定の態様が特定の請求項形式で示されているが、発明者らは、どのような利用可能な請求項形式でも本発明の様々な態様を想定している。たとえば、現時点では、本発明の一部の態様だけが、コンピュータ可読媒体のかたちで具体化されるように記載されているが、他の態様も同様にそのように具体化されることが可能である。
【図面の簡単な説明】
【0061】
【図1A】アクセスマネージャシステム、サービス、およびユーザの間で行われる様々なタイプの対話の例を示す図である。
【図1B】アクセスマネージャシステム、サービス、およびユーザの間で行われる様々なタイプの対話の例を示す図である。
【図1C】アクセスマネージャシステム、サービス、およびユーザの間で行われる様々なタイプの対話の例を示す図である。
【図2A】カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャと、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す図である。
【図2B】カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャと、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す図である。
【図2C】カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャと、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す図である。
【図2D】カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャと、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す図である。
【図2E】カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャと、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す図である。
【図3A】カスタマサービスの代理としてのアクセスマネージャからユーザに提供される、カスタマイズされたサインオンプロセスの例を示す図である。
【図3B】カスタマサービスの代理としてのアクセスマネージャからユーザに提供される、カスタマイズされたサインオンプロセスの例を示す図である。
【図4】アクセスマネージャサーバコンピューティングシステムの例示的実施形態を示すブロック図である。
【図5】カスタマ登録マネージャルーチンの例示的実施形態のフロー図である。
【図6】ユーザ対話マネージャルーチンの例示的実施形態のフロー図である。
【図7】信用証明書マネージャルーチンの例示的実施形態のフロー図である。
【図8】カスタマステータスマネージャルーチンの例示的実施形態のフロー図である。
【図9A】受け取ったメッセージを認証するルーチンの例示的実施形態のフロー図である。
【図9B】受け取ったメッセージを認証するルーチンの例示的実施形態のフロー図である。
【技術分野】
【0001】
以下の開示は、主に、カスタマイズ可能なユーザサインオン機能性を提供する手法に関し、たとえば、この機能性は、シングルサインオンサービスのカスタマである他のサービスのユーザに、カスタマイズ可能なサインオンプロセスを提供するシングルサインオンサービスにより提供される。
【背景技術】
【0002】
日常生活におけるコンピュータの利用が広く普及しつつあり、たとえば、ユーザが、インターネット経由で(たとえば、Webサイトを介して)、あるいは、他のアクセスメカニズム(たとえば、携帯電話網)を介して、様々なタイプのリモートサービスにアクセスしてこれを利用することが可能になっている。たとえば、そのようなサービスは、様々なタイプの情報(たとえば、最新ニュースや参考資料)を提供することが可能なものもあれば、様々なタイプのアクティビティや機能(たとえば、オンラインバンキング、オンラインショッピング、電子メールまたは他のメッセージングサービスなど)を提供することが可能なものもある。一部のサービスは情報および機能を誰にでも提供することが可能であるが、他の多くのサービスは、許可されたユーザのみに制限されており、たとえば、許可されたユーザのみがユーザ情報を利用できるようにすることにより、ユーザ情報のプライバシが保護され(たとえば、ユーザが自分の電子メールを読むためには電子メールサービスにログインしなければならない)、実行されるアクティビティに使用されるユーザデータが管理され(たとえば、ユーザのショッピングを便利にするために、ユーザの金銭情報および出荷先情報(たとえば、ユーザに対して保持されているアカウントの一部)をオンライン商店側が保存する)、ユーザがしかるべき支払いを完了したことや、ユーザがそのサービスの利用に関する他の条件に満足していることが確認される。
【0003】
サービスにサインオン(または「ログオン」または「ログイン」)して、制限された情報または機能性へのアクセスを許可されていることを示すことが可能であるためには、典型的には、ユーザはまず、そのサービスに登録し、そのサービスに固有の、しかるべきサインオン情報(たとえば、ユーザ名およびパスワード)を取得しなければならない。しかしながら、それぞれが固有のサインオン情報を有するサービスが急増しているため、ユーザは、異なるインターネットサイトごとに異なる、多数のサインオン情報のセットを覚えなければならない不便さを強いられている。さらに、インターネットサイトおよびそのようなサービスの他のプロバイダの多くの運営者が、そのようなユーザサインオンを可能にすること、ならびにユーザサインオンデータおよび他の認証データを保持することの機能性を提供する負担から解放されることを望んでいる。
【0004】
こうした状況に対処すべく、提携する複数のサービスまたはシステムの群へのアクセスを可能にするサインオン情報の単一セットをユーザが作成するシングルサインオンシステムが生み出された。残念なことに、現在のシングルサインオンシステムには様々な問題がある。たとえば、サービス運営者の多くが、別の運営者によって提供されるサインオン機能性を使用することに対して億劫である。この億劫さは、利用できるサインオンシステムが所望の機能性を提供できないことなどにより、サインオンシステムと対話する際のユーザエクスペリエンスに一貫性がないため(たとえば、一貫したブランディング、あるいは他の一貫した外観や機能性がないため)であると考えられる。さらに、サービス運営者およびユーザは、セキュリティに関して懸念がある場合がある。それは、たとえば、詐欺師が、シングルサインオンシステムとの対話においてユーザまたはサービス運営者になりすまして、制限された情報または機能性へのアクセス権を不正に取得することが可能なのではないかという恐れである。
【0005】
したがって、シングルサインオンサービスを改善する手法および他の利点を提供することが有益であろう。
【発明を実施するための最良の形態】
【0006】
ユーザと対話するための、カスタマイズ可能な機能性を提供する手法について説明する。カスタマイズ可能な機能性は、他のサービスにシングルサインオン機能性および他の機能性を提供するアクセスマネージャシステムを介するなどして提供される。実施形態によっては、ユーザが利用できるWebサイトまたは他のサービスの運営者が、アクセスマネージャシステムと対話することにより、アクセスマネージャシステムがサービスのユーザに対して利用可能にするシングルサインオン機能性および/または他の機能性をカスタマイズしたり、他の方法で構成したりすることが可能である。アクセスマネージャシステムは、そのような機能性を、様々な実施形態において様々な形式で他のサービスに提供することが可能であり、これは、たとえば、サービスの運営者が初期構成を対話形式で行うことを可能にすることによって、かつ、カスタマイズされた機能性が、アクセスマネージャシステムのAPI(「アプリケーションプログラミングインターフェース」)によるプログラム形式でサービスのユーザに提供されることを可能にすることによって、可能である。少なくとも一部のそのような実施形態では、アクセスマネージャシステムは、様々なユーザの様々なサインオン情報および他のアカウント情報を保持し、それらのユーザが対話する複数の互いに無関係なサービスの代理として、その保持されている情報を使用して、それらのユーザにシングルサインオン機能性を提供する。さらに、少なくとも一部の実施形態では、アクセスマネージャシステムが、その代理として、カスタマイズされた機能性を提供するところのサービス群は、それぞれが、アクセスマネージャシステムのカスタマ(カスタマサービス)であり、これは、たとえば、既にアクセスマネージャシステムに登録しているカスタマサービスが、(たとえば、料金と引き替えに)カスタマイズされた機能性を提供されるようにするためのものである。
【0007】
実施形態によっては、アクセスマネージャは、アクセスマネージャから利用できるシングルサインオン機能性および/または他の機能性に対する様々なタイプのカスタマイズを可能にすることが可能である。カスタマサービスの代理であるアクセスマネージャとのユーザ対話が、個々のカスタマサービスに合わせてカスタマイズされるように、カスタマサービスの運営者が、様々なタイプのカスタマイズを構成することが可能である。たとえば、少なくとも一部の実施形態では、そのようなタイプのカスタマイズとして、サービスのユーザとの対話時にアクセスマネージャによって使用される、そのサービスに対する様々なタイプのコブランディングが含まれることが可能であり、たとえば、ユーザに提示される1つまたは複数の情報群(たとえば、ユーザに対して表示される1つまたは複数のWebページ)のそれぞれに、そのサービスのために構成された様々な情報が含まれ、そのような情報として、たとえば、1つまたは複数の指示された画像(たとえば、ロゴ)、指示されたテキスト、指示されたユーザ選択可能リンク、指示された他のユーザ選択可能コントロール(たとえば、指示されたURL(「ユニフォームリソースロケータ」)から入手できるか、または指示されたコードを実行することにより入手できるような、表示されるメニューバー)、指示されたコードを実行することにより提供される機能などがある。さらに、少なくとも一部の実施形態では、アクセスマネージャから利用可能な機能性のカスタマイズには、アクセスマネージャとの対話時にサービスのユーザから収集される様々なタイプの情報が含まれ、たとえば、サービスの運営者によって選択された1つまたは複数のあらかじめ定義された質問および/またはサービス運営者によって指定された1つまたは複数の質問に基づいてユーザから情報(たとえば、ユーザに関するデモグラフィック情報、嗜好情報、サービスがその操作の実行時に使用する、ユーザに固有の情報、その他)が収集される。コブランディングおよび情報収集のカスタマイズの詳細については、後述する。
【0008】
実施形態によっては、ユーザがアクセスマネージャと対話して、あるサービスのカスタマイズされたサインオンプロセスを完了した後、アクセスマネージャは、そのユーザについての信用証明書(credential)をそのサービスに提供し、これは、たとえば、そのサービスが、その後、ユーザの代理としてアクションを実行する(たとえば、ユーザの代わりに支払いを行う、ユーザの代わりに、保存されているアカウント情報を修正する、など)ための要求を行うことができるように、ユーザがそのサービスの許可されたユーザであることを示すものであり、かつ/または、ユーザを表すものである。この信用証明書は、様々な実施形態において様々な形式をとることが可能であり、たとえば、ユーザに固有の情報(たとえば、ユーザの一意のユーザ名または他の識別子、ユーザの実名または他の識別情報、カスタマイズされたサインオンプロセスにおいてユーザから収集された情報、その他)を、暗号化形式であれ、非暗号化形式であれ、含むことが可能であり、あるいは、単に、アクセスマネージャが後で(返された場合に)ユーザにマッピングできる情報(たとえば、アクセスマネージャまたはサービスに対して一意の番号)であることが可能である。さらに、少なくとも一部の実施形態では、ユーザの代理であるサービスに与えられた信用証明書が、アクセスマネージャによって、そのサービスに固有のものであるとして扱われ、これによって、後で、ユーザの代理として信用証明書を使用する要求が行われた場合には、その要求は、そのサービスによって行われたか、そのサービスの代理で行われた場合に限り、有効として扱われる。さらに、少なくとも一部の実施形態では、信用証明書は、他の様々なタイプの特性を有することが可能である。たとえば、特定の信用証明書が、ある限られた期間においてのみ有効であったり、かつ/または、ユーザの代理での特定のタイプのアクティビティまたは操作についてのみ有効であったりしてよい。その場合、アクセスマネージャは、そのような特性に基づいて、信用証明書の使用を制限することが可能である。信用証明書の詳細については、後述する。
【0009】
実施形態によっては、少なくともいくつかのサービスについて、サービスが実行することを許可されているアクティビティのタイプに関連する、さらなるタイプのカスタマイズがアクセスマネージャによって許可される。たとえば、いくつかのサービスがそれらのサインオンしたユーザに対して実行することを許可されているアクションのタイプを、様々な形式で限定することが可能であり、これは、たとえば、アクセスマネージャによってサービスに付与されている信頼度を反映させることによって可能であり、一例として、信用証明書は、実施形態によっては、限定された期間のみ有効であることが可能であり、その場合、サービスによっては、有効期間を延長するために、それらのユーザの信用証明書を(たとえば、指定された回数まで、指定された全有効期間まで、無期限かつ無制限に)リフレッシュすることを、少なくとも状況によっては、許可されることが可能である。さらに、少なくとも一部の実施形態では、少なくともいくつかのサービスについてアクセスマネージャによって許可されるカスタマイズは、プライマリサービスが、ユーザの代理としてアクションを実行するために、別のセカンダリサービスに対して行うことが可能であってよい、1つまたは複数のタイプの権限委譲を含み、これは、たとえば、アクセスマネージャによって付与された信頼度をプライマリサービスおよび/またはセカンダリサービスに反映させるためのものである。たとえば、信用証明書が与えられた少なくともいくつかのプライマリサービスは、そのような信用証明書を様々な形式で使用する権限を他のサービスに委譲することを許可されることが可能であり、そのような形式として、信用証明書を使用して、少なくともいくつかのタイプのアクションを、表されたユーザの代理として実行すること、少なくとも状況によっては、限定された有効期間で信用証明書をリフレッシュすること、当該ユーザについての、セカンダリサービス専用の新しい信用証明書の発行を要求すること(たとえば、信用証明書がオリジナルの発行先のサービスについてのみ有効である場合)などが含まれる。権限委譲のタイプの詳細については、後述する。
【0010】
アクセスマネージャによって、サービスが利用できるようにされるカスタマイズのタイプは、様々な実施形態において様々な形式で決定されることが可能であり、たとえば、サービスおよび/またはサービス運営者に関して取得可能な情報に基づく自動的な形式で決定されることが可能である。たとえば、悪意のあるサービス(または、悪意のないサービスになりすまそうとするか、その他の方法で悪意のないサービスの代理として動作しようとする、悪意のあるパーティ)が、あるタイプのカスタマイズを許可された場合、それらのタイプのカスタマイズは、大きなセキュリティリスクおよび不利益リスクをもたらしうる。コブランディングタイプのカスタマイズの場合、ユーザに対して表示されるテキストおよび/またはイメージを追加することをサービスに許可することは、(テキストのコンテキストが攻撃的でも違法でもない限り)比較的リスクが少ない。逆に、アクセスマネージャが、ユーザに与えられる情報を生成する際に使用する実行可能コード、またはユーザに与えられる情報に含まれる実行可能コード(たとえば、ユーザに送られるWebページの一部として含まれるJava(登録商標)アプレット)を指定することをサービスに許可することは、比較的高いリスクをもたらす可能性がある(たとえば、サービスの指定するコードが、(監視しない限りサービス側にはわからない)ユーザからアクセスマネージャに提供されるサインオン情報を監視するなどして、ユーザに関する情報を不適切に取得することを可能にするリスクをもたらす可能性がある)。サービスが利用できるようにするカスタマイズのタイプの決定方法の詳細については、後述する。
【0011】
さらに、実施形態によっては、悪意のあるパーティが実際の許可されたパーティになりすまそうとするフィッシング詐欺の企てを阻止するなど、悪意のあるパーティが不正なアクティビティを行うのを阻止するために、様々な手法が用いられる。たとえば、悪意のあるユーザが、アクセスマネージャと対話することを許可されたサービスになりすまして、アクセスマネージャと対話しようとするのを阻止するために、追加のセキュリティ手法を用いて、少なくとも一部のサービスから送られる一部またはすべてのメッセージを認証することが可能である。具体的には、実施形態によっては、アクセスマネージャと対話することを許可された各サービスが、サービスおよびアクセスマネージャには知られている、少なくとも1つの一意の秘密アクセス鍵を与えられ、その後、サービスが、メッセージまたは他の連絡をアクセスマネージャに送る際に、そのサービスの秘密アクセス鍵を使用し、これによって、アクセスマネージャは、メッセージの送信者が実際にそのサービスであることを検証することが可能である。たとえば、サービスからのそのような各メッセージが、そのサービスの一意識別子の通知を含むことが可能であり、また、メッセージ内容の少なくとも一部に基づき、秘密アクセス鍵を用いて生成されたデジタル署名を含むことも可能である。アクセスマネージャは、そのようなメッセージを受け取ると、サービス識別子を用いて、そのサービスを識別し、そのサービスに対応する秘密アクセス鍵を取り出すことが可能であり、その後、取り出した秘密アクセス鍵と、メッセージ内容の同じ部分とを用いて、同じ方法で、デジタル署名を独自に生成することが可能である。アクセスマネージャによって生成されたデジタル署名が、送信者によってメッセージに含められたデジタル署名と一致すれば、アクセスマネージャは、送信者が一意識別子およびそのサービスの秘密アクセス鍵の両方にアクセスできることを確認することが可能であり、したがって、送信者が実際にそのサービスであることが非常に確からしいことを検証することが可能である。秘密アクセス鍵は、様々な実施形態において様々な形式をとることが可能であり、たとえば、共有秘密鍵、PKI(「公開鍵インフラストラクチャ」)鍵ペア、X.509証明書、ハードトークンを使用して生成された秘密鍵などの形式をとることが可能である。少なくとも一部の実施形態では、さらに他のセキュリティ手法を用いることが可能であり、秘密アクセス鍵の使用に関する詳細については、後述する。
【0012】
以下、例示を目的として、いくつかの実施形態を説明する。それらの実施形態においては、特定タイプのサービスが、アクセスマネージャシステムによって、そのサービスの特定タイプのユーザに特定の形式で提供された特定タイプの機能性の特定タイプのカスタマイズを構成する。しかしながら、説明される手法が、他の多様な状況で使用されることが可能であること、ならびに本発明が、与えられる例示的詳細に限定されないことを理解されたい。
【0013】
図1Aは、アクセスマネージャシステム、サービス、およびユーザの間で行われる様々なタイプの対話の例を示す。具体的には、図1Aは、アクセスマネージャシステム114と、アクセスマネージャのカスタマであるサービス110と、カスタマサービスのユーザ112と、カスタマサービスと提携している他のセカンダリサービス118(オプション)と、アカウントマネージャシステム116との間で行われる対話を示している。この例では、アカウントマネージャ116およびアクセスマネージャ114は、両方とも、単一エンティティによって与えられたシステム115のグループの一部として与えられており(たとえば、アカウントマネージャは、許可されたパーティからの要求があった場合に、アクセスマネージャとともに、アカウントを有するユーザの代理として様々なアクションを実行する)、実施形態によっては、提携サービス118の少なくともいくつかがシステム115に含まれることも可能である。図示されたシステム、サービス、およびユーザの間では、様々なメッセージが発生する。そのようなメッセージとして、ユーザのアカウントを確立することの一部である、ユーザとアクセスマネージャシステムとの間のメッセージ(たとえば、サインオン情報を含む)、カスタマサービスのためのカスタマイズされた機能性を構成する、カスタマサービスとアクセスマネージャとの間のメッセージ、ユーザとカスタマサービスとの間のメッセージ(ユーザが、カスタマサービスに合わせてカスタマイズされたサインオンプロセスに参加するために、アクセスマネージャとの対話にリダイレクトされる初期対話を含む)、カスタマサービスとアカウントマネージャシステムとの間のメッセージ(たとえば、カスタマサービスにサインオンしたユーザの代理としてアクティビティを実行するためのメッセージ)、カスタマサービスと提携セカンダリサービスとの間のメッセージ(たとえば、カスタマサービスにサインオンしたユーザの代理としてアクティビティを実行するためのメッセージ)、提携サービスとアクセスマネージャとアカウントマネージャシステムとの間のメッセージ(たとえば、カスタマサービスにサインオンしたユーザの代理としてのメッセージ)などがある。さらに、サービスに関与するメッセージ(たとえば、カスタマサービス110および/または提携サービス118と、アクセスマネージャ114、アカウントマネージャ116、および他のカスタマサービスまたは提携サービスとの間のメッセージ)の少なくともいくつかは、サービスの秘密アクセス鍵に基づくデジタル署名(図示せず)を使用することが可能である。
【0014】
図1Bは、アクセスマネージャシステム、サービス、およびユーザの間の様々なタイプの対話の1つの具体例を示し、特に、カスタマサービスが、Webサイトではなくアプリケーション開発者のアプリケーションによって与えられている実施形態を示している。具体的には、アプリケーション開発者120(この例では「ボブ」という名前である)が最初に、開発者のアプリケーション122によって与えられるサービスに関して、アクセスマネージャシステム150に登録180する。この登録は、たとえば、この例では(たとえば、カスタマ登録マネージャコンポーネントで与えられることが可能な)カスタマ登録プロセス158と対話することによって行われる。この例では、アプリケーション122は、アプリケーションのエンドユーザにサービスおよび/または他の機能性を提供する(たとえば、汎用パーソナルコンピュータで実行されるための)アプリケーションプログラムであるが、他の実施形態では、そのようなアプリケーションは、他の様々な形式をとることが可能であり、そのような形式としては、Webアプリケーション、ダウンロード可能なアプレットまたは他の実行可能コード、クライアントおよび/またはサーバアプリケーション、モバイルアプリケーション(たとえば、携帯電話または他の形態のモバイルコンピューティング装置で実行されるアプリケーション)などがある。ステップ180の一環として、開発者は、様々な情報を供給することが可能であり、それには、連絡先情報およびアプリケーション122に関する情報(およびオプションでアプリケーションのコピー)が含まれる。登録対話180の一環として、開発者は、後でアプリケーションのエンドユーザが使用する様々なカスタマイズを構成することが可能であり、それらは、アクセスマネージャシステムによって開発者に付与されているパーミッションのレベルに応じたコブランディング、情報収集、権限委譲などである。代替として、一部のカスタマイズが使用されない場合がある。たとえば、アプリケーションがエンドユーザと直接対話してサインオン情報を取得し、取得されたサインオン情報がプログラムによって、検証のためにアクセスマネージャシステムに送られる場合には、コブランディングが構成されない。さらに、アプリケーションのエンドユーザが、アプリケーション122によって与えられたグラフィカルユーザインターフェースと対話する、図示されたような実施形態では、アプリケーションは、少なくともいくつかの情報を特定の形式のグラフィカルユーザインターフェースからエンドユーザに提供することを、契約により、または他の形式で義務づけられることが可能である。そのような情報は、たとえば、アクセスマネージャのブランドとコブランディングされる形式でエンドユーザに提示されているアクセスマネージャシステムにサインオンすることに関連付けられることが可能である。代替として、アプリケーションは、他のタイプの、アクセスマネージャに固有の情報または機能性を提供すること、および/またはエンドユーザのサインオン情報を保護するために、様々な指定のセキュリティ対策を採用することを義務づけられることも可能である。開発者は、登録後に、アクセスマネージャ158から様々な情報181を受け取ることが可能であり、たとえば、使用される秘密鍵の通知(または対話180の一環として開発者から指定された秘密鍵の確認)およびアプリケーションの非秘密の一意識別子(たとえば、秘密アクセス鍵に関連付けられた識別子)を受け取ることが可能である。開発者が様々なエンドユーザ130にアプリケーションを配布182した後、エンドユーザが、そのアプリケーションを使用して様々なタイプの機能性を取得することが可能である。
【0015】
次に、ユーザ例130が、アプリケーションと対話183し、たとえば、リモートサードパーティWebサービスプロバイダ140(たとえば、ユーザが既成のアカウントを有するWebサービスプロバイダ)から提供される1つまたは複数のWebサービスを利用するためにユーザがサインオンを行う動作を要求する。Webサービスは、異種のアプリケーションおよびコンピュータ同士が対話することを可能にすることが可能であり、様々な下位プロトコルおよび手法を用いて定義および実装されることが可能である。たとえば、一部のWebサービス実装は、URI(たとえば、指定された動作および1つまたは複数のクエリパラメータを含むURL)として指定されるWebサービス呼び出し要求への応答として、HTTP (「HyperText Transport Protocol」)を用いてXML(「eXtensible Markup Language」)フォーマットのデータを返す。他の実装では、さらなる下位プロトコルが様々な目的で使用され、たとえば、標準メッセージ交換のためにSOAP(「Simple Object Access Protocol」)が使用され、サービス呼び出しの記述のためにWSDL(「Web Services Description Language」)が使用され、利用可能サービスの発見のためにUDDI(「Universal Description,Discovery,and Integration service」)が使用される。状況によっては、アプリケーション122およびWebサービスプロバイダ140は、あらかじめ定義された関係を有することが可能である。他の実施形態では、アプリケーションは、そのようなあらかじめ定義された関係を有することなく、単に、アプリケーションのエンドユーザの代理として、提供されたWebサービスの定義済みAPIと対話することが可能であり、これは、たとえば、Webサービスプロバイダがアクセスマネージャシステムのカスタマでもあり、ユーザを表すために、アクセスマネージャシステムの信用証明書を受け取って使用するように構成されている場合である。
【0016】
ユーザが、サインオンをトリガする動作を要求すると、(たとえば、要求者がアプリケーションであることの検証のために、アプリケーションの秘密鍵を使用して生成されたデジタル署名を有する)サインオン要求メッセージが、アプリケーションによって生成され、ユーザ対話マネージャプロセス152へ送られる184。このメッセージが検証された場合、アクセスマネージャは、オプションで、ユーザからサインオン情報を収集する際にアプリケーションによって使用されるサインオン情報(たとえば、情報を収集するためにユーザに対して行う質問、または、アプリケーションが1つまたは複数のページまたはスクリーンをユーザに対して表示するように設計されている場合は、それらのページまたはスクリーン)を返す185ことが可能であり、アプリケーションは、(この例では、アクセスマネージャシステムにあるユーザの既成アカウントを反映する)様々なサインオン情報を収集するために、ユーザとのサインオンプロセスを実行することが可能である。収集された情報は、次に、アクセスマネージャユーザ対話マネージャ152へ送られる186。他の実施形態では、アプリケーションは、(たとえば、アプリケーションに付与されているパーミッションのレベルに応じて)アクセスマネージャシステムとの初期対話を行うことなく、ユーザからサインオン情報を収集し、その、ユーザのサインオン情報を、初期要求184とともに送ることが可能であるが、そのような状況では、エンドユーザのサインオン情報がアプリケーションにさらされる可能性がある。アクセスマネージャユーザ対話マネージャ152は、サインオン情報を受け取ると、このサインオン情報をアカウントマネージャシステム160へ送り187、アカウントマネージャシステム160は、ユーザアカウントデータベース(「DB」)162内の情報を使用してそのサインオン情報を検証する。次に、ユーザ認証の通知(たとえば、ユーザIDまたはエラーメッセージ)がアクセスマネージャユーザ対話マネージャに返される188。サインオン情報が有効だった場合は、信用証明書マネージャ156へ要求が(たとえば、ユーザIDとともに)送られ189、信用証明書マネージャは、アプリケーションによって使用されるための、そのユーザを表す信用証明書を生成し、この信用証明書をアクセスマネージャユーザ対話マネージャへ返す190。アクセスマネージャユーザ対話マネージャは、信用証明書を受け取ると、その信用証明書をアプリケーションに送り返す191。
【0017】
次に、アプリケーションは、Webサービス要求を生成し、これをWebサービスプロバイダ140へ送る192。この要求には、オプションで、アプリケーションの秘密アクセス鍵を使用して生成されたデジタル署名が含まれる。Webサービスプロバイダ140は、要求を受け取ると、オプションで、デジタル署名が添付されている場合にはデジタル署名を使用して、(要求をアクセスマネージャに送って検証を要求すること(図示せず)などにより)要求者の身元を検証する。さらに、Webサービスプロバイダは、ユーザの信用証明書を検証する。これは、この例では、Webサービスプロバイダが信用証明書を信用証明書マネージャに送り193、信用証明書マネージャが(たとえば、信用証明書の正当性を立証する)適切な応答を生成し、これをWebサービスプロバイダに送る194ことによって行われる。信用証明書の正当性が立証されると、Webサービスプロバイダは、要求されたWebサービスをユーザに提供し、応答をアプリケーションへ送る195。次に、アプリケーションは、その応答に基づいて、対応する情報および/または機能性をユーザに提供することが可能である。実施形態によっては、アプリケーションはさらに、さらなる様々なタイプのWebサービス要求および他の要求を行うことが可能であり、たとえば、アカウントマネージャシステムと直接対話して、ユーザアカウントを変更したり、ユーザアカウントデータベース162からデータを取り出したりする要求を行うことが可能である。すべての要求が行われた後、ユーザは、アプリケーションを介してサインアウトするか、単に、信用証明書の限られた有効期限が切れるのを許容することが可能である。
【0018】
図1Cは、単一のサインオンWebサービス101と、カスタマWebサイト例103と、このカスタマWebサイトと対話しているエンドユーザ(図示せず)によって使用されるWebブラウザ105との間の様々なタイプの対話の一例を示す。この例では、図示された対話の第1のステップとして、エンドユーザは、指示された機能性を取得するために、ブラウザ105を使用して、HTTPベースの要求121をカスタマWebサイト103へ送る。Webサイトは、要求された機能性はサインオンしたユーザだけが利用できることを決定し、したがって、サインオンプロセスを実行するために、サインオン要求123をエンドユーザへ送る。この図示された実施形態では、サインオン要求に(たとえば、X.509証明書を使用して)デジタル署名が添付されており、これを生成する方法については、別の場所で詳述する。この例では、サインオンプロセスは、シングルサインオンサービスによって多数のカスタマWebサイトに提供され、サインオン要求123がブラウザ105に送られると、ブラウザ105は、要求123の指示により、(たとえば、HTTP 301ステータスコードを介するなどしてリダイレクトURLを送ることにより)デジタル署名を含む要求125をシングルサインオンサービスに転送する。次に、シングルサインオンサービス101は、要求125のデジタル署名の検証を試行し(詳細については、別の場所で詳述する)、検証が成功すれば、次に、サインオンページをブラウザ105に返す127。次に、エンドユーザは、ブラウザ105にサインオンページが表示された際に、自分のサインオン情報(たとえば、ユーザ名およびパスワード)をサインオンページに入力する。サインオンページは、対応するユーザアカウントを作成するために、ユーザとシングルサインオンサービスとの間で行われた登録の際に提供された情報に基づいて(または、対話型登録プロセス(図示せず)の後に)生成されることが可能である。次に、サインオン情報は、(たとえば、エンドユーザが「完了」コントロールまたは他の同様のコントロールを選択した際に)シングルサインオンサービスに返される129。この例では、エンドユーザは、シングルサインオンサービスプロバイダを信頼して、自分のサインオン情報を進んでシングルサインオンサービスに送っている。これは特に、この例では、サインオン情報がカスタマWebサイト103と共有されないためである。シングルサインオンサービス101は、サインオン情報を受け取った後、受け取ったサインオン情報が有効かどうかを判定し、有効であれば、そのエンドユーザのサインオンを実行し、そのユーザをサインオンしたエンドユーザとして表す信用証明書を生成する。生成された信用証明書は、ブラウザ105に送られ131、そこから(カスタマWebサイト用クッキーまたはリダイレクトURLを介するなどして)カスタマWebサイト103へ転送される133。カスタマWebサイト103は、エンドユーザのサインオンの成功を示す信用証明書を受け取ると、最初に要求された機能性(図示せず)をエンドユーザに提供する。また、ここでは図示されていないが、カスタマWebサイトは、信用証明書を使用して、様々な後続のアクションをエンドユーザの代理として実行することも可能である。たとえば、信用証明書が、ユーザのアカウントに関連する要求とともに(たとえば、ユーザアカウントに保存されている金銭情報に基づいて支払いを行うために)、シングルサインオンサービスに返されることが可能である。そのような、信用証明書に基づく利用は、カスタマWebサイト103とシングルサインオンサービス101との間で直接行われる対話に基づくことが可能であり、あるいは、1つまたは複数の提携中間サービス(図示せず)および/またはエンドユーザとの対話を介することも可能である。さらに、様々なメッセージの少なくともいくつかが、セキュリティ上の理由から、HTTP/Sにより有利に転送されることも可能である。
【0019】
図2A〜2Eは、カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャとWebサイトまたは他の、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す。具体的には、図2Aは、アクセスマネージャのカスタマになる見込みのあるサービスの担当者に対して表示されることが可能な第1の情報群を示しており、これは、たとえば、サービスのユーザの代理として、カスタマイズされた機能性を取得するために、アクセスマネージャに登録しようとしているサービスの運営者に対して表示されるWebページによって示される。この例では、初期登録情報は、指示情報201およびセクション202を含んでおり、セクション202では、アクセスマネージャカスタマが様々なタイプの情報を指定することが可能であり、たとえば、名前およびインターネットアドレス202a(たとえば、サービスを提供するWebサイトのURL)、管理用連絡先情報202b、サービスの少々の概要情報202cなどを指定することが可能である。サービスおよびサービス運営者に関する他の様々なタイプの情報が、他の実施形態において様々な方法で取得されることが可能であり、たとえば、カスタマが利用できるようにするカスタマイズのタイプを制限するなど、アクセスマネージャがアクセスマネージャカスタマに付与する信頼度およびこれに対応するパーミッションを決定するための要素として使用されることが可能である。入力された情報は、この例では、ユーザ選択可能な「登録」コントロール203をクリックすることにより、アクセスマネージャに送られる。また、ユーザ選択可能な「リセット」コントロール204を使用すると、フォームに入力した情報をリセットすることが可能である。「登録」コントロール203が選択されると、この例では、見込みのあるカスタマに対して、アクセスマネージャへの登録を続行するための、図2Bに示されるような、後続の情報群(たとえば、次のWebページ)が表示される。他の実施形態では、すべての情報要求およびカスタマイズ制御が、別の形式で(たとえば、まとめて表示される単一情報群の一部として)表示されることが可能である。
【0020】
図2Bは、コブランディングのカスタマイズの1つまたは複数のタイプを指定するための、カスタマになる見込みのあるサービスの担当者に対して表示されることが可能な第2の情報群の例を示している。この例では、コブランディングのカスタマイズの利用可能なタイプは、比較的最小限であり、これは、たとえば、カスタマに付与されたパーミッションが比較的低レベルであることを反映するためである(たとえば、高い信頼度が検証可能でない限り、どのカスタマにも適用される初期デフォルトとして、または図2Aに対して入力された情報および/またはサービスまたはサービス運営者に関して利用可能な他の情報に基づいて(たとえば、サービスまたは運営者との、過去の対話エクスペリエンスに基づいて))。この例では、カスタマは、複数のブランドを指定すること、および情報をブランドごとに異なるようにカスタマイズすることを許可される。他の実施形態では、そのようなブランドを使用しないことや、サービスとブランドとの各組合せを別個のカスタマとして扱うことが可能である。同様に、ここでは図示されていないが、他の実施形態では、カスタマは、指定および使用される異なるコブランディングまたは他のカスタマイズに関する他のタイプの区別を指定することが可能であってよい(たとえば、ユーザが関連付けられることが可能な複数の地理的ロケールまたは他のユーザグループ)。複数のブランド、ロケール、または他の異なるグルーピングを指定する場合、そのようなグルーピングのそれぞれは、実施形態によっては、別々の識別子と、オプションで、別々の秘密アクセス鍵とを与えられることが可能であり、これは、たとえば、使用される個々のグルーピングへの参照を可能にするためである。この例では、表示される情報は、構成されるブランドを示すセクション206(異なる複数のブランドが使用されない場合、または、カスタマイズがすべてのブランドに適用される場合には、空白のままにされる)と、指示情報205と、カスタマが1つまたは複数のカスタマイズを指定するための様々な質問および情報選択/指定の領域を有する領域207と、を含んでいる。たとえば、カスタマは、ユーザに対して表示される、サービスの1つまたは複数のロゴイメージを(たとえば、対応するファイルをアップロードすること、またはイメージを取り出すことが可能なネットワークアドレスを指定することにより)指定することが可能であり、この例では、指定されたロゴイメージのプレビュー208が、使用されるロゴロケーション、ユーザに対して表示されるテキスト、およびユーザに対して表示されるリンクとともに表示される。他の実施形態では、他の様々なタイプのコブランディングカスタマイズを利用可能にすることが可能であることが理解されよう。さらに、この例では、カスタマは、ユーザ選択可能な「プレビュー」コントロール209とユーザ選択可能な「保存」コントロール210とを与えられ、「プレビュー」コントロール209を使用すると、指定されたコブランディングカスタマイズの結果である1つまたは複数のサインオンページまたはスクリーンをプレビューすることが可能であり、「保存」コントロール210を使用すると、指定されたコブランディングカスタマイズを保存することが可能である。この例では、カスタマは、単一グループのコブランディングカスタマイズのみを実行するように図示されているが、他の実施形態では、コブランディングカスタマイズの異なる複数のセットを指定することが可能である。たとえば、アクセスマネージャによって、ユーザに対して表示される複数のページまたは他の情報群(たとえば、サインオンプロセスに使用される複数のページ、および/または他の関連するタイプのアクティビティ(たとえば、サインオフまたはサインアウトプロセス、ユーザからの情報収集、エラーの提示、信用証明書のリフレッシュ、プライマリサービスに対して発行された信用証明書に基づく、セカンダリサービス用の新しい信用証明書の生成(信用証明書の「クローニング」と呼ばれる)など)に使用されるページ)を反映するために、単一ブランドに対して、コブランディングカスタマイズの異なる複数のセットを提供することが可能である。
【0021】
図2Cは、図2Bの場合と同様に、コブランディングカスタマイズの1つまたは複数のタイプを指定するための、カスタマになる見込みのあるサービスの担当者に対して表示されることが可能な第2の情報群の別の例を示している。この例では、カスタマに付与された比較的高レベルのパーミッションを反映するために、(たとえば、図2Aのように提供された情報および/またはサービスまたはサービス運営者に関して利用可能な他の情報に基づいて)さらなるタイプのコブランディングカスタマイズがカスタマに対して利用可能になっている。他の実施形態では、他の理由で、さらなるタイプのコブランディングカスタマイズを利用可能にすることが可能である(たとえば、プレミアムカスタマに対し、追加料金と引き替えで)。この例では、表示される情報は、図2Bの情報205〜208からなる通知211を含み、さらに、追加のコブランディングカスタマイズ212を含む。この例における追加タイプのコブランディングカスタマイズは、ユーザに対して表示される情報の外観を追加指定する機能と、ページの見出しに含まれるユーザ選択可能コントロールおよび/または他の情報、またはユーザに対して表示される他の情報を指定する機能と、ページの一部として含まれる他の実行可能コード、またはユーザに対して表示または提供される他の情報と、を含んでいる。これらの追加のコブランディングカスタマイズのタイプは、単に例示的であって、代替実施形態では、他の追加タイプのカスタマイズを利用可能にすることも可能である。
【0022】
この例では、カスタマサービスの運営者または他の担当者が、様々なカスタマイズを、対応するプロンプトに応じて個々に指定するが、他の実施形態では、別の手法でコブランディングカスタマイズを指定することも可能である。たとえば、実施形態によっては、ユーザに対して表示または他の方法で提示されるカスタマイズされたサインオンページまたは他の情報の外観をカスタマがグラフィカルに指定するWYSWYG(「What You See is What You Get(見たものが、手に入るもの)」)システムを用いることが可能であり、あるいは、適切なフォーマット(たとえば、XMLまたは(X)HTML(「(eXtensible)HyperText Markup Language(拡張可能ハイパーテキストマークアップ言語)」)フラグメント)を使用して、コブランディングカスタマイズをファイルのかたちで指定して、アクセスマネージャに送ることも可能である。
【0023】
図2Dは、サービスのユーザとの対話時に実行される情報収集の1つまたは複数のタイプを指定するために、カスタマサービス担当者に対して表示されることが可能な、第3の情報群の例を示す。実施形態によっては、一部またはすべてのタイプの情報収集が、十分に高いレベルのパーミッションを有するカスタマだけが利用できるようにされることが可能であり、かつ/または、他の条件に基づいて(たとえば、プレミアムカスタマだけが)利用できるようにすることが可能である。この例では、(たとえば、それぞれが、ユーザに対して表示される、対応する質問(図示せず)を有する)様々な定義済みタイプの収集対象情報に対して、定義済み情報タイプの1つまたは複数を選択するためのチェックボックス213が利用可能になっている。ここでは図示されていないが、少なくとも一部の実施形態では、ユーザに対して行われるカスタマ指定質問の1つまたは複数のセットをカスタマサービスが構成することがさらに可能であり、たとえば、行われる質問を入力すること、およびオプションで、質問に対する可能な答えを列挙または他の方法で表示することを構成することが可能である。さらに、この例では、カスタマは、アクセスマネージャが追跡するユーザアクティビティの1つまたは複数のタイプ215をさらに指定することが可能であり、そのようなタイプとして、たとえば、サインオン試行(成功および/または失敗)、サインオフ試行、表示または他の方法で提示された契約条件(たとえば、登録プロセス(図示せず)においてカスタマによって指定され、「同意」コントロールを選択すること、または他のユーザ同意の提示によってユーザに受け入れられる契約条件)に対する同意を与えることなどがある。この例では、カスタマはさらに、(ユーザ選択可能タイミング制御214で示されるように)定義済みおよび/またはカスタマ指定のタイプの情報をユーザに尋ねるタイミングを指定することが可能であるが、他の実施形態では、タイミングを固定することも可能である(たとえば、サービスに対するユーザの最初のサインオン(または他のアクティビティ)の間に1回のみ、またはサインオンごとに、など)。この例では、フォーマッティング情報216がカスタマによって指定されることも可能であり、これは、たとえば、定義済みタイプの収集対象情報の少なくともいくつかについて可能なタイプの答えを示すためである。実施形態によっては、情報収集の構成時に他のタイプの情報も与えられることが可能であり、たとえば、与えられるユーザの答えが許容可能かどうかを動的に判定する際に使用される論理や、いくつかの質問(たとえば、ユーザに配偶者または子供がいるかどうかを示すユーザからの答えに基づく、ユーザの配偶者または子供に関する詳細についての質問)が特定のユーザに対して行われるべきかどうかを判定する際に使用される論理などが与えられることが可能である。
【0024】
図2Eは、他の提携セカンダリサービスに対する1つまたは複数のタイプの権限委譲(たとえば、プライマリカスタマサービスのユーザの代理として特定タイプのアクションを実行する権限の委譲)を指定するために、カスタマサービス担当者に対して表示されることが可能な、第4の情報群を示しているが、実施形態によっては、そのようなカスタマイズは、十分に高レベルのパーミッションを有するカスタマにのみ与えられることが可能である(そして、権限委譲の個々のタイプは、パーミッションレベルおよび/または他の要因に応じて変わってよい)。この例では、図2Eは、指示情報217と、権限の委譲を受けるサービスをカスタマが指定することが可能なセクション219、221、および223とを含んでいる。ここでは図示されていないが、実施形態によっては、カスタマはさらに、権限委譲のデフォルトセットを修正することなどにより、提携セカンダリサービスのそれぞれに対する、特定タイプの権限の委譲を指定することが可能である。カスタマはさらに、提携サービスがアクセスする情報に対する制御(たとえば、利用可能なユーザ情報の指定されたサブセット)を指定することが可能である。この例では、セクション219は、アクセスマネージャと提携している他の様々なサービス((たとえば、ユーザのアカウントに対して、かつ/または、ユーザのアカウントから行われる支払いを有効にする)支払サービスや、(たとえば、ユーザに関して既に指定された嗜好に従うなどして、ユーザの代理として、推薦を取得および/または付与する)推薦サービスなど)を(たとえば、同じエンティティによって与えられることを前提として)利用可能にする。さらに、セクション221は、他の様々な一般サービス(この例では、人気または信頼性の格付けのような、そのサービスに関する情報を含む)を利用可能にし、セクション223は、カスタマが他のサービスを指定することを可能にする。
【0025】
実施形態によっては、プライマリカスタマサービスと提携しているセカンダリサービス自体が、ユーザの代理としてアクセスマネージャと対話するために、アクセスマネージャに登録されることが必要な場合があり、したがって、一般サービスは、アクセスマネージャに既に登録されているサービスに基づくことが可能である。代替として、指定されたサービスがまだアクセスマネージャに登録されていない場合、アクセスマネージャは、その指定されたサービスに自動的に照会して、登録機能を提供することが可能である。カスタマサービスがユーザと対話しているときには、別のサービスへの権限の委譲は、ユーザによって開始される場合(たとえば、セカンダリサービスを介して提供される機能に対応する、プライマリカスタマサービスによって表示されるリンクまたはコントロール(たとえば、支払サービスに委譲される、ユーザのアカウントから支払いを行うリンク)をユーザが選択することに基づいて)、および/または、プライマリカスタマサービスによって自動的に実行される場合など、様々なかたちで行われることが可能である。さらに、実施形態によっては、セカンダリサービスとの対話は、ユーザにとって透過的なかたちで実行されることが可能である。たとえば、支払関連機能が要求された場合は、セカンダリ提携支払サービスがページまたは他の情報群を生成してユーザに送ることが可能である。これは、たとえば、対応する情報をユーザから取得するためである(たとえば、1つまたは複数の他のパーティの表示、少なくともいくつかのタイプのアクションに関するユーザのサインオンまたは他の情報の検証など)。さらに、一貫性のあるエクスペリエンスをユーザに提供するために、セカンダリ提携サービスは、少なくとも一部の実施形態では、プライマリカスタマサービスに対して既に指定されたコブランディング情報を、ユーザに対して表示される情報の中で使用することが可能である。そのような既に指定されたコブランディングへのアクセス権を取得するために、セカンダリ提携サービスは、そのコブランディング情報を使用する権限がセカンダリ提携サービスに委譲されている場合には、アクセスマネージャと対話して、コブランディング情報を取得することが可能である。たとえば、プライマリカスタマサービスは、プライマリカスタマサービスのための指定のタイプのコブランディング情報(たとえば、プライマリカスタマサービス用の1つまたは複数のロゴまたは他のイメージ)をセカンダリ提携サービスが指定の形式で使用できるように、セカンダリ提携サービスに権限を委譲することが可能であり、そうであれば、セカンダリサービスは、適切な要求(たとえば、セカンダリサービス、プライマリカスタマサービス、必要な情報のタイプ、およびオプションで、プライマリカスタマサービスの固有のコブランディング情報を指示する要求)をアクセスマネージャに送ることにより、そのようなコブランディング情報の使用権を得ることが可能である。アクセスマネージャは、セカンダリサービスがそのコブランディング情報の使用を許可されたことを確認すると、そのコブランディング情報(または、セカンダリサービスがそのコブランディング情報を取得するために使用できる情報)を返す。
【0026】
図3A〜3Bは、カスタマサービスの代理としてのアクセスマネージャからユーザに提供される、カスタマイズされたサインオンプロセスの例を示す。具体的には、図3Aは、サービスのユーザに対して表示される、カスタマサービスに合わせてカスタマイズされた最初のサインオンページを示している。この例では、サインオンページは、比較的低レベルのパーミッションを有するカスタマ(または、高レベルのパーミッションに関連付けられたカスタマイズを含めることを選択していないカスタマ)向けに、アクセスマネージャ機能性のプロバイダによって生成されることが可能である。この例では、カスタマロゴ301およびカスタマイメージ303が、コブランディングカスタマイズに従って表示され、アクセスマネージャまたはアクセスマネージャを提供するエンティティのロゴ305も表示されている。他の実施形態では、ロゴ305は使用されなくてよい。指示情報307は、(たとえば、ユーザの、アカウントマネージャプロバイダのアカウントに基づいて)アカウントマネージャプロバイダに関するサインオン情報を使用してサインオンプロセスを開始するように、ユーザに通知する。そのサインオン情報は、ユーザによって、しかるべき場所309に入力されることが可能である。さらに、カスタマの使用条件およびカスタマのプライバシポリシーへのアクセスを提供する、カスタマイズされたリンク313が表示されている。さらに、サインオン情報を送るための様々なユーザ選択可能コントロール311も提示されている。
【0027】
図3Bは、このサービスの少なくとも一部のユーザ(たとえば、このカスタマサービスへのサインオンが初めてであるユーザや、指定の条件を満たす後続のサインオン試行を行うユーザ)に対して表示される、カスタマサービスに合わせてカスタマイズされたサインオンプロセスの後続のページを示している。具体的には、この例では、このページは、カスタマによって指定された質問325を行うことによって、カスタマイズされたタイプの情報収集を実行するために提供される。そのような質問としては、出荷先アドレス、電話番号、および他の、ユーザの連絡先情報があり、これらに限定されない。カスタマロゴ321は、情報収集ページの一部として表示可能な、様々なタイプのコブランディングの一例を示している。これは、図3Aのロゴ301であっても、カスタマ固有のロゴであってもよい。さらに、指示情報323をユーザに対して表示して、デフォルトの質問であれ、カスタマサービスによって指定された質問であれ、質問に答えるよう、ユーザに通知することが可能である。質問によっては、(たとえば、電話番号327のように)カスタマによって指定された、カスタマイズされたデータ形式を示すことも可能である。実施形態によっては、クライアントサイドスクリプティング(たとえば、Java(登録商標)Script)を使用して、許容できる値について任意の指定された制限を設けることが可能であり、また、質問のいくつかがユーザに対して行われるべきかどうかを決定する、指定された論理を実装することも可能である。ユーザがカスタマにサインオンするたびに、他の一度きりの情報収集が実行されない場合でも、追加の質問329をユーザに対して行うことが可能である。ユーザは、質問に答え終わったら、ユーザ選択可能コントロールを使用して、その情報を送信することが可能である331。
【0028】
サインオンおよび情報収集は、様々な実施形態において様々な形式で行われることが可能である。たとえば、図3Aおよび3BはWebページを示しているが、実施形態によっては、プログラム的にアクセスされるインターフェースを含め、他のインターフェースを利用することも可能である。さらに、ユーザの情報を収集する際に複数のページを使用することが可能であり(特に、ユーザがカスタマに初めてサインオンする場合)、ユーザインターフェース内で様々なユーザインターフェースウィジェットを使用することが可能である。
【0029】
ここでは図示されていないが、カスタマイズされたサインオンプロセスおよび他のタイプのカスタマイズされたユーザ対話は、他の様々な状況および形式でも使用されることが可能である。たとえば、図3Aおよび3Bでは、カスタマイズ手法は、1つまたは複数のWebページの一部として使用されるものとして示されているが、1つまたは複数の電子メールメッセージ(たとえば、HTML形式で指定された電子メールメッセージ)または他のタイプの、エンドユーザに送られる電子メッセージのような、他の様々なタイプのメッセージおよび情報も、同様にカスタマイズされることが可能である。さらに、カスタマイズ手法は、検索エンジンの出力や、ソーシャルネットワーキングサービスで与えられる情報のような、ユーザに提供される他の様々なタイプの情報をコブランディングするために使用されることも可能である。
【0030】
図4は、アクセスマネージャコンピューティングシステム400、ならびに、様々なユーザコンピューティングシステム450、提携サービスコンピューティングシステム490、およびカスタマサービスコンピューティングシステム470の例示的実施形態を示すブロック図である。図示された実施形態では、アクセスマネージャコンピューティングシステムは、CPU 405、各種I/Oコンポーネント410、ストレージ430、およびメモリ420を含んでおり、I/Oコンポーネントは、ディスプレイ411、ネットワークインターフェース412、コンピュータ可読媒体ドライブ413、および他のI/Oデバイス415を含んでいる。
【0031】
アクセスマネージャシステム423およびアカウントマネージャシステム428の実施形態は、メモリ420内で実行されており、これらは、ネットワーク480を介して(たとえば、インターネットおよび/またはワールドワイドウェブを介して)他のコンピューティングシステムと対話する。ユーザらは、最初に、アカウントを確立して使用するために、(たとえば、各ユーザがユーザコンピュータシステムのメモリ457内で実行されているブラウザ458を使用して)アカウントマネージャシステムと対話することが可能であり、これは、たとえば、ストレージ430上のユーザアカウントデータベース432データ構造に格納されているサインオン情報、連絡先情報、金銭情報などを指定するためであり、実施形態によっては、アカウントマネージャシステムおよび/または1つまたは複数の他の提携システム(図示せず)がさらに、様々なタイプの機能性(オンラインショッピング機能性、メッセージングサービス機能性、情報アクセス機能性など)をユーザに提供することが可能である。アクセスマネージャシステム423の図示された実施形態は、様々な機能性を提供するために複数のマネージャコンポーネントを含んでおり、それらには、カスタマ登録マネージャコンポーネント421、ユーザ対話マネージャコンポーネント422、信用証明書マネージャコンポーネント424、カスタマステータスマネージャコンポーネント425、カスタマ検証マネージャコンポーネント426などが含まれるが、他の実施形態では、これらのマネージャコンポーネントの機能性は、他の形式で編成されてもよい。カスタマ登録マネージャコンポーネントは、サービスの運営者および他の担当者と対話することにより、それらのサービスをアクセスマネージャシステムのカスタマとして登録し、サービスのユーザに提供されるサインオン機能性および他の機能性をカスタマイズし、カスタマによって提供される情報は、ストレージにあるカスタマ情報データベース440データ構造に格納される。カスタマになる見込みのあるサービスがカスタマとして登録されると、1人または複数のユーザが、カスタマサービスコンピューティングシステムによって提供されるサービスおよび他の機能性と対話することが可能であり、カスタマサービスへのサインオンを実行するために、アクセスマネージャシステムにダイレクトされることが可能である。次に、ユーザ対話マネージャコンポーネントは、ユーザと対話して、たとえば、前に保存されたユーザアカウント情報に基づいて、かつ/または、(直接であれ、ユーザをアカウントマネージャシステムと対話することにリダイレクトすることによってであれ)ユーザをアカウントマネージャシステムの新しいユーザとして登録することに基づいて、カスタマサービスのカスタマイズされたサインオンプロセスを提供する。さらに、実施形態によっては、ユーザ対話マネージャコンポーネントは、ユーザに関する様々な情報を、カスタマイズされた形式で収集し、その情報を、収集済みユーザ情報データベース436データ構造に格納する。サインオン試行が成功した場合、信用証明書マネージャコンポーネントは、ユーザを表す信用証明書を生成し、その信用証明書情報を、ストレージにある信用証明書データベース438データ構造に格納し、(たとえば、カスタマサービスへリダイレクトバックされるユーザへの応答として)カスタマサービスのコンピューティングシステムのストレージ471に信用証明書473として格納するため、ならびに、オプションで、ユーザに関して収集されたすべての情報を提供するために、その信用証明書をカスタマサービスに返す。
【0032】
次に、カスタマサービスが、アカウントマネージャシステムおよび/またはアクセスマネージャシステムと対話して、ユーザを表す信用証明書を提供することなどにより、ユーザの代理として様々なアクションを実行すること(たとえば、ユーザのアカウント情報を修正および/または使用すること)が可能である。状況によっては、カスタマサービスがユーザを、提携サービスコンピューティングシステムによって提供されている提携サービスにダイレクトすることが可能であり、この場合は、ユーザに関してカスタマサービスに発行された信用証明書が、提携サービスに与えられ、提携サービスコンピューティングシステムのストレージ491上に信用証明書493とともに格納される。次に、ユーザは、オプションで、ユーザの代理としてアクションを実行するアクセスマネージャシステムおよび/またはアカウントマネージャシステムと対話するために、提携サービスによって同様にリダイレクトされることが可能である。カスタマサービス(またはその担当者)はさらに、カスタマステータスマネージャコンポーネントと対話して、(サービス自身の、アクセスマネージャシステムにおけるカスタマアカウントに関する情報、および収集済みユーザ情報データベースにある収集済みユーザ情報を含む)サービスに関する様々な情報を取得することが可能である。さらに、少なくとも一部の実施形態では、アクセスマネージャシステムおよびアカウントマネージャシステムが、カスタマサービスのユーザのアクションに関する様々なタイプの情報を追跡および提供する、さらなるカスタマイズされた機能性を提供することを、いくつかのカスタマサービスのそれぞれが要求することが可能であり、これは、たとえば、カスタマサービスが自身のサインオンサービスを実装していたとすれば有するであろうユーザ関連情報のほとんどまたはすべてを、カスタマサービスが利用できるようにするためである。その場合、そのようなユーザ情報は、代替ユーザプールデータベース434データ構造に格納され、カスタマステータスマネージャコンポーネントによって、それらのカスタマサービスが利用できるようにされるが、他のユーザ(または、他のサービスと対話している場合の同じユーザ)に関する同様の詳細情報は、図示された実施形態では、それらのカスタマサービスが利用できるようにはされない。
【0033】
少なくとも一部の実施形態では、カスタマサービスとアクセスマネージャシステムおよび/またはアカウントマネージャシステムとの対話に関する様々な追加セキュリティ対策を与えるために、カスタマ検証マネージャコンポーネントが使用される。具体的には、そのような実施形態では、カスタマサービスからの少なくともいくつかのメッセージが、メッセージ内の情報に基づいて、そのサービスおよびカスタマ検証マネージャコンポーネントに知られている秘密アクセス鍵(たとえば、サービスの初期登録時に決定され、サービス情報データベース440に格納されている秘密アクセス鍵)を使用して生成されたデジタル署名を含まなければならず、そのようなデジタル署名は、図示された実施形態では、カスタマサービスのコンピューティングシステム470のメモリ477内で実行されている署名ジェネレータコンポーネント478により、カスタマサービスの秘密アクセス鍵(図示せず)を使用して、カスタマサービスによって生成される。その場合、カスタマ検証マネージャコンポーネントは、他のシステムまたはコンポーネントが、受け取ったメッセージに応答する前に、そのメッセージを認証するために、含まれるデジタル署名を検証する(これは、たとえば、カスタマ検証マネージャコンポーネントに知られている、そのカスタマの秘密アクセス鍵を使用して、一致する別のデジタル署名を生成することにより、デジタル署名を複製することによって行われる)。そのようなメッセージ認証はさらに、少なくとも一部の実施形態および状況においては、少なくとも一部の提携サービスに対して実行されることも可能である。さらに、実施形態によっては、他のタイプのメッセージも、1つまたは複数の関連するサービスの秘密アクセス鍵を使用して同様にデジタル署名されることが可能であり、そのデジタル署名に基づいて認証されることが可能である。たとえば、このようなメッセージとして、受信者サービスによって認証される、アクセスマネージャシステムおよび/またはアカウントマネージャシステムからカスタマサービスまたは提携サービスへのメッセージや、(サービスが他のサービスの秘密アクセス鍵にアクセスできない場合に)カスタマ検証マネージャコンポーネントの支援によって認証される、カスタマサービスと提携サービスとの間のメッセージなどがある。
【0034】
図示されたコンピューティングシステムは、例に過ぎず、本発明の範囲を限定するものではないことを理解されたい。アクセスマネージャコンピューティングシステム400は、インターネットやウェブのような1つまたは複数のネットワークを介することを含め、図示されていない他のデバイスと接続されることが可能である。より一般的には、各種コンピューティングシステムのそれぞれは、説明された形式で対話を行うことが可能なハードウェアおよびソフトウェアの任意の組合せを備えることが可能であり、それらには、コンピュータ、ネットワークデバイス、インターネット電気器具、PDA(「携帯情報端末」)、携帯電話、ページャ、電子手帳、テレビベースのシステム、および他の、相互通信機能を含む様々なコンシューマ製品などが含まれる。さらに、図4に示されたアクセスマネージャシステムコンポーネントによって提供される機能性は、実施形態によっては、より少ないコンポーネントの組合せであったり、別の複数のコンポーネントに分散されたりすることが可能である。同様に、実施形態によっては、図示されたコンポーネントのうちのいくつかの機能性が提供されない場合があり、かつ/または、他の追加の機能性が利用できる場合がある。
【0035】
これも当業者であれば理解されるように、様々なアイテムがメモリ内またはストレージに格納されて使用されているように図示されているが、これらのアイテムまたはその一部は、メモリ管理およびデータ保全のために、メモリと他のストレージデバイスとの間で転送されることが可能である。代替として、他の実施形態では、ソフトウェアコンポーネントの一部またはすべてが、別のデバイスのメモリ内で実行され、相互コンピュータ通信により、図示されたコンピューティングシステムまたはデバイスと通信することが可能である。アクセスマネージャシステムコンポーネントまたはデータ構造の一部またはすべてがさらに、(たとえば、命令または構造化データとして)ハードディスク、メモリ、ネットワーク、または適切なドライバによって読み取られる可搬物のような、コンピュータ可読媒体に格納されることが可能であってよい。また、アクセスマネージャコンポーネントおよびデータ構造は、無線ベースおよび有線/ケーブルベースの媒体を含む、様々なコンピュータ可読伝送媒体上に(たとえば、搬送波の一部として)生成されたデータ信号として、伝送されることが可能である。したがって、本発明は、他のコンピュータシステム構成でも実施されることが可能である。
【0036】
図5は、カスタマ登録マネージャルーチン500の例示的実施形態のフロー図である。このルーチンは、サービスの運営者および他の担当者と対話して、サービスのユーザに提供されるサインオン機能性および他の機能性をカスタマイズするなどのために、たとえば、図4のカスタマ登録マネージャコンポーネント421の実行によって与えられることが可能である。
【0037】
このルーチンはステップ505から始まり、ステップ505では、サービスの運営者または他の担当者から、サービスをカスタマとしてアクセスマネージャに登録する指示を受け取る。ステップ505の後、ルーチンは、ステップ510で、サービス(たとえば、Webサイトによって提供されるサービス、またはWebサイトの一部としてのサービス)に関する情報を受け取る。これは、たとえば、(たとえば、図2Aに示されたような)情報を尋ねるページを表示することによる対話形式で、または、プログラム的にアクセスされるAPIの一部として、受け取られる。ステップ510で情報が受け取られた後、ルーチンは、そのカスタマを受け入れるかどうかを、たとえば、(ステップ510で取得された情報を用いて)そのサービスおよび/または運営者が十分信用できると判断されるかどうかに基づいて、かつ/または他の基準に基づいて、決定する。カスタマが受け入れられない場合、ルーチンは、ステップ520に進み、登録拒否メッセージを送信し、その後、ステップ590に進む。カスタマが受け入れられる場合、ルーチンは、ステップ530で、たとえば、そのサービスおよび/または運営者に関して評価された信頼度に基づいて、かつ、オプションで、(たとえば、サービスのタイプ、サービスのユーザ数、カスタマが使用することを可能にされているコブランディングおよび/または他のカスタマイズのタイプ(たとえば、カスタマが実効可能コードを指定して使用することを許可されているかどうか)、などに基づく)サービスのアクションの結果である、アクセスマネージャの何らかの不利益、過去の、アクセスマネージャとカスタマとの間の何らかのエクスペリエンス、その他の要因に基づいて、カスタマに付与するパーミッションのレベルを決定する。さらに、実施形態によっては、カスタマが、(たとえば、プレミアムサービスの一環として)より高いレベルのパーミッションを受け取り、したがって、追加の機能性を得るために、より多くの料金を課せられることが可能である。割増料金は、機密ユーザ情報を、許可されていないユーザにさらすことや、許可されていないユーザが、ユーザの代理として、金銭取引または他の操作を行うことを許すことなどにより、アクセスマネージャを不利益にさらすことになる、カスタマの能力および/または可能性に、少なくとも部分的に基づくことが可能である。少なくとも一部の実施形態では、カスタマのパーミッションのレベルは、後で見直しおよび変更されることが可能である。ステップ530でパーミッションのレベルが決定された後、ルーチンは、付与されたパーミッションに応じて、カスタマが何らかのブランドを構成することを許可するかどうかを決定し、許可する場合は、カスタマがそのようなブランドを有するかどうかを判定する。有する場合、ルーチンは、ステップ540に進み、ブランドを適宜構成する。
【0038】
有しない場合、またはステップ540の後、ルーチンは、ステップ545に進み、決定されたパーミッションレベルに従って、カスタマが利用できるコブランディングカスタマイズのタイプを(たとえば、それらのブランドのうちの1つ目について、かつ/またはすべてのブランドについて(ブランドがステップ540で構成済みの場合))表示する。実施形態によっては、この表示は、Webページであってよく、図2Bおよび/または2Cのユーザインターフェースと同様のユーザインターフェースを含んでよい。利用可能なコブランディングカスタマイズのタイプを表示した後、オプションで、コブランディングカスタマイズの1つまたは複数の指示を、ステップ550で、ルーチンが受け取り、後で使用するために保存する。実施形態によっては、複数のページまたは他の複数の情報群がコブランディングされることが可能な場合、各ページは、別々に構成されてよい。ステップ555で、決定されたパーミッションレベルに従って、カスタマが利用できる情報収集の定義済みタイプを表示し、オプションで、情報収集のカスタマイズの1つまたは複数の指示を、ステップ560で受け取り、後で使用するために保存する。ステップ565で、決定されたパーミッションレベルに従って、カスタマが利用できる権限委譲の定義済みタイプを表示し、オプションで、権限委譲のカスタマイズの1つまたは複数の指示を受け取り、後で使用するために保存する。ステップ568で、複数のブランドが構成済みであって個別にカスタマイズされる場合、ルーチンは、ステップ545に戻って、次のブランドの構成を開始し、そうでない場合、ルーチンは、ステップ570に進み、必要に応じて追加処理を実行する(たとえば、様々な情報を適切なデータストアに格納したり、一意識別子および秘密アクセス鍵を生成してカスタマに与えたりする)。次に、ルーチンは、ステップ590に進み、続行するかどうかを決定する。続行する場合、ルーチンは、ステップ505に戻り、続行しない場合はステップ599で終了する。
【0039】
図示されたルーチンは、代替実施形態では、別の方法で実行されることが可能である。たとえば、このルーチンは、各ブランドが複数のタイプのカスタマイズに関して構成されることが可能であることを示しているが、実施形態によっては、ブランドは、個別に構成されたコブランディングカスタマイズを有することのみが可能であってよい。他の実施形態では、カスタマイズは、異なる順序で指定されることが可能であり、アクセスマネージャカスタマが特定タイプのカスタマイズを構成するパーミッションを有しない場合は、そのタイプのカスタマイズに関連するステップがスキップされてよい。たとえば、カスタマがユーザから情報を収集するパーミッションを有しない場合、ルーチンは、ステップ550から565をスキップしてよい。ここでは図示されていないが、実施形態によっては、ルーチンは、他の様々なセキュリティ情報および/またはメカニズムを追加で使用することが可能であり、これは、たとえば、カスタマの担当者の識別情報を検証するためである。
【0040】
図6は、ユーザ対話マネージャルーチン600の例示的実施形態のフロー図である。このルーチンは、たとえば、図4のユーザ対話マネージャコンポーネント422の実行によって与えられることが可能であり、たとえば、カスタマサービスによって指定される、カスタマイズされたサインオンプロセスを提供するために、カスタマサービスの代理としてユーザと対話することが可能である。
【0041】
ステップ605で、ルーチンは、カスタマイズサービスの代理として、ユーザに関する(たとえば、ユーザがサービスにサインオンすることの)要求の通知を受け取る。図示された実施形態では、この要求は、カスタマに関連付けられたカスタマ識別子と、カスタマに固有の形式で生成された、この要求に対するデジタル署名とを含む。次に、要求に添付されたデジタル署名は、(図9Bに示されるように)カスタマ検証マネージャルーチンによってチェックされ、ステップ610で、有効ではないと判定された場合には、ルーチンはステップ680に進み、失敗通知を送信して、ステップ690に進む。署名が有効であれば、ルーチンは、ステップ615に進み、要求のタイプを決定する。要求がサインオン以外の何かであれば、要求された操作は、ステップ685で適宜実行される。要求がサインオン要求であれば、受け取られたカスタマ識別子に関連付けられたカスタマに関して既に構成されたカスタマイズを、ステップ620において取り出し、ステップ625で、カスタマイズされたコブランディングがなされたコンテンツを有するサインオンページを生成して、ユーザに送る。次に、ステップ630で、ルーチンは、ユーザがアクセスマネージャにアカウントを有するかどうかを判定し、有しない場合、ルーチンは、ステップ640で、ユーザに関する情報を取得し、ユーザをアクセスマネージャに登録する。ユーザが既にアクセスマネージャプロバイダにアカウントを有する場合は、ステップ635で、ユーザからサインオン情報を受け取り、ステップ645で、サインオン情報が有効かどうか(たとえば、そのユーザについて保存されているサインオン情報と一致するかどうか)を判定する。サインオン情報が有効でない場合、ルーチンは、ステップ680に進み、失敗通知をユーザに送る。
【0042】
サインオン情報が有効な場合、またはステップ640の後、ステップ650で、信用証明書または他の、ユーザのサインオンが有効であることの通知を生成して、サービスに渡す(または、他の実施形態では、ユーザが(たとえば、指定された期間に、または他の指示された条件に従って)1つまたは複数のサービスで使用するために、ユーザに渡す)。次に、ルーチンは、ステップ655で、ユーザに関する追加情報(たとえば、ユーザ名、一意識別子、実名など)を取り出してサービスに渡すかどうかを、以前のカスタマイズおよび現在の状況に基づくなどして決定し、渡す場合は、ステップ660に進み、追加情報を適宜取り出す。実施形態によっては、この追加情報を取得するカスタマサービスの機能は、カスタマに付与されたパーミッションのレベルによって制限されることが可能である。ステップ660の後、または追加情報が取り出されなかった場合、ルーチンは、ステップ665で、ユーザに関して収集すべき情報があるかどうかを、以前のカスタマイズおよび現在の状況に基づくなどして決定し、ある場合は、ステップ670に進み、ユーザに関する情報を適宜収集する。ステップ670の後、または情報が収集されなかった場合は、信用証明書およびオプションで他のデータ(たとえば、取り出された情報および/または収集された情報)を、HTTPリダイレクト機能性を用いてユーザ経由で、カスタマに送る。ステップ675、680、または685の後、ルーチンは、ステップ690で、続行するかどうかを決定する。続行する場合、ルーチンは、ステップ605に戻り、続行しない場合はステップ699で終了する。
【0043】
図7は、信用証明書マネージャルーチン700の例示的実施形態のフロー図である。このルーチンは、たとえば、図4の信用証明書マネージャコンポーネント424の実行によって与えられることが可能であり、たとえば、ユーザを表す信用証明書を生成し、他の信用証明書関連アクティビティを実行することが可能である。
【0044】
ルーチンは、ステップ705から始まり、ステップ705で、信用証明書関連の要求を、要求に応じて、外部サービスや別のアクセスマネージャコンポーネントなどから受け取り、この要求は、要求が実行される際に基づく既存の信用証明書を含む追加パラメータを含むことも可能である。要求を受け取った後、ルーチンは、ステップ710に進み、受け取った要求が、サービスのユーザを表す新しい信用証明書を生成することかどうかを、ユーザ対話マネージャコンポーネントに基づくなどして判定する。そうであれば、ルーチンは、ステップ715で、(たとえば、一意の乱数をユーザにマッピングしたり、ユーザに関する情報を取り出して信用証明書の一部として含めたりすることにより)信用証明書を適宜作成し、ステップ770に進み、その信用証明書を保存し、オプションで要求者に渡す。要求が、信用証明書を生成することではなかった場合、ルーチンは、ステップ720で、要求が既存の信用証明書をリフレッシュしてその有効期間を延長することかどうかを、その信用証明書が最初に発行された対象のサービスに基づくなどして判定する。そうであれば、ルーチンは、ステップ722で、要求者が信用証明書をリフレッシュするパーミッションを有するかどうかを(たとえば、要求者に付与されたパーミッションのレベル、および/または信用証明書で表されるユーザによって(たとえば、サービスへのサインオンの際に)指定された情報に基づいて)判定する。パーミッションが存在する場合は、ルーチンは、ステップ724で、信用証明書をリフレッシュしてから、ステップ770に進む。ユーザの信用証明書をリフレッシュするのに十分なパーミッションがない場合、ルーチンは、ステップ729でエラーメッセージを通知し、ステップ795に進む。
【0045】
ステップ720で、要求が、信用証明書をリフレッシュすることではないと判定された場合、ルーチンは、ステップ730に進み、(たとえば、セカンダリ提携サービスからの、セカンダリ提携サービスが提携しているプライマリカスタマサービスに発行された、ユーザに関する信用証明書の使用権を取得する要求のように)要求が既存の信用証明書をクローニングすることかどうかを判定する。そうであれば、ルーチンは、ステップ732に進み、信用証明書のクローニングが許可されているかどうかを、プライマリサービスからセカンダリサービスに委譲された権限に基づくなどして判定する。さらに、実施形態によっては、ユーザを表す信用証明書のクローニングは、ユーザに対し、情報を提供することと、オプションで、クローニングを承認または他の方法で了解することと、を要求することを必要とする可能性があり、そのような実施形態では、クローニングが許可されているかどうかの判定はさらに、ユーザのアクションに少なくとも部分的に基づくことが可能である。ステップ732で、パーミッションが存在すると判定された場合、ルーチンは、ステップ734で、信用証明書をクローニングして、ステップ770に進み、パーミッションが存在しないと判定された場合、ルーチンは、ステップ739で、エラーが発生したことの通知を送信し、ステップ795に進む。
【0046】
ステップ730で、要求が、信用証明書をクローニングすることではないと判定された場合、ルーチンは、ステップ740に進み、要求が、信用証明書が有効かどうかを検証することかどうかを判定する。そうであれば、ルーチンは、ステップ745で、信用証明書が要求者にとって(かつオプションで、指示されたアクションにとって)現時点で有効かどうかを判定し、信用証明書の有効性の通知を要求者に送る。要求が、信用証明書が有効かどうかを判定することではなかった場合、ルーチンは、ステップ750で、要求が、信用証明書の期限がいつ切れるかを判定することかどうかを判定する。そうであれば、ルーチンは、ステップ755で、期限切れを判定し、それを要求者に通知し、そうでない場合、ルーチンは、ステップ760に進み、他のタイプの要求に適宜応答する。ステップ729、739、745、755、760、または770の後、ルーチンは、ステップ795で、続行するかどうかを決定する。続行する場合、ルーチンは、ステップ705に戻り、続行しない場合はステップ799で終了する。
【0047】
図8は、カスタマステータスマネージャルーチン800の例示的実施形態のフロー図である。このルーチンは、たとえば、図4のカスタマステータスマネージャコンポーネント425の実行によって与えられることが可能であり、たとえば、様々なタイプの情報をカスタマに提供することが可能である。
【0048】
ルーチンは、ステップ805から始まり、ステップ805では、カスタマから要求を受け取る。ステップ810で、ルーチンは、要求が許可されているかどうかを、たとえば、カスタマ検証マネージャコンポーネントと対話することにより、かつ/またはカスタマに付与されたパーミッションのレベルに基づいて、判定する。許可されていない場合、ルーチンはステップ895に進み、許可されている場合は、ステップ815〜860で、様々なタイプの情報を修正することをカスタマが要求したかどうかを判定し、要求した場合は、その修正を適宜実行する。図示された実施形態においてカスタマによって修正されることが可能な情報のタイプとして、コブランディングのカスタマイズ(ステップ815および820)、情報収集のカスタマイズ(ステップ825および830)、権限委譲のカスタマイズ(ステップ835および840)、ブランド(ステップ845および850)、およびカスタマアカウント情報(ステップ855および860)がある。受け取られた要求が、情報を修正することではない場合、ルーチンは、ステップ865で、要求が、ユーザを監視することかどうかを判定する。そうであれば、ルーチンは、ステップ870で、あらかじめ追跡されたユーザ情報を取り出してカスタマに提供し、そうでない場合、ルーチンは、ステップ875に進み、他の要求された機能性を適宜実行する。ステップ820、830、840、850、860、870、および875の後、または、ステップ810で、要求が許可されていないと判定された場合、ルーチンは、ステップ895に進み、続行するかどうかを決定する。続行する場合、ルーチンは、ステップ805に戻り、続行しない場合はステップ899で終了する。
【0049】
図9Aおよび9Bは、受け取ったメッセージを認証するルーチンの例示的実施形態のフロー図であり、図9Bは、検証マネージャルーチン925の例示的実施形態を示しており、図9Aは、対応するクライアントサイド検証ルーチン900を示している。検証マネージャルーチンは、たとえば、図4のカスタマ検証マネージャコンポーネント426の実行によって与えられることが可能であり、たとえば、カスタマサービスおよび他のサービスからの着信メッセージに関する様々な追加セキュリティ対策を与えることが可能である。クライアントサイド検証ルーチンは、たとえば、カスタマサービスのコンピューティングシステムと図4の署名ジェネレータコンポーネント478との組合せによって与えられることが可能であり、たとえば、アクセスマネージャへの送信メッセージに対して追加セキュリティ対策を行うことが可能である。
【0050】
図9Aのクライアントサイドルーチン900は、ステップ905から始まり、ステップ905では、様々な情報を含めるべき送信メッセージを生成する指示をカスタマサービスから受け取り、セキュリティのためにメッセージに添付するカスタマ固有のデジタル署名を生成する際に用いる様々な情報を収集する。実施形態によっては、署名の生成に使用される情報は、メッセージ内容の少なくとも一部と、秘密アクセス鍵のような、メッセージに含まれない他の情報とを含む。さらに、実施形態によっては、署名の生成に使用する情報に、(たとえば、メッセージが傍受された場合に後で再利用されることを避けるための)現在のタイムスタンプのような、他の情報を追加することが可能である。送られるメッセージは、様々な形式を有することが可能であり、たとえば、URLまたは他のURI(「統一資源識別子(Uniform Resource Identifier)」)を使用して送られるHTTP要求であって、メッセージ内容が1つまたは複数のクエリ文字列パラメータ値の一部として含まれ、デジタル署名が別のクエリ文字列パラメータの値として含まれる、HTTP要求の形式を有することが可能である。ステップ910で、ルーチンは、収集された情報に基づいてデジタル署名を生成する。これは、たとえば、あらかじめ選択されたデジタル署名アルゴリズムを使用し、あらかじめ選択されたタイプのメッセージ情報(たとえば、特定の順序の特定のメッセージパラメータ値)を使用することによって行われる。ステップ915で、ルーチンは、署名をメッセージに追加してからメッセージを送信し、次の署名付きメッセージが送られるまで、ステップ920で終了する。
【0051】
図9Bの検証マネージャルーチン925は、ステップ927から始まり、ステップ927では、着信メッセージの検証の要求(たとえば、カスタマサービスまたは提携サービスから受け取ったメッセージに関して、アクセスマネージャシステムまたはそのコンポーネントの1つから受け取った要求)を受け取る。ステップ930で、ルーチンは、最初に、メッセージが十分に最近のものかどうかを、たとえば、メッセージに添付されているタイムスタンプからの経過時間が所定時間を超えていないかどうかに基づいて、判定する。タイムスタンプが古すぎる場合、ルーチンは、ステップ970で、署名が無効であることの通知を送信し、オプションで、ステップ975で、追加の処理を適宜実行する(たとえば、無効なメッセージのパターンが見つかった場合は通知を生成する)。その後、ルーチンはステップ995に進む。
【0052】
タイムスタンプが十分に最近のものであった場合、ルーチンは、ステップ935に進み、受け取ったメッセージの送信元であるカスタマに対応する、保存されていた秘密アクセス鍵を、メッセージに含まれていて、その秘密アクセス鍵に関連付けられている、そのカスタマに割り当てられた識別子に基づくなどして、取り出す。他の実施形態では、カスタマサービスまたは他の提携サービスは、受け取られた要求の送信元のIPアドレスに基づくなど、他の方法で識別されることが可能である。ステップ935で、秘密アクセス鍵およびカスタマに関する任意の追加情報を取り出した後、ルーチンは、図9Aのステップ905および910に関して前述されたものと同じ方法で、ステップ940および945で、メッセージのデジタル署名を生成する。これは、たとえば、(デジタル署名を含まない)メッセージに含まれた情報および取り出された秘密アクセス鍵を使用するためである。ステップ950で、新しく生成した署名を、メッセージに含まれている署名と照合する。ステップ955で、その2つのデジタル署名が同じであると判定した場合は、メッセージを検証し、ステップ960で、対応する確認を送信する。メッセージが正しいことが立証されない場合は、メッセージを偽造と見なし、ステップ965で、対応する通知を送信する。ステップ960、965、または975の後、ルーチンは、ステップ995に進み、続行するかどうかを決定する。続行する場合、ルーチンは、ステップ927に戻り、続行しない場合はステップ999で終了する。
【0053】
ここでは図示されていないが、実施形態によっては、アクセスマネージャからのメッセージを検証するために、同様の手法がサービスによって用いられてよい。さらに、様々な実施形態が、図9Aおよび9Bに示された署名ベースの検証より強力な、追加のセキュリティ機能およびメカニズムを有してよく、これは、たとえば、サービスの担当者が最初にサービスを登録した場合に、その担当者の身元に関する情報を収集することである。
【0054】
このように、様々な手法を用いて、カスタマイズ可能なサインオン機能性および他の機能性をサービスに提供することが可能であり、また、様々な手法を用いて、対話のセキュリティを強化することが可能である。さらに、実施形態によっては、さらに様々な情報および手法を用いることが可能である。たとえば、アクセスマネージャのカスタマが、Webサイト(電子商取引サイトなど)を含むことが可能であり、アクセスマネージャのプロバイダに無関係であることが可能である。アクセスマネージャによってカスタマに付与されるパーミッションのレベルは、たとえば、未知のサイトよりは、よく知られ、評価の高いサイトに、より高いレベルのパーミッションを付与するというように、一定でなくてもよい。さらに、低レベルのコブランディングパーミッションは、使用するイメージおよびテキストを指定することをアクセスマネージャカスタマに許可することだけが可能であるが、高いレベルのパーミッションを有するアクセスマネージャカスタマは、イメージ、イメージマップ(ユーザがイメージの任意の部分または指定部分を選択したときに機能性を提供する)、指定されたタイプのユーザ選択可能機能性(たとえば、ドロップダウンボタンを有する見出し)、テキスト、リンク、バックグラウンドミュージック、Java(登録商標)Scriptコード、Flashアニメーション、Shockwaveムービー、Java(登録商標)アプレット、カスタムCSS(「カスケーディングスタイルシート」)スタイルなどを追加することが可能である。実施形態によっては、パーミッションの付与は、リアルタイムまたはほぼリアルタイムのプロセスで自動的に行われるが、他の実施形態では、このプロセスは(たとえば、サービスの手動見直しを考慮に入れるために)より時間がかかる可能性がある。さらに、実施形態によっては、カスタマに付与されるパーミッションのレベルは、(たとえば、定期的に)見直しおよび修正されることが可能である。たとえば、カスタマに関して問題または懸念が持ち上がった場合は、パーミッションのレベルを下げることが可能である。逆に、そのような問題が発生していない場合は、パーミッションのレベルを上げることが可能である。たとえば、一部またはすべての新規カスタマに低レベルのパーミッションを付与し、カスタマとの継続的なエクスペリエンスによって保証される場合はパーミッションのレベルを徐々に上げていくことが可能である。たとえば、カスタマによる、またはカスタマの代理でのトラフィックおよび/または利用パターンの分析または見直しに基づいて、パーミッションのレベルを上げることが可能である。実施形態によっては、付与されたパーミッションのレベルの見直しは、外部要因(たとえば、カスタマに関するニュースまたはカスタマに起こった変化(たとえば、カスタマの合併または買収、破産など))によってトリガされる場合がある。
【0055】
様々なタイプのサービスが、提携サービスとして行われることが可能であり、そのようなサービスとして、支払処理、クレジットカード検証サービス、コンシューマ調査サービス、広告サービス、履行サービスなどがあり、これらに限定されない。また、実施形態によっては、アクセスマネージャのプロバイダが、そのサービスのいくつかを提携サービスとして提案してもよい。提携サービスは、場合によっては、カスタマまたはユーザがそれぞれのサービスの提供を容易にするための情報のサブセットへのアクセス権を与えられることが可能であり、たとえば、コンシューマ調査サービスは、特定の製品がいつコンシューマに出荷されたか、ならびに、製品およびサービスに関してコンシューマの追跡を実行するための連絡先情報を知ることが必要であろう。
【0056】
サービスからアクセスマネージャへ送られるメッセージまたは他の要求は、様々な実施形態において様々な形式をとることが可能である。実施形態によっては、要求が、クエリ文字列として渡されるメッセージパラメータまたは他のコンテンツを有するHTTPメッセージであることが可能であり、少なくとも一部の情報(たとえば、秘密アクセス鍵、機密のユーザサインオン情報および他のユーザ情報など)が、好ましくは、セキュアな手段(たとえば、セキュアHTTP)または(たとえば、物理メール、電話などを介する)オフライン形式で送られる。同様に、ユーザのサインオン情報または他の識別情報が、様々な形式を有することが可能であり、たとえば、ユーザ名およびパスワード、各種バイオメトリック情報、PKIベースの情報などの形式を有することが可能である。実施形態によっては、信用証明書は、Webブラウザのクッキーとして、または、代替として、WS−Federation Passive Profileで指定される形式(たとえば、WS−Trust RequestSecurityTokenResponse XML要素)で、または別のサインオン仕様標準に基づいて(たとえば、Liberty Alliance ProjectやMicrosoftのPassportサービスなどに基づいて)、交換されることが可能である。同様に、実施形態によっては、サインオンプロセスが、様々な方法で(たとえば、WS−Federation Passive Requestor Profileで指定されたプロセスで)実行されることが可能である。
【0057】
前述のように、実施形態によっては、少なくとも一部のカスタマサービスが、(たとえば、様々なタイプの、ユーザとの対話を追跡するために)代替データプールの開設および使用を、サービスのユーザの代わりに要求することが可能である。たとえば、代替データプールは、購入、表示された製品またはサービス、ログイン時刻、行われた情報修正、さらに場合によっては、カスタマサービスに固有ではない、ユーザの履歴や他のアクティビティの情報などの、ユーザに関する情報を格納することが可能であり、実施形態によっては、カスタマが、どのようなデータを代替データプールに格納するかを構成することを許可されることが可能である。実施形態によっては、カスタマが代替データプールを利用できるかどうかは、カスタマに付与されたパーミッションのレベルに依存することが可能である。
【0058】
実施形態によっては、秘密アクセス鍵を、(たとえば、定期的に、または破損時に)修正または再生成することが可能である。さらに、秘密アクセス鍵の使用方法に関する情報を適正な受信者だけが利用できるように管理することにより、また、さらにオプションで、カスタマごとに異なるプロセスを使用して、セキュリティをさらに強化することが可能である。実施形態によっては、指示されるプロセスは、メッセージに関するパラメータ値が含まれるべき、パラメータのリスト、メッセージパラメータの順序、および使用するエンコードのタイプなどを含むことが可能であり、プロセスが様々な形式でカスタマに指示されることが可能である(たとえば、サービス運営者がサービスにプロセスを手動で組み込む際に使用するドキュメンテーション、プロセスが実行されるように様々な入力を与えられる実行可能コードなどの形式であることが可能である)。デジタル署名は、様々な形式で生成されることが可能であり、たとえば、メッセージ認証コード(たとえば、HMAC(「keyed−Hash Message Authentication Code」)−MD5(「Message Digest algorithm 5」))を使用して生成されることが可能である。
【0059】
当業者であればさらに理解されるように、実施形態によっては、前述の諸ルーチンで与えられる機能性は、別の形式で与えられることも可能であり、たとえば、より多くのルーチンに分割されたり、より少ないルーチンに統合されたりして与えられることも可能である。同様に、実施形態によっては、図示されたルーチンは、説明されたものより多くの機能性または少ない機能性を与える場合があり、それは、たとえば、他の図示されたルーチンがそのような機能性を欠いたり、含んだりする場合や、与えられる機能性の数が変更された場合である。さらに、様々な操作が、特定の形式で(たとえば、シリアルに、またはパラレルに)かつ/または特定の順序で実行されるように示されているが、当業者であれば理解されるように、他の実施形態では、それらの動作が、他の順序で、かつ、他の形式で実行されることが可能である。当業者であればさらに理解されるように、前述のデータ構造は、別の形式で構造化されることも可能であり、これは、たとえば、1つのデータ構造を複数のデータ構造に分割することによって、あるいは、複数のデータ構造を1つのデータ構造に統合することによって可能である。同様に、実施形態によっては、図示されたデータ構造は、説明されたものより多くの情報または少ない情報を格納する場合があり、それは、たとえば、他の図示されたデータ構造がそのような情報を欠いたり、含んだりする場合や、格納される情報の数またはタイプが変更された場合である。
【0060】
以上より理解されるように、本明細書では、例示を目的として特定の実施形態について説明してきたが、本発明の趣旨および範囲から逸脱することなく、様々な修正がなされることが可能である。したがって、本発明は、添付の特許請求項およびその中で記載されている要素によって限定されることを除き、限定されない。さらに、本発明の特定の態様が特定の請求項形式で示されているが、発明者らは、どのような利用可能な請求項形式でも本発明の様々な態様を想定している。たとえば、現時点では、本発明の一部の態様だけが、コンピュータ可読媒体のかたちで具体化されるように記載されているが、他の態様も同様にそのように具体化されることが可能である。
【図面の簡単な説明】
【0061】
【図1A】アクセスマネージャシステム、サービス、およびユーザの間で行われる様々なタイプの対話の例を示す図である。
【図1B】アクセスマネージャシステム、サービス、およびユーザの間で行われる様々なタイプの対話の例を示す図である。
【図1C】アクセスマネージャシステム、サービス、およびユーザの間で行われる様々なタイプの対話の例を示す図である。
【図2A】カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャと、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す図である。
【図2B】カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャと、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す図である。
【図2C】カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャと、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す図である。
【図2D】カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャと、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す図である。
【図2E】カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャと、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す図である。
【図3A】カスタマサービスの代理としてのアクセスマネージャからユーザに提供される、カスタマイズされたサインオンプロセスの例を示す図である。
【図3B】カスタマサービスの代理としてのアクセスマネージャからユーザに提供される、カスタマイズされたサインオンプロセスの例を示す図である。
【図4】アクセスマネージャサーバコンピューティングシステムの例示的実施形態を示すブロック図である。
【図5】カスタマ登録マネージャルーチンの例示的実施形態のフロー図である。
【図6】ユーザ対話マネージャルーチンの例示的実施形態のフロー図である。
【図7】信用証明書マネージャルーチンの例示的実施形態のフロー図である。
【図8】カスタマステータスマネージャルーチンの例示的実施形態のフロー図である。
【図9A】受け取ったメッセージを認証するルーチンの例示的実施形態のフロー図である。
【図9B】受け取ったメッセージを認証するルーチンの例示的実施形態のフロー図である。
【特許請求の範囲】
【請求項1】
コンピューティングシステムにおけるアクセス管理の方法であって、
複数のサービスのうちの第1のサービスの登録を開始するステップと、
前記第1のサービスが利用可能なサインオン機能の動作をカスタマイズするための、アクセスマネージャによって付与されるパーミッションのレベルを、前記アクセスマネージャから決定するステップと、
前記第1のサービスが利用可能な複数のサインオンカスタマイズ機能の通知を、前記パーミッションレベルに少なくとも部分的に基づいて表示するステップと、
前記第1のサービスに関するサインオンカスタマイズの1つまたは複数の選択を受け取るステップと、
前記1つまたは複数の選択と整合性があるサインオンサービスを前記第1のサービスのユーザに提供するステップと、を含むことを特徴とする方法。
【請求項2】
前記利用可能なサインオンカスタマイズ機能は、前記複数のサービスのうちの複数のサービスにおけるサインオン機能のコブランディングを含むことを特徴とする請求項1に記載の方法。
【請求項3】
前記利用可能なサインオンカスタマイズ機能は、情報収集を含むことを特徴とする請求項1および2のいずれかに記載の方法。
【請求項4】
前記アクセスマネージャは、前記複数のサービスを提供する複数のサードパーティWebサイト運営者にシングルサインオンサービスを提供する、方法であって、
ユーザからサインオン要求を受け取るステップと、
前記第1のサービスに関して選択された1つまたは複数のコブランディングカスタマイズを行うような方法で、前記第1のサービスの代理として、前記ユーザに、カスタマイズされたサインオン機能を提供するステップと、
前記第1のサービスに関して選択された1つまたは複数の情報収集タイプのカスタマイズに基づいて、前記ユーザから情報を取得するステップと、をさらに含むことを特徴とする請求項3に記載の方法。
【請求項5】
前記アクセスマネージャにある前記ユーザの有効なアカウントを反映させるために前記第1のサービスを認証するステップと、
前記ユーザを表す信用証明書を第1のサービスに与えるステップと、をさらに含み、前記信用証明書は、前記第1のサービスが、前記ユーザの代理として、前記アクセスマネージャとのアクションを実行することを可能にすることを特徴とする請求項4に記載の方法。
【請求項6】
前記選択されたサインオンカスタマイズを含み、ユーザ名およびパスワードの入力を促すサインオンページを生成するステップと、
前記ユーザに関連付けられた第1のユーザ名および第1のパスワードを受け取るステップと、
前記ユーザの前記アカウントに関する情報と、前記受け取られたユーザ名およびパスワードとの間の一致に少なくとも部分的に基づいて、前記ユーザを認証するステップと、
前記ユーザが認証されたことの通知を前記第1のサービスに送るステップと、をさらに含むことを特徴とする請求項5に記載の方法。
【請求項7】
前記第1のサービスに対する最初のサインオンの場合に、前記サインオンページは、選択された情報収集カスタマイズに基づいて情報の入力を促す、方法であって、前記情報収集カスタマイズに対応する情報を受け取るステップと、前記受け取られた情報を前記第1のサービスに対して利用可能にするステップと、をさらに含むことを特徴とする請求項6に記載の方法。
【請求項8】
前記提供されるサインオンカスタマイズ機能は、前記第1のサービスに関して選択された少なくとも1つの質問に基づく、ユーザからの情報収集を含むことを特徴とする請求項6に記載の方法。
【請求項9】
前記第1のサービスに対する前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスによって通知されるテキストが前記第1のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項2に記載の方法。
【請求項10】
前記第1のサービスに対する前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスによって通知されるリンクが前記第1のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項2に記載の方法。
【請求項11】
前記第1のサービスに対する前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスによって通知される新しいユーザ選択可能機能性が前記第1のサービスのユーザに対して利用可能にされることを可能にすることを含むことを特徴とする請求項2に記載の方法。
【請求項12】
前記第1のサービスに対する前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスに関するイメージが前記第1のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項2に記載の方法。
【請求項13】
前記第1のサービスに対する前記パーミッションレベルを前記決定するステップは、それぞれが異なる信頼度に対応する、複数のあらかじめ定義されたパーミッションレベルのうちの1つを選択するステップを含み、前記選択するステップは、前記第1のサービスに関して取得された複数のタイプの情報を使用して評価された、前記第1のサービスの信頼度に基づくことを特徴とする請求項1に記載の方法。
【請求項14】
前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスが、前記アクセスマネージャを介して、別のサービスに権限を委譲することを可能にすることを特徴とする請求項1に記載の方法。
【請求項15】
請求項1から14に記載の方法のいずれかを実行するコンピュータプログラム。
【請求項16】
コンピューティングシステムにおいてサービスを提供する方法であって、
前記サービスの、アクセスマネージャへの登録を要求するステップと、
前記サービスにおけるサインオン機能の動作をカスタマイズするための、アクセスマネージャによって付与されるパーミッションのレベルを受け取るステップと、
前記パーミッションレベルに少なくとも部分的に基づいて、複数の利用可能なサインオンカスタマイズ機能から1つまたは複数のオプションを選択するステップと、を含み、
前記サービスのユーザとのサインオン対話は、前記選択された1つまたは複数のオプションと整合性があることを特徴とする方法。
【請求項17】
サインオン機能のカスタマイズが正常に終了したことの通知を受け取るステップをさらに含むことを特徴とする請求項16に記載の方法。
【請求項18】
前記利用可能なサインオンカスタマイズ機能は、コブランディングカスタマイズを含むことを特徴とする請求項17に記載の方法。
【請求項19】
前記利用可能なサインオンカスタマイズ機能は、ユーザから情報を収集するプロセスを含むことを特徴とする請求項17に記載の方法。
【請求項20】
前記コンピューティングシステムは、複数のサービスのユーザにサインオン機能を提供するサインオンサービスの代理として動作し、ユーザとの前記対話は、前記サインオンサービスに対して前記ユーザのサインオンを実行するプロセスの一部であることを特徴とする請求項17に記載の方法。
【請求項21】
前記サービスは、前記サインオンサービスとは異なることを特徴とする請求項20に記載の方法。
【請求項22】
請求項16から21に記載の方法のいずれかを実行するコンピュータプログラム。
【請求項23】
コンピューティングシステムにおけるアクセス管理のシステムであって、
複数のサービスのうちの第1のサービスの登録を開始する手段と、
前記第1のサービスが利用可能なサインオン機能の動作をカスタマイズするための、アクセスマネージャによって付与されるパーミッションのレベルを、前記アクセスマネージャから決定する手段と、
前記第1のサービスが利用可能な複数のサインオンカスタマイズ機能の通知を、前記パーミッションレベルに少なくとも部分的に基づいて表示する手段と、
前記第1のサービスに関するサインオンカスタマイズの1つまたは複数の選択を受け取る手段と、
前記1つまたは複数の選択と整合性があるサインオンサービスを前記第1のサービスのユーザに提供する手段と、を備えることを特徴とするシステム。
【請求項24】
前記利用可能なサインオンカスタマイズ機能は、前記複数のサービスのうちの複数のサービスにおけるサインオン機能のコブランディングを含むことを特徴とする請求項23に記載のシステム。
【請求項25】
前記利用可能なサインオンカスタマイズ機能は、情報収集を含むことを特徴とする請求項23および24のいずれかに記載のシステム。
【請求項26】
前記複数のサービスを提供する複数のサードパーティWebサイト運営者にシングルサインオンサービスを提供するシステムであって、
ユーザから複数のサインオン要求を受け取る手段と、
前記第1のサービスに関して選択された1つまたは複数のコブランディングカスタマイズを行うような方法で、前記第1のサービスの代理として、前記ユーザに、カスタマイズされたサインオン機能を提供する手段と、
前記第1のサービスに関して選択された1つまたは複数の情報収集タイプのカスタマイズに基づいて、前記ユーザから情報を取得する手段と、をさらに備えることを特徴とする請求項25に記載のシステム。
【請求項27】
前記アクセスマネージャにある前記ユーザの有効なアカウントを反映させるために前記第1のサービスを認証する手段と、
前記ユーザを表す信用証明書を第1のサービスに与える手段と、をさらに備え、前記信用証明書は、前記第1のサービスが、前記ユーザの代理として、前記アクセスマネージャとのアクションを実行することを可能にすることを特徴とする請求項26に記載のシステム。
【請求項28】
前記選択されたカスタマイズを含み、ユーザ名およびパスワードの入力を促すサインオンページを生成する手段と、
前記ユーザに関連付けられた第1のユーザ名および第1のパスワードを受け取る手段と、
前記ユーザの前記アカウントに関する情報と、前記受け取られたユーザ名およびパスワードとの間の一致に少なくとも部分的に基づいて、前記ユーザを認証する手段と、
前記ユーザが認証されたことの通知を前記第1のサービスに送る手段と、をさらに備えることを特徴とする請求項27に記載のシステム。
【請求項29】
前記第1のサービスに対する最初のサインオンの場合に、前記サインオンページは、選択された情報収集カスタマイズに基づいて情報の入力を促す、システムであって、前記情報収集カスタマイズに対応する情報を受け取る手段と、前記受け取られた情報を前記第1のサービスに対して利用可能にする手段と、をさらに備えることを特徴とする請求項28に記載のシステム。
【請求項30】
前記提供されるサインオンカスタマイズ機能は、前記第1のサービスに関して選択された少なくとも1つの質問に基づく、ユーザからの情報収集を含むことを特徴とする請求項28に記載のシステム。
【請求項31】
前記第1のサービスに対する前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスによって通知されるテキストが前記第1のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項24に記載のシステム。
【請求項32】
前記第1のサービスに対する前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスによって通知されるリンクが前記第1のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項24に記載のシステム。
【請求項33】
前記第1のサービスに対する前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスによって通知される新しいユーザ選択可能機能性が前記第1のサービスのユーザに対して利用可能にされることを可能にすることを含むことを特徴とする請求項24に記載のシステム。
【請求項34】
前記第1のサービスに対する前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスに関するイメージが前記第1のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項24に記載のシステム。
【請求項35】
前記第1のサービスに対する前記パーミッションレベルを前記決定する手段は、それぞれが異なる信頼度に対応する、複数のあらかじめ定義されたパーミッションレベルのうちの1つを選択する手段を含み、前記選択は、前記第1のサービスに関して取得された複数のタイプの情報を使用して評価された、前記第1のサービスの信頼度に基づくことを特徴とする請求項23に記載のシステム。
【請求項36】
前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスが、前記アクセスマネージャを介して、別のサービスに権限を委譲することを可能にすることを特徴とする請求項23に記載のシステム。
【請求項37】
コンピューティングシステムにおいてサービスを提供するシステムであって、
前記サービスの、アクセスマネージャへの登録を要求する手段と、
前記サービスにおけるサインオン機能の動作をカスタマイズするための、アクセスマネージャによって付与されるパーミッションのレベルを受け取る手段と、
前記パーミッションレベルに少なくとも部分的に基づいて、複数の利用可能なサインオンカスタマイズ機能から1つまたは複数のオプションを選択する手段と、を備え、
前記サービスのユーザとのサインオン対話は、前記選択された1つまたは複数のオプションと整合性があることを特徴とするシステム。
【請求項38】
サインオン機能のカスタマイズが正常に終了したことの通知を受け取る手段をさらに備えることを特徴とする請求項37に記載のシステム。
【請求項39】
前記利用可能なサインオンカスタマイズ機能は、コブランディングカスタマイズを含むことを特徴とする請求項38に記載のシステム。
【請求項40】
前記利用可能なサインオンカスタマイズ機能は、ユーザから情報を収集するプロセスを含むことを特徴とする請求項38に記載のシステム。
【請求項41】
前記コンピューティングシステムは、複数のサービスのユーザにサインオン機能を提供するサインオンサービスの代理として動作し、ユーザとの前記対話は、前記サインオンサービスに対して前記ユーザのサインオンを実行するプロセスの一部であることを特徴とする請求項38に記載のシステム。
【請求項42】
前記サービスは、前記サインオンサービスとは異なることを特徴とする請求項41に記載のシステム。
【請求項1】
コンピューティングシステムにおけるアクセス管理の方法であって、
複数のサービスのうちの第1のサービスの登録を開始するステップと、
前記第1のサービスが利用可能なサインオン機能の動作をカスタマイズするための、アクセスマネージャによって付与されるパーミッションのレベルを、前記アクセスマネージャから決定するステップと、
前記第1のサービスが利用可能な複数のサインオンカスタマイズ機能の通知を、前記パーミッションレベルに少なくとも部分的に基づいて表示するステップと、
前記第1のサービスに関するサインオンカスタマイズの1つまたは複数の選択を受け取るステップと、
前記1つまたは複数の選択と整合性があるサインオンサービスを前記第1のサービスのユーザに提供するステップと、を含むことを特徴とする方法。
【請求項2】
前記利用可能なサインオンカスタマイズ機能は、前記複数のサービスのうちの複数のサービスにおけるサインオン機能のコブランディングを含むことを特徴とする請求項1に記載の方法。
【請求項3】
前記利用可能なサインオンカスタマイズ機能は、情報収集を含むことを特徴とする請求項1および2のいずれかに記載の方法。
【請求項4】
前記アクセスマネージャは、前記複数のサービスを提供する複数のサードパーティWebサイト運営者にシングルサインオンサービスを提供する、方法であって、
ユーザからサインオン要求を受け取るステップと、
前記第1のサービスに関して選択された1つまたは複数のコブランディングカスタマイズを行うような方法で、前記第1のサービスの代理として、前記ユーザに、カスタマイズされたサインオン機能を提供するステップと、
前記第1のサービスに関して選択された1つまたは複数の情報収集タイプのカスタマイズに基づいて、前記ユーザから情報を取得するステップと、をさらに含むことを特徴とする請求項3に記載の方法。
【請求項5】
前記アクセスマネージャにある前記ユーザの有効なアカウントを反映させるために前記第1のサービスを認証するステップと、
前記ユーザを表す信用証明書を第1のサービスに与えるステップと、をさらに含み、前記信用証明書は、前記第1のサービスが、前記ユーザの代理として、前記アクセスマネージャとのアクションを実行することを可能にすることを特徴とする請求項4に記載の方法。
【請求項6】
前記選択されたサインオンカスタマイズを含み、ユーザ名およびパスワードの入力を促すサインオンページを生成するステップと、
前記ユーザに関連付けられた第1のユーザ名および第1のパスワードを受け取るステップと、
前記ユーザの前記アカウントに関する情報と、前記受け取られたユーザ名およびパスワードとの間の一致に少なくとも部分的に基づいて、前記ユーザを認証するステップと、
前記ユーザが認証されたことの通知を前記第1のサービスに送るステップと、をさらに含むことを特徴とする請求項5に記載の方法。
【請求項7】
前記第1のサービスに対する最初のサインオンの場合に、前記サインオンページは、選択された情報収集カスタマイズに基づいて情報の入力を促す、方法であって、前記情報収集カスタマイズに対応する情報を受け取るステップと、前記受け取られた情報を前記第1のサービスに対して利用可能にするステップと、をさらに含むことを特徴とする請求項6に記載の方法。
【請求項8】
前記提供されるサインオンカスタマイズ機能は、前記第1のサービスに関して選択された少なくとも1つの質問に基づく、ユーザからの情報収集を含むことを特徴とする請求項6に記載の方法。
【請求項9】
前記第1のサービスに対する前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスによって通知されるテキストが前記第1のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項2に記載の方法。
【請求項10】
前記第1のサービスに対する前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスによって通知されるリンクが前記第1のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項2に記載の方法。
【請求項11】
前記第1のサービスに対する前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスによって通知される新しいユーザ選択可能機能性が前記第1のサービスのユーザに対して利用可能にされることを可能にすることを含むことを特徴とする請求項2に記載の方法。
【請求項12】
前記第1のサービスに対する前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスに関するイメージが前記第1のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項2に記載の方法。
【請求項13】
前記第1のサービスに対する前記パーミッションレベルを前記決定するステップは、それぞれが異なる信頼度に対応する、複数のあらかじめ定義されたパーミッションレベルのうちの1つを選択するステップを含み、前記選択するステップは、前記第1のサービスに関して取得された複数のタイプの情報を使用して評価された、前記第1のサービスの信頼度に基づくことを特徴とする請求項1に記載の方法。
【請求項14】
前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスが、前記アクセスマネージャを介して、別のサービスに権限を委譲することを可能にすることを特徴とする請求項1に記載の方法。
【請求項15】
請求項1から14に記載の方法のいずれかを実行するコンピュータプログラム。
【請求項16】
コンピューティングシステムにおいてサービスを提供する方法であって、
前記サービスの、アクセスマネージャへの登録を要求するステップと、
前記サービスにおけるサインオン機能の動作をカスタマイズするための、アクセスマネージャによって付与されるパーミッションのレベルを受け取るステップと、
前記パーミッションレベルに少なくとも部分的に基づいて、複数の利用可能なサインオンカスタマイズ機能から1つまたは複数のオプションを選択するステップと、を含み、
前記サービスのユーザとのサインオン対話は、前記選択された1つまたは複数のオプションと整合性があることを特徴とする方法。
【請求項17】
サインオン機能のカスタマイズが正常に終了したことの通知を受け取るステップをさらに含むことを特徴とする請求項16に記載の方法。
【請求項18】
前記利用可能なサインオンカスタマイズ機能は、コブランディングカスタマイズを含むことを特徴とする請求項17に記載の方法。
【請求項19】
前記利用可能なサインオンカスタマイズ機能は、ユーザから情報を収集するプロセスを含むことを特徴とする請求項17に記載の方法。
【請求項20】
前記コンピューティングシステムは、複数のサービスのユーザにサインオン機能を提供するサインオンサービスの代理として動作し、ユーザとの前記対話は、前記サインオンサービスに対して前記ユーザのサインオンを実行するプロセスの一部であることを特徴とする請求項17に記載の方法。
【請求項21】
前記サービスは、前記サインオンサービスとは異なることを特徴とする請求項20に記載の方法。
【請求項22】
請求項16から21に記載の方法のいずれかを実行するコンピュータプログラム。
【請求項23】
コンピューティングシステムにおけるアクセス管理のシステムであって、
複数のサービスのうちの第1のサービスの登録を開始する手段と、
前記第1のサービスが利用可能なサインオン機能の動作をカスタマイズするための、アクセスマネージャによって付与されるパーミッションのレベルを、前記アクセスマネージャから決定する手段と、
前記第1のサービスが利用可能な複数のサインオンカスタマイズ機能の通知を、前記パーミッションレベルに少なくとも部分的に基づいて表示する手段と、
前記第1のサービスに関するサインオンカスタマイズの1つまたは複数の選択を受け取る手段と、
前記1つまたは複数の選択と整合性があるサインオンサービスを前記第1のサービスのユーザに提供する手段と、を備えることを特徴とするシステム。
【請求項24】
前記利用可能なサインオンカスタマイズ機能は、前記複数のサービスのうちの複数のサービスにおけるサインオン機能のコブランディングを含むことを特徴とする請求項23に記載のシステム。
【請求項25】
前記利用可能なサインオンカスタマイズ機能は、情報収集を含むことを特徴とする請求項23および24のいずれかに記載のシステム。
【請求項26】
前記複数のサービスを提供する複数のサードパーティWebサイト運営者にシングルサインオンサービスを提供するシステムであって、
ユーザから複数のサインオン要求を受け取る手段と、
前記第1のサービスに関して選択された1つまたは複数のコブランディングカスタマイズを行うような方法で、前記第1のサービスの代理として、前記ユーザに、カスタマイズされたサインオン機能を提供する手段と、
前記第1のサービスに関して選択された1つまたは複数の情報収集タイプのカスタマイズに基づいて、前記ユーザから情報を取得する手段と、をさらに備えることを特徴とする請求項25に記載のシステム。
【請求項27】
前記アクセスマネージャにある前記ユーザの有効なアカウントを反映させるために前記第1のサービスを認証する手段と、
前記ユーザを表す信用証明書を第1のサービスに与える手段と、をさらに備え、前記信用証明書は、前記第1のサービスが、前記ユーザの代理として、前記アクセスマネージャとのアクションを実行することを可能にすることを特徴とする請求項26に記載のシステム。
【請求項28】
前記選択されたカスタマイズを含み、ユーザ名およびパスワードの入力を促すサインオンページを生成する手段と、
前記ユーザに関連付けられた第1のユーザ名および第1のパスワードを受け取る手段と、
前記ユーザの前記アカウントに関する情報と、前記受け取られたユーザ名およびパスワードとの間の一致に少なくとも部分的に基づいて、前記ユーザを認証する手段と、
前記ユーザが認証されたことの通知を前記第1のサービスに送る手段と、をさらに備えることを特徴とする請求項27に記載のシステム。
【請求項29】
前記第1のサービスに対する最初のサインオンの場合に、前記サインオンページは、選択された情報収集カスタマイズに基づいて情報の入力を促す、システムであって、前記情報収集カスタマイズに対応する情報を受け取る手段と、前記受け取られた情報を前記第1のサービスに対して利用可能にする手段と、をさらに備えることを特徴とする請求項28に記載のシステム。
【請求項30】
前記提供されるサインオンカスタマイズ機能は、前記第1のサービスに関して選択された少なくとも1つの質問に基づく、ユーザからの情報収集を含むことを特徴とする請求項28に記載のシステム。
【請求項31】
前記第1のサービスに対する前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスによって通知されるテキストが前記第1のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項24に記載のシステム。
【請求項32】
前記第1のサービスに対する前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスによって通知されるリンクが前記第1のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項24に記載のシステム。
【請求項33】
前記第1のサービスに対する前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスによって通知される新しいユーザ選択可能機能性が前記第1のサービスのユーザに対して利用可能にされることを可能にすることを含むことを特徴とする請求項24に記載のシステム。
【請求項34】
前記第1のサービスに対する前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスに関するイメージが前記第1のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項24に記載のシステム。
【請求項35】
前記第1のサービスに対する前記パーミッションレベルを前記決定する手段は、それぞれが異なる信頼度に対応する、複数のあらかじめ定義されたパーミッションレベルのうちの1つを選択する手段を含み、前記選択は、前記第1のサービスに関して取得された複数のタイプの情報を使用して評価された、前記第1のサービスの信頼度に基づくことを特徴とする請求項23に記載のシステム。
【請求項36】
前記利用可能なサインオンカスタマイズ機能は、前記第1のサービスが、前記アクセスマネージャを介して、別のサービスに権限を委譲することを可能にすることを特徴とする請求項23に記載のシステム。
【請求項37】
コンピューティングシステムにおいてサービスを提供するシステムであって、
前記サービスの、アクセスマネージャへの登録を要求する手段と、
前記サービスにおけるサインオン機能の動作をカスタマイズするための、アクセスマネージャによって付与されるパーミッションのレベルを受け取る手段と、
前記パーミッションレベルに少なくとも部分的に基づいて、複数の利用可能なサインオンカスタマイズ機能から1つまたは複数のオプションを選択する手段と、を備え、
前記サービスのユーザとのサインオン対話は、前記選択された1つまたは複数のオプションと整合性があることを特徴とするシステム。
【請求項38】
サインオン機能のカスタマイズが正常に終了したことの通知を受け取る手段をさらに備えることを特徴とする請求項37に記載のシステム。
【請求項39】
前記利用可能なサインオンカスタマイズ機能は、コブランディングカスタマイズを含むことを特徴とする請求項38に記載のシステム。
【請求項40】
前記利用可能なサインオンカスタマイズ機能は、ユーザから情報を収集するプロセスを含むことを特徴とする請求項38に記載のシステム。
【請求項41】
前記コンピューティングシステムは、複数のサービスのユーザにサインオン機能を提供するサインオンサービスの代理として動作し、ユーザとの前記対話は、前記サインオンサービスに対して前記ユーザのサインオンを実行するプロセスの一部であることを特徴とする請求項38に記載のシステム。
【請求項42】
前記サービスは、前記サインオンサービスとは異なることを特徴とする請求項41に記載のシステム。
【図1A】
【図1B】
【図1C】
【図2A】
【図2B】
【図2C】
【図2D】
【図2E】
【図3A】
【図3B】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9A】
【図9B】
【図1B】
【図1C】
【図2A】
【図2B】
【図2C】
【図2D】
【図2E】
【図3A】
【図3B】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9A】
【図9B】
【公表番号】特表2009−532772(P2009−532772A)
【公表日】平成21年9月10日(2009.9.10)
【国際特許分類】
【出願番号】特願2009−502981(P2009−502981)
【出願日】平成19年3月29日(2007.3.29)
【国際出願番号】PCT/US2007/007703
【国際公開番号】WO2007/126905
【国際公開日】平成19年11月8日(2007.11.8)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.FLASH
【出願人】(506329306)アマゾン テクノロジーズ インコーポレイテッド (56)
【Fターム(参考)】
【公表日】平成21年9月10日(2009.9.10)
【国際特許分類】
【出願日】平成19年3月29日(2007.3.29)
【国際出願番号】PCT/US2007/007703
【国際公開番号】WO2007/126905
【国際公開日】平成19年11月8日(2007.11.8)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.FLASH
【出願人】(506329306)アマゾン テクノロジーズ インコーポレイテッド (56)
【Fターム(参考)】
[ Back to top ]