JP4856755B2 - カスタマイズ可能なサインオンサービス - Google Patents

Description

以下の開示は、主に、カスタマイズ可能なユーザサインオン機能性を提供する手法に関し、たとえば、この機能性は、シングルサインオンサービスのカスタマである他のサービスのユーザに、カスタマイズ可能なサインオンプロセスを提供するシングルサインオンサービスにより提供される。

日常生活におけるコンピュータの利用が広く普及しつつあり、たとえば、ユーザが、インターネット経由で（たとえば、Ｗｅｂサイトを介して）、あるいは、他のアクセスメカニズム（たとえば、携帯電話網）を介して、様々なタイプのリモートサービスにアクセスしてこれを利用することが可能になっている。たとえば、そのようなサービスは、様々なタイプの情報（たとえば、最新ニュースや参考資料）を提供することが可能なものもあれば、様々なタイプのアクティビティや機能（たとえば、オンラインバンキング、オンラインショッピング、電子メールまたは他のメッセージングサービスなど）を提供することが可能なものもある。一部のサービスは情報および機能を誰にでも提供することが可能であるが、他の多くのサービスは、許可されたユーザのみに制限されており、たとえば、許可されたユーザのみがユーザ情報を利用できるようにすることにより、ユーザ情報のプライバシが保護され（たとえば、ユーザが自分の電子メールを読むためには電子メールサービスにログインしなければならない）、実行されるアクティビティに使用されるユーザデータが管理され（たとえば、ユーザのショッピングを便利にするために、ユーザの金銭情報および出荷先情報（たとえば、ユーザに対して保持されているアカウントの一部）をオンライン商店側が保存する）、ユーザがしかるべき支払いを完了したことや、ユーザがそのサービスの利用に関する他の条件に満足していることが確認される。

サービスにサインオン（または「ログオン」または「ログイン」）して、制限された情報または機能性へのアクセスを許可されていることを示すことが可能であるためには、典型的には、ユーザはまず、そのサービスに登録し、そのサービスに固有の、しかるべきサインオン情報（たとえば、ユーザ名およびパスワード）を取得しなければならない。しかしながら、それぞれが固有のサインオン情報を有するサービスが急増しているため、ユーザは、異なるインターネットサイトごとに異なる、多数のサインオン情報のセットを覚えなければならない不便さを強いられている。さらに、インターネットサイトおよびそのようなサービスの他のプロバイダの多くの運営者が、そのようなユーザサインオンを可能にすること、ならびにユーザサインオンデータおよび他の認証データを保持することの機能性を提供する負担から解放されることを望んでいる。

こうした状況に対処すべく、提携する複数のサービスまたはシステムの群へのアクセスを可能にするサインオン情報の単一セットをユーザが作成するシングルサインオンシステムが生み出された。残念なことに、現在のシングルサインオンシステムには様々な問題がある。たとえば、サービス運営者の多くが、別の運営者によって提供されるサインオン機能性を使用することに対して億劫である。この億劫さは、利用できるサインオンシステムが所望の機能性を提供できないことなどにより、サインオンシステムと対話する際のユーザエクスペリエンスに一貫性がないため（たとえば、一貫したブランディング、あるいは他の一貫した外観や機能性がないため）であると考えられる。さらに、サービス運営者およびユーザは、セキュリティに関して懸念がある場合がある。それは、たとえば、詐欺師が、シングルサインオンシステムとの対話においてユーザまたはサービス運営者になりすまして、制限された情報または機能性へのアクセス権を不正に取得することが可能なのではないかという恐れである。

したがって、シングルサインオンサービスを改善する手法および他の利点を提供することが有益であろう。

ユーザと対話するための、カスタマイズ可能な機能性を提供する手法について説明する。カスタマイズ可能な機能性は、他のサービスにシングルサインオン機能性および他の機能性を提供するアクセスマネージャシステムを介するなどして提供される。実施形態によっては、ユーザが利用できるＷｅｂサイトまたは他のサービスの運営者が、アクセスマネージャシステムと対話することにより、アクセスマネージャシステムがサービスのユーザに対して利用可能にするシングルサインオン機能性および／または他の機能性をカスタマイズしたり、他の方法で構成したりすることが可能である。アクセスマネージャシステムは、そのような機能性を、様々な実施形態において様々な形式で他のサービスに提供することが可能であり、これは、たとえば、サービスの運営者が初期構成を対話形式で行うことを可能にすることによって、かつ、カスタマイズされた機能性が、アクセスマネージャシステムのＡＰＩ（「アプリケーションプログラミングインターフェース」）によるプログラム形式でサービスのユーザに提供されることを可能にすることによって、可能である。少なくとも一部のそのような実施形態では、アクセスマネージャシステムは、様々なユーザの様々なサインオン情報および他のアカウント情報を保持し、それらのユーザが対話する複数の互いに無関係なサービスの代理として、その保持されている情報を使用して、それらのユーザにシングルサインオン機能性を提供する。さらに、少なくとも一部の実施形態では、アクセスマネージャシステムが、その代理として、カスタマイズされた機能性を提供するところのサービス群は、それぞれが、アクセスマネージャシステムのカスタマ（カスタマサービス）であり、これは、たとえば、既にアクセスマネージャシステムに登録しているカスタマサービスが、（たとえば、料金と引き替えに）カスタマイズされた機能性を提供されるようにするためのものである。

実施形態によっては、アクセスマネージャは、アクセスマネージャから利用できるシングルサインオン機能性および／または他の機能性に対する様々なタイプのカスタマイズを可能にすることが可能である。カスタマサービスの代理であるアクセスマネージャとのユーザ対話が、個々のカスタマサービスに合わせてカスタマイズされるように、カスタマサービスの運営者が、様々なタイプのカスタマイズを構成することが可能である。たとえば、少なくとも一部の実施形態では、そのようなタイプのカスタマイズとして、サービスのユーザとの対話時にアクセスマネージャによって使用される、そのサービスに対する様々なタイプのコブランディングが含まれることが可能であり、たとえば、ユーザに提示される１つまたは複数の情報群（たとえば、ユーザに対して表示される１つまたは複数のＷｅｂページ）のそれぞれに、そのサービスのために構成された様々な情報が含まれ、そのような情報として、たとえば、１つまたは複数の指示された画像（たとえば、ロゴ）、指示されたテキスト、指示されたユーザ選択可能リンク、指示された他のユーザ選択可能コントロール（たとえば、指示されたＵＲＬ（「ユニフォームリソースロケータ」）から入手できるか、または指示されたコードを実行することにより入手できるような、表示されるメニューバー）、指示されたコードを実行することにより提供される機能などがある。さらに、少なくとも一部の実施形態では、アクセスマネージャから利用可能な機能性のカスタマイズには、アクセスマネージャとの対話時にサービスのユーザから収集される様々なタイプの情報が含まれ、たとえば、サービスの運営者によって選択された１つまたは複数のあらかじめ定義された質問および／またはサービス運営者によって指定された１つまたは複数の質問に基づいてユーザから情報（たとえば、ユーザに関するデモグラフィック情報、嗜好情報、サービスがその操作の実行時に使用する、ユーザに固有の情報、その他）が収集される。コブランディングおよび情報収集のカスタマイズの詳細については、後述する。

実施形態によっては、ユーザがアクセスマネージャと対話して、あるサービスのカスタマイズされたサインオンプロセスを完了した後、アクセスマネージャは、そのユーザについての信用証明書（ｃｒｅｄｅｎｔｉａｌ）をそのサービスに提供し、これは、たとえば、そのサービスが、その後、ユーザの代理としてアクションを実行する（たとえば、ユーザの代わりに支払いを行う、ユーザの代わりに、保存されているアカウント情報を修正する、など）ための要求を行うことができるように、ユーザがそのサービスの許可されたユーザであることを示すものであり、かつ／または、ユーザを表すものである。この信用証明書は、様々な実施形態において様々な形式をとることが可能であり、たとえば、ユーザに固有の情報（たとえば、ユーザの一意のユーザ名または他の識別子、ユーザの実名または他の識別情報、カスタマイズされたサインオンプロセスにおいてユーザから収集された情報、その他）を、暗号化形式であれ、非暗号化形式であれ、含むことが可能であり、あるいは、単に、アクセスマネージャが後で（返された場合に）ユーザにマッピングできる情報（たとえば、アクセスマネージャまたはサービスに対して一意の番号）であることが可能である。さらに、少なくとも一部の実施形態では、ユーザの代理であるサービスに与えられた信用証明書が、アクセスマネージャによって、そのサービスに固有のものであるとして扱われ、これによって、後で、ユーザの代理として信用証明書を使用する要求が行われた場合には、その要求は、そのサービスによって行われたか、そのサービスの代理で行われた場合に限り、有効として扱われる。さらに、少なくとも一部の実施形態では、信用証明書は、他の様々なタイプの特性を有することが可能である。たとえば、特定の信用証明書が、ある限られた期間においてのみ有効であったり、かつ／または、ユーザの代理での特定のタイプのアクティビティまたは操作についてのみ有効であったりしてよい。その場合、アクセスマネージャは、そのような特性に基づいて、信用証明書の使用を制限することが可能である。信用証明書の詳細については、後述する。

実施形態によっては、少なくともいくつかのサービスについて、サービスが実行することを許可されているアクティビティのタイプに関連する、さらなるタイプのカスタマイズがアクセスマネージャによって許可される。たとえば、いくつかのサービスがそれらのサインオンしたユーザに対して実行することを許可されているアクションのタイプを、様々な形式で限定することが可能であり、これは、たとえば、アクセスマネージャによってサービスに付与されている信頼度を反映させることによって可能であり、一例として、信用証明書は、実施形態によっては、限定された期間のみ有効であることが可能であり、その場合、サービスによっては、有効期間を延長するために、それらのユーザの信用証明書を（たとえば、指定された回数まで、指定された全有効期間まで、無期限かつ無制限に）リフレッシュすることを、少なくとも状況によっては、許可されることが可能である。さらに、少なくとも一部の実施形態では、少なくともいくつかのサービスについてアクセスマネージャによって許可されるカスタマイズは、プライマリサービスが、ユーザの代理としてアクションを実行するために、別のセカンダリサービスに対して行うことが可能であってよい、１つまたは複数のタイプの権限委譲を含み、これは、たとえば、アクセスマネージャによって付与された信頼度をプライマリサービスおよび／またはセカンダリサービスに反映させるためのものである。たとえば、信用証明書が与えられた少なくともいくつかのプライマリサービスは、そのような信用証明書を様々な形式で使用する権限を他のサービスに委譲することを許可されることが可能であり、そのような形式として、信用証明書を使用して、少なくともいくつかのタイプのアクションを、表されたユーザの代理として実行すること、少なくとも状況によっては、限定された有効期間で信用証明書をリフレッシュすること、当該ユーザについての、セカンダリサービス専用の新しい信用証明書の発行を要求すること（たとえば、信用証明書がオリジナルの発行先のサービスについてのみ有効である場合）などが含まれる。権限委譲のタイプの詳細については、後述する。

アクセスマネージャによって、サービスが利用できるようにされるカスタマイズのタイプは、様々な実施形態において様々な形式で決定されることが可能であり、たとえば、サービスおよび／またはサービス運営者に関して取得可能な情報に基づく自動的な形式で決定されることが可能である。たとえば、悪意のあるサービス（または、悪意のないサービスになりすまそうとするか、その他の方法で悪意のないサービスの代理として動作しようとする、悪意のあるパーティ）が、あるタイプのカスタマイズを許可された場合、それらのタイプのカスタマイズは、大きなセキュリティリスクおよび不利益リスクをもたらしうる。コブランディングタイプのカスタマイズの場合、ユーザに対して表示されるテキストおよび／またはイメージを追加することをサービスに許可することは、（テキストのコンテキストが攻撃的でも違法でもない限り）比較的リスクが少ない。逆に、アクセスマネージャが、ユーザに与えられる情報を生成する際に使用する実行可能コード、またはユーザに与えられる情報に含まれる実行可能コード（たとえば、ユーザに送られるＷｅｂページの一部として含まれるＪａｖａ（登録商標）アプレット）を指定することをサービスに許可することは、比較的高いリスクをもたらす可能性がある（たとえば、サービスの指定するコードが、（監視しない限りサービス側にはわからない）ユーザからアクセスマネージャに提供されるサインオン情報を監視するなどして、ユーザに関する情報を不適切に取得することを可能にするリスクをもたらす可能性がある）。サービスが利用できるようにするカスタマイズのタイプの決定方法の詳細については、後述する。

