(57)【要約】差し込み可能なアーキテクチャは、セキュリティ及びビジネスロジックのプラグインが、サーバー(206)をホストとするセキュリティサービスの中に挿入され、かつ、そのサーバー上、セキュリティドメイン(208)内の他のサーバー上、又はセキュリティドメイン間に存在する一以上の安全なリソースへのアクセスを制御することを可能にする。セキュリティサービス(222)は、セキュリティ実行、及びアクセス権判定における焦点として動作し、及び、一つのログイン処理内で使用又は判定された情報は、透過的かつ自動的に他のログイン処理に流通させることができる。権限付与は、特定のユーザー(204)が、特定の状況の中で、特定のリソース(226)を用いて、出来ること又は出来ないことを示している。権限の付与は、安全性の確保された環境の技術的側面(許可又は拒否の概念)を反映するだけでなく、サーバー提供者が要求するビジネスロジック又は機能を表現するためにも使用される。このようにして、権限の付与は、単純なセキュリティプラットフォームと複雑なビジネスポリシーのプラットフォームとの間の隔たりを埋める。
2004533075.tif 000002
【特許請求の範囲】
【請求項１】
クライアントが保護されたリソースにアクセスすることを可能にするセキュリティシステムであって、
保護されたリソースへのアクセスについての、クライアントアプリケーションからのアクセス要求を受け取り、前記アクセス要求をセキュリティサービスに伝えるアプリケーションインターフェース機構と、
前記アクセス要求を許可又は拒否する判定を行うセキュリティサービスと、
許可されたアクセス要求を前記保護されたリソースへ伝えるリソースインターフェースと、
を備えるセキュリティシステム。
【請求項２】
前記アプリケーションインターフェース機構が、アプリケーション配置記述を読み取り、前記配置記述をセキュリティサービス内に登録するためのアプリケーションコンテナを含む、
請求項１記載のセキュリティシステム。
【請求項３】
前記アプリケーションコンテナが、EnterpriseJavaBeansコンテナである、
請求項２記載のセキュリティシステム。
【請求項４】
前記アプリケーションコンテナが、WebAppコンテナである、
請求項２記載のセキュリティシステム。
【請求項５】
前記セキュリティサービスが、アクセスポリシーを定義し、前記アクセス要求を許可、拒否、又は保留の寄与判定を定めるための複数のアクセス判定機構を含む、
請求項１記載のセキュリティシステム。
【請求項６】
前記セキュリティサービスが、前記アクセス要求を前記複数のアクセス判定機構に転送し、前記寄与判定を合体させて、前記アクセス要求を許可又は拒否するセキュリティサービスによる一つの全体判定とするアクセス制御装置をさらに含む、
請求項５記載のセキュリティシステム。
【請求項７】
前記アクセス判定が、ビジネス機能に関連するアクセスポリシーを表すものである、
請求項５記載のセキュリティシステム。
【請求項８】
アクセスポリシーにおける変更を反映するために、アクセス判定がセキュリティサービスに付加される、
請求項５記載のセキュリティシステム。
【請求項９】
前記保護されたリソースに前記クライアントがアクセスすることができる権限の付与を定義するために、前記アクセス判定機構が使用される、
請求項５記載のセキュリティシステム。
【請求項１０】
前記アクセス判定機構のいずれか一つによる拒否又は保留によって、セキュリティサービスがアクセス要求を拒否するようになった、
請求項５記載のセキュリティシステム。
【請求項１１】
前記アクセス判定機構のいずれか一つによる保留によっては、セキュリティサービスがアクセス要求を拒否しないようになった、
請求項５記載のセキュリティシステム。
【請求項１２】
前記セキュリティサービスが、前記複数のアクセス要求に対する判定を検査するための検査メカニズムをさらに含む、
請求項５記載のセキュリティシステム。
【請求項１３】
前記リソースインターフェースが、保護されたリソースへの要求、又は保護されたリソースからの要求を通すためのインターフェース機構を含む、
請求項１記載のセキュリティシステム。
【請求項１４】
前記インターフェース機構が、JavaJ2EEセキュリティインターフェースを含む、
請求項１３記載のセキュリティシステム。
【請求項１５】
前記インターフェース機構が、セキュリティプロバイダーインターフェースを含む、
請求項１３記載のセキュリティシステム。
【請求項１６】
前記インターフェース機構が、前記リソースインターフェースの中にプラグインとして含まれる、
請求項１３記載のセキュリティシステム。
【請求項１７】
セキュリティサービスがさらに、前記保護されたリソースから前記クライアントへの、前記アクセス要求に対する応答を許可するか又は拒否するかを判定する、
請求項１記載のセキュリティシステム。
【請求項１８】
クライアントが保護されたリソースにアクセスすることを可能にする方法であって、
保護されたリソースへのアクセスについてのクライアントアプリケーションからのアクセス要求を、アプリケーションインターフェース機構で受け取り、前記アクセス要求をセキュリティサービスに伝えるステップと、
前記セキュリティサービスにおいて、前記アクセス要求を許可するか、又は拒否するかを判定するステップと、
許可されたアクセス要求を、リソースインターフェースを介して前記保護されたリソースへ伝達するステップと、
を含む方法。
【請求項１９】
前記アプリケーションインターフェース機構が、アプリケーション配置記述を読み取り、前記配置記述をセキュリティサービス内に登録するアプリケーションコンテナを含む、
請求項１８記載の方法。
【請求項２０】
前記アプリケーションコンテナがEnterpriseJavaBeansコンテナである、
請求項１９記載の方法。
【請求項２１】
前記アプリケーションコンテナがWebAppコンテナである、
請求項１９記載の方法。
【請求項２２】
複数のアクセス判定機構を介して前記セキュリティサービス内にアクセスポリシーを定義するステップと、
各アクセス判定機構において、前記アクセス要求を許可、拒否、又は保留するための寄与判定を定めるステップと、
をさらに含む、請求項１８記載の方法。
【請求項２３】
前記アクセス要求を、アクセス制御装置を介して、前記複数のアクセス判定機構に転送し、前記アクセス要求を許可又は拒否するために、前記寄与判定を合体させてセキュリティサービスによる一つの全体判定とするステップ、
をさらに含む請求項２２記載の方法。
【請求項２４】
前記アクセス判定が、ビジネス機能に関連するアクセスポリシーを表すものである、
請求項２２記載の方法。
【請求項２５】
アクセスポリシーにおける変更を反映するために、アクセス判定がセキュリティサービスに付加される、
請求項２２記載の方法。
【請求項２６】
前記保護されたリソースに前記クライアントがアクセスすることができる権限の付与を定義するために、前記アクセス判定機構を使用するステップ、
をさらに含む、請求項２２記載の方法。
【請求項２７】
前記アクセス判定機構のいずれか一つの拒否又は保留によりセキュリティサービスがアクセス要求を拒否するようになった、
請求項２２記載の方法。
【請求項２８】
前記アクセス判定機構のいずれか一つの保留によってはセキュリティサービスがアクセス要求を拒否しないようになった、
請求項２２記載の方法。
【請求項２９】
検査機構を介して前記複数のアクセス要求の判定を検査するステップ、
をさらに備える、請求項２２記載の方法。
【請求項３０】
リソースインターフェースを介して伝達する前記ステップが、インターフェース機構を介して、保護されたリソースへの、あるいは保護されたリソースからの要求を通すステップを含む、
請求項１８記載の方法。
【請求項３１】
前記インターフェース機構がJavaJ2EEセキュリティインターフェースを含む、
請求項３０記載の方法。
【請求項３２】
前記インターフェース機構がセキュリティプロバイダーインターフェースを含む、
請求項３０記載の方法。
【請求項３３】
前記インターフェース機構が、前記リソースインターフェースの中でプラグインとして含まれる、
請求項３０記載の方法。
【請求項３４】
前記保護されたリソースから前記クライアントへの前記アクセス要求に対する応答を、許可するか、又はは拒否するかの判定を行うステップ、
をさらに備える、請求項１８記載の方法。
【請求項３５】
安全性環境における保護されたリソースへのユーザーのアクセス権限の付与を定める方法であって、
保護されたリソースへのアクセスについてのユーザーアプリケーションからのアクセス要求を受け取るステップと、
前記アクセス要求で、セキュリティサービスを呼び出すステップと、
前記保護されたリソースへのアクセスについてのユーザーの権限付与を定めるステップと、
前記セキュリティサービスにおいて、前記ユーザーへの権限付与に基づき、前記アクセス要求を許可、又は拒否する判定を行うステップと、
(a)許可されたアクセス要求を前記保護されたリソースへ伝えるステップ、又は(b)拒否されたアクセス要求を前記保護されたリソースに与えないステップ、のいずれか一方のステップと、
を含む方法。
【請求項３６】
前記権限付与が、前記保護されたリソースのユーザーに利用可能なアクセスの形式を定めるものである、
請求項３５記載の方法。
【請求項３７】
前記アクセスの形式が、前記保護されたリソースの一部又は全部を、開く、修正する、削除する、コピーする、のいずれかを含む、
請求項３６記載の方法。
【請求項３８】
前記ユーザーの権限付与についての情報を、第一のセキュリティ領域から第二のセキュリティ領域へ伝えることができる、
請求項３５記載の方法。
【請求項３９】
前記ユーザーの権限付与についての情報を、前記第一のセキュリティ領域から前記第二のセキュリティ領域へ伝える前に、前記第一のセキュリティ領域からの付加的情報を使用してユーザーの権限付与を修正することができる、
請求項３８記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にサーバーセキュリティ機構に関するものであり、特にサーバーセキュリティのためのアーキテクチャに関するものである。
【背景技術】
【０００２】
サーバー技術、特定的にはeコマースのサーバーに適用される「セキュリティ」という用語は、この数年の間に、セキュリティ環境のいくつかの側面をカバーするまでに拡張されてきた。この用語の元来の定義は、特定のユーザー(あるいはクライアント)を認証したり、またアクセスを許可されていないサーバー上の情報を、ユーザーが検索、閲覧、あるいはアクセスしないようにする機構を、常に想定していた。
【０００３】
図１は、今日一般に使用されているセキュリティ機構の典型例を示している。クライアント102,104は、多数のプロトコル、例えばhttp110及びIIOP112を介して、アプリケーションサーバー106のようなセキュリティの確保されたリソースにアクセスする。アクセス要求は、典型的には物理的に固定された一連の規則に基づいて、要求されたアクセスを許可するか又は許可しないかを判定するセキュリティレイヤー118を通して、フィルターされる。セキュリティレイヤーは、保護されたリソース(たとえば、アプリケーションサーバーそのもの)のコンポーネントとすることができ、又は別の実体(たとえば、ファイアウォールシステムやデバイスの一部)として動作するものとすることもできる。
【０００４】
現在のシステムでは、アクセス要求の性質、クライアントの形式、又は保護されたリソースの形式を解析する試みは、殆ど又は全くなされていない。従って、セキュリティは、サーバーによって提供される保護されたリソースを理解し、それらのリソースへのユーザーやクライアントのアクセス権を支配する、あらかじめ定義された一連の規則を理解するような形態に設計された単純な「許可又は拒否」機構として考えられることが多い。要求が作成される方法、又は特定のユーザーがリソースへのアクセスを要求きるようにする環境設定についての理解は、殆ど又は全くなされず、またセキュリティ機構は、セキュリティについてのビジネスポリシーにおける新たな変更を反映するための規則の容易な修正には適していない。
【０００５】
セキュリティの概念、とりわけユーザー特有の環境を表している情報を含むサーバーセキュリティの概念、及び特定の安全性の確保されたリソースへのアクセス要求の表現方法を発展させる試みがなされてきた。同様に、ビジネスポリシー、セキュリティポリシー、及びアクセス権における変更を反映するために、容易に修正可能なセキュリティの仕組みを提供する試みもなされている。一般的に、これらの方法は、一連のビジネスポリシーについての質問を一緒に集め、「これはＯＫですか？---このアクセスはセキュリティ規則に従って許可されますか？」と問いかけることを、依然としてアプリケーションプログラマーの責任とする。この過程を全て含んでおり、セキュリティ関連ビジネスポリシーの質問を尋ねるプログラム及びアプリケーションを開発できるようにするのに、プログラマーがビジネスの意味及びビジネスポリシーを理解する必要がないようにする機構が必要とされている。
【０００６】
最近では、リソースの安全性確保に関する新しい一連の要求が、アプリケーションサーバーの顧客とシステムインテグレーターとの話し合いから生じている。これらの新たな要求は、構造基盤の代わりとしてのアプリケーションという観点からのセキュリティとして表現される。これらの新たな要求の中での主要な区別は、ビジネスポリシー実行の存在である。ビジネスポリシーの実行は、典型的には、ユーザーが行為する役割及びビジネス要求の状況に基づいて、ユーザーが遂行することの「権限が与えられた」行為として記述される。顧客及びシステムインテグレーターは、アプリケーションの中にビジネスポリシーを実行するコードを埋め込まなければならないことに、失望している。この形式のロジックの埋め込みは、ビジネスポリシーが変更される度に、アプリケーションが修正され、テストされ、かつ再配置されなければならないという点で、配置問題を生み出す。ビジネスポリシーの変更のレートが与えられると、修正及び再配置に対する現在の要求は受け入れられないものとなる。
【０００７】
顧客及びシステムインテグレーターは、理想的にはこれらの新しい承認能力を、異なる形式の実行及びリソースコンテナ、例えばEnterpriseJavaBean(EJB)、WebApplications(Servlet、JSP)のためのものを含む実行及びリソースコンテナ、並びに他の形式のビジネス及びリソースコンテナにわたって、普遍的に適用できるようにしたいのであろう。役割ベースのアクセス制御(RBAC)は、顧客及びシステムインテグレーターが求める主要な許可形式の一つとなりつつある。役割を使用する傾向は、承認判定を行う時に、組織の識別情報を識別の抽象的な形態として用いることを許す。役割の使用は、管理全体を単純化するため、アプリケーションセキュリティの管理におけるコスト及びエラーの両方を軽減する機構を提供する。
【０００８】
Java2EnterpriseEdition(J2EE)は、役割ベースのアクセス制御の宣言形態を定義する。しかしながら、それは宣言計画に基づくため、主体に対する役割の関連付けは静的なものである。さらに、現在のJ2EEの仕様は、与えられた主体と関連付けられる役割を決定する際に、要求のパラメータ又はターゲットの識別のようなビジネス要求の状況を考慮に入れることができる手段を、全く提供していない。その結果、アプリケーション開発者は、「オーナー」のような概念をサポートするために、動的な役割の関連付けを計算するビジネスポリシーの規則を、アプリケーション内に実装することが求められる。
【０００９】
近頃では、顧客及びシステムインテグレーターは、Java2セキュリティで定義されるパーミッションベースのアクセス制御や、Java2EnterpriseEditionで定義される役割ベースのアクセス制御によって提供されるもの以上に、より豊かな一連の承認能力を要求している。より高レベルの承認に対する要求の基本は、アクセス制御リスト及びビジネスポリシー実行といった、従来の承認機構の共通部分に見ることができ、また承認判定を行う際に、ビジネス要求の状況を考慮に入れることができる能力を含むこともできる。要求の状況は、ターゲットオブジェクトの識別情報、要求のパラメータの値、及び手続開始クライアントのネットワークアドレス又はIPアドレスのような潜在的な環境情報を含んでいる。
【００１０】
実行又はリソースコンテナの形式に関係なく、これらの新しい承認能力の統合のための単純な機構の欠如が、顧客及びシステムインテグレーターの失望の原因となっている。サービスプロバイダーインターフェース(SPI)は、外部の承認プロバイダーとの統合を許すための機構であり、カリフォルニア州サンノゼのBEAシステムIncの製品であるWebLogicサーバー等のいくつかのアプリケーションサーバーによって用いられている。このSPIの領域は、第三者承認機構を統合するための有効な手段として用いられる能力を制限するか、あるいは顧客及びシステムインテグレーターに新しい承認機能が求めらられるという点で、多くの限定がある。
【００１１】
現在の「領域」SPIの最も大きな制限の一つは、実行の範囲である。現在、領域SPIの機構の実行範囲は、EnterpriseJavaBean及びWebアプリケーションのようなリソースをカバーしない。特に領域SPIは、JMSの宛先、JNDIのエントリー、及びきめの粗いレベルのサーブレットのようなRMI形式のリソースに焦点が当てられる。そのようなリソースの保護をサポートするのに必要な承認ポリシーの定義を維持するために、領域SPIはアップデートできるのであるが、これが、最終的に領域SPIをすべての承認要求を受け入れるのには非現実的な機構にしてしまう他の制限である。
【００１２】
現在の領域SPIの第二の制限は、実行のポイントである。現在の領域SPIの機構は、保護されたリソースへのアクセスが領域自身の中に存在することを許すような判定がなされるポイントを許さない。そのかわり、実行のポイントは、アプリケーションサーバー自身の中にある。このアプローチのため、現在の領域SPIは、パーミッションベースの承認機構のみをサポートするように定義されており、領域SPIは単にアクセス制御リストのデータベースとして動作する。同様に、Java2sandboxもサポートできるJava2のポリシーオブジェクトを提供するほどの複雑さは、殆どのベンダーで受け入れられていない。
【００１３】
さらに他の制限は、現在の領域SPIの実行機構のサポートである。実行ポイントについては、現在の領域SPIによって許されている実行の機構は、パーミッションベースの承認機構に基づくもののみに限定される。これが、第三者承認プロバイダーを導く能力に反するものであり、これらプロバイダーの統合は、日常ベースで顧客及びシステムインテグレーターによって望まれている。
【００１４】
これらの制限は合わさって、プロバイダーの価値提供を最小化することなくエンタープライズアプリケーションサーバーと統合することができる承認プロバイダーの形式を抑制する。求められている高度の承認を提供するために、要求の状況を獲得するような能力は現在残っていない。
【００１５】
(優先権の主張)
本出願は、2001年6月11日に出願された、「サーバーセキュリティ及び権限付与処理のためのシステム及びその方法」という名称の米国特許出願第09/878,536号に基づく優先権を主張するものであり、この出願を引用により本出願の中に組み入れる。
【００１６】
(発明の概要)
本発明は、一般的に、サーバーセキュリティ、特にサーバーセキュリティと権限付与処理を提供するアーキテクチャに関するものである。差し込み可能なアーキテクチャは、セキュリティ及びビジネスロジックのプラグインが、サーバーをホストとするセキュリティサービスの中に挿入され、かつ、そのサーバー上、セキュリティドメイン内の他のサーバー上、又はセキュリティドメイン間にある一以上の安全性の確保されたリソースへのアクセスを制御することを可能にする。セキュリティサービスは、セキュリティ実行、及びアクセス権判定における焦点として動作し、また、ある一つのログインプロセスの中で使用又は判定された情報は、他のログイン処理にも透過的かつ自動的に流通させることができる。
【００１７】
本発明はまた、アクセス状況内で使用される権限付与の概念を導入する。本出願の文脈の中で使用される、「ユーザー」又は「クライアント」は、同一の事−実際の人間、実際の人間の管理下にあるハードウェアデバイス或いはソフトウェアアプリケーション、又はユーザー介入なしの自己管理下で動作するハードウェアデバイス或いはソフトウェアアプリケーションのいずれか、をいう。ユーザー（又はクライアント）は、サーバー上にある保護されたリソースへアクセスしようとする実体である。この保護されたソフトウェアとは、たとえばサーバー上で動作するソフトウェアアプリケーション、特定のウェブページ或いはウェブサイトの一部、又はデータベース等である。
【００１８】
ユーザーがリソースにアクセスしようとする時、セキュリティサービスは、アクセス要求の形式、宛先(保護されたリソース)、及びその要求が作成された環境−以下、アクセス状況または単に状況と呼ぶ、を判定する。この情報から、セキュリティサービスは、ユーザーに対する「権限の付与」、又は一連の権限の付与を決定することができる。権限の付与は、特定のユーザーが、特定の状況で、特定のリソースを用いて、出来ること又は出来ないことを明白に示すものである。権限の付与は、安全性の確保された環境の技術的側面(許可又は拒否の概念)を反映するのみならず、サーバー提供者が要求するビジネスロジック、又は機能を表すことにも使用される。このようにして、権限の付与は、単純なセキュリティプラットフォームと、複雑なビジネスポリシープラットフォームとの間の隔たりを埋める。
【００１９】
その能力を説明するため、次のようなビジネス例を考える：
「スミス医師は、患者の医療カルテを更新することができますか？」という質問に対する答えは、その質問が尋ねられた状況に依存する。パーミッションベースの承認システムでは、リソースは『医療カルテ』オブジェクトのある事例であり、要求は『更新する』ことであり、そして対象は『スミス医師』であるので、状況はない。従って、もし返された答えが『はい』ならば、スミス医師はいかなる患者のカルテでも更新することができる。能力ベースの承認システムでは、質問中に、どの患者の、という必要な状況を付加することが可能である。従って、この質問は、「スミス医師は、ジョン・ジョー氏の医療カルテを更新することができますか？」というように言い換えられることができる。この質問に対する回答を判定するにあたり、スミス医師がジョン・ジョー氏の個人的な医者であるのか、又はおそらく医療センターでの担当医であるのか、を知る必要がある。単純な循環を使って、その概念を次のように表すことができる。
【００２０】
ある実施形態では、本発明は、クライアントが保護されたリソースにアクセスすることを許し、保護されたリソースへのアクセスについてのクライアントアプリケーションからのアクセス要求を受け取り、及び前記アクセス要求をセキュリティサービスに伝えるアプリケーションインターフェース機構と；前記アクセス要求を許可または拒否する判定を行うセキュリティサービスと；許可されたアクセス要求を前記保護されたリソースに伝えるリソースインターフェースとを備えるセキュリティシステム、を備えるものである。
【００２１】
他の実施形態では、本発明は、クライアントが保護されたリソースにアクセスすることを許し、保護されたリソースへのアクセスについてのクライアントアプリケーションからのアクセス要求をアプリケーションインターフェース機構で受け取り、前記アクセス要求をセキュリティサービスに伝えるステップと；前記セキュリティサービスで、前記アクセス要求を許可又は拒否する判定を行うステップと；リソースインターフェースを介して、許可されたアクセス要求を前記保護されたリソースへ伝えるステップとを備える方法、を備えるものである。
【００２２】
(発明の詳細な説明)
本発明の実施形態は、サーバーセキュリティ及び権限付与処理を提供し、セキュリティ及びビジネスロジックプラグインがサーバーをホストとするセキュリティサービスに挿入されることを許し、かつ、そのサーバー上、そのセキュリティドメイン或いはセキュリティ領域内の別のサーバー上、又はセキュリティ領域間に存在する一以上の安全性の確保されたリソースへのアクセスを制御するのに使用されるセキュリティアーキテクチャを含む。セキュリティサービスは、セキュリティ実行及びアクセス権判定における焦点として動作し、かつ、シングルサイン又はセキュリティ実行を考慮して、一つのログイン処理内で使用された情報は、自動的に他のログイン処理にも流通させることができる。
【００２３】
以下で定義される新しい用語を除いて、本文書で使用される用語は、Java、EnterpriseJavaBeans、WebLogicサーバーに関する標準書で定義される専門用語、及びその他一般的に認められているセキュリティ概念と一致するものである。
アクセス制御 - 承認されないリソースの使用を防ぐための、リソースへのアクセス制限
アクセス制御情報(ACI) - リソースへのアクセス要求の発起者についての情報であり、アクセス制御実行の判定を行うために使用される。
アクセス制御リスト(ACL) - リソースにアクセスすることを承認された実体を、それらのアクセス権と共に示すリスト。
承認 - 権限の許可であり、アクセス権に基づくアクセスの許可を含む。
資格 - ユーザー又はその他の主体のセキュリティ属性(識別情報及び/又は特権)を記述する情報。資格は、認証又は権限の委任を通して主張され、かつアクセス制御によって使用される。
権限の委任 - おそらく制限を伴って、一人のユーザーあるいは主体が、他者に、自分の識別情報又は特権を使用する権限を与える行為。
権限の付与 - ある主体に認められた権利または許可。
識別情報 - 一意性を持つセキュリティ属性であり、如何なる二つの主体の識別情報も同一であることはない。主体は、それぞれ一意の、いくつかの異なった種類の識別情報を有する。
主体 - システムのリソースを使用できる能力を持つユーザー、又はあらかじめプログラムされた実体。
役割 - 承認されたユーザーに対する一連の許容される行為を定義する、組織的な識別情報。
役割ベースのアクセス制御(RBAC) - 役割と呼ばれる組織的な識別情報を通じて、リソースへのアクセスを調停するセキュリティ機構のクラス。
セキュリティ属性 - その対象を支配するシステムポリシーの基礎を形成する、対象(ユーザーまたは主体)の特性。
セキュリティポリシー - システムのセキュリティサービスが何の保護を提供しなければならないか、を定義するデータ。アクセス制御ポリシー、検査ポリシー等を含む多数の種類のセキュリティポリシーがある。
サービスプロバイダーインターフェース(SPI) - サービスの一部の具体的な実装をサポートするパッケージ、又は一連のパッケージ。
ターゲット - 権限委任における「呼び出し連鎖」中の、最終受信者。呼び出しの発信者ではない、呼び出し連鎖における唯一の参加者である。
ターゲットオブジェクト - ビジネス要求メッセージの受信者。
信託モデル - もしシステムを安全のまま保つのであれば、システム中のどのコンポーネント及びシステム外のどの実体を信託すべきか、及び何についてそれらを信託すべきか、についての記述。
信託演算処理基盤(TCB) - システムを安全に保持するために、正しく機能すべきシステムの部分。TCBは、耐不正性であることがのぞましく、そのポリシーの実行は妨げられてはならない。
認証されない主体 - 如何なる識別情報又は特権も認証されなかったユーザー、または他の主体。
ユーザー - 自分の代理としてオブジェクトにシステム内で機能を実行させるために、当該オブジェクトに要求を出すようにシステムを利用する人間。
【００２４】
ここで記述される本発明の実施形態は、アクセスに関連して使用される権限付与の判定を可能にしている。典型的には、ユーザーは、サーバー上の保護されたリソースにアクセスしようとする。この保護されたリソースとは、例えば、サーバー上で動作するソフトウェアアプリケーション、特定のウェブページ又はウェブサイトの一部、或いはデータベースシステムである。他の形式の保護されたリソースも、本発明の技術的範囲内である限り使用することができる。ユーザーがリソースにアクセスしようとする時、セキュリティサービスは、アクセス要求の形式、宛先(保護されたリソース)、及び要求が作成された状況を判定する。この情報から、セキュリティサービスは、ユーザーに対する、権限の付与、又は一連の権限付与を判定することができる。権限の付与は、特定のユーザーが特定の状況のもとで特定のリソースを用いて出来ることを、明白に示す。権限の付与は、サーバー提供者が要求するビジネスロジック又は機能を表すのに使用され、それゆえ、単純なセキュリティプラットフォームと複雑なビジネスポリシープラットフォームとの間の隔たりを埋めている。
【００２５】
本発明の実施形態は、さらに、以下のようなアプリケーション形式に保護を提供する第三者ベンダーのセキュリティ製品の統合も考慮に入れる：
・  EnterpeiseJavaBean
・  ウェブアプリケーション(Servlets、JavaServerPages(JSP's))
・  リソース（RemoteMethodInvocation(RMI)、JavaMessagingSystem(JMS)）
【００２６】
本発明の実施形態は、また、以下のような高度な機能をサポートするため、外部公開鍵の構造基盤の統合も考慮に入れる：
・  証明書と鍵の検索
・  証明書の有効化
・  無効化機構(証明書革新リスト(CRL)、オンライン証明書状態プロトコル(OCSP))
【００２７】
本発明を開発するにあたっての重要な目標は、Java2EnterpriseEdition(J2EE)の仕様、及びそれとの間の相互運用性のサポートを含むことである。このJ2EEの仕様の特徴は、共通安全相互運用性(CSI)プロトコル、ユーザー識別トークン、状態なし認証サービス(SAS)プロトコル、マシン、クラスタ、及び/又はドメインの境界間にわたるセキュリティ資格の伝搬のサポート、ポリシーに基づく識別情報の伝搬の制御、仮想ホスト/サイトの高度なサポート、ドメイン範囲内でのユーザー識別情報の生成能力、及びホスト/サイト特有のセキュリティポリシーを含む。
【００２８】
本発明の他の重要な目標は、更新されたSSL能力、ハードウェア加速器、トランスポート層セキュリティ(TLS)プロトコル、セッション再開、証明書認可局、ネットワーク接続の保護、ウェブサーバーのプロキシ、サーバー対サーバー通信、セッションIDの暗号化、及びディレクトリサーバーとの高度な統合、のような機能のサポートを含むことである。
【００２９】
セキュリティドメイン
本発明の状況において使用される、セキュリティ領域又はセキュリティドメインは、一つのサーバー、複数のサーバー、一群のサーバー、又は管理ドメインに及ぶものである。本発明は、セキュリティドメイン内での、セキュリティドメインにわたる、及びセキュリティドメイン間における識別情報伝搬の管理制御を考慮している。クライアントアプリケーション又はユーザーの識別情報は、伝搬され、かつセキュリティドメインによって有効範囲を絞られる。たとえば：
Principal-Identity＠security-domain-name
【００３０】
伝搬が動作不能の時は、手続開始識別情報は発信者不明(アノニマス)として表すことができる。たとえば：
2004533075.tif 000003
【００３１】
フレームワーク
本発明によって提供されるセキュリティアーキテクチャ又はフレームワークは、出された要求及び多数の他の事に対処するよう意図されている。承認要求のみに焦点をあてると、このセキュリティアーキテクチャは、典型的なパーミッションベースの承認に加えて、次のような能力を提供しようと試みる。
【００３２】
動的な役割の関連付け
動的な役割の関連付けとは、役割の主体への関連付けの遅い結合を許す機構、すなわち、主体に権限付与されている機能を判定する間に、要求の状況を考慮に入れることができるようにする機構である。動的な役割の関連付けは、実行時における、主体の役割との遅い結合として考えることもできる。この遅い結合は、主体対役割の関連付けが静的に定義されるか、動的に計算されるかに関わらず、保護されたリソースに対する承認判定の直前に生ずる。呼び出しシーケンスにおける位置付けにより、主体対役割の関連付けについてのどんな結果も、この要求の一部としてなされた何れかの承認判定の一部としての識別情報として、受け取ることが出来る。
【００３３】
静的に定義された関連付けと異なり、主体の役割への関連付けは、実行時に動的に計算される。動的役割の計算は、ターゲットの識別情報(利用可能な場合)、要求のパラメータの値、手続開始主体に関連付けられたプロファイル属性の値、並びに潜在的な他の情報、を含む要求の背景を作り上げる多くの情報にアクセスすることができる。
【００３４】
状況の情報は、典型的には、規則又は式評価エンジンによって評価されることとなる式の中のパラメータ値として利用される。評価エンジンによって提供される機能に依存して、主体が飛んだ距離の大きさのような外部計算を行う外部クラスを呼び出す能力を表現することも可能であり、これはその時、式のパラメータとして使用される。
【００３５】
対象中の主体と動的に関連付けられるべき役割を計算することに加えて、この機能は、また、J2EEで定義された配置記述の使用を通じてか又は管理者によってか、のいずれかで静的に定義された役割を関連付ける任務もある。
【００３６】
この能力の結果は、一実施形態においては、対象に含まれる体が所定の状況及びターゲットを受け取る権限を付与された役割を含む更新されたJAAS Subjectである。これらの役割は、次いで、ビジネスコンテナ及びアプリケーションコードと同様に、保護されたリソース上での何らかの承認判定に利用できる。たとえば、個人向けサーバー、アプリケーションサーバー、又はウェブサーバーは、特定の役割がウェブページを個人向けにする手段として対象によって保持されるか否か、を判定する標準的な方法を利用することが出来る。この機構は、アクセスが許可されるべきか否かを判定するビジネスポリシーの情報を持つことなく、フィールドレベルの承認という結果となる、データベースの記録からフィールドの検索を行うか否かを判定するために、EnterpriseJavaBean又は他のアプリケーションで使用される。
【００３７】
パラメータ承認
パラメータ承認とは、保護されたリソースについての承認判定が、潜在的に要求の状況に基づいてなされることを可能にする機構である。本発明によって提供されるアーキテクチャの範囲内で、その実施範囲は、全ての実行及びリソースコンテナに適用できるまでに拡張された。これは、すべての実行及びリソースコンテナに、セキュリティサービスによって提供されるアクセス制御装置オブジェクトを通して、承認及び役割のマッピングサービスを獲得させることにより、遂行される。このアクセス制御装置は、要求される能力を提供するため、サービスプロバイダーインターフェース(SPI)を通して提供される承認サービスを利用する。
【００３８】
動的な役割の関連付け及びパラメータ承認を提供するのに使用される機構を実際に定義するサービスプロバイダーインターフェースは、権限委任される承認デザインに基づくものであり、これは実行点がアプリケーションサーバー自身の中でなく機能の提供側に移るという結果を生ずる。
【００３９】
さらに、承認フレームワークを備えるサービスプロバイダーインターフェース上で定義される方法は、第三者承認ベンダーによって提供されるサービスとより自然に提携するように設計された実施機構を利用するものである。能力ベース機構の使用は、権限委任される承認手法が、能力ベースとパーミッションベースの両方の実装をサポートすることを可能にする。
【００４０】
従来のセキュリティ機構は、所定のリソースに対して主体に与えられた権限のみに基づくものであるので、状況なしの傾向が強い。それゆえ、なされる承認判定の唯一の形式は、主体がリソースにアクセスするのに必須な権限を持っているか否か、というものである。承認判定のこれらの形式は、ビジネス判定を表そうとするものではないので、より複雑になっている。結果として、この制限を補償するために、付加的なセキュリティチェックがアプリケーションコードの中でしばしば要求される。たとえば、従来の方法を使用することにより、主体が特定の口座にお金を転送することが許されるか否かについて、評価できた。しかしながら、送金の合計、発信元と送信先の両方の口座の通貨、及び曜日を考慮に入れることは不可能である。
【００４１】
本発明に従ったパラメータ承認ベースの機構では、要求の状況を使って承認判定がなされ、それゆえ、その承認判定は、より綿密に現実のビジネス判定を表している。アプリケーション自身の中で、セキュリティチェックを補う必要は殆どない。例えば、実社会の銀行業務の例に本発明を使用すると、誰によって、及びどのような環境下で送金が許されるか否かを管理するビジネスポリシーの処理の一部として、送金の合計、送信元と送信先の両方の口座の通貨、及び曜日を考慮に入れて、承認判定することが可能となる。
【００４２】
状況情報へのアクセス
いくつかの他のシステムが、上で述べたパラメータ承認の記述と同様な機能を提供しようとする一方で、これら先行のシステム及び方法はすべて、呼び出し元に対し、評価されているビジネスポリシーのパラメータについての以前の情報を持つように要求する。この情報への要求は、アプリケーションコード−ビジネスポリシーのある側面の情報の中で承認判定を行う場合と、事実上、全く同じ問題を提示する。他の状況情報を要求するためにビジネスポリシーが変更される度に、アプリケーションは修正かつ再配置されなければならない。
【００４３】
ビジネスポリシーについての以前の情報なしで、状況情報を提供することの問題への対処は、承認プロバイダーからコンテナへの呼び戻しの使用によって遂行される。アプリケーションを根本的に変化させる要求のパラメータの形式又は数の変更が、アプリケーションの再配置を要求する一方で、動的な役割の関連付け及びパラメータ承認プロバイダーの実装が、アプリケーションに0ビジネスポリシー面の以前の情報を持つことを要求することなく、状況情報にアクセスすることが可能となる。
【００４４】
本発明を用いて動作し、かつ承認フレームワークをサポートするように定義されたサービスプロバイダーインターフェース(SPI)は、Java認証及び承認サービス(JAAS)で定義されるのと同様な、標準化された呼び戻し機構を利用することができる。コンテナからサービスプロバイダーインターフェースの実装へ渡される呼び戻し処理ルーチンを利用することで、プロバイダーは特定の状況情報が返されるよう要求できる。コンテナの呼び戻し処理ルーチンが呼ばれると、コンテナは、呼び戻しに適切な値を代入することにより応答する。もしコンテナが、処理ルーチンの中で指定される呼び戻しを理解しない場合には、コンテナは、呼び戻しに値の変更を反映しない。アプリケーションもコンテナもいずれも、特定のビジネスポリシーの式の評価によって導き出される状況情報を問われるものであるため、ビジネスポリシーに対する変更は意識しない。
【００４５】
機能説明
パラメータ承認の要求を満たすのに使用される、権限付与処理エンジン(権限付与エンジン)の実装は、次のような要求をサポートしなければならない：
【００４６】
実装は、ビジネス要求からのパラメータ値、主キー、認証されたユーザーを意味するJAAS対象内の主体からの属性、及び状況の一部と考えられ得るその他の何らかの情報が、規則式の一部として表現されることを明示できるべきである。
【００４７】
実装は、規則の評価によって使用される可能性のある如何なるパラメータ情報も、規則評価の最初に渡されることを要求するのではなく、呼び出し元からオンデマンドで、パラメータ情報を要求できるべきである。情報要求の機構は、JAASにおいて定義されるのと同様な呼び出し形式であるべきである。その実装は、個々の情報それぞれについて呼び戻しを行い、一つの呼び戻しの中で複数の情報を要求する、又はその組み合わせを行う。
【００４８】
実装は、規則評価の一部として呼び出されるJavaクラス名を指定できるべきである。Javaクラスから返される値は、規則式の評価の中で使用される。これは、規則を評価する際に考慮される値を計算するためにユーザー提供のコードが呼び出されるという、マクロ機能として考えられる。たとえば、旅行予約の例では、規則式は、対象によって表される乗客が現在までに飛行したマイル数を計算、又は調べるユーザー提供クラスへの呼び出しを指定することもできる。
【００４９】
一連の規則の評価は、規則が正常に満たされたか否かを示すブーリアン値となるべきである。
【００５０】
本発明は、即座に適応及びカスタマイズできるビジネス機能及びシナリオを可能にするために、配置又は「プラグイン」されるアプリケーションの実装、特にログイン、承認、及び検査実装の範囲内でのフレームワークアーキテクチャを、企業アプリケーション開発者に提供する。
【００５１】
本発明によって提供されるフレームワークアーキテクチャは、開発者(又はユーザー)に見えない、かつセキュリティ処理を付加的に階層化又は変換する必要なく、提供されたセキュリティを企業全体に分散させることができる方法でのこれらセキュリティ機能の利用を大幅に拡張することを除いて、特に、Java開発者が既存のJavaセキュリティ機能を利用することを可能にしている。
【００５２】
本発明の実施形態は、特に、企業及びサーバーセキュリティ、及びビジネスワークフローの分野で役立つ。フレームワークは差し込み可能なアーキテクチャを使用するので、アーキテクチャの中核を修正する必要なく第三者ベンダーがセキュリティ実装のプラグインを提供することを可能にしている。これらのプラグインは、デジタル証明書及びキー検索、証明書の有効化及び無効化機構(例えばCRLやOCSP)のためのツールを含む。差し込み可能なフレームワークアーキテクチャは、それゆえ、EnterpriseJavaBeans(EJB's)、アプリケーション(Servlet及びJSP'sを含む)、及び他のネットワークリソース(例えばRMI,JNDI,JMSの宛先)、のような企業リソースの安全なアクセス制御を考慮に入れる。
【００５３】
さらに、本発明のフレームワークアーキテクチャは、特に、安全な承認、及び企業全体のセキュリティドメイン全域にわたる安全なリソースアクセスの方法を提供するのに適している。ドメインを持つ各サーバーは、異なる一連の機能、サービス、及びアプリケーションを提供する。本発明は、ドメイン全域にわたる又は協調ドメイン間でのクライアントのアクセス権限を判定する一回限定ログオンの機構を通して、各サーバーの特定のサービスを利用することができるクライアントアプリケーションを、開発者が配置することを可能にしている。
【００５４】
図２は、本発明の実施形態に従ったセキュリティアーキテクチャの例を示している。その中に示されるように、クライアント202,204(物理的なハードウェアクライアント、又はソフトウェアアプリケーション)は、トランザクション又はアプリケーションサーバー208を介して、持続的ディレクトリサーバーのような安全性の確保されたサービス又はリソース206にアクセスしようと試みる。そのようなトランザクションサーバーの一例として、カリフォルニア州サンノゼ所在のBEA Systems Inc.によるWeblogicサーバー製品があるが、本発明では、如何なる他のサーバー製品又は等価なシステムを使用することも可能である。インターネットCORBAのクライアントは、典型的には、InternetInter-ORBプロトコル(IIOP)要求212を通じて、そのようなアクセスを試みる。ウェブのクライアントは、典型的には、ウェブサーバー214を介して直接的に、又はプロキシプラグイン216(このケースでは、プロキシはまた、例えばSSL暗号化218のような付加的機能も提供する)を介してのいずれかにより、一連のhttp要求210を通してアクセスを試みる。いかなる場合においても、接続試行は、しばしば最初の接続フィルター220を介して、トランザクションサーバーに受け取られ、そしてセキュリティサービス222に渡される。本発明によれば、セキュリティサービス222は、クライアント及びユーザレベルのリソースアクセス、承認、証明、権限評価、及び権限付与の判定を含む、セキュリティ判定における焦点となる。EnterpriseJavaBeans(EJB's)224、ウェブアプリケーション(WebApp's)226、及び他の形式のアプリケーションはすべて、コンテナの使用を通じて、セキュリティサービスを利用する。図２の場合には、セキュリティサービスは、これらコンテナから保護されたリソースへの呼び出しを処理する。呼び出しは、例えば複数のMBeans230、又はJNDI232によって処理される。
【００５５】
図３は、セキュリティサービスのアーキテクチャ300の実施形態を、非常に詳細に示している。セキュリティサービスは、標準Java2EnterpriseEditionのセキュリティセットにより提供される基本的なセキュリティサービス及び機能を強化するものである。この例に示されるように、基本的なJavaセキュリティセット302は、他との間の、鍵の保管、認証、証明書の有効化、及び安全なソケットのためのセキュリティプロバイダーインターフェース304を含む。顧客アプリケーション306は、Javaセキュリティ層、及びこれらSPI'sを直接利用するように書かれている。本発明は、図3に示すように、これら及び他のセキュリティ機能の利用における、開発者の選択の幅を大幅に広げている。本発明によれば、顧客アプリケーションは、例えばWebAppコンテナ310のEJBコンテナ308のようなコンテナの中に配置される。コンテナは直接、セキュリティサービス314(ここでは、セキュリティサービス222と同じ)と通信し、セキュリティサービス314は、Javaセキュリティ層302及びそのセキュリティSPI's304と、交替で通信する。これは、安全な承認判定に対する責務を、アプリケーションから移し、かつセキュリティサービス層に任せるとを可能にする。
【００５６】
さらに、本発明は、既存のJavaセキュリティSPI's304の使用を、特化されたSPI's316,318と統合するのに理想的である。例えば、接続フィルター、アクセス判定インターフェース、検査チャネル、及び証明書認証者のような付加的SPI'sは、セキュリティサービスに含まれる、又は統合される。セキュリティサービスは、安全な企業リソース全域へのアクセスを調停する。
【００５７】
図４は、アプリケーションが安全なリソースへアクセスするために本発明を使用する過程を示している。ステップ402で、開発者は顧客アプリケーションを作成する。アプリケーションは、実際のユーザーあるいは顧客によって使用されるものとすることができ、又は他のアプリケーションがセキュリティサーバーを利用できるようにするためのアプリケーションインターフェースプログラムとすることもできる。ステップ404で、アプリケーションはコンテナ内部に配置され、その配置過程については、以下でより詳細に開示する。次いで、アプリケーションは、ステップ406において、コンテナを用いてセキュリティサービスにアクセスする。任意で、ステップ408において、セキュリティサービスは、一連のJ2EE準拠のJavaセキュリティ機能と直接、整合性をとることができる。一方、ステップ410では、コンテナは、第三者又はカスタムのセキュリティプロバイダーインターフェースへのアクセスを可能にするのに使用される。ステップ412で、セキュリティプロバイダーインターフェースは、要求されたアクセスが許可されるべきであることをセキュリティサービスが示したのを受けて、アプリケーションが安全なリソースにアクセスすることを許可する。
【００５８】
図５は、コンテナ内部にアプリケーションを配置するのに使用される配置機構の、一実施形態を示している。図５に示すように、データは、アプリケーションコンテナ504による使用のため、セキュリティサービス502(ここでは、セキュリティサービス314と同じ)に登録される。従来的には、コンテナが配置記述506から情報を読み取り、それから実際のコンテナが実行する。もし、WebAppのコンテナ、EJBのコンテナというように、異なる種類のコンテナが存在する場合、異なる実装エンジンである必要がある。さらに、コンテナを持たず、かつ配置説明も持たないJ2EE環境の内部に、一連のリソースが存在する。この方法を用いる一番の問題は、セキュリティの様々な側面が、一つの環境の中で、異なった方法で実行されることである。本発明は、第一に、配置記述子を読み取ったコンテナが、その中で定義されているセキュリティ制限及びポリシーをセキュリティサービスに伝えることを可能にすることにより、この問題に対処するが、これはセキュリティサービス内部のセキュリティポリシーの集団となる。第二に、コンテナは、その後保護されたリソースへのアクセス要求を作成した時には、全ての承認判定をセキュリティサービスに委任し、従って、実行点が、コンテナからセキュリティサービスに移ることになる。配置記述を通して提供される、並びに管理ツールを通して管理者によって定義されるセキュリティ制限及びポリシーを参照することにより、承認判定がなされる。配置ツールは、また、配置記述子を読み取る、及びセキュリティサービス内部に存在するセキュリティ情報を記録するのにも使用される。配置ツールは、次からは、配置記述子を読み取ることなく、直接セキュリティサービスへ向かうことができる。
【００５９】
図６は、アプリケーションの配置の間に、データがセキュリティサービスの中に入り込む過程を示している。ステップ602で、開発者が、配置記述を作成する。その記述は、ステップ604でコンテナに渡され、コンテナは何の情報をセキュリティサービスに渡すべきか評価するため、その情報を解析する。任意で配置記述は配置ツールに与えられることもあり、ステップ606で、配置ツールはその情報をセキュリティサービスに渡す。
【００６０】
図７は、ネットワーク上又はサーバー上の保護されたリソースにアクセスするために、本発明に従ってセキュリティサーバーを使用するクライアントの一例を示している。その処理は、要求を作り出すクライアント702で始まり、これは、自分自身を認証するクライアントという単純な場合の一例である。クライアントは、矢印704で示されるように、コンテナに接続する。トークン706は、要求と共に渡される。接続確立の一部として、システム(セキュリティサーバー710を含む)は、リソース708が保護されているかを判定し、そうであれば、クライアントは認証する必要がある。この例では、トークンは、クライアントの認証されたユーザーを表しており、呼び出し要求の中で順番にコンテナへ渡され、コンテナは、セキュリティサービス呼び出しにおける後のほうのステップで、それらを使用する。いくつかの実施形態では、トークンは、クライアント自身の認証された識別情報を表す。クライアントは、セキュリティサービス712(セキュリティサービス、又はセキュリティサービス314と同じ)に、「このトークンによって識別されるユーザーは、アクセス、及びターゲットリソース上で要求された能力を実行できるか？」という質問714を投げ掛ける。
【００６１】
この質問に答えるために、セキュリティサービスは、図７においてAC716として示されるアクセス制御装置を使用する。AC716は次の２つのことを行う：それは、一連のアクセス判定(AD)プラグイン718,720,722全体に渡って、分散させる端末増設機構として動作し、それはまた判定器としても動作する。ACがアクセス判定を呼び出す時、それは「これはOKですか？」と尋ねながら、最初のアクセス判定718から順番に、トークンを各アクセス判定に回す。アクセス判定は、許可、拒否、又は保留という三つの返答のうちの一つを返す。もし次のアクセス判定があれば、アクセス制御装置は次のものに移る、というように全てのアクセス判定がポーリングされるまで行う。実際には、セキュリティ機構は、一連の窓ガラスのように動作する。もしX718が「許可」といえば、処理は続行する；もしX718が「拒否」といえば、処理は止まる。ACは、次にアクセス判定Y720へ移り、そして全く同じ識別情報を提示しながら、全く同じ質問を尋ねる、そしてY720も同様に、許可、拒否、又は保留で返答する。
【００６２】
この処理は、サービスがこれらプラグインをどれだけ多く有していても、それらに対して続けられる。判断ポリシーは、もし何れか一つが拒否と言えば、処理を終了させる、又は、単に全体拒否を返す、ということを定めている。アーキテクチャは、もしX718が許可、及びY720が拒否、及びC722が保留であるならば許可とみなすような、充分に柔軟な判定を行う判断ポリシーを考慮している。他の実装は、もっと強硬路線を採る：もしどれか拒否するものがあれば、それは全体拒否とする。ACが、アクセス判定に対しアクセス判定が一義的に理解できない質問を尋ね、それゆえ明確な判定をできない時には必ず、保留が返される。これは、従来の承認システムが含まれるときは常に、最も一般的なものであり、全てではないが幾つかの動作、又はX718が企業ポリシーでありかつYがビジネス路線である時に、必要とされる。この場合、ビジネス路線ではなく、企業ポリシーによって実行されるような質問が尋ねられると、ビジネス路線の判定器は「これを理解できない、保留する」と言う。
【００６３】
全てのアクセス判定器がポーリングされ、要求が最後に通過する点までどれも拒否を示さなければ、その時にはアクセス要求はどれも拒否しない、あるものは許可しかつあるものは保留する、例えばY720は保留しかつX718及びC722は両方とも許可、という点に到達する。次に判断ポリシーは、どのように結果を定めるかを制御するために使用することができる。ある一実施形態では、コンテナに対し、許可又は拒否という二つの結果のみがある。そこでアクセス制御装置は、どのようにして判定するかを決める判断ポリシー見る。たとえば、ある場合には、そのボックスの実装より、システムは、「全員一致の許可を要求しますか？」と言う判断ポリシーを使用するが、この場合、X、Y、及びCすべてが許可しなければならない。もしどれか一つでも許可しなければ、結果は拒否となる。その他のアプローチは、全員一致の同意を必要とするものではなく、その場合、どれかが拒否と言わない限り、アクセスは許可される。この判定は、判断ポリシーに基づいてなされる。
【００６４】
アクセス判定の過程の中で何が起きたとしても、セキュリティサービス自身は、何が起きたのか及びその結果の検査を求めて、要求を検査サブシステム724に渡す。その点においてのみ、セキュリティサービスは、コンテナに最終結果が許可又は拒否であるかを教える。もし許可であるなら、コンテナは、要求された操作が保護されたリソースへ送られることを可能にする。もし拒否であるなら、要求はその点まで届かず、即座に拒絶される。
【００６５】
本発明はまた、例えば後述の保護されたリソース上でのアクセス要求の正常な受け取り等、の途中で、アクセス判定過程を呼び出す方法を提供する。このシナリオでは、システムは要求に対する最初のチェックを通過し、かつ全てが許可され、そこでその方法がリソースへ送られたことを前提としている。リソースは、クライアントに戻すデータを返す。ただやみくもに、このデータを返すのではなく、むしろ、承認チェックが再実行され、今度はセキュリティサービス、特にアクセス判定が、そのデータがクライアントに返されるのがOKであるか否かを判定するために、返されるデータを調べる。ここでの一例は、ユーザーがドキュメントを要求しようとするビジネス操作の例である。ユーザーは最初に入るとき、彼らに割り当てられたセキュリティ許可を持ち、それは、ユーザーが、彼らのセキュリティ許可上で機密扱いとされないドキュメントを見ることができることを意味する。もし、彼らが秘密セキュリティ許可のみを持ち、かつ返されるはずのドキュメントが最高機密である場合には、たとえ彼らがそれを実行するための手段を持ち合わせていたとしても、システムは、出力をユーザーに戻すことを許さないが、その理由は、もしそれを許せば、ユーザーは見ることを許されないものを、見ることが可能になってしまうからである。アクセス判定は、今度はユーザーに戻す結果を見直しながら、再実行され、及び同種の判定を行う。この例では、例えばYアクセス判定720が「出力が何であろうと関係ない。入ってくる入力にのみ関心がある」と言うような、多くの保留が存在する。開発者は、ビジネス路線に基づいて、又は企業ポリシーに基づいて、異なるポリシーを実現させるために、プラグインを組み合わせ、及び整合させることができる。
【００６６】
図８は、安全性の確保された、又は保護されたリソースへのアクセスの提供において、本発明の実施形態で使用される過程を示すフローチャートである。ステップ802で、クライアントはコンテナ内部で、アプリケーションを開発し、及び配置する。アプリケーションが保護されたリソースへのアクセスを要求するとき、呼び出しが作成され、ステップ804で示されるように適切なコンテナへ送られる。コンテナは、ステップ806で、セキュリティサービスを呼び出すために使用される。セキュリティサービス内では、ステップ808で、端末増設機構のアクセス制御装置が、この特定のアクセス要求を検証、又は確認するにあたって、どのアクセス判定が起こるべきかを判定する。ステップ810では、各アクセス判定が選択され、及びアクセス要求へのその寄与判定のために処理又はポーリングされ、各アクセス判定の結果は拒否、許可、又は保留となる。検査機構は、ステップ812で、各アクセス判定の結果の跡をたどる。アクセス判定の結果及び累積的な応答--それは許可、拒否、又は保留である--に基づいて、ステップ814では、コンテナは、保護されたリソースへのアクセスを与えられる(又は拒否される)。ステップ816では、データは次に、クライアントアプリケーションから保護されたリソースに、及び、逆に保護されたリソースからクライアントアプリケーションに、渡される。もし、クライアントがその後、同じリソース又は異なるリソース（ステップ818で判定されるように）に対して要求する場合には、その要求は適切なコンテナへ送られ、及び他の承認判定が要求され(ステップ820)、そうでなければ、セッションは終了する(ステップ822)。
【００６７】
図９は、権限付与レイヤー904、及びビジネスアプリケーションレイヤー908に対するその位置付け、ビジネスポリシーレイヤー906及びセキュリティ承認レイヤー902を含む、本発明の一例に従ったセキュリティ及び個人化レイヤーを示している。当業者には、図９に示される説明図が、どのように権限付与レイヤーが開発されるかの概念表現であること、そしてこのアーキテクチャについて多くの他の変形を使用できるということよりもむしろ、このような個々のレイヤーをどれか特定のデザイン実装の中で使用することはできない(実際に殆ど使用されない)ということが、明らかであろう。図９は、権限付与904がどのように、従来のセキュリティアーキテクチャ(902として表現される)と、しばしば別個であるビジネスポリシーアーキテクチャ(906として表現される)との間の境界を越えるのに使用されるか、を示している。このような権限付与の使用を通して添えられる情報は、例えば会社のビジネスアプリケーションを個々の実体のために、その実体の権限付与に基づいて個人化するというような、908として表現される会社のビジネスアプリケーションの実施、を導くために使用される。
【００６８】
図10は、権限付与が、動的に役割を生成するために、どのように使用されるかを示している。権限付与処理1002は、セキュリティの質問がある状況の中で尋ねられることを可能にする。本発明は、その権限付与に基づいて、特定の対象1000、例えば主体１1004、主体２1006から主体ｎ1008までに、動的に役割を割り当てる能力を備え、これはさらに、システムがセキュリティレイヤーの中でアプリケーションの状況を提供することを可能にし、及び承認質問がアプリケーションの観点から表現されることを可能にする。医者と患者の一般的な例のように、質問が状況の観点から表現されるならば、システムはそれらの質問に正確に答えるだけである。もし質問が、「スミス医師は、患者のカルテを修正できますか？」と投げ掛けられたら、それは状況なしの質問である。従来の答えは、「ある時はイエス、及びある時はノー」である。厳密に答えを判定する唯一の方法は、例えばどの患者について話しているのか、あるいはどのカルテについて話しているのかというような、質問が尋ねられた状況を知ることである。システムはその時、所有者のように役割を割り当てる、又は、システムがセキュリティ判定ではなく、むしろビジネス判定を可能とするような、動的な割り当てを基本的に行う。
【００６９】
単純な表記を用いて、この概念を次のように表現することができる：
各対象において、アクティブな役割ARは、その対象が現在使用しているものである：
AR(s:対象)＝{対象sにおけるアクティブな役割}
各対象は、一以上の承認された役割RAと関連付けられる：
RA(s:対象)＝{対象sについて承認された役割}
各役割は、一以上のタスクTAを実行するために、承認される：
TA(r:役割)＝{役割rについて承認されたタスク}
もし述語関数exec(s,t)が、現在の値で、時間内に、現時点で真であるならば、対象はタスクを実行する：
2004533075.tif 000004
【００７０】
上記の記述が正しく評価を行うために、一組のルールが要求される：
1.役割割り当て  -  役割を割り当てられた場合のみ、対象はトランザクションを実行することができる。システム上で実行される全ての他の動作はタスクを通して行われるが、識別及び認証の過程はタスクの一部と見なされない：
2004533075.tif 000005
2.役割承認  -  ある対象のアクティブな役割は、その対象について承認されなければならない。このルールは、ユーザーが承認された役割のみを引き受けることができることを、保証するものである：
2004533075.tif 000006
3.タスク承認  -  対象は、タスクがその対象のアクティブな役割について承認された場合のみ、そのタスクを実行することができる：
2004533075.tif 000007
【００７１】
別の例として、開発者が、ユーザーに権限付与されている事に基づいてウェブページを個人化するために、本発明を使用することができる。たとえば、自己登録又は自己支援機能は、クレジットカードのウェブページの一部とされることが可能であり、そこではユーザーが、クレジットカードナンバーを変更することができる唯一の者である。ベンダーは、それらを読むことは出来るが、変更することはできない、また他の誰もそれらを見ることは出来ない。システムは、その状況を知らなければ、これをどのようにして行うか解らない。誰かクレジットカードフィールドを修正することができるか？もちろん、誰かはクレジットカードフィールドを修正することができる。ではそれならば、誰がそれを修正することができるのか？如何なるメンバーも、他のメンバーのクレジットカードを修正することは許されないので、その時システムは、どの特定の一人であるか尋ねなければならない。そのためシステムは、どのオブジェクト及びどのプロファイルが審議中であるか、を知らなければならず、そこで「あなたは、そのプロファイルの所有者ですか？」と尋ねる。従来は、定義される唯一の事が、静的な役割であった。本発明は、権限付与の利用を通じて、ビジネスアナリスト及びビジネスポリシー作成者が、オブジェクト又は主体の識別情報を定義するために、実行時に計算される動的役割を定義することを可能にする。これらの役割は、サーバーアーキテクチャの基礎となっているセキュリティ仕様に違反しない。例えば、要求は、所有者の役割として登録された呼出元となることもできる。システムは所有者の役割を定義しないが、しかし所有者の役割は動的にユーザーと関連付けられることが可能であり、及びユーザーがもはや所有者ではないという何らかの行為を行うや否や、ユーザーから無効とさせることもできる。EJBのような技法は、何らかの行為を行うために、その使用が許されるべきかどうかという事が、あなたがその役割にあるか否かということに基づき、かつあなたがこの可能性を問い合わせるために標準EJBを使用する、という点でこれを利用することができる。
【００７２】
本発明がどのように使用されるかの他の例は、一回限定ログオン機構の設備を通じたものであり、これは従来のセキュリティ実装の要素と、ビジネスポリシー実装の要素を組み合わせるものである。図11に示されるように、第一のセキュリティ領域Ａ1102、例えば第三者アプリケーションによって提供され、及びユーザープロファイル又は企業のビジネスポリシーの情報を全く持たないセキュリティ領域での、最初のログイン処理の間に受け取られた情報は、第一のログインモジュール1108によって取り込まれ、及び第二のセキュリティ領域1104の中にある二番目のログインモジュール1110に渡される（矢印1104で示されるように）。第二のセキュリティ領域Ｂ1104は、ビジネスポリシーの情報を持ち、かつ元のログイン情報に加えて、ユーザーに対する権限付与又は権限付与プロファイル1102を判定又は計算することができる。元のログイン情報及び権限付与情報は、第三のセキュリティ領域Ｃ1106の中にある三番目のログインモジュール1112に渡される(それぞれ、矢印1108及び矢印1120で示されるように)、というように続く。
【００７３】
セキュリティプロバイダーインターフェース
本発明と共に使用されるセキュリティプロバイダーインターフェース(SPI)は、次に挙げるものについてのインターフェースを含む：
・認証  -  Java認証及び承認サービス(JASS)ログインモジュール
・承認  -  アクセス判定
・検査  -  検査チャネル
・主体-＞役割マッピング  -  JAASログインモジュール
・主体-＞証明マッピング  -  JAASログインモジュール
・鍵記憶装置  -  Java2鍵保管Spi
・証明書検索及び無効化  -  Certパス
・証明書マッピング  -  Cert認証装置
・ハードウェア加速器  -  Java暗号化拡張
・周辺保護  -  接続フィルター
【００７４】
ここで記述されるSPIは、本発明と共に使用されるインターフェースの形式の単なる例にすぎず、かつ本発明によって提供されるセキュリティサービスアーキテクチャの柔軟性を説明する目的でここに列挙されたものであることは、当業者には明白であろう。本発明の技術的範囲内である限り、他の形式のインターフェースが、ここで記述されるインターフェースと置き換えられる、又は強化するということも可能である。
【００７５】
認証SPI
本発明で使用されるJAASログインモジュールは、標準JAASログインモジュールに基づくものであるが、しかしさらに、標準ログインモジュールの実装をサポートする。認証SPIは、ユーザー、グループの管理をサポートし、及び複数のJAASログインモジュールのサポートを提供するまでに、拡張される。資格は、ログインモジュールのインスタンス全体で共有され、かつユーザープロファイル情報を用いて更新する個々のログインモジュールが提供される。認証SPIの任務は、セキュリティ領域範囲及び、JAAS対象内の主体群に基づくユーザー認証を含む。
【００７６】
承認SPI
承認SPIはアクセス判定に備えるものであるが、これに対応するJavaの全くの等価物は存在しない。承認SPIは、宣言及びルールの両方をベースとした、様々な承認モデルをサポートする。呼び戻し処理装置は、呼び出し状況へのアクセスを獲得するために使用される。SPIはまた、主体の識別情報、グループの帰属資格、及び役割割り当てといった対象情報、及びユーザープロファイル情報(任意)へのアクセスを提供する。多重アクセス判定プロバイダーは、スタックの中で構築される。承認SPIの任務は、許可、拒否、又は保留の承認判定を行うこと、又はアプリケーションの適用範囲内である保護されたリソースへのアクセス要求を作成することを含む。図11は、ドメイン内のセキュリティ領域間に、プロファイル情報を分散させるために、本発明がどのように使用されるか、一例を示している。
【００７７】
検査SPI
検査SPIは検査チャネルを含むものであるが、これに対するJavaの等価物は何も定義されていない。呼び戻し処理装置は、対象情報、主体の識別情報、グループの帰属資格、及び役割割り当てへのアクセス、及びユーザープロファイル情報(任意)を含む呼び出し状況へのアクセスを獲得するために使用される。再度、多重検査チャネルプロバイダーがスタックの中で構築される。検査SPIの任務は、情報が検査されるべきか否かを判定することと、及びQoSポリシーに基づいてデータの実際の検査を行うことを含む。
【００７８】
主体−＞役割マッピングSPI
主体−＞役割マッピング(JAASログインモジュール)SPIは、JAASログインモジュールに基づくものであり、かつ、役割を動的に、対象内に含まれる主体の識別情報にマッピングするために使用される。役割は、管理者によって、又は配置記述子から明確に定義されたもの、又はビジネス要求のパラメータ、主体のプロファイル中の属性値、並びにその他の条件に基づいて動的に計算されるものである。
【００７９】
主体−＞証明マッピングSPI
主体−＞証明マッピング(JAASログインモジュール)SPIは、JAASログインモジュールに基づくものであり、かつセキュリティドメインポリシー又はセキュリティドメイン技術の境界を越える時に、主体の識別情報をマッピングするために使用される。主体マッピングSPIの任務は、提供された対象に基づくものであり、かつユーザー名/パスワードにおけるパスワード証明、及びトークン形式の証明における汎用的証明のような、適切な情報を有する公的証明を対象に付加するために使用される。
【００８０】
鍵記憶装置SPI
Java2鍵保管SPIは、Java2鍵保管インターフェースに基づくものであり、かつファイルベースの媒体:(PKCS #5/#8, PKCS #12)、HSMベースの媒体:(PKCS #11)、スマートカード/Javaカードといった様々な媒体内に保管される鍵への一貫したアクセスを提供する。鍵保管SPIは、暗号署名に必須なサポートを提供し、かつその任務は、保護されたリソースからの秘密鍵検索、及び保護された記憶装置からの機密検索を含む。
【００８１】
証明書検索SPI
証明書検索SPI(Certパス)はJSR55に基づくものであり、かつ複数の証明書形式のサポートのほか、デジタル証明書の検索、検証、及び無効化のための一貫した機構を提供する。
CertパスSPIの機能は、次のことを含む：
Cert保管:問い合わせを介して、記憶装置から証明書の検索；
Certパス：Cert保管を利用した、証明書の連鎖の検索；
Certパスチェッカー：証明書を確認する；
Certパス確認装置：証明書の連鎖を確認する
【００８２】
証明書マッピングSPI
証明書マッピングSPI(Cert認証装置)についてJavaの等価物は定義されていないが、この証明書マッピングSPIは、セキュリティドメイン内での、デジタル証明書と主体識別情報との間のマッピングを可能にするための拡張可能な方法を提供する。それはさらに、Cert認証装置の呼び出しの前に実行される、検証及び無効化のチェックを提供する。
証明書マッピングSPIの任務は、検証されたクライアントのデジタル証明書に基づくものであり、それをユーザー名及び主体領域にマッピングする。
【００８３】
ハードウェア加速器SPI
ハードウェア加速器SPIはJava暗号化拡張を使用し、かつJava2セキュリティアーキテクチャに基づくものである。その任務は、セキュリティサービスの制御下で暗号化サービスを提供することを含む。
【００８４】
周辺保護SPI
周辺保護SPIは、組込みの接続フィルターの実装を提供するための接続フィルターを含む。これは使い易さに的が絞られ、かつMbeansを介してコンソールから設定できるものであり、それぞれ順番に実行されるユーザー作成フィルター、及び縦続接続フィルターの継続したサポートを可能とする。これは、顧客が運用しなけれならない条件を最小化するものである。
【００８５】
セキュリティ管理SPI
セキュリティ管理SPIは、第三者ベンダーのコンソールを、サーバーコンソールに統合させ、及びセキュリティが、これらベンダーからサーブレットへ転送することを可能にする。セキュリティ管理SPIは、ユーザー、グループ、役割、及び承認情報の完全なライフサイクルのサポートを提供する。
【００８６】
一回限定ログオン(SSO)SPI
一回限定ログオンSPIは、手続開始主体の識別情報からリソース識別情報へのマッピングを行い、及びリソース証明の安全な記憶領域を提供するために、ログインモジュールを使用する。
【００８７】
本発明のより好ましい実施形態についての上述の説明は、例証及び説明の目的のために提供されたものである。それは網羅的なもの、又は本発明を開示された厳密な形態に限定しようとするものではない。多くの修正及び変更が、当業者には明らかになることが明白であろう。本実施形態は、本発明の原理、及びその実用例を最もよく説明するために選択され、かつ記述されたものであり、それによって当業者は、意図された個別の利用に適した様々な実施形態における、及び様々な修正を伴った本発明を理解することができる。本発明の技術的範囲は、次に述べる特許請求の範囲及びその均等技術によって、定められるものである。
【図面の簡単な説明】
【００８８】
【図１】従来の技術知識に従った、クライアント/サーバーのアーキテクチャの説明図を示している。
【図２】本発明に従った、クライアント/サーバーのアーキテクチャの説明図を示している。
【図３】本発明に従った、セキュリティサービスの説明図を示している。
【図４】本発明に従った、セキュリティサービスで使用される方法のフローチャートを示している。
【図５】本発明に従った、サーバーセキュリティの配置ツール及び処理の説明図を示している。
【図６】本発明に従った、サーバーセキュリティの配置ツールで使用される方法のフローチャートを示している。
【図７】本発明に従った、セキュリティサービス及び保護されたリソースの説明図を示している。
【図８】本発明に従った、保護されたリソースへのアクセスを許可するためにセキュリティサービスで使用される方法のフローチャートを示している。
【図９】本発明の実施形態に従った、セキュリティレイヤーの説明図を示している。
【図１０】本発明の実施形態に従った、権限付与の機構の説明図を示している。
【図１１】本発明に従った、いくつかのセキュリティドメインわたるログインの説明図を示している。
【図１】
2004533075.tif 000008
【図２】
2004533075.tif 000009
【図３】
2004533075.tif 000010
【図４】
2004533075.tif 000011
【図５】
2004533075.tif 000012
【図６】
2004533075.tif 000013
【図７】
2004533075.tif 000014
【図８】
2004533075.tif 000015
【図９】
2004533075.tif 000016
【図１０】
2004533075.tif 000017
【図１１】
2004533075.tif 000018
【国際公開パンフレット】
2004533075.tif 000019
2004533075.tif 000020
2004533075.tif 000021
2004533075.tif 000022
2004533075.tif 000023
2004533075.tif 000024
2004533075.tif 000025
2004533075.tif 000026
2004533075.tif 000027
2004533075.tif 000028
2004533075.tif 000029
2004533075.tif 000030
2004533075.tif 000031
2004533075.tif 000032
2004533075.tif 000033
2004533075.tif 000034
2004533075.tif 000035
2004533075.tif 000036
2004533075.tif 000037
2004533075.tif 000038
2004533075.tif 000039
2004533075.tif 000040
2004533075.tif 000041
2004533075.tif 000042
2004533075.tif 000043
2004533075.tif 000044
2004533075.tif 000045
2004533075.tif 000046
2004533075.tif 000047
2004533075.tif 000048
2004533075.tif 000049
2004533075.tif 000050
2004533075.tif 000051
2004533075.tif 000052
2004533075.tif 000053
2004533075.tif 000054
2004533075.tif 000055
2004533075.tif 000056
2004533075.tif 000057
2004533075.tif 000058
2004533075.tif 000059
2004533075.tif 000060
2004533075.tif 000061
2004533075.tif 000062
2004533075.tif 000063
2004533075.tif 000064
2004533075.tif 000065
2004533075.tif 000066
2004533075.tif 000067
2004533075.tif 000068
【国際調査報告】
2004533075.tif 000069