JP6438940B2 - シングルサインオンのためのウェブベースインターフェース統合 - Google Patents

Description

関連出願の相互参照
本願は、参照により全文が組み込まれる、本願に援用される２０１３年９月２０日に出願された米国仮特許出願第６１／８８０，８００号、表題「ウェブベースシングルサインオンのシステムおよび方法」［代理人整理番号８８３２５−８８７０５１（１４３８０１ＵＳ）］の優先権を主張する。

背景
企業においてユーザ（例えば従業員）は通常、１つ以上の異なるシステムやアプリケーションにアクセスすることがある。これらのシステムやアプリケーションはそれぞれ異なるアクセス制御ポリシーを使用し、異なる認証情報（例えばユーザ名とパスワード）を要求することがある。このためユーザは通常使用するシステムやアプリケーションのために多数の異なる認証情報を管理することになり、パスワード疲労を被り、認証情報の入力や再入力で時間を浪費し、失われた認証情報の回復および／またはリセットのため余分なＩＴリソースが費やされることがある。シングルサインオン（ＳＳＯ）は最初のログイン後に複数のシステムおよびアプリケーションへのアクセスをユーザに提供できる。例えば業務用コンピュータにログインしたユーザは１つ以上の他のシステムおよびアプリケーションにもアクセスできる。

従来のＳＳＯソリューションはデスクトップベースであり、ユーザのコンピュータでローカルに実行するデスクトップクライアントにより、ユーザが認証情報を管理できるようにし、他のＳＳＯサービスや運営管理を提供するものであった。デスクトップまたはラップトップコンピュータはクライアントを実行し、ユーザのシステムおよびアプリケーションにアクセスする必要があった。ローカルで実行するクライアントはユーザの活動を監視してシングルサインオンサービスを提供できた。ただしユーザは次第に、本格的なデスクトップＳＳＯクライアントを実行できないスマートフォンやタブレットを使ってウェブベースのサービスにアクセスするようになっている。また、従来のＳＳＯシステムは通常、同種のアクセス制御を使用するシステムでシングルオンを提供できたが、異種アクセス制御を使用するアプリケーションをまとめて扱うことはしなかった。このためユーザのいくつかのアプリケーションではシングルサインオンが可能でも、他のシステムやアプリケーションについては手作業でログインすることがユーザに強いられることがある。

概要
一実施形態によると、ウェブベースシングルサインオンは、ユーザが（ウェブブラウザやシンクライアントを通じて）単一のインターフェースにログインすることを可能にし、１つ以上のウェブアプリケーション、システム、およびその他サービスでユーザにＳＳＯサービスを提供することができる。ウェブベースＳＳＯシステムは、フォームフィル、連合（ＯＩＦ）、ＳＳＯ保護（ＯＡＭ）、特権／共用（ＯＰＡＭ）、Ｏａｕｔｈ、およびその他ポリシー等、１つ以上の異なるアクセス制御方法をサポートする形に拡張できる。ウェブベースＳＳＯシステムは、ユーザが様々なウェブアプリケーションやシステム等にアクセスして自身の認証情報を管理するためのユーザインターフェースを含んでよい。ＳＳＯサービスの各々にはウェブインターフェース（ＲＥＳＴインターフェース等）を対応付けることができ、完全なクライアントをユーザのデバイスに配備せずとも、ウェブ対応デバイスを使ってブラウザ等からウェブを介してＳＳＯサービスにアクセスできる。ウェブインターフェースはＳＳＯサービスの各々でＣＲＵＤ（作成、読み取り、更新、削除）機能を提供できる。様々なアクセスポリシーをサポートするため、ウェブベースＳＳＯシステムは、様々なリポジトリに対するデータアクセスを透過的に管理できる拡張可能データマネージャを含んでよい。

従来、ＳＳＯサービスはローカルで（例えばローカルマシンやローカルネットワークで実行するＳＳＯサービスを通じて）提供され、安全なポリシー・認証情報転送を提供するプロトコルを使って通信するように構成されていた。ただし、後方互換性を維持しながらウェブベースまたはクラウドベースのリモートＳＳＯシステムからこれらのサービスにアクセスするには、込み入った通信課題がある。クライアントはＨＴＴＰかＨＴＴＰＳでウェブリクエストを送信し、ウェブレスポンスを受信するよう通常構成されるが、ＳＳＯサービスのリクエストとレスポンスはアクセスプロトコル（ネットワークアクセスプロトコルやＯｒａｃｌｅ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ等）を通常使用する。本発明のいくつかの実施形態では、アクセスプロトコルにまたがってクライアントからアクセスマネージャサーバへリクエストとレスポンスをトンネルできる。いくつかの実施形態において、認証情報管理やポリシー管理を含むシングルサインオンサービスへのアクセスは、１つ以上のウェブインターフェース（ＲＥＳＴインターフェース等）を用いてウェブベースまたはクラウドベースＳＳＯシステムに一体化できる。

いくつかの実施形態において、方法は、シングルサインオンサービスに対するリクエストを受信することを含んでよい。リクエストは、シングルサインオンサービスに対応付けられたウェブインターフェースを介して受信されてよい。方法はさらに、リクエストに基づきデータマネージャへデータリクエストを送信することと、対応付けられたウェブインターフェースを介してレスポンスを返すこととを含んでよい。リクエストは、リクエストに応じたポリシーまたは認証情報の情報を含んでよく、ポリシーまたは認証情報の情報はアプリケーションに自動的にログインするためクライアントデバイスによって使用される。例えばポリシー情報はテンプレートを含んでよく、テンプレートは、受信ウェブレスポンス（例えば着信ウェブページ）を、当該着信ウェブページを通じて提出される認証情報に照合し、ユーザをアプリケーションにログインさせるため、クライアントデバイスによって使用されてよい。

いくつかの実施形態において、リクエストはプロキシによって第１のプロトコルで受信されてよく、プロキシはリクエストを第１のプロトコルから第２のプロトコルに変換し、変換したリクエストをシングルサインオンサービスへ転送する。いくつかの実施形態において、レスポンスはプロキシによって第２のプロトコルで受信され、プロキシはレスポンスを第２のプロトコルから第１のプロトコルに変換し、変換したレスポンスを返す。

いくつかの実施形態において、シングルサインオンサービスに対するリクエストはポリシー管理リクエストであり、方法はさらに、ポリシー管理リクエストをポリシーマネージャへ送信することを含んでよい。ポリシー管理リクエストは１つ以上のポリシー管理操作を含んでよい。方法はさらに、１つ以上のポリシー管理操作に基づいてデータリクエストを生成することとを含んでよい。いくつかの実施形態において、ポリシー管理リクエストは第１のインターフェース向けにフォーマットされてよく、ポリシーマネージャはポリシー管理リクエストに対応付けられたポリシー管理プラグインを特定し、特定したポリシー管理プラグインに基づきポリシー管理リクエストを第２のインターフェース向けのフォーマットに変換してよい。

いくつかの実施形態において、シングルサインオンサービスに対するリクエストは認証情報管理リクエストであってよく、方法はさらに、認証情報管理リクエストを認証情報マネージャへ送信することを含んでよい。認証情報管理リクエストは１つ以上の認証情報管理操作を含んでよい。方法はさらに、１つ以上の認証情報管理操作に基づいてデータリクエストを生成することとを含んでよい。いくつかの実施形態において、認証情報管理リクエストは第１のインターフェース向けにフォーマットされてよく、認証情報マネージャは認証情報管理リクエストに対応付けられたサブマネージャを特定し、特定したサブマネージャに基づき認証情報管理リクエストを第２のインターフェース向けのフォーマットに変換してよい。

いくつかの実施形態では、コンピュータ可読媒体とプロセッサとを含むコンピュータを含むシステムが提供されてよい。システムはさらに、コンピュータで実行する複数のシングルサインオンサービスを含んでよい。シングルサインオンサービスの各々には１つ以上のウェブインターフェースが対応付けられてよい。複数のシングルサインオンサービスは、クライアントから対応付けられたウェブインターフェースを介してポリシーまたは認証情報を管理するリクエストを受信し、ポリシーまたは認証情報を管理するリクエストに基づいてデータマネージャへデータリクエストを送信し、対応付けられたウェブインターフェースを介してクライアントへレスポンスを返す、ように構成されてよい。

いくつかの実施形態では、命令を蓄積する非一時的コンピュータ可読記憶媒体が提供されてよく、命令がプロセッサによって実行されるとプロセッサは、シングルサインオンサービスに対するリクエストをシングルサインオンサービスに対応付けられたウェブインターフェースを介して受信するステップと、ポリシーまたは認証情報を管理するリクエストに基づきデータマネージャへデータリクエストを送信するステップと、対応付けられたウェブインターフェースを介してレスポンスを返すステップとを遂行する。

図面の簡単な説明
これより本発明の例示的実施形態を下記図面を参照しながら詳しく説明する。

図１は、本発明の一実施形態に係る、ウェブベースシングルサインオンシステムの概要を示す。 図２は、本発明の一実施形態に係る、フォームフィルアーキテクチャのブロック図を示す。 図３は、本発明の一実施形態に係る、リソースにアクセスするためのリクエストに応じてＳＳＯプロキシアプリケーションを挿入する方法のブロック図を示す。 図４は、本発明の一実施形態に係る、フォームフィルの状態図を示す。 図５は、本発明の一実施形態に係る、様々な環境で実行できるプラグ方式シングルサインオンアプリケーションを示す。 図６は、本発明の一実施形態に係る、デスクトップログオンマネージャインターフェースを示す。 図７は、本発明の一実施形態に係る、モバイルログオンマネージャインターフェースを示す。 図８は、本発明の一実施形態に係る、ログオンマネージャアーキテクチャを示す。 図９は、本発明の一実施形態に係る、ウェブログオンインターフェースを通じてウェブアプリケーションにアクセスする方法のブロック図を示す。 図１０は、本発明の一実施形態に係る、シングルサインオンサービスが組み込まれたＳＳＯサーバアーキテクチャを示す。 図１１Ａは、本発明の一実施形態に係る、ポリシーマネージャアーキテクチャを示す。 図１１Ｂは、本発明の一実施形態に係る、認証情報マネージャアーキテクチャを示す。 図１２は、本発明の一実施形態に係る、ウェブベースインターフェースを通じてＳＳＯサービスを提供する方法のブロック図を示す。 図１３は、本発明の一実施形態に係る、データマネージャアーキテクチャを示す。 図１４は、本発明の一実施形態に係る、複数のデータストアに蓄積された認証情報を管理する方法のブロック図を示す。 図１５は、実施形態のいずれか１つを実装する分散システムの簡略図を示す。 図１６は、本開示の一実施形態に係る、システム環境のコンポーネントの簡略ブロック図であり、実施形態システムのコンポーネントから提供されるサービスはクラウドサービスとして提供され得る。 図１７は、本発明の種々実施形態を実装し得る例示的コンピュータシステムを示す。

詳細な説明
以降の説明には解説の目的で本発明の実施形態を十分に理解するための具体的詳細が記載されている。ただし、これらの具体的詳細がなくとも種々の実施形態を実施し得ることは明らかとなるであろう。図と説明は限定を意図するものではない。

いくつかの図に示されたシステムは様々な構成で提供され得る。いくつかの実施形態において、システムは分散システムとして構成されてよく、分散システムの１つ以上のコンポーネントはクラウドコンピューティングシステムの中で１つ以上のネットワークにまたがって分散される。

本発明の実施形態はウェブベースシングルサインオンサービスを目的としており、ウェブベースシングルサインオンサービスは、ユーザが（ウェブブラウザやクライアントアプリケーションを通じて）単一のインターフェースにログインすることを可能にし、１つ以上のウェブアプリケーション、エンタープライズシステム、およびその他サービスでユーザにシングルサインオン（single sign-on：ＳＳＯ）サービスを提供することができる。ウェブベースＳＳＯシステムは、フォームフィル、連合アイデンティティ、ポリシー本位制御、特権／共用アカウント、ＯＡｕｔｈ、およびその他セキュリティシステム等、１つ以上の異なるアクセス制御方法をサポートする形に拡張できる。ウェブベースＳＳＯシステムは、ユーザが様々なウェブアプリケーションやシステム等にアクセスして自身の認証情報を管理するためのユーザインターフェースを含んでよい。それぞれのＳＳＯサービスにはウェブインターフェース（ＲＥＳＴインターフェース等）を対応付けることができ、完全なクライアントをユーザのデバイスに配備せずとも、ウェブ対応デバイスを使ってブラウザ等からウェブを介してＳＳＯサービスにアクセスできる。ウェブインターフェースはそれぞれのＳＳＯサービスでＣＲＵＤ（作成（create）、読み取り（read）、更新（update）、削除（delete））機能を提供できる。様々なアクセスポリシーをサポートするため、ウェブベースＳＳＯシステムは、様々なリポジトリに対するデータアクセスを透過的に管理できる拡張可能データマネージャを含んでよい。

図１は、本発明の一実施形態に係る、ウェブベースシングルサインオンシステムの概要を示す。図１に見られるように、シングルサインオンサービス１００はＳＳＯサーバ１０２で実装できる。ＳＳＯサーバ１０２は１つ以上のカスタマイズされたウェブインターフェース１０４を使って１つ以上の異なるクライアント１０６にサービス１００を提供できる。いくつかの実施形態では、ＳＳＯサーバ１０２をアクセスマネージャサーバに組み込むことができる。これは、１つ以上の異なるエンドユーザクライアント１０６が１つのＳＳＯバックエンドからＳＳＯサービスにアクセスしＳＳＯサービスを利用することを可能にする。クライアント１０６はＳＳＯクライアントアプリケーション１０６Ａが予めインストールされたクライアントデバイスを含み得、これらはシッククライアントやリッチクライアントと呼ばれることがあり、パーソナルコンピュータ、ワークステーション、モバイルデバイス、およびその他クライアントデバイスを含み得る。前記に加えて、または前記の代わりに、Ｊａｖａｓｃｒｉｐｔアプリケーション等のウェブアプリケーション１０６ＢやブラウザアプリケーションでＳＳＯサービスを管理、提供でき、この場合はクライアントデバイスごとに単独のＳＳＯアプリケーションを準備しインストールする必要はない。ここで用いるＳＳＯアプリケーションという用語は、クライアントデバイスにインストールされた単独のＳＳＯクライアントアプリケーションを指す場合もあれば、ブラウザベースのＳＳＯアプリケーションを指す場合もある。

それぞれのウェブインターフェース１０４は、クライアントが認証情報（ユーザ名／パスワード、連合または保護サイトへのリンク、またはその他種類）を含むＳＳＯサービスおよびリソースにどのようにアクセスするかを定めるほか、ＳＳＯサービスが認証情報を使ってどのようにアプリケーションとやり取りするかを定めるポリシーを定める。いくつかの実施形態において、それぞれのＳＳＯサービス１００には異なるウェブインターフェース１０４に対応付けることができる。いくつかの実施形態において、アプリケーションはローカルであってよく、あるいはリモートであってよく、ＳａａＳや他のクラウドベースアプリケーションおよび／またはサービス等のウェブアプリケーションを含む。ウェブベースでは、ユーザが何らかのインターネット接続デバイスを使ってアプリケーションに安全にアクセスできる。ここではＲＥＳＴ（Representational State Transfer）インターフェースについて説明するが、どのようなウェブベースインターフェースでも使用できる。

いくつかの実施形態において、ＳＳＯアプリケーションはＳＳＯサービス１００に蓄積された所定のポリシーを使って認証イベントを特定できる。ウェブインターフェースを通じてエンドユーザの認証情報とポリシーを管理でき、クライアント１０６から届くリクエストに適用できる。ユーザはクライアント１０６のいずれか１つで認証情報を提示することによってログオンできる（スマートカード／プロクシミティカード、トークン、ＰＫＩ（公開鍵基盤）、Ｗｉｎｄｏｗｓ Ｌｏｇｏｎ、ＬＤＡＰ（ライトウェイトディレクトリアクセスプロトコル）ログオン、バイオメトリックデバイス、その他）。その後認証情報は認証サービスで解析できる。いくつかの実施形態において、１つ以上のクライアント側認証プラグインは認証イベントを検出し、ユーザから届く認証情報を収集できる。それぞれの認証プラグインには様々な種類の認証情報および／または異なるログオン方法を対応付けることができる。いくつかの実施形態において、それぞれの認証プラグインにはグレードを対応付けることができる。いくつかの実施形態において、グレードは認証情報の種類やリクエストの種類に割り当てることができる。グレードは数値として蓄積できる。このためＳＳＯシステムは、ユーザから提供される認証情報のグレードに応じてログオンリクエストに対するレスポンスを変えることができる。例えばユーザがグレード１の認証情報でログインする場合に、グレード２以上の認証イベントが確認されると、より高いグレードの認証情報を提供することをユーザに促すことができる。いくつかの実施形態において、認証情報は認証クッキーとしてユーザのブラウザアプリケーションの中に蓄積できる。認証クッキーは、（例えばユーザがウェブベースのログオンページから自身のクライアントデバイスにログインするときに）ユーザから認証情報が届き次第ローカルまたはウェブベースの認証サービスから取得できる。認証クッキーはＳＳＯサーバ１０２に対するウェブリクエストに含めることができ、リクエストに応じてＳＳＯサービスを提供する前に検査できる。いくつかの実施形態では、サービスごとに異なる認証レベルが必要となり得、認証レベルは認証クッキーで具現され得る。例えばユーザが何らかのサービスをリクエストしてもユーザの認証クッキーが当該サービスへのアクセスを許可しない場合は、新たな認証クッキーを取得するためユーザをログインページにリダイレクトできる。

いくつかの実施形態において、クライアント１０６からのリクエストは、ロードバランサや他のウェブサーバ等のＳＳＯゲートウェイ１０８を通じて受信できる。ＳＳＯゲートウェイ１０８はクライアント１０６からのリクエストを平衡するため１つ以上のアクセスエージェント１１０を実装できる。いくつかの実施形態において、ユーザは、自身のデバイスで実行するクライアント１０６を通じて、またはウェブブラウザを通じて、ここでログオンマネージャまたはダッシュボードと呼ぶ、ＳＳＯユーザインターフェース１１２Ａにアクセスできる。いくつかの実施形態では、ＳＳＯシステム１０２でＳＳＯユーザインターフェース１１２Ｂを実装できる。いくつかの実施形態において、ＳＳＯユーザインターフェース１０８はユーザがよく利用するアプリケーションのリストを含むことができる。ユーザはＳＳＯユーザインターフェースを通じて自身の認証情報やアプリケーションに関連するポリシーを管理できる。ユーザがユーザインターフェースを通じて何らかのアプリケーションへのアクセスをリクエストすると、ＳＳＯユーザインターフェースは当該アプリケーションのポリシー種類を判断し、当該ポリシー種類に基づいてユーザの認証情報を取得できる。いくつかの実施形態において、認可モジュール１１８はリクエストに付属する認証クッキーを検査し、認証情報を引き出す権限がユーザにあるか否かを判断できる。権限がある場合、ユーザは認証情報を使ってアプリケーションにログインできる。様々な認証情報やポリシーを別々のリポジトリに保管できる。蓄積された認証情報および／またはポリシーにアクセスする、引き出す、更新する、削除する、または操作するためのリクエストが届くと、ＳＳＯサービス１００はデータマネージャ１２２を通じて該当するリポジトリ１２０にアクセスできる。いくつかの実施形態において、ＳＳＯプロキシ１１４は、ユーザが、最初にＳＳＯユーザインターフェース１１０にアクセスせず、あるいはユーザのデバイスで実行するクライアントを使用せず、ウェブブラウザから直接ＳＳＯサービスを使ってウェブアプリケーション１１６にアクセスすることを可能にできる。いくつかの実施形態において、ＳＳＯサービス１００は企業ディレクトリ等のアイデンティティマネージャ１２４にアクセスしてユーザのアイデンティティを検査できる。