さらに、実施形態によっては、悪意のあるパーティが実際の許可されたパーティになりすまそうとするフィッシング詐欺の企てを阻止するなど、悪意のあるパーティが不正なアクティビティを行うのを阻止するために、様々な手法が用いられる。たとえば、悪意のあるユーザが、アクセスマネージャと対話することを許可されたサービスになりすまして、アクセスマネージャと対話しようとするのを阻止するために、追加のセキュリティ手法を用いて、少なくとも一部のサービスから送られる一部またはすべてのメッセージを認証することが可能である。具体的には、実施形態によっては、アクセスマネージャと対話することを許可された各サービスが、サービスおよびアクセスマネージャには知られている、少なくとも１つの一意の秘密アクセス鍵を与えられ、その後、サービスが、メッセージまたは他の連絡をアクセスマネージャに送る際に、そのサービスの秘密アクセス鍵を使用し、これによって、アクセスマネージャは、メッセージの送信者が実際にそのサービスであることを検証することが可能である。たとえば、サービスからのそのような各メッセージが、そのサービスの一意識別子の通知を含むことが可能であり、また、メッセージ内容の少なくとも一部に基づき、秘密アクセス鍵を用いて生成されたデジタル署名を含むことも可能である。アクセスマネージャは、そのようなメッセージを受け取ると、サービス識別子を用いて、そのサービスを識別し、そのサービスに対応する秘密アクセス鍵を取り出すことが可能であり、その後、取り出した秘密アクセス鍵と、メッセージ内容の同じ部分とを用いて、同じ方法で、デジタル署名を独自に生成することが可能である。アクセスマネージャによって生成されたデジタル署名が、送信者によってメッセージに含められたデジタル署名と一致すれば、アクセスマネージャは、送信者が一意識別子およびそのサービスの秘密アクセス鍵の両方にアクセスできることを確認することが可能であり、したがって、送信者が実際にそのサービスであることが非常に確からしいことを検証することが可能である。秘密アクセス鍵は、様々な実施形態において様々な形式をとることが可能であり、たとえば、共有秘密鍵、ＰＫＩ（「公開鍵インフラストラクチャ」）鍵ペア、Ｘ．５０９証明書、ハードトークンを使用して生成された秘密鍵などの形式をとることが可能である。少なくとも一部の実施形態では、さらに他のセキュリティ手法を用いることが可能であり、秘密アクセス鍵の使用に関する詳細については、後述する。

以下、例示を目的として、いくつかの実施形態を説明する。それらの実施形態においては、特定タイプのサービスが、アクセスマネージャシステムによって、そのサービスの特定タイプのユーザに特定の形式で提供された特定タイプの機能性の特定タイプのカスタマイズを構成する。しかしながら、説明される手法が、他の多様な状況で使用されることが可能であること、ならびに本発明が、与えられる例示的詳細に限定されないことを理解されたい。

図１Ａは、アクセスマネージャシステム、サービス、およびユーザの間で行われる様々なタイプの対話の例を示す。具体的には、図１Ａは、アクセスマネージャシステム１１４と、アクセスマネージャのカスタマであるサービス１１０と、カスタマサービスのユーザ１１２と、カスタマサービスと提携している他のセカンダリサービス１１８（オプション）と、アカウントマネージャシステム１１６との間で行われる対話を示している。この例では、アカウントマネージャ１１６およびアクセスマネージャ１１４は、両方とも、単一エンティティによって与えられたシステム１１５のグループの一部として与えられており（たとえば、アカウントマネージャは、許可されたパーティからの要求があった場合に、アクセスマネージャとともに、アカウントを有するユーザの代理として様々なアクションを実行する）、実施形態によっては、提携サービス１１８の少なくともいくつかがシステム１１５に含まれることも可能である。図示されたシステム、サービス、およびユーザの間では、様々なメッセージが発生する。そのようなメッセージとして、ユーザのアカウントを確立することの一部である、ユーザとアクセスマネージャシステムとの間のメッセージ（たとえば、サインオン情報を含む）、カスタマサービスのためのカスタマイズされた機能性を構成する、カスタマサービスとアクセスマネージャとの間のメッセージ、ユーザとカスタマサービスとの間のメッセージ（ユーザが、カスタマサービスに合わせてカスタマイズされたサインオンプロセスに参加するために、アクセスマネージャとの対話にリダイレクトされる初期対話を含む）、カスタマサービスとアカウントマネージャシステムとの間のメッセージ（たとえば、カスタマサービスにサインオンしたユーザの代理としてアクティビティを実行するためのメッセージ）、カスタマサービスと提携セカンダリサービスとの間のメッセージ（たとえば、カスタマサービスにサインオンしたユーザの代理としてアクティビティを実行するためのメッセージ）、提携サービスとアクセスマネージャとアカウントマネージャシステムとの間のメッセージ（たとえば、カスタマサービスにサインオンしたユーザの代理としてのメッセージ）などがある。さらに、サービスに関与するメッセージ（たとえば、カスタマサービス１１０および／または提携サービス１１８と、アクセスマネージャ１１４、アカウントマネージャ１１６、および他のカスタマサービスまたは提携サービスとの間のメッセージ）の少なくともいくつかは、サービスの秘密アクセス鍵に基づくデジタル署名（図示せず）を使用することが可能である。

図１Ｂは、アクセスマネージャシステム、サービス、およびユーザの間の様々なタイプの対話の１つの具体例を示し、特に、カスタマサービスが、Ｗｅｂサイトではなくアプリケーション開発者のアプリケーションによって与えられている実施形態を示している。具体的には、アプリケーション開発者１２０（この例では「ボブ」という名前である）が最初に、開発者のアプリケーション１２２によって与えられるサービスに関して、アクセスマネージャシステム１５０に登録１８０する。この登録は、たとえば、この例では（たとえば、カスタマ登録マネージャコンポーネントで与えられることが可能な）カスタマ登録プロセス１５８と対話することによって行われる。この例では、アプリケーション１２２は、アプリケーションのエンドユーザにサービスおよび／または他の機能性を提供する（たとえば、汎用パーソナルコンピュータで実行されるための）アプリケーションプログラムであるが、他の実施形態では、そのようなアプリケーションは、他の様々な形式をとることが可能であり、そのような形式としては、Ｗｅｂアプリケーション、ダウンロード可能なアプレットまたは他の実行可能コード、クライアントおよび／またはサーバアプリケーション、モバイルアプリケーション（たとえば、携帯電話または他の形態のモバイルコンピューティング装置で実行されるアプリケーション）などがある。ステップ１８０の一環として、開発者は、様々な情報を供給することが可能であり、それには、連絡先情報およびアプリケーション１２２に関する情報（およびオプションでアプリケーションのコピー）が含まれる。登録対話１８０の一環として、開発者は、後でアプリケーションのエンドユーザが使用する様々なカスタマイズを構成することが可能であり、それらは、アクセスマネージャシステムによって開発者に付与されているパーミッションのレベルに応じたコブランディング、情報収集、権限委譲などである。代替として、一部のカスタマイズが使用されない場合がある。たとえば、アプリケーションがエンドユーザと直接対話してサインオン情報を取得し、取得されたサインオン情報がプログラムによって、検証のためにアクセスマネージャシステムに送られる場合には、コブランディングが構成されない。さらに、アプリケーションのエンドユーザが、アプリケーション１２２によって与えられたグラフィカルユーザインターフェースと対話する、図示されたような実施形態では、アプリケーションは、少なくともいくつかの情報を特定の形式のグラフィカルユーザインターフェースからエンドユーザに提供することを、契約により、または他の形式で義務づけられることが可能である。そのような情報は、たとえば、アクセスマネージャのブランドとコブランディングされる形式でエンドユーザに提示されているアクセスマネージャシステムにサインオンすることに関連付けられることが可能である。代替として、アプリケーションは、他のタイプの、アクセスマネージャに固有の情報または機能性を提供すること、および／またはエンドユーザのサインオン情報を保護するために、様々な指定のセキュリティ対策を採用することを義務づけられることも可能である。開発者は、登録後に、アクセスマネージャ１５８から様々な情報１８１を受け取ることが可能であり、たとえば、使用される秘密鍵の通知（または対話１８０の一環として開発者から指定された秘密鍵の確認）およびアプリケーションの非秘密の一意識別子（たとえば、秘密アクセス鍵に関連付けられた識別子）を受け取ることが可能である。開発者が様々なエンドユーザ１３０にアプリケーションを配布１８２した後、エンドユーザが、そのアプリケーションを使用して様々なタイプの機能性を取得することが可能である。

次に、ユーザ例１３０が、アプリケーションと対話１８３し、たとえば、リモートサードパーティＷｅｂサービスプロバイダ１４０（たとえば、ユーザが既成のアカウントを有するＷｅｂサービスプロバイダ）から提供される１つまたは複数のＷｅｂサービスを利用するためにユーザがサインオンを行う動作を要求する。Ｗｅｂサービスは、異種のアプリケーションおよびコンピュータ同士が対話することを可能にすることが可能であり、様々な下位プロトコルおよび手法を用いて定義および実装されることが可能である。たとえば、一部のＷｅｂサービス実装は、ＵＲＩ（たとえば、指定された動作および１つまたは複数のクエリパラメータを含むＵＲＬ）として指定されるＷｅｂサービス呼び出し要求への応答として、ＨＴＴＰ （「ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ」）を用いてＸＭＬ（「ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ」）フォーマットのデータを返す。他の実装では、さらなる下位プロトコルが様々な目的で使用され、たとえば、標準メッセージ交換のためにＳＯＡＰ（「Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ」）が使用され、サービス呼び出しの記述のためにＷＳＤＬ（「Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ」）が使用され、利用可能サービスの発見のためにＵＤＤＩ（「Ｕｎｉｖｅｒｓａｌ Ｄｅｓｃｒｉｐｔｉｏｎ，Ｄｉｓｃｏｖｅｒｙ，ａｎｄ Ｉｎｔｅｇｒａｔｉｏｎ ｓｅｒｖｉｃｅ」）が使用される。状況によっては、アプリケーション１２２およびＷｅｂサービスプロバイダ１４０は、あらかじめ定義された関係を有することが可能である。他の実施形態では、アプリケーションは、そのようなあらかじめ定義された関係を有することなく、単に、アプリケーションのエンドユーザの代理として、提供されたＷｅｂサービスの定義済みＡＰＩと対話することが可能であり、これは、たとえば、Ｗｅｂサービスプロバイダがアクセスマネージャシステムのカスタマでもあり、ユーザを表すために、アクセスマネージャシステムの信用証明書を受け取って使用するように構成されている場合である。

ユーザが、サインオンをトリガする動作を要求すると、（たとえば、要求者がアプリケーションであることの検証のために、アプリケーションの秘密鍵を使用して生成されたデジタル署名を有する）サインオン要求メッセージが、アプリケーションによって生成され、ユーザ対話マネージャプロセス１５２へ送られる１８４。このメッセージが検証された場合、アクセスマネージャは、オプションで、ユーザからサインオン情報を収集する際にアプリケーションによって使用されるサインオン情報（たとえば、情報を収集するためにユーザに対して行う質問、または、アプリケーションが１つまたは複数のページまたはスクリーンをユーザに対して表示するように設計されている場合は、それらのページまたはスクリーン）を返す１８５ことが可能であり、アプリケーションは、（この例では、アクセスマネージャシステムにあるユーザの既成アカウントを反映する）様々なサインオン情報を収集するために、ユーザとのサインオンプロセスを実行することが可能である。収集された情報は、次に、アクセスマネージャユーザ対話マネージャ１５２へ送られる１８６。他の実施形態では、アプリケーションは、（たとえば、アプリケーションに付与されているパーミッションのレベルに応じて）アクセスマネージャシステムとの初期対話を行うことなく、ユーザからサインオン情報を収集し、その、ユーザのサインオン情報を、初期要求１８４とともに送ることが可能であるが、そのような状況では、エンドユーザのサインオン情報がアプリケーションにさらされる可能性がある。アクセスマネージャユーザ対話マネージャ１５２は、サインオン情報を受け取ると、このサインオン情報をアカウントマネージャシステム１６０へ送り１８７、アカウントマネージャシステム１６０は、ユーザアカウントデータベース（「ＤＢ」）１６２内の情報を使用してそのサインオン情報を検証する。次に、ユーザ認証の通知（たとえば、ユーザＩＤまたはエラーメッセージ）がアクセスマネージャユーザ対話マネージャに返される１８８。サインオン情報が有効だった場合は、信用証明書マネージャ１５６へ要求が（たとえば、ユーザＩＤとともに）送られ１８９、信用証明書マネージャは、アプリケーションによって使用されるための、そのユーザを表す信用証明書を生成し、この信用証明書をアクセスマネージャユーザ対話マネージャへ返す１９０。アクセスマネージャユーザ対話マネージャは、信用証明書を受け取ると、その信用証明書をアプリケーションに送り返す１９１。

次に、アプリケーションは、Ｗｅｂサービス要求を生成し、これをＷｅｂサービスプロバイダ１４０へ送る１９２。この要求には、オプションで、アプリケーションの秘密アクセス鍵を使用して生成されたデジタル署名が含まれる。Ｗｅｂサービスプロバイダ１４０は、要求を受け取ると、オプションで、デジタル署名が添付されている場合にはデジタル署名を使用して、（要求をアクセスマネージャに送って検証を要求すること（図示せず）などにより）要求者の身元を検証する。さらに、Ｗｅｂサービスプロバイダは、ユーザの信用証明書を検証する。これは、この例では、Ｗｅｂサービスプロバイダが信用証明書を信用証明書マネージャに送り１９３、信用証明書マネージャが（たとえば、信用証明書の正当性を立証する）適切な応答を生成し、これをＷｅｂサービスプロバイダに送る１９４ことによって行われる。信用証明書の正当性が立証されると、Ｗｅｂサービスプロバイダは、要求されたＷｅｂサービスをユーザに提供し、応答をアプリケーションへ送る１９５。次に、アプリケーションは、その応答に基づいて、対応する情報および／または機能性をユーザに提供することが可能である。実施形態によっては、アプリケーションはさらに、さらなる様々なタイプのＷｅｂサービス要求および他の要求を行うことが可能であり、たとえば、アカウントマネージャシステムと直接対話して、ユーザアカウントを変更したり、ユーザアカウントデータベース１６２からデータを取り出したりする要求を行うことが可能である。すべての要求が行われた後、ユーザは、アプリケーションを介してサインアウトするか、単に、信用証明書の限られた有効期限が切れるのを許容することが可能である。

