特許 6010610 アクセス制御アーキテクチャ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6010610

(24)【登録日】2016年9月23日

(45)【発行日】2016年10月19日

(54)【発明の名称】アクセス制御アーキテクチャ

(51)【国際特許分類】

   G06F 21/62 20130101AFI20161006BHJP

【ＦＩ】

   G06F21/62

【請求項の数】13

【全頁数】32

(21)【出願番号】特願2014-510515(P2014-510515)

(86)(22)【出願日】2012年5月11日

(65)【公表番号】特表2014-513374(P2014-513374A)

(43)【公表日】2014年5月29日

(86)【国際出願番号】US2012037625

(87)【国際公開番号】WO2012155096

(87)【国際公開日】20121115

【審査請求日】2015年4月24日

(31)【優先権主張番号】61/485,025

(32)【優先日】2011年5月11日

(33)【優先権主張国】US

(31)【優先権主張番号】13/464,906

(32)【優先日】2012年5月4日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】特許業務法人深見特許事務所

(72)【発明者】

【氏名】スリニバサン，ウッピリ

(72)【発明者】

【氏名】モツクル，バムシ

(72)【発明者】

【氏名】トゥルラパティ，ラマナ・ラオ・エス

【審査官】 伏本 正典

(56)【参考文献】

【文献】 特開２００６−０７２５４８（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１０／０２５０７２９（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２００７／０２４０２３１（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ２１／６２

(57)【特許請求の範囲】

【請求項1】

アクセス制御システムであって、
アクセスメタデータオブジェクトのアクセスメタデータリポジトリを含み、アクセスメタデータリポジトリにおける複数のアクセスメタデータオブジェクトの各アクセスメタデータオブジェクトは、アクセスサービスに関連付けられたデータを記述しており、前記アクセス制御システムはさらに、
第１の要求エンティティから第１のアクセス要求を受信するように構成された入出力部と、
前記第１のアクセス要求に関連付けられた第１の要求タイプを判断するように構成されたサービス制御部と、
前記第１のアクセス要求が準拠するプロトコルによってのみ必要とされる情報のすべてを前記第１のアクセス要求から除外した第１の標準化されたアクセス要求を生成するよう構成された標準化部と、
前記第１の標準化されたアクセス要求と前記第１の要求タイプに関連付けられたアクセスメタデータオブジェクトとに少なくとも部分的に基づいて、前記第１の標準化されたアクセス要求の少なくとも一部を満たすように、第１の機能的コンポーネントを選択するように構成されたコンポーネント制御エンジンとを含み、
前記アクセスメタデータリポジトリ、前記入出力部、前記サービス制御部、前記標準化部、および前記コンポーネント制御エンジンは、１つ以上のコンピューティング装置上で実現され、
前記標準化部は、コンポーネント制御エンジンからの第１の標準化されたアクセス要求への応答に含まれるべき詳細を記述している特定のメタデータを、前記コンポーネント制御エンジンに送信するよう構成されており、
前記特定のメタデータは、前記第１の要求タイプに関連付けられたアクセスメタデータオブジェクト内に含まれる、アクセス制御システム。

【請求項2】

前記コンポーネント制御エンジンはさらに、前記第１の標準化されたアクセス要求の少なくとも一部を前記第１の機能的コンポーネントに提供するように構成されており、
前記コンポーネント制御エンジンはさらに、前記第１のアクセス要求に関連付けられた前記第１の要求タイプに適合する第１の応答の少なくとも一部を、前記第１の機能的コンポーネントに生成させるように構成されており、
前記標準化部はさらに、第１の機能的コンポーネントを含む異なる機能的コンポーネントによって生成された複数の部分的応答に基づいて、完全な応答を生成するよう構成されており、
前記サービス制御部はさらに、前記第１の応答の少なくとも一部を前記第１の要求エンティティに提供するように構成されている、請求項１に記載のアクセス制御システム。

【請求項3】

前記第１の要求エンティティは、信頼されるアプリケーションである第１のアプリケーションであり、
前記第１のアクセス要求は、第２のアプリケーションに関連付けられたセキュリティトークンについての要求を含んでおり、
応答の少なくとも一部を生成することは、前記第１のアプリケーションのユーザの代わりに前記第２のアプリケーションに関連付けられた変更を行なうことを前記第１のアプリケーションに承認する第１のトークンを生成することを含む、請求項１または２に記載のアクセス制御システム。

【請求項4】

前記入出力部はさらに、第２の要求エンティティから第２のアクセス要求を受信するように構成されており、前記第２のアクセス要求は、アイデンティティプロバイダに関連付けられたセキュリティトークンについての要求を含んでおり、
前記標準化部はさらに、第２の標準化されたアクセス要求を生成するように構成されており、
前記コンポーネント制御エンジンはさらに、第３のアプリケーションへのアクセスを承認する第２のトークンを、前記第１の機能的コンポーネントに生成させるように構成されており、
前記第１の機能的コンポーネントは、前記第１の標準化されたアクセス要求の少なくとも一部を受信することに応じて第１のトークンを生成するように構成されており、
前記第１の機能的コンポーネントは、前記第２の標準化されたアクセス要求の少なくとも一部を受信することに応じて第２のトークンを生成するように構成されている、請求項３に記載のアクセス制御システム。

【請求項5】

要求は、第１の機能的コンポーネントに関連付けられた状態と第２の機能的コンポーネントに関連付けられた状態とを識別する複合状態情報を含む、請求項１〜４のいずれかに記載のアクセス制御システム

【請求項6】

アクセスについての要求を許すべきかどうかを判断するためのアクセスポリシーメタデータを格納するように構成されたアクセスポリシーリポジトリと、
前記アクセスポリシーメタデータによって特定された基準を前記第１の標準化されたアクセス要求が満たしていないという判断に応じて、前記アクセスポリシーメタデータに関連付けられた情報を含む第１の要求エンティティへの応答を生成するように構成された、第２の機能的コンポーネントとをさらに含む、請求項１〜５のいずれかに記載のアクセス制御システム。

【請求項7】

前記入出力部はさらに、第２の要求エンティティから第２のアクセス要求を受信するように構成されており、
前記サービス制御部はさらに、前記第２のアクセス要求に関連付けられた第２の要求タイプを判断するように構成されており、
前記標準化部はさらに、前記第２の標準化されたアクセス要求を生成するように構成されており、
前記コンポーネント制御エンジンはさらに、前記第２の標準化されたアクセス要求と前記第２の要求タイプに関連付けられたアクセスメタデータオブジェクトとに少なくとも部分的に基づいて、前記第２の標準化されたアクセス要求の少なくとも一部を満たすように、前記第１の機能的コンポーネントを選択するように構成されており、
前記標準化部はさらに、前記第２の標準化されたアクセス要求の少なくとも一部を前記第１の機能的コンポーネントに提供するように構成されており、
前記コンポーネント制御エンジンはさらに、前記第２のアクセス要求に関連付けられた前記第２の要求タイプに適合する第２の応答の少なくとも一部を、前記第１の機能的コンポーネントに生成させるように構成されており、
前記サービス制御部はさらに、前記第１の応答の少なくとも一部を前記第１の要求エンティティに提供するように構成されている、請求項１〜６のいずれかに記載のアクセス制御システム。

【請求項8】

アクセス制御方法であって、
アクセスメタデータオブジェクトのアクセスメタデータリポジトリを保持するステップを含み、アクセスメタデータリポジトリにおける複数のアクセスメタデータオブジェクトの各アクセスメタデータオブジェクトは、アクセスサービスに関連付けられたデータを記述しており、前記アクセス制御方法はさらに、
第１の要求エンティティから第１のアクセス要求を受信するステップと、
前記第１のアクセス要求に関連付けられた第１の要求タイプを判断するステップと、
前記第１のアクセス要求が準拠するプロトコルによってのみ必要とされる情報のすべてを前記第１のアクセス要求から除外した第１の標準化されたアクセス要求を生成するステップと、
（ａ）前記第１の要求タイプに関連付けられた前記アクセスメタデータオブジェクト内に含まれ、かつ（ｂ）コンポーネント制御エンジンからの前記第１の標準化されたアクセス要求への応答に含まれるべき詳細を記述している特定のメタデータを、前記コンポーネント制御エンジンに送信するステップと、
前記第１の標準化されたアクセス要求と前記第１の要求タイプに関連付けられたアクセスメタデータオブジェクトとに少なくとも部分的に基づいて、前記第１の標準化されたアクセス要求の少なくとも一部を満たすように、第１の機能的コンポーネントを選択するステップとを含み、
前記方法は、１つ以上のコンピューティング装置によって行なわれる、アクセス制御方法。

【請求項9】

アクセス制御を行なうためのシステムであって、
アクセスメタデータオブジェクトのアクセスメタデータリポジトリを保持するための手段を含み、アクセスメタデータリポジトリにおける複数のアクセスメタデータオブジェクトの各アクセスメタデータオブジェクトは、アクセスサービスに関連付けられたデータを記述しており、前記システムはさらに、
第１の要求エンティティから第１のアクセス要求を受信するための手段と、
前記第１のアクセス要求に関連付けられた第１の要求タイプを判断するための手段と、
前記第１のアクセス要求が準拠するプロトコルによってのみ必要とされる情報のすべてを前記第１のアクセス要求から除外した第１の標準化されたアクセス要求を生成するための手段と、
（ａ）前記第１の要求タイプに関連付けられた前記アクセスメタデータオブジェクト内に含まれ、かつ（ｂ）コンポーネント制御エンジンからの前記第１の標準化されたアクセス要求への応答に含まれるべき詳細を記述している特定のメタデータを、前記コンポーネント制御エンジンに送信するための手段と、
前記第１の標準化されたアクセス要求と前記第１の要求タイプに関連付けられたアクセスメタデータオブジェクトとに少なくとも部分的に基づいて、前記第１の標準化されたアクセス要求の少なくとも一部を満たすように、第１の機能的コンポーネントを選択するための手段とを含む、システム。

【請求項10】

１つ以上のプロセッサによって実行可能な複数の命令を格納したコンピュータプログラムであって、複数の命令はプロセッサによって実行されると請求項８に記載の方法を行なう、コンピュータプログラム。

【請求項11】

システムであって、
アクセスメタデータオブジェクトを格納する記憶装置を含み、前記記憶装置における複数のアクセスメタデータオブジェクトの各アクセスメタデータオブジェクトは、アクセスサービスに対応するデータを記述しており、前記システムはさらに、
コンピューティング装置を含み、
前記コンピューティング装置は、
第１のクライアントから第１のアクセス要求を受信し、
前記第１のアクセス要求の第１の要求タイプを判断し、
前記第１のアクセス要求が準拠するプロトコルによってのみ必要とされる情報のすべてを前記第１のアクセス要求から除外した第１の標準化されたアクセス要求を生成し、
（ａ）前記第１の要求タイプに関連付けられた前記アクセスメタデータオブジェクト内に含まれ、かつ（ｂ）コンポーネント制御エンジンからの前記第１の標準化されたアクセス要求への応答に含まれるべき詳細を記述している特定のメタデータを、前記コンポーネント制御エンジンに送信し、
前記第１の標準化されたアクセス要求と、前記記憶装置に格納され前記第１の要求タイプに対応するアクセスメタデータオブジェクトとに少なくとも基づいて、前記第１の標準化されたアクセス要求の少なくとも一部を満たすように、第１の機能的コンポーネントを選択する、システム。

【請求項12】