いくつかの実施形態において、ＳＳＯサービス１００は、自動サインオン、アプリケーションパスワード変更およびリセット、セッション管理、アプリケーション認証情報プロビジョニング、セッション内外での認証を含む、アプリケーションに対するアクセス許可／却下を管理できる。いくつかの実施形態において、ＳＳＯシステム１０２は、クライアントデバイスから実行する、またはクライアントデバイスからアクセスされる、Ｗｉｎｄｏｗｓ（登録商標）、Ｗｅｂ、Ｊａｖａ（登録商標）、およびメインフレーム／ターミナルベースのアプリケーションの自動シングルサインオン機能を提供できる。ログオンマネージャ１１２Ａはセッションを監視し、アプリケーションからのログオンリクエストを自動的に検出し、リクエストに対応する特定のログオン要件に従って自動的にログオンを完了できる。

いくつかの実施形態では、Ｏｒａｃｌｅ Ａｃｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ保護リソース、連合アプリケーション／リソース、フォームフィルアプリケーション等、様々な種類の認証情報とアプリケーションをサポートできる。ＯＡＭ保護リソースの場合は、ユーザリクエストを認証した後、所望のリソースのＵＲＬへユーザリクエストを誘導できる。連合アプリケーションの場合は、企業間（Ｂ２Ｂ）パートナーアプリケーションやＳａａＳアプリケーションを含む、連合パートナーおよびリソースへ至るリンクを提供できる。フォームフィルアプリケーションの場合は、認証情報を送出できるアプリケーションウェブページのフィールドをテンプレートを使って特定できる。

上述したように、ウェブベースＳＳＯサービスは、多数のブラウザベースアクセス方法を含む様々なクライアントアプリケーションを通じて提供できる。後述するように、ユーザはＳＳＯゲートウェイ１０８を通じてアプリケーションにアクセスしてＳＳＯサービスを受けることができる。ある１つのアクセス方法は、ユーザがユーザのブラウザに自動的にインストールされる埋め込みＳＳＯアプリケーションを通じて透過的にＳＳＯサービスにアクセスすることを可能にする。いくつかの実施形態において、ユーザはブラウザを使ってウェブログオンマネージャにアクセスし、アプリケーションにアクセスしたり、ポリシーや認証情報を管理したり、ＳＳＯサービスを消費したりできる。これらのアクセス方法については後述する。

フォームフィルプロキシアプリケーションによるウェブベースシングルサインオン
一実施形態によると、ウェブアプリケーションに対するリクエストはＳＳＯプロキシを通じて引き渡すことができる。ウェブアプリケーションからレスポンスを受け取ったＳＳＯプロキシは、ポリシー情報や他のペイロード内容をレスポンスに付加し、クライアントデバイスにＳＳＯ処理を任せるＳＳＯアプリケーションを埋め込み、必要に応じレスポンスの内容を書き換えることができる。埋め込まれるアプリケーションは、いくつかの実施形態でＪａｖａｓｃｒｉｐｔ（登録商標）アプリケーションとして実装されてよく、クライアントデバイスの処理能力を利用してシングルサインオン機能を実行する。ＳＳＯ処理の多くをクライアントデバイスに任せるこのソリューションは、多くのデバイスに対応する形に容易く拡張できる。ウェブベースのインターフェースにＳＳＯ機能を加えることでユーザエクスペリエンスも向上する。

図２は、本発明の一実施形態に係る、フォームフィルアーキテクチャ２００のブロック図を示す。上述したように、ＳＳＯシステム１０２にはＳＳＯゲートウェイ１０８を通じてアクセスできる。ＳＳＯゲートウェイ１０８には、クライアントのウェブブラウザアプリケーションにＳＳＯアプリケーションを埋め込むフォームフィルプロキシを組み込むことができる。いくつかの実施形態において、ＳＳＯアプリケーションは、認証情報を管理しポリシーを取得するためＳＳＯゲートウェイ１０８を通じてアクセスマネージャサーバ１０２のＳＳＯウェブサービスと通信できるＪａｖａｓｃｒｉｐｔアプリケーションであってよい。

一実施形態によると、ユーザはクライアントデバイス１０６Ｂで実行するウェブブラウザを通じてウェブアプリケーション２０２にアクセスできる。ウェブアプリケーション２０２は、ウェブベースのｅメールサービス、ビジネスアプリケーション、または他の何らかのウェブアプリケーションであってよい。クライアントデバイス１０６Ｂはウェブアプリケーション２０２にアクセスするためのリクエスト２０４を送信でき、リクエスト２０４はＳＳＯゲートウェイ１０８によってインターセプトされる。ＳＳＯゲートウェイ１０８はリクエストをウェブアプリケーション２０２に転送でき、ウェブアプリケーションからのレスポンス２０６をインターセプトできる。いくつかの実施形態において、ＳＳＯゲートウェイ１０８は、ウェブアプリケーション２０２からのレスポンスをＳＳＯゲートウェイ１０８へ返す形にリクエストを修正できる。ＳＳＯゲートウェイ１０８は、リクエスト側クライアント１０６Ｂへレスポンスを返す前に、ＳＳＯゲートウェイ１０８にあるＳＳＯプロキシ１１４へレスポンス２０６を引き渡すことができる。ＳＳＯプロキシ１１４は、様々なＳＳＯ機能へのアクセスを提供する追加データ２０８を含めてレスポンスを修正できる。

例えばプロキシは、ブラウザからＳＳＯファンクションを呼び出して実行するためのＪａｖａｓｃｒｉｐｔ等のＳＳＯアプリケーションコードをレスポンスに加えることができる。ＳＳＯアプリケーションはユーザのデバイス１０６Ｂで実行でき、フォームフィル方式のページやフィールドを特定したり、ＳＳＯサーバにポリシーをリクエストしたり、認証情報を管理したりする。後述するように、認証情報やポリシーのリクエストはウェブインターフェースを通じてＳＳＯシステム１０２へ送信できる。例えば、ウェブアプリケーションから届くログインページはＳＳＯアプリケーションで検出できる。ＳＳＯアプリケーションはウェブアプリケーションのポリシーを読み取り、認証情報を引き出すことができる。ＳＳＯアプリケーションは引き出した認証情報を使ってログインページのしかるべきフィールドを自動的に埋め、ログインリクエストを送出できる。ログインが失敗する場合、ＳＳＯアプリケーションはログイン失敗を検出してログイン失敗フローを実行でき、ログイン失敗フローは、例えばユーザがウェブアプリケーションに対する自身の認証情報をリセットおよび／または回復し、ＳＳＯサーバで自身の認証情報を更新することを可能にする。

一実施形態によると、プロキシはウェブアプリケーションから届くレスポンスに追加内容２０８を加えることができる。追加内容２０８はテンプレートやポリシーを含み得る。ＳＳＯアプリケーションはテンプレートを基にフォームフィル方式のページやフィールドを特定できるほか、フィールドへ認証情報を加える方法を判断できる。ウェブページレスポンスにＳＳＯアプリケーションを加えることにより、ＳＳＯ処理の多くがバックエンドシステムからユーザデバイスに任される。処理の多くをエンドユーザに任せることにより、ＳＳＯサーバにおける処理要求が低減され、従来のシステムより拡張性に富むＳＳＯソリューションになる。

図３は、本発明の一実施形態に係る、リソースにアクセスするためのリクエストに応じてＳＳＯプロキシアプリケーションを挿入する方法３００のブロック図を示す。ブロック３０２では、ウェブアプリケーションにアクセスするためのリクエストをクライアントデバイスから受信できる。上述したように、リクエストはＳＳＯシステムに対応するＳＳＯゲートウェイで受信できる。いくつかの実施形態において、クライアントデバイスからのリクエストはウェブアプリケーションのウェブページを求めるリクエストであってよい（例えばＨＴＴＰリクエスト）。リクエストは、デバイスで実行するＳＳＯクライアントを含まないクライアントデバイスから受信できる。

ブロック３０４では、リクエストをウェブアプリケーションに引き渡せる。いくつかの実施形態において、ＳＳＯゲートウェイは、後ほどの監査のため、または他の目的のため、リクエストに関する情報（時刻、日付、ウェブアドレス、その他）をログできる。ブロック３０６では、ウェブアプリケーションからレスポンスが受信される。レスポンスは、ユーザがログイン情報を提供するためのフィールドを含むウェブページであってよい。ブロック３０８では、レスポンスにポリシーデータやシングルサインオンアプリケーションを付加して付加レスポンスを作ることができる。いくつかの実施形態では、ユーザのエンタープライズシステムに似た外観や風合いを提供するためレスポンスを書き換えることができる。例えば、ユーザのリクエストに応じ、ウェブページの配色とレイアウトをユーザの内部イントラネットの配色とレイアウトに似せて修正できる。ブロック３１０では、付加レスポンスがクライアントデバイスへ返される。

いくつかの実施形態において、シングルサインオンアプリケーションは、ＪａｖａＳｃｒｉｐｔアプリケーションである。シングルサインオンアプリケーションは、ユーザのブラウザアプリケーションで実行してＳＳＯサービスを提供できる。例えばＳＳＯアプリケーションはＳＳＯシステムにポリシーとテンプレートをリクエストし、それらのポリシーとテンプレートを使用し、ウェブアプリケーションに対するリクエストに応じて受信するページを対応するポリシーと照合できる。ＳＳＯアプリケーションはウェブページレスポンスの一致するフィールドに適切なユーザ認証情報を自動的に挿入し、それらの認証情報をウェブアプリケーションへ送出できる。このように、ユーザのクライアントデバイスに独立したＳＳＯクライアントアプリケーションを準備しインストールしなくても、シングルサインオンが達成される。

いくつかの実施形態において、シングルサインオンアプリケーションは、様々なハードウェア、オペレーティングシステム、ブラウザ、またはこれらの組み合わせに対応する実行可能スクリプトを含み得る。ＳＳＯアプリケーションは、クライアントデバイスのプラットフォームを識別し、１つ以上のプラットフォーム固有操作を実行する形に自身を構成するよう構成できる。プラットフォームは、クライアントデバイス種類（デスクトップ、モバイルデバイス、ワークステーション、または他のハードウェア構成）、ブラウザアプリケーション種類、および／またはオペレーティングシステムのうちいずれか１つ以上を指し得る。

一旦インストールされたＳＳＯアプリケーションはユーザのブラウザを通じてユーザにＳＳＯサービスを提供でき、独立したＳＳＯクライアントアプリケーションは必要ない。図４は、本発明の一実施形態に係る、ＳＳＯアプリケーションの状態図を示す。図４に見られるように、ブロック４０２では、ユーザのブラウザで実行するＳＳＯアプリケーションがウェブアプリケーションのポリシーをリクエストできる。リクエストはＳＳＯシステムによって提供されるウェブインターフェースに従ってフォーマットされたウェブリクエストであってよい。ポリシーが返されない場合、ＳＳＯアプリケーションの実行は終了でき、ユーザのブラウザでウェブアプリケーションを開くことができ、さらなるＳＳＯサービスは提供しない（例えばウェブアプリケーションのポリシーが見つからない場合、ＳＳＯアプリケーションは認証情報を加えたりユーザをウェブアプリケーションにログインさせたりしない）。

少なくとも１つのポリシーが返される場合は、ブロック４０４で、ＳＳＯアプリケーションはウェブアプリケーションによって返されるページにポリシーを照合できる。例えば、ある１つのポリシーはログインページに相当し得、別のポリシーはパスワード変更ページに相当し得る。それぞれのポリシーにはページテンプレートを対応付けることができる。着信ページがポリシーに一致する場合は、着信ページが蓄積されたテンプレートページに比較される。例えばテンプレートは、ページ内にある様々なフィールドおよびタイプ、内容、ラベル、タグ、その他を識別する場所を規定し得る。着信ページがテンプレートに一致する場合は、そのテンプレートに対応するポリシーを使ってそのページのＳＳＯサービスを提供できる。いくつかの実施形態において、ポリシーは一致したページで実施すべきアクション（例えばどの認証情報をどのように供給するべきか等）を規定し得る。ポリシーが一致せず、着信ページに一致するテンプレートがなければ、着信ページをユーザに提示でき、さらなるＳＳＯサービスは提供されない。

ポリシーが一致した場合は、ブロック４０６で、ＳＳＯアプリケーションがＳＳＯサーバに認証情報をリクエストできる。１つ以上の認証情報が返される場合は、ブロック４０８で、ＳＳＯアプリケーションがログオンチューザを起動できる。いくつかの実施形態において、ブロック４１０では、ユーザのクライアントデバイスでログオンチューザをユーザに向けて表示でき、ユーザが、返された認証情報から認証情報を手作業で選択できるようにする。ユーザがログオンチューザを使って認証情報を選択したら、ブロック４１２でＳＳＯアプリケーションは選択された認証情報を挿入してログオンリクエストを送出できる。

いくつかの実施形態において、ユーザが選択を行うと、選択された認証情報が送出され、４１４でＳＳＯアプリケーションはログオン結果を検証できる。ログオンが正常に遂行される場合、ブロック４１６で、ＳＳＯアプリケーションは、ユーザの選択に基づいてそのページのユーザ認証情報を更新するためのリクエストをＳＳＯサーバへ送信できる。このため、ユーザが後ほどそのウェブアプリケーションをリクエストするときには、選択されたユーザ認証情報を返すことができ、ユーザはログオンチューザから認証情報を手作業で選択しなくてすむ。いくつかの実施形態では、ユーザに向けてログオンチューザを表示する前に自動化されたログオンチューザプロセスを実行できる。例えば少数の認証情報が返される場合、ＳＳＯアプリケーションは、ログオン成功が検出されるまで、返された認証情報を自動的に順次送出できる。ＳＳＯアプリケーションはその後、そのウェブアプリケーションのユーザ認証情報を更新するための更新リクエストをＳＳＯサーバへ送信できる。

ただ１つの認証情報が返された場合、処理はブロック４１０を迂回してブロック４１２へ進むことができ、ここでユーザからさらなる入力がなくとも認証情報をページに挿入し、送出できる。認証情報が送出されると、ＳＳＯアプリケーションはログインリクエストの状態を監視できる。いくつかの実施形態において、ログインが失敗する場合は処理を終了できる。いくつかの実施形態において、ログインが成功する場合はブロック４１６で認証情報を保存できる。

認証情報が返されない場合は、ユーザのブラウザでユーザに向けて着信ページを表示でき、ブロック４１８でＳＳＯアプリケーションはユーザによって手作業で入力された認証情報を捕捉できる。ユーザによって入力された認証情報は送出でき、ログオン結果を監視できる。ログオンが成功した場合は、ブロック４１６で認証情報が保存され、ユーザはウェブアプリケーションにログインされる。ログオンが失敗する場合は、ウェブアプリケーションのログオン失敗ページをユーザに向けて表示できる。いくつかの実施形態において、ＳＳＯアプリケーションは自動的にログオン失敗ページを検出し、ログオン失敗ページにポリシーを照合し、ログオン失敗に対応するフローを実行できる（パスワード回復またはリセット等）。

いくつかの実施形態において、ユーザはウェブアプリケーションでパスワード変更（password change：ＰＷＣ）を遂行することを選べる。ＳＳＯアプリケーションはＰＷＣページを検出し（例えばそのウェブアプリケーションに規定されたＰＷＣテンプレートを使用）、ブロック４１８でユーザによって提供される認証情報を捕捉できる。ＳＳＯアプリケーションはＰＷＣプロセスを監視でき、成功する場合は、ブロック４１６で新しい認証情報をＳＳＯサーバに保存できる。ＰＷＣに失敗する場合は、ウェブアプリケーションのＰＷＣ失敗ページをユーザに向けて表示できる。いくつかの実施形態において、ＳＳＯアプリケーションは自動的にＰＷＣ失敗ページを検出し、ＰＷＣ失敗ページにポリシーを照合し、ＰＷＣ失敗に対応するフローを実行できる（例えばＰＷＣフローを再度実行し、失敗の理由をユーザに伝える）。

図４に見られるように、ブロック４０２、４０６、４１０、および４１６における処理は（例えばポリシーおよび認証情報を取得、認証情報を保存、ログオンチューザのユーザ設定を取得）、ＳＳＯサーバとの通信をともなう。ただし、ＰＷＣおよびログオン試行の成功の監視、ポリシーおよびテンプレートの検出、認証情報の挿入等を含む他の処理ステップは、ブラウザにてＳＳＯアプリケーションによって遂行できる。これはＳＳＯサーバに必要とされる処理リソース量を減らし、システムリソースを酷使することなくユーザを追加することを容易にする。

いくつかの実施形態において、ＳＳＯサーバは、ウェブアプリケーションのポリシーを求めるリクエストをシングルサインオンアプリケーションから受信できる。ＳＳＯサーバはその後、所望されたポリシーを求めるリクエストをデータマネージャに送信できる。１つ以上のポリシーが返される場合、ＳＳＯサーバは１つ以上のポリシーを含むレスポンスをシングルサインオンアプリケーションへ送信できる。ポリシーが返されない場合、ＳＳＯサーバは、ウェブアプリケーションのポリシーがないことを伝えるレスポンスをＳＳＯアプリケーションへ返すことができる。

いくつかの実施形態において、ＳＳＯサーバは、ウェブアプリケーションにアクセスするためのユーザに対応付けられた認証情報を求めるリクエストをシングルサインオンアプリケーションから受信できる。ＳＳＯサーバはその後、認証情報を求めるリクエストをデータマネージャへ送信できる。１つ以上の認証情報が返される場合、ＳＳＯサーバは１つ以上の認証情報を含むレスポンスをシングルサインオンアプリケーションへ送信できる。ＳＳＯアプリケーションはその後、１つ以上の認証情報から認証情報を選択するためのログオンチューザをユーザに提示する。認証情報が返されない場合、ＳＳＯサーバは、ユーザとウェブアプリケーションに対応付けられた認証情報がないことを伝えるレスポンスをＳＳＯアプリケーションへ返すことができる。

いくつかの実施形態において、ＳＳＯアプリケーションは、認証情報を検索および表示し、自動・手動パスワード変更（ＰＷＣ）処理、ログオンチューザ、およびログオン失敗を遂行できる認証情報マネージャを含むことができる。上述したように、いくつかの実施形態において、ＳＳＯアプリケーションはウェブアプリケーションに対するリクエストに応じてユーザのブラウザにインストールできる（例えばユーザへ送信される付加レスポンスにＳＳＯアプリケーションを加えることができる。ＳＳＯアプリケーションは、ＳＳＯアプリケーションを含む着信レスポンスウェブページに対応する状態に初期化できる。