図１Ｃは、単一のサインオンＷｅｂサービス１０１と、カスタマＷｅｂサイト例１０３と、このカスタマＷｅｂサイトと対話しているエンドユーザ（図示せず）によって使用されるＷｅｂブラウザ１０５との間の様々なタイプの対話の一例を示す。この例では、図示された対話の第１のステップとして、エンドユーザは、指示された機能性を取得するために、ブラウザ１０５を使用して、ＨＴＴＰベースの要求１２１をカスタマＷｅｂサイト１０３へ送る。Ｗｅｂサイトは、要求された機能性はサインオンしたユーザだけが利用できることを決定し、したがって、サインオンプロセスを実行するために、サインオン要求１２３をエンドユーザへ送る。この図示された実施形態では、サインオン要求に（たとえば、Ｘ．５０９証明書を使用して）デジタル署名が添付されており、これを生成する方法については、別の場所で詳述する。この例では、サインオンプロセスは、シングルサインオンサービスによって多数のカスタマＷｅｂサイトに提供され、サインオン要求１２３がブラウザ１０５に送られると、ブラウザ１０５は、要求１２３の指示により、（たとえば、ＨＴＴＰ ３０１ステータスコードを介するなどしてリダイレクトＵＲＬを送ることにより）デジタル署名を含む要求１２５をシングルサインオンサービスに転送する。次に、シングルサインオンサービス１０１は、要求１２５のデジタル署名の検証を試行し（詳細については、別の場所で詳述する）、検証が成功すれば、次に、サインオンページをブラウザ１０５に返す１２７。次に、エンドユーザは、ブラウザ１０５にサインオンページが表示された際に、自分のサインオン情報（たとえば、ユーザ名およびパスワード）をサインオンページに入力する。サインオンページは、対応するユーザアカウントを作成するために、ユーザとシングルサインオンサービスとの間で行われた登録の際に提供された情報に基づいて（または、対話型登録プロセス（図示せず）の後に）生成されることが可能である。次に、サインオン情報は、（たとえば、エンドユーザが「完了」コントロールまたは他の同様のコントロールを選択した際に）シングルサインオンサービスに返される１２９。この例では、エンドユーザは、シングルサインオンサービスプロバイダを信頼して、自分のサインオン情報を進んでシングルサインオンサービスに送っている。これは特に、この例では、サインオン情報がカスタマＷｅｂサイト１０３と共有されないためである。シングルサインオンサービス１０１は、サインオン情報を受け取った後、受け取ったサインオン情報が有効かどうかを判定し、有効であれば、そのエンドユーザのサインオンを実行し、そのユーザをサインオンしたエンドユーザとして表す信用証明書を生成する。生成された信用証明書は、ブラウザ１０５に送られ１３１、そこから（カスタマＷｅｂサイト用クッキーまたはリダイレクトＵＲＬを介するなどして）カスタマＷｅｂサイト１０３へ転送される１３３。カスタマＷｅｂサイト１０３は、エンドユーザのサインオンの成功を示す信用証明書を受け取ると、最初に要求された機能性（図示せず）をエンドユーザに提供する。また、ここでは図示されていないが、カスタマＷｅｂサイトは、信用証明書を使用して、様々な後続のアクションをエンドユーザの代理として実行することも可能である。たとえば、信用証明書が、ユーザのアカウントに関連する要求とともに（たとえば、ユーザアカウントに保存されている金銭情報に基づいて支払いを行うために）、シングルサインオンサービスに返されることが可能である。そのような、信用証明書に基づく利用は、カスタマＷｅｂサイト１０３とシングルサインオンサービス１０１との間で直接行われる対話に基づくことが可能であり、あるいは、１つまたは複数の提携中間サービス（図示せず）および／またはエンドユーザとの対話を介することも可能である。さらに、様々なメッセージの少なくともいくつかが、セキュリティ上の理由から、ＨＴＴＰ／Ｓにより有利に転送されることも可能である。

図２Ａ〜２Ｅは、カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャとＷｅｂサイトまたは他の、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す。具体的には、図２Ａは、アクセスマネージャのカスタマになる見込みのあるサービスの担当者に対して表示されることが可能な第１の情報群を示しており、これは、たとえば、サービスのユーザの代理として、カスタマイズされた機能性を取得するために、アクセスマネージャに登録しようとしているサービスの運営者に対して表示されるＷｅｂページによって示される。この例では、初期登録情報は、指示情報２０１およびセクション２０２を含んでおり、セクション２０２では、アクセスマネージャカスタマが様々なタイプの情報を指定することが可能であり、たとえば、名前およびインターネットアドレス２０２ａ（たとえば、サービスを提供するＷｅｂサイトのＵＲＬ）、管理用連絡先情報２０２ｂ、サービスの少々の概要情報２０２ｃなどを指定することが可能である。サービスおよびサービス運営者に関する他の様々なタイプの情報が、他の実施形態において様々な方法で取得されることが可能であり、たとえば、カスタマが利用できるようにするカスタマイズのタイプを制限するなど、アクセスマネージャがアクセスマネージャカスタマに付与する信頼度およびこれに対応するパーミッションを決定するための要素として使用されることが可能である。入力された情報は、この例では、ユーザ選択可能な「登録」コントロール２０３をクリックすることにより、アクセスマネージャに送られる。また、ユーザ選択可能な「リセット」コントロール２０４を使用すると、フォームに入力した情報をリセットすることが可能である。「登録」コントロール２０３が選択されると、この例では、見込みのあるカスタマに対して、アクセスマネージャへの登録を続行するための、図２Ｂに示されるような、後続の情報群（たとえば、次のＷｅｂページ）が表示される。他の実施形態では、すべての情報要求およびカスタマイズ制御が、別の形式で（たとえば、まとめて表示される単一情報群の一部として）表示されることが可能である。

図２Ｂは、コブランディングのカスタマイズの１つまたは複数のタイプを指定するための、カスタマになる見込みのあるサービスの担当者に対して表示されることが可能な第２の情報群の例を示している。この例では、コブランディングのカスタマイズの利用可能なタイプは、比較的最小限であり、これは、たとえば、カスタマに付与されたパーミッションが比較的低レベルであることを反映するためである（たとえば、高い信頼度が検証可能でない限り、どのカスタマにも適用される初期デフォルトとして、または図２Ａに対して入力された情報および／またはサービスまたはサービス運営者に関して利用可能な他の情報に基づいて（たとえば、サービスまたは運営者との、過去の対話エクスペリエンスに基づいて））。この例では、カスタマは、複数のブランドを指定すること、および情報をブランドごとに異なるようにカスタマイズすることを許可される。他の実施形態では、そのようなブランドを使用しないことや、サービスとブランドとの各組合せを別個のカスタマとして扱うことが可能である。同様に、ここでは図示されていないが、他の実施形態では、カスタマは、指定および使用される異なるコブランディングまたは他のカスタマイズに関する他のタイプの区別を指定することが可能であってよい（たとえば、ユーザが関連付けられることが可能な複数の地理的ロケールまたは他のユーザグループ）。複数のブランド、ロケール、または他の異なるグルーピングを指定する場合、そのようなグルーピングのそれぞれは、実施形態によっては、別々の識別子と、オプションで、別々の秘密アクセス鍵とを与えられることが可能であり、これは、たとえば、使用される個々のグルーピングへの参照を可能にするためである。この例では、表示される情報は、構成されるブランドを示すセクション２０６（異なる複数のブランドが使用されない場合、または、カスタマイズがすべてのブランドに適用される場合には、空白のままにされる）と、指示情報２０５と、カスタマが１つまたは複数のカスタマイズを指定するための様々な質問および情報選択／指定の領域を有する領域２０７と、を含んでいる。たとえば、カスタマは、ユーザに対して表示される、サービスの１つまたは複数のロゴイメージを（たとえば、対応するファイルをアップロードすること、またはイメージを取り出すことが可能なネットワークアドレスを指定することにより）指定することが可能であり、この例では、指定されたロゴイメージのプレビュー２０８が、使用されるロゴロケーション、ユーザに対して表示されるテキスト、およびユーザに対して表示されるリンクとともに表示される。他の実施形態では、他の様々なタイプのコブランディングカスタマイズを利用可能にすることが可能であることが理解されよう。さらに、この例では、カスタマは、ユーザ選択可能な「プレビュー」コントロール２０９とユーザ選択可能な「保存」コントロール２１０とを与えられ、「プレビュー」コントロール２０９を使用すると、指定されたコブランディングカスタマイズの結果である１つまたは複数のサインオンページまたはスクリーンをプレビューすることが可能であり、「保存」コントロール２１０を使用すると、指定されたコブランディングカスタマイズを保存することが可能である。この例では、カスタマは、単一グループのコブランディングカスタマイズのみを実行するように図示されているが、他の実施形態では、コブランディングカスタマイズの異なる複数のセットを指定することが可能である。たとえば、アクセスマネージャによって、ユーザに対して表示される複数のページまたは他の情報群（たとえば、サインオンプロセスに使用される複数のページ、および／または他の関連するタイプのアクティビティ（たとえば、サインオフまたはサインアウトプロセス、ユーザからの情報収集、エラーの提示、信用証明書のリフレッシュ、プライマリサービスに対して発行された信用証明書に基づく、セカンダリサービス用の新しい信用証明書の生成（信用証明書の「クローニング」と呼ばれる）など）に使用されるページ）を反映するために、単一ブランドに対して、コブランディングカスタマイズの異なる複数のセットを提供することが可能である。

図２Ｃは、図２Ｂの場合と同様に、コブランディングカスタマイズの１つまたは複数のタイプを指定するための、カスタマになる見込みのあるサービスの担当者に対して表示されることが可能な第２の情報群の別の例を示している。この例では、カスタマに付与された比較的高レベルのパーミッションを反映するために、（たとえば、図２Ａのように提供された情報および／またはサービスまたはサービス運営者に関して利用可能な他の情報に基づいて）さらなるタイプのコブランディングカスタマイズがカスタマに対して利用可能になっている。他の実施形態では、他の理由で、さらなるタイプのコブランディングカスタマイズを利用可能にすることが可能である（たとえば、プレミアムカスタマに対し、追加料金と引き替えで）。この例では、表示される情報は、図２Ｂの情報２０５〜２０８からなる通知２１１を含み、さらに、追加のコブランディングカスタマイズ２１２を含む。この例における追加タイプのコブランディングカスタマイズは、ユーザに対して表示される情報の外観を追加指定する機能と、ページの見出しに含まれるユーザ選択可能コントロールおよび／または他の情報、またはユーザに対して表示される他の情報を指定する機能と、ページの一部として含まれる他の実行可能コード、またはユーザに対して表示または提供される他の情報と、を含んでいる。これらの追加のコブランディングカスタマイズのタイプは、単に例示的であって、代替実施形態では、他の追加タイプのカスタマイズを利用可能にすることも可能である。

この例では、カスタマサービスの運営者または他の担当者が、様々なカスタマイズを、対応するプロンプトに応じて個々に指定するが、他の実施形態では、別の手法でコブランディングカスタマイズを指定することも可能である。たとえば、実施形態によっては、ユーザに対して表示または他の方法で提示されるカスタマイズされたサインオンページまたは他の情報の外観をカスタマがグラフィカルに指定するＷＹＳＷＹＧ（「Ｗｈａｔ Ｙｏｕ Ｓｅｅ ｉｓ Ｗｈａｔ Ｙｏｕ Ｇｅｔ（見たものが、手に入るもの）」）システムを用いることが可能であり、あるいは、適切なフォーマット（たとえば、ＸＭＬまたは（Ｘ）ＨＴＭＬ（「（ｅＸｔｅｎｓｉｂｌｅ）ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（拡張可能ハイパーテキストマークアップ言語）」）フラグメント）を使用して、コブランディングカスタマイズをファイルのかたちで指定して、アクセスマネージャに送ることも可能である。