コンピューティング装置によって、第１のクライアントから第１のアクセス要求を受信するステップと、
前記コンピューティング装置によって、前記第１のアクセス要求の第１の要求タイプを判断するステップと、
前記コンピューティング装置によって、前記第１のアクセス要求が準拠するプロトコルによってのみ必要とされる情報のすべてを前記第１のアクセス要求から除外した第１の標準化されたアクセス要求を生成するステップと、
（ａ）前記第１の要求タイプに関連付けられたアクセスメタデータオブジェクト内に含まれ、かつ（ｂ）コンポーネント制御エンジンからの前記第１の標準化されたアクセス要求への応答に含まれるべき詳細を記述している特定のメタデータを、前記コンピューティング装置によってコンポーネント制御エンジンに送信するステップと、
前記第１の標準化されたアクセス要求と、記憶装置に格納され前記第１の要求タイプに対応するアクセスメタデータオブジェクトとに少なくとも基づいて、前記コンピューティング装置によって、前記第１の標準化されたアクセス要求の少なくとも一部を満たすように、第１の機能的コンポーネントを選択するステップとを含み、
前記記憶装置における複数のアクセスメタデータオブジェクトの各アクセスメタデータオブジェクトは、アクセスサービスに対応するデータを記述している、方法。

【請求項13】

第１のクライアントから第１のアクセス要求を受信し、
前記第１のアクセス要求の第１の要求タイプを判断し、
前記第１のアクセス要求が準拠するプロトコルによってのみ必要とされる情報のすべてを前記第１のアクセス要求から除外した第１の標準化されたアクセス要求を生成し、
（ａ）前記第１の要求タイプに関連付けられたアクセスメタデータオブジェクト内に含まれ、かつ（ｂ）コンポーネント制御エンジンからの前記第１の標準化されたアクセス要求への応答に含まれるべき詳細を記述している特定のメタデータを、前記コンポーネント制御エンジンに送信し、
前記第１の標準化されたアクセス要求と、記憶装置に格納され前記第１の要求タイプに
対応するアクセスメタデータオブジェクトとに少なくとも基づいて、前記第１の標準化されたアクセス要求の少なくとも一部を満たすように、第１の機能的コンポーネントを選択することを、プロセッサに行なわせる、プログラムであって、
前記記憶装置における複数のアクセスメタデータオブジェクトの各アクセスメタデータオブジェクトは、アクセスサービスに対応するデータを記述している、プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

利益の主張
本願は、２０１１年５月１１日に出願された仮出願連続番号第６１／４８５，０２５号の利益を主張する。当該仮出願の内容全体は、米国特許法第１１９条（ｅ）により、ここに完全に述べられているかのように引用により援用される。

【0002】

発明の分野
本発明は一般に保護されたコンピューティングに関し、より一般的にはコンピューティングシステムのためのアクセス制御に関する。

【背景技術】

【0003】

背景
現在のビジネスは、ビジネス活動に欠かせない情報を制御し生成するさまざまなアプリケーションおよびシステムに依拠している。アプリケーションが異なれば、提供するサービスおよび情報も異なることが多く、ユーザが異なれば、各システムまたはアプリケーション内でアクセスを必要とする情報のレベルも異なるであろう。ユーザが許されるアクセスのレベルは、ユーザの役割に依存し得る。たとえば、マネージャは自分の部下である従業員についてのある情報へのアクセスを必要とする場合があるが、そのマネージャが自分の上司についての同じ情報にアクセスすることは不適切な場合がある。

【発明の概要】

【発明が解決しようとする課題】

【0004】

初期のそれほど性能が高くないアプリケーションは、アクセス制御ビジネスロジックをアプリケーションコードに直接取入れていた。すなわち、各アプリケーションは、ユーザらが、たとえば個別のアカウント、個別のポリシーロジック、および個別の許可を有することを必要としたであろう。また、これらのアプリケーションのうちの１つによってあるユーザが認証された場合、第１のアプリケーションでの認証が生じたという事実が共有されないため、この認証は、企業における他のアプリケーションには知らされないままである。このため、認証のために異なるシステムを使用するアプリケーションとアクセス制御との間には、信頼という概念はない。技術者らは、企業においてアプリケーション毎にアクセス制御システムを有することは、車毎にガソリンスタンドを有するようなものであることにすぐ気付き、認証およびアクセス制御は共有リソースとしてより効率的に実現され管理されるであろうと判断した。これらの共有リソースは、アクセス制御システムとして知られるようになった。

【0005】

アクセス制御システムは、ある特定のリソースにある特定のアクセス要求を許すべきかどうかについて判断を下すために、ポリシーおよび他のビジネスロジックを使用することが多い。アクセスを許すべきであるという判断が下されると、要求者にはトークンが提供される。このトークンは、秘密データを防護するドアを開けるために使用できる鍵のようなものである。たとえば、あるユーザは、給与情報といったある従業員らについての情報を収集するために、人事データベースにアクセスしようとするかもしれない。そのユーザのウェブブラウザはアプリケーションに要求を行ない、それは認証を必要とする。ウェブブラウザがトークンを有していない場合、ユーザは、アクセス制御システムにログインするよう求められる。ユーザが認証されると、ユーザのブラウザは、人事アプリケーションにアクセスするために使用され得るトークンを表わすクッキーを受信する。

【0006】

アクセス制御システムの普及を促進するために、そのようなシステムの開発者らは、あるアプリケーションの代わりにアクセス制御システムと情報をやりとりすることが可能なエージェントをアプリケーション開発者らが容易に作成することができるように、エージェント開発キットを作り出した。これらのエージェントはアプリケーション側で必要とされるロジックを表わしており、アプリケーションがこれらのエージェントと統合し、これらのエージェントを使用するために必要とするコードは、アクセス制御ロジックをアプリケーションに直接含めるために必要とするであろうコードよりも少ない。しかしながら、エージェントは、エージェントツールキットが開発されたアクセス制御システムに固有のものである。したがって、企業の設計者または技術者がある特定のアプリケーションによって使用されるアクセス制御システムを変更したい場合、そのアプリケーションに関連付けられたエージェントも、新しいアクセス制御システムの要件に準拠するよう置き換えられなければならない。また、アクセス制御システムは異なる特徴を有する場合があり、そのため、エージェントが互換性のあるものであったとしても、あるアクセスマネージャは、企業におけるアプリケーションによって要求されるサービスを提供しないであろう。これはすべて、アクセス制御システムを「粘着性のあるもの」にする。つまり、あるアクセス制御システムへの依存から別のものへとアプリケーションを切換えることは、非常に難しく、またはコスト効率が悪い。

【0007】

アクセス制御システムの粘着性のために、多くの企業は、複数のアクセス制御システムを使用しているか、または企業が既に採用しているアクセス制御システムと容易に統合されるアプリケーションを使用している。アプリケーションはこのため「サイロ」（silo）へと編成され、アプリケーションの多くは、それらと互換性がないアクセス制御システムによって提供されるサービスを活用することができない。そのような企業では、アクセス制御システム毎に統合を行なわなければならないため、新しいアクセス制御機能を展開することが難しくなる。加えて、同じアクセス制御システムを使用するアプリケーション間の区別がユーザにはわかりにくいため、普遍的統合の欠落によってユーザらが困惑することがしばしばある。

【0008】

アプリケーションがすべて、同じアクセス制御システムを使用している場合、企業の設計者らは、既存のアクセス制御システムを維持したいという願望から、アプリケーションの選択を制限されることがしばしばある。したがって、ある特定のアプリケーションが秀でた機能を提供する場合でも、設計者は、一貫性を維持するために秀でた機能を犠牲にして、企業内で既に配備されているアクセス制御システムと既に互換性があるかまたは容易に統合される別のアプリケーションを選択することが多いであろう。

【0009】

現在のアクセス制御ソリューションはいくつかの課題に直面しており、既存の製品は、出現しつつある企業およびインターネットアクセス制御要件を途切れなくサポートするように発展するよう、圧力を受けている。この発展は、製品が出現しつつある要件に対応するよう拡張するのに実用的でない設計を使用するため、問題である。その結果、新機能の追加は、破壊的で時間がかかる統合および実現プロセスを提起するより新しい製品コンポーネントを介して達成されることが多い。

【0010】

企業リソースを保護し、企業ユーザによるこれらのリソースへのアクセスを可能にすることに関しては、会社は、自らの要望に最もよく合うプロトコル規格および実現モデルについて自らのソリューションを選択し標準化する自由を有している。しかしながら、エクストラネットに関しては、さまざまなレベルの信頼を表わすユーザコミュニティ（ビジネスパートナーコミュニティ、企業顧客、およびインターネットでの一般消費者など）ならびに関連付けられた情報やりとりモデルの拡大する基盤を受入れ、引きつけるというビジネス動機がある。

【0011】

企業は、異なる管理モデルおよび問題領域にまたがるさまざまなタイプのリソースを保護する必要がある。一方、企業におけるユーザらは、多くのそのような領域を越えてリソースにアクセスする必要がしばしばある。

【0012】

ＳＯＸまたはＭ＆Ａ活動などの規制順守の取組みによって推進されて、企業アクセス制御のユーザらは、アクセス制御および制御が一貫した態様ですべてのＩＴアセット（assets）に適用され得るように、機能的な製品サイロを、さまざまなレガシースタックを一本化するプロセス指向環境へと遷移する必要がある。しかしながら、一貫した一本化アーキテクチャおよび移行フレームワークの欠如はしばしば、克服できない実現課題を提起する。

【0013】

アクセス制御のベンダーらは従来、特定の問題領域に特化された個々の製品を用いて上述の課題に対処してきた。アクセス制御ソリューションの共通要素、すなわち、アサーション（assertions）を符号化するために使用されるトークンのタイプ、関与する当事者間の信頼モデル、およびワイヤプロトコル規格はすべて、本質的に独立した問題である。しかしながら、伝統的な製品は、これらの要素間に緊密な結合を作り出す傾向がある。

【0014】

図１は、異なる環境に適合された異なる製品の一例を示しており、各々、その製品が対象とする環境に典型的な特定の結合を表わしている。上述の緊密な結合のため、異種問題領域に対処するために複数の個々の製品を貼り付けあう必要がある。この貼り付け／橋渡しは、セキュリティ姿勢全体において最も弱い連結に終わってしまう。なぜなら、橋渡しされる個々の製品は、それらのセキュリティモデルおよび設計パターンの点で互換性がないためである。

【0015】

これらの独立した製品はまた、独立した技術スタックに基づいている場合が多く、このため、顧客のために統合されたソリューションを配備するという課題を複雑にしている。

【図面の簡単な説明】

【0016】

【図1】異なる環境に適合された異なる製品の一例を示す図である。

【図2】本発明の一実施例に従ったアクセス制御モデルを示す図である。

【図3】本発明の一実施例に従ったアクセス制御アーキテクチャを示す図である。

【図4】本発明の一実施例に従った、異なるアクセス制御ソリューションが階層化を通して継ぎ目のない態様で作成されまたは組立てられることを可能にするアクセス制御アーキテクチャを示す図である。

【図5】階層化アプローチを用いたアクセス制御アーキテクチャのより一般的な図である。

【図6】一実施例が実現され得るアクセス制御システムを示す簡略化されたブロック図である。

【図7】一実施例が実現され得るアクセス制御システムの機能を示すフローチャートである。

【図8】一実施例が実現され得るアクセス制御システムの機能を示すフローチャートである。

【図9】アクセス制御製品に適用可能な移行パターンの一例を示す図である。

【図10】アクセス制御製品に適用可能な移行パターンの一例を示す図である。

【図11】本発明の一実施例に従って使用され得るシステム環境の物理的コンポーネントを示す簡略化されたブロック図である。

【図12】本発明の一実施例を現実化するために使用され得るコンピュータシステムの簡略化されたブロック図である。

【発明を実施するための形態】

【0017】

発明の詳細な説明
以下の説明では、説明の目的で、本発明の実施例の完全な理解を提供するために特定の詳細が述べられている。しかしながら、これらの特定の詳細がなくても本発明が現実化され得ることは明らかであろう。

【0018】

全体の概要
本発明の一実施例によれば、上述の課題に対処可能なアクセス制御アーキテクチャが提供される。一実施例では、異なる問題領域に対する独立したソリューションサイロの代わりに、アーキテクチャはモジュール式で分離型のコンポーネントを含んでおり、異種ソリューションの組立可能性を可能にする。特に、アーキテクチャは、異種プログラミング言語により実現された技術スタックの組立を可能にする。

【0019】

一実施例では、ここに説明されるアクセス制御アーキテクチャは、出現しつつある技術および途切れなく対応する関連する新しいプロトコルが発展するにつれて、それらに対するサポートを可能にする。一実施例では、顧客の配備環境に適合可能な複合および異種ソリューションが可能とされる。さまざまな信頼モデルに対応し、異なるコミュニティ用のモデルを同時にかつ途切れなく供給しつつ、異なるワイヤプロトコルを同時にサポートするアクセス制御ソリューションを、ここに説明する。

【0020】

一実施例では、ここに説明されるアクセス制御アーキテクチャは、１つの組織のすべてのデータおよびアセットにまたがることができる統合された企業間アクセス制御を可能にする。一実施例では、企業全体にわたってセキュリティのリスクをより良好に管理する統合された企業間アクセス制御ソリューションが提供される。一実施例では、レガシー技術の系統立った移行、および移行期間中のレガシーおよび新技術の一本化された制御が可能とされ得る。

【0021】

一実施例では、アクセスメタデータリポジトリが、アクセスサービスに関連付けられたデータを記述するアクセスメタデータオブジェクトのリポジトリを保持する。要求エンティティからアクセス要求が受信され、そのアクセス要求に関連付けられた要求タイプが判断される。標準化された要求が生成され、標準化されたアクセス要求と要求タイプに関連付けられたアクセスメタデータオブジェクトとに部分的に基づいて、第１の標準化されたアクセス要求の少なくとも一部を満たすように、第１の機能的コンポーネントが選択される。一実施例では、第１の機能的コンポーネントは応答の少なくとも一部を生成し、それは要求エンティティに提供される。一実施例では、応答は、要求エンティティに提供される前に、プロトコル固有応答へと変換される。一実施例では、コンピュータ読取可能な不揮発性記憶媒体は、コンピュータシステムの１つ以上のコンピュータにロードされると、以下に説明される方法をシステムに実行させるコードセグメントを含んでいる。一実施例では、アクセス制御システムは、アクセスメタデータオブジェクトのアクセスメタデータリポジトリを含み、アクセスメタデータリポジトリにおける複数のアクセスメタデータオブジェクトの各アクセスメタデータオブジェクトは、アクセスサービスに関連付けられたデータを記述しており、アクセス制御システムはさらに、第１の要求エンティティから第１のアクセス要求を受信するように構成された入出力部と、第１のアクセス要求に関連付けられた第１の要求タイプを判断するように構成されたサービス制御部と、第１の標準化されたアクセス要求を生成するように構成された標準化部と、第１の標準化されたアクセス要求と第１の要求タイプに関連付けられたアクセスメタデータオブジェクトとに少なくとも部分的に基づいて、第１の標準化されたアクセス要求の少なくとも一部を満たすように、第１の機能的コンポーネントを選択するように構成されたコンポーネント制御エンジンとを含み、アクセスメタデータリポジトリ、入出力部、サービス制御部、標準化部、およびコンポーネント制御エンジンは、１つ以上のコンピューティング装置上で実現される。一実施例では、コンポーネント制御エンジンはさらに、第１の標準化されたアクセス要求の少なくとも一部を第１の機能的コンポーネントに提供するように構成されており、コンポーネント制御エンジンはさらに、第１のアクセス要求に関連付けられた第１の要求タイプに適合する第１の応答の少なくとも一部を、第１の機能的コンポーネントに生成させるように構成されており、サービス制御部はさらに、第１の応答の少なくとも一部を第１の要求エンティティに提供するように構成されている。一実施例では、第１の要求エンティティは、信頼されるアプリケーションである第１のアプリケーションであり、第１のアクセス要求は、第２のアプリケーションに関連付けられたセキュリティトークンについての要求を含んでおり、応答の少なくとも一部を生成することは、第１のアプリケーションのユーザの代わりに第２のアプリケーションに関連付けられた変更を行なうことを第１のアプリケーションに承認する第１のトークンを生成することを含む。一実施例では、入出力部はさらに、第２の要求エンティティから第２のアクセス要求を受信するように構成されており、第２のアクセス要求は、アイデンティティプロバイダに関連付けられたセキュリティトークンについての要求を含んでおり、標準化部はさらに、第２の標準化されたアクセス要求を生成するように構成されており、コンポーネント制御エンジンはさらに、第３のアプリケーションへのアクセスを承認する第２のトークンを、第１の機能的コンポーネントに生成させるように構成されており、第１の機能的コンポーネントは、第１の標準化された要求の少なくとも一部を受信することに応じて第１のトークンを生成するように構成されており、第１の機能的コンポーネントは、第２の標準化された要求の少なくとも一部を受信することに応じて第２のトークンを生成するように構成されている。一実施例では、要求は、第１の機能的コンポーネントに関連付けられた状態と第２の機能的コンポーネントに関連付けられた状態とを識別する複合状態情報を含む。一実施例では、システムはさらに、アクセスについての要求を許すべきかどうかを判断するためのアクセスポリシーメタデータを格納するように構成されたアクセスポリシーリポジトリと、アクセスポリシーメタデータによって特定された基準を第１の標準化されたアクセス要求が満たしていないという判断に応じて、アクセスポリシーメタデータに関連付けられた情報を含む第１の要求エンティティへの応答を生成するように構成された、第２の機能的コンポーネントとを含む。一実施例では、入出力部はさらに、第２の要求エンティティから第２のアクセス要求を受信するように構成されており、サービス制御部はさらに、第２のアクセス要求に関連付けられた第２の要求タイプを判断するように構成されており、標準化部はさらに、第２の標準化されたアクセス要求を生成するように構成されており、コンポーネント制御エンジンはさらに、第２の標準化されたアクセス要求と第２の要求タイプに関連付けられたアクセスメタデータオブジェクトとに少なくとも部分的に基づいて、第２の標準化されたアクセス要求の少なくとも一部を満たすように、第１の機能的コンポーネントを選択するように構成されており、標準化部はさらに、第２の標準化されたアクセス要求の少なくとも一部を第１の機能的コンポーネントに提供するように構成されており、コンポーネント制御エンジンはさらに、第２のアクセス要求に関連付けられた第２の要求タイプに適合する第２の応答の少なくとも一部を、第１の機能的コンポーネントに生成させるように構成されており、サービス制御部はさらに、第１の応答の少なくとも一部を第１の要求エンティティに提供するように構成されている。一実施例では、アクセス制御方法は、アクセスメタデータオブジェクトのアクセスメタデータリポジトリを保持するステップを含み、アクセスメタデータリポジトリにおける複数のアクセスメタデータオブジェクトの各アクセスメタデータオブジェクトは、アクセスサービスに関連付けられたデータを記述しており、アクセス制御方法はさらに、第１の要求エンティティから第１のアクセス要求を受信するステップと、第１のアクセス要求に関連付けられた第１の要求タイプを判断するステップと、第１の標準化されたアクセス要求を生成するステップと、第１の標準化されたアクセス要求と第１の要求タイプに関連付けられたアクセスメタデータオブジェクトとに少なくとも部分的に基づいて、第１の標準化されたアクセス要求の少なくとも一部を満たすように、第１の機能的コンポーネントを選択するステップとを含み、前記方法は、１つ以上のコンピューティング装置によって行なわれる。一実施例では、前記方法はさらに、第１の標準化されたアクセス要求の少なくとも一部を第１の機能的コンポーネントに提供するステップと、第１の機能的コンポーネントを用いて第１の応答の少なくとも一部を生成するステップとを含み、第１の応答は、第１のアクセス要求に関連付けられた第１の要求タイプに適合しており、前記方法はさらに、第１の応答の少なくとも一部を第１の要求エンティティに提供するステップを含む。一実施例では、第１の要求エンティティは、信頼されるアプリケーションである第１のアプリケーションであり、第１のアクセス要求は、第２のアプリケーションに関連付けられたセキュリティトークンについての要求を含んでおり、応答の少なくとも一部を生成するステップは、第１のアプリケーションのユーザの代わりに第２のアプリケーションに関連付けられた変更を行なうことを第１のアプリケーションに承認する第１のトークンを生成するステップを含む。一実施例では、前記方法はさらに、第２の要求エンティティから第２のアクセス要求を受信するステップを含み、第２のアクセス要求は、アイデンティティプロバイダに関連付けられたセキュリティトークンについての要求を含んでおり、前記方法はさらに、第２の標準化されたアクセス要求を生成するステップと、第３のアプリケーションへのアクセスを承認する第２のトークンを生成するステップとを含み、第１のトークンは、第１の標準化された要求の少なくとも一部をトークン生成エンジンで受信することに応じて、トークン生成エンジンによって生成され、第２のトークンは、第２の標準化された要求の少なくとも一部をトークン生成エンジンで受信することに応じて、トークン生成エンジンによって生成される。一実施例では、要求は、第１の機能的コンポーネントに関連付けられた状態と第２の機能的コンポーネントに関連付けられた状態とを識別する複合状態情報を含む。一実施例では、前記方法はさらに、アクセスについての要求を許すべきかどうかを判断するためのアクセスポリシーメタデータを格納するアクセスポリシーリポジトリを保持するステップと、アクセスポリシーメタデータによって特定された基準を第１の標準化されたアクセス要求が満たしていないという判断に応じて、アクセスポリシーメタデータに関連付けられた情報を含む第１の要求エンティティへの応答を生成するステップとを含む。一実施例では、前記方法はさらに、第２の要求エンティティから第２のアクセス要求を受信するステップと、第２のアクセス要求に関連付けられた第２の要求タイプを判断するステップと、第２の標準化されたアクセス要求を生成するステップと、第２の標準化されたアクセス要求と第２の要求タイプに関連付けられたアクセスメタデータオブジェクトとに少なくとも部分的に基づいて、第２の標準化されたアクセス要求の少なくとも一部を満たすように、第１の機能的コンポーネントを選択するステップと、第２の標準化されたアクセス要求の少なくとも一部を第１の機能的コンポーネントに提供するステップと、第１の機能的コンポーネントを用いて第２の応答の少なくとも一部を生成するステップとを含み、第２の応答は、第２のアクセス要求に関連付けられた第２の要求タイプに適合しており、前記方法はさらに、第１の応答の少なくとも一部を第１の要求エンティティに提供するステップを含む。一実施例では、アクセス制御を行なうためのシステムは、アクセスメタデータオブジェクトのアクセスメタデータリポジトリを保持するための手段を含み、アクセスメタデータリポジトリにおける複数のアクセスメタデータオブジェクトの各アクセスメタデータオブジェクトは、アクセスサービスに関連付けられたデータを記述しており、前記システムはさらに、第１の要求エンティティから第１のアクセス要求を受信するための手段と、第１のアクセス要求に関連付けられた第１の要求タイプを判断するための手段と、第１の標準化されたアクセス要求を生成するための手段と、第１の標準化されたアクセス要求と第１の要求タイプに関連付けられたアクセスメタデータオブジェクトとに少なくとも部分的に基づいて、第１の標準化されたアクセス要求の少なくとも一部を満たすように、第１の機能的コンポーネントを選択するための手段とを含む。一実施例では、前記システムはさらに、第１の標準化されたアクセス要求の少なくとも一部を第１の機能的コンポーネントに提供するための手段と、第１の機能的コンポーネントを用いて第１の応答の少なくとも一部を生成するための手段とを含み、第１の応答は、第１のアクセス要求に関連付けられた第１の要求タイプに適合しており、前記システムはさらに、第１の応答の少なくとも一部を第１の要求エンティティに提供するための手段を含む。一実施例では、第１の要求エンティティは、信頼されるアプリケーションである第１のアプリケーションであり、第１のアクセス要求は、第２のアプリケーションに関連付けられたセキュリティトークンについての要求を含んでおり、応答の少なくとも一部を生成するための手段は、第１のアプリケーションのユーザの代わりに第２のアプリケーションに関連付けられた変更を行なうことを第１のアプリケーションに承認する第１のトークンを生成するための手段を含む。一実施例では、
前記システムはさらに、第２の要求エンティティから第２のアクセス要求を受信するための手段を含み、第２のアクセス要求は、アイデンティティプロバイダに関連付けられたセキュリティトークンについての要求を含んでおり、前記システムはさらに、第２の標準化されたアクセス要求を生成するための手段と、第３のアプリケーションへのアクセスを承認する第２のトークンを生成するための手段とを含み、第１のトークンは、第１の標準化された要求の少なくとも一部をトークン生成エンジンで受信することに応じて、トークン生成エンジンによって生成され、第２のトークンは、第２の標準化された要求の少なくとも一部をトークン生成エンジンで受信することに応じて、トークン生成エンジンによって生成される。一実施例では、要求は、第１の機能的コンポーネントに関連付けられた状態と第２の機能的コンポーネントに関連付けられた状態とを識別する複合状態情報を含む。一実施例では、前記システムはさらに、アクセスについての要求を許すべきかどうかを判断するためのアクセスポリシーメタデータを格納するアクセスポリシーリポジトリを保持するための手段と、アクセスポリシーメタデータによって特定された基準を第１の標準化されたアクセス要求が満たしていないという判断に応じて、アクセスポリシーメタデータに関連付けられた情報を含む第１の要求エンティティへの応答を生成するための手段とを含む。一実施例では、前記システムはさらに、第２の要求エンティティから第２のアクセス要求を受信するための手段と、第２のアクセス要求に関連付けられた第２の要求タイプを判断するための手段と、第２の標準化されたアクセス要求を生成するための手段と、第２の標準化されたアクセス要求と第２の要求タイプに関連付けられたアクセスメタデータオブジェクトとに少なくとも部分的に基づいて、第２の標準化されたアクセス要求の少なくとも一部を満たすように、第１の機能的コンポーネントを選択するための手段と、第２の標準化されたアクセス要求の少なくとも一部を第１の機能的コンポーネントに提供するための手段と、第１の機能的コンポーネントを用いて第２の応答の少なくとも一部を生成するための手段とを含み、第２の応答は、第２のアクセス要求に関連付けられた第２の要求タイプに適合しており、前記システムはさらに、第１の応答の少なくとも一部を第１の要求エンティティに提供するための手段を含む。

【0022】

階層化されたアクセス制御アーキテクチャ
図２は、本発明の一実施例に従ったアクセス制御モデルを示す。図２に示すアーキテクチャは、各層が構築ブロックのカテゴリを含む、一意的な多層アーキテクチャを示す。図２に示す実施例では、構築ブロックは、アイデンティティソリューション２１０と、プロトコルファサード２２０と、トークンハンドリングエンジン２３０と、信頼モデル２４０と、共有サービス２５０とを含む。

【0023】

一実施例では、階層化モデルは上述の構築ブロックに基づいている。これらの構築ブロックを使用する層間でメッセージのオーケストレーションを行なう（orchestrate）ために、オーケストレーション（orchestration）コントローラコンポーネントが使用されて、特定のコンポーネント間のハードコードされた通信ではなく、層間の通信が、層間の要望に従って層間で利用可能な通信能力に適合するようにする。これは、新しい能力および複合ソリューションの系統立った開発を容易にするのに役立つ。

【0024】

一実施例では、プロトコルにより定義されたエンティティとそれらの対応する正準表現にマッピングする正準の実世界の物理的エンティティとの単一セットを表わす拡張可能な基盤が可能とされてもよい。たとえば、一実施例で説明される多層アクセスモデルを用いて、外部ポリシーエンジンをアクセス制御システムの共有サービス層に通信可能に結合してもよく、それにより、アクセスモデルによって提供されるあらゆるサービスの機能性が拡張される。この能力は、同じ物理的エンティティ（サービス、アプリケーションクライアント、またはユーザなど）が、問題領域およびプロトコルにまたがる複合ソリューションの一部となることを可能にする。

【0025】

一実施例では、広範囲の顧客配備環境を可能とすることを目的として、共有可能な機能的コンポーネントを識別しパッケージ化するためのパターンが、異なるフォームファクタ（組込、配布など）で配備可能である。加えて、いくつかの実施例では、レガシーから新技術への漸進的移行を可能にしつつ、レガシー技術の共存および統合制御を容易にすることを目的とする、同じ組立可能アーキテクチャを利用する一組の専用サービスファサードが、特徴付けられてもよい。

【0026】

一実施例では、多層アクセス制御システムは、情報ライフサイクルから情報タイプを切離すインフラストラクチャを利用して、外面化（externalize）すべきアクセス制御全体にわたる制御と施行との外面化および共有、ひいてはポリシー決定およびセッションインフラストラクチャの切離し／外面化を可能にする。この設計要素は、問題領域および管理境界（企業リソース用のウェブシングルサインオン（Web Single Sign On：ＳＳＯ）、パートナー用のＩＤ連合（federation）、ＩＤ伝搬およびウェブサービスへの委任されたアクセスなど）間のポリシーの一貫した制御および施行を容易にする。

【0027】

現在のアクセス制御製品は、図１に示すような「サイロ」アプローチに基づいている。図１を参照すると、サイロＡ１１０、サイロＢ１２０、サイロＣ１３０、およびサイロＤ１４０はすべて、変更されないかもしれない静的な要素のセットを含む。たとえば、顧客ポータルアプリケーションは、単にＯｐｅｎＩＤを用いて認証するアクセス制御ソリューションを使用するかもしれず、サイロＤ１４０以外のサイロの機能性を利用しないかもしれない。図１に示すアプローチでは、各製品は本質的に島である。その結果、さまざまなサイロ間で一貫した態様でセキュリティを定義し、管理し、施行することは、ほぼ不可能である。この断片化は企業のセキュリティの鎧における割れ目を露出させ、インターネットの使用の増加は企業のＩＴアセットが含まれる可能性を著しく増加させている。上述の問題を解決するために、必要なことは、機能的サイロから組立可能ユニットへの製品の遷移である。これは、出現しつつある規格に基づいた幅広い異種ソリューションを同時に供給しながら既存のソリューションに対して遷移を段階的に容易にする新しいアーキテクチャを通して実現される。

【0028】

図３は、本発明の一実施例に従ったアクセス制御アーキテクチャを示す。図３に示す実施例は、マルチプロトコル複合サーバアーキテクチャを提供する。一実施例では、構築ブロックは階層化モデルとともに使用され、製品および複合ソリューションがどの特定の言語、プラットフォームまたは技術からも独立した態様で機能することを可能にする。

【0029】

一実施例では、図３に示す機能的階層化は、コードの再使用を確実にしつつ、任意の既存のアクセス制御（ＡＣ）製品（既存および将来）の組立を可能にする。プロトコル結合３１０は、認証プロトコルメッセージを標準メッセージングおよびトランスポートプロトコルにマッピングするロジックを表わす。プロトコル結合３１０は、プロトコル応答および要求をそれぞれ変換し復元することを担当する。コントローラ３２０は、機能的コンポーネントを呼出すことによってプロトコル要求を満たすために必要とされるコアビジネスロジックオーケストレーションを表わす。アクセス用共有サービス（Shared services for access：ＳＳＡ）３３０は、あらゆるＡＭ製品によって使用されることが意図されている共有サーバ機能性を表わす。それは、高レベルのステートフルエンジン（基盤コンポーネント）および低レベルのステートレスエンジン（基盤ＡＰＩ）から構成される。制御はプロトコル結合層３１０からコントローラ３２０、ＳＳＡ層３３０へと通される。

【0030】

一実施例では、共有可能な機能性の識別およびパッケージ化のためのパターンにより、この機能性は、幅広い範囲のソリューションをサポートするために異なるフォームファクタで利用可能となるようになる。アーキテクチャは、インターフェイス、層間の階層化、および層を実現するエンティティ／モジュールに重点を置いている。各層は、より低い層がその上の層による使用のための機能を提供する、特定の機能性のセットを提供している。一実施例では、この階層化アプローチは、（たとえば図４に示すような）複合ソリューションを構築するために、パッケージ化フォームファクタとは独立した機能性の組立を可能にする。

【0031】

実施例は、さまざまな層における異なるエンティティ／モジュールが（たとえば図４に示すような）組立を経るようにすることによって、異なる製品の構築を容易にする。その結果、新しい機能／機能性および管理可能性が漸進的に導入され得る。

【0032】

図４は、さまざまなソリューション４１０と、パッケージ化された製品４２０と、スタンドアロンエンティティ４３０と、シングルサインオン認証（single sign-on authentication：ＳＳＡ）４４０と、他のプラットフォームＡＰＩ、コネクタ、およびプラグイン４５０とを含むアーキテクチャを含む。この例示は、アクセス制御への「サイロ」アプローチではなく階層化アプローチによって提供されるフレキシビリティの一例を提供する。

【0033】

図５は、階層化アプローチを用いたアクセス制御アーキテクチャのより一般的な図を示す。一実施例では、アクセス制御アーキテクチャのコンポーネントは、サービスエンティティ５１０と、プロトコル結合５２０と、コントローラ５３０と、統合された機能的コンポーネント５４０と、ＡＰＩを有する機能的コンポーネント５５０という５種類のエンティティを含む。

【0034】

サービスエンティティ５１０は、スタンドアロンのソフトウェアコンポーネントとしてともにパッケージ化された機能的エンティティのセットを表わす。サービスエンティティは、顧客によって管理運営され得る。

【0035】

プロトコル結合層５２０は、認証プロトコルメッセージを標準メッセージングおよびトランスポートプロトコルにマッピングするロジックを表わす。プロトコル結合は、プロトコル応答および要求を変換し復元することを担当する。

【0036】

一実施例では、プロトコル結合は、セキュリティ処理と、バイトのワイヤ順序付けに依存するワイヤデータ最適化（たとえば、ＭＴＯＭ）とを行なうかもしれず、プロトコル要求／応答の意味処理を何ら行なわない。プロトコル結合層５２０は、下位に位置するプラットフォームによって提供されるトランスポートおよびメッセージプロトコル結合機能を活用しており、ハンドラ、インターセプタ、プラグイン、およびライブラリＡＰＩといったプログラミング構造体において実現化されてもよい。

【0037】

コントローラ５３０は、機能的コンポーネントを呼出すことによってプロトコル要求を満たすために必要とされるコアビジネスロジックオーケストレーションを表わす。一実施例では、コントローラ層５３０はプロトコル結合層から切離されており、トランスポート結合に依存しない。コントローラ層は、機能的コンポーネント（エンジン）および基盤ＡＰＩを呼出すことによって要求を処理するロジックを含む。一実施例では、機能的コンポーネントが、それらの個々の機能を行なうのに不必要な詳細に気付かないままでいられるように、製品に固有のビジネスロジックがコントローラ層５３０で分離されている。このため、一実施例では、コントローラ層５３０から機能的コンポーネント層５４０および５５０に通されたメッセージは、各機能的コンポーネントによって必要とされる情報のみを含むよう標準化される。このため、さまざまなアクセス制御コンポーネント間でのモジュール方式およびコード再使用を促進するために、製品独立／一般ロジックが、エンジン／基盤ＡＰＩへと押し進められる。

【0038】

機能的コンポーネントは、明確に定義された機能性のユニットを表わす。各機能的コンポーネントは、他の機能的コンポーネントに緊密に結合され、他の機能的コンポーネントからロジック的に分離している。一実施例では、コンポーネント間の通信は、パブリックインターフェイスを介してのみ可能とされる。機能的コンポーネントは、ユーザに見え、かつサービスエンティティ層５１０におけるより大きいサービスエンティティの一部としての他の機能的エンティティとともに使用されるよう意図された、関連付けられた構成を有する。モジュール方式および並列開発を容易にするために、１つのコンポーネントが複数のサブコンポーネントに分解されてもよい。統合された機能的コンポーネント５４０およびＡＰＩを有する機能的コンポーネント５５０は、システムへの統合のレベルが異なっている。たとえば、統合された機能的コンポーネントは、アクセス制御システムの機能性を拡張するために、別の機能的コンポーネントに関連付けられたＡＰＩにアクセスしてもよい。これは、階層化されたアクセス制御アーキテクチャの拡張可能な性質を示す。以下の「エンジン」は、一実施例において実現され得る機能的エンティティの例を表わす。

【0039】

認証エンジン：認証エンジンは、特定の認証プロトコルを用いてユーザの信用証明を収集し検証することによってユーザのアイデンティティを確立することを担当する。ユーザはコントローラ（ビュー）と情報をやりとりし、それは認証エンジンに認証ロジック（モデル＋コントローラ）を委任する。信用証明収集のためのユーザとのやりとりは、コントローラ、エージェント、およびインターセプタなどのプロトコル／ウェブ／提示階層コンポーネントによって行なわれる。

【0040】

認証エンジンは、さまざまな認証スキームをさまざまな組合せで適用し、認証モデル（それらのモデルによって必要とされるポリシーおよび制御フラグを含む）をサポートし、技術、規則、およびプロトコルを含む認証プロセスの全局面をカスタマイズして拡張し、信用証明収集を推進するためにエージェント階層と情報をやりとりするために必要なすべての機能を含む。

【0041】

承認エンジン：承認エンジンは、特定の認証プロトコルを用いて請求者のアイデンティティを確立するプロセスを担当する。信用証明収集のために、ユーザとのやりとりが、ＮＧ−ＡＭコントローラ、エージェント、およびインターセプタなどのプロトコル／ウェブ／提示階層コンポーネントによって行なわれる。

【0042】

一実施例では、承認エンジンは、さまざまな認証スキームをさまざまな組合せで適用し、ポリシーおよび制御フラグを含むＪＡＡＳ認証モデルをサポートし、技術、規則、およびプロトコルを含む認証プロセスの全局面をカスタマイズして拡張し、信用証明収集を推進するためにエージェント層と情報をやりとりするために必要な機能を含む。

【0043】

一実施例では、承認エンジンは既存のスキームをサポートする。一実施例では、集中型および分散型のアイデンティティ格納もサポートされる。一実施例では、承認エンジンは、異なる制御フラグとの組合せでリソース毎に複数の認証スキームをサポートしており、プロトコル結合およびエージェント環境などの信用証明収集の詳細に依存しない。一実施例では、承認エンジンは、承認サービスをリモートまたは外部の承認サービスに委任してもよい。

【0044】

一実施例では、承認エンジンは、別の認証されたユーザ（たとえば、管理者またはサポート人員）によるユーザのなり済ましをサポートする。一実施例では、承認エンジンはまた、信用証明収集のために複数のエージェント相互作用モデルをサポートできる。

【0045】

一実施例では、承認エンジンは、セッション持続性、トークン生成／検証、またはシステムに関連付けられた任意の他の機能性といった必要とされる機能性のために、他のエンジンおよび／または基盤ＡＰＩを活用してもよい。加えて、一実施例では、承認エンジンは、認証ポリシーおよび使用事例の移行をサポートする。

【0046】

ＳＳＯエンジン：ＳＳＯエンジンは、シングルサインオン（ＳＳＯ）経験をユーザに提供することを担当する。これは、ユーザがあるアプリケーションに「サインイン」し、そのトークンを用いて他のアプリケーションにアクセスしてもよいということを意味する。それは、有効ユーザセッションにおいてあらゆるＲＰ間でログアウトのオーケストレーションを行なうことにより、グローバルログアウトを容易にすることに関与する、ユーザセッションライフサイクルを管理することによって、これを達成する。

【0047】

一実施例では、ＳＳＯエンジンは、ログアウトオーケストレーションおよびクライアント状態ハンドリングをサポートする。加えて、ＳＳＯエンジンは、ウェブエージェントのためのサポートを提供する。たとえば、ウェブエージェントは、ウェブベースのアプリケーションへのアクセスを「防護する」ために使用されてもよい。アプリケーションにアクセス要求がなされると、ウェブエージェントはその要求を阻止し、要求をアクセス制御システムに渡す。要求が標準化された後で、標準化された要求はＳＳＯエンジンに送信され、それは、クライアントセッション状態を持続してその位置を特定することを担当する。

【0048】

一実施例では、ＳＳＯエンジンは、セッションインデックス付け、領域を範囲とする、およびリソースを範囲とする信頼モデル、ならびにクッキーベースのマルチ領域マルチゾーンＳＳＯをサポートする。一実施例では、ＳＳＯエンジンは、必要とされる機能性（たとえば、セッション持続性、トークン生成）のために、他のエンジンおよび／または基盤ＡＰＩを活用する。

【0049】

連合エンジン：連合エンジンは、パートナーとのアカウント連結を管理し、連合セッション制御サービスを提供することを担当する。連合エンジンは、連合プロトコルを用いて、領域間での標準ベースのＳＳＯを可能にする。連合エンジンはまた、ＳＳＯ環境におけるログアウトフローのオーケストレーションを行なう。

【0050】

一実施例では、連合エンジンは、複数の連合プロトコルをサポートする。連合データは、データベースシステムまたは他のストレージなどのリポジトリに持続的に格納されていてもよい。一実施例では、インフォカード（Infocard）ベースの認証を含むさまざまな認証メカニズムが、連合エンジンによってサポートされる。しかしながら、他の機能および機能性が外面化されてもよい。たとえば、一実施例ではセキュリティ処理が外面化されてもよい。

【0051】

トークンエンジン：トークンエンジンは、セキュリティトークンおよび信用証明の生成、検証、削除、および更新を含む、あらゆるトークンについてのトークンライフサイクル全体を管理することを担当する。それは、外部動作に使用されるネイティブＳＳＯブリッジを用いたローカルの動作および外部の／委任された動作の双方を含む。（サイロ間の複数のトークンエンジンではなく）単一のトークン制御エンジンを保持することは、製品間の改良されたセキュリティ、保全性、およびコード複製の排除を確実にする。トークンエンジンはまた、プロトコル／コンポーネント／サーバ間でトークンに関連付けられたユーザのセキュリティトークンおよび信用証明の位置を特定し、それらをレゾルブするための機能も含む。一実施例では、トークン処理基盤ＡＰＩは、信用証明およびトークン処理の力学または構造的局面を取扱うことを担当する。

【0052】

一実施例では、トークンエンジンは、任意の所与のトークンタイプ用の複数のトークン生成、検証、削除、および／または更新モジュールを含む。加えて、トークンエンジンは、任意の既存のセキュリティ製品／インフラストラクチャとの統合を必要とすることなく、またはそれらを活用することなく、ユーザ名、ＳＡＭＬ、およびＸ．５０９（検証）をサポートする。なぜなら、これらの機能はトークンエンジンに含まれているためである。一実施例では、トークンエンジンは、クライアントが証明トークンおよび他のアイデンティティ証明データを入力として提出する能力をサポートし、また、複数の情報のやりとりに関与するＳＰＮＥＧＯのような課題応答および交渉プロトコルもサポートする。いくつかの実施例では、トークンエンジンはトークン処理のためにＦＩＰＳ１４０−２暗号モジュールを活用でき、トークンエンジンによって行なわれるどのＸ．５０９トークン処理も、ＮＩＳＴによって特定されているような連邦処理規則をサポートする。トークンエンジンはまた、メタデータを発行してランタイムでのエンジン機能性の動的発見をサポートする。加えて、トークンエンジンは、Ｊ２ＳＥおよびＪ２ＥＥクライアントによって呼出されることが可能であり、Ｊ２ＥＥサーバ間ではポータブルである。型付けされたトークンライフサイクル動作のための拡張可能なプラグインモデルもサポートされてもよい。

【0053】

一実施例では、トークン処理の構造的局面（構築）がトークン処理基盤ＡＰＩに委任される。一実施例では、トークン処理基盤ＡＰＩを介して、追加のカスタムトークンタイプおよびカスタマイズされたトークンハンドリングも利用可能である。一実施例では、トークンのセキュリティ処理は外面化されており、必要とされる機能性のためにパートナー信頼メタデータエンジン、他のエンジンおよび／または基盤ＡＰＩを活用してもよい。

【0054】

セッション制御エンジン：セッション制御エンジンは、ユーザ／管理者が起動したタイムアウトベースの事象に対するサポートを用いて、ユーザセッションおよびトークンコンテキスト情報を管理することを担当する。セッション制御エンジンは、セッションの使用を通してグローバルロックアウトのオーケストレーションを行なうことができる。セッション制御エンジンはまた、セッションの間中ずっとエンティティを認証することを担当するトークンを管理することも担当する。セッションを維持するために使用されるトークンの制御は、トークンライフサイクル制御と呼ばれる。セッション制御エンジンは、ユーザセッションを作成、更新および削除すること、プロトコル／コンポーネント／サーバ間でトークンに関連付けられたセッションの位置を特定し、セッションをレゾルブすること、ならびにトークンコンテキストを作成、更新および削除することを担当する。

【0055】

セッション制御エンジンは、データベースまたはリポジトリにアクティブセッションを格納してもよい。一実施例では、セッション満了後、設定可能な期間、アクティブでないセッションの情報が利用可能なままとなる。たとえば、セッションが利用可能なままとなり得る期間は、ユーザインターフェイスを介して入力されてもよい。

【0056】

いくつかの実施例では、セッション制御エンジンはまた、登録されたリスナに特定のセッション事象について通知でき、インメモリおよびＲＤＢＭＳセッション持続性をサポートし、分散されたインメモリセッション持続性をサポートし、ユーザ名、ＧＵＩＤ、およびユーザ名−プロバイダＩＤによってインデックス付けされ、セッションインデックス付けをサポートできるようになっていてもよい。

【0057】

カード制御エンジン：カード（ｉＣａｒｄを含む）により、人々は、自分たちのデジタルアイデンティティを編成すること、および任意の所与の情報のやりとりのために自分たちが使いたいものを選択することができるようになる。カード制御エンジンは、カードスペース（Cardspace）準拠のおよび他のカードタイプのライフサイクルを管理することを担当する。それは、ユーザ中心のアイデンティティモデルをサポートするために必要とされる主要機能性であり、カード関連プロトコルメッセージでＩＤＰのコントローラによって呼出される。

【0058】

信頼ポリシー制御エンジン：信頼ポリシー制御エンジンは、信頼ポリシー情報の制御およびアクセス、ならびにこれらのポリシーに基づく決定を可能にする。信頼ポリシー制御エンジンは、情報のやりとりに関与するピアエンティティとの信頼関係の制御を担当する。信頼ポリシーは、ユーザ間ではなくエンティティ間の信頼に向けられている。たとえば、２つのアプリケーションが互いとの信頼関係を構築してもよく、それらのアプリケーションが互いにデータを共有することを可能にする。

【0059】

信頼ポリシー制御エンジンは、情報をやりとりするエンティティについて信頼判定を行ない、信頼関係を管理し、プロトコル固有エンティティ識別子を正準表現にレゾルブ／変換するために必要な機能からなる。

【0060】

パートナーメタデータ制御エンジン：パートナーメタデータ制御エンジンは、パートナーに関するメタデータの制御およびアクセスを可能にし、より良好な制御および順守のための集中型制御のためにメタデータを一本化する。管理動作およびプロトコル動作の双方で呼出される。

【0061】

一実施例では、パートナーメタデータ制御エンジンは、メタデータを作成し、更新し、選択するために必要な機能からなる。それはまた、特定の対象にアクセスするために特定のプロトコルを用いてパートナーと情報をやりとりするのに必要とされるメタデータの位置を特定し、それを検索するための機能も含んでいてもよい。パートナーメタデータ制御エンジンはすべてのパートナー情報用のレジストリを保持しており、高性能化のために軽量記憶機構を使用する。各メタデータオブジェクトは自己記述的であり、したがってパートナーメタデータ制御エンジンは、メタデータのこの局面に準拠する必要とされるあらゆるタイプのメタデータを格納していてもよい。

【0062】

ネイティブＳＳＯブリッジ：ネイティブｓｓｏブリッジは、ＳＳＯポリシーサーバに固有のセマンティクス（semantics）および複雑性を採用している第三者のＳＳＯ／ポリシーサービスとのアクティブな統合に関連する機能を行なう。

【0063】

基盤ＡＰＩ３５０は、直接統合を介してではなくＡＰＩを介してアクセス制御システムが利用可能な追加の機能性を表わす。

【0064】

構造的および機能的概要
図６は、一実施例が実現され得るアクセス制御システム６１０を示す簡略化されたブロック図である。図６に示す実施例では、アクセス制御システム６１０は、エンティティ６３０、６４０、６５０、６６０、および６７０の集合であり、それらは各々、ソフトウェアロジックゲート、ハードウェアロジックゲート、またはそれらの任意の組合せといったロジックゲートにおいて実現化され得る。一実施例では、アクセス制御システム６１０は、入力／出力（Ｉ／Ｏ）インターフェイス６２０を含む。別の実施例では、Ｉ／Ｏインターフェイス６２０はアクセス制御システム６１０の一部ではなく、アクセス制御システム６１０に結合されている。Ｉ／Ｏインターフェイス６２０は、ネットワーク、またはキーボード、マウスなどのユーザ入力装置、もしくは任意の他のユーザ入力装置に、アクセス制御システム６１０を結合するように構成されてもよい。Ｉ／Ｏインターフェイス６２０はまた、出力６１４を送信もしくは表示可能なネットワーク、表示装置、または送信媒体装置を含む、入力６１２などの信号またはデータを提供もしくは解釈する他の装置または手段に、アクセス制御システム６１０を結合するように構成されてもよい。一実施例では、Ｉ／Ｏインターフェイス６２０は、複数のＩ／Ｏインターフェイスを表わしていてもよい。

【0065】

一実施例では、入力６１２は、アプリケーション６８０などのウェブアプリケーションまたはエージェント６９０などのエージェントからの入力を含んでいてもよい。エージェント６９０は、ユーザのウェブブラウザソフトウェアまたは他のソフトウェアもしくはハードウェアから発行されたアクセス要求といった、ユーザからのアクセス要求を阻止するように構成されてもよい。これらの要求は、入力６１２の形で、アクセス制御システム６１０に全体的にまたは部分的に向けられてもよい。

【0066】

一実施例では、アクセス制御システム６１０は、Ｉ／Ｏインターフェイス６２０から入力６１２を受信するように構成されたＩ／Ｏ部６３０を含む。Ｉ／Ｏ部６３０は、入力６１２または入力６１２に関連付けられた情報を、揮発性または不揮発性記録媒体などの持続性媒体に格納するように構成されてもよい。たとえば、Ｉ／Ｏ部６２３はロギングロジックを含んでいてもよい。一実施例では、Ｉ／Ｏ部６２３は、サービス制御部６４０、メタデータリポジトリ６５０、標準化部６６０、およびコンポーネント制御エンジン６７０に通信可能に結合されている。

【0067】

一実施例では、サービス制御部６４０サービス制御部６４０は、サービスエンティティ層５１０に関連付けられたサービスエンティティを管理する。これらのサービスエンティティは、たとえば、特定のタイプの要求を聞くプロトコル固有リスナを含んでいてもよい。一実施例では、サービスエンティティによって要求が受信されると、その要求は標準化部６６０に渡される。

【0068】

一実施例では、アクセス制御システム６１０は標準化部６６０を含む。標準化部６６０は、プロトコル結合層５２０に関して上述した機能を実現する。一実施例では、標準化部６６０は、サービス制御部６４０からプロトコル固有要求を受信する。標準化部６６０は次に、非プロトコル固有情報のみをコンポーネント制御エンジンに提供することによって、その要求を標準化する。加えて、標準化部６６０は、標準化された要求に応じてコンポーネント制御エンジン６７０から期待される応答の詳細を記述するために、メタデータリポジトリ６５０からコンポーネント制御エンジン６７０にメタデータを提供してもよい。ここに使用されるように、「標準化された要求」という用語は、標準化された要求が基づいている元の要求とは異なる要求である。一実施例では、メタデータリポジトリ６５０は、メタデータおよび他のデータを格納するために使用される。

【0069】

一実施例では、アクセス制御システム６１０は、コンポーネント制御エンジン６７０を含む。コンポーネント制御エンジン６７０は、入来する要求に関連付けられたすべての活動の性能のオーケストレーションを行なう。具体的には、コンポーネント制御エンジンは、標準化部によって提供された情報に基づいて、要求を満たすのにどちらの機能的コンポーネント５４０および５５０が必要とされているかを判断し、それらのコンポーネントにそれぞれの機能を行なうよう指示する。

【0070】

例示的なコンフィギュレーションメタデータ
一実施例では、標準化部６６０は、コンポーネント制御エンジン６７０にコンフィギュレーションメタデータを提供する。コンフィギュレーションメタデータおよび他のメタデータは、アクセスメタデータオブジェクトと呼ばれてもよい。一実施例では、このメタデータは、メタデータリポジトリ６５０または他の有形記憶媒体に格納される。メタデータの目的は、コンポーネント制御エンジン６７０が要求を満たして要求のオーケストレーションを行なうのに役立つ詳細を、コンポーネント制御エンジン６７０に提供することである。具体的には、各メタデータオブジェクトは、ある特定のタイプの要求を表わしていてもよく、要求を遵守するためにどちらの機能的コンポーネントを使用すべきか、およびどのタイプの応答が標準化部６６０によってプロトコル結合層５２０で期待されているかということを含む、どのように要求を取扱うかに関するコンポーネント制御エンジン６７０への命令を含んでいてもよい。

【0071】

上述の層間の通信を達成するためにあらゆるコンフィギュレーションメタデータフォーマットまたはデータソースが使用されてもよいが、以下のＸＭＬコードは、一実施例で使用され得るサンプルコンフィギュレーションスキーマを表わしている。

【0072】

【数1】

【0073】

このコンフィギュレーションスキーマを使用するより具体的な一例を、以下に示す。

【0074】

【数2】

【0075】

コンフィギュレーション情報の形式よりも、コンフィギュレーションによって入手すべき情報の方がより重要である。言い換えれば、上述するようなＸＭＬでコンフィギュレーションが実現されることはそれほど重要ではなく、コンポーネント制御エンジン６７０にとって有益となるように、十分な情報がコンフィギュレーションファイルで入手されることの方がより重要である。いくつかの実施例で入手され得る情報は、製品挙動、製品結合、製品バックエンド統合、および製品拡張を含む。

【0076】

製品挙動の例は、Ｗｉｎｄｏｗｓ（登録商標）ネイティブ認証／ユーザ名／Ｘ．５０９／などの承認情報、およびデバッグ／タイムアウト／監査／スロットリング情報などの他の一般的な機能性を含む、承認、メタデータおよび信頼モデル情報を含む。製品結合の例は、ＨＴＴＰベーシック／ダイジェスト、ＯＡＰ（Oracle Access Protocol：オラクルアクセスプロトコル）／ＳＡＭＬ／ＯｐｅｎＩＤシンプルサイン、インフォカード／ヒギンス情報といったセキュリティ情報を含む。結合はまた、メタデータ、ＨＴＴＰトランスポート、メッセージ符号化、または他の同様の情報といった非セキュリティ情報も含んでいてもよい。製品バックエンド統合情報は、ユーザデータ格納、パートナー信頼、ＩＤ管理およびアクセス制御インフラストラクチャについての情報、ならびに監査、ロギング、および監視情報を含んでいてもよい。製品拡張は、結合、統合、および挙動拡張を含んでいてもよい。

【0077】

アクセス制御要求のハンドリング
図７は、一実施例が実現され得るアクセス制御システムの機能を示すフローチャートである。ステップ７１０で、要求が受信される。たとえば、この要求は、アプリケーション６８０などのアプリケーションまたはエージェント６９０などのエージェントからの要求であってもよい。この要求は、認証、承認、または機能的コンポーネント層５４０および５５０によってサポートされている任意の他のサービスについての要求を含んでいてもよい。一実施例では、この要求は、入力６１２としてＩ／Ｏインターフェイス６２０を介してアクセス制御システム６１０によって受信されてもよい。たとえば、一実施例では、Ｉ／Ｏインターフェイス６２０は、処理のために要求をＩ／Ｏ部６３０に提供してもよい。

【0078】

ステップ７２０で、標準化された要求が生成される。たとえば、標準化部６６０は、元の要求よりも多い、少ない、または異なる情報を含み得る要求の変更バージョンを生成する。一実施例では、要求は、標準化された要求に含まれていないプロトコル固有情報を含んでいてもよい。

【0079】

ステップ７３０で、標準化された要求の少なくとも一部を満たすように、機能的コンポーネントが選択される。たとえば、要求がトークンについての要求である場合、要求を満たす機能的コンポーネントとしてトークンエンジンが、コンポーネント制御エンジン６７０によって選択されてもよい。一実施例では、要求が他の機能的コンポーネントからの追加サービスを必要としている場合、それらのコンポーネントも、要求の遵守に参加するよう、コンポーネント制御エンジン６７０によって選択されてもよい。

【0080】

図８は、一実施例が実現され得るアクセス管理システムのより特定的な機能を示すフローチャートである。これらの特定の機能は、図７のステップ７２０および７３０に関連付けられている。

【0081】

ステップ８１０で、どのタイプの要求を受信したかという判断が、サービス制御部６４０によって下される。たとえば、要求はｗｅｂＳＳＯ要求であってもよい。ステップ８２０で、要求タイプに基づいて、標準化された要求が生成される。たとえば、標準化された要求は、プロトコル固有情報がないｗｅｂＳＳＯ要求の一部を含んでいてもよい。ステップ８３０で、要求への応答の生成のオーケストレーションを行なうのに必要とされる情報を記述するメタデータリポジトリ６５０からのアクセスメタデータとともに、標準化された要求はコンポーネント制御エンジン６７０に送信される。

【0082】

ステップ８４０で、標準化部６６０から、標準化された要求が、コンポーネント制御エンジン６７０で受信される。要求はアクセスメタデータを含んでいてもいなくてもよい。一実施例では、要求がアクセスメタデータを含んでいない場合、メタデータリポジトリ６５０からアクセスメタデータが検索されてもよい。ステップ８５０で、標準化された要求とアクセスメタデータとに基づいて、標準化された要求の少なくとも一部を満たすように、機能的コンポーネントが選択される。ステップ８６０で、選択されたコンポーネントが、標準化された要求への応答の少なくとも一部を生成する。

【0083】

一実施例では、標準化された要求に応じて生成された応答は、コンポーネント制御部６７０によって標準化部６６０に提供され、それは次に完全な応答をサービス制御部６４０に提供する。一実施例では、完全な応答は、異なる機能的コンポーネントによって生成されたいくつかの部分的応答を含んでいてもよい。たとえば、応答は、すべて異なる機能的コンポーネントによって生成された認証および承認情報ならびにトークンを含んでいてもよい。応答は、期待されるプロトコル固有フォーマットを用いて要求エンティティに送信されてもよい。なぜなら、プロトコル固有情報は、コンフィギュレーションメタデータに基づいてコンポーネント制御エンジンによって提供されるためである。

【0084】

一実施例では、要求エンティティは、アプリケーション、またはアプリケーションのためにサービスを行なうエージェントであってもよい。たとえば、エージェントは、承認要求といったあるタイプの要求を阻止し、アクセス制御システム６１０と通信することによってそれらの要求を取扱ってもよい。要求は、アプリケーションが第２のアプリケーションにアクセスすることを可能にするトークンについての要求であってもよい。要求に応じて、トークンエンジンは、第１のアプリケーションのユーザの代わりに第２のアプリケーションに関連付けられた変更を行なうことを第１のアプリケーションに承認するトークンを生成してもよい。

【0085】

一実施例では、要求は、アイデンティティプロバイダに関連付けられたトークンについての要求を含んでいてもよい。標準化部６６０は標準化されたアクセス要求を生成し、それはコンポーネント制御エンジン６７０に提供され、それは要求を満たすようにトークンエンジンを選択する。このため、第１の要求についてのトークンを生成するために使用されたものと同じトークンエンジンが、第２の異なるタイプの要求についてのトークンを生成するためにも使用される。

【0086】

一実施例では、一部またはすべての機能的エンジンは同じ状態を保つ。その状態は、時折またはサーバがアクセスされるたびに、トークンまたはクッキーの形で各機能的エンジンに提供される。たとえば、ユーザはリソースにアクセスしてもよく、そのリソースへのアクセスを提供する機能的コンポーネントを用いてクッキーを構築する。別のアクセスが生じると、クッキーはアクセス制御システム６１０に戻される。一実施例では、複数の機能的エンジンが、同じ状態情報（すなわち、同じクッキー）の一部に関連付けられてもよい。この状態情報はプロトコル結合層を通り抜け、次にコントローラに送信される。コントローラは、すべての機能的エンジンに状態情報アクセスを提供する。一実施例では、要求は、第１の機能的コンポーネントに関連付けられた状態と第２の機能的コンポーネントに関連付けられた状態とを識別する複合状態情報を含む。

【0087】

一実施例では、アクセスについての要求を許すべきかどうかを判断するためのアクセスポリシーメタデータを格納するために、アクセスポリシーリポジトリが構成される。一実施例では、アクセスポリシーメタデータによって特定された基準を第１の標準化されたアクセス要求が満たしていないという判断に応じて、アクセスポリシーメタデータに関連付けられた情報を含む第１の要求エンティティへの応答を生成するために、ポリシー制御機能的コンポーネントが構成される。たとえば、メタデータは、ポリシー不具合に関連付けられたエラーメッセージを特定してもよい。このエラーメッセージは、アクセスポリシーメタデータによって特定された基準を要求が満たしていないという判断に応じて返送されてもよい。

【0088】

アクセス制御システムにおけるポリシー施行
アクセス制御ポリシーは、決定を導き、意図されたアクセス制御結果を達成するためのよく練られた行動計画である。アクセス制御ポリシーは、認証、承認および監査のプロセスに適用可能である。認証ポリシーは、要求者のアイデンティティを確立するために使用され、一方、承認ポリシーは、要求者が要求した行動を対象に対して行なうことを許可するかどうかを判断するために使用される。

【0089】

ポリシー施行には少なくとも２タイプある。これらは、情報ベースのポリシー施行と決定サービスベースのポリシー施行とを含む。情報ベースのポリシー施行では、施行ポイントによってポリシー評価が行なわれる。加えて、ポリシーオブジェクトタイプおよびスキーマが発行され、施行ポイントはポリシーの構造および表現に関心があり、それらに気付いている。決定ベースのポリシー施行では、ポリシー評価はポリシー施行ポイントによって決定サービスにアウトソーシングされる。加えて、施行ポイントは、決定のみに関心があり、施行に使用されるポリシーの構造または表現には関心がなく、もしくはそれらに気付いていない。

【0090】

一実施例では、ポリシー施行は、ここに説明される階層化アプローチを用いてアクセス制御ソリューションにおいて実現されてもよい。たとえば、いくつかの実施例では、ポリシーエンジンは、統合された機能的コンポーネントまたはＡＰＩを有する機能的コンポーネントとして実現されてもよい。一実施例では、さまざまな情報アクセスおよびサービスのために、承認、リスク、不正、および信頼仲介に関連付けられたポリシー決定が考えられる。一実施例では、プラグインにやさしい階層化アプローチのため、いかなるポリシーも実現され得るが、以下のものが具体的に検討されてきた：認証規則−信用証明収集規則、連鎖規則、強制認証；ＳＳＯ−目的、範囲、セッションライフタイム；Ｉ−Ｃａｒｄ−タイプ、クレーム、データハンドリング；信頼−発行者、受領者；連合−アカウント連結規則、プロファイルサポート、名前ＩＤ選択；メッセージフォーマット化−署名／暗号化、符号化および最適化の使用；監査およびロギング−リソースへのレベルのマッピング；パートナー−メタデータの使用；およびセキュリティトークン−発行／交換、トークン更新、削除、委任およびなり済まし規則。

【0091】

正準移行フレームワーク
従来のソリューションは、ＡＭコンポーネント／製品の２つの所与のバージョンがともに機能できることを確実にするために、広範な製品検定プロセスと組合せられた、フルアップグレード用のダウンタイムまたはサポート共存機能を必要とするプロセスを通して、移行をサポートする。検定プロセスは、非常に時間がかかりかつ高価であるため、拡張できない。ダウンタイムアプローチは、ミッションクリティカルなシステムであるため、ＡＭコンポーネント／製品にとっては役に立たない。このため、配備モデルを促進する新しい移行アーキテクチャが提供され、ＡＭコンポーネント／製品の異なるバージョンが共存することを可能にする設計パターンが、ゼロダウンタイム要件に対処するために必要とされる。加えて、共存モジュールがもはや必要ではなくなった場合に後で除去／撤去できるように、共存モジュールを分離する能力が望ましい。

【0092】

より具体的には、一実施例では、既存のおよびレガシーのアクセス制御ソリューションが段階的にかつ破壊が最小限に抑えられる態様で移行されることを可能にする正準移行アーキテクチャが提供される。それはまた、クライアントおよびサーバのタイプやバージョンを互いに切離し、それにより、既存の配備においてレガシーのならびにより新しいクライアントおよび／またはサーバを組合せることを可能にする。これは、既存のインフラストラクチャが引続き機能するであろうという保証の下で、個々の部品／製品のポイントアップグレードを可能にすることにより、アクセス制御製品の特定のバージョンにおける顧客の現在の投資の将来の保証を可能にする。

【0093】

図９および図１０は、アクセス制御製品に適用可能な２つの移行パターンの例を示す。一実施例では、アクセス制御システム６１０は、移行プロセス時のＡＭ配備の利用可能性を確実にしつつ、ＡＭ配備の漸進的移行を容易にするが、それは非常に必要である。なぜなら、ＡＭ配備のいかなるダウンタイムも、アクセスできない企業アプリケーションをもたらすためである。

【0094】

図９では、顧客は、レガシーアプリケーションの一部のために次世代ＳＳＯポリシーの表現力を使用することを望んでいる。一実施例では、顧客は、ポリシーデータ移行アダプタを用いて、レガシーポリシーを新しいＮＧ−ＳＳＯ／現在のソリューションポリシーに移行する必要があるであろう。レガシーポリシーサーバは、プラグインアダプタを介して、上述のポリシー処理を共存プロキシに委任するであろう。たとえば、ブラウザ９０５は、レガシーポリシー施行ポイント９１０に接続して、リライングパーティ９２０へのアクセスを要求するかもしれない。これに応じて、レガシーポリシー施行ポイント９１０は、共存プロキシ９５０と情報をやりとりするプロトコルアダプタ９４０と通信する。共存プロキシ９５０は、ＮＧ−ＳＳＯサーバ９４５にアクセスする。一方、レガシーポリシー９３５は、ポリシーデータ移行アダプタ９３０を用いてＮＧ−ＳＳＯサーバ９４５に移行されてもよい。ＮＧ−ＳＳＯポリシー施行ポイント９１５がリライングパーティ９２５などのリライングパーティに関連付けられている場合、情報のやりとりが直接、ＮＧ−ＳＳＯサーバ９４５と行なわれてもよい。ＮＧ−ＳＳＯサーバ９４５へのそれほど破壊的でない移行を容易にするために、移行が完了するまで、既存のポリシー施行ポイントに対するサポートが存続してもよい。

【0095】

図１０では、顧客は、ポリシーデータ移行アダプタを用いて、レガシーポリシーをＮＧ−ＳＳＯポリシーに移行する。顧客は、引続きレガシーＰＥＰを使用すること、および漸進的にＮＧ−ＳＳＯ ＰＥＰに移行することを望んでいる。レガシーＰＥＰはここでは、レガシーサーバとＮＧ−ＳＳＯサーバとの間のプロトコルブリッジとして作用するプロトコルアダプタを介して、共存プロキシと通信する。たとえば、ブラウザ１００５は、レガシーポリシー施行ポイント１０１０に接続して、リライングパーティ１０２０へのアクセスを要求するかもしれない。これに応じて、レガシーポリシー施行ポイント１０１０はポリシーサーバ１０３０と通信し、それは次にプラグインアダプタ１０３５と通信する。プラグインアダプタ１０３５は共存プロキシ１０４５と情報をやりとりし、共存プロキシ９５０はＮＧ−ＳＳＯサーバ９４５にアクセスする。一方、レガシーポリシーは、ポリシーデータ移行アダプタ１０５０を用いてポリシーサーバ１０３０からＮＧ−ＳＳＯサーバ１０４０に移行されてもよい。次世代シングルサインオンポリシー施行ポイント１０１５がリライングパーティ１０２５などのリライングパーティに関連付けられている場合、情報のやりとりが直接、ＮＧ−ＳＳＯサーバ１０４０と行なわれてもよい。ＮＧ−ＳＳＯサーバ１０４０へのそれほど破壊的でない移行を容易にするために、移行が完了するまで、既存のポリシー施行ポイントに対するサポートが存続してもよい。

【0096】

本発明の一実施例は、複数のアクセス制御製品の組合せられた特徴集合をサポート可能な単一の製品を提供する。このアーキテクチャは、既存の製品の収束が異なる中心に基づくこと、互換性がないアーキテクチャを有すること、ならびに異なる言語および技術を用いて構築されることを可能にする。一実施例では、アクセス制御アーキテクチャは、拡張性および保全性を改良する。有益には、説明されるいくつかの実施例は、新しい能力および複合ソリューションの系統立った発展を容易にする階層化モデルおよびオーケストレーションコントローラコンポーネントを提供する。有益には、本発明のいくつかの実施例は、プロトコルにより定義されたエンティティとそれらの対応する正準表現にマッピングする正準の実世界の物理的エンティティとの単一セットを表わす拡張可能な基盤を提供し、それにより、同じ物理的エンティティ（サービス、アプリケーションクライアント、またはユーザなど）が、問題領域およびプロトコルにまたがる複合ソリューションの一部となることを可能にする。有益には、いくつかの実施例は、共有可能な機能的コンポーネントを識別しパッケージ化するためのパターンを、異なるフォームファクタ（組込、配布など）で配備可能となるよう提供し、それにより、広範囲の顧客配備環境を可能とする。有益には、いくつかの実施例は、同じ組立可能アーキテクチャを利用する一組の専用サービスファサードを提供し、レガシーから新技術への漸進的移行を可能にしつつ、レガシー技術の共存および統合制御を容易にする。有益には、いくつかの実施例は、情報ライフサイクルから情報タイプを切離すインフラストラクチャを提供して、外面化すべきアクセス制御システム全体にわたる管理と施行との外面化および共有を可能にし、このため、ポリシー決定およびセッションインフラストラクチャの切離し／外面化を可能にする。有益には、いくつかの実施例は、問題領域および管理境界（たとえば、企業リソース用のＷｅｂＳＳＯ、パートナー用のＩＤ連合、ＩＤ伝搬およびウェブサービスへの委任されたアクセスなど）間のポリシーの一貫した管理および施行を容易にする。

【0097】

ハードウェア概要
図１１は、本発明の一実施例に従って使用され得るシステム環境１１００の物理的コンポーネントを示す簡略化されたブロック図である。この図は単なる一例であり、請求の範囲を過度に限定するものではない。当業者であれば多くの変形、代替例、および修正を認識するであろう。

【0098】

図示されているように、システム環境１１００は、ネットワーク１１１２を介してサーバコンピュータ１１１０と通信可能に結合された１つ以上のクライアントコンピューティング装置１１０２、１１０４、１１０６、１１０８を含む。一組の実施例では、クライアントコンピューティング装置１１０２、１１０４、１１０６、１１０８は、上述のグラフィカルインターフェイスの１つ以上のコンポーネントを実行するように構成されてもよい。

【0099】

クライアントコンピューティング装置１１０２、１１０４、１１０６、１１０８は、汎用パーソナルコンピュータ（たとえば、マイクロソフトＷｉｎｄｏｗｓ（登録商標）および／またはアップルマッキントッシュ（登録商標）オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む）、携帯電話またはＰＤＡ（マイクロソフトＷｉｎｄｏｗｓモバイルなどのソフトウェアを実行し、インターネット、ｅメール、ＳＭＳ、ブラックベリー（登録商標）、および／または他の通信プロトコルに対応）、および／または商業的に入手可能なさまざまなＵＮＩＸ（登録商標）またはＵＮＩＸ系オペレーティングシステムのいずれかを実行するワークステーションコンピュータ（さまざまなＧＮＵ／Ｌｉｎｕｘ（登録商標）オペレーティングシステムを含むが，これらに限定されない）であってもよい。また、これに代えて、クライアントコンピューティング装置１１０２、１１０４、１１０６、および１１０８は、ネットワーク（たとえば、以下に説明するネットワーク１１１２）を通してサーバコンピュータ１１１０と通信可能な任意の他の電子装置であってもよい。システム環境１１００は４つのクライアントコンピューティング装置と１つのサーバコンピュータとを有して図示されているが、任意の数のクライアントコンピューティング装置およびサーバコンピュータがサポートされてもよい。

【0100】

サーバコンピュータ１１１０は、汎用コンピュータ、特化サーバコンピュータ（たとえば、ＬＩＮＵＸサーバ、ＵＮＩＸサーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラック搭載サーバなどを含む）、サーバファーム、サーバクラスタ、もしくは任意の他の適切な構成および／または組合せであってもよい。サーバコンピュータ１１１０は、上述のいずれかを含むオペレーティングシステム、および商業的に入手可能なあらゆるサーバオペレーティングシステムを実行してもよい。サーバコンピュータ１１１０はまた、ウェブサーバ、Ｊａｖａ（登録商標）仮想マシン、アプリケーションサーバ、データベースサーバなどを含むさまざまなサーバアプリケーションおよび／または中間階層アプリケーションのいずれかを実行してもよい。さまざまな実施例では、サーバコンピュータ１１１０は、上述の診断機能性を提供する１つ以上のウェブサービスまたはソフトウェアアプリケーションを実行するよう適合されている。たとえば、サーバコンピュータ１１１０は、上述のさまざまなフローチャートで説明されるさまざまな方法を実行するように構成されてもよい。

【0101】

図示されているように、クライアントコンピューティング装置１１０２、１１０４、１１０６、１１０８、およびサーバコンピュータ１１１０は、ネットワーク１１１２を介して通信可能に結合されている。ネットワーク１１１２は、ＴＣＰ／ＩＰ、ＳＮＡ、ＩＰＸ、AppleTalkなどを含むがそれらに限定されない商業的に入手可能なさまざまなプロトコルのいずれかを用いてデータ通信をサポート可能なあらゆるタイプのネットワークであってもよい。ほんの一例として、ネットワーク１１１２は、イーサネット（登録商標）ネットワーク、トークンリングネットワークなどのローカルエリアネットワーク（local area network：ＬＡＮ）；ワイドエリアネットワーク；仮想プライベートネットワーク（virtual private network：ＶＰＮ）を含むがそれに限定されない仮想ネットワーク；インターネット；イントラネット；エクストラネット；公衆交換電話網（public switched telephone network：ＰＳＴＮ）；赤外線ネットワーク；無線ネットワーク（たとえば、プロトコルのＩＥＥＥ８０２、１１スイートのいずれか、当該技術分野で公知のBluetooth（登録商標）プロトコル、および／または任意の他の無線プロトコルの下で動作するネットワーク）、および／または、これらのおよび／または他のネットワークの組合せであってもよい。さまざまな実施例では、クライアントコンピューティング装置１１０２、１１０４、１１０６、１１０８、およびサーバコンピュータ１１１０は、ネットワーク１１１２を通してデータベース１１１４にアクセス可能である。いくつかの実施例では、クライアントコンピューティング装置１１０２、１１０４、１１０６、１１０８、およびサーバコンピュータ１１１０は各々、それ自体のデータベースを有する。

【0102】

システム環境１１１０はまた、１つ以上のデータベース１１１４を含んでいてもよい。データベース１１１４は、統合リポジトリのインスタンス、およびこの開示に記載される任意の他のタイプのデータベースまたはデータ記憶コンポーネントに対応していてもよい。データベース１１１４は、さまざまな場所に存在していてもよい。一例として、データベース１１１４は、コンピュータ１１０２、１１０４、１１０６、１１０８、１１１０のうちの１つ以上にローカルな（および／または存在する）記憶媒体上に存在していてもよい。また、これに代えて、データベース１１１４は、コンピュータ１１０２、１１０４、１１０６、１１０８、１１１０のいずれかまたはすべてからリモートであってもよく、および／またはこれらのうちの１つ以上と（たとえば、ネットワーク１１１２を介して）通信してもよい。一組の実施例では、データベース１１１４は、当業者にはよく知られているストレージエリアネットワーク（storage area network：ＳＡＮ）に存在していてもよい。同様に、コンピュータ１１０２、１１０４、１１０６、１１０８、１１１０に起因する機能を行なうためのあらゆる必要なファイルが、それぞれのコンピュータ上にローカルに、および／またはデータベース１１１４上にリモートで、適宜格納されてもよい。一組の実施例では、データベース１１１４は、ＳＱＬフォーマットのコマンドに応じてデータを格納し、更新し、検索するよう適合された、オラクル・コーポレイションから入手可能なオラクル１１ｇなどのリレーショナルデータベースである。さまざまな実施例では、データベース１１１４は、上述のような診断能力を提供するために使用されるデータを格納する。

【0103】

図１２は、本発明の一実施例を現実化するために使用され得るコンピュータシステムの簡略化されたブロック図である。コンピュータシステム１２００は、図１に示す処理システム１０２として機能してもよい。さまざまな実施例では、コンピュータシステム１２００は、上述のシステム環境１１００に示されたコンピュータ１１０２、１１０４、１１０６、１１０８、１１１０のいずれかを実現するために使用されてもよい。図１２に示すように、コンピュータシステム１２００は、バスサブシステム１２０４を介して多くの周辺サブシステムと通信するプロセッサ１２０２を含む。これらの周辺サブシステムは、メモリサブシステム１２０８およびファイルストレージサブシステム１２１０を含むストレージサブシステム１２０６と、ユーザインターフェイス入力装置１２１２と、ユーザインターフェイス出力装置１２１４と、ネットワークインターフェイスサブシステム１２１６とを含んでいてもよい。

【0104】

バスサブシステム１２０４は、コンピュータシステム１２００のさまざまなコンポーネントおよびサブシステムが意図されたように互いに通信するようにするための機構を提供する。バスサブシステム１２０４は単一のバスとして概略的に示されているが、バスサブシステムの代替的な実施例は複数のバスを利用していてもよい。

【0105】

ネットワークインターフェイスサブシステム１２１６は、他のコンピュータシステム、ネットワーク、およびポータルへのインターフェイスを提供する。ネットワークインターフェイスサブシステム１２１６は、コンピュータシステム１２００とは別のシステムとの間でデータを送受信するためのインターフェイスとして機能する。

【0106】

ユーザインターフェイス入力装置１２１２は、キーボード、ポインティングデバイス、たとえばマウス、トラックボール、タッチパッド、またはグラフィックタブレット、スキャナ、バーコードスキャナ、ディスプレイに一体化されたタッチスクリーン、音声入力装置、たとえば音声認識システム、マイク、および他のタイプの入力装置を含んでいてもよい。一般に、「入力装置」という用語の使用は、コンピュータシステム１２００に情報を入力するためのあらゆる可能なタイプの装置および機構を含むよう意図されている。

【0107】

ユーザインターフェイス出力装置１２１４は、ディスプレイサブシステム、プリンタ、ファックス機、または音声出力装置などの非視覚的表示を含んでいてもよい。ディスプレイサブシステムは、ブラウン管（cathode ray tube：ＣＲＴ）、液晶ディスプレイ（liquid crystal display：ＬＣＤ）などのフラットパネル装置、または投影装置であってもよい。一般に、「出力装置」という用語の使用は、コンピュータシステム１２００から情報を出力するためのあらゆる可能なタイプの装置および機構を含むよう意図されている。

【0108】

ストレージサブシステム１２０６は、本発明の機能性を提供する基本的なプログラミングおよびデータ構造体を格納するためのコンピュータ読取可能な持続性記憶媒体を提供する。プロセッサによって実行されると本発明の機能性を提供するソフトウェア（プログラム、コードモジュール、命令）が、ストレージサブシステム１２０６に格納されてもよい。これらのソフトウェアモジュールまたは命令は、プロセッサ１２０２によって実行されてもよい。ストレージサブシステム１２０６はまた、本発明に従って使用されるデータを格納するためのリポジトリを提供してもよい。ストレージサブシステム１２０６は、メモリサブシステム１２０８と、ファイル／ディスクストレージサブシステム１２１０とを含んでいてもよい。

【0109】

メモリサブシステム１２０８は、プログラム実行中の命令およびデータの格納のためのメインランダムアクセスメモリ（random access memory：ＲＡＭ）１２１８と、固定された命令が格納された読出専用メモリ（read only memory：ＲＯＭ）１２２０とを含む、複数のメモリを含んでいてもよい。ファイルストレージサブシステム１２１０は、プログラムおよびデータファイルのための持続的な（不揮発性の）の格納を提供しており、ハードディスクドライブ、フロッピー（登録商標）ディスクドライブならびに関連するリムーバブルメディア、コンパクトディスク読出専用メモリ（ＣＤ−ＲＯＭ）ドライブ、光学式ドライブ、リムーバブルメディアカートリッジ、および他の同様の記憶媒体を含んでいてもよい。

【0110】

コンピュータシステム１２００は、パーソナルコンピュータ、ポータルコンピュータ、ワークステーション、ネットワークコンピュータ、メインフレーム、キオスク、サーバ、または任意の他のデータ処理システムを含むさまざまな種類のものであり得る。コンピュータおよびネットワークの刻々と変化する性質により、図１２に示すコンピュータシステム１２００の説明は、コンピュータシステムの好ましい実施例を例示するための具体例としてのみ意図されている。図１２に示すシステムよりもコンポーネントが多いまたは少ない他の多くのコンポーネントが可能である。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】