いくつかの実施形態において、ウェブアプリケーションリクエストは後述するウェブログオンマネージャ（web logon manager：ＷＬＭ）から開始できる。かかる実施形態において、ＳＳＯアプリケーションは（例えばクエリー文字列、セッション蓄積情報、またはその他情報をチェックすることにより）ＷＬＭから認証情報の情報を取得できる。ＷＬＭからの認証情報を使用することで、ＳＳＯアプリケーションがＳＳＯサーバに認証情報の情報をリクエストする必要はなくなり、ＳＳＯサーバにかかる負荷はさらに減る。

いくつかの実施形態において、自動パスワード変更（ＰＷＣ）プロセスはＳＳＯシステムによって実施できる。ＳＳＯシステムはＰＷＣページをテンプレートと照合し、ＰＷＣページに対応付けられたポリシーを特定できる。ＳＳＯアプリケーションはページテンプレートに一致する認証情報のリクエストを送信できる。認証情報を基に、現在のユーザ名とパスワードをＰＷＣページのしかるべきフィールドに加えることができる。自動ＰＷＣのときにはＳＳＯサーバで新たなパスワードを自動的に生成でき、自動的に生成された新たなパスワードでユーザの認証情報を更新できる。ＳＳＯサーバはその後、更新された認証情報をＳＳＯアプリケーションへ返すことができる。ＳＳＯアプリケーションはＰＷＣページのしかるべきフィールドに新しいパスワードを加え、パスワード変更リクエストを送出できる。ブロック４２０では、ＰＷＣ結果を検証できる。パスワードが正常に更新された場合は、ブロック４１６で、変更が確定され、更新された認証情報が保存される。パスワードが正常に更新されなかった場合は、ユーザをＰＷＣページに戻すことができる。

いくつかの実施形態では、手動ＰＷＣプロセスも提供できる。手動ＰＷＣでは、自動ＰＷＣと同様にＰＷＣページが照合され、照合に基づいて認証情報が特定される。ＳＳＯアプリケーションは認証情報を受信し、ＰＷＣページのしかるべきフィールドに認証情報を挿入できる。手動ＰＷＣの場合、ポリシーは自動送出を無効にし、ＳＳＯアプリケーションが認証情報を自動的に送出するのを阻止できる。ＳＳＯアプリケーションはＰＷＣページを監視し、ユーザによって手作業で入力される新しいパスワードを捕捉する。その後、ユーザから提供されたパスワードを用いて蓄積された認証情報を更新できる。いくつかの実施形態において、ＳＳＯサーバはユーザから提供されたパスワードが文字数や文字種等のパスワード基準（ウェブアプリケーションによって設定された基準、またはＳＳＯサーバによって設定された基準）に適合していることを確認できる。

図５は、本発明の一実施形態に係る、様々な環境で実行できるプラグ方式シングルサインオンアプリケーションを示す。上述したように、プロキシはユーザのブラウザで実行するＳＳＯアプリケーションをウェブアプリケーションからのレスポンスに付加し、ＳＳＯサーバと通信しながらポリシーおよび認証情報管理等のＳＳＯサービスを提供できる。ユーザデバイスやクライアントやブラウザによって要件や能力は異なるため、ＳＳＯアプリケーションをプラグ方式にすることで様々な環境に対応できる。例えば環境変数５００は、使用するクライアント（例えばクライアントはスタンドアロンクライアントか、あるはブラウザか）やブラウザ（Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、Ｃｈｒｏｍｅ、Ｆｉｒｅｆｏｘ等）を規定する形に設定できる。サポートされたそれぞれのクライアントには、ブラウザ専用の、かつプラットフォーム専用の、ファンクション５０２を対応付けることができる。ＳＳＯアプリケーションのためプラットフォーム専用の、またはブラウザ専用の、プラグインを作ることで、新たなプラットフォームやブラウザのサポートを加えることができる。

ＳＳＯアプリケーションはインストール時に構成でき、あるいはＳＳＯサーバからプラットフォーム専用ＳＳＯアプリケーションを提供できる。いくつかの実施形態において、一旦インストールされたＳＳＯアプリケーションはプラットフォーム専用ファンクションを呼び出してＳＳＯサービスを遂行できる。いくつかの実施形態では、プラットフォーム専用ファンクションに加えて、複数のプラットフォームにまたがる１組の共用ファンクションを提供できる。例えば、ＳＳＯサーバと通信するため呼び出されるファンクションを複数のプラットフォームにまたがって共用できるほか、ウェブページで認証情報を挿入し捕捉するプラットフォーム専用ファンクションも提供できる。

上述したように、ＳＳＯアプリケーションはユーザのブラウザアプリケーションにインストールされ、ユーザにＳＳＯサービスを透過的に提供できる。加えて、ＳＳＯアプリケーションはユーザのクライアントデバイスの処理能力を利用してＳＳＯサーバ１０２の処理量を減らすことができる。例えば、テンプレート照合や認証情報挿入やその他のＳＳＯ処理はクライアント側で片付けることができる。いくつかの実施形態において、ユーザはウェブベースのログオンマネージャインターフェースを通じてさらなるアプリケーションにアクセスし、さらなるＳＳＯ管理を遂行できる。

いくつかの実施形態において、クライアントはネットワークを介してリモートサーバで実行するウェブアプリケーションへリクエストを送信できる。このリクエストはＳＳＯプロキシで受信でき、ウェブアプリケーションへ転送できる。いくつかの実施形態において、ＳＳＯプロキシは、ウェブアプリケーションがリクエスト側クライアントではなくＳＳＯプロキシへレスポンスを返す形にリクエストを修正できる。ウェブアプリケーションはリクエスト（例えばウェブページを求めるウェブリクエスト）を受信し、レスポンスを返すことができる（例えばデータを含むウェブレスポンス、このデータはクライアントで実行するブラウザによって所望のウェブページに変えることができる）。ＳＳＯプロキシはリモートサーバからレスポンスを受信し、レスポンスを修正できる。いくつかの実施形態において、ＳＳＯプロキシはレスポンスに関係するポリシーおよび／または認証情報の情報をレスポンスに付け足す（例えば付加する）ことができる。例えばＳＳＯプロキシは、ウェブアプリケーションに対応付けられたポリシーの情報（上述した１つ以上のテンプレート等）を、および／または認証情報の情報（ユーザおよびウェブアプリケーションに対応付けられたユーザ名およびパスワード等）を、取得するためのリクエストを、ＳＳＯサーバへ送信できる。ＳＳＯプロキシは、ポリシーおよび／または認証情報の情報のほかに、ＳＳＯアプリケーションをレスポンスに加えることもできる。ＳＳＯアプリケーションはＪａｖａｓｃｒｉｐｔアプリケーションであってよく、あるいはクライアントで実行するブラウザアプリケーションの中で実行するように構成された他のアプリケーションであってよい。ＳＳＯプロキシはその後、付加されたレスポンスをクライアントへ返すことができる。レスポンスがクライアントで受信されると、ブラウザアプリケーションにＳＳＯアプリケーションを自動的にインストールでき、ポリシーおよび／または認証情報の情報はクライアントに蓄積される。上述したように、ＳＳＯアプリケーションはその後、リクエストおよびレスポンスに対しＳＳＯサービスを提供でき、それらは送信され受信される。

ウェブベースシングルサインオンログオンマネージャ
既存のログオンマネージャは通常、同じログイン方法を使用するアプリケーションへのアクセスだけを管理できる。例えばフォームフィルアプリケーションを、異なるログイン方法を使用する他のアプリケーションと一緒に管理することはできない。本発明の実施形態は、エンドユーザがアプリケーションにアクセスするための拠点を提供するエンドユーザアプリケーションダッシュボードを提供する。ダッシュボードはログイン要件がそれぞれ異なる複数のアプリケーションに対し統一的な足がかりを提供する。例えばフォームフィルアプリケーション、連合アプリケーション、アクセス制御され保護されない他のアプリケーションである。アプリケーションはダッシュボードに登録し、どのようにアクセスされるかを指定できる。登録後は、アプリケーションがどのようにアクセスされるかに基づいてアプリケーションのポリシーを規定できる。ダッシュボードは拡張可能であるため、新たなログイン種類をサポートできる。ダッシュボードは、アプリケーションがどのようにアクセスされかに関わりなく、ユーザの全アプリケーションに対しシンプルで統一されたアクセスポイントを提供する。

図６は、本発明の一実施形態に係る、デスクトップログオンマネージャインターフェースを示す。図６に見られるように、ログオンマネージャインターフェース６００は１つ以上のアプリケーションアイコン６０２の統一的展望を提供でき、それぞれのアプリケーションアイコン６０２は、ユーザがアクセスできるウェブアプリケーション、サービス、および／またはシステムを表している。ユーザのアプリケーションアイコンはエンドユーザアプリケーションカタログすなわちダッシュボードに表示でき、それぞれのアプリケーションには異なるアクセス要件を対応付けることができる。ダッシュボードはユーザがシステムにログインした後に表示できる。いくつかの実施形態において、ユーザは自身のクライアントデバイスにログオンしてウェブログオンマネージャにアクセスできる。いくつかの実施形態において、ユーザはウェブログオンマネージャにアクセスする際に最初にログインできる。ダッシュボードに表示されるいくつかのアプリケーションは保護されておらず、アクセスにあたって認証情報を必要としないが、他のアプリケーションはフォームフィルアプリケーション、連合アプリケーション、またはその他アクセス種類であってよい。つまりダッシュボードはアクセス種類に関わりなくアプリケーションを表示でき、アプリケーションの統一的展望と単一のアクセスポイントをユーザに提示する。

ダッシュボードに表示されるアプリケーションには１つ以上のポリシーや１つ以上の認証情報を対応付けることができる。ポリシーはどのようにしてアプリケーションにアクセスできるかを定めるものであり、認証情報はアプリケーションにアクセスするユーザの認証に使える情報を提供する。いくつかの実施形態では、ユーザのダッシュボードを準備できる。例えば会社の新入社員は、ｅメールアプリケーションやビジネスアプリケーションのアイコン等、自身が今後利用するいくつかのアプリケーションアイコンが設定されたダッシュボードを持つことができる。ユーザのダッシュボードでアプリケーションが設定され見えるようになると、各アプリケーションのポリシー種類／認証情報種類はユーザに見えないよう隠される。ユーザはアプリケーションを選択するだけでアプリケーションにアクセスでき、アプリケーションへのアクセスにあたって詳細を管理する必要はない。

いくつかの実施形態において、ウェブログオンマネージャはユーザが利用できるアプリケーションを様々な形で表示でき、ユーザは、ダッシュボードにおけるアプリケーションの表示のあり方を変えたり整理したりすることによってダッシュボードのレイアウトをカスタマイズできる。例えばウェブログオンマネージャは検索機能６０４を提供し、ユーザが特定のアプリケーションを（例えば名前、種類、または他の特性で）検索できるようにし、一致するアプリケーションを含む検索ビューを表示できる。いくつかの実施形態において、ユーザは全表示６０６アイコンを選択して利用可能な全アプリケーションをダッシュボードに表示できる。ユーザは様々な次元（例えば最も頻繁にアクセスされるアプリケーション順、追加された時間順、アルファベット順、その他）でアプリケーションを並べ替えることを選ぶこともできる。いくつかの実施形態において、ユーザは特定のアプリケーションをお気に入りとして指定し、お気に入りアイコン６０８を選択することによってお気に入りに指定されたアプリケーションだけを見ることができる。いくつかの実施形態において、ユーザは最近アイコン６１０を選択することによって最近追加されたアプリケーションを見ることができる。

いくつかの実施形態において、ユーザはウェブログオンマネージャに新たなアプリケーションを手作業で追加６１２できる。例えばユーザはポリシーや認証情報を追加したり削除したりすることによってアプリケーションの追加や削除を行える。いくつかの実施形態において、ユーザはログオンマネージャを通じて自身の認証情報を更新できる。いくつかの実施形態では編集ビュー６１４を表示でき、ユーザはお気に入り６１６の指定やアプリケーションの設定を行える。例えばユーザは設定６１８を選択してアプリケーションに関する設定を手作業で更新（例えば認証情報やポリシーを更新）できる。ユーザはダッシュボードからアプリケーション名を選択（例えばクリック、またはタップ）することによってアプリケーションを起動できる。

いくつかの実施形態において、ユーザはカタログから使用可能なアプリケーションを選択してしかるべき認証情報を提供することによって自身のダッシュボードにアプリケーションを追加できる。アプリケーションにはそれぞれ種類の異なる認証情報を使用できる。ウェブログオンマネージャは選択されるアプリケーションに応じて認証情報の種類を判断し、しかるべき認証情報を求めるメッセージをユーザに向けて表示できる。いくつかの実施形態において、ユーザはアプリケーションについて独自の表示名や説明文やその他の詳細を提供できる。いくつかの実施形態において、表示名はユーザのために前もって表示できる。ユーザは必要に応じてこれを修正することを選べる。いくつかの実施形態では、同じウェブアプリケーションで複数の認証情報（例えばｅコマースアプリケーションの複数のアカウントに相当）を提供できる。認証情報はダッシュボードの中でアプリケーションアイコンで表すことができ、自動的に数字やその他の標識を付けて区別できる。前記に加えて、または前記の代わりに、いくつかの実施形態では、ある１つのアプリケーションで複数のログオン認証情報を設定できる。例えばログオンマネージャは、ウェブアプリケーションにおけるユーザの活動を監視し、ユーザから提供される追加の認証情報を捕捉できる。

いくつかの実施形態において、ユーザはアプリケーションに対応付けられた認証情報を削除できる。認証情報が削除されると、ユーザのダッシュボードからアプリケーションが自動的に削除される。いくつかの実施形態において、ユーザがアプリケーションをお気に入りとして指定していた場合は、ユーザのダッシュボードのお気に入りビューにアプリケーションを表示し続けることもできる。ユーザは後ほどアプリケーションの新たな認証情報を追加し、アプリケーションをユーザのダッシュボードに戻すことができる。いくつかの実施形態において、ある１つのアプリケーションに対し複数の認証情報が蓄積されている場合、ユーザはそれぞれの認証情報を個別に削除できる。いくつかの実施形態において、ユーザはある１つのアプリケーションに対応付けられている全ての認証情報の削除を要求できる。

いくつかの実施形態において、ユーザは自身の認証情報を共用したり別のユーザに委譲したりすることができる。ダッシュボードは共用できるアプリケーションに「共用」アイコンを表示できる。アプリケーション開発者および／またはアドミニストレータはアプリケーションを共用する形に構成できる。いくつかの実施形態において、共用はアプリケーション単位で無効にできる。ユーザが自身の認証情報の共用を選ぶ場合は、認証情報を共用することとなるユーザに関するユーザ情報の提供をユーザに要求するプロンプトを表示できる。いくつかの実施形態において、プロンプトはユーザのリストを含むことができる（例えばエンタープライズユーザデータベースから挿入）。認証情報が委譲された場合は、委譲された者がその認証情報を別のユーザと共用することを阻止することもできる。いくつかの実施形態では、認証情報を共用できるユーザ数を最大数に制限できる。

ユーザは「取り消し」アイコンを選択することによっていつでも委譲を取り消すことができる。この取り消しアイコンは認証情報が別のユーザと共用される場合に表示できる。いくつかの実施形態において、認証情報を委譲するユーザは委譲期間を設定でき、この委譲期間を過ぎると認証情報は自動的に取り消される。

いくつかの実施形態において、ウェブログオンマネージャにはパスワード変更（ＰＷＣ）ウィザードを組み込むことができる。上述したように、ＰＷＣウィザードには、ユーザが新しいパスワードを指定する手動モードと、ＰＷＣウィザードがユーザに代わって新しいパスワードを自動的に選択する自動モードを盛り込むことができる。

図７は、本発明の一実施形態に係る、ログオンマネージャインターフェース７００を示す。ユーザがスマートフォンやタブレット等のモバイルデバイスからログオンマネージャにアクセスすると、インターフェースは自動的にユーザのデバイスのサイズおよび寸法要件に適応できる。モバイルログオンマネージャインターフェース７００は図６に関して上述したフルスクリーンインターフェースやデスクトップインターフェースと同様の機能を提供できる。アイコン７０２および７０４等、それぞれのアプリケーションアイコンはサイズを変えてスクロール可能リストに表示できる。ユーザはアプリケーションの表示名の横にあるアイコン７０４を選択してアプリケーションの詳細を見ることができる。いくつかの実施形態において、詳細には、アプリケーションを編集（例えばアプリケーションに対応付けられた認証情報および／またはポリシーを更新）するオプションをユーザに提示できる。いくつかの実施形態では、アイコン７０４を選択することによってアプリケーションを起動できる。

図８は、本発明の一実施形態に係る、ログオンマネージャアーキテクチャを示す。図６および７に図示されたアイコンは、ウェブアプリケーション、ローカルアプリケーション、リモートアプリケーション等、それぞれ異なるアプリケーションを代表できる。上述したように、それぞれのアイコンには、ＳＳＯシステムがアプリケーションとどのようにやり取りするかを規定するポリシーと、アプリケーションへのアクセスをユーザに提供する認証情報とを対応付けることができる。図８に見られるように、ユーザはユーザのデバイス１０６Ｂで実行するＳＳＯクライアント１０６を通じてログオンマネージャにアクセスできる。いくつかの実施形態において、クライアントはスタンドアロンクライアントであってよく、あるいはブラウザベースのクライアントであってよい。

いくつかの実施形態において、ユーザはウェブログオンマネージャのＵＲＬを訪ねることによってクライアントデバイス上のブラウザからログオンマネージャにアクセスできる。いくつかの実施形態において、ウェブログオンマネージャはＳＳＯゲートウェイ１０８とＳＳＯシステム１０２にまたがって分散させることができる。フロントエンドウェブログオンコンポーネント１１２ＡはＳＳＯゲートウェイ１０８で実行でき、グラフィカルユーザインターフェース（ＧＵＩ）を提供でき、このグラフィカルユーザインターフェースを通じてクライアント１０６からのリクエストを受信できる。いくつかの実施形態では、認証情報（例えばユーザ名とパスワード）をログオンマネージャに直接提供するようユーザに催促でき、あるいはユーザをリダイレクトしてＳＳＯシステム１０２でログオンすることをユーザに催促することもできる。一旦ログオンすると、ユーザのブラウザにクッキーやその他の識別子を加えることができる。これはユーザがログインし、ログオンマネージャにアクセスでき、ダッシュボードを見ることができることを意味する。いくつかの実施形態において、タブレット、ラップトップ、またはスマートフォン等のデバイスにログインしたユーザは、さらなる認証情報を提供せずにログオンマネージャにアクセスできる。ログインしたユーザはダッシュボードに表示されたアプリケーションに対するアクセスをリクエストでき、さらなるログインは必要ない。

いくつかの実施形態において、ウェブログオンマネージャ１１２Ａは、例えばユーザがダッシュボードに表示されたアプリケーションを選択したときに、ダッシュボードのアプリケーションにアクセスするためのリクエストを受信できる。リクエストはＨＴＴＰ／ＨＴＴＰＳを介してフロントエンドウェブログオンコンポーネント１１２Ａで受信でき、フロントエンドウェブログオンコンポーネント１１２Ａでアクセスプロトコル（カリフォルニア州レッドウッドショアズのＯｒａｃｌｅ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｒｐｏｒａｔｉｏｎから入手できるＯｒａｃｌｅ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ等）に変換でき、後置ウェブログオンコンポーネント１１２Ｂに転送できる。変換されたリクエストは、ウェブインターフェースのため、アプリケーションに対応付けられたポリシーのため、および／またはユーザに対応付けられた認証情報のため、フォーマットされたリクエストを含むことができる。後置ウェブログオンコンポーネント１１２Ｂはポリシーおよび／または認証情報リクエストを抽出し、それらをウェブインターフェース１０４を通じてＳＳＯサービス１００へ送信できる。ポリシーおよび／または認証情報はウェブインターフェース１０４を通じて後置ウェブログオンコンポーネント１１２Ｂへ返すことができる。ウェブログオンコンポーネント１１２Ｂはポリシーおよび／または認証情報を含むレスポンスメッセージを生成し、そのメッセージをアクセスプロトコルを介してウェブログオンコンポーネント１１２Ａへ送信できる。ウェブログオンマネージャ１１２Ａは、例えばアプリケーションのＵＲＬのＨＴＴＰリクエストを送信することによって、アプリケーションを起動できる。ウェブログオンマネージャ１１２Ａは、アプリケーションに対応付けられたポリシーを使用し、アプリケーションから受信したレスポンスにポリシーを照合できる。ウェブログオンマネージャ１１２Ａはポリシーに従って自動的にユーザ認証情報をアプリケーションに提供できる。

図９は、本発明の一実施形態に係る、ウェブログオンインターフェースを通じてウェブアプリケーションにアクセスする方法９００のブロック図を示す。ブロック９０２では、ウェブログオンマネージャユーザインターフェースを通じてアプリケーションにアクセスするためのリクエストを受信できる。いくつかの実施形態において、リクエストは、ユーザのクライアントデバイス（デスクトップまたはモバイルコンピューティングデバイス等）で実行するブラウザアプリケーションを通じてウェブベースインターフェースを介して受信できる。いくつかの実施形態において、ユーザはブラウザアプリケーションでウェブログオンマネージャユーザインターフェースのＵＲＬを入力することによってウェブログオンマネージャユーザインターフェースへ進むことができる。いくつかの実施形態では、ブラウザアプリケーションを通じてウェブページやウェブアプリケーションのリクエストを送信する際に、ユーザを自動的にウェブログオンマネージャユーザインターフェースへリダイレクトできる。ウェブログオンマネージャユーザインターフェースはユーザインターフェースにアクセスするための認証情報をユーザにリクエストできる。

ブロック９０４では、アプリケーションに対応付けられたポリシーを特定できる。ポリシーはアプリケーションのアクセス要件を規定できる。例えばポリシーは、アプリケーションへのアクセスに必要な認証情報の種類を規定でき、また認証情報がどのようにしてアプリケーションに提供されるか（例えばどのフィールドで認証情報を受け取るか）を規定できる。いくつかの実施形態において、ウェブログオンマネージャは、ポリシーリクエストメッセージを生成し、ウェブインターフェースを通じてＳＳＯシステムへポリシーリクエストメッセージを送信することによって、ポリシーを特定できる。ブロック９０６では、アプリケーション要件に基づいてユーザ認証情報を特定できる。いくつかの実施形態において、ウェブログオンマネージャは受信したポリシーに基づいて認証情報を特定できる。ウェブログオンマネージャは、認証情報リクエストメッセージを生成し、ウェブインターフェースを通じてＳＳＯシステムへ認証情報リクエストメッセージを送信することによって、認証情報を引き出すことができる。

ブロック９０８で、適切なポリシーと認証情報を受信したウェブログオンマネージャは自動的にユーザ認証情報をアプリケーションに提供できる。いくつかの実施形態において、アプリケーションから着信ウェブページレスポンスを受け取ったウェブログオンマネージャは、ポリシーに基づいて認証情報を挿入するウェブページレスポンスのフィールドを特定し、ウェブアプリケーションへ認証情報を送出できる。いくつかの実施形態において、ポリシーリクエストに応じてフォームフィルポリシーを受け取ったウェブログオンマネージャは、アプリケーションに対応するグラフィカルユーザインターフェースのフィールドにユーザ認証情報を自動的に挿入し、グラフィカルユーザインターフェースを通じてアプリケーションへユーザ認証情報を送出できる。ウェブログオンマネージャはログオンのときにログオンが成功したことを確認し、ユーザへレスポンスウェブページを返すことができる。

いくつかの実施形態において、ユーザまたはアドミニストレータはログオンマネージャに新たなアプリケーションを追加できる。例えば新入社員が雇われる場合に、会社標準のアプリケーションやよく使われるアプリケーションを新入社員のダッシュボードに準備できる。新たなアプリケーションを追加することは、ログオンマネージャに新たなアプリケーションを追加するためのリクエストを受信することを含み得、このリクエストはユーザの認証情報とポリシーを含み得る。ウェブログオンマネージャは、ポリシーと認証情報を蓄積するため、ウェブインターフェースを通じてデータマネージャへリクエストを送信できる。データマネージャがポリシーと認証情報が正常に蓄積されたことを確認すると、ログオンマネージャは新たなアプリケーションに相当するアプリケーションアイコンをログオンマネージャに追加でき、そのアイコンはログオンマネージャで表示される。いくつかの実施形態では、複数のアプリケーションを一度に一括して追加できる。かかるリクエストは、ユーザのため複数のアプリケーションを準備するため、各アプリケーションのポリシーおよび認証情報を含むリクエストを受信することを含み得る。ウェブログオンマネージャはその後、各アプリケーションのポリシーおよび認証情報を蓄積するため、複数のリクエスト（または一括リクエスト）をデータマネージャへ送信できる。正常に蓄積されたことの確認を受け取ったウェブログオンマネージャは、複数のアプリケーションの各々に相当するアイコンをログオンマネージャに追加でき、ユーザがログオンマネージャにログインするとそれらのアイコンが表示される。

いくつかの実施形態において、ログオンマネージャインターフェースは様々な種類の認証情報が対応付けられたアプリケーションの統一的展望を提示する。例えば、ユーザのダッシュボードに表示されるアプリケーションアイコンはまとめて表示できる。アプリケーションを起動するためアプリケーションアイコンが選択されると、ウェブログオンマネージャはＳＳＯシステムと通信し、しかるべき認証情報を使ってアプリケーションを起動できる。いくつかの実施形態において、ユーザのダッシュボードは認証情報の種類に基づいてアプリケーションを表示でき、あるいは複数のビューを表示でき、それぞれのビューには各種の認証情報に対応するアプリケーションが表示される。

上述したように、ＳＳＯサービスは、様々な経路を通じて（例えばユーザのブラウザにインストールされたＳＳＯアプリケーションを通じて、ウェブログオンマネージャを通じて、または他の経路を通じて）、ユーザによってアクセスされ、ユーザに提供され得る。リクエストは、クライアントに依存しない標準的なＳＳＯサービス提供方法を提供する１つ以上のウェブインターフェースを通じてＳＳＯサーバ１０２に伝達できる。

シングルサインオンのためのウェブベースインターフェース統合
一実施形態によると、認証情報管理やポリシー管理を含むシングルサインオンサービスは、１つ以上のウェブインターフェースを通じてウェブベースまたはクラウドベースＳＳＯシステムに一体化できる。クライアントは、ウェブを通じ、ＲＥＳＴインターフェース等の１つ以上のウェブインターフェースを介し、ＳＳＯシステムから提供されるＳＳＯサービスにアクセスできる。従来、ＳＳＯサービスはローカルで（例えばローカルマシンやローカルネットワークで実行するＳＳＯサービスを通じて）提供され、安全なポリシー・認証情報転送を提供するプロトコルを使って通信するように構成されていた。ただし、後方互換性を維持しながらウェブベースまたはクラウドベースのリモートＳＳＯシステムからこれらのサービスにアクセスするには、込み入った通信課題がある。クライアントはＨＴＴＰかＨＴＴＰＳでウェブリクエストを送信し、ウェブレスポンスを受信するように通常構成されるが、ＳＳＯサービスのリクエストとレスポンスはアクセスプロトコル（ネットワークアクセスプロトコルやＯｒａｃｌｅ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ等）を通常使用する。本発明の実施形態はリクエストのトンネリングを助長し、クライアントからＮＡＰを介してアクセスマネージャサーバへレスポンスをトンネルできる。

図１０は、本発明の一実施形態に係る、シングルサインオンサービスが組み込まれたＳＳＯサーバアーキテクチャ１０００を示す。ウェブベースであれデスクトップベースであれ、シングルサインオンにはポリシー管理サービスと認証情報管理サービスが必要である。上述したように、ポリシーはシングルサインオンシステムがアプリケーションとどのようにやり取りするかを定めるものであり、認証情報はアプリケーションにアクセスするユーザの認証に使われる。本発明の実施形態はウェブベースシングルサインオンの提供を目的とする。それぞれのシングルサインオンサービス１００はＲＥＳＴインターフェース等のウェブインターフェース１０４を使って露出できる。上述したように、ウェブインターフェースを使用することで様々な種類のクライアント１０６がシングルサインオンサービス１００にアクセスできるほか、新たなクライアントを容易に追加できる。いくつかの実施形態において、それぞれのＳＳＯサービス１００には異なるウェブインターフェースを対応付けることができる。ウェブインターフェースはポリシーや認証情報の作成、読み取り、更新、および削除（ＣＲＵＤ）を行う簡素な方式を提供する。

クライアント１０６は、シングルサインオンサービスのリクエストを、例えばポリシーや認証情報のリクエストを、ＳＳＯゲートウェイ１０８を通じてＳＳＯシステム１０２へ送信できる。図１０に見られるように、クライアント１０６からのリクエストは、アクセスエージェント１１０、ウェブログオンマネージャインターフェース１１２Ａ、および／またはＳＳＯアプリケーション１１４を通じてＳＳＯゲートウェイ１０８で受信できる。リクエストは、例えばアクセスプロトコル（ＮＡＰ、ＯＡＰ等）でトンネルされるＲＥＳＴリクエストであってよい。いくつかの実施形態では、１つのウェブインターフェースを使ってシングルサインオンサービスにアクセスできる。いくつかの実施形態では、それぞれのシングルサインオンサービスにサービス専用ウェブインターフェースを対応付けることができる。

いくつかの実施形態において、アクセスエージェント、ログオンマネージャ、またはプロキシを通じてＳＳＯサービスのリクエストがなされる場合は、クライアントからＨＴＴＰまたはＨＴＴＰＳリクエストとしてリクエストを受信できる。ＳＳＯゲートウェイ１０８にはトンネルプロキシ１００２Ａを組み込むことができ、トンネルプロキシ１００２ＡはＮＡＰ（ネットワークアクセスプロトコル）かＯＡＰ（Ｏｒａｃｌｅ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）を介してＳＳＯサーバ１０２へＨＴＴＰリクエストをトンネルできる。ＳＳＯゲートウェイ１０８とＳＳＯサーバ１０２にあるＮＡＰ／ＯＡＰエンドポイント１００４との間にＮＡＰまたはＯＡＰ接続を開通できる。いくつかの実施形態において、ＮＡＰ／ＯＡＰエンドポイント１００４は指定ＵＲＬでアクセスされるウェブインターフェースであってよい。ＳＳＯサーバ１０２にあるトンネルプロキシ１００２Ｂはリクエストを変換してＨＴＴＰまたはＨＴＴＰＳに戻し、変換したリクエストをＳＳＯサーバ１０２にあるしかるべきＳＳＯサービス１００へ送信できる。いくつかの実施形態において、サービスは、トンネルされたリクエストを受信し、かつトンネルプロキシを通じてトンネルされたレスポンスを送信するため、トンネルプロキシ１００２Ｂに登録できる。ＳＳＯサーバ１０２からリクエスト側クライアントへ至るレスポンスも同様にトンネルバックできる（例えばリクエストされたサービス１００によって生成されるＨＴＴＰまたはＨＴＴＰＳレスポンスは、リクエストをＮＡＰ／ＯＡＰに変換できるトンネルプロキシ１００２Ｂで受信でき、トンネルされたレスポンスはウェブインターフェース１００４を通じてトンネルプロキシ１００２Ａへ送信できる）。

例えばＵＲＬはＳＳＯゲートウェイ１０８からＳＳＯサーバ１０２へトンネルされるよう設定できる。いくつかの実施形態において、ＵＲＬはＳＳＯサーバ１０２でＳＳＯサービス１００に対応するサーブレットまたはＪＳＰページにマップできる。ＨＴＴＰ／ＳリクエストがＵＲＬへ送信されると、ＨＴＴＰ／ＳリクエストはＮＡＰ／ＯＡＰリクエストに変換され、ＮＡＰ／ＯＡＰ接続を介してＳＳＯサーバ１０２へ転送される。ＳＳＯサーバ１０２のエンドポイント１００４はＮＡＰ／ＯＡＰリクエストを受信し、このリクエストをトンネルプロキシ１００２Ｂに引き渡す。トンネルプロキシ１００２ＢはＮＡＰ／ＯＡＰリクエストをＨＴＴＰ／Ｓリクエストに変換し、このリクエストを適切なサービスへ送信できる。例えばトンネルプロキシはＮＡＰ／ＯＡＰリクエストをＨＴＴＰＳｅｒｖｌｅｔＲｅｑｕｅｓｔに変換し、適切なサーブレットを呼び出すことができる（ＪＳＰの場合はＪＳＰファイルからコンパイルされたＳｅｒｖｌｅｔ）。レスポンスはトンネルプロキシ１００２ＢでＮＡＰ／ＯＡＰに戻し、ＮＡＰ／ＯＡＰエンドポイント１００４へ引き渡すことができる。ＮＡＰ／ＯＡＰレスポンスはその後ＳＳＯゲートウェイへ返され、そこでトンネルプロキシ１００２ＡはＮＡＰ／ＯＡＰレスポンスをＨＴＴＰ／ＨＴＴＰＳレスポンスに戻すことができ、ＨＴＴＰ／ＨＴＴＰＳレスポンスは、ユーザのブラウザ等、クライアントへ返される。

いくつかの実施形態では、ウェブインターフェース層１００４（ＲＥＳＴ層等）を通じて受信されるリソースのリクエスト（アプリケーション、認証情報、ポリシー、またはその他データへのアクセス等）を解析し、所望のリソースが保護されているか否かを、またリクエストに認証クッキーが付属しているか否かを、判断できる。認証クッキーが提供されない、もしくは期限切れで、所望のリソースが保護されている場合は、認証サービスへ、例えばカリフォルニア州レッドウッドショアズのＯｒａｃｌｅ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｒｐｏｒａｔｉｏｎから入手できるＯｒａｃｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｍａｎａｇｅｒへ、リクエストをリダイレクトできる。認証サービスはユーザに認証情報（例えばユーザ名とパスワード）をリクエストできる。認証情報を受け取った認証サービスは認証情報を検証し、認証情報が有効ならば、認証クッキーをユーザのブラウザに返すことができる。リソースリクエストはその後ウェブインターフェース層へリダイレクトでき、認証クッキーは所望のリソースへのアクセスを提供する。いくつかの実施形態において、タイムアウトか積極的ログアウトによりユーザがセッションを終了する場合、ウェブインターフェース層はセッション情報を破壊してユーザをログオン画面に戻すことができる。

図１１Ａおよび１１Ｂは、本発明の一実施形態に係る、ポリシーマネージャアーキテクチャ１１００と認証情報マネージャアーキテクチャ１１０２を示す。図１１Ａに見られるように、ポリシーマネージャ１１０４は、複数のポリシーリポジトリ／システムにわたるポリシーの蓄積や引き出し等、ＳＳＯポリシー管理サービス１１０６への集約的アクセスを提供できる。ポリシーマネージャ１１０４にはウェブインターフェース１０４（例えばＲＥＳＴインターフェース）を対応付けることができ、そうすることでポリシーマネージャはウェブを介してリクエストを受信したりレスポンスを送信したりできる。これによりポリシーマネージャプラットフォームは独立し、ウェブベースのメッセージを送受できるどのクライアントともやり取りできるようになる。いくつかの実施形態では、ポリシーマネージャ１１０４を使ってユーザポリシーや運営ポリシーを管理できる。ポリシーマネージャ１１０４はプラグイン１１０６を使って様々な種類のアクセス制御をサポートする形に構成できる。それぞれのプラグインは、ポリシーの種類に応じてポリシーを作成、読み取り、更新、および削除する１つ以上の独自の方法を含むことができる。新たなアクセス制御種類のサポートを加えるため、新たなプラグインをポリシーマネージャに提供できる。

いくつかの実施形態において、ポリシーマネージャ１１０４は特定のポリシー種類からの抽象化層を提供でき、例えばクライアントはウェブインターフェース１０４を通じてポリシーマネージャ１１０４と通信する方法さえ知っていればよく、基礎となるポリシー種類と通信する方法を知る必要はない。リクエストを受け取ったポリシーマネージャ１１０４は、リクエストに対応するポリシー種類を判断でき、該当するプラグイン１１０６を使用し、ポリシー種類に合ったリクエストを生成できる。ポリシーマネージャ１１０４はポリシー種類に合ったリクエストをデータマネージャ１２２へ送信できる。後述するように、データマネージャ１２２は様々なデータソースへの抽象化層を提供する。データマネージャはリクエストに応じてデータを特定し、特定したデータをポリシーマネージャへ返すことができる。例えばポリシーマネージャからの検索リクエストは、リクエストに含まれる検索条件（例えばフィルタ、ポリシー識別子、ポリシー種類、その他）に応じてポリシーのリストを返すことができる。いくつかの実施形態において、条件が提供されない場合は全てのポリシーを取り出して返すことができる。新たなポリシーが追加されると、ポリシーマネージャ１１０４は識別子を作り、新たなポリシーに識別子を割り当てることができる。いくつかの実施形態では、複数のポリシーに同じ識別子を割り当てることができる。ポリシーマネージャ１１０４はその後、識別子とポリシーを含むリストをデータマネージャ１２２に引き渡すことができる。同様に、更新操作は、１つ以上の既存ポリシーに割り当てられた識別子と更新されたポリシー情報を含んでよい。ポリシーマネージャ１１０４は識別子と更新されたポリシーをデータマネージャ１２２へ送信でき、データマネージャ１２２は更新されたポリシーを蓄積できる。削除リクエストは１組の識別子を含んでよく、データマネージャ１２２は特定されたポリシーを削除し、削除のステータス情報を返すことができる。いくつかの実施形態において、ポリシー管理リクエストは、エンドユーザからクライアントデバイスを通じて、および／またはアドミニストレータからアドミンコンソールを通じて、受信できる。

いくつかの実施形態において、ポリシーマネージャ１１０４はアプリケーションテンプレートを管理できる。それぞれのアプリケーションテンプレートは、アプリケーションにＳＳＯサービスをどのように提供するかを定める定義を含むオブジェクトであってよい。例えばアプリケーションテンプレートは、ＳＳＯシステムがＳＳＯサービスとやり取りし照合し、挿入し、特定のアプリケーションに提供する方法を定義できる。所与のアプリケーションテンプレートには様々な照合種類に各々相当する１つ以上のサブフォームを対応付けることができる（例えばログインＵＩ、パスワード変更ＵＩ、成功／失敗ＵＩ、相互作用の方法、その他）。いくつかの実施形態において、特定のアプリケーションテンプレートには多数のユーザを対応付けることができ、ユーザは多数のアプリケーションテンプレートにアクセスできる。さらに、いくつかの実施形態において、アプリケーションテンプレートには多数の認証情報を対応付けることができる。いくつかの実施形態において、アプリケーションテンプレートには１つ以上の他のポリシーを対応付けることができる（例えばパスワードポリシー、認証情報共用ポリシー、その他）。

いくつかの実施形態において、ポリシーマネージャ１１０４はパスワードポリシーを管理できる。上述したように、それぞれのパスワードポリシーにはパスワードポリシーを共用する１つ以上のアプリケーションテンプレートを対応付けることができる。パスワードポリシーは、アプリケーションのパスワードを設定したり更新したりする際にプロビジョニングマネージャ１１１２および／またはパスワードリセットマネージャ１１１４で使用できる。いくつかの実施形態では、プロビジョニングおよび／またはパスワードリセットのときにパスワードを自動的に生成するためパスワードポリシーを使用できるほか、ユーザから受け取ったパスワードを検証するためパスワードポリシーを使用できる。いくつかの実施形態において、ポリシーマネージャ１１０４は、ユーザ設定やローカルに配備された設定より優先する運営ポリシーを管理できる。

図１１Ｂに見られるように、認証情報マネージャ１１１０は別々のリポジトリ１２０に蓄積された１種類以上の認証情報にわたるエンドユーザ認証情報管理のための集約的アクセスを提供できる。認証情報マネージャ１１１０はクライアントからの認証情報管理操作を抽象化でき、必要なロジック量を減らして新たなクライアントの開発を簡素化する。認証情報マネージャ１１１０はプラットフォームから独立しており、ウェブ上でメッセージを送受できるどのクライアントとも通信できる。

いくつかの実施形態において、認証情報マネージャ１１１０は複数のリポジトリ１２０にわたる認証情報の蓄積と引き出しを管理でき、既存のユーザ認証情報にアクセスするための後方互換性を提供する。認証情報マネージャ１１１０は、クライアントが委譲認証情報や特権認証情報を含む様々な種類のＳＳＯ認証情報を管理することを可能にできる。認証情報マネージャはウェブインターフェース１０４を通じてＡＰＩを公開することができ、ＡＰＩは、認証情報の取得、追加、更新、削除といったＣＲＵＤ操作を提供する。これは認証情報ストアからの抽象化層を提供し、例えばクライアントは認証情報マネージャと通信する方法さえ知っていればよく、多数のサポートされた認証情報データストアと通信する方法を知る必要はない。ウェブインターフェース１０４を通じて認証情報リクエストを受け取った認証情報マネージャ１１１０は、認証情報の種類に応じた１つ以上のサブマネージャ（特権認証情報マネージャ１１１４、委譲認証情報マネージャ１１１８、ＳＳＯ認証情報マネージャ１１２０等）を使ってリクエストを解析でき、適切なデータストアを特定し、認証情報リクエストを履行する。

いくつかの実施形態において、認証情報マネージャ１１１０は所与のユーザの認証情報リクエストを受信できる。認証情報マネージャ１１１０はそれぞれのサブマネージャ１１１４、１１１８、１１２０へリクエストを送信でき、ユーザに対応付けられた認証情報を特定し、一致する認証情報を返す。いくつかの実施形態において、認証情報マネージャ１１１０は、特権アカウント認証情報等の認証情報を取得するためのリクエストを受信できる。認証情報マネージャは認証情報を取得するため、認証情報を取得するためのリクエストを該当するサブマネージャへ送信できる（例えば特権アカウント認証情報を追加する場合、認証情報マネージャは特権認証情報マネージャ１１１４へリクエストを送信できる）。該当するサブマネージャは（例えば特権サーバ１１１６から）認証情報を調べ出し、この認証情報を認証情報マネージャ１１１０へ返すことができる。いくつかの実施形態において、機密扱いにするべき認証情報のフィールドは、認証情報マネージャ１１１０へ認証情報を送信する前に暗号化できる。

いくつかの実施形態において、認証情報マネージャ１１１０は、認証情報取得操作を受け取る場合に、リクエストに基づいて認証情報（例えばリクエストで指定されるユーザ、認証情報ＩＤ、認証情報種類、またはその他基準に対応する認証情報）のリストをリクエストできる。いくつかの実施形態において、リクエストで基準が指定されない場合、認証情報マネージャ１１１０はリクエストするユーザに対応付けられた全ての認証情報をリクエストできる。いくつかの実施形態において、認証情報マネージャ１１１０はユーザの認証情報を追加するためのリクエストを受信できる。認証情報マネージャ１１１０は認証情報ごとに認証情報識別子を生成し、追加すべき認証情報の種類に応じて該当するサブマネージャを呼び出すことができる。サブマネージャは受け取った認証情報を検証でき、適切なデータリポジトリ１２０に認証情報を蓄積するためデータマネージャ１２２へリクエストを送信できる。データマネージャは追加された認証情報のステータスを返すことができる。同様に、認証情報マネージャ１１１０は認証情報を更新するためのリクエストを受信できる。認証情報マネージャ１１１０は、更新された認証情報を含むリクエストを該当するサブマネージャへ送信できる。サブマネージャは更新された認証情報を検証でき、更新された認証情報を蓄積するためデータマネージャ１２２へリクエストを送信できる。更新ステータスを返すことができる。いくつかの実施形態において、認証情報マネージャ１１１０は認証情報を削除するためのリクエストを受信できる。認証情報マネージャ１１１０は該当するサブマネージャを特定し、そのサブマネージャへ認証情報を削除するためのリクエストを送信できる。いくつかの実施形態において、認証情報が委譲されている場合は、削除に先立ち委譲を取り消すことができる。

図１２は、本発明の一実施形態に係る、ウェブベースインターフェースを通じてＳＳＯサービスを提供する方法１２００のブロック図を示す。ブロック１２０２では、シングルサインオンサービスに対するリクエストが受信される。リクエストは、クライアントデバイス、アドミンコンソール、アプリケーション、または他の何らかのエンティティから受信できる。リクエストはシングルサインオンサービスに対応付けられたウェブインターフェースを介して受信できる。いくつかの実施形態では、１つのウェブインターフェースが１つ以上のＳＳＯサービスへ向けられた全リクエストの集中入口点として機能できる。リクエストが受信されると、そのリクエストに対応するＳＳＯサービスを特定でき、そのＳＳＯサービスに対応するエンドポイントへリクエストを転送できる。

いくつかの実施形態において、プロキシは第１のプロトコルでリクエストを受信でき、プロキシはリクエストを第１のプロトコルから第２のプロトコルに変換し、変換されたリクエストをシングルサインオンサービスへ転送する。例えばリクエストはＨＴＴＰ／Ｓリクエストであってよく、プロキシはＮＡＰやＯＡＰ等のアクセスプロトコルでＨＴＴＰ／Ｓリクエストをトンネルできる。いくつかの実施形態では、第２のプロキシがトンネルされたリクエストを受信し、ＳＳＯサービスへ引き渡すＨＴＴＰ／Ｓリクエストを抽出できる。いくつかの実施形態では、レスポンスも同様にトンネルされてリクエスト側クライアントへ返すことができる。例えば第２のプロキシはＳＳＯサービスからレスポンス（例えばリクエストされた認証情報、ポリシー、確認メッセージ等を含む）を受信できる。レスポンスはＨＴＴＰ／Ｓレスポンスであってよい。プロキシはＮＡＰ、ＯＡＰ、または類似アクセスプロトコルを使ってＨＴＴＰ／Ｓレスポンスをトンネルし、トンネルされたレスポンスをプロキシを介してリクエスト側クライアントへ返すことができる。

ブロック１２０４では、ポリシーまたは認証情報を管理するためのリクエストに基づきデータマネージャへデータリクエストを送信できる。いくつかの実施形態において、ＳＳＯサービスに対するリクエストは、例えばポリシー管理リクエスト（ポリシーを作成、読み取り、更新、または削除するためのリクエスト等）であってよく、あるいは認証情報管理リクエスト（認証情報を作成、読み取り、更新、または削除するためのリクエスト等）であってよい。

種類の異なるポリシーは、データソース専用のインターフェースでアクセスできる別々のデータソースに蓄積されるため、従来、ＳＳＯシステムで扱えるポリシーの種類には限りがあった。これはエンドユーザが選べるオプションを制限し、あるいは多数のアプリケーションをサポートすることをエンドユーザに強いた。ただし上述したように、本発明の実施形態が提供するポリシーマネージャは第１の（汎用）インターフェースを通じてリクエストを受信できる。リクエストはインターフェースに従って遂行すべきポリシー管理操作（例えばＣＲＵＤ操作）を指定できる。ポリシー管理リクエストはデータソースに依存しなくてよい（例えばリクエストはポリシーがどこにどのように蓄積されるかを指定しなくてよい、あるいはリクエストはデータソースによって異なる操作を含まなくてよい）。ポリシーマネージャはその後、ポリシー管理リクエストに対応するポリシー管理プラグインを特定し、特定したポリシー管理プラグインに基づき第２の（データソース専用）インターフェースの形式にポリシー管理リクエストを変換できる。ポリシーマネージャはその後、１つ以上のポリシー管理操作に基づいてデータリクエストを生成できる。

同様に、認証情報は、それぞれ専用のインターフェースでアクセスできる様々な認証情報ストアに蓄積できる。これは従来、ＳＳＯアプリケーションを同種の認証情報を使用するものに限定していた。本発明の実施形態が提供する認証情報マネージャは、別々の認証情報ストアに蓄積された様々な種類の認証情報を管理する形に構成できる。認証情報管理リクエストを受信したら、これを認証情報マネージャへ送信できる。ポリシーマネージャと同様、認証情報マネージャは汎用インターフェースを通じてリクエストを受信できる。これは、認証情報管理リクエストを出すクライアントとそのリクエストに応じる認証情報ストアとの間で抽象化層として機能する。いくつかの実施形態において、認証情報マネージャは認証情報管理リクエストに対応するサブマネージャを特定し、特定したサブマネージャに基づき第２のインターフェースの形式に認証情報管理リクエストを変換できる。第２のインターフェースはサブマネージャによって管理される特定の認証情報ストアに一致し得る。認証情報マネージャはその後、１つ以上のポリシー管理操作に基づいてデータリクエストを生成できる。

ブロック１２０６では、対応するウェブインターフェースを介してレスポンスが返される。レスポンスはリクエストに従って引き出されたデータ（例えばポリシー、認証情報）を含むことができる。いくつかの実施形態において、レスポンスは作成、更新、または削除操作が成功したか失敗したかを伝えることができる。

仮想データストレージとポリシーおよび認証情報データソースの管理
上述したように、本発明の実施形態は、フォームフィル、連合、保護等、種々のアクセスを利用する１つ以上の異なるアプリケーションでシングルサインオンをサポートできる。アクセスの種類が異なるポリシーや認証情報は種類の異なるリポジトリに蓄積できる。一実施形態によると、統一インターフェースを通じて種々のアクセスをサポートするため、実際の物理的ストレージ（ＯＩＤ、ＡＤ、ＡＤＡＭ、データベース、その他）に依存しない仮想データ管理システムが提供される。データ管理システムは認証情報とポリシーを管理するためＳＰＩ層を提供できる。データ管理システムはまた、ＣＲＵＤ操作を遂行するためＡＰＩを提供でき、使用するデータストアコンテナに依存せず権限（ＡＣＬ権限、データレベル権限等）を管理できる。いくつかの実施形態において、データ管理システムはデータアクセスを高速化するためマルチハッシュマップ方式のキャッシュを使用できる。

いくつかの実施形態において、データ管理システムは、認証情報、ポリシー、運営サービス、および他の構成およびセキュリティサービスを管理できる集約的リポジトリを提供する。これは、ユーザが様々なクライアント１０６を通じてＳＳＯサービスにアクセスしＳＳＯサービスを消費することを可能にする。データ管理システムは、Ｏｒａｃｌｅ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｅｒｓ（ＯＩＤ、ＯＤＳＥＥ、ＯＵＤ）、Ｍｉｃｒｏｓｏｆｔ Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ、Ｍｉｃｒｏｓｏｆｔ ＡＤＡＭ／ＡＤ−ＬＤＳ、および他のＬＤＡＰ適合ディレクトリ、ならびにＳＱＬデータベース、およびローカルまたはネットワークファイルシステム等、様々なリポジトリおよびサービスに対し統一的なインターフェースを提示できる。データ管理は拡張可能であり、適合プラグインを実装することによって新たなデータソースやサービスをデータ管理システムに組み入れることができる。

いくつかの実施形態において、データ管理システムは、クライアントによってローカルに蓄積された認証情報を、データ管理システムによって管理される１つ以上の認証情報データストアに蓄積された認証情報に同期させることができる。（例えば起動時に、または認証情報が追加、削除、または更新されるときに）同期イベントがトリガーされると、データ管理システムは、クライアントキャッシュに蓄積された認証情報データを、データ管理システムによって管理されるリポジトリに蓄積された認証情報データに比較できる。認証情報は、（例えばユーザにより）クライアントでローカルに更新でき、あるいは（例えばアドミニストレータにより、またはサードパーティ認証情報サービスにより）認証情報リポジトリで直接更新できる。同期のときには、ローカルに蓄積された認証情報と１つ以上の認証情報データストアに蓄積された認証情報に矛盾が見つかる可能性がある。矛盾ポリシーはどの認証情報を保存すべきかを規定できる。いくつかの実施形態では、最後に更新された認証情報を保存でき、他の認証情報は破棄できる。いくつかの実施形態では、認証情報データストアに蓄積された認証情報を保存でき、ローカルに蓄積された他の認証情報は破棄できる。同期はデスクトップベースＳＳＯサービスとの後方互換性も維持する。デスクトップベースサービスはローカルに保管された認証情報とポリシーを使ってＳＳＯサービスを提供するため、ローカルストアとウェブベースリポジトリとの同期を維持することで、デスクトップベースＳＳＯサービスは最新のＳＳＯサービスを提供し続けることができる。

図１３は、本発明の一実施形態に係る、データマネージャアーキテクチャ１３００を示す。図１３に見られるように、データマネージャ１２２は、拡張可能プラグイン１３０４を通じて１つ以上の異なる物理的ストレージシステム１３０２をサポートできるＳＳＯデータ管理のための集約的インターフェースを提供する。それぞれのプラグインは、ＳＳＯサービスから受信するデータリクエストを該当する物理的ストレージシステムで遂行することを可能にできる。データマネージャは拡張可能であるため、該当するプラグインを追加することで新たな種類の物理的データソースをサポートできる。データマネージャはデスクトップベースＳＳＯサービスに対し後方互換性を有する。

データマネージャ１２２は、複数のリポジトリ１３０２にわたってポリシーの蓄積と引き出しを可能にする単一のインターフェースを提供する。データリクエストは、特定のリポジトリ情報やリポジトリ固有操作を必要としない単一のＡＰＩを通じてデータマネージャ１２２で受信できる。代わりに、データマネージャ１２２はリクエストに適したリポジトリを特定し、該当するプラグイン１３０４を通じてそのリポジトリへリクエストを送信できる。いくつかの実施形態において、データマネージャ１２２はそれぞれのプラグインと連係するＳＰＩ層を提供する。データマネージャ１２２は、ポリシー、認証情報、およびプロビジョニングデータに関わるＣＲＵＤ操作のための統一的なインターフェースを露出する。

ＳＰＩ層はＣＲＵＤ操作の種類に基づいてプラグインインスタンスを自動初期化できる。いくつかの実施形態において、データマネージャ１２２は、データストア１２０２を指定せずにＣＲＵＤ操作を遂行するために使われる汎用インターフェースを提供できる。いくつかの実施形態では、各種の操作（例えば認証情報、ポリシー、およびプロビジョニング操作）のために汎用インターフェースを提供できる。汎用インターフェースを通じてリクエストが受信されると、データマネージャ１２２は、ＳＳＯシステム１０２によって（例えばデータマネージャ１２２によって）管理される設定情報からデータストアに特化した操作や接続情報を特定できる。データマネージャ１２２はその後、データストアと通信するため該当するプラグインを初期化できる。

いくつかの実施形態において、プラグインインスタンスが初めて呼び出されて初期化が行われるときには、データストアのためコンテクストオブジェクトプールを作成できる。これは高度なアベイラビリティとスレッド安全性を提供できる。ＣＲＵＤ操作ごとに別々のコンテクストオブジェクトをプールから割り当てることができ、操作が完了したらプールに戻すことができる。データマネージャ１２２は、コネクションプーリング（例えばＪＮＤＩサービスプロバイダによって提供）とコンテクストプーリングを使用でき、アプリケーションが起動するときに接続のプールを作り、接続を作るのにかかる時間や切断するのにかかる時間を短縮することによってリソースを節約する。また、コネクションプールを開始することで、接続作成、アプリケーションの最大接続数、接続の最大アイドル時間、およびその他構成詳細をコネクションプールマネージャに委任できるため、データストアへの接続の管理を簡素化できる。

いくつかの実施形態では、様々なデータリポジトリ１３０２に蓄積されたポリシーや認証情報を調べるときのパフォーマンスを向上させるため、１つ以上のハッシュマップをデータマネージャ１２２で使用できる。いくつかの実施形態において、ある１つのハッシュマップはポリシー種類を識別子とポリシーオブジェクトにマップできる。別のハッシュマップはポリシー名をポリシーリファレンスにマップできる。別のハッシュマップはキーをポリシーオブジェクトにマップできる。別のハッシュマップは値をポリシーオブジェクトのリストにマップできる。

いくつかの実施形態では、認証情報、ポリシー、およびプロビジョニングサービスで作成、読み取り、更新、および削除（ＣＲＵＤ）操作をサポートできる。データマネージャ１２２はウェブインターフェースを通じてＣＲＵＤ操作を露出できる。例えば認証情報操作は、指定されたオブジェクト（例えばアプリケーション、サービス）の新たな認証情報を作成すること、ユーザおよび少なくとも１つのアプリケーションに対応付けられた認証情報を読み取ること（例えば引き出すこと）、指定された認証情報を更新すること（例えば認証情報を修正すること、または新たな認証情報を提供すること）、および指定されたオブジェクトの認証情報を削除することを含み得る。ポリシーおよびプロビジョニングサービスでも同様の操作を提供できる。

いくつかの実施形態において、データマネージャ１２２は、アプリケーションテンプレート、パスワードポリシー、認証情報共用グループ、および運営データを含むポリシーデータへのＣＲＵＤ操作をサポートできる。いくつかの実施形態において、データマネージャ１２２はさらに、認証情報データ、プロビジョニングデータ（例えば命令／キー）、ユーザ設定、データ管理設定、ユーザシークレット（ＵＡＭ）、暗号鍵（ＵＡＭ）、およびエンロールメント認証情報（ＵＡＭ）へのＣＲＵＤ操作をサポートできる。

図１４は、本発明の一実施形態に係る、複数のデータストアに蓄積された認証情報を管理する方法１４００のブロック図を示す。ブロック１４０２で、拡張可能データマネージャは１つ以上のシングルサインオンサービスに対し１つ以上のストレージシステムの統一的展望を提供できる。いくつかの実施形態において、それぞれのシングルサインオンサービスにはウェブインターフェースが対応付けられる。

ブロック１４０４では、シングルサインオンサービスから認証情報を求めるデータリクエストを拡張可能データマネージャで受信できる。拡張可能データマネージャは１つ以上のストレージシステムに対し抽象化層として機能できるため、リクエストはストレージシステムに依存しない。例えばデータリクエストは、所望の認証情報を特定するための基準を含むことができる。基準は様々な種類の認証情報に一致するため広範であってよい。従来のシステムでは、ユーザがそれぞれの認証情報ストアで一致する認証情報を別々に検索しなければならない。しかし本発明の一実施形態によると、データマネージャは１つのリクエストを受信し、複数の認証情報ストアにまたがって検索できる。

ブロック１４０６では、リクエストに対応する少なくとも１つのストレージシステムを特定できる。例えばデータマネージャは、認証情報ＩＤ、認証情報種類、その他基準等、リクエストに含まれる基準に基づき、１つ以上の対応するストレージシステムを特定できる。いくつかの実施形態において、データマネージャはハッシュマップを使用し、基準を基に該当するストレージシステムを特定できる。

ブロック１４０８では、少なくとも１つのストレージシステムの各々に対応するストレージシステムプラグインを特定できる。データマネージャは、プラグインを提供することによって多数のストレージシステムが連係できるＳＰＩ層を含むことができる。それぞれのプラグインは、第１の（汎用）インターフェースを通じてデータマネージャで受信するデータリクエストを、対応するストレージシステムに適合する形に変換できる。いくつかの実施形態では、データマネージャにプラグインを加えることで新たなストレージシステムのサポートを提供できる。データマネージャはアドミニストレータから新たなストレージシステムに対応するストレージシステムプラグインを受け取ることができる。いくつかの実施形態において、プラグインはデータマネージャによって提供されるＳＰＩを実装できる。データマネージャはプラグインを検査し（例えば必要な方法や構成ファイルが提供されていることを確認）、ストレージシステムプラグインをＳＰＩ層に加えることができる。

ブロック１４１０では、ストレージシステムプラグインを使ってストレージシステムからデータリクエストに対応するデータを引き出すことができる。いくつかの実施形態では、データリクエストに対応するデータを作成、読み取り、更新、または削除するため、第２の（ストレージシステム専用）インターフェースを通じてストレージシステムへ変換されたデータリクエストを送信できる。引き出されるデータは、所望の認証情報またはポリシーを、または作成、更新、または削除操作の成否の確認を、含むことができる。

ブロック１４１２では、リクエストされたデータをＳＳＯサービスへ返すことができる。いくつかの実施形態において、リクエストされたデータは検索リクエストに一致する１つ以上の認証情報を含んでよい。いくつかの実施形態において、リクエストされたデータは作成、更新、または削除操作の成否の確認を含んでよい。いくつかの実施形態において、データマネージャは、ストレージシステムから第２の（ストレージシステム専用）インターフェースを通じて認証情報を含むレスポンスを受信できる。データマネージャは認証情報の少なくとも一部分は暗号化でき、第１のインターフェースに基づいてレスポンスの形式を変えた後、第１のインターフェースを通じてレスポンスを返すことができる。

いくつかの実施形態において、データマネージャはアプリケーションのポリシーに関わるデータリクエストを受信することもできる。データマネージャは、リクエストに対応する少なくとも１つのストレージシステムと、少なくとも１つのストレージシステムに対応する少なくとも１つのストレージシステムプラグインを、特定できる。データマネージャはその後、少なくとも１つのストレージシステムプラグインを通じて少なくとも１つのストレージシステムでアプリケーションの１つ以上のポリシーを作成、読み取り、更新、または削除できる。いくつかの実施形態において、データマネージャは、リクエストを第１の（例えば汎用）インターフェースから第２の（例えばポリシーストア専用）インターフェースに変換でき、第２のデータリクエストに応じて少なくとも１つのポリシーを引き出すため、変換されたデータリクエストを第２のインターフェースを通じてストレージシステムへ送信できる。レスポンスも同様に第２のインターフェースから第１のインターフェースに形式を変えることができ、その後リクエスト側アプリケーションに返される。

図１５は、実施形態のいずれか１つを実装する分散システム１５００の簡略図を示す。図示された実施形態で、分散システム１５００は１つ以上のクライアントコンピューティングデバイス１５０２、１５０４、１５０６、および１５０８を含み、クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および１５０８は、１つ以上のネットワーク１５１０を介してウェブブラウザや独自クライアント（例えばＯｒａｃｌｅ Ｆｏｒｍｓ）等のクライアントアプリケーションを実行し操作するように構成される。サーバ１５１２はネットワーク１５１０経由で遠隔地のクライアントコンピューティングデバイス１５０２、１５０４、１５０６、および１５０８と通信する形に結合され得る。

様々な実施形態において、サーバ１５１２は、システムの１つ以上のコンポーネントによって提供される１つ以上のサービスまたはソフトウェアアプリケーションを実行するよう設定されてよい。いくつかの実施形態において、これらのサービスは、ウェブベースサービスとして、またはクラウドサービスとして、またはＳｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（ＳａａＳ）モデルのもとで、クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および／または１５０８のユーザに提供されてよい。クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および／または１５０８を操作するユーザは、１つ以上のクライアントアプリケーションを利用してサーバ１５１２とやり取りし、これらのコンポーネントによって提供されるサービスを利用してよい。

図示された構成で、システム１５００のソフトウェアコンポーネント１５１８、１５２０、および１５２２はサーバ１５１２で実装されたものとして示されている。他の実施形態において、システム１５００の１つ以上のコンポーネントは、および／またはこれらのコンポーネントによって提供されるサービスは、１つ以上のクライアントコンピューティングデバイス１５０２、１５０４、１５０６、および／または１５０８によって実装されてもよい。クライアントコンピューティングデバイスを操作するユーザは１つ以上クライアントアプリケーションを利用してこれらのコンポーネントによって提供されるサービスを使用してよい。これらのコンポーネントはハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせで実装されてよい。分散システム１５００とは異なる様々なシステム構成が可能であることを理解されたい。図示された実施形態は実施形態システムを実装する分散システムの一例であり、限定を意図するものではない。

クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および／または１５０８は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ Ｍｏｂｉｌｅ（登録商標）等のソフトウェアを、および／またはｉＯＳ、Ｗｉｎｄｏｗｓ Ｐｈｏｎｅ、Ａｎｄｒｏｉｄ、ＢｌａｃｋＢｅｒｒｙ １０、Ｐａｌｍ ＯＳ等の種々モバイルオペレーティングシステムを、実行し、かつインターネット、ｅメール、ショートメッセージサービス（ＳＭＳ）、Ｂｌａｃｋｂｅｒｒｙ（登録商標）、またはその他通信プロトコルに対応する、手持ち型可搬デバイス（例えばｉＰｈｏｎｅ（登録商標）、携帯電話機、ｉＰａｄ（登録商標）、コンピューティングタブレット、個人用デジタル補助装置（ＰＤＡ））またはウェアラブルデバイス（例えばＧｏｏｇｌｅ Ｇｌａｓｓ（登録商標）ヘッドマウントディスプレイ）であってよい。クライアントコンピューティングデバイスは、例えばＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ（登録商標）、および／またはＬｉｎｕｘ（登録商標）オペレーティングシステムの種々バージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む、汎用パーソナルコンピュータであってよい。クライアントコンピューティングデバイスは、様々なＧＮＵ／Ｌｉｎｕｘオペレーティングシステムを、例えばＧｏｏｇｌｅ Ｃｈｒｏｍｅ ＯＳを含み、ただしこれらに限定されない、様々な市販ＵＮＩＸ（登録商標）またはＵＮＩＸ系オペレーティングシステムのいずれかを実行する、ワークステーションコンピュータであってよい。前記の代わりに、または前記に加えて、クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および１５０８は、ネットワーク１５１０を介して通信できる、シンクライアントコンピュータ、インターネット対応ゲームシステム（例えばＫｉｎｅｃｔ（登録商標）ジェスチャ入力デバイスを有する、または有さない、Ｍｉｃｒｏｓｏｆｔ Ｘｂｏｘゲームコンソール）、および／またはパーソナルメッセージングデバイス等、他の何らかの電子デバイスであってよい。

４つのクライアントコンピューティングデバイスを含む例示的分散システム１５００が図示されているが、いくつものクライアントコンピューティングデバイスをサポートできる。他のデバイスも、例えばセンサーを有するデバイス等も、サーバ１５１２とやり取りできる。

分散システム１５００のネットワーク１５１０は、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）、ＳＮＡ（システムネットワークアーキテクチャ）、ＩＰＸ（インターネットパケット交換）、ＡｐｐｌｅＴａｌｋ等を含み、ただしこれらに限定されない、様々な市販プロトコルのいずれかを使ってデータ通信をサポートできる、当業者にとって周知の、どのような種類のネットワークであってよい。ほんの一例として、ネットワーク１５１０はローカルエリアネットワーク（ＬＡＮ）であってよく、例えばイーサネット（登録商標）、トークンリング、および／または同様のものに基づくローカルエリアネットワークであってよい。ネットワーク１５１０はワイドエリアネットワークであってよく、またインターネットであってもよい。これは、仮想プライベートネットワーク（ＶＰＮ）、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（例えば電気電子協会（ＩＥＥＥ）８０２．１１プロトコル、Ｂｌｕｅｔｏｏｔｈ（登録商標）、および／または他の何らかの無線プロトコルのいずれかで作動するネットワーク）、および／またはこれらのネットワークおよび／または他のネットワークの組み合わせを含み、ただしこれらに限定されない、仮想ネットワークを含み得る。

サーバ１５１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（例えばＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント型サーバ、その他を含む）、サーバファーム、サーバクラスタ、または他の何らかの適切な構成および／または組み合わせから成ってよい。様々な実施形態において、サーバ１５１２は上述した１つ以上のサービスまたはソフトウェアアプリケーションを実行する形に構成されてよい。例えばサーバ１５１２は、本開示の一実施形態に従って上述した処理を遂行するサーバであってよい。

サーバ１５１２は、上述したオペレーティングシステムを含むオペレーティングシステムや何らかの市販サーバオペレーティングシステムを実行してよい。サーバ１５１２はまた、様々なサーバプリケーションおよび／またはミッドティアアプリケーションのいずれかを実行してよく、ＨＴＴＰ（ハイパーテキスト転送プロトコル）サーバ、ＦＴＰ（ファイル転送プロトコル）サーバ、ＣＧＩ（共通ゲートウェイインターフェース）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバ等を含む。例示的データベースサーバは、Ｏｒａｃｌｅ、Ｍｉｃｒｏｓｏｆｔ、Ｓｙｂａｓｅ、ＩＢＭ（International Business Machines）等から入手できるデータベースサーバを含み、ただしそれらに限定されない。

いくつかの実施形態において、サーバ１５１２には、クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および１５０８のユーザから受信するデータフィードおよび／またはイベントアップデートを解析し整理する１つ以上のアプリケーションを組み込むことができる。一例として、データフィードおよび／またはイベントアップデートは、Ｔｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）アップデート、または１つ以上のサードパーティ情報源および連続データストリームから受信されるリアルタイムアップデートを含み得、ただしこれらに限定されず、リアルタイムアップデートは、センサーデータアプリケーション、ファイナンシャルティッカー、ネットワーク性能測定ツール（例えばネットワーク監視アプリケーション、トラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通モニタリング等に関するリアルタイムイベントを含み得る。サーバ１５１２には、クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および１５０８の１つ以上のディスプレイデバイスでデータフィードおよび／またはリアルタイムイベントを表示する１つ以上のアプリケーションを組み込むことができる。

分散システム１５００はまた、１つ以上のデータベース１５１４および１５１６を含んでよい。データベース１５１４および１５１６は様々な場所に存在してよい。例えばデータベース１５１４および１５１６のいずれか１つ以上は、サーバ１５１２内に局在（および／または存在）する非一時的記憶媒体に存在してよい。あるいはデータベース１５１４および１５１６はサーバ１５１２から離れていて、ネットワーク接続か専用接続でサーバ１５１２と通信してよい。１組の実施形態において、データベース１５１４および１５１６はストレージエリアネットワーク（ＳＡＮ）に存在してよい。同様に、サーバ１５１２に関わる機能を遂行するのに必要なファイルは、サーバ１５１２内に、および／または遠隔地に、適宜蓄積されてよい。１組の実施形態において、データベース１５１４および１５１６は、Ｏｒａｃｌｅによって提供されるデータベース等、ＳＱＬ形式のコマンドに応じてデータを蓄積、更新、および引き出すように構成されたリレーショナルデータベースを含み得る。

図１６は、本開示の一実施形態によるシステム環境１６００の１つ以上のコンポーネントの簡略ブロック図であり、実施形態システムの１つ以上のコンポーネントから提供されるサービスはクラウドサービスとして提供され得る。図示された実施形態において、システム環境１６００は１つ以上のクライアントコンピューティングデバイス１６０４、１６０６、および１６０８を含み、ユーザはクライアントコンピューティングデバイスを使ってクラウドサービスを提供するクラウドインフラシステム１６０２とやり取りできる。クライアントコンピューティングデバイスは、ウェブブラウザ、独自クライアントアプリケーション（例えばＯｒａｃｅｌ Ｆｏｒｍｓ）、または他の何らかのアプリケーション等、クライアントアプリケーションを操作するように構成されてよく、クライアントコンピューティングデバイスのユーザはクライアントアプリケーションを使ってクラウドインフラシステム１６０２とやり取りし、クラウドインフラシステム１６０２から提供されるサービスを利用できる。

図示されたクラウドインフラシステム１６０２が図示されたコンポーネント以外のコンポーネントを有し得ることを理解されたい。また、図示された実施形態は、本発明の一実施形態を採用し得るクラウドインフラシステムの一例に過ぎない。他の実施形態において、クラウドインフラシステム１６０２は図示されたコンポーネントより多い、または少ない、コンポーネントを有してよく、２つ以上のコンポーネントを組み合わせてよく、あるいは異なるコンポーネント構成または配置を有してよい。

クライアントコンピューティングデバイス１６０４、１６０６、および１６０８は、１５０２、１５０４、１５０６、および１５０８について上述したデバイスと同様のデバイスであってよい。

３つのクライアントコンピューティングデバイスを含む例示的システム環境１６００が図示されているが、いくつものクライアントコンピューティングデバイスをサポートできる。他のデバイスも、例えばセンサーを有するデバイス等も、クラウドインフラシステム１６０２とやり取りできる。

ネットワーク１６１０はクライアント１６０４、１６０６、および１６０８とクラウドインフラシステム１６０２との通信とデータ交換を促進してよい。それぞれのネットワークは、ネットワーク１５１０について上述したものを含む、様々な市販プロトコルのいずれかを使ってデータ通信をサポートできる、当業者にとって周知の、どのような種類のネットワークであってよい。

クラウドインフラシステム１６０２は、サーバ１５１２について上述したものを含む、１つ以上のコンピュータおよび／またはサーバを備えてよい。

いくつかの実施形態において、クラウドインフラシステムによって提供されるサービスは、オンラインデータ蓄積およびバックアップソリューション、ウェブベースｅメールサービス、ホステッドオフィススイートおよびドキュメントコラボレーションサービス、データベース処理、マネジドテクニカルサポートサービス等、クラウドインフラシステムのユーザにオンデマンド方式で提供される多数のサービスを含み得る。クラウドインフラシステムによって提供されるサービスは動的に拡張してユーザのニーズを満たすことができる。クラウドインフラシステムによって提供されるサービスのインスタンス化は本書で「サービスインスタンス」と呼ばれる。概して、クラウドサービスプロバイダのシステムからインターネット等の通信ネットワークを介してユーザに提供されるサービスは「クラウドサービス」と呼ばれる。通常、パブリッククラウド環境においてクラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身の敷地内サーバおよびシステムと異なる。例えば、クラウドサービスプロバイダのシステムはアプリケーションをホストでき、ユーザはインターネット等の通信ネットワークを介して当該アプリケーションをオンデマンド方式で注文し利用することができる。

いくつかの例において、コンピュータネットワーククラウドインフラにおけるサービスは、ストレージ、ホステッドデータベース、ホステッドウェブサーバ、ソフトウェアアプリケーションに対する保護コンピュータネットワークアクセス、またはクラウドベンダーからユーザに提供されるその他サービス、または当技術で周知のサービスを含み得る。例えば、サービスはインターネットを通じてクラウド上のリモートストレージにアクセスするパスワード保護アクセスを含み得る。もうひとつの例として、サービスはネットワーク開発者専用のスクリプト言語ミドルウェアエンジンやウェブサービスベースのホステッドリレーショナルデータベースを含み得る。もうひとつの例として、サービスはクラウドベンダーのウェブサイトでホストされたｅメールソフトウェアアプリケーションへのアクセスを含み得る。

いくつかの実施形態において、クラウドインフラシステム１６０２は、セルフサービス形式で契約方式で拡張的に間違いなく確実に安全に顧客へ提供される１組のアプリケーション、ミドルウェア、およびデータベースサービス商品を含み得る。譲受人によって提供されているＯｒａｃｌｅ Ｐｕｂｌｉｃ Ｃｌｏｕｄはかかるクラウドインフラシステムの一例である。

様々な実施形態において、クラウドインフラシステム１６０２は、クラウドインフラシステム１６０２によって提供されるサービスに対する顧客の契約を自動的に準備、管理、および追跡するように構成されてよい。クラウドインフラシステム１６０２は様々な配備モデルでクラウドサービスを提供してよい。例えばサービスはパブリッククラウドモデルで提供されてよく、この場合はクラウドインフラシステム１６０２がクラウドサービスを販売する組織によって所有され（例えばＯｒａｃｌｅによって所有され）、一般大衆や企業にサービスが提供される。もうひとつの例として、サービスはプライベートクラウドモデルで提供されてよく、この場合はクラウドインフラシステム１６０２が１つの組織のために運営され、組織内の１つ以上のエンティティにサービスを提供してよい。クラウドサービスはコミュニティクラウドモデルで提供されてもよく、この場合は関連コミュニティの中の複数の組織によってクラウドインフラシステム１６０２とクラウドインフラシステム１６０２によって提供されるサービスが共用される。２つ以上の異なるモデルを組み合わせたハイブリッドクラウドモデルでクラウドサービスが提供されてもよい。

いくつかの実施形態において、クラウドインフラシステム１６０２によって提供されるサービスは、Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（ＳａａＳ）カテゴリ、Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ（ＰａａＳ）カテゴリ、Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（ＩａａＳ）カテゴリ、またはハイブリッドサービスを含むその他サービスカテゴリで提供される１つ以上のサービスを含み得る。顧客は契約注文によりクラウドインフラシステム１６０２によって提供される１つ以上のサービスを注文できる。クラウドインフラシステム１６０２は、顧客の契約注文に含まれるサービスを提供するための処理を遂行する。

いくつかの実施形態において、クラウドインフラシステム１６０２によって提供されるサービスは、アプリケーションサービス、プラットフォームサービス、およびインフラサービスを含み得、ただしこれらに限定されない。いくつかの例において、アプリケーションサービスはクラウドインフラシステムからＳａａＳプラットフォームを通じて提供されてよい。ＳａａＳプラットフォームはＳａａＳカテゴリに該当するクラウドサービスを提供する形に構成されてよい。例えばＳａａＳプラットフォームは、統合開発・配備プラットフォームで一連のオンデマンドアプリケーションを構築し引き渡す能力を提供できる。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するため基礎となるソフトウェアとインフラを管理し制御することができる。ＳａａＳプラットフォームによって提供されるサービスを利用することにより、顧客はクラウドインフラシステムで実行するアプリケーションを利用できる。顧客はライセンスやサポートを購入しなくてもアプリケーションサービスを得ることができる。様々なＳａａＳサービスが提供され得る。例は、大規模組織の販売業績管理、企業統合、およびビジネスフレキシビリティのためのソリューションを提供するサービスを含み、ただしこれらに限定されない。

いくつかの実施形態において、プラットフォームサービスはクラウドインフラシステムからＰａａＳプラットフォームを通じて提供されてよい。ＰａａＳプラットフォームはＰａａＳカテゴリに該当するクラウドサービスを提供する形に構成されてよい。プラットフォームサービスの例は、組織（Ｏｒａｃｌｅ等）が共通の共用アーキテクチャで既存のアプリケーションを整理統合することを可能にするサービス、ならびにプラットフォームによって提供される共用サービスを利用する新たなアプリケーションを構築する能力を含み得、ただしこれらに限定されない。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するため基礎となるソフトウェアとインフラを管理し制御することができる。顧客はライセンスやサポートを購入しなくてもクラウドインフラシステムによって提供されるＰａａＳサービスを得ることができる。プラットフォームサービスの例は、Ｏｒａｃｌｅ Ｊａｖａ Ｃｌｏｕｄ Ｓｅｒｖｉｃｅ（ＪＣＳ）、Ｏｒａｃｌｅ Ｄａｔａｂａｓｅ Ｃｌｏｕｄ Ｓｅｒｖｉｃｅ（ＤＢＣＳ）、およびその他を含み、ただしこれらに限定されない。

ＰａａＳプラットフォームによって提供されるサービスを利用することにより、顧客はクラウドインフラシステムでサポートされたプログラミング言語やツールを使用できるほか、配備されたサービスをコントロールすることもできる。いくつかの実施形態において、クラウドインフラシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（例えばＯｒａｃｌｅ Ｆｕｓｉｏｎ Ｍｉｄｄｌｅｗａｒｅサービス）、およびＪａｖａクラウドサービスを含み得る。いくつかの実施形態において、データベースクラウドサービスは、組織がデータベースリソースをプールし、データベースクラウドの形でＤａｔａｂａｓｅ ａｓ ａ Ｓｅｒｖｉｃｅを顧客に提供することを可能にする共用サービス配備モデルをサポートできる。ミドルウェアクラウドサービスは顧客が様々なビジネスアプリケーションを開発し配備するためのプラットフォームを提供でき、Ｊａｖａクラウドサービスは顧客がクラウドインフラシステムでＪａｖａアプリケーションを配備するためのプラットフォームを提供できる。

クラウドインフラシステムではＩａａＳプラットフォームによって様々なインフラサービスが提供されてよい。インフラサービスは、ＳａａＳプラットフォームやＰａａＳプラットフォームによって提供されるサービスを利用する顧客のため、ストレージ、ネットワーク、およびその他基礎的コンピューティングリソース等、基礎となるコンピューティングリソースの管理と制御を助長する。

いくつかの実施形態において、クラウドインフラシステム１６０２はまた、クラウドインフラシステムの顧客に様々なサービスを提供するために使われるリソースを提供するインフラリソース１６３０を含んでよい。一実施形態において、インフラリソース１６３０は、ＰａａＳプラットフォームやＳａａＳプラットフォームによって提供されるサービスを実行するため、サーバ、ストレージ、およびネットワーキングリソース等、予め統合され最適化されたハードウェアの組み合わせを含んでよい。

いくつかの実施形態において、クラウドインフラシステム１６０２内のリソースは複数のユーザによって共用されてよく、デマンドに応じて動的に再配分されてよい。加えて、リソースは様々な時間帯にあるユーザに配分されてよい。例えばクラウドインフラシステム１６３０は、第１の時間帯にある第１のユーザ群にクラウドインフラシステムのリソースを所定の時間にわたって利用させ、その後別の時間帯にある別のユーザ群に同じリソースを再配分することにより、リソースの利用効率を最大限に高めることができる。

いくつかの実施形態では、クラウドインフラシステム１６０２のコンポーネントやモジュールによって共用され、またクラウドインフラシステム１６０２によって提供されるサービスによって共用される、いくつかの内部共用サービス１６３２が提供されてよい。これらの内部共用サービスは、セキュリティおよびアイデンティティサービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウイルススキャンおよびホワイトリストサービス、高アベイラビリティ、バックアップおよびリカバリサービス、クラウドサポートを可能にするサービス、ｅメールサービス、通知サービス、ファイル転送サービス等を含み得、ただしこれらに限定されない。

いくつかの実施形態において、クラウドインフラシステム１６０２はクラウドインフラシステムにおける総合クラウドサービス（例えばＳａａＳ、ＰａａＳ、およびＩａａＳサービス）管理を提供してよい。一実施形態において、クラウド管理機能は、クラウドインフラシステム１６０２で受信される顧客の契約等を準備、管理、および追跡する能力を含み得る。

一実施形態では、図示されているように、注文管理モジュール１６２０、注文調整モジュール１６２２、注文プロビジョニングモジュール１６２４、注文管理監視モジュール１６２６、およびアイデンティティ管理モジュール１６２８等、１つ以上のモジュールによってクラウド管理機能が提供されてよい。これらのモジュールは、１つ以上のコンピュータおよび／またはサーバを含んでよく、または１つ以上のコンピュータおよび／またはサーバを用いて提供されてよく、１つ以上のコンピュータおよび／またはサーバは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、または他の何らかの適切な構成および／または組み合わせであってよい。

例示的操作１６３４において、クライアントデバイス１６０４、１６０６、または１６０８等のクライアントデバイスを使用する顧客は、クラウドインフラシステム１６０２によって提供される１つ以上のサービスをリクエストし、クラウドインフラシステム１６０２によって提供される１つ以上のサービスの契約注文を入れることにより、クラウドインフラシステム１６０２とやり取りできる。いくつかの実施形態において、顧客はクラウドユーザインターフェース（ＵＩ）、クラウドＵＩ １６１２、クラウドＵＩ １６１４、および／またはクラウドＵＩ １６１６にアクセスし、これらのＵＩを通じて契約注文を入れることができる。顧客が入れた注文に応じてクラウドインフラシステム１６０２で受信される注文情報は、顧客を特定する情報と、顧客が契約しようとするクラウドインフラシステム１６０２から提供される１つ以上のサービスを特定する情報を含んでよい。

顧客が注文を入れた後には、クラウドＵＩ １６１２、１６１４、および／または１６１６を通じて注文情報が受信される。

操作１６３６では、注文が注文データベース１６１８に蓄積される。注文データベース１６１８は、クラウドインフラシステム１６１８によって操作され、かつ他のシステムエレメントと連動される、いくつかのデータベースのいずれか１つであってよい。

操作１６３８では、注文情報が注文管理モジュール１６２０へ転送される。いくつかの実施形態において、注文管理モジュール１６２０は、注文を検査し、検査した注文を記帳する等、注文に関わる課金・会計機能を遂行するように構成されてよい。

操作１６４０では、注文に関する情報が注文調整モジュール１６２２へ伝達される。注文調整モジュール１６２２は注文情報を基にし、顧客が入れた注文に応じたサービスやリソースの準備を調整できる。いくつかの例において、注文調整モジュール１６２２は、注文プロビジョニングモジュール１６２４のサービスを使ってリソースの準備を調整し、契約されたサービスを支援できる。

いくつかの実施形態において、注文調整モジュール１６２２は注文に関わるビジネスプロセスの管理を可能にし、ビジネスロジックを適用して注文を準備段階に進めるべきか否かを判断する。操作１６４２で、新たな契約注文を受信した注文調整モジュール１６２２は、契約注文を履行するにあたって必要なリソースを配分し構成するため、注文プロビジョニングモジュール１６２４へリクエストを送信する。注文プロビジョニングモジュール１６２４は顧客が注文するサービスのためのリソース配分を可能にする。注文プロビジョニングモジュール１６２４は、クラウドインフラシステム１６００によって提供されるクラウドサービスと、リクエストされたサービスを提供するためリソースを準備するのに使われる物理的実装層との間に、抽象化レベルを提供する。このため、サービスやリソースが臨機応変に準備されるか、それとも予め準備されリクエストに応じて配分／割り当てられるかといった実装の詳細から注文調整モジュール１６２２を分離することができる。

サービスおよびリソースが準備されると、操作１６４４で、クラウドインフラシステム１６０２の注文プロビジョニングモジュール１６２４によって、クライアントデバイス１６０４、１６０６、および／または１６０８の顧客へ、提供されるサービスの通知が送信されてよい。

操作１６４６では、顧客の契約注文が注文管理監視モジュール１６２６によって管理され追跡されてよい。いくつかの例において、注文管理監視モジュール１６２６は、使用ストレージ数、転送データ量、ユーザ数、システム稼動・不稼働時間等、契約注文に含まれるサービスについて運用統計を収集する形に構成されてよい。

いくつかの実施形態において、クラウドインフラシステム１６００はアイデンティティ管理モジュール１６２８を含んでよい。アイデンティティ管理モジュール１６２８は、クラウドインフラシステム１６００でアクセス管理サービスや認可サービス等のアイデンティティサービスを提供するように構成されてよい。いくつかの実施形態において、アイデンティティ管理モジュール１６２８は、クラウドインフラシステム１６０２によって提供されるサービスの利用を望む顧客に関する情報を制御できる。かかる情報は、かかる顧客のアイデンティティを認証する情報と、それらの顧客が種々システムリソース（ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメント、その他）に対して遂行することを許可されるアクションを記述する情報を含んでよい。アイデンティティ管理モジュール１６２８はまた、それぞれの顧客に関する記述的情報と、その記述的情報を誰がどのようにアクセスし修正するかに関する記述的情報の管理を含んでよい。

図１７は、本発明の種々実施形態を実装し得る例示的コンピュータシステム１７００を示す。システム１７００は上述したコンピュータシステムのいずれかを実装するために使用されてよい。図に見られるように、コンピュータシステム１７００は、バスサブシステム１７０２を通じていくつかの周辺サブシステムと通信する処理装置１７０４を含む。これらの周辺サブシステムは、処理加速装置１７０６、Ｉ／Ｏサブシステム１７０８、ストレージサブシステム１７１８、および通信サブシステム１７２４を含んでよい。ストレージサブシステム１７１８は有形コンピュータ読取可能記憶媒体１７２２とシステムメモリ１７１０とを含む。

バスサブシステム１７０２は、コンピュータシステム１７００の様々なコンポーネントやサブシステムが互いに意図した通りに通信するためのメカニズムを提供する。バスサブシステム１７０２は１本のバスとして概略的に図示されているが、バスサブシステムの代替実施形態は複数のバスを利用してよい。バスサブシステム１７０２は、メモリバスまたはメモリコントローラ、周辺バス、および種々バスアーキテクチャのいずれかを使用するローカルバスを含む、数種のバス構造のいずれかであってよい。例えば、かかるアーキテクチャは、インダストリースタンダードアーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、エンハンストＩＳＡ（ＥＩＳＡ）バス、ビデオエレクトロニクススタンダーズアソシエーション（ＶＥＳＡ）ローカルバス、およびＩＥＥＥ Ｐ１３８６．１規格に従って製造されメザニンとして実装できるペリフェラルコンポーネントインターコネクト（ＰＣＩ）バスを含み得る。

１つ以上の集積回路（例えば従来のマイクロプロセッサやマイクロコントローラ）として実装できる処理装置１７０４はコンピュータシステム１７００の操作を制御する。処理装置１７０４には１つ以上のプロセッサを組み込むことができる。これらのプロセッサはシングルコアまたはマルチコアプロセッサを含み得る。いくつかの実施形態において、処理装置１７０４は、シングルまたはマルチコアプロセッサを各々含む１つ以上の独立した処理装置１７３２および／または１７３４として実装されてよい。他の実施形態において、処理装置１７０４は、１つのチップに２つのデュアルコアプロセッサを集積することによって形成されるクアドコア処理装置として実装されてもよい。

様々な実施形態において、処理装置１７０４はプログラムコードに応じて様々なプログラムを実行でき、複数の同時に実行するプログラムやプロセスを維持できる。実行されるプログラムコードの一部または全部は、プロセッサ１７０４に、および／またはストレージサブシステム１７１８に、随時入れることができる。プロセッサ１７０４は、適切なプログラミングにより、上述した様々な機能を提供できる。コンピュータシステム１７００は処理加速装置１７０６をさらに含んでよく、処理加速装置１７０６は、デジタル信号プロセッサ（ＤＳＰ）、専用プロセッサ、および／または同類のものを含んでよい。

Ｉ／Ｏサブシステム１７０８はユーザインターフェース入力デバイスとユーザインターフェース出力デバイスとを含んでよい。ユーザインターフェース入力デバイスは、キーボード、マウスまたはトラックボール等のポインティングデバイス、ディスプレイに一体化されたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、音声コマンド認識システムを備えた音声入力デバイス、マイクロフォン、および他種入力デバイスを含み得る。ユーザインターフェース入力デバイスは、例えばユーザが自然なユーザインターフェースを通じてジェスチャや音声コマンドによりＭｉｃｒｏｓｏｆｔ Ｘｂｏｘ（登録商標）３６０ゲームコントローラ等の入力デバイスを操作することを可能にするＭｉｃｒｏｓｏｆｔ Ｋｉｎｅｃｔ（登録商標）モーションセンサー等のモーション感知および／またはジェスチャ認識デバイスを含み得る。ユーザインターフェース入力デバイスはまた、ユーザの眼の動き（例えば写真を撮影するとき、および／またはメニューを選択するときの「瞬き」）を検出し、眼のジェスチャを入力デバイス（例えばＧｏｏｇｌｅ Ｇｌａｓｓ（登録商標））への入力に変換するＧｏｏｇｌｅ Ｇｌａｓｓ（登録商標）ブリンクディテクタ等の眼ジェスチャ認識デバイスを含み得る。加えて、ユーザインターフェース入力デバイスは、ユーザが音声コマンドで音声認識システム（例えばＳｉｒｉ（登録商標）ナビゲータ）とやり取りすることを可能にする音声認識感知デバイスを含み得る。

ユーザインターフェース入力デバイスはまた、三次元（３Ｄ）マイス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、およびスピーカー、デジタルカメラ、デジタルカムコーダー、ポータブルメディアプレイヤー、ウェブカメラ、画像スキャナ、指紋スキャナ、バーコードリーダー３Ｄスキャナ、３Ｄプリンタ、レーザー測距器、および視線追跡デバイス等の視聴覚デバイスを含み得、ただしこれらに限定されない。加えてユーザインターフェース入力デバイスは、例えばコンピュータ断層撮影、磁気共鳴撮影、ポジション放出断層撮影、および医療用超音波検査装置等の医療用画像入力デバイスを含み得る。ユーザインターフェース入力デバイスはまた、例えばＭＩＤＩキーボード、デジタル楽器等の音響入力デバイスを含み得る。

ユーザインターフェース出力デバイスは、ディスプレイサブシステム、インジケータライト、または音響出力デバイス等の非視覚ディスプレイを含み得る。ディスプレイサブシステムは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）やプラズマディスプレイ等を使用するフラットパネルデバイス、投影装置、タッチスクリーン等であってよい。概して、用語「出力デバイス」は、コンピュータシステム１７００からユーザまたは他コンピュータへ情報を出力するあらゆる種類のデバイスまたはメカニズムを含む。例えばユーザインターフェース出力デバイスは、モニター、プリンタ、スピーカー、ヘッドフォン、自動車ナビゲーションシステム、プロッタ、音声出力デバイス、モデム等、文字、画像、および視聴覚情報を視覚的に伝える様々なディスプレイデバイスを含み得、ただしこれらに限定されない。

コンピュータシステム１７００はストレージサブシステム１７１８を備えてよく、ストレージサブシステム１７１８はシステムメモリ１７１０内に位置するものとして現在図示されているソフトウェアエレメントを備える。システムメモリ１７１０は、処理装置１７０４に読み込まれて実行されるプログラム命令を格納できるほか、これらのプログラムの実行中に収集されるデータを格納できる。

コンピュータシステム１７００の構成や種類に応じて、システムメモリ１７１０は揮発性（ランダムアクセスメモリ（ＲＡＭ）等）であってよく、および／または不揮発性（読み取り専用メモリ（ＲＯＭ）、フラッシュメモリ等）であってよい。ＲＡＭは通常、処理装置１７０４によって速やかにアクセスされるデータおよび／またはプログラムモジュールを、および／または処理装置１７０４によって目下操作され実行されているデータおよび／またはプログラムモジュールを、格納する。いくつかの実装において、システムメモリ１７１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）やダイナミックランダムアクセスメモリ（ＤＲＡＭ）等、複数の異種メモリを含み得る。いくつかの実装において、起動時等にコンピュータシステム１７００の中でエレメント間の情報転送を支援する基礎的ルーチンを含む基本入出力システム（ＢＩＯＳ）は、ＲＯＭに通常格納されてよい。限定ではなく例示を目的とし、システムメモリ１７１０には、アプリケーションプログラム１７１２と、プログラムデータ１７１４と、オペレーティングシステム１７１６とが図示されており、アプリケーションプログラム１７１２は、クライアントアプリケーション、ウェブブラウザ、ミッドティアアプリケーション、リレーショナルデータベース管理システム（ＲＤＢＭＳ）、その他を含み得る。例えばオペレーティングシステム１７１６は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ（登録商標）、および／またはＬｉｎｕｘオペレーティングシステムの種々バージョン、様々な市販ＵＮＩＸ（登録商標）またはＵＮＩＸ系オペレーティングシステム（様々なＧＮＵ／Ｌｉｎｕｘオペレーティングシステム、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ（登録商標）ＯＳ等を含み、ただしこれらに限定されない）、および／またはｉＯＳ、Ｗｉｎｄｏｗｓ（登録商標）Ｐｈｏｎｅ、Ａｎｄｒｏｉｄ（登録商標）ＯＳ、ＢｌａｃｋＢｅｒｒｙ（登録商標）１７ ＯＳ、Ｐａｌｍ（登録商標）ＯＳオペレーティングシステム等の種々モバイルオペレーティングシステムを、含み得る。

ストレージサブシステム１７１８はまた、いくつかの実施形態の機能を提供する基礎的プログラミングおよびデータ構造を格納する有形コンピュータ読取可能記憶媒体を提供してよい。プロセッサによって実行されたときに上述した機能を提供するソフトウェア（プログラム、コードモジュール、命令）はストレージサブシステム１７１８に格納されてよい。これらのソフトウェアモジュールは処理装置１７０４によって実行されてよい。ストレージサブシステム１７１８はまた、本発明に従って使用されるデータを格納するリポジトリを提供してよい。

ストレージサブシステム１７００はまた、コンピュータ読取可能記憶媒体１７２２へ接続できるコンピュータ読取可能記憶媒体読取装置１７２０を含んでよい。コンピュータ読取可能記憶媒体１７２２は、システムメモリ１７１０と連携することで、リモート、ローカル、固定、および／または取り外し可能ストレージデバイスであると同時に、コンピュータ読取可能情報を一時的におよび／または永久的に格納、蓄積、伝送、および引き出す記憶媒体に成り得る。

コードを、またはコードの一部を、格納するコンピュータ読取可能記憶媒体１７２２はまた、何らかの情報の格納および／または伝送方法または技術で実装される揮発性および不揮発性、取り外し可能または取り外し不能媒体等であって、ただしこれらに限定されない、記憶媒体および通信媒体を含む、当技術で周知の、または当技術で使用されている、何らかの適切な媒体を含み得る。これは、ＲＡＭ、ＲＯＭ、電子的消去プログラム可能ＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリ、またはその他メモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、またはその他光学式ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、またはその他磁気式ストレージデバイス、またはその他有形コンピュータ読取可能媒体等の有形コンピュータ読取可能記憶媒体を含み得る。これはまた、情報を伝送するために使用できかつコンピュータシステム１７００からアクセスできるデジタル信号、データ伝送、または他の何らかの媒体等、無形コンピュータ読取可能媒体を含み得る。

例えばコンピュータ読取可能記憶媒体１７２２は、取り外し不能不揮発性磁気媒体で読み書きを行うハードディスクドライブ、取り外し可能不揮発性磁気ディスクで読み書きを行う磁気ディスクドライブ、およびＣＤ ＲＯＭ、ＤＶＤ、およびＢｌｕ−Ｒａｙ（登録商標）ディスク、またはその他光媒体等の取り外し可能不揮発性光ディスクで読み書きを行う光ディスクドライブを含み得る。コンピュータ読取可能記憶媒体１７２２は、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ、セキュアデジタル（ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープ等を含み得、ただしこれらに限定されない。コンピュータ読取可能記憶媒体１７２２はまた、フラッシュメモリ型ＳＳＤ、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭ等、不揮発性メモリを基礎とするソリッドステートドライブ（ＳＳＤ）、ならびにソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭ、ＤＲＡＭ型ＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤ、およびＤＲＡＭ型ＳＳＤとフラッシュメモリ型ＳＳＤを組み合わせたハイブリッドＳＳＤ等、揮発性メモリを基礎とするＳＳＤを含み得る。ディスクドライブと関連コンピュータ読取可能媒体は、コンピュータシステム１７００のコンピュータ読取可能命令、データ構造、プログラムモジュール、およびその他データの不揮発性格納を提供できる。

通信サブシステム１７２４は他のコンピュータシステムやネットワークに対するインターフェースを提供する。通信サブシステム１７２４は、他システムからデータを受信しコンピュータシステム１７００から他システムへデータを伝送するインターフェースとして機能する。例えば通信サブシステム１７２４は、コンピュータシステム１７００がインターネットを介して１つ以上のデバイスへ接続することを可能にできる。いくつかの実施形態において、通信サブシステム１７２４は、無線音声および／またはデータネットワークにアクセスする無線周波（ＲＦ）送受信コンポーネント（例えば携帯電話技術、３Ｇ、４Ｇ、またはＥＤＧＥ（グローバル進化のための改良データレート）等の先進データネットワーク技術、ＷｉＦｉ（ＩＥＥＥ ８０２．１１系規格、またはその他モバイル通信技術、またはこれらの組み合わせを使用するもの）、全地球測位システム（ＧＰＳ）受信コンポーネント、および／またはその他コンポーネントを含み得る。いくつかの実施形態において、通信サブシステム１７２４は、無線インターフェースに加えて、または無線インターフェースの代わりに、有線ネットワーク接続（例えばイーサネット）を提供できる。

いくつかの実施形態において、通信サブシステム１７２４はまた、コンピュータシステム１７００を使用する１名以上のユーザに代わって、構造化および／または非構造化データフィード１７２６、イベントストリーム１７２８、イベントアップデート１７３０等の形で入力通信を受信してよい。

例えば通信サブシステム１７２４は、Ｔｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）アップデート、リッチサイトサマリー（ＲＳＳ）フィード等のウェブフィード等、データフィード１７２６をソーシャルネットワークおよび／またはその他通信サービスのユーザからリアルタイムで受信する形に、および／または１つ以上のサードパーティ情報源からリアルタイムアップデートを受信する形に、構成されてよい。

加えて、通信サブシステム１７２４は連続データストリームの形でデータを受信する形に構成されてもよく、連続データストリームは、明確な終わりがない、本質的に連続する、または際限のない、リアルタイムイベントおよび／またはイベントアップデート１７３０のイベントストリーム１７２８を含み得る。連続データを生成するアプリケーションの例は、例えばセンサーデータアプリケーション、ファイナンシャルティッカー、ネットワーク性能測定ツール（例えばネットワーク監視アプリケーション、トラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通モニタリング等を含み得る。

通信サブシステム１７２４はまた、コンピュータシステム１７００へ結合された１つ以上のストリーミングデータソースコンピュータと通信する１つ以上のデータベースへ、構造化および／または非構造化データフィード１７２６、イベントストリーム１７２８、イベントアップデート１７３０等を出力する形に構成されてよい。

コンピュータシステム１７００は、手持ち型可搬デバイス（例えばｉＰｈｏｎｅ（登録商標）、携帯電話機、ｉＰａｄ（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブルデバイス（例えばＧｏｏｇｌｅ Ｇｌａｓｓ（登録商標）ヘッドマウントディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラック、または他の何らかのデータ処理システムを含む、様々な種類のいずれか１つであってよい。

コンピュータやネットワークは絶えず変化しているため、図示されたコンピュータシステム１７００の説明は一例に過ぎない。このほかにも、図示されたシステムより多い、または少ない、コンポーネントを有する数多くの構成が可能である。例えば、カスタマイズされたハードウェアを使用することもでき、および／または特定のエレメントをハードウェア、ファームウェア、ソフトウェア（アプレットを含む）、または組み合わせで実装することもできる。また、ネットワーク入力／出力デバイス等の他のコンピューティングデバイスへの接続を使用できる。当業者なら、本書の開示と教示を基に様々な実施形態を実装する他のやり方および／または方法を理解するであろう。

以上の明細書では本発明の特定の実施形態を参照しながら本発明の態様が説明されているが、当業者なら、本発明がこれらの実施形態に限定されないことを理解するであろう。上述した本発明の様々な特徴や態様は個別に、またはまとめて、使用できる。例えば他の態様においては開示された特徴を適当に組み合わせることができる。また、これらの実施形態は、明細書の幅広い精神と範囲から逸脱することなく、ここに記載されていないいくつもの環境や用途に利用できる。明細書と図面は限定ではなく例証とみなすべきものである。

Claims (22)

1. コンピュータが実行する方法であって、
   シングルサインオンサービスに対するリクエストを前記シングルサインオンサービスに対応付けられたウェブインターフェースを介して受信することと、
   ポリシーまたは認証情報を管理する前記リクエストに基づきデータマネージャへデータリクエストを送信することと、を含み、
   前記ポリシーまたは認証情報を管理することは、前記コンピュータが備えるコンピュータ読取可能記憶媒体に前記ポリシーまたは認証情報を蓄積することを含み、
   対応付けられたウェブインターフェースを介してレスポンスを返すこととを含み、前記リクエストは、前記リクエストに応じたポリシーまたは認証情報を含み、アプリケーションに自動的にログインするためクライアントデバイスによって使用され、
   前記方法は、さらに、
   前記リクエストをプロキシによって第１のプロトコルで受信すること、
   受信した前記リクエストをプロキシによって前記第１のプロトコルから第２のプロトコルに変換すること、
   変換した前記リクエストを前記シングルサインオンサービスへ転送すること、を含む、方法。
2. 前記レスポンスは前記プロキシによって前記第２のプロトコルで受信され、前記プロキシは前記レスポンスを前記第２のプロトコルから前記第１のプロトコルに変換し、前記変換したレスポンスを返す、請求項１に記載の方法。
3. シングルサインオンサービスに対する前記リクエストはポリシー管理リクエストであり、
   １つ以上のポリシー管理操作を含む前記ポリシー管理リクエストをポリシーマネージャへ送信することと、
   前記１つ以上のポリシー管理操作に基づいて前記データリクエストを生成することとをさらに含む、請求項１または２に記載の方法。
4. 前記ポリシー管理リクエストは第１のインターフェース向けにフォーマットされ、前記ポリシーマネージャは前記ポリシー管理リクエストに対応付けられたポリシー管理プラグインを特定し、前記特定したポリシー管理プラグインに基づき前記ポリシー管理リクエストを第２のインターフェース向けのフォーマットに変換する、請求項３に記載の方法。
5. シングルサインオンサービスに対する前記リクエストは認証情報管理リクエストであり、
   １つ以上の認証情報管理操作を含む前記認証情報管理リクエストを認証情報マネージャへ送信することと、
   前記１つ以上の認証情報管理操作に基づいて前記データリクエストを生成することとをさらに含む、請求項１〜４のいずれか１項に記載の方法。
6. 前記認証情報管理リクエストは第１のインターフェース向けにフォーマットされ、前記認証情報マネージャは前記認証情報管理リクエストに対応付けられたサブマネージャを特定し、前記特定したサブマネージャに基づき前記認証情報管理リクエストを第２のインターフェース向けのフォーマットに変換する、請求項５に記載の方法。
7. コンピュータ読取可能記憶媒体とプロセッサとを含むコンピュータと、
   前記コンピュータで実行する複数のシングルサインオンサービスとを備え、シングルサインオンサービスの各々にはウェブインターフェースが対応付けられ、
   前記複数のシングルサインオンサービスの各々は、
   クライアントデバイスから前記対応付けられたウェブインターフェースを介してポリシーまたは認証情報を管理するリクエストを受信し、
   前記ポリシーまたは認証情報を管理する前記リクエストに基づいてデータマネージャへデータリクエストを送信し、
   前記対応付けられたウェブインターフェースを介して前記クライアントデバイスへレスポンスを返すように構成され、前記リクエストは、前記リクエストに応じたポリシーまたは認証情報を含み、アプリケーションに自動的にログインするためクライアントデバイスによって使用され、
   前記リクエストを第１のプロトコルで受信し、前記リクエストを前記第１のプロトコルから第２のプロトコルに変換し、前記変換したリクエストを前記シングルサインオンサービスへ転送する、第１のトンネルプロキシをさらに備える、システム。
8. 前記レスポンスを前記第２のプロトコルで受信し、前記レスポンスを前記第２のプロトコルから前記第１のプロトコルに変換し、前記変換したレスポンスを返す、第２のトンネルプロキシをさらに備える、請求項７に記載のシステム。
9. シングルサインオンサービスに対する前記リクエストはポリシー管理リクエストであり、前記複数のシングルサインオンサービスの各々はさらに、
   １つ以上のポリシー管理操作を含む前記ポリシー管理リクエストをポリシーマネージャへ送信し、
   前記１つ以上のポリシー管理操作に基づいて前記データリクエストを生成する、ように構成される、請求項７または８に記載のシステム。
10. 前記ポリシー管理リクエストは第１のインターフェース向けにフォーマットされ、前記ポリシーマネージャは前記ポリシー管理リクエストに対応付けられたポリシー管理プラグインを特定し、前記特定したポリシー管理プラグインに基づき前記ポリシー管理リクエストを第２のインターフェース向けのフォーマットに変換する、請求項９に記載のシステム。
11. シングルサインオンサービスに対する前記リクエストは認証情報管理リクエストであり、前記複数のシングルサインオンサービスの各々はさらに、
    １つ以上の認証情報管理操作を含む前記認証情報管理リクエストを認証情報マネージャへ送信し、
    前記１つ以上の認証情報管理操作に基づいて前記データリクエストを生成するよう構成される、請求項７〜１０のいずれか１項に記載のシステム。
12. 前記認証情報管理リクエストは第１のインターフェース向けにフォーマットされ、前記認証情報マネージャは前記認証情報管理リクエストに対応付けられたサブマネージャを特定し、前記特定したサブマネージャに基づき前記認証情報管理リクエストを第２のインターフェース向けのフォーマットに変換する、請求項１１に記載のシステム。
13. 命令を有するコンピュータ可読プログラムであって、前記命令がプロセッサによって実行されると前記プロセッサは、
    シングルサインオンサービスに対するリクエストを前記シングルサインオンサービスに対応付けられたウェブインターフェースを介して受信するステップと、
    ポリシーまたは認証情報を管理する前記リクエストに基づきデータマネージャへデータリクエストを送信するステップと、
    対応付けられたウェブインターフェースを介してレスポンスを返すステップとを実行し、前記リクエストは、前記リクエストに応じたポリシーまたは認証情報を含み、アプリケーションに自動的にログインするためクライアントデバイスによって使用され、
    前記プロセッサは、さらに、前記リクエストをプロキシによって第１のプロトコルで受信し、前記プロキシによって前記リクエストを前記第１のプロトコルから第２のプロトコルに変換し、前記変換したリクエストを前記シングルサインオンサービスへ転送するステップを実行する、コンピュータ可読プログラム。
14. コンピュータが実行する方法であって、
    シングルサインオンサービスに対するリクエストを前記シングルサインオンサービスに対応付けられたウェブインターフェースを介して受信することと、
    ポリシーまたは認証情報を管理する前記リクエストに基づきデータマネージャへデータリクエストを送信することと、を含み、
    前記ポリシーまたは認証情報を管理することは、前記コンピュータが備えるコンピュータ読取可能記憶媒体に前記ポリシーまたは認証情報を蓄積することを含み、
    対応付けられたウェブインターフェースを介してレスポンスを返すこととを含み、前記リクエストは、前記リクエストに応じたポリシーまたは認証情報を含み、アプリケーションに自動的にログインするためクライアントデバイスによって使用され、
    シングルサインオンサービスに対する前記リクエストはポリシー管理リクエストを含み、
    １つ以上のポリシー管理操作を含む前記ポリシー管理リクエストをポリシーマネージャへ送信することと、
    前記１つ以上のポリシー管理操作に基づいて前記データリクエストを生成することとをさらに含む、方法。
15. 前記ポリシー管理リクエストは第１のインターフェース向けにフォーマットされ、前記ポリシーマネージャは前記ポリシー管理リクエストに対応付けられたポリシー管理プラグインを特定し、前記特定したポリシー管理プラグインに基づき前記ポリシー管理リクエストを第２のインターフェース向けのフォーマットに変換する、請求項１４に記載の方法。
16. コンピュータが実行する方法であって、
    シングルサインオンサービスに対するリクエストを前記シングルサインオンサービスに対応付けられたウェブインターフェースを介して受信することと、
    ポリシーまたは認証情報を管理する前記リクエストに基づきデータマネージャへデータリクエストを送信することと、を含み、
    前記ポリシーまたは認証情報を管理することは、前記コンピュータが備えるコンピュータ読取可能記憶媒体に前記ポリシーまたは認証情報を蓄積することを含み、
    対応付けられたウェブインターフェースを介してレスポンスを返すこととを含み、前記リクエストは、前記リクエストに応じたポリシーまたは認証情報を含み、アプリケーションに自動的にログインするためクライアントデバイスによって使用され、
    シングルサインオンサービスに対する前記リクエストは認証情報管理リクエストを含み、
    １つ以上の認証情報管理操作を含む前記認証情報管理リクエストを認証情報マネージャへ送信することと、
    前記１つ以上の認証情報管理操作に基づいて前記データリクエストを生成することとをさらに含む、方法。
17. 前記認証情報管理リクエストは第１のインターフェース向けにフォーマットされ、前記認証情報マネージャは前記認証情報管理リクエストに対応付けられたサブマネージャを特定し、前記特定したサブマネージャに基づき前記認証情報管理リクエストを第２のインターフェース向けのフォーマットに変換する、請求項１６に記載の方法。
18. コンピュータ読取可能記憶媒体とプロセッサとを含むコンピュータと、
    前記コンピュータで実行する複数のシングルサインオンサービスとを備え、シングルサインオンサービスの各々にはウェブインターフェースが対応付けられ、
    前記複数のシングルサインオンサービスの各々は、
    クライアントデバイスから前記対応付けられたウェブインターフェースを介してポリシーまたは認証情報を管理するリクエストを受信し、
    前記ポリシーまたは認証情報を管理する前記リクエストに基づいてデータマネージャへデータリクエストを送信し、
    前記対応付けられたウェブインターフェースを介して前記クライアントデバイスへレスポンスを返すように構成され、前記リクエストは、前記リクエストに応じたポリシーまたは認証情報を含み、アプリケーションに自動的にログインするためクライアントデバイスによって使用され、
    シングルサインオンサービスに対する前記リクエストはポリシー管理リクエストを含み、前記複数のシングルサインオンサービスの各々はさらに、
    １つ以上のポリシー管理操作を含む前記ポリシー管理リクエストをポリシーマネージャへ送信し、
    前記１つ以上のポリシー管理操作に基づいて前記データリクエストを生成する、ように構成される、システム。
19. 前記ポリシー管理リクエストは第１のインターフェース向けにフォーマットされ、前記ポリシーマネージャは前記ポリシー管理リクエストに対応付けられたポリシー管理プラグインを特定し、前記特定したポリシー管理プラグインに基づき前記ポリシー管理リクエストを第２のインターフェース向けのフォーマットに変換する、請求項１８に記載のシステム。
20. コンピュータ読取可能記憶媒体とプロセッサとを含むコンピュータと、
    前記コンピュータで実行する複数のシングルサインオンサービスとを備え、シングルサインオンサービスの各々にはウェブインターフェースが対応付けられ、
    前記複数のシングルサインオンサービスの各々は、
    クライアントデバイスから前記対応付けられたウェブインターフェースを介してポリシーまたは認証情報を管理するリクエストを受信し、
    前記ポリシーまたは認証情報を管理する前記リクエストに基づいてデータマネージャへデータリクエストを送信し、
    前記対応付けられたウェブインターフェースを介して前記クライアントデバイスへレスポンスを返すように構成され、前記リクエストは、前記リクエストに応じたポリシーまたは認証情報を含み、アプリケーションに自動的にログインするためクライアントデバイスによって使用され、
    シングルサインオンサービスに対する前記リクエストは認証情報管理リクエストを含み、前記複数のシングルサインオンサービスの各々はさらに、
    １つ以上の認証情報管理操作を含む前記認証情報管理リクエストを認証情報マネージャへ送信し、
    前記１つ以上の認証情報管理操作に基づいて前記データリクエストを生成するよう構成される、システム。
21. 前記認証情報管理リクエストは第１のインターフェース向けにフォーマットされ、前記認証情報マネージャは前記認証情報管理リクエストに対応付けられたサブマネージャを特定し、前記特定したサブマネージャに基づき前記認証情報管理リクエストを第２のインターフェース向けのフォーマットに変換する、請求項２０に記載のシステム。
22. 命令を有するコンピュータ可読プログラムであって、前記命令がプロセッサによって実行されると、前記プロセッサに請求項１〜６および１４〜１７のいずれか１項に記載の方法を実行させるコンピュータ可読プログラム。