図２Ｄは、サービスのユーザとの対話時に実行される情報収集の１つまたは複数のタイプを指定するために、カスタマサービス担当者に対して表示されることが可能な、第３の情報群の例を示す。実施形態によっては、一部またはすべてのタイプの情報収集が、十分に高いレベルのパーミッションを有するカスタマだけが利用できるようにされることが可能であり、かつ／または、他の条件に基づいて（たとえば、プレミアムカスタマだけが）利用できるようにすることが可能である。この例では、（たとえば、それぞれが、ユーザに対して表示される、対応する質問（図示せず）を有する）様々な定義済みタイプの収集対象情報に対して、定義済み情報タイプの１つまたは複数を選択するためのチェックボックス２１３が利用可能になっている。ここでは図示されていないが、少なくとも一部の実施形態では、ユーザに対して行われるカスタマ指定質問の１つまたは複数のセットをカスタマサービスが構成することがさらに可能であり、たとえば、行われる質問を入力すること、およびオプションで、質問に対する可能な答えを列挙または他の方法で表示することを構成することが可能である。さらに、この例では、カスタマは、アクセスマネージャが追跡するユーザアクティビティの１つまたは複数のタイプ２１５をさらに指定することが可能であり、そのようなタイプとして、たとえば、サインオン試行（成功および／または失敗）、サインオフ試行、表示または他の方法で提示された契約条件（たとえば、登録プロセス（図示せず）においてカスタマによって指定され、「同意」コントロールを選択すること、または他のユーザ同意の提示によってユーザに受け入れられる契約条件）に対する同意を与えることなどがある。この例では、カスタマはさらに、（ユーザ選択可能タイミング制御２１４で示されるように）定義済みおよび／またはカスタマ指定のタイプの情報をユーザに尋ねるタイミングを指定することが可能であるが、他の実施形態では、タイミングを固定することも可能である（たとえば、サービスに対するユーザの最初のサインオン（または他のアクティビティ）の間に１回のみ、またはサインオンごとに、など）。この例では、フォーマッティング情報２１６がカスタマによって指定されることも可能であり、これは、たとえば、定義済みタイプの収集対象情報の少なくともいくつかについて可能なタイプの答えを示すためである。実施形態によっては、情報収集の構成時に他のタイプの情報も与えられることが可能であり、たとえば、与えられるユーザの答えが許容可能かどうかを動的に判定する際に使用される論理や、いくつかの質問（たとえば、ユーザに配偶者または子供がいるかどうかを示すユーザからの答えに基づく、ユーザの配偶者または子供に関する詳細についての質問）が特定のユーザに対して行われるべきかどうかを判定する際に使用される論理などが与えられることが可能である。

図２Ｅは、他の提携セカンダリサービスに対する１つまたは複数のタイプの権限委譲（たとえば、プライマリカスタマサービスのユーザの代理として特定タイプのアクションを実行する権限の委譲）を指定するために、カスタマサービス担当者に対して表示されることが可能な、第４の情報群を示しているが、実施形態によっては、そのようなカスタマイズは、十分に高レベルのパーミッションを有するカスタマにのみ与えられることが可能である（そして、権限委譲の個々のタイプは、パーミッションレベルおよび／または他の要因に応じて変わってよい）。この例では、図２Ｅは、指示情報２１７と、権限の委譲を受けるサービスをカスタマが指定することが可能なセクション２１９、２２１、および２２３とを含んでいる。ここでは図示されていないが、実施形態によっては、カスタマはさらに、権限委譲のデフォルトセットを修正することなどにより、提携セカンダリサービスのそれぞれに対する、特定タイプの権限の委譲を指定することが可能である。カスタマはさらに、提携サービスがアクセスする情報に対する制御（たとえば、利用可能なユーザ情報の指定されたサブセット）を指定することが可能である。この例では、セクション２１９は、アクセスマネージャと提携している他の様々なサービス（（たとえば、ユーザのアカウントに対して、かつ／または、ユーザのアカウントから行われる支払いを有効にする）支払サービスや、（たとえば、ユーザに関して既に指定された嗜好に従うなどして、ユーザの代理として、推薦を取得および／または付与する）推薦サービスなど）を（たとえば、同じエンティティによって与えられることを前提として）利用可能にする。さらに、セクション２２１は、他の様々な一般サービス（この例では、人気または信頼性の格付けのような、そのサービスに関する情報を含む）を利用可能にし、セクション２２３は、カスタマが他のサービスを指定することを可能にする。

実施形態によっては、プライマリカスタマサービスと提携しているセカンダリサービス自体が、ユーザの代理としてアクセスマネージャと対話するために、アクセスマネージャに登録されることが必要な場合があり、したがって、一般サービスは、アクセスマネージャに既に登録されているサービスに基づくことが可能である。代替として、指定されたサービスがまだアクセスマネージャに登録されていない場合、アクセスマネージャは、その指定されたサービスに自動的に照会して、登録機能を提供することが可能である。カスタマサービスがユーザと対話しているときには、別のサービスへの権限の委譲は、ユーザによって開始される場合（たとえば、セカンダリサービスを介して提供される機能に対応する、プライマリカスタマサービスによって表示されるリンクまたはコントロール（たとえば、支払サービスに委譲される、ユーザのアカウントから支払いを行うリンク）をユーザが選択することに基づいて）、および／または、プライマリカスタマサービスによって自動的に実行される場合など、様々なかたちで行われることが可能である。さらに、実施形態によっては、セカンダリサービスとの対話は、ユーザにとって透過的なかたちで実行されることが可能である。たとえば、支払関連機能が要求された場合は、セカンダリ提携支払サービスがページまたは他の情報群を生成してユーザに送ることが可能である。これは、たとえば、対応する情報をユーザから取得するためである（たとえば、１つまたは複数の他のパーティの表示、少なくともいくつかのタイプのアクションに関するユーザのサインオンまたは他の情報の検証など）。さらに、一貫性のあるエクスペリエンスをユーザに提供するために、セカンダリ提携サービスは、少なくとも一部の実施形態では、プライマリカスタマサービスに対して既に指定されたコブランディング情報を、ユーザに対して表示される情報の中で使用することが可能である。そのような既に指定されたコブランディングへのアクセス権を取得するために、セカンダリ提携サービスは、そのコブランディング情報を使用する権限がセカンダリ提携サービスに委譲されている場合には、アクセスマネージャと対話して、コブランディング情報を取得することが可能である。たとえば、プライマリカスタマサービスは、プライマリカスタマサービスのための指定のタイプのコブランディング情報（たとえば、プライマリカスタマサービス用の１つまたは複数のロゴまたは他のイメージ）をセカンダリ提携サービスが指定の形式で使用できるように、セカンダリ提携サービスに権限を委譲することが可能であり、そうであれば、セカンダリサービスは、適切な要求（たとえば、セカンダリサービス、プライマリカスタマサービス、必要な情報のタイプ、およびオプションで、プライマリカスタマサービスの固有のコブランディング情報を指示する要求）をアクセスマネージャに送ることにより、そのようなコブランディング情報の使用権を得ることが可能である。アクセスマネージャは、セカンダリサービスがそのコブランディング情報の使用を許可されたことを確認すると、そのコブランディング情報（または、セカンダリサービスがそのコブランディング情報を取得するために使用できる情報）を返す。

図３Ａ〜３Ｂは、カスタマサービスの代理としてのアクセスマネージャからユーザに提供される、カスタマイズされたサインオンプロセスの例を示す。具体的には、図３Ａは、サービスのユーザに対して表示される、カスタマサービスに合わせてカスタマイズされた最初のサインオンページを示している。この例では、サインオンページは、比較的低レベルのパーミッションを有するカスタマ（または、高レベルのパーミッションに関連付けられたカスタマイズを含めることを選択していないカスタマ）向けに、アクセスマネージャ機能性のプロバイダによって生成されることが可能である。この例では、カスタマロゴ３０１およびカスタマイメージ３０３が、コブランディングカスタマイズに従って表示され、アクセスマネージャまたはアクセスマネージャを提供するエンティティのロゴ３０５も表示されている。他の実施形態では、ロゴ３０５は使用されなくてよい。指示情報３０７は、（たとえば、ユーザの、アカウントマネージャプロバイダのアカウントに基づいて）アカウントマネージャプロバイダに関するサインオン情報を使用してサインオンプロセスを開始するように、ユーザに通知する。そのサインオン情報は、ユーザによって、しかるべき場所３０９に入力されることが可能である。さらに、カスタマの使用条件およびカスタマのプライバシポリシーへのアクセスを提供する、カスタマイズされたリンク３１３が表示されている。さらに、サインオン情報を送るための様々なユーザ選択可能コントロール３１１も提示されている。

図３Ｂは、このサービスの少なくとも一部のユーザ（たとえば、このカスタマサービスへのサインオンが初めてであるユーザや、指定の条件を満たす後続のサインオン試行を行うユーザ）に対して表示される、カスタマサービスに合わせてカスタマイズされたサインオンプロセスの後続のページを示している。具体的には、この例では、このページは、カスタマによって指定された質問３２５を行うことによって、カスタマイズされたタイプの情報収集を実行するために提供される。そのような質問としては、出荷先アドレス、電話番号、および他の、ユーザの連絡先情報があり、これらに限定されない。カスタマロゴ３２１は、情報収集ページの一部として表示可能な、様々なタイプのコブランディングの一例を示している。これは、図３Ａのロゴ３０１であっても、カスタマ固有のロゴであってもよい。さらに、指示情報３２３をユーザに対して表示して、デフォルトの質問であれ、カスタマサービスによって指定された質問であれ、質問に答えるよう、ユーザに通知することが可能である。質問によっては、（たとえば、電話番号３２７のように）カスタマによって指定された、カスタマイズされたデータ形式を示すことも可能である。実施形態によっては、クライアントサイドスクリプティング（たとえば、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ）を使用して、許容できる値について任意の指定された制限を設けることが可能であり、また、質問のいくつかがユーザに対して行われるべきかどうかを決定する、指定された論理を実装することも可能である。ユーザがカスタマにサインオンするたびに、他の一度きりの情報収集が実行されない場合でも、追加の質問３２９をユーザに対して行うことが可能である。ユーザは、質問に答え終わったら、ユーザ選択可能コントロールを使用して、その情報を送信することが可能である３３１。

サインオンおよび情報収集は、様々な実施形態において様々な形式で行われることが可能である。たとえば、図３Ａおよび３ＢはＷｅｂページを示しているが、実施形態によっては、プログラム的にアクセスされるインターフェースを含め、他のインターフェースを利用することも可能である。さらに、ユーザの情報を収集する際に複数のページを使用することが可能であり（特に、ユーザがカスタマに初めてサインオンする場合）、ユーザインターフェース内で様々なユーザインターフェースウィジェットを使用することが可能である。

ここでは図示されていないが、カスタマイズされたサインオンプロセスおよび他のタイプのカスタマイズされたユーザ対話は、他の様々な状況および形式でも使用されることが可能である。たとえば、図３Ａおよび３Ｂでは、カスタマイズ手法は、１つまたは複数のＷｅｂページの一部として使用されるものとして示されているが、１つまたは複数の電子メールメッセージ（たとえば、ＨＴＭＬ形式で指定された電子メールメッセージ）または他のタイプの、エンドユーザに送られる電子メッセージのような、他の様々なタイプのメッセージおよび情報も、同様にカスタマイズされることが可能である。さらに、カスタマイズ手法は、検索エンジンの出力や、ソーシャルネットワーキングサービスで与えられる情報のような、ユーザに提供される他の様々なタイプの情報をコブランディングするために使用されることも可能である。

図４は、アクセスマネージャコンピューティングシステム４００、ならびに、様々なユーザコンピューティングシステム４５０、提携サービスコンピューティングシステム４９０、およびカスタマサービスコンピューティングシステム４７０の例示的実施形態を示すブロック図である。図示された実施形態では、アクセスマネージャコンピューティングシステムは、ＣＰＵ ４０５、各種Ｉ／Ｏコンポーネント４１０、ストレージ４３０、およびメモリ４２０を含んでおり、Ｉ／Ｏコンポーネントは、ディスプレイ４１１、ネットワークインターフェース４１２、コンピュータ可読媒体ドライブ４１３、および他のＩ／Ｏデバイス４１５を含んでいる。

アクセスマネージャシステム４２３およびアカウントマネージャシステム４２８の実施形態は、メモリ４２０内で実行されており、これらは、ネットワーク４８０を介して（たとえば、インターネットおよび／またはワールドワイドウェブを介して）他のコンピューティングシステムと対話する。ユーザらは、最初に、アカウントを確立して使用するために、（たとえば、各ユーザがユーザコンピュータシステムのメモリ４５７内で実行されているブラウザ４５８を使用して）アカウントマネージャシステムと対話することが可能であり、これは、たとえば、ストレージ４３０上のユーザアカウントデータベース４３２データ構造に格納されているサインオン情報、連絡先情報、金銭情報などを指定するためであり、実施形態によっては、アカウントマネージャシステムおよび／または１つまたは複数の他の提携システム（図示せず）がさらに、様々なタイプの機能性（オンラインショッピング機能性、メッセージングサービス機能性、情報アクセス機能性など）をユーザに提供することが可能である。アクセスマネージャシステム４２３の図示された実施形態は、様々な機能性を提供するために複数のマネージャコンポーネントを含んでおり、それらには、カスタマ登録マネージャコンポーネント４２１、ユーザ対話マネージャコンポーネント４２２、信用証明書マネージャコンポーネント４２４、カスタマステータスマネージャコンポーネント４２５、カスタマ検証マネージャコンポーネント４２６などが含まれるが、他の実施形態では、これらのマネージャコンポーネントの機能性は、他の形式で編成されてもよい。カスタマ登録マネージャコンポーネントは、サービスの運営者および他の担当者と対話することにより、それらのサービスをアクセスマネージャシステムのカスタマとして登録し、サービスのユーザに提供されるサインオン機能性および他の機能性をカスタマイズし、カスタマによって提供される情報は、ストレージにあるカスタマ情報データベース４４０データ構造に格納される。カスタマになる見込みのあるサービスがカスタマとして登録されると、１人または複数のユーザが、カスタマサービスコンピューティングシステムによって提供されるサービスおよび他の機能性と対話することが可能であり、カスタマサービスへのサインオンを実行するために、アクセスマネージャシステムにダイレクトされることが可能である。次に、ユーザ対話マネージャコンポーネントは、ユーザと対話して、たとえば、前に保存されたユーザアカウント情報に基づいて、かつ／または、（直接であれ、ユーザをアカウントマネージャシステムと対話することにリダイレクトすることによってであれ）ユーザをアカウントマネージャシステムの新しいユーザとして登録することに基づいて、カスタマサービスのカスタマイズされたサインオンプロセスを提供する。さらに、実施形態によっては、ユーザ対話マネージャコンポーネントは、ユーザに関する様々な情報を、カスタマイズされた形式で収集し、その情報を、収集済みユーザ情報データベース４３６データ構造に格納する。サインオン試行が成功した場合、信用証明書マネージャコンポーネントは、ユーザを表す信用証明書を生成し、その信用証明書情報を、ストレージにある信用証明書データベース４３８データ構造に格納し、（たとえば、カスタマサービスへリダイレクトバックされるユーザへの応答として）カスタマサービスのコンピューティングシステムのストレージ４７１に信用証明書４７３として格納するため、ならびに、オプションで、ユーザに関して収集されたすべての情報を提供するために、その信用証明書をカスタマサービスに返す。

次に、カスタマサービスが、アカウントマネージャシステムおよび／またはアクセスマネージャシステムと対話して、ユーザを表す信用証明書を提供することなどにより、ユーザの代理として様々なアクションを実行すること（たとえば、ユーザのアカウント情報を修正および／または使用すること）が可能である。状況によっては、カスタマサービスがユーザを、提携サービスコンピューティングシステムによって提供されている提携サービスにダイレクトすることが可能であり、この場合は、ユーザに関してカスタマサービスに発行された信用証明書が、提携サービスに与えられ、提携サービスコンピューティングシステムのストレージ４９１上に信用証明書４９３とともに格納される。次に、ユーザは、オプションで、ユーザの代理としてアクションを実行するアクセスマネージャシステムおよび／またはアカウントマネージャシステムと対話するために、提携サービスによって同様にリダイレクトされることが可能である。カスタマサービス（またはその担当者）はさらに、カスタマステータスマネージャコンポーネントと対話して、（サービス自身の、アクセスマネージャシステムにおけるカスタマアカウントに関する情報、および収集済みユーザ情報データベースにある収集済みユーザ情報を含む）サービスに関する様々な情報を取得することが可能である。さらに、少なくとも一部の実施形態では、アクセスマネージャシステムおよびアカウントマネージャシステムが、カスタマサービスのユーザのアクションに関する様々なタイプの情報を追跡および提供する、さらなるカスタマイズされた機能性を提供することを、いくつかのカスタマサービスのそれぞれが要求することが可能であり、これは、たとえば、カスタマサービスが自身のサインオンサービスを実装していたとすれば有するであろうユーザ関連情報のほとんどまたはすべてを、カスタマサービスが利用できるようにするためである。その場合、そのようなユーザ情報は、代替ユーザプールデータベース４３４データ構造に格納され、カスタマステータスマネージャコンポーネントによって、それらのカスタマサービスが利用できるようにされるが、他のユーザ（または、他のサービスと対話している場合の同じユーザ）に関する同様の詳細情報は、図示された実施形態では、それらのカスタマサービスが利用できるようにはされない。

少なくとも一部の実施形態では、カスタマサービスとアクセスマネージャシステムおよび／またはアカウントマネージャシステムとの対話に関する様々な追加セキュリティ対策を与えるために、カスタマ検証マネージャコンポーネントが使用される。具体的には、そのような実施形態では、カスタマサービスからの少なくともいくつかのメッセージが、メッセージ内の情報に基づいて、そのサービスおよびカスタマ検証マネージャコンポーネントに知られている秘密アクセス鍵（たとえば、サービスの初期登録時に決定され、サービス情報データベース４４０に格納されている秘密アクセス鍵）を使用して生成されたデジタル署名を含まなければならず、そのようなデジタル署名は、図示された実施形態では、カスタマサービスのコンピューティングシステム４７０のメモリ４７７内で実行されている署名ジェネレータコンポーネント４７８により、カスタマサービスの秘密アクセス鍵（図示せず）を使用して、カスタマサービスによって生成される。その場合、カスタマ検証マネージャコンポーネントは、他のシステムまたはコンポーネントが、受け取ったメッセージに応答する前に、そのメッセージを認証するために、含まれるデジタル署名を検証する（これは、たとえば、カスタマ検証マネージャコンポーネントに知られている、そのカスタマの秘密アクセス鍵を使用して、一致する別のデジタル署名を生成することにより、デジタル署名を複製することによって行われる）。そのようなメッセージ認証はさらに、少なくとも一部の実施形態および状況においては、少なくとも一部の提携サービスに対して実行されることも可能である。さらに、実施形態によっては、他のタイプのメッセージも、１つまたは複数の関連するサービスの秘密アクセス鍵を使用して同様にデジタル署名されることが可能であり、そのデジタル署名に基づいて認証されることが可能である。たとえば、このようなメッセージとして、受信者サービスによって認証される、アクセスマネージャシステムおよび／またはアカウントマネージャシステムからカスタマサービスまたは提携サービスへのメッセージや、（サービスが他のサービスの秘密アクセス鍵にアクセスできない場合に）カスタマ検証マネージャコンポーネントの支援によって認証される、カスタマサービスと提携サービスとの間のメッセージなどがある。

図示されたコンピューティングシステムは、例に過ぎず、本発明の範囲を限定するものではないことを理解されたい。アクセスマネージャコンピューティングシステム４００は、インターネットやウェブのような１つまたは複数のネットワークを介することを含め、図示されていない他のデバイスと接続されることが可能である。より一般的には、各種コンピューティングシステムのそれぞれは、説明された形式で対話を行うことが可能なハードウェアおよびソフトウェアの任意の組合せを備えることが可能であり、それらには、コンピュータ、ネットワークデバイス、インターネット電気器具、ＰＤＡ（「携帯情報端末」）、携帯電話、ページャ、電子手帳、テレビベースのシステム、および他の、相互通信機能を含む様々なコンシューマ製品などが含まれる。さらに、図４に示されたアクセスマネージャシステムコンポーネントによって提供される機能性は、実施形態によっては、より少ないコンポーネントの組合せであったり、別の複数のコンポーネントに分散されたりすることが可能である。同様に、実施形態によっては、図示されたコンポーネントのうちのいくつかの機能性が提供されない場合があり、かつ／または、他の追加の機能性が利用できる場合がある。

これも当業者であれば理解されるように、様々なアイテムがメモリ内またはストレージに格納されて使用されているように図示されているが、これらのアイテムまたはその一部は、メモリ管理およびデータ保全のために、メモリと他のストレージデバイスとの間で転送されることが可能である。代替として、他の実施形態では、ソフトウェアコンポーネントの一部またはすべてが、別のデバイスのメモリ内で実行され、相互コンピュータ通信により、図示されたコンピューティングシステムまたはデバイスと通信することが可能である。アクセスマネージャシステムコンポーネントまたはデータ構造の一部またはすべてがさらに、（たとえば、命令または構造化データとして）ハードディスク、メモリ、ネットワーク、または適切なドライバによって読み取られる可搬物のような、コンピュータ可読媒体に格納されることが可能であってよい。また、アクセスマネージャコンポーネントおよびデータ構造は、無線ベースおよび有線／ケーブルベースの媒体を含む、様々なコンピュータ可読伝送媒体上に（たとえば、搬送波の一部として）生成されたデータ信号として、伝送されることが可能である。したがって、本発明は、他のコンピュータシステム構成でも実施されることが可能である。

図５は、カスタマ登録マネージャルーチン５００の例示的実施形態のフロー図である。このルーチンは、サービスの運営者および他の担当者と対話して、サービスのユーザに提供されるサインオン機能性および他の機能性をカスタマイズするなどのために、たとえば、図４のカスタマ登録マネージャコンポーネント４２１の実行によって与えられることが可能である。

このルーチンはステップ５０５から始まり、ステップ５０５では、サービスの運営者または他の担当者から、サービスをカスタマとしてアクセスマネージャに登録する指示を受け取る。ステップ５０５の後、ルーチンは、ステップ５１０で、サービス（たとえば、Ｗｅｂサイトによって提供されるサービス、またはＷｅｂサイトの一部としてのサービス）に関する情報を受け取る。これは、たとえば、（たとえば、図２Ａに示されたような）情報を尋ねるページを表示することによる対話形式で、または、プログラム的にアクセスされるＡＰＩの一部として、受け取られる。ステップ５１０で情報が受け取られた後、ルーチンは、そのカスタマを受け入れるかどうかを、たとえば、（ステップ５１０で取得された情報を用いて）そのサービスおよび／または運営者が十分信用できると判断されるかどうかに基づいて、かつ／または他の基準に基づいて、決定する。カスタマが受け入れられない場合、ルーチンは、ステップ５２０に進み、登録拒否メッセージを送信し、その後、ステップ５９０に進む。カスタマが受け入れられる場合、ルーチンは、ステップ５３０で、たとえば、そのサービスおよび／または運営者に関して評価された信頼度に基づいて、かつ、オプションで、（たとえば、サービスのタイプ、サービスのユーザ数、カスタマが使用することを可能にされているコブランディングおよび／または他のカスタマイズのタイプ（たとえば、カスタマが実効可能コードを指定して使用することを許可されているかどうか）、などに基づく）サービスのアクションの結果である、アクセスマネージャの何らかの不利益、過去の、アクセスマネージャとカスタマとの間の何らかのエクスペリエンス、その他の要因に基づいて、カスタマに付与するパーミッションのレベルを決定する。さらに、実施形態によっては、カスタマが、（たとえば、プレミアムサービスの一環として）より高いレベルのパーミッションを受け取り、したがって、追加の機能性を得るために、より多くの料金を課せられることが可能である。割増料金は、機密ユーザ情報を、許可されていないユーザにさらすことや、許可されていないユーザが、ユーザの代理として、金銭取引または他の操作を行うことを許すことなどにより、アクセスマネージャを不利益にさらすことになる、カスタマの能力および／または可能性に、少なくとも部分的に基づくことが可能である。少なくとも一部の実施形態では、カスタマのパーミッションのレベルは、後で見直しおよび変更されることが可能である。ステップ５３０でパーミッションのレベルが決定された後、ルーチンは、付与されたパーミッションに応じて、カスタマが何らかのブランドを構成することを許可するかどうかを決定し、許可する場合は、カスタマがそのようなブランドを有するかどうかを判定する。有する場合、ルーチンは、ステップ５４０に進み、ブランドを適宜構成する。

有しない場合、またはステップ５４０の後、ルーチンは、ステップ５４５に進み、決定されたパーミッションレベルに従って、カスタマが利用できるコブランディングカスタマイズのタイプを（たとえば、それらのブランドのうちの１つ目について、かつ／またはすべてのブランドについて（ブランドがステップ５４０で構成済みの場合））表示する。実施形態によっては、この表示は、Ｗｅｂページであってよく、図２Ｂおよび／または２Ｃのユーザインターフェースと同様のユーザインターフェースを含んでよい。利用可能なコブランディングカスタマイズのタイプを表示した後、オプションで、コブランディングカスタマイズの１つまたは複数の指示を、ステップ５５０で、ルーチンが受け取り、後で使用するために保存する。実施形態によっては、複数のページまたは他の複数の情報群がコブランディングされることが可能な場合、各ページは、別々に構成されてよい。ステップ５５５で、決定されたパーミッションレベルに従って、カスタマが利用できる情報収集の定義済みタイプを表示し、オプションで、情報収集のカスタマイズの１つまたは複数の指示を、ステップ５６０で受け取り、後で使用するために保存する。ステップ５６５で、決定されたパーミッションレベルに従って、カスタマが利用できる権限委譲の定義済みタイプを表示し、オプションで、権限委譲のカスタマイズの１つまたは複数の指示を受け取り、後で使用するために保存する。ステップ５６８で、複数のブランドが構成済みであって個別にカスタマイズされる場合、ルーチンは、ステップ５４５に戻って、次のブランドの構成を開始し、そうでない場合、ルーチンは、ステップ５７０に進み、必要に応じて追加処理を実行する（たとえば、様々な情報を適切なデータストアに格納したり、一意識別子および秘密アクセス鍵を生成してカスタマに与えたりする）。次に、ルーチンは、ステップ５９０に進み、続行するかどうかを決定する。続行する場合、ルーチンは、ステップ５０５に戻り、続行しない場合はステップ５９９で終了する。

図示されたルーチンは、代替実施形態では、別の方法で実行されることが可能である。たとえば、このルーチンは、各ブランドが複数のタイプのカスタマイズに関して構成されることが可能であることを示しているが、実施形態によっては、ブランドは、個別に構成されたコブランディングカスタマイズを有することのみが可能であってよい。他の実施形態では、カスタマイズは、異なる順序で指定されることが可能であり、アクセスマネージャカスタマが特定タイプのカスタマイズを構成するパーミッションを有しない場合は、そのタイプのカスタマイズに関連するステップがスキップされてよい。たとえば、カスタマがユーザから情報を収集するパーミッションを有しない場合、ルーチンは、ステップ５５０から５６５をスキップしてよい。ここでは図示されていないが、実施形態によっては、ルーチンは、他の様々なセキュリティ情報および／またはメカニズムを追加で使用することが可能であり、これは、たとえば、カスタマの担当者の識別情報を検証するためである。

図６は、ユーザ対話マネージャルーチン６００の例示的実施形態のフロー図である。このルーチンは、たとえば、図４のユーザ対話マネージャコンポーネント４２２の実行によって与えられることが可能であり、たとえば、カスタマサービスによって指定される、カスタマイズされたサインオンプロセスを提供するために、カスタマサービスの代理としてユーザと対話することが可能である。

ステップ６０５で、ルーチンは、カスタマイズサービスの代理として、ユーザに関する（たとえば、ユーザがサービスにサインオンすることの）要求の通知を受け取る。図示された実施形態では、この要求は、カスタマに関連付けられたカスタマ識別子と、カスタマに固有の形式で生成された、この要求に対するデジタル署名とを含む。次に、要求に添付されたデジタル署名は、（図９Ｂに示されるように）カスタマ検証マネージャルーチンによってチェックされ、ステップ６１０で、有効ではないと判定された場合には、ルーチンはステップ６８０に進み、失敗通知を送信して、ステップ６９０に進む。署名が有効であれば、ルーチンは、ステップ６１５に進み、要求のタイプを決定する。要求がサインオン以外の何かであれば、要求された操作は、ステップ６８５で適宜実行される。要求がサインオン要求であれば、受け取られたカスタマ識別子に関連付けられたカスタマに関して既に構成されたカスタマイズを、ステップ６２０において取り出し、ステップ６２５で、カスタマイズされたコブランディングがなされたコンテンツを有するサインオンページを生成して、ユーザに送る。次に、ステップ６３０で、ルーチンは、ユーザがアクセスマネージャにアカウントを有するかどうかを判定し、有しない場合、ルーチンは、ステップ６４０で、ユーザに関する情報を取得し、ユーザをアクセスマネージャに登録する。ユーザが既にアクセスマネージャプロバイダにアカウントを有する場合は、ステップ６３５で、ユーザからサインオン情報を受け取り、ステップ６４５で、サインオン情報が有効かどうか（たとえば、そのユーザについて保存されているサインオン情報と一致するかどうか）を判定する。サインオン情報が有効でない場合、ルーチンは、ステップ６８０に進み、失敗通知をユーザに送る。

サインオン情報が有効な場合、またはステップ６４０の後、ステップ６５０で、信用証明書または他の、ユーザのサインオンが有効であることの通知を生成して、サービスに渡す（または、他の実施形態では、ユーザが（たとえば、指定された期間に、または他の指示された条件に従って）１つまたは複数のサービスで使用するために、ユーザに渡す）。次に、ルーチンは、ステップ６５５で、ユーザに関する追加情報（たとえば、ユーザ名、一意識別子、実名など）を取り出してサービスに渡すかどうかを、以前のカスタマイズおよび現在の状況に基づくなどして決定し、渡す場合は、ステップ６６０に進み、追加情報を適宜取り出す。実施形態によっては、この追加情報を取得するカスタマサービスの機能は、カスタマに付与されたパーミッションのレベルによって制限されることが可能である。ステップ６６０の後、または追加情報が取り出されなかった場合、ルーチンは、ステップ６６５で、ユーザに関して収集すべき情報があるかどうかを、以前のカスタマイズおよび現在の状況に基づくなどして決定し、ある場合は、ステップ６７０に進み、ユーザに関する情報を適宜収集する。ステップ６７０の後、または情報が収集されなかった場合は、信用証明書およびオプションで他のデータ（たとえば、取り出された情報および／または収集された情報）を、ＨＴＴＰリダイレクト機能性を用いてユーザ経由で、カスタマに送る。ステップ６７５、６８０、または６８５の後、ルーチンは、ステップ６９０で、続行するかどうかを決定する。続行する場合、ルーチンは、ステップ６０５に戻り、続行しない場合はステップ６９９で終了する。

図７は、信用証明書マネージャルーチン７００の例示的実施形態のフロー図である。このルーチンは、たとえば、図４の信用証明書マネージャコンポーネント４２４の実行によって与えられることが可能であり、たとえば、ユーザを表す信用証明書を生成し、他の信用証明書関連アクティビティを実行することが可能である。

ルーチンは、ステップ７０５から始まり、ステップ７０５で、信用証明書関連の要求を、要求に応じて、外部サービスや別のアクセスマネージャコンポーネントなどから受け取り、この要求は、要求が実行される際に基づく既存の信用証明書を含む追加パラメータを含むことも可能である。要求を受け取った後、ルーチンは、ステップ７１０に進み、受け取った要求が、サービスのユーザを表す新しい信用証明書を生成することかどうかを、ユーザ対話マネージャコンポーネントに基づくなどして判定する。そうであれば、ルーチンは、ステップ７１５で、（たとえば、一意の乱数をユーザにマッピングしたり、ユーザに関する情報を取り出して信用証明書の一部として含めたりすることにより）信用証明書を適宜作成し、ステップ７７０に進み、その信用証明書を保存し、オプションで要求者に渡す。要求が、信用証明書を生成することではなかった場合、ルーチンは、ステップ７２０で、要求が既存の信用証明書をリフレッシュしてその有効期間を延長することかどうかを、その信用証明書が最初に発行された対象のサービスに基づくなどして判定する。そうであれば、ルーチンは、ステップ７２２で、要求者が信用証明書をリフレッシュするパーミッションを有するかどうかを（たとえば、要求者に付与されたパーミッションのレベル、および／または信用証明書で表されるユーザによって（たとえば、サービスへのサインオンの際に）指定された情報に基づいて）判定する。パーミッションが存在する場合は、ルーチンは、ステップ７２４で、信用証明書をリフレッシュしてから、ステップ７７０に進む。ユーザの信用証明書をリフレッシュするのに十分なパーミッションがない場合、ルーチンは、ステップ７２９でエラーメッセージを通知し、ステップ７９５に進む。

ステップ７２０で、要求が、信用証明書をリフレッシュすることではないと判定された場合、ルーチンは、ステップ７３０に進み、（たとえば、セカンダリ提携サービスからの、セカンダリ提携サービスが提携しているプライマリカスタマサービスに発行された、ユーザに関する信用証明書の使用権を取得する要求のように）要求が既存の信用証明書をクローニングすることかどうかを判定する。そうであれば、ルーチンは、ステップ７３２に進み、信用証明書のクローニングが許可されているかどうかを、プライマリサービスからセカンダリサービスに委譲された権限に基づくなどして判定する。さらに、実施形態によっては、ユーザを表す信用証明書のクローニングは、ユーザに対し、情報を提供することと、オプションで、クローニングを承認または他の方法で了解することと、を要求することを必要とする可能性があり、そのような実施形態では、クローニングが許可されているかどうかの判定はさらに、ユーザのアクションに少なくとも部分的に基づくことが可能である。ステップ７３２で、パーミッションが存在すると判定された場合、ルーチンは、ステップ７３４で、信用証明書をクローニングして、ステップ７７０に進み、パーミッションが存在しないと判定された場合、ルーチンは、ステップ７３９で、エラーが発生したことの通知を送信し、ステップ７９５に進む。

ステップ７３０で、要求が、信用証明書をクローニングすることではないと判定された場合、ルーチンは、ステップ７４０に進み、要求が、信用証明書が有効かどうかを検証することかどうかを判定する。そうであれば、ルーチンは、ステップ７４５で、信用証明書が要求者にとって（かつオプションで、指示されたアクションにとって）現時点で有効かどうかを判定し、信用証明書の有効性の通知を要求者に送る。要求が、信用証明書が有効かどうかを判定することではなかった場合、ルーチンは、ステップ７５０で、要求が、信用証明書の期限がいつ切れるかを判定することかどうかを判定する。そうであれば、ルーチンは、ステップ７５５で、期限切れを判定し、それを要求者に通知し、そうでない場合、ルーチンは、ステップ７６０に進み、他のタイプの要求に適宜応答する。ステップ７２９、７３９、７４５、７５５、７６０、または７７０の後、ルーチンは、ステップ７９５で、続行するかどうかを決定する。続行する場合、ルーチンは、ステップ７０５に戻り、続行しない場合はステップ７９９で終了する。

図８は、カスタマステータスマネージャルーチン８００の例示的実施形態のフロー図である。このルーチンは、たとえば、図４のカスタマステータスマネージャコンポーネント４２５の実行によって与えられることが可能であり、たとえば、様々なタイプの情報をカスタマに提供することが可能である。

ルーチンは、ステップ８０５から始まり、ステップ８０５では、カスタマから要求を受け取る。ステップ８１０で、ルーチンは、要求が許可されているかどうかを、たとえば、カスタマ検証マネージャコンポーネントと対話することにより、かつ／またはカスタマに付与されたパーミッションのレベルに基づいて、判定する。許可されていない場合、ルーチンはステップ８９５に進み、許可されている場合は、ステップ８１５〜８６０で、様々なタイプの情報を修正することをカスタマが要求したかどうかを判定し、要求した場合は、その修正を適宜実行する。図示された実施形態においてカスタマによって修正されることが可能な情報のタイプとして、コブランディングのカスタマイズ（ステップ８１５および８２０）、情報収集のカスタマイズ（ステップ８２５および８３０）、権限委譲のカスタマイズ（ステップ８３５および８４０）、ブランド（ステップ８４５および８５０）、およびカスタマアカウント情報（ステップ８５５および８６０）がある。受け取られた要求が、情報を修正することではない場合、ルーチンは、ステップ８６５で、要求が、ユーザを監視することかどうかを判定する。そうであれば、ルーチンは、ステップ８７０で、あらかじめ追跡されたユーザ情報を取り出してカスタマに提供し、そうでない場合、ルーチンは、ステップ８７５に進み、他の要求された機能性を適宜実行する。ステップ８２０、８３０、８４０、８５０、８６０、８７０、および８７５の後、または、ステップ８１０で、要求が許可されていないと判定された場合、ルーチンは、ステップ８９５に進み、続行するかどうかを決定する。続行する場合、ルーチンは、ステップ８０５に戻り、続行しない場合はステップ８９９で終了する。

図９Ａおよび９Ｂは、受け取ったメッセージを認証するルーチンの例示的実施形態のフロー図であり、図９Ｂは、検証マネージャルーチン９２５の例示的実施形態を示しており、図９Ａは、対応するクライアントサイド検証ルーチン９００を示している。検証マネージャルーチンは、たとえば、図４のカスタマ検証マネージャコンポーネント４２６の実行によって与えられることが可能であり、たとえば、カスタマサービスおよび他のサービスからの着信メッセージに関する様々な追加セキュリティ対策を与えることが可能である。クライアントサイド検証ルーチンは、たとえば、カスタマサービスのコンピューティングシステムと図４の署名ジェネレータコンポーネント４７８との組合せによって与えられることが可能であり、たとえば、アクセスマネージャへの送信メッセージに対して追加セキュリティ対策を行うことが可能である。

図９Ａのクライアントサイドルーチン９００は、ステップ９０５から始まり、ステップ９０５では、様々な情報を含めるべき送信メッセージを生成する指示をカスタマサービスから受け取り、セキュリティのためにメッセージに添付するカスタマ固有のデジタル署名を生成する際に用いる様々な情報を収集する。実施形態によっては、署名の生成に使用される情報は、メッセージ内容の少なくとも一部と、秘密アクセス鍵のような、メッセージに含まれない他の情報とを含む。さらに、実施形態によっては、署名の生成に使用する情報に、（たとえば、メッセージが傍受された場合に後で再利用されることを避けるための）現在のタイムスタンプのような、他の情報を追加することが可能である。送られるメッセージは、様々な形式を有することが可能であり、たとえば、ＵＲＬまたは他のＵＲＩ（「統一資源識別子（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）」）を使用して送られるＨＴＴＰ要求であって、メッセージ内容が１つまたは複数のクエリ文字列パラメータ値の一部として含まれ、デジタル署名が別のクエリ文字列パラメータの値として含まれる、ＨＴＴＰ要求の形式を有することが可能である。ステップ９１０で、ルーチンは、収集された情報に基づいてデジタル署名を生成する。これは、たとえば、あらかじめ選択されたデジタル署名アルゴリズムを使用し、あらかじめ選択されたタイプのメッセージ情報（たとえば、特定の順序の特定のメッセージパラメータ値）を使用することによって行われる。ステップ９１５で、ルーチンは、署名をメッセージに追加してからメッセージを送信し、次の署名付きメッセージが送られるまで、ステップ９２０で終了する。

図９Ｂの検証マネージャルーチン９２５は、ステップ９２７から始まり、ステップ９２７では、着信メッセージの検証の要求（たとえば、カスタマサービスまたは提携サービスから受け取ったメッセージに関して、アクセスマネージャシステムまたはそのコンポーネントの１つから受け取った要求）を受け取る。ステップ９３０で、ルーチンは、最初に、メッセージが十分に最近のものかどうかを、たとえば、メッセージに添付されているタイムスタンプからの経過時間が所定時間を超えていないかどうかに基づいて、判定する。タイムスタンプが古すぎる場合、ルーチンは、ステップ９７０で、署名が無効であることの通知を送信し、オプションで、ステップ９７５で、追加の処理を適宜実行する（たとえば、無効なメッセージのパターンが見つかった場合は通知を生成する）。その後、ルーチンはステップ９９５に進む。

タイムスタンプが十分に最近のものであった場合、ルーチンは、ステップ９３５に進み、受け取ったメッセージの送信元であるカスタマに対応する、保存されていた秘密アクセス鍵を、メッセージに含まれていて、その秘密アクセス鍵に関連付けられている、そのカスタマに割り当てられた識別子に基づくなどして、取り出す。他の実施形態では、カスタマサービスまたは他の提携サービスは、受け取られた要求の送信元のＩＰアドレスに基づくなど、他の方法で識別されることが可能である。ステップ９３５で、秘密アクセス鍵およびカスタマに関する任意の追加情報を取り出した後、ルーチンは、図９Ａのステップ９０５および９１０に関して前述されたものと同じ方法で、ステップ９４０および９４５で、メッセージのデジタル署名を生成する。これは、たとえば、（デジタル署名を含まない）メッセージに含まれた情報および取り出された秘密アクセス鍵を使用するためである。ステップ９５０で、新しく生成した署名を、メッセージに含まれている署名と照合する。ステップ９５５で、その２つのデジタル署名が同じであると判定した場合は、メッセージを検証し、ステップ９６０で、対応する確認を送信する。メッセージが正しいことが立証されない場合は、メッセージを偽造と見なし、ステップ９６５で、対応する通知を送信する。ステップ９６０、９６５、または９７５の後、ルーチンは、ステップ９９５に進み、続行するかどうかを決定する。続行する場合、ルーチンは、ステップ９２７に戻り、続行しない場合はステップ９９９で終了する。

ここでは図示されていないが、実施形態によっては、アクセスマネージャからのメッセージを検証するために、同様の手法がサービスによって用いられてよい。さらに、様々な実施形態が、図９Ａおよび９Ｂに示された署名ベースの検証より強力な、追加のセキュリティ機能およびメカニズムを有してよく、これは、たとえば、サービスの担当者が最初にサービスを登録した場合に、その担当者の身元に関する情報を収集することである。

このように、様々な手法を用いて、カスタマイズ可能なサインオン機能性および他の機能性をサービスに提供することが可能であり、また、様々な手法を用いて、対話のセキュリティを強化することが可能である。さらに、実施形態によっては、さらに様々な情報および手法を用いることが可能である。たとえば、アクセスマネージャのカスタマが、Ｗｅｂサイト（電子商取引サイトなど）を含むことが可能であり、アクセスマネージャのプロバイダに無関係であることが可能である。アクセスマネージャによってカスタマに付与されるパーミッションのレベルは、たとえば、未知のサイトよりは、よく知られ、評価の高いサイトに、より高いレベルのパーミッションを付与するというように、一定でなくてもよい。さらに、低レベルのコブランディングパーミッションは、使用するイメージおよびテキストを指定することをアクセスマネージャカスタマに許可することだけが可能であるが、高いレベルのパーミッションを有するアクセスマネージャカスタマは、イメージ、イメージマップ（ユーザがイメージの任意の部分または指定部分を選択したときに機能性を提供する）、指定されたタイプのユーザ選択可能機能性（たとえば、ドロップダウンボタンを有する見出し）、テキスト、リンク、バックグラウンドミュージック、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔコード、Ｆｌａｓｈアニメーション、Ｓｈｏｃｋｗａｖｅムービー、Ｊａｖａ（登録商標）アプレット、カスタムＣＳＳ（「カスケーディングスタイルシート」）スタイルなどを追加することが可能である。実施形態によっては、パーミッションの付与は、リアルタイムまたはほぼリアルタイムのプロセスで自動的に行われるが、他の実施形態では、このプロセスは（たとえば、サービスの手動見直しを考慮に入れるために）より時間がかかる可能性がある。さらに、実施形態によっては、カスタマに付与されるパーミッションのレベルは、（たとえば、定期的に）見直しおよび修正されることが可能である。たとえば、カスタマに関して問題または懸念が持ち上がった場合は、パーミッションのレベルを下げることが可能である。逆に、そのような問題が発生していない場合は、パーミッションのレベルを上げることが可能である。たとえば、一部またはすべての新規カスタマに低レベルのパーミッションを付与し、カスタマとの継続的なエクスペリエンスによって保証される場合はパーミッションのレベルを徐々に上げていくことが可能である。たとえば、カスタマによる、またはカスタマの代理でのトラフィックおよび／または利用パターンの分析または見直しに基づいて、パーミッションのレベルを上げることが可能である。実施形態によっては、付与されたパーミッションのレベルの見直しは、外部要因（たとえば、カスタマに関するニュースまたはカスタマに起こった変化（たとえば、カスタマの合併または買収、破産など））によってトリガされる場合がある。

様々なタイプのサービスが、提携サービスとして行われることが可能であり、そのようなサービスとして、支払処理、クレジットカード検証サービス、コンシューマ調査サービス、広告サービス、履行サービスなどがあり、これらに限定されない。また、実施形態によっては、アクセスマネージャのプロバイダが、そのサービスのいくつかを提携サービスとして提案してもよい。提携サービスは、場合によっては、カスタマまたはユーザがそれぞれのサービスの提供を容易にするための情報のサブセットへのアクセス権を与えられることが可能であり、たとえば、コンシューマ調査サービスは、特定の製品がいつコンシューマに出荷されたか、ならびに、製品およびサービスに関してコンシューマの追跡を実行するための連絡先情報を知ることが必要であろう。

サービスからアクセスマネージャへ送られるメッセージまたは他の要求は、様々な実施形態において様々な形式をとることが可能である。実施形態によっては、要求が、クエリ文字列として渡されるメッセージパラメータまたは他のコンテンツを有するＨＴＴＰメッセージであることが可能であり、少なくとも一部の情報（たとえば、秘密アクセス鍵、機密のユーザサインオン情報および他のユーザ情報など）が、好ましくは、セキュアな手段（たとえば、セキュアＨＴＴＰ）または（たとえば、物理メール、電話などを介する）オフライン形式で送られる。同様に、ユーザのサインオン情報または他の識別情報が、様々な形式を有することが可能であり、たとえば、ユーザ名およびパスワード、各種バイオメトリック情報、ＰＫＩベースの情報などの形式を有することが可能である。実施形態によっては、信用証明書は、Ｗｅｂブラウザのクッキーとして、または、代替として、ＷＳ−Ｆｅｄｅｒａｔｉｏｎ Ｐａｓｓｉｖｅ Ｐｒｏｆｉｌｅで指定される形式（たとえば、ＷＳ−Ｔｒｕｓｔ ＲｅｑｕｅｓｔＳｅｃｕｒｉｔｙＴｏｋｅｎＲｅｓｐｏｎｓｅ ＸＭＬ要素）で、または別のサインオン仕様標準に基づいて（たとえば、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ ＰｒｏｊｅｃｔやＭｉｃｒｏｓｏｆｔのＰａｓｓｐｏｒｔサービスなどに基づいて）、交換されることが可能である。同様に、実施形態によっては、サインオンプロセスが、様々な方法で（たとえば、ＷＳ−Ｆｅｄｅｒａｔｉｏｎ Ｐａｓｓｉｖｅ Ｒｅｑｕｅｓｔｏｒ Ｐｒｏｆｉｌｅで指定されたプロセスで）実行されることが可能である。

前述のように、実施形態によっては、少なくとも一部のカスタマサービスが、（たとえば、様々なタイプの、ユーザとの対話を追跡するために）代替データプールの開設および使用を、サービスのユーザの代わりに要求することが可能である。たとえば、代替データプールは、購入、表示された製品またはサービス、ログイン時刻、行われた情報修正、さらに場合によっては、カスタマサービスに固有ではない、ユーザの履歴や他のアクティビティの情報などの、ユーザに関する情報を格納することが可能であり、実施形態によっては、カスタマが、どのようなデータを代替データプールに格納するかを構成することを許可されることが可能である。実施形態によっては、カスタマが代替データプールを利用できるかどうかは、カスタマに付与されたパーミッションのレベルに依存することが可能である。

実施形態によっては、秘密アクセス鍵を、（たとえば、定期的に、または破損時に）修正または再生成することが可能である。さらに、秘密アクセス鍵の使用方法に関する情報を適正な受信者だけが利用できるように管理することにより、また、さらにオプションで、カスタマごとに異なるプロセスを使用して、セキュリティをさらに強化することが可能である。実施形態によっては、指示されるプロセスは、メッセージに関するパラメータ値が含まれるべき、パラメータのリスト、メッセージパラメータの順序、および使用するエンコードのタイプなどを含むことが可能であり、プロセスが様々な形式でカスタマに指示されることが可能である（たとえば、サービス運営者がサービスにプロセスを手動で組み込む際に使用するドキュメンテーション、プロセスが実行されるように様々な入力を与えられる実行可能コードなどの形式であることが可能である）。デジタル署名は、様々な形式で生成されることが可能であり、たとえば、メッセージ認証コード（たとえば、ＨＭＡＣ（「ｋｅｙｅｄ−Ｈａｓｈ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ」）−ＭＤ５（「Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ ａｌｇｏｒｉｔｈｍ ５」））を使用して生成されることが可能である。

当業者であればさらに理解されるように、実施形態によっては、前述の諸ルーチンで与えられる機能性は、別の形式で与えられることも可能であり、たとえば、より多くのルーチンに分割されたり、より少ないルーチンに統合されたりして与えられることも可能である。同様に、実施形態によっては、図示されたルーチンは、説明されたものより多くの機能性または少ない機能性を与える場合があり、それは、たとえば、他の図示されたルーチンがそのような機能性を欠いたり、含んだりする場合や、与えられる機能性の数が変更された場合である。さらに、様々な操作が、特定の形式で（たとえば、シリアルに、またはパラレルに）かつ／または特定の順序で実行されるように示されているが、当業者であれば理解されるように、他の実施形態では、それらの動作が、他の順序で、かつ、他の形式で実行されることが可能である。当業者であればさらに理解されるように、前述のデータ構造は、別の形式で構造化されることも可能であり、これは、たとえば、１つのデータ構造を複数のデータ構造に分割することによって、あるいは、複数のデータ構造を１つのデータ構造に統合することによって可能である。同様に、実施形態によっては、図示されたデータ構造は、説明されたものより多くの情報または少ない情報を格納する場合があり、それは、たとえば、他の図示されたデータ構造がそのような情報を欠いたり、含んだりする場合や、格納される情報の数またはタイプが変更された場合である。

以上より理解されるように、本明細書では、例示を目的として特定の実施形態について説明してきたが、本発明の趣旨および範囲から逸脱することなく、様々な修正がなされることが可能である。したがって、本発明は、添付の特許請求項およびその中で記載されている要素によって限定されることを除き、限定されない。さらに、本発明の特定の態様が特定の請求項形式で示されているが、発明者らは、どのような利用可能な請求項形式でも本発明の様々な態様を想定している。たとえば、現時点では、本発明の一部の態様だけが、コンピュータ可読媒体のかたちで具体化されるように記載されているが、他の態様も同様にそのように具体化されることが可能である。

アクセスマネージャシステム、サービス、およびユーザの間で行われる様々なタイプの対話の例を示す図である。 アクセスマネージャシステム、サービス、およびユーザの間で行われる様々なタイプの対話の例を示す図である。 アクセスマネージャシステム、サービス、およびユーザの間で行われる様々なタイプの対話の例を示す図である。 カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャと、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す図である。 カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャと、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す図である。 カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャと、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す図である。 カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャと、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す図である。 カスタマサービスのユーザに提供される機能性をカスタマイズするために、アクセスマネージャと、アクセスマネージャのカスタマとして動作するサービスとの間で行われる対話の例を示す図である。 カスタマサービスの代理としてのアクセスマネージャからユーザに提供される、カスタマイズされたサインオンプロセスの例を示す図である。 カスタマサービスの代理としてのアクセスマネージャからユーザに提供される、カスタマイズされたサインオンプロセスの例を示す図である。 アクセスマネージャサーバコンピューティングシステムの例示的実施形態を示すブロック図である。 カスタマ登録マネージャルーチンの例示的実施形態のフロー図である。 ユーザ対話マネージャルーチンの例示的実施形態のフロー図である。 信用証明書マネージャルーチンの例示的実施形態のフロー図である。 カスタマステータスマネージャルーチンの例示的実施形態のフロー図である。 受け取ったメッセージを認証するルーチンの例示的実施形態のフロー図である。 受け取ったメッセージを認証するルーチンの例示的実施形態のフロー図である。

Claims (38)

1. コンピューティングシステムにおいてコンピュータに実装されるアクセス管理の方法であって、実行命令で構成された１または複数のコンピュータシステムの制御下で、
   前記コンピュータシステムによって提供されるアクセスマネージャシステムにより、複数のサービスのうちの第１のサービスの登録を開始するステップであって、前記第１のサービスは、前記複数のサービスをユーザにアクセス可能にする、前記アクセスマネージャシステムにより提供されるユーザサインオン機能を受信するために前記アクセスマネージャシステムに登録されるステップと、
   前記アクセスマネージャシステムから、前記第１のサービスに利用可能な前記ユーザサインオン機能の動作をカスタマイズするための前記第１のサービスについて、前記アクセスマネージャシステムによって、パーミッションのレベルを決定するステップであって、前記利用可能なユーザサインオンカスタマイズ機能は、前記第１のサービスについての前記ユーザサインオン機能のコブランディングを含むステップと、
   前記アクセスマネージャシステムから利用可能な前記ユーザサインオン機能の動作のカスタマイズについて、前記第１のサービスが利用可能なサインオン機能の複数のカスタマイズの通知を、前記決定したパーミッションレベルに少なくとも部分的に基づいて表示するステップと、
   前記第１のサービスの運営者から、１つまたは複数のサインオンカスタマイズの１つまたは複数の選択を受け取るステップと、
   前記アクセスマネージャシステムの制御下で、前記１つまたは複数の選択されたカスタマイズに少なくとも部分的に基づくカスタマイズされた方法で、サインオン機能を前記第１のサービスのユーザに提供するステップと
   を含むことを特徴とする方法。
2. 前記複数のカスタマイズは、前記第１のサービスのユーザからの、ユーザサインオン間の情報収集を含み、前記アクセスマネージャシステムは該情報収集を実行するよう構成されることを特徴とする請求項１に記載の方法。
3. 前記アクセスマネージャは、前記複数のサービスを提供する複数のサードパーティＷｅｂサイト運営者にシングルサインオンサービスを提供する、方法であって、
   前記第１のサービスのユーザからサインオン要求を受け取るステップと、
   前記第１のサービスに関して選択された１つまたは複数のコブランディングカスタマイズを行うような方法で、前記第１のサービスの代理として、前記ユーザに、カスタマイズされたサインオン機能を提供するステップと、
   前記第１のサービスに関して選択された１つまたは複数の情報収集タイプのカスタマイズに基づいて、前記ユーザから情報を取得するステップと、をさらに含むことを特徴とする請求項２に記載の方法。
4. 前記アクセスマネージャにある前記ユーザの有効なアカウントを反映させるために前記第１のサービスを認証するステップと、
   前記ユーザを表す信用証明書を第１のサービスに与えるステップと、をさらに含み、前記信用証明書は、前記第１のサービスが、前記ユーザの代理として、前記アクセスマネージャとのアクションを実行することを可能にすることを特徴とする請求項３に記載の方法。
5. 前記選択されたカスタマイズを含み、ユーザ名およびパスワードの入力を促すサインオンページを生成するステップと、
   前記ユーザに関連付けられた第１のユーザ名および第１のパスワードを受け取るステップと、
   前記ユーザの前記アカウントに関する情報と、前記受け取られた第１のユーザ名および第１のパスワードとの間の一致に少なくとも部分的に基づいて、前記ユーザを認証するステップと、
   前記ユーザが認証されたことの通知を前記第１のサービスに送るステップと、をさらに含むことを特徴とする請求項４に記載の方法。
6. 前記第１のサービスに対する最初のサインオンの場合に、前記サインオンページは、選択された情報収集カスタマイズに基づいて情報の入力を促す、方法であって、前記情報収集カスタマイズに対応する情報を受け取るステップと、前記受け取られた情報を前記第１のサービスに対して利用可能にするステップと、をさらに含むことを特徴とする請求項５に記載の方法。
7. カスタマイズの１つまたは複数の情報収集タイプは、前記第１のサービスに関して選択された少なくとも１つの質問に基づく、ユーザからの情報収集を含むことを特徴とする請求項６に記載の方法。
8. 前記第１のサービスに対する前記複数のカスタマイズは、前記第１のサービスによって通知されるテキストが前記第１のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項１に記載の方法。
9. 前記第１のサービスに対する前記複数のカスタマイズは、前記第１のサービスによって通知されるリンクが前記第１のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項１に記載の方法。
10. 前記第１のサービスに対する前記複数のカスタマイズは、前記第１のサービスによって通知される新しいユーザ選択可能機能性が前記第１のサービスのユーザに対して利用可能にされることを可能にすることを含むことを特徴とする請求項１に記載の方法。
11. 前記第１のサービスに対する前記複数のカスタマイズは、前記第１のサービスに関するイメージが前記第１のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項１に記載の方法。
12. 前記第１のサービスに対する前記パーミッションのレベルを前記決定するステップは、それぞれが異なる信頼度に対応する、複数のあらかじめ定義されたパーミッションレベルのうちの１つを選択するステップを含み、前記選択するステップは、前記第１のサービスに関して取得された複数のタイプの情報を使用して評価された、前記第１のサービスの信頼度に基づくことを特徴とする請求項１に記載の方法。
13. 前記複数のカスタマイズは、前記第１のサービスが、前記アクセスマネージャシステムを介して、別のサービスに権限を委譲することを可能にすることを含むことを特徴とする請求項１に記載の方法。
14. 請求項１から１３に記載の方法のいずれかを実行するコンピュータプログラム。
15. コンピューティングシステムにおいてコンピュータに実装されるサービスを提供する方法であって、実行命令で構成された１または複数のコンピュータシステムの制御下で、
    前記サービスの、アクセスマネージャへの登録を要求するステップと、
    前記サービスにおけるサインオン機能の動作をカスタマイズするための、アクセスマネージャによって付与されるパーミッションのレベルを受け取るステップと、
    前記パーミッションレベルに少なくとも部分的に基づいて、複数の利用可能なサインオンカスタマイズ機能から１つまたは複数のオプションを選択するステップであって、前記利用可能なサインオンカスタマイズ機能は、コブランディングカスタマイズを含むステップと、を含み、
    前記サービスのユーザとのサインオン対話は、前記選択された１つまたは複数のオプションと整合性があることを特徴とする方法。
16. サインオン機能のカスタマイズが正常に終了したことの通知を受け取るステップをさらに含むことを特徴とする請求項１５に記載の方法。
17. 前記利用可能なサインオンカスタマイズ機能は、ユーザから情報を収集するプロセスを含むことを特徴とする請求項１６に記載の方法。
18. 前記コンピューティングシステムは、複数のサービスのユーザにサインオン機能を提供するサインオンサービスの代理として動作し、ユーザとの前記対話は、前記サインオンサービスに対して前記ユーザのサインオンを実行するプロセスの一部であることを特徴とする請求項１６に記載の方法。
19. 前記サービスは、前記サインオンサービスとは異なることを特徴とする請求項１８に記載の方法。
20. 請求項１５から１９に記載の方法のいずれかを実行するコンピュータプログラム。
21. コンピューティングシステムにおけるアクセス管理のシステムであって、実行命令で構成された１または複数のコンピュータシステムの制御下で、
    複数のサービスのうちの第１のサービスの登録を開始する手段であって、前記第１のサービスは、前記複数のサービスをユーザにアクセス可能にする、アクセスマネージャシステムにより提供されるユーザサインオン機能を受信するために前記アクセスマネージャシステムに登録される手段と、
    前記第１のサービスに利用可能な前記ユーザサインオン機能の動作をカスタマイズするための前記第１のサービスについて、前記アクセスマネージャシステムによって、パーミッションのレベルを決定する手段であって、前記利用可能なユーザサインオンカスタマイズ機能は、前記第１のサービスについての前記ユーザサインオン機能のコブランディングを含む手段と、
    前記アクセスマネージャシステムから利用可能な前記ユーザサインオン機能の動作のカスタマイズについて、前記第１のサービスが利用可能なサインオン機能の複数のカスタマイズの通知を、前記決定したパーミッションレベルに少なくとも部分的に基づいて表示する手段と、
    前記第１のサービスの運営者から、１つまたは複数のサインオンカスタマイズの１つまたは複数の選択を受け取る手段と、
    前記１つまたは複数の選択されたカスタマイズに少なくとも部分的に基づくカスタマイズされた方法で、サインオン機能を前記第１のサービスのユーザに提供する手段と
    を備えることを特徴とするシステム。
22. 前記複数のカスタマイズは、前記第１のサービスのユーザからの、ユーザサインオン間の情報収集を含み、前記アクセスマネージャシステムは該情報収集を実行するよう構成されることを特徴とする請求項２１に記載のシステム。
23. 前記複数のサービスを提供する複数のサードパーティＷｅｂサイト運営者にシングルサインオンサービスを提供するシステムであって、
    前記第１のサービスのユーザから複数のサインオン要求を受け取る手段と、
    前記第１のサービスに関して選択された１つまたは複数のコブランディングカスタマイズを行うような方法で、前記第１のサービスの代理として、前記ユーザに、カスタマイズされたサインオン機能を提供する手段と、
    前記第１のサービスに関して選択された１つまたは複数の情報収集タイプのカスタマイズに基づいて、前記ユーザから情報を取得する手段と、をさらに備えることを特徴とする請求項２２に記載のシステム。
24. 前記アクセスマネージャシステムにある前記ユーザの有効なアカウントを反映させるために前記第１のサービスを認証する手段と、
    前記ユーザを表す信用証明書を第１のサービスに与える手段と、をさらに備え、前記信用証明書は、前記第１のサービスが、前記ユーザの代理として、前記アクセスマネージャシステムとのアクションを実行することを可能にすることを特徴とする請求項２３に記載のシステム。
25. 前記選択されたカスタマイズを含み、ユーザ名およびパスワードの入力を促すサインオンページを生成する手段と、
    前記ユーザに関連付けられた第１のユーザ名および第１のパスワードを受け取る手段と、
    前記ユーザの前記アカウントに関する情報と、前記受け取られた第１のユーザ名および第１のパスワードとの間の一致に少なくとも部分的に基づいて、前記ユーザを認証する手段と、
    前記ユーザが認証されたことの通知を前記第１のサービスに送る手段と、をさらに備えることを特徴とする請求項２１に記載のシステム。
26. 前記第１のサービスに対する最初のサインオンの場合に、前記サインオンページは、選択された情報収集カスタマイズに基づいて情報の入力を促す、システムであって、前記情報収集カスタマイズに対応する情報を受け取る手段と、前記受け取られた情報を前記第１のサービスに対して利用可能にする手段と、をさらに備えることを特徴とする請求項２５に記載のシステム。
27. カスタマイズの１つまたは複数の情報収集タイプは、前記第１のサービスに関して選択された少なくとも１つの質問に基づく、ユーザからの情報収集を含むことを特徴とする請求項２５に記載のシステム。
28. 前記第１のサービスに対する前記複数のカスタマイズは、前記第１のサービスによって通知されるテキストが前記第１のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項２１に記載のシステム。
29. 前記第１のサービスに対する前記複数のカスタマイズは、前記第１のサービスによって通知されるリンクが前記第１のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項２１に記載のシステム。
30. 前記第１のサービスに対する前記複数のカスタマイズは、前記第１のサービスによって通知される新しいユーザ選択可能機能性が前記第１のサービスのユーザに対して利用可能にされることを可能にすることを含むことを特徴とする請求項２１に記載のシステム。
31. 前記第１のサービスに対する前記複数のカスタマイズは、前記第１のサービスに関するイメージが前記第１のサービスのユーザに対して表示されることを可能にすることを含むことを特徴とする請求項２１に記載のシステム。
32. 前記第１のサービスに対する前記パーミッションのレベルを前記決定する手段は、それぞれが異なる信頼度に対応する、複数のあらかじめ定義されたパーミッションレベルのうちの１つを選択する手段を含み、前記選択は、前記第１のサービスに関して取得された複数のタイプの情報を使用して評価された、前記第１のサービスの信頼度に基づくことを特徴とする請求項２１に記載のシステム。
33. 前記複数のカスタマイズは、前記第１のサービスが、前記アクセスマネージャシステムを介して、別のサービスに権限を委譲することを可能にすることを含むことを特徴とする請求項２３に記載のシステム。
34. コンピューティングシステムにおいてコンピュータに実装されるサービスを提供するシステムであって、実行命令で構成された１または複数のコンピュータシステムの制御下で、
    前記サービスの、アクセスマネージャシステムへの登録を要求する手段と、
    前記サービスにおけるサインオン機能の動作をカスタマイズするための、アクセスマネージャによって付与されるパーミッションのレベルを受け取る手段と、
    前記パーミッションレベルに少なくとも部分的に基づいて、複数の利用可能なサインオンカスタマイズ機能から１つまたは複数のオプションを選択する手段であって、前記利用可能なサインオンカスタマイズ機能は、コブランディングカスタマイズを含む手段と
    を備え、
    前記サービスのユーザとのサインオン対話は、前記選択された１つまたは複数のオプションと整合性があることを特徴とするシステム。
35. サインオン機能のカスタマイズが正常に終了したことの通知を受け取る手段をさらに備えることを特徴とする請求項３４に記載のシステム。
36. 前記利用可能なサインオンカスタマイズ機能は、ユーザから情報を収集するプロセスを含むことを特徴とする請求項３４に記載のシステム。
37. 前記コンピューティングシステムは、複数のサービスのユーザにサインオン機能を提供するサインオンサービスの代理として動作し、ユーザとの前記対話は、前記サインオンサービスに対して前記ユーザのサインオンを実行するプロセスの一部であることを特徴とする請求項３４に記載のシステム。
38. 前記サービスは、前記サインオンサービスとは異なることを特徴とする請求項３７に記載のシステム。

Images