JP4164855B2 - プラグ対応認可システムに対するサーバサポート方法およびシステム - Google Patents

Description

本発明は、一般的にコンピュータネットワークセキュリティに関し、特にアクセス制御フレームワークの状況内で確保されたシステムリソースにアクセスする技術に関する。

情報技術（ＩＴ）システムおよびインタネットは現在のグローバル経済成長の原動力となってきた。ＩＴシステムには特筆すべき利点があるが、同時に未認可の第三者からセキュリティ上の脅威を被る可能性を秘めている。実際に、現代のＩＴシステムにおけるセキュリティの欠如は、グローバルコンピュータネットワークの保全性を脅かすものとして浮上している。この問題に対処するため、ＩＴシステムは、データ認証、データの機密保持、主体認証および認可等、多数の既知サービスを提供している。データ認証は、一般的に二つのサブサービスからなる。すなわち、データ保全サービスおよびデータの出所認証サービスである。データ保全サービスは、所定データの受信者に対し、転送中該データに変更がなかったことを証明するために用いられる。データの出所認証は真の発信者の身元を受信者に対して示すものである。データの機密保持は送信中にデータが開示されるのを防ぐ。主体認証は、ある主体が主張しているその主体であることの証明を該システムに与える。認可は、認証された主体がある行為を実行する権利があるかどうかを判断するものである。認可および認証はこのように関連したサービスである。権限認可を提供できるようにするため、誰がその主体であるかを（例えば主体認証によって）判断する必要がある。一般的に、認可は二つの独立した段階からなる。すなわち、ある特定の主体に対して特権（認定信任）を与える段階と、これら特権と該リソースのアクセス判定ルールとを組み合わせて、該主体に対してアクセスを許可すべきかどうかを判断する段階とからなる。

多くのサーバが（オープングループの分散コンピューティング環境、すなわちＤＣＥ等）時代遅れになってしまった認可システムを利用しており、ロールベースの承認および資格授与等、新しい認可システム技術を活用していない。この認可システムもまた時代遅れになるかもしれない。なぜならば、アプリケーションは特定プロダクト向け認可ＡＰＩを使用する必要があるためだ。一方、オープングループは標準的な認可（ＡＺＮ）ＡＰＩのための技術仕様、すなわち、規格に準拠する任意のシステムやアプリケーションとインタフェースをとることができるオープングループの技術標準規格Ｃ９０８を普及させてきた。

現在、新しい認可技術および標準認可ＡＰＩを活用する新しい認可システムが市販されている。一例がＩＢＭのポリシーディレクタ（Ｐｏｌｉｃｙ Ｄｉｒｅｃｔｏｒ）である。サーバアプリケーションの開発者はこのような新しい認可システムの使用を望んでいる。なぜならば、これら認可システムは、サーバアプリケーションが新しい認可技術を活用し、必要に応じて同一規格の認可ＡＰＩを使用する他の認可システムへの接続（プラグイン）を可能にする。従来これは実用的ではなかった。

新しい認可ＡＰＩに対してレガシーアプリケーションをアップグレードすることは困難なだけではなく費用もかかる。有効な解決策はレガシーアプリケーションの大規模な再符号化とテストを要するが、これは費用がかかるだけではなく、レガシーアプリケーションを変更するのに必要な技量が即座に得られない場合には不可能である。それゆえ、企業の管理者が既存のレガシーアプリケーションを保持する必要がある場合、アプリケーションを新しい認可システムへとアップグレードする際、両方の認可システムによって使用されるデータベースをサポートするよう要求されるようなら、管理者はいずれのアプリケーションもアップグレードしたくないと考えるかもしれない。

例えば、管理者がＤＣＥ認可システムに基づく既存のサーバアプリケーションを維持するとする。このアプリケーションは、ＤＣＥベースの認可システムによって使用されるデータベースのみならず、（"dce_acl_is_client_authorized"という呼び出しとして了解する)サーバ上にＤＣＥインタフェースを保持するよう管理者に要求する。ここで、管理者が認可システムとしてＩＢＭのポリシーディレクタを利用する新しいサーバアプリケーションの追加を望んでいるとする。この場合、標準認可ＡＰＩおよびＤＣＥベースの認可システムの双方に対する呼び出しが了解される必要があるため、管理者は、サーバへのＤＣＥインタフェースのみならず、ポリシーディレクタ用インタフェースも維持するよう求められる。また、管理者は、両認可システムによって要求される認可データベースを維持することも求められる。

それゆえ、レガシーアプリケーションを変更することなく新しい認可システムをプラグインする方法論を提供することは有利である。

レガシーアプリケーションが認可ＡＰＩおよびレガシー認可システムのバックエンドリモートインタフェースを利用できるように新しい認可システムをプラグインするための方法、システム、装置およびコンピュータプログラムプロダクトを提示する。レガシーアプリケーションがレガシー認可システム内のルーチンに対して呼び出しを行うと、その呼び出しは転送され新たに配備された認可システムのＡＰＩに適した呼び出しを行う。

例えば、レガシーＤＣＥ認可システムにおいて、ＤＣＥリモートＡＣＬ（ｒｄａｃ１）に明示されたバックエンドルーチンを呼び出すＤＣＥ ＡＰＩを用いた管理アプリケーションを利用することにより、管理者はオブジェクトについてのアクセス制御リスト（ＡＣＬ）を構成することができる。ＡＣＬが構成された後、ＤＣＥベースのサーバアプリケーションはＤＣＥ ＡＰＩ（例えば、dce_ac１_is_client_authorizedと名付けられたＡＰＩ）を呼び出すことによりクライアントのアクセス権を判断することができる。

このレガシー認可モデルはアップグレードでき、リモートＡＣLバックエンドルーチンの新規セットと新しいＤＣＥ ＡＰＩを配備することにより、新しい認可システムをコンピュータの使用環境に接続することを可能にする。新しい認可システムを利用するようにサーバが構成されると、リモートＡＣＬルーチンおよび新しいＤＣＥ ＡＰＩが新しい認可システムで必要なＡＰＩを呼び出す。

以上、本発明により関連のあるオブジェクトおよび特徴をいくつか概略した。これらのオブジェクトは、本発明のより重要な特徴および応用の一部の単なる実例として構築されるべきものである。開示発明を異なる方法で適用したり、あるいは後述するように本発明を変更することにより、その他多くの有益な結果を得ることができる。したがって、他のオブジェクトおよび本発明のより完全な理解は、以下の「発明を実施するための最良の形態」を参照することにより得られるだろう。

以下図面を参照して説明する。図１はデータ処理システムの典型的なネットワークを表す。分散データ処理システム１００はネットワーク１０２を含む。ネットワーク１０２は、分散データ処理システム１００内で互いに接続する様々な装置およびコンピュータ間の通信リンクを提供するのに利用できる媒体である。ネットワーク１０２は、ワイヤや光ファイバケーブル等の永久接続や、電話や無線通信を介した一時的接続のいずれを含んでいてもよい。例えば、ネットワーク１０２はインタネットを含んでいてもよい。図示の例では、サーバ１０４−１１０が記憶ユニット１１２と共にネットワーク１０２に接続されている。また、クライアント１１４−１１８もネットワーク１０２に接続されている。

本発明は様々なハードウェアプラットフォーム上で実現できる。図１は非均質計算環境の一例であり、本発明に対する構成上の制限を表すものではない。ネットワークに接続されたデータ処理システムは、メインフレームコンピュータ、パーソナルコンピュータ、携帯情報端末（ＰＤＡ）等、様々な電算装置によって表される。分散データ処理システム１００は、図示していない更なるサーバ、クライアント、ルータおよびその他装置を備えていてもよい。

図２に関して説明すると、図１に示すようなデータ処理システムの典型的なコンピュータアーキテクチャを表す図である。データ処理システム１２０は内部システムバス１２３に接続された１つ以上の中央演算処理装置（ＣＰＵ）１２２を含む。システムバス１２３は、ランダムアクセスメモリ（ＲＡＭ）１２４および読み出し専用メモリ（ＲＯＭ）１２６と、プリンタ１３０、ディスクユニット１３２、あるいはサウンドシステム等図示しない他の装置等、様々な入出力装置をサポートする入出力アダプタ１２８とを相互接続する。また、システムバス１２３は、通信リンク１３６にアクセスする通信アダプタ１３４も接続する。ユーザインタフェースアダプタ１４８は、キーボード１４０およびマウス１４２、あるいはスタイラス、マイクロホン等の図示しないその他装置等、様々なユーザ装置を接続する。ディスプレイアダプタ１４４はシステムバス１２３をディスプレイ装置１４６に接続する。

図２のハードウェアがシステム実装に応じて変わる可能性があることを当業者なら理解するであろう。例えば、システムが１つ以上のプロセッサおよび複数種類の不揮発性メモリを有していてもよい。また、図２に表されたハードウェアに加えて、あるいはそれに代えてその他の周辺装置を用いてもよい。すなわち、当業者は、ネットワークアクセス可能な電話機やデスクトップワークステーション内で類似要素やアーキテクチャを見出すことを期待しているわけではない。図示の例は本発明に関して構成上の制限を示すものではない。

様々なハードウェアプラットフォームで実現できることに加え、本発明は様々なソフトウェア環境においても実現可能である。典型的なオペレーティングシステムを用いて各データ処理システム内でプログラムの実行を制御してもよい。例えば、ある装置はＵＮＩＸ（Ｒ）オペレーティングシステムを走らせ、他の装置にはＭｉｃｒｏｓｏｆｔ（Ｒ）Ｗｉｎｄｏｗｓ（Ｒ）オペレーティングシステム環境が入っているかもしれない。

本発明は、上述したように、様々なハードウェアおよびソフトウェアプラットフォーム上で実現され得る。しかしながら、より具体的には、本発明はレガシーアプリケーションおよびプラグ対応認可システムと共に用いられる認可フレームワークの提供に向けられたものである。本発明をより詳細に説明する前に、背景として、既成の標準的な認可システムおよび典型的なレガシー認可フレームワークを示す。

図３に関して説明すると、既成のアクセス制御の方法論を表すブロック図である。周知の通り、アクセス制御は、未認可でのリソースの利用の防止を含むリソースの不正使用の防止に関係する。認可機能を提供する標準的なアクセス管理フレームワークは、"Access Control Framework"というタイトルがついたＩＳＯの１０１８１−３標準規格（国際標準化機構、"InformationRetrieval, Transfer and Management for OSI: Access Control Framework," ISO／IECJTC １／SC ２１／WG １ N６９４７, Second CD 10181-3、１９９２年５月）において規定されてきた。

図３は、ＩＳＯの１０１８１−３のアクセス制御フレームワーク内でアクセスリクエストに関係する構成要素の４つの確定した基本的役割を示す。すなわち、イニシエータ１５０、ターゲット１５２、アクセス制御実施（エンフォースメント）機能（ＡＥＦ）１５４およびアクセス制御判定機能（ＡＤＦ）１５６である。イニシエータ１５０はアクセスリクエストを提出し、制御または保護されたリソースへのアクセスを得る。１つのイニシエータは一主体である。例えば、個人ユーザやコンピュータベースの主体等であり、他の主体にアクセスしようと試みる。試みられるアクセスの一部をなす操作およびオペランドを含むアクセスリクエストは、アクセスされる可能性のある任意の主体としてのターゲット１５２に対して実行されるある操作を特定する。操作は、イニシエータのアクセスリクエストが保護リソースに対して実行されたことを照会する任意の動作である。アクセス制御実施機能１５４はアクセスリクエストを仲介する。特に、あるＡＥＦ１５４はアクセス制御判定機能１５６に対して判定リクエストを提出する。このように、判定リクエストは、ＡＥＦ１５４がＡＤＦ１５６に送信し、特定アクセスリクエストを許可すべきか拒絶すべきかを尋ねるメッセージである。そして、ＡＤＦ１５６は、保護された、あるいは確保されたリソースに対するアクセスリクエストを許可すべきか拒絶すべきかを決定する。リソースは、データ処理システム内におけるアプリケーション、データ、ソフトウェアコンポーネント、ハードウェアコンポーネント、またはシステムやその他ソフトウェア・ハードウェア製品の計算値である。

前述したようなアクセス制御フレームワークにおいて、認証機能はあるシステム主体によって、あるいはそれに対して請求された身元を検証するプロセスを参照する。そして認可機能は、ユーザやプログラム等の対象に対してアクセス権を与えるプロセスを参照する。特定イニシエータがアクセス権を有するかどうかは、通常１つ以上の所謂特権属性によって判断される。特権属性はイニシエータに関連する属性であり、保護リソースの制御属性に対してマッチングした場合、該特権属性を用いて保護リソースに対するアクセスの許可あるいは拒絶が行われる。代表的な特権属性はグループメンバーシップや役割の許可上限（クリアランス）等である。

図４に関して説明すると、既成の標準的な認可アーキテクチャを表すブロック図である。以下さらに詳述するように、本発明は、レガシーアプリケーションに対して何ら変更を加えることなく、レガシーアプリケーションが標準的な認可権限を活用するのを可能にする。図４は、認可（ＡＺＮ）ＡＰＩに対するオープングループの技術標準規格Ｃ９０８に準拠する認可サービスを表す。該オープングループの技術標準規格Ｃ９０８はそれ自身ＩＳＯの１０１８１−３標準規格に準拠している。

図４において、認可サービスは、高信頼コンピューティング基盤（ＴＣＢ）２００における認可ドメインすなわち「信用」ドメイン内で動作する。認可権限は、ターゲット２０２に対して他の使用に関しては認可されている可能性のある主体による該リソースに対する不正使用の防止を含め、ターゲット２０２等保護リソースの不正使用を防止するのに用いられる。人間あるいはコンピュータベースの主体であるイニシエータ２０４は、ターゲット２０２に対するアクセスを要求する。認可権限は、特権属性証明書（ＰＡＣ）サービス２１０、信任取得サービス（ＣＡＳ）２１２、資格授与サービス２１３および所定のアクセス制御判定機能（ＡＤＦ）２１４によって提供される認可サービスから認証サービス２０６（およびそれに関連した認証機構２０８）を分離するのに役立つアクセス制御（すなわち、認可または”ａｚｎ”)アプリケーションプログラミングインターフェイス２０５を構成する。同時に、認可ＡＰＩ２０５、ＣＡＳ２１２、ＰＡＣサービス２１０、資格授与サービス２１３およびＡＤＦ２１４は認可サービス２１５を構成する。

認証サービス２０６および認証機構２０８が認可権限の一部である必要はない。実例としての実施例において、認証サービス２０６はケルベロス認証、公開鍵認証、あるいはいずれか他の既成認証手法を実行し、トークン信号またはユーザＩＤを表すその他データ構成を返す。なお、認証の特定タイプは本発明の一部をなすものではない。

ＡＤＦ２１４は専門分野に特化した機能であり、所定の情報に基づきアクセス制御方針のルールをアクセスリクエストに適用することによりアクセス制御判定を行う。アクセス制御方針のルールはアクセス制御方針リポジトリ（収納庫）２２４に格納されている。ＣＡＳ２１２は認証サービス２０６によって認証されたイニシエータについての情報を用い、特権属性リポジトリすなわちデータベース２１８におけるイニシエータの特権属性を調べる。

特権属性はイニシエータに関連する属性であり、保護リソースの制御属性に対してマッチングした場合、その保護リソースに対するアクセスを許可または拒絶するために用いられる。信任証は、イニシエータの特権属性の内部表現を含む認可ＡＰＩ２０５によって維持された内部構成である。イニシエータの特権属性の外部表現は特権属性証明書すなわち”ＰＡＣ”である。このように、ＰＡＣはそれを生成した当局によって署名される可能性のある特権属性を含むデータ構成である。ＰＡＣはＰＡＣサービス２１０によって必要とされる場合に作成される。

企業の管理者は、特権マネージャ２２０を用いて特権属性を設定、管理できる。特権マネージャ２２０は、管理者が所定ユーザの素性に割り当てられる認可属性に対する組織の観点を定義できるようにするインタフェースである。また、企業の管理者は、ポリシーマネージャ２２２を用いてアクセス制御方針のルールを設定、管理できる。ポリシーマネージャ２２２は、管理者がＡＤＦ２１４を作成し組織の認可方針を定義、管理できるようにするインタフェースである。これらアクセス方針はアクセス制御方針リポジトリ２２４に格納される。マネージャ２２０および２２２は、各々固有の表示メニュと、属性または方針データの定義および管理を促進する制御手段を有するコンピュータインタフェースである。

必要に応じて、認可サービス２１５はアクセス制御実施機能（ＡＥＦ）２１６によって参照される。ＡＥＦ２１６は専門分野に特化した機能であり、所定のアクセス制御リクエストに関するイニシエータ２０４およびターゲット２０２間のアクセス経路の一部をなす。図３に関して説明したように、ＡＥＦ２１６はＡＤＦ２１４によってなされた決定を実施する。

望ましくは、図４に示す構成要素は以下の信頼関係を有する。すなわち、ターゲットリソース２０２のオーナはＡＥＦ２１６を当てにする。これは、高信頼コンピューティング基盤２００内の認証および認可サービスが未認可のイニシエータによるターゲットに対するアクセスを防止することへの信頼を暗示している。また、認証サービス２０６は、その認証機構２０８が正しく機能しイニシエータ２０４に対して正しい身元保証を与えるものと信用する。ＡＥＦ２１６は、認証サービス２０６が（したがって、暗示的にその認証機構２０８が）イニシエータ２０４に対して正しく認証された身元保証を与えるものと信用する。

認可ＡＰＩ２０５は、ＡＥＦ２１６が正しいアクセス制御情報すなわち”ＡＣＬ”を提供するものと信用する。該アクセス制御情報はアクセス制御目的に使用される任意の情報であり、状況（文脈）上の情報を含む。相補的に、ＡEＦ２１６はＡＰＩ２０５が、そして暗示的に認可サービス２１５が、正しいアクセス判定をして正しいＰＡＣおよび特権属性を返送するものと信用する。また、認可ＡＰＩ２０５は、そのＣＡＳが（そしてその基礎をなす特権属性リポジトリ２１８が）信任を表すものとしてイニシエータの身元を正しく解釈するものと信用する。さらに、認可ＡＰＩ２０５はＰＡＣサービス２１０が信任証から正しくＰＡＣを生成し、信任の特権属性を正しく返送するものと信用する。そして、認可ＡＰＩ２０５およびＰＡＣサービス２１０は、特権属性リポジトリ２１８が正しい情報を含んでいるものと信用する。さらに、認可ＡＰＩ２０５は、認可サービスのＡＤＦ２１４が（そして、その基礎をなすアクセス制御方針リポジトリ２２４が）正しいアクセス判定をするものと信用する。

認可サービス内で実現される可能性のある機能の一例として、以下の表は標準的な認可ＡＰＩによって提供される機能群を記載すると共に、各機能群が何をするのかを簡単に説明する。

図５に関して説明すると、既成のレガシー認可システムを表すブロック図である。この例において、レガシー認可システムは、以下のようにしてイニシエータにターゲットへのアクセス許可を与えるＤＣＥ認可システムである。しかしながら、他の認可システムもレガシー認可システムの一例として用いることができることに留意する必要がある。例えば、Ｍｉｃｒｏｓｏｆｔ（Ｒ）Ｗｉｎｄｏｗｓ（Ｒ）２０００オペレーティングシステムもＤＣＥ認可サービスと同様に認可サービスを行う。

イニシエータ３００はＤＣＥログインＡＰＩ３０２を呼び出す。それに応じ、ＤＣＥログインＡＰＩが３つのステップを実行する。第一のステップとして、ＤＣＥ認証システムを用い、ＤＣＥログインＡＰＩがＤＣＥケルベロス鍵発行局（ＫＤＣ）サービス３０４のリモートルーチンを呼び出し、イニシエータに対するケルベロス認証信任証を得る。

次いで、ＤＣＥログインＡＰＩは３つのうち残りの２ステップのためにＤＣＥ認可システムを使用する。第二のステップでは、ＤＣＥログインＡＰＩがＤＣＥレジストリサービス３０６のリモート"rs_login_get_info"ルーチンを呼び出し、イニシエータの特権属性を得る。ＤＣＥレジストリサービス３０６はＤＣＥレジストリデータベース３０８から特権属性を得る。

第三のステップでは、ＤＣＥログインＡＰＩがＤＣＥ特権サービス３１０のリモート"rpriv_get_eptgt"ルーチンを呼び出し、イニシエータの特権属性を検証し、これら属性をＤＣＥ ＥＰＡＣの構成に封印する。このＤＣＥ ＥＰＡＣの構成は随意ＤＣＥ ＥＰＡＣ（拡張特権属性証明書）の構成に埋め込むことができる。（この例では、ＰＡＣがＥＰＡＣ構成に埋め込まれるが、ＰＡＣがＥＰＡＣ構成に埋め込まれなくても本例は機能する。）ＤＣＥ特権サービス３１０は３つのステップを実行することによりこれを行う。第一のステップは、ＤＣＥケルベロスＫＤＣ認証サービス３０４からそれ自身のケルベロス認証の信任証を得るためのステップである。第二のステップはＤＣＥレジストリサービス３０６を用い特権属性を検証するためのステップである。第三のステップはＤＣＥ ＰＡＣに特権属性を封印し、そのＤＣＥ ＰＡＣをＤＣＥ ＥＰＡＣ構成に埋め込み、（イニシエータの特権属性を含む）そのＤＣＥ ＥＰＡＣおよび（ＤＣＥ特権サービス３０６の認証信任証である）ケルベロス認証の信任証をＤＣＥログインＡＰＩ３０２に返送するためのステップである。ＤＣＥログインＡＰＩはこの情報をイニシエータに返送する。

次いで、イニシエータ３００は保護リソースにアクセスすべくターゲット３２０に対してリクエストする。このリクエストと共に、イニシエータ３００は、ＤＣＥ特権サービスのケルベロス認証の信任証とイニシエータのＤＣＥ ＥＰＡＣを渡す。この例において、イニシエータはＤＣＥ ＲＰＣ（遠隔手続き呼び出し）プロトコルを用いてリクエストする。周知のとおり、クライアント・サーバモデルに基づく分散アプリケーションは２つの部分からなる。すなわち、一方のマシンで走り、ユーザの代わりにサービス要求を行うクライアントサイドのアプリケーションと、ネットワーク上の他方のマシンで走りサービス要求を遂行するサーバサイドのアプリケーションとである。ここで、２つの異なるマシン上の二つのコードをネットワークで通信可能にする必要がある。アプリケーションのクライアントおよびサーバ間の通信を実現させる１つのモデルとして遠隔手続き呼び出し（ＲＰＣ）があげられる。ＲＰＣにおいては、従来のローカル手続き呼出しにおけるように、制御があるコードセグメントから他のコードセグメントへと渡され、その後元のセグメントに返される。しかしながら、遠隔手続き呼び出しにおいて、呼び出される手続きは異なるアドレス空間で、通常は呼び出す手続きとは異なるマシンで実行されるので、因数および返値をメッセージに載せネットワークで送信しなければならない。基礎をなすＲＰＣ機構はこれをプログラマに対する手続き呼び出しであるかのように見せ、ＲＰＣ機能がクライアントおよびサーバノード間のネットワーク通信の細部からアプリケーションプログラマを保護する。

ターゲット３２０は、先ず、ＤＣＥ特権サービスのケルベロス認証の信任証が本物であることを証明する。この例において、ターゲット３２０はＤＣＥ ＲＰＣプロトコルを用いてこれを行う。

認証の後、ターゲット３２０はイニシエータが何れのリソースにアクセスを望んでいるかを判断し、イニシエータが要求しているアクセス権を判断し、そして要求されたアクセスを実行する権限をイニシエータに与えるかどうかを判断する。これを行うために、ターゲットは４つのステップを実行する。第一のステップは、ＤＣＥ ＲＰＣプロトコルによって返送されたＲＰＣ構成を手に入れるためのステップである。第二のステップは、リクエストから所望のリソース名を抽出し、これを２つのＤＣＥ汎用一意識別子（ＵＵＩＤ）へマッピングするためのステップである。ここで２つのＵＵＩＤは、リソースに対して構成されたアクセス制御リスト（ＡＣＬ）のＵＵＩＤと、このリソースへのアクセスを制御するＡＣＬマネージャのＵＵＩＤとである。第三のステップは、リクエストから所望のアクセス権を抽出し、それらをＤＣＥ許可セットへマッピングするためのステップである。第四のステップは、"dce_acl_is_client_authorized"ＡＰＩを呼び出し、ＡＣＬ ＵＵＩＤ、ＡＣＬマネージャＵＵＩＤ、および所望のアクセス権をＲＰＣ構成に入れてクライアントに所望のリクエストを実行する権限を与えるかどうかを判断するためのステップである。

ＤＣＥ"dce_acl_is_client_authorized"ＡＰＩは、ＤＣＥ ＡＰＩ３２２内の様々なＡＰＩを用いて６つのステップを実行する。第一のステップは、イニシエータから受信した認証信任証が有効かどうか判断するために、ＲＰＣ構成に入れてＤＣＥ ＲＰＣ ＡＰＩを呼び出すステップである。第二のステップは、ＲＰＣ構成に入れてＤＣＥ信任証ＡＰＩを呼び出してイニシエータのＤＣＥ ＰＡＣを入手するためのステップである。第三のステップは、イニシエータの所望するアクセス権をＤＣＥ ＰＡＣと比較してイニシエータのアクセス権セットを手に入れるためのステップである。第四のステップはＡＣＬマネージャＵＵＩＤおよびＡＣＬ ＵＵＩＤを使用して所望のリソースに対するＡＣＬを見つけ、このＡＣＬにおいて構成されたアクセス権セットを手に入れるためのステップである。第五のステップは、イニシエータのアクセス権セットをＡＣＬにおいて構成されたアクセス権セットと比較し、そうすることによってイニシエータに権限を与えるかどうかを判断するためのステップである。最後のステップは、イニシエータに権限を与えるかどうかを示すＹＥＳまたはＮＯの値をターゲットに返送するためのステップである。

図４におけるマネージャ２２０および２２２と同様に、１つ以上のマネージャアプリケーション３２６は、ＤＣＥ ＡＰＩ３２８を用いてしかるべきデータベース内で情報を構成する。ＤＣＥ認可システムは２つのデータベースが前提となる。すなわち、各ユーザの特権属性が構成されるＤＣＥレジストリデータベース３０８と、各リソースのＤＣＥ ＡＣＬを構成するＤＣＥ ＡＣＬデータベース３２４とである。ＤＣＥレジストリデータベース３０８を構成するために、マネージャアプリケーションは、ＤＣＥレジストリサービスのリモートインタフェースを呼び出すＤＣＥレジストリＡＰＩを呼び出す。ＡＣＬデータベース３２４を構成するために、マネージャは、ＤＣＥリモートＡＣＬサービス３３０のリモートインタフェースを呼び出すＤＣＥ ＡＣＬ ＡＰＩを呼び出す。

図５はレガシーアプリケーションによる利用が考えられるレガシー認可システムを示す。そして図４は、様々な更新ノンレガシー（既成でない）アプリケーションによる利用が考えられる標準的な認可システムを示す。これらとは異なり、本発明は、標準的な認可システムに対するレガシー認可システムを対象とした再ルーティング認可リクエストに照準を合わせたものである。

図５のＤＣＥレガシー認可システムの例においては、イニシエータの代わりになされる全ての認可処理がＤＣＥリモートルーチンによって行われる。レガシー認可システムにおける遠隔手続き呼び出しが途中で捕捉され得るということを認知することにより、本発明はリモートルーチンに対する呼び出しを途中で捕捉し、異なる機能をそれらリモートルーチンの代わりにする。

図４の標準的な認可システムの例においては、イニシエータの代わりになされる全ての認可処理が、認可機能を呼び出すための標準インタフェースを提供する認可ＡＰＩ経由で行われる。この標準的な認可ＡＰＩは、様々な市販のプラグ対応認可システムによって入手可能な認可機能の潜在的に異なる実装に対して標準インタフェースを提供する。プラグ対応認可システムで利用可能な標準的な認可ＡＰＩを備えたレガシー認可システムの遠隔呼び出しルートを変更する能力の観測結果を用いることにより、本発明は、標準的な認可ＡＰＩを介したレガシー認可システムのリモートルーチンに対する呼び出しのうち途中で捕捉されるものに対して、様々なプラグ対応の認可システムへのルートを決める方法論を提供する。すなわち、本発明は、レガシーアプリケーション維持する一方、高価で大規模なレガシーアプリケーションの再符号化なしに、様々なプラグ対応認可システムでそれらレガシーアプリケーションを使用する方法論を提供する。

図６乃至９を参照して説明すると、レガシー認可システムにおけるリモートルーチンへの呼び出しを、本発明の好適な実施形態に係わる認可プラグインを使用して標準的な認可システムに転送する方法を示す一組のブロック図である。特に、図６は、認可プラグインをどのように用いて図５に示すイニシエータ等のイニシエータの代わりになされた認可リクエストを途中で捕捉し処理することが可能かを示す。図７は、ターゲットの代わりになされる全ての認可処理のルートを認可プラグインにより変更する方法論を示す。図８および図９は、本実施形態内で正常に機能するように管理アプリケーションを変更する仕方を表す。

図６を参照すると、認可プラグイン４００は標準的な認可サーバにインストールできる。リモートルーチンＲＰＣエンドポイントをエキスポートする公知技術を用い、認可プラグイン４００はＤＣＥリモートレジストリおよび特権サービスのためにリモートルーチンＲＰＣエンドポイントをエキスポートし、そうすることにより、それら２つのサービスに対する全てのリモートルーチン呼び出しを途中で捕捉、処理する。認可プラグイン４００は認可サーバ上に位置しているか、あるいは、リモートルーチン呼び出しを途中で捕捉、処理できると共に標準的な認可サービスと関連づけることができるのであれば、分散コンピューティング環境内のどこに位置していてもよい。

例えば、図５のイニシエータ３００に関して上述したのと同様に、イニシエータ４０２は、ＤＣＥ ＡＰＩ４０４内の多数のＡＰＩの１つであるＤＣＥログインＡＰＩを呼び出す。しかしながら、図５に示すプロセスとは異なり、ＤＣＥログインＡＰＩが"rs_login_get_info"リモートルーチンを呼び出す際、認可プラグイン４００がこのルーチンを途中で補足、処理する。このプラグインは２つのステップを実行することにより呼び出しを処理する。先ず、標準的な認可ＡＰＩ、すなわち、上記表１にて示した"azn_creds"ＡＰＩ等、認可ＡＰＩ４０６内のＡＰＩの１つが呼び出され、該標準認可システムによって用いられる特権属性データベース４０８から特権属性を検索する。第二のステップは、ＤＣＥログインＡＰＩによって要求されるフォーマットで特権属性をＤＣＥログインＡＰＩに返送するステップである。

ＤＣＥログインＡＰＩが"rpriv_get_epac"リモートルーチンを呼び出す際、認可プラグイン４００がこのルーチンを途中で捕捉、処理する。このプラグインは３つのステップからなる一連の処理動作としてこのルーチンを処理する。すなわち、（１）ＤＣＥ特権サービスの同一性を前提としながらケルベロスＫＤＣ信任証をケルベロスＫＤＣサービス４１０から得る（この例では、管理者がＤＣＥ特権サービスの同一性を用いてＤＣＥの範囲において認証を行うことができるようにプラグインを構成したものとする）。（２）"azn_creds"ＡＰＩ等、標準的な認可ＡＰＩを呼び出してイニシエータの特権属性を検証し、ＣＡＳ４１２およびＰＡＣサービス４１４を用いてその標準認可システムによって使用される標準的なＰＡＣにそれらを封印する。（３）ＤＣＥ特権サービスのケルベロス信任証を、ＤＣＥ ＥＰＡＣ構成に埋め込まれた（イニシエータの特権属性を含む）該標準ＰＡＣと共に（ＤＣＥログインＡＰＩによって要求されるフォーマットで）ＤＣＥログインＡＰＩに返送する。

図６がイニシエータの代わりに呼び出しを処理する方法を表し、図７がターゲットの代わりに呼び出しを処理する方法を表す。レガシー認可システムにもよるが、ターゲットアプリケーションはレガシー認可システムにおけるリモートルーチンに対しても遠隔手続き呼び出しを行うかもしれない。その場合には、ターゲットアプリケーションからレガシー認可システムのアプリケーションプログラミングインターフェイスへの呼び出しも、エキスポートされたＲＰＣエンドポイントを用いて認可プラグインが転送するかもしれない。

他のレガシー認可システムにおいては、ターゲットアプリケーションからレガシー認可システムのアプリケーションプログラミングインターフェイスへの呼び出しが、ターゲットアプリケーションにコンパイルあるいはリンクされたコードに対して直接行われるかもしれない。それらタイプのシステムにおいて、認可プラグインは、認可プラグインが標準的な認可サーバ上に配置される場合にターゲットアプリケーションに再コンパイルあるいはリンクされ得るコードライブラリの形で機能を提供するかもしれない。

図５のＤＣＥレガシー認可システムの例に戻って説明すると、ターゲットの代わりになされる全ての認可処理がＤＣＥ"dce_is_client_authorized"ＡＰＩによって処理される。図７はこのＡＰＩへの呼び出しがどのようにして認可プラグインにおける同一名のＡＰＩへ転送可能になるかを示す。この例では、ターゲットアプリケーションが認可プラグインライブラリで再コンパイルされる。認可プラグインライブラリは"dce_acl_is_client_authorized"ＡＰＩを実装する。そして、ターゲットアプリケーションが公知の方法で再コンパイルされ、ＤＣＥライブラリからの"dce_acl_is_client_authorized"ＡＰＩではなく、プラグインライブラリからの"dce_acl_is_client_authorized"ＡＰＩが処理される。

ターゲット５０２がＤＣＥ ＡＰＩ５０４内の多数のＡＰＩの１つであるＤＣＥ"dce_acl_is_client_authorized"ＡＰＩを呼び出す際、認可プラグイン５０６がこのＡＰＩに対する呼び出しを受信、処理する。プラグインは６つのステップからなる一連の処理動作を実行することにより該ＡＰＩに対する呼び出しを処理する。この一連の６つのステップは、ＤＣＥ"dce_acl_is_client_authorized"ＡＰＩを処理するために図５に関して上述した６つのステップと同様である。

最初の２つのステップは、イニシエータによって渡されたＤＣＥ ＲＰＣ ＡＰＩを用いてケルベロス認証信任証が本物であることを証明する。これは、ＤＣＥレガシー"dce_acl_is_client_authorized"ＡＰＩによって実行される第一のステップと同様である。第二のステップはＤＣＥ ＥＰＡＣから標準認可ＰＡＣを手入するためのもので、ＤＣＥレガシー"dce_acl_is_client_authorized"ＡＰＩによって実行されるのと同じである。

第三のステップは、ＤＣＥ ＡＣＬマネージャＵＵＩＤを標準認可システムによって認識されたリソースマネージャにマッピングし、そのＤＣＥ ＡＣＬ ＵＵＩＤを該標準認可システムによって管理されたリソースにマッピングする。第四のステップは、ＤＣＥアクセス権セットを標準認可システムによって認識されたアクセス権セットへマッピングする。第五のステップは、標準的な認可ＡＰＩ、すなわち、表１に示す"azn_decision"等の認可ＡＰＩ５０８内のＡＰＩの１つを用い、ＰＡＣ、所望のアクセス権、リソース、およびＡＤＦ５１０およびアクセス制御リポジトリ５１２の使用も要求するリソースマネージャに基づき認可判定を行う。最後のステップは、認可判定、すなわちイニシエータに権限を付与するかどうかを示すＹＥＳまたはＮＯの値をターゲットに返送するステップである。

図５に戻って説明すると、特権マネージャアプリケーションは、ＤＣＥレジストリデータベースにそれら属性を格納するリモートＤＣＥレジストリルーチンに対してＤＣＥ ＡＰＩ呼び出しを行うことにより特権属性を構成する。同様に、ポリシーマネージャアプリケーションは、ＤＣＥ ＡＣＩデータベースにそれら属性を格納するリモートＤＣＥ ＡＣＬルーチンに対してＤＣＥ ＡＰＩ呼び出しを行うことによりＡＣＬ属性を構成する。図６および図７に関して説明したルート変更と同様に、図８および図９は、認可プラグインによってリモートＤＣＥレジストリルーチンのルートをどのようにして標準認可システムに変更できるかを示すブロック図である。図８および図９に対して、図６および図７に対するのと同様に、分散コンピューティング環境の他の場所に位置していたとしても、認可プラグインは標準的な認可システムサーバにインストールされる。

図８を参照すると、認可プラグイン６００はＤＣＥレジストリルーチンのためのリモート・ルーチンＲＰＣエンドポイントをエキスポートし、そうすることにより、標準認可システムによって使用される特権属性データベース６０６にデータを格納し、ＤＣＥ特権マネージャアプリケーション６０２からＤＣＥ ＡＰＩ６０４内のＤＣＥレジストリルーチンへの如何なる呼び出しも途中で捕捉、処理する。図９を参照すると、認可プラグイン７００はＤＣＥレジストリルーチンのためのリモート・ルーチンＲＰＣエンドポイントをエキスポートし、そうすることにより、標準認可システムによって使用されるアクセス制御リポジトリ７０６にデータを格納し、ＤＣＥポリシーマネージャアプリケーション７０２からＤＣＥ ＡＰＩ７０４内のＤＣＥレジストリルーチンへの如何なる呼び出しも途中で捕捉、処理する。

本発明の利点は、以上説明した発明の詳細な説明から明らかであろう。新しい認可システムは、レガシーアプリケーションが認可ＡＰＩおよびレガシー認可システムのバックエンドリモートインタフェースを使用し続けることができるようにしてコンピュータ環境への接続可を能にする認可システムである。しかしながら、レガシーアプリケーションがレガシー認可システム内のルーチンに向けて呼び出しを行う場合、その呼び出しは転送され新たに配備された認可システムのＡＰＩに適した呼び出しが行われる。新しい認可ＡＰＩを使用するためにレガシーアプリケーションをアップグレードすることは困難なだけではなく費用もかかるので、本発明は、新たに配備される認可システムと連動して動作するように変更されたレガシーアプリケーションの大規模な再符号化とテストを回避するためのものである。

解決策によっては、一組のレガシーアプリケーションの使用を減らす認可システムを維持しながら同時に新しいアプリケーションのための認可システムを配備することを企業は決定するかもしれない。この解決策は、各認可システムのために異なるセットのデータベースを維持するようシステム管理者に要求する。職員の計算リソースからの変更、追加および削除等にもよるが、任意の変更に対して複数セットのデータベースを更新する必要が生じるかもしれない。一方、本発明に関しては、新たに配備された認可システムのデータベースだけが維持されればよい。レガシー認可システムで動作するよう設計されたレガシーアプリケーションは、標準の認可システム内で使用される同じデータベースから情報を取り出す。

以上、本発明を完全に機能しているデータ処理システムの状況において説明したが、本発明のプロセスが、配布を行うのに実際用いられる媒体が特定タイプの信号搬送媒体であるかどうかに係わらず、コンピュータによって読み出し可能な媒体に格納した命令の形や、その他様々な形態で配布可能なことを当業者なら理解するであろうことに留意することが重要である。コンピュータによって読み出し可能な媒体には、ＥＰＲＯＭ、ＲＯＭ、テープ、紙、フレキシブルディスク、ハードディスクドライブおよびＲＡＭやＣＤ−ＲＯＭ等の媒体、そしてディジタルおよびアナログ通信リンク等の伝送型の媒体が含まれる。

本発明に対する上述は説明のために提示されたもので、開示される実施形態に包括されたり限定されたりするものではない。多くの変更や変形が可能なことは当業者には明らかである。以上の実施形態は本発明とその実用化の原理を説明するために選択されたものであり、その他検討される利用にふさわしいかもしれない様々な変更を伴う様々な実施形態を実現するために、当業者が本発明を容易に理解できるようにしたものである。

既成のアクセス制御方法論のブロック図である。 既成のアクセス制御方法論のブロック図である。 既成のアクセス制御方法論のブロック図である。 既成の標準的な認可アーキテクチャのブロック図である。 既成のレガシー認可システムのブロック図である。 本発明の好適実施形態に係わり、認可プラグインをどのように用いてイニシエータの代わりになされる認可リクエストを途中で捕捉し処理することが可能かを示すブロック図である。 本発明の好適実施形態に係わり、認可プラグインをどのように用いてターゲットの代わりになされる認可リクエストを途中で捕捉し処理することが可能かを示すブロック図である。 認可プラグインをどのように用いてマネージャアプリケーションによってなされるリクエストを途中で捕捉し処理することが可能かを示すブロック図である。 認可プラグインをどのように用いてマネージャアプリケーションによってなされるリクエストを途中で捕捉し処理することが可能かを示すブロック図である。

Claims (15)

1. データ処理システム内の保護リソースに対するアクセス許可方法において、下記ステップをコンピュータに実行させる方法であって、該方法が、
   分散コンピューティング環境(ＤＣＥ)認可サービスに向けられた許可要求に対するリモートルーチンのための遠隔手続き呼び出しを第二の認可サービスに関連付けられた認可プラグインを実行させて途中で捕捉するステップであって、前記捕捉は、ＤＣＥ認可サービスのリモートルーチンのための遠隔手続き呼び出しのエンドポイントを前記認可プラグインを実行させてエクスポートすることによって可能になる、前記捕捉するステップと、
   第二の認可サービスのアプリケーションプログラミングインターフェイスを呼び出すことによって、前記許可要求を前記認可プラグインを実行させて処理するステップであって、
   前記アプリケーションプログラミングインターフェイスに対する呼び出しを受け付けるステップと、
   イニシエータによってターゲットアプリケーションに渡された認可信任証が本物であることを確認するステップと、
   ＤＣＥ ＥＰＡＣ構成から特権属性証明書を検索するステップと、
   ＤＣＥ ＥＰＡＣ構成からのＤＣＥアクセス制御リスト（ＡＣＬ）マネージャの汎用一意識別子（ＵＵＩＤ）を第二の認可サービスのリソースマネージャへマッピングするステップと、
   ＤＣＥ ＥＰＡＣ構成からのＤＣＥ ＡＣＬ ＵＵＩＤを前記第二の認可サービスによって管理されるリソースへマッピングするステップと、
   ＤＣＥ ＥＰＡＣ構成からのＤＣＥアクセス権セットを前記第二の認可サービスのアクセス権セットへマッピングするステップと、
   第二の認可サービスのアプリケーションプログラミングインターフェイスを呼び出して、前記第二の認可サービスのアクセス権セット、特権属性証明書、リソース、およびリソースマネージャに基づき認可判定を行うステップと、
   認可判定の指示を前記ターゲットアプリケーションに返送するステップと
   を含む、前記処理するステップと
   を含む、前記方法。
2. 前記ステップが、
   ＤＣＥ"rs_login_get_info"ルーチンに対する呼び出しを前記認可プラグインを実行させて途中で捕捉するステップと、
   第二の認可サービスにおける特権属性データベースからイニシエータの特権属性を検索するステップと、
   該特権属性をＤＣＥ認可サービスのアプリケーションプログラミングインターフェイスに返送するステップと
   をさらに含む、請求項１記載の方法。
3. 前記ステップが、
   ＤＣＥ"rpriv_get_epac"ルーチンに対する呼び出しを前記認可プラグインを実行させて途中で捕捉するステップと、
   ＤＣＥ特権サービスのための認可信任証を得るステップと、
   該特権属性を特権属性証明書に格納するステップと、
   認可信任証及び特権属性証明書をＤＣＥ拡張特権属性証明書（ＥＰＡＣ）構成に埋め込むステップと、
   該ＥＰＡＣ構成をＤＣＥ認可サービスのアプリケーションプログラミングインターフェイスに返送するステップと
   をさらに含む、請求項２記載の方法。
4. 前記アプリケーションプログラミングインターフェイスが"dce_acl_is_client_authorized"アプリケーションプログラミングインターフェイスである、請求項１記載の方法。
5. 第二の認可サービスが標準規格準拠の認可アプリケーションプログラミングインターフェイスをサポートし、前記標準規格準拠の認可アプリケーションプログラミングインターフェイスが認可ＡＰＩのオープングループの技術標準規格Ｃ９０８に準拠する、請求項１記載の方法。
6. データ処理システム内の保護リソースに対するアクセス許可装置において、
   分散コンピューティング環境(ＤＣＥ)認可サービスに向けられた許可要求に対するリモートルーチンのための遠隔手続き呼び出しを第二の認可サービスに関連付けられた認可プラグインを実行させて途中で捕捉する手段であって、前記捕捉は、ＤＣＥ認可サービスのリモートルーチンのための遠隔手続き呼び出しのエンドポイントを前記認可プラグインを実行させてエクスポートすることによって可能になる、第一の途中捕捉手段と、
   第二の認可サービスのアプリケーションプログラミングインターフェイスを呼び出すことによって、前記許可要求を前記認可プラグインを実行させて処理する処理手段であって、
   前記アプリケーションプログラミングインターフェイスに対する呼び出しを受け付ける受付手段と、
   イニシエータによってターゲットアプリケーションに渡された認可信任証が本物であることを確認する認証手段と、
   ＤＣＥ ＥＰＡＣ構成から特権属性証明書を検索する第二の検索手段と、
   ＤＣＥ ＥＰＡＣ構成からのＤＣＥアクセス制御リスト（ＡＣＬ）マネージャの汎用一意識別子（ＵＵＩＤ）を第二の認可サービスのリソースマネージャへマッピングする第一のマッピング手段と、
   ＤＣＥ ＥＰＡＣ構成からのＤＣＥ ＡＣＬ ＵＵＩＤを前記第二の認可サービスによって管理されるリソースへマッピングする第二のマッピング手段と、
   ＤＣＥ ＥＰＡＣ構成からのＤＣＥアクセス権セットを前記第二の認可サービスのアクセス権セットへマッピングする第三のマッピング手段と、
   第二の認可サービスのアプリケーションプログラミングインターフェイスを呼び出して、前記第二の認可サービスのアクセス権セット、特権属性証明書、リソース、およびリソースマネージャに基づき認可判定を行う呼出手段と、
   認可判定の指示をターゲットアプリケーションに返送する第三の返送手段と
   を含む、前記処理手段と
   含む、前記装置。
7. ＤＣＥ"rs_login_get_info"ルーチンに対する呼び出しを前記認可プラグインを実行させて途中で捕捉する第二の途中捕捉手段と、
   第二の認可サービスにおける特権属性データベースからイニシエータの特権属性を検索する第一の検索手段と、
   該特権属性をＤＣＥ認可サービスのアプリケーションプログラミングインターフェイスに返送する第一の返送手段と
   をさらに含む、請求項６記載の装置。
8. ＤＣＥ"rpriv_get_epac"ルーチンに対する呼び出しを前記認可プラグインを実行させて途中で捕捉する第三の途中捕捉手段と、
   ＤＣＥ特権サービスのための認可信任証を得る取得手段と、
   該特権属性を特権属性証明書に格納する格納手段と、
   認可信任証及び特権属性証明書をＤＣＥ拡張特権属性証明書（ＥＰＡＣ）構成に埋め込む埋込手段と、
   該ＥＰＡＣ構成をＤＣＥ認可サービスのアプリケーションプログラミングインターフェイスに返送する第二の返送手段と
   をさらに含む、請求項７記載の装置。
9. 前記アプリケーションプログラミングインターフェイスが"dce_acl_is_client_authorized"アプリケーションプログラミングインターフェイスである、請求項６記載の装置。
10. 第二の認可サービスが標準規格準拠の認可アプリケーションプログラミングインターフェイスをサポートし、前記標準規格準拠の認可アプリケーションプログラミングインターフェイスが認可ＡＰＩのオープングループの技術標準規格Ｃ９０８に準拠する、請求項６記載の装置。
11. データ処理システム内の保護リソースに対するアクセス許可のプログラムにおいて、下記ステップをコンピュータに実行させるプログラムであって、該ステップが、
    分散コンピューティング環境(ＤＣＥ)認可サービスに向けられた許可要求に対するリモートルーチンのための遠隔手続き呼び出しを第二の認可サービスに関連付けられた認可プラグインを実行させて途中で捕捉するステップであって、前記捕捉は、ＤＣＥ認可サービスのリモートルーチンのための遠隔手続き呼び出しのエンドポイントを前記認可プラグインを実行させてエクスポートすることによって可能になる、前記捕捉するステップと、
    第二の認可サービスのアプリケーションプログラミングインターフェイスを呼び出すことによって、前記許可要求を前記認可プラグインを実行させて処理するステップであって、
    前記アプリケーションプログラミングインターフェイスに対する呼び出しを受け付けるステップと、
    イニシエータによってターゲットアプリケーションに渡された認可信任証が本物であることを確認するステップと、
    ＤＣＥ ＥＰＡＣ構成から特権属性証明書を検索するステップと、
    ＤＣＥ ＥＰＡＣ構成からのＤＣＥアクセス制御リスト（ＡＣＬ）マネージャの汎用一意識別子（ＵＵＩＤ）を第二の認可サービスのリソースマネージャへマッピングするステップと、
    ＤＣＥ ＥＰＡＣ構成からのＤＣＥ ＡＣＬ ＵＵＩＤを前記第二の認可サービスによって管理されるリソースへマッピングするステップと、
    ＤＣＥ ＥＰＡＣ構成からのＤＣＥアクセス権セットを前記第二の認可サービスのアクセス権セットへマッピングするステップと、
    第二の認可サービスのアプリケーションプログラミングインターフェイスを呼び出して、前記第二の認可サービスのアクセス権セット、特権属性証明書、リソース、およびリソースマネージャに基づき認可判定を行うステップと、
    認可判定の指示を前記ターゲットアプリケーションに返送するステップと
    を含む、前記処理するステップと
    を含む、前記プログラム。
12. 前記ステップが、
    ＤＣＥ"rs_login_get_info"ルーチンに対する呼び出しを前記認可プラグインを実行させて途中で捕捉するステップと、
    第二の認可サービスにおける特権属性データベースからイニシエータの特権属性を検索するステップと、
    該特権属性をＤＣＥ認可サービスのアプリケーションプログラミングインターフェイスに返送するステップと
    をさらに含む、請求項１１記載のプログラム。
13. 前記ステップが、
    ＤＣＥ"rpriv_get_epac"ルーチンに対する呼び出しを前記認可プラグインを実行させて途中で捕捉するステップと、
    ＤＣＥ特権サービスのための認可信任証を得るステップと、
    該特権属性を特権属性証明書に格納するステップと、
    認可信任証及び特権属性証明書をＤＣＥ拡張特権属性証明書（ＥＰＡＣ）構成に埋め込むステップと、
    該ＥＰＡＣ構成をＤＣＥ認可サービスのアプリケーションプログラミングインターフェイスに返送するステップと
    をさらに含む、請求項１２記載のプログラム。
14. 前記アプリケーションプログラミングインターフェイスが"dce_acl_is_client_authorized"アプリケーションプログラミングインターフェイスである、請求項１１に記載のプログラム。
15. 第二の認可サービスが標準規格準拠の認可アプリケーションプログラミングインターフェイスをサポートし、前記標準規格準拠の認可アプリケーションプログラミングインターフェイスが認可ＡＰＩのオープングループの技術標準規格Ｃ９０８に準拠する、請求項１１記載のプログラム。

Images