アクセス・サーバーは、リクエスタに認証と認可の両方を求めることにより、リソースへのアクセスを制御します。認証は、ユーザーがアクセスするためにIDを確立して証明するためのプロセスです。認可は、ユーザーが認証された後に実行が許可される操作を決定します。管理コンソールを使用した認証および認可の構成の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
この章では、認可に関するサポートについて説明します。
内容は次のとおりです。
認可プラグインAPIでは、認可スキーム内で使用されるプラグインと呼ばれるモジュールを開発者が作成する手段が用意されています。スキームは認可ルールに含まれており、1つ以上の認可ルール、1つの認証ルールおよび1つの監査ルールがポリシーを構成します。ポリシーにより、Webサイト内のURLやアプリケーション内の一連のメソッドなど、ドメイン内のリソースに対するアクセスを制御します。Oracle Access Managerには、HTTPとEJBという2つの標準リソース・タイプがありますが、管理者はその他のリソース・タイプを簡単に追加および定義できます。リソース・タイプ、ドメイン、ポリシー、ルールおよびスキームの作成の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
認可スキーム内のプラグインを使用する目的には、次の2つがあります。
リソースに対するアクセスを確定または拒否します。あるいは、ポリシー内の次の認可ルールで使用されるデータを取得します。これは、認可プラグインと呼ばれます。
アクセスに関する決定が下された後になんらかのアクションを実行します。これは、カスタム・アクション・プラグインと呼ばれます。
認可プラグインを実行すると、次のいずれかの結果が得られます。詳細は、後述の「ObAzplug-instatus_t」の項を参照してください。
続行
アクセス許可
アクセス拒否
中断
認可プラグインによってアクセスが許可または拒否された場合の、カスタム・アクション・プラグインの実行を指示できます。カスタム・アクション・プラグインは、アクセス・ゲートにデータを戻すことや、特定のユーザーへの通知やトランザクションの記録などのサービスの実行に使用されます。
認可プラグインAPIによって作成されたプラグインを使用するには、管理者が2つのタイプの情報を構成する必要があります。
プラグインを使用するための認可スキーム。1つのスキームで認可プラグインとカスタム・アクション・プラグインの両方を使用できます。
スキームを使用するためのカスタム認可ルール。
プラグイン自体の作成に関する、この章内の他の項:
「APIの環境」: APIライブラリのインストール場所、ビルド環境および使用方法の説明
「C APIのデータ」: API内で使用されるデータの説明
「C APIの関数」: APIの処理内容の説明
「Cの例」: APIの使用例の提示
プラグインを作成する場合、Microsoft .NETフレームワークによってサポートされている任意の言語(C、MC++およびVisual Basicを含む)を使用できます。Windows環境でプラグインを使用する場合、マネージ・コードを使用すると、様々な実装言語から言語を選択できます。また、マネージ・コードにはこれ以外にも様々な利点があります。
ここでは、10g(10.1.4.0.1)における変更と下位互換性について説明します。
10g(10.1.4.0.1)より前では、C用の認可プラグインAPIに、アクセス・サーバーとカスタム・プラグイン間のデータ交換用としてLatin-1エンコーディングが使用されていました。しかし、10g(10.1.4.0.1)のC用の認可プラグインAPIでは、プラグインの処理用としてUTF-8エンコーディングを使用します。
古いアクセス・サーバーを10g(10.1.4.0.1)にアップグレードする場合、アクセス・サーバーのglobalparams.xmlファイルに値="IsBackwardCompatible" Value="false"
が自動的に設定されます。下位互換性のあるアクセス・サーバーでは、データがそのままLatin-1エンコーディングで認可プラグインに送信され、プラグインによってデータがLatin-1エンコーディングで設定されるものと想定されます。プラグインのデータのエンコーディングには変更はありません。
アップグレードした環境に新しい10g(10.1.4.0.1)のアクセス・サーバーを追加する場合、アクセス・サーバーのglobalparams.xmlファイルに="IsBackwardCompatible" Value="false"
を手動で設定し、古いプラグインとインタフェースとの通信、および古いWebGateとカスタム・アクセス・ゲートとの通信を有効にする必要があります。
次の各項では、API環境について説明します。
認可プラグインSDKは、アクセス・サーバーのインストール時に標準コンポーネントとして次のロケーションにインストールされます。
ASInstall_dir /sdk/authorization/samples
ASInstall_dir
は、アクセス・サーバーをインストールしたロケーションです。次はその例です。
COREid/access/oblix
サンプル・ディレクトリには、プラグイン・コードの例、1つ以上のmakeファイル、およびincludeサブディレクトリが含まれます。includeサブディレクトリには、作成対象のプラグインに含まれる2つのヘッダー・ファイルが含まれます。as_plugin_utils.hファイルにより、アクセス・サーバーがすべての認可プラグインに提供する一連のユーティリティが定義されます。authz_plugin_api.hファイルにより、APIデータおよび関数が定義され、その他のヘッダー・ファイルが組み込まれます。
注意: ヘッダー・ファイルには、APIデータおよび関数の定義が含まれます。インストールの一部としてこのファイルに含まれるコンテンツは、APIを正しくビルドおよび操作する上で重要です。アクセス・サーバーによってプラグインがロードされるときに、プラグイン内にあるauthz_plugin_api.hに一連の関数が実装されているものと想定されます。このファイルには情報を追加できますが、既存のコンテンツは削除しないでください。 |
ビルドの手順
サンプル・ディレクトリで、mypluginなどの名前のディレクトリを新しく作成します。makeファイルおよびサンプル・コードをこの新規ディレクトリにコピーします。
新規ディレクトリ内では、authz_api.cファイルがプラグインの構造や操作を示す好例となります。必要な場合、独自のファイルを作成してサイトに固有の特定の機能を追加できます。
Cコンパイラへの実際のパスを示すようにするとともに、すべてのソース・コードを含めてコンパイルするようmakeファイルを変更します。
makeファイルを実行します。
これにより、*.soまたは*.dllというプラグインが新しく作成されます。
認可プラグインSDKは、アクセス・サーバーのインストール時に標準コンポーネントとして次のロケーションにインストールされます。
ASInstall_dir/sdk/authorization/managed/authz_c++
ASInstall_dirは、アクセス・サーバーをインストールしたロケーションです。次はその例です。
COREid/access/oblix
このディレクトリには、C++のプラグイン・コードの例が含まれます。次のロケーションにmanaged_plugin_interfaceファイルがあります。
ASInstall_dir/apps/common/bin
これにより、アクセス・サーバーがすべての管理認可プラグインに提供する一連のインタフェースを定義します。managed_plugin_interface.hにより、プラグイン開発者が使用可能なインタフェースを定義および記述します。
ヘッダー・ファイルには、APIデータおよび関数の定義が含まれます。インストールの一部としてこのファイルに含まれるコンテンツは、APIを正しくビルドおよび操作する上で重要です。プラグインがアクセス・サーバーによってロードされるときに、プラグイン内にあるmanaged_plugin_interface.hに一連の関数が実装されているものと想定されます。
重要: 既存のコンテンツは削除しないでください。 |
ビルドの手順
サンプル・ディレクトリで、新規ディレクトリを作成します。
このディレクトリには、mydirectoryなどの任意の名前を付けることができます。
必要な場合、新規ファイルを作成し、サイトに固有の機能を追加できます。
新規ディレクトリ内では、cplusplus.cppファイルがプラグインの構造や操作を示す好例となります。
cplusplus.vcprojプロジェクト・ファイルを使用して、プラグインをロードおよびビルドします。
これにより、.dllというプラグインが新しく作成されます。
*.soまたは*.dllファイルとして(Cまたはマネージ・コードで)作成するプラグインは、アクセス・サーバーが動作しているシステム上の任意のロケーションに格納できます。認証プラグインAPIの一貫性を保つには、認可プラグインを次のロケーションにコピーします。
<$ASInstall_dir >/lib
この作業は必ずしも必要ではありません。しかし、このファイルはアクセス・サーバーが動作しているマシン上の任意のロケーションに格納できます。このため、アクセス管理者は、認可スキームの構成時にプラグインを参照するには、ファイルへのフルパスを把握している必要があります。また、アクセス管理者は、プラグインに必要な必須入力パラメータとオプション入力パラメータも把握している必要があります。認可スキームの構成の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。認可スキームの構成例については、「Cの例」に続く画面を参照してください。
注意: システムを移行する場合、カスタム・プラグインは移行されません。このことも、手動による移行作業を簡単に行うために、これらすべてのプラグインを1つのロケーションにまとめる理由の1つとなります。 |
次の各項では、C APIについて説明します。
authz_plugin_api.hファイルには、プログラミングを補助するために複数の値が定義されています。
その1つとして、ObAzPluginGetVersionがコールされたときにアクセス・サーバーに戻される値があります。
#define OB_AZ_PLUGIN_VERSION "10.1.3"
注意: バージョンに関して提供される値は、後続のバージョンでは異なる場合があります。 |
定義されたその他の値は、ObAzPluginInfo構造体のRequestorInfoまたはRequestContextメンバーとしてアクセス・サーバーが提供するデータの名前にマップされます。
#define ObAzPluginRequesterDn "RequesterDn" #define ObAzPluginRequesterIP "RequesterIP" #define ObAzPluginRequestResourceType "ResourceType" #define ObAzPluginRequestResource "Resource" #define ObAzPluginRequestOperation "Operation" #define ObAzPluginRequesterDn "RequesterDn" #define ObAzPluginRequesterIP "RequesterIP" #define ObAzPluginRequestResourceType "ResourceType" #define ObAzPluginRequestResource "Resource" #define ObAzPluginRequestOperation "Operation"
認可スキームでは、外部ソースからデータを取得することもできます(『Oracle Access Managerアクセス管理ガイド』を参照)。このデータは、カスタム認可プラグインに渡されます。外部データ(通常ではユーザーに関する情報)を取得すると、認可の可否をユーザー入力に基づいて動的に判別できます。
たとえば、ユーザーがフォームにアクセスして$1000のアイテムを購入しようとした場合、この$1000という金額を制限値(データベースに保存された値など)と照合して動的に評価し、購入が認可されるかどうかを判別できます。
外部ソースから認可データを取得するプロセスは、リバース・アクションとも呼ばれます。
リバース・アクションを使用する認可プラグインを作成する場合、リバース・アクションを取得するためのコールは、リバース・アクションが存在しなくてもエラーを起こさないという点に注意してください。たとえば、次のような場合、RequestContext
にuser-agent
値が存在しないときには、リストに対してNULL
が戻されます。
ObASPluginList_t list = pFnBlock->GetDataFn(pInfo->RequestContext, "user-agent");
プラグインは、リバース・アクション(またはその他の目的)用に戻されたデータ・リストを個別のデータ値の取得に使用する前に、データがNULL
でないかどうかを確認する必要があります。このような状況は、クライアントがリバース・アクション用の値を指定しなかった場合に発生する可能性があります。
アクセス・サーバーおよびAPIでは、ハンドルとも呼ばれるポインタを使用して、プラグインで使用できるようアクセス・サーバーが管理するデータ構造を操作します。これらのハンドルの名前と説明を、次の表で説明します。すべての構造体の内容に関する説明は、「C構造体」を参照してください。リスト、名前、値および項目といった用語は、「ObAzPluginInfo」に示すように、ObAzPluginInfo構造体の内部で相互関係があるデータを表しています。
データ型および名前 | 説明 |
---|---|
void const* ObASPluginList_t |
ObAzPluginInfo構造体の特定のメンバーの値リストを指すハンドル。このハンドルは、GetDataFn関数を使用して取得します。 |
void const* ObASPluginListItem_t |
値リスト内の項目の1つを指すハンドル。このハンドルは、GetFirstItemFnまたはGetNextFn関数を使用して取得します。 |
ObASPluginListItem_t *ObASPluginGetFirstItem_t |
名前リストの先頭を示すハンドルを取得するアクセス・サーバー関数を指すハンドル。 |
const char* *ObASPluginGetValue_t |
現在の項目の値を取得するアクセス・サーバー関数を指すハンドル。 |
ObASPluginListItem_t *ObASPluginGetNext_t |
リスト内の次の項目を示すハンドルを取得するアクセス・サーバー関数を指すハンドル。 |
ObASPluginList_t *ObAzPluginGetData_t |
名前リストの先頭を示すハンドルを取得するアクセス・サーバー関数を指すハンドル。 |
ObAzASStatus_t *ObAzplug-insetData_t |
リストに値を格納するアクセス・サーバー関数を指すハンドル。 |
void const*
ObAzPluginData_t |
不透明なデータ構造ObAzPluginInfoの読取り専用メンバーの名前リストの先頭を指すハンドル。 |
struct ObAzPluginFns
ObAzPluginFns_t |
アクセス・サーバーによって提供される関数を示すハンドルが含まれるObAzPluginFns構造体を指すハンドル。ObAzPluginInfo構造体内のデータを操作するために使用されます。 |
struct ObAzPluginInfo*
|
ObAzPluginInfo構造体の先頭を指すハンドル。 |
char**
|
関数の結果を報告するためにプラグイン関数がアクセス・サーバーに戻すNULL終了文字列を指すハンドル。 |
void*
|
不透明なデータ構造ObAzPluginInfoの読取りおよび書込みメンバーの名前リストの先頭を指すハンドル。 |
struct ObAzServerContext*
|
ObAzServerContext構造体の先頭を指すハンドル。 |
アクセス・サーバーおよびAPIが通信用として使用する関数の多くは、ステータス値を戻します。これらの戻り値は、ここで説明するように、事前に定義されています。
これらは、認可の試行結果を示すためにプラグインが戻すことの可能な値を示します。
typedef enum { ObAzplug-instatusContinue = 0, ObAzplug-instatusAccessDenied = 2, ObAzplug-instatusAccessAllowed = 1, ObAzplug-instatusAbort = 3
名前 | 説明 |
---|---|
ObAzplug-instatusAbort |
プラグイン内で致命的エラーが発生したことを示します。処理は次のプラグイン(存在する場合)には渡されません。認可プラグインからこのエラーが戻された場合、認可が失敗し、アクセスは拒否されます。カスタム・アクション・プラグインからこのエラーが戻された場合、エラー・メッセージがログに記録されますが、認可ステータスには影響しません。初期化中に戻された場合は、エラー・メッセージがログに記録されます。 |
ObAzplug-instatusAccessAllowed |
プラグインにより、リクエスタによるターゲットへのアクセスが認可されます。このプラグインが認可プラグインである場合、認可処理は中止され、アクセス・サーバーは成功アクション処理に進みます。このプラグインがカスタム・アクション・プラグインである場合、このレスポンスは無視されます。 |
ObAzplug-instatusAccessDenied |
リクエスタによるターゲットへのアクセスが拒否されます。このプラグインが認可プラグインである場合、認可処理は中止され、アクセス・サーバーは拒否されたアクション処理に進みます。このプラグインがカスタム・アクション・プラグインである場合、このレスポンスは無視されます。 |
ObAzplug-instatusContinue |
認可またはカスタム・アクション処理は、プラグインの終了後も続行されます。 |
プラグインがSetDataFnをコールしてデータをObAzPluginInfo構造体に書き込む場合、アクセス・サーバーがこの処理を実行しようとし、このカテゴリの値を1つ戻します。
typedef enum { ObAzASStatusSuccess = 0, ObAzASStatusWriteNotAllowed = 1 }ObAzASStatus_t;
名前 | 目的 |
---|---|
ObAzASStatusSuccess |
アクセス・サーバーで操作が正常に実行されました。 |
ObAzASStatusWriteNotAllowed |
アクセス・サーバーで操作が実行されませんでした。具体的には、プラグインが変更が許可されていない値を変更しようとしました。 |
アクセス・サーバーは、関連するデータ項目を名前付きの構造体にまとめ、これらにメモリーを割り当て、この構造体内にあるデータを保持します。APIは、ハンドルを使用してこれらの構造体に対するデータの読取りおよび書込みを行います。構造体はユーザーからは不透明です。つまり、構造体を使用してアクセス・サーバーと情報をやり取りできますが、構造体の編成方法や構造体に含まれるデータの形式は変更できません。認可プラグインAPIで使用される構造体は、次のとおりです。
この構造体は、プラグインで必要となるアクセス・サーバーに関する情報を転送するために使用します。この構造体には2つのメンバーがあります。
const *ObAzserverContext{ char *AccessServerInstallDir; char *AccessServerAzPluginAPIVersion; };
*ObAzServerContext_t定数は、この構造体の先頭を指すハンドルです。
この構造体に保持されているデータは読取り専用です。
次の表は、構造体のメンバーを示しています。
名前 | 説明 |
---|---|
AccessServerInstallDir |
アクセス・サーバーのインストール・ディレクトリへのパス |
AccessServerAzPluginAPI Version |
アクセス・サーバーが現在サポートしている認可プラグインAPIの最も古いバージョン |
アクセス・サーバーは、スキームを使用する認可ルールとともに、プラグインを使用する認可スキームによって決定されたデータをこの構造体に組み込みます。プラグインでは、処理の進行とともに、構造体内部のデータが変更され、場合によっては新規データが追加されます。ポリシー内で複数の認可ルールが実行される場合は、この構造体は、ルール内の1つのプラグインから別のプラグインに情報を渡す手段ともなります。
struct ObAzPluginInfo{ ObAzPluginData_tRequesterInfo; ObAzPluginData_tRequestContext; ObAzPluginData_tParams; ObAzPluginWritableData_tContext; ObAzPluginWritableData_tActionInfo; };
*ObAzPluginInfo_t定数は、この構造体を指すハンドルです。
ObAzPluginWritableData_tのデータ型は、読取りと書込みの両方が可能です。ObAzPluginData_tのデータ型は、読取り専用です。
構造体からのデータの抽出や構造体へのデータの格納には、「ObAzPluginFns」で説明されている関数が使用されます。
次の表は、この構造体のメンバーによって提供される情報を示しています。
データ型および名前 | 説明 |
---|---|
RequesterInfo |
リソースにアクセスしようとするユーザーまたはアプリケーションに関するデータ。プラグインはこの情報を変更できません。アクセス・サーバーでは、このリスト内にRequesterDnとRequesterIPという2つの名前が事前に定義されています。認可スキームの構成時に、ユーザー・パラメータとして他の名前を追加することもできます。入力したパラメータは、ディレクトリに表示される属性の名前になります。アクセス・サーバーでは、属性の名前とこの属性のエントリの値が提供されます。 |
RequestContext |
プラグインに渡されるリクエスト固有の情報(リソース・タイプなど)。プラグインはこの情報を変更できません。アクセス・サーバーでは、このリスト内にResourceType、ResourceおよびOperationという3つの名前が事前に定義されています。ユーザーは他の名前を追加できません。 |
Params |
プラグイン構成に指定されている必須、オプションおよび追加パラメータすべての名前と値。プラグインはこの情報を変更できません。名前は、システムまたはマスター・アクセス管理者が認可スキームを初めて作成するときに作成されます。値は、スキームを初めて作成するときに指定するか、認可ルールでスキームを使用するときに委任アクセス管理者が後で追加することが可能です。 |
Context |
プラグインは、このデータを使用して情報を一時的に格納または転送します。たとえば、論理モジュール間で移動するときにそれ自体の状態を追跡する場合や、情報を別のプラグインに渡す場合に使用します。プラグインでは、新規データの追加や既存データの置換が可能です。アクセス・サーバーは、認可リクエストが完了するまでこのデータを保持します。 |
ActionInfo |
プラグインは、このデータを使用して認可結果などの情報をアクセス・ゲートに戻します。プラグインでは、新規データの追加や既存データの置換が可能です。アクセス・サーバーは、認可リクエストが完了し、クライアントに提供されるまでこのデータを保持します。 |
認可プラグインAPIの動作を理解する上で、ObAzPluginInfo構造体の構成を理解することは重要です。
認可プラグインAPIでは、構造体のすべてのメンバーに複数の値があります。つまり、各構造体に保持されている名前ごとに複数の値がある場合があります。それぞれの名前には、1つ以上の項目のリストを指すハンドルが関連付けられています。各項目には、値に加えて、リスト内の次の項目を指すハンドルがあります。次の項目を指すハンドルがNULLに設定されている場合、リストの最後であることを示します。
paramsメンバーの動作は、次のダイアグラムのようになります。GetDataFnを使用して、params配列内の特定のパラメータ名に関するリストを指すポインタを取得します。次に、GetFirstItemFnを使用して、リスト内の最初の項目に関する情報を指すハンドルを取得します。ここでGetValueFnを使用することで項目1の値が戻され、GetNextFnを使用することで項目2の情報を指すハンドルが戻される、というように続いていきます。
図7-1は、認可プラグインAPIのプロセス・フローを示しています。
この構造体には、プラグインでObAzPluginInfo構造体のデータを操作するために使用される、アクセス・サーバーによって提供される関数のブロックを指すハンドルが用意されています。
struct ObAzPluginFns ObAzPluginFns_t{ ObASPluginGetFirstItem_tGetFirstItemFn; ObASPluginGetValue_tGetValueFn; ObASPluginGetNext_tGetNextFn; ObAzPluginGetData_tGetDataFn; ObAzPluginsetData_tSetDataFn; };
次の表は、この構造体のメンバーを示しています。データの編成方法の詳細は、「ObAzPluginInfo」を参照してください。
注意: ObAzPluginFns_t定数は、この構造体を指すハンドルです。 |
名前 | 説明 |
---|---|
GetFirstItemFn |
名前に関連付けられたリスト内の最初の項目を指すハンドルを取得する関数。 |
GetValueFn |
GetFirstItemFnまたはGetNextFnを使用して項目のハンドルが定義された後に項目の値を読み取る関数。 |
GetNextFn |
名前に関連付けられたリスト内の次の項目を指すハンドルを取得する関数。戻されたハンドル値がNULLである場合、リスト内にこれ以上項目がないことを示します。 |
GetDataFn |
名前にテキスト値が指定されている場合、ObAzPluginInfo構造体の特定のメンバー内の名前を指すハンドルを取得する関数。戻されたハンドル値がNULLである場合、指定した名前がこの構造体のメンバーにはないことを示します。 |
SetDataFn |
名前にテキスト値が指定されている場合、ObAzPluginInfo構造体の特定のメンバー内の名前に値を格納する関数。 |
このAPIでアクセス・サーバーとの通信に使用される関数には2つのタイプがあります。1つのタイプは、アクセス・サーバーによって提供される関数で、アクセス・サーバーを参照することでコールされます。もう1つのタイプは、プラグインに実装する関数です。実装には、authz_plugin_api.h内のプロトタイプを使用します。
これらの関数は、渡された構造体のデータを取得および設定します。これらの関数を使用するには、コードで指定したObAzPluginFnsタイプの構造体のメンバーとしてコールする必要があります。たとえば、ObAzPluginFnを実装し、ObAzPluginFnsタイプの変数名をpFnBlockに設定した場合、pFnBlock→GetDataFnのように、構造体内の位置を参照することによってGetDataFnをコールします。
プラグインは、この関数を使用して、ObAzPluginInfo構造体のメンバーの1つの名前に関連付けられた値リストの先頭を指すハンドルを取得します。次に、プラグインは、リスト操作関数GetFirstItemFn、GetValueFn、GetNextFn、GetValueFnなどを使用してリストから情報を抽出する必要があります。この関数の書式は次のとおりです。
ObASPluginList_t GetDataFn( ObAzPluginData_tpmember, const char*pName);
入力パラメータ
名前 | 説明 |
---|---|
pmember |
名前が含まれることが想定されるObAzPluginInfo構造体のメンバー |
pName |
値を取得する対象の名前 |
出力パラメータ
この関数には出力パラメータはありません。
この関数からは、指定した名前の値からなるリストへのハンドルが戻されます。ハンドルの値がNULLの場合、指定した名前はこの構造体のメンバーにはありません。
プラグインは、この関数を使用して、ObAzPluginInfo構造体のメンバーの1つの名前に対する単一値を格納します。この関数の書式は次のとおりです。
ObAzASStatus_t SetDataFn( ObAzPluginData_t pMember, const char* pName, const char* Value, const int replace);
入力パラメータ
名前 | 説明 |
---|---|
pMember |
ObAzPluginInfo構造体の書込み可能メンバーの名前。 |
pName |
値を設定する情報の名前。 |
pValue |
挿入する値。 |
replace |
名前の既存の値を置換するかまたはそれに追加するかを指定します。値に0を指定すると、追加になります。0以外の値は、pNameの現在の第1の値を置換するリクエストとなります。 |
この関数には出力パラメータはありません。
出力パラメータ
この関数は、ObAzASStatus_tの値の1つを戻します。
注意: replaceオプションは、リスト内の最初の項目にのみ適用されます。 |
プラグインは、GetDataFnを使用してリストの先頭を指すハンドルが取得された後、この関数を使用して、値リストの最初の項目を指すハンドルを取得します。次に、GetValueFnを使用して値を抽出するか、GetNextFnを使用してリスト内の次の項目を指すハンドルを取得する必要があります。
この関数の書式は次のとおりです。
ObASPluginListItem_t GetFirstItemFn( ObASPluginList_tplist);
入力パラメータ
名前 | 説明 |
---|---|
pList |
GetDataFnによって戻される値リストの先頭を指すハンドル |
出力パラメータ
この関数には出力パラメータはありません。
この関数は、値リスト内の最初の項目を指すハンドルを戻します。ハンドル値がNULLである場合、最初の項目はありません。
これらの関数は、.dllに含まれる必要があるエントリ・ポイントを記述します。これらの5つの関数のプロトタイプは、authz_plugin_api.hに用意されています。これらはすべてプラグインに実装する必要があります。
OBDLLEXPORTエントリは各メソッドに必要です。このエントリにより、アクセス・サーバーがプラグイン内でこれらのメソッドを特定してコールする手段が提供されます。
アクセス・サーバーではこれらの関数がこの順序でコールされます。
GetVersion: プラグインの初回のロード時にコールされます。
Init: プラグインの初回のロード時にコールされます。
DeAllocStatusMessage: ステータス・メッセージを戻す他の任意の関数に続いて自動的にコールされます。
Fn: プラグインの使用時に毎回コールされます。
Terminate: アクセス・サーバーの停止時またはプラグインのアンロード時にコールされます。
アクセス・サーバーは、プラグインの初回ロード時にこの関数を1回コールします。プラグインは、ビルド時に使用されたauthz_plugin_api.hファイルに定義されているバージョン番号を戻します。アクセス・サーバーは、このバージョンを使用して、プラグインをサポート可能であるかどうかを確認します。つまり、古いバージョンのアクセス・サーバーがより新しいバージョンのAPIをサポートするよう求められていたのか、新しいバージョンのアクセス・サーバーがサポートの終了したバージョンのプラグインをサポートするよう求められていたのかを把握します。
この関数の書式は次のとおりです。
OBDLLEXPORT const char* ObAzPluginGetVersion(void)
入力パラメータ
この関数には入力パラメータはありません。
出力パラメータ
この関数には出力パラメータはありません。
この関数は、認可プラグインのバージョンを戻します。
アクセス・サーバーは、バージョンを確認した後、この関数をコールします。ObAzPluginInitを使用して、データベースへの接続やプラグインのグローバル・データの初期化などのタスクを含むプラグインの作業領域を初期化します。この関数は、pResult文字列を戻すためのメモリーを割り当てます。このメモリーは、後でObAzPluginDeallocStatusMsgを使用して割当てを解除する必要があります。
この関数の書式は次のとおりです。
OBDLLEXPORT ObAzplug-instatus_t ObAzPluginInit( ObAzServerContext_tpServerContext, ObAzplug-instatusMsg_tpResult)
入力パラメータ
名前 | 説明 |
---|---|
pServerContext |
アクセス・サーバーから提供されるコンテキスト情報構造にプラグインから割り当てられる名前 |
出力パラメータ
名前 | 説明 |
---|---|
pResult |
関数によって報告される結果メッセージ |
この関数は、次の表に示すObAzASStatus_tの2つの値のいずれかを戻す必要があります。
名前 | 説明 |
---|---|
ObAzplug-instatusContinue |
作業領域は正常に初期化されました。いずれかのタイプのその他プラグイン(存在する場合)が引き続き処理されます。 |
ObAzplug-instatusAbort |
初期化に失敗しました。どちらのタイプのその他プラグインも処理されません。 |
アクセス・サーバーは、アクセス・サーバーの終了時またはプラグインのアンロード時にこの関数をコールします。この関数は、データベースからの切断やメモリーの解放など、プラグインの作業領域の消去に使用します。
この関数の書式は次のとおりです。
OBDLLEXPORT ObAzplug-instatus_t ObAzPluginTerminate( ObAzServerContext_tpServerContext, ObAzplug-instatusMsg_tpResult);
入力パラメータ
名前 | 説明 |
---|---|
pServerContext |
アクセス・サーバーから提供されるコンテキスト情報構造にプラグインから割り当てられる名前 |
出力パラメータ
名前 | 説明 |
---|---|
pResult |
関数によって報告される結果メッセージ |
この関数は、次の表に示すObAzASStatus_tの2つの値のいずれかを戻す必要があります。
名前 | 説明 |
---|---|
ObAzplug-instatusContinue |
作業領域は正常に消去されました。いずれかのタイプのその他プラグイン(存在する場合)が引き続き処理されます。 |
ObAzplug-instatusAbort |
作業領域は消去できませんでした。たとえば、データベースが停止中であったため、データベース接続を閉じることができなかった場合などです。プラグインの処理は終了します。 |
保護されているリソースがプラグインが含まれるポリシーの適用対象である認可を必要とする場合、アクセス・サーバーは常にこの関数をコールします。この関数を使用して、アクセスの拒否または許可に関する詳細な決定または一連の決定を下します。この関数は、カスタム認可またはカスタム・アクション・プロセスを定義します。
この関数の書式は次のとおりです。
BDLLEXPORT ObAzplug-instatus_t ObAzPluginFn( ObAzServerContext_tpServerContext, ObAzPluginFns_tpFuncBlock, ObAzPluginInfo_tpData)
入力パラメータ
名前 | 説明 |
---|---|
pServerContext |
アクセス・サーバーから提供されるコンテキスト情報構造に割り当てる名前。 |
pFuncBlock |
アクセス・サーバーに付属する関数のブロックへのハンドル。プラグインがデータを操作するために必要となります。このブロックには名前を指定します。 |
pData |
アクセス・サーバー内のObAzPluginInfo構造体を指すハンドル。この構造体には名前を指定します。 |
出力パラメータ
名前 | 説明 |
---|---|
pData |
プラグインによって変更されたデータのハンドル |
この関数は、次の表で説明されているObAzplug-instatus_tの値のいずれかを戻します。
名前 | 説明 |
---|---|
ObAzplug-instatusContinue |
プラグインのタイプとは関係なく、次のプラグインに進むようアクセス・サーバーに指示します。認可プラグインの場合、これは、プラグインがリクエスタに対してアクセスを明示的に許可または拒否しなかったことを示します。 |
ObAzplug-instatusAccessAllowed |
この結果が認可プラグインから得られた場合、リクエスタはターゲットへのアクセスを許可されます。アクセス・サーバーは、認可プラグインの評価を中止し、成功したアクション・プラグイン(存在する場合)に進みます。カスタム・アクション・プラグインの場合、このステータスは無視されます。 |
ObAzplug-instatusAccessDenied |
この結果が認可プラグインから得られた場合、リクエスタはターゲットへのアクセスを拒否されます。アクセス・サーバーは、認可プラグインの評価を中止し、拒否されたアクション・プラグイン(存在する場合)に進みます。カスタム・アクション・プラグインの場合、このステータスは無視されます。 |
ObAzplug-instatusAbort |
この関数の後は、プラグインのタイプと関係なく、処理は続行されません。この結果が認可プラグインから得られた場合、認可は失敗です。 |
アクセス・サーバーは、プラグインの終了時にこの関数をコールします。この関数を使用して、ステータス・メッセージを戻したその他のプラグインによって割り当てられているメモリーを削除します。
この関数の書式は次のとおりです。
OBDLLEXPORT void ObAzPluginDeallocStatusMsg( ObAzplug-instatusMsg_tpStatusMsg);
入力パラメータ
名前 | 説明 |
---|---|
pStatusMsg |
メモリーの割当てを解除するステータス・メッセージ |
出力パラメータ
この関数には出力パラメータはありません。
この関数は何も戻しません。
例7-1は、プラグイン関数の基本的な使用例を示しています。これは、Access Systemインストールの一部として用意されているauthz_api.cサンプル関数を変更したものです。
例7-1 認可プラグインの例
OBDLLEXPORT const char* ObAzPluginGetVersion(void) { FILE *file = fopen("d:\\AZtestfile.txt", "a+"); fprintf (file, "\n%s %s\n", "getting version, it is", OB_AZ_PLUGIN_VERSION); fclose(file); return OB_AZ_PLUGIN_VERSION; } /* * ----------------------------------------------- * Implementation of ObAnPluginInit * * The logged data appears only once, when the Plugin is first loaded. * */ OBDLLEXPORT ObAzplug-instatus_t ObAzPluginInit(ObAzServerContext_t pContext, ObAzplug-instatusMsg_t pResult) { // Values to be read in by this function are initialized. ObAzplug-instatus_t rtval; const char* pASPluginVersion = NULL; FILE *file = fopen("d:\\AZtestfile.txt", "a+"); fprintf (file, "\n%s\n", "initializing"); if(pContext != NULL) { pASPluginVersion = pContext->AccessServerAzPluginAPIVersion; } if((pASPluginVersion != NULL) && (strcmp(pASPluginVersion, OB_AZ_PLUGIN_VERSION) == 0)) { rtval = ObAzplug-instatusContinue; *pResult = strdup("Success version check"); } else { /* * return failure, because the version provided by the AS * is not what was expected. */ rtval = ObAzplug-instatusAbort; } fclose(file); return rtval; } /* * ----------------------------------------------- * Implementation of ObAnPluginTerminate * * The logged data appears only when the Access Server terminates. * */ OBDLLEXPORT ObAzplug-instatus_t ObAzPluginTerminate (ObAzServerContext_t pContext, ObAzplug-instatusMsg_t pResult) { FILE *file = fopen("d:\\AZtestfile.txt", "a+"); fprintf (file, "\n%s\n", "terminating gracefully"); *pResult = strdup("Success, terminated"); fclose(file); return ObAzplug-instatusContinue; } /* * ----------------------------------------------- * Implementation of ObAnPluginDeallocStatusMsg * The logged data appears following each other function * that provides a presult. */ OBDLLEXPORT void ObAzPluginDeallocStatusMsg (ObAzplug-instatusMsg_t pResult) { FILE *file = fopen("d:\\AZtestfile.txt", "a+"); fprintf (file, "\n%s\n", "deallocating"); if(pResult != NULL && *pResult != NULL) { free(*pResult); *pResult = NULL; } fclose(file); } /* * ----------------------------------------------- * Implementation of ObAnPluginFn */ OBDLLEXPORT ObAzplug-instatus_t ObAzPluginFn (ObAzServerContext_t pContext, ObAzPluginFns_t pFnBlock, ObAzPluginInfo_t pInfo) { /* * Default will be to continue without granting or denying * authorization. */ ObAzplug-instatus_t rtval = ObAzplug-instatusContinue; * Pointers are defined. */ ObASPluginList_t list; ObASPluginListItem_t item; /* * Data that might be read in is initialized. */ const char* ou = NULL; const char* deny1 = NULL; const char* deny2 = NULL; const char* allow1 = NULL; const char* allow2 = NULL; const char* allow3 = NULL; const char* allow4 = NULL; int i = 0; FILE *file = fopen("d:\\AZtestfile.txt", "a+"); fprintf (file, "\n%s\n", "doing real work"); if((pFnBlock != NULL) && (pInfo != NULL)){ fprintf (file, "%s\n", "first test okay, getting ou"); /* * get user's "ou" from pInfo. */ list = pFnBlock->GetDataFn(pInfo->RequesterInfo, "ou"); item = pFnBlock->GetFirstItemFn(list); ou = pFnBlock->GetValueFn(item); } /* * show the ou value. */ if(ou != NULL){ fprintf (file, "%s\n", "ou was not null"); fprintf (file,"%s %s \n", "ou is", ou); } else { fprintf (file, "%s\n", "ou was not found"); rtval = ObAzplug-instatusAccessDenied; pFnBlock->SetDataFn (pInfo->ActionInfo, "access_status", "deny", 1); fclose(file); return rtval; ) /* * now get two deny_organization values. * This is risky coding, since it could be that "deny_organization" * does not exist, or only has one value. In either case, the code * will be generating NULL pointers, which could be misused elsewhere */ list = pFnBlock->GetDataFn(pInfo->Params, "deny_organization"); if(list == NULL){ fprintf (file, "%s\n", "missing deny org"); rtval = ObAzplug-instatusAccessDenied; pFnBlock->SetDataFn (pInfo->ActionInfo, "access_status", "deny", 1); fclose(file); return rtval; } item = pFnBlock->GetFirstItemFn(list); deny1 = pFnBlock->GetValueFn(item); fprintf (file,"%s %s \n", "deny1 is", deny1); item = pFnBlock->GetNextFn(item); deny2 = pFnBlock->GetValueFn(item); fprintf (file,"%s %s \n", "deny2 is", deny2); /* * now get up to 4 allow_organization values. */ list = pFnBlock->GetDataFn(pInfo->Params,"allow_organization"); if(list == NULL){ fprintf (file, "%s\n", "missing allow org"); rtval = ObAzplug-instatusAccessDenied; pFnBlock->SetDataFn (pInfo->ActionInfo, "access_status", "deny", 1); fclose(file); return rtval; } /* * This is a better approach; it avoids generating null pointers. */ for(i = 0, item = pFnBlock->GetFirstItemFn(list); item != NULL; i++, item = pFnBlock->GetNextFn(item)) { switch(i) { case 0: allow1 = pFnBlock->GetValueFn(item); fprintf (file,"%s %s \n", "allow1 is", allow1); break; case 1: allow2 = pFnBlock->GetValueFn(item); fprintf (file,"%s %s \n", "allow2 is", allow2); break; case 2: allow3 = pFnBlock->GetValueFn(item); fprintf (file,"%s %s \n", "allow3 is", allow3); break; case 3: allow4 = pFnBlock->GetValueFn(item); fprintf (file,"%s %s \n", "allow4 is", allow4); break; }}
次の画面は、アクセス管理者が設定する認可スキームの初期設定を示しています。必須パラメータに入力する領域が残されていますが、値は入力されていません。
後で、この認可スキームを使用するリソースを対象とするポリシーを定義するときに、委任アクセス管理者が残りの必須パラメータ値を入力します。次の例では、別の値も追加されています。
このバージョンの認可スキームの場合、サンプル・コードに対応するトレース情報は、次のようになります。
initializing deallocating doing real work first test okay, getting ou ou was not null ou is Sales deny1 is nosuch deny2 is reqdenparam allow1 is sales allow2 is addallowparam allow3 is optallowparam access was allowed
次の各項では、マネージ・コードAPIインタフェースについて説明します。
managed_plugin_interface.hファイルには、プログラミングを補助するために複数の値が定義されています。その1つとして、ObAzPluginGetVersionがコールされたときにアクセス・サーバーに戻される値があります。
#define OB-AZ_PLUGIN_VERSION "10.1.3"
注意: バージョンに関して提供される値は、後続のバージョンでは異なる場合があります。 |
アクセス・サーバーおよびAPIでは、インタフェースを使用して、プラグインで使用できるようアクセス・サーバーが保守するデータ構造を操作します。これらのインタフェースの名前と説明は、次の表を参照してください。
名前 | 説明 |
---|---|
IObASPluginListItem |
値リスト内の項目の1つにアクセスする関数が用意されているインタフェース |
IObAzPluginData |
読取り専用値のリストにアクセスする関数が用意されているインタフェース |
IObAzPluginInfo |
プラグインが使用可能な様々なデータ項目にアクセスする関数が用意されているインタフェース |
IObAzPluginWritableData |
値リストにアクセスして変更する関数が用意されているインタフェース |
IObAzServerContext |
サーバーのコンテキスト情報にアクセスする関数が用意されているインタフェース |
アクセス・サーバーおよびAPIが通信用として使用する関数の多くは、ステータス値を戻します。これらの詳細は、次の項を参照してください。
認可の試行結果を示すためにプラグインが戻すことが可能な値を次に示します。
IObAuthzPlugin::Status { ObAzpluginstatusContinue = 0, ObAzpluginstatusAccessAllowed = 1, ObAzpluginstatusAccessDenied = 2, ObAzpluginstatusAbort = 3
名前 | 意味 |
---|---|
ObAzpluginStatus Abort |
プラグイン内で致命的エラーが発生したことを示します。処理は次のプラグイン(存在する場合)には渡されません。認可プラグインからこのエラーが戻された場合、認可が失敗し、アクセスは拒否されます。カスタム・アクション・プラグインからこのエラーが戻された場合、エラー・メッセージがログに記録されますが、認可ステータスには影響しません。初期化中に戻された場合は、エラー・メッセージがログに記録されます。 |
ObAzpluginStatus AccessAllowed |
プラグインにより、リクエスタによるターゲットへのアクセスが認可されます。このプラグインが認可プラグインである場合、認可処理は中止され、アクセス・サーバーは成功アクション処理に進みます。このプラグインがカスタム・アクション・プラグインである場合、このレスポンスは無視されます。 |
ObAzpluginStatus AccessDenied |
リクエスタによるターゲットへのアクセスが拒否されます。このプラグインが認可プラグインである場合、認可処理は中止され、アクセス・サーバーは拒否されたアクション処理に進みます。このプラグインがカスタム・アクション・プラグインである場合、このレスポンスは無視されます。 |
ObAzpluginStatus Continue |
認可またはカスタム・アクション処理は、プラグインの終了後も続行されます。 |
プラグインがset_DataをコールしてデータをObAzPluginInfo構造体に書き込む場合、アクセス・サーバーがこの処理を実行しようとし、次のいずれかの値を戻します。
IObAuthzPlugin::ASStatus { ObAzASStatusSuccess = 0, ObAzASStatusWriteNotAllowed = 1 };
名前 | 意味 |
---|---|
ObAzASStatusSuccess |
アクセス・サーバーで操作が正常に実行されました。 |
ObAzASStatusWrite NotAllowed |
アクセス・サーバーで操作が実行されませんでした。具体的には、プラグインが変更を許可されていない値を変更しようとしました。 |
アクセス・サーバーでは、関連するデータ項目を構造体にまとめ、様々なメンバーへのアクセス用のインタフェースを提供します。認可プラグインAPIで使用されるインタフェースは、次のとおりです。
この構造体は、プラグインで必要となるアクセス・サーバーに関する情報を転送するために使用します。この構造体には2つのメンバーがあります。
public _gc _interface IObAzServerContext { _property String* get_AccessServerInstallDir(); _property String* get_AccessServerAzPluginAPIVersion(); };
名前 | 説明 |
---|---|
get_AccessServer InstallDir |
アクセス・サーバーのインストール・ディレクトリへのパス |
get_AccessServerAz PluginAPIVersion |
アクセス・サーバーが現在サポートしている認可プラグインAPIの最も古いバージョン |
この構造体には、スキームを使用する認可ルールとともに、プラグインを使用する認可ルールで設定されたデータがアクセス・サーバーによって格納されます。プラグインでは、処理の進行とともに、構造体内部のデータが変更され、場合によっては新規データが追加されます。ポリシー内で複数の認可ルールが実行される場合は、この構造体は、ルール内の1つのプラグインから別のプラグインに情報を渡す手段ともなります。
public _gc _interface IObAzPluginInfo { IObAzPluginData* GetRequesterInfo(); IObAzPluginData* GetRequestContext (); IObAzPluginData* GetParams (); IObAzPluginWritableData* GetContext (); IObAzPluginWritableData* GetActionInfo ();
IObAzPluginWritableDataのデータ型は、読取りと書込みの両方が可能です。IObAzPluginDataのデータ型は、読取り専用です。
次の表は、この構造体のメンバーによって提供される情報を示しています。
名前 | 説明 |
---|---|
GetRequestInfo |
リソースにアクセスしようとするユーザーまたはアプリケーションに関するデータを戻します。プラグインはこの情報を変更できません。アクセス・サーバーでは、このリスト内にRequesterDnとRequesterIPという2つの名前が事前に定義されています。認可スキームの構成時に、ユーザー・パラメータとして他の名前を追加することもできます。入力したパラメータは、ディレクトリに表示される属性の名前になります。アクセス・サーバーでは、属性の名前とこの属性のエントリの値が提供されます。 |
GetRequestContext |
プラグインに渡されるリクエスト固有の情報(リソース・タイプなど)を戻します。プラグインはこの情報を変更できません。アクセス・サーバーでは、このリスト内にResourceType、ResourceおよびOperationという3つの名前が事前に定義されています。ユーザーは他の名前を追加できません。リクエスト・コンテキストの操作の詳細は、「C定数の定義」を参照してください。 |
GetParams |
プラグイン構成に指定されている必須、オプションおよび追加パラメータすべての名前と値を戻します。プラグインはこの情報を変更できません。名前は、システムまたはマスター・アクセス管理者が認可スキームを初めて作成するときに作成されます。値は、スキームを初めて作成するときに指定するか、認可ルールでスキームが使用されるときに委任アクセス管理者が後で追加することが可能です。 |
GetContext |
プラグインは、このデータを使用して情報を一時的に格納または転送します。たとえば、論理モジュール間で移動するときにそれ自体の状態を追跡する場合や、情報を別のプラグインに渡す場合に使用します。プラグインでは、新規データの追加や既存データの置換が可能です。アクセス・サーバーは、認可リクエストが完了するまでこのデータを保持します。 |
GetActionInfo |
プラグインは、このデータを使用して認可結果などの情報をアクセス・ゲートに戻します。プラグインでは、新規データの追加や既存データの置換が可能です。アクセス・サーバーは、認可リクエストが完了し、クライアントに提供されるまでこのデータを保持します。 |
認可プラグインAPIでは、構造体のすべてのメンバーに複数の値があります。つまり、各構造体に保持されている名前ごとに複数の値がある場合があります。それぞれの名前には、1つ以上の項目のリストが関連付けられています。各項目には値があります。
このインタフェースには、項目のリストを取得するための関数が用意されています。
public _gc _interface IObAzPluginData { _property IEnumerator* get_Data(String* pName); };
このインタフェースには、項目のリストを取得および設定する関数が用意されています。
public _gc _interface IObAzPluginWritableData { IEnumerator* get_Data(String* pName); IObAuthzPlugin::ASStatus set_Data(String* key, String* val, Oblix::ObListOper operation); };
プラグインは、この関数を使用して、ObAzPluginInfo構造体のメンバーの1つの名前に関連付けられた値リストを取得します。次に、プラグインは、列挙関数Current、MoveNextおよびResetを使用して、リストから項目を取得する必要があります。
名前 | 目的 |
---|---|
pName |
値を取得する対象の名前 |
この関数は、IEnumeratorインタフェースを実装するオブジェクトを戻します。
プラグインは、この関数を使用して、ObAzPluginInfo構造体のメンバーの1つの名前に対する単一値を格納します。この関数の書式は次のとおりです。
名前 | 目的 |
---|---|
key |
値を設定する情報の名前。 |
Val |
挿入する値。 |
operation |
名前の既存の値を置換するかまたはそれに追加するかを指定します。ObListOper::ObAddという値は、追加を示します。その他のすべての値は、keyの現在の第1の値を置換するリクエストとなります。 |
この関数は、ObAzASStatus_tの値の1つを戻します。
注意: replaceオプションは、リスト内の最初の項目にのみ適用されます。 |
認可プラグインの場合、プラグイン開発者は、次の関数を使用してクラスを定義する必要があります。
namespace sample { public _gc class ObAuthzPlugin { public: ObAuthzPlugin(); String* ObAzPluginGetVersion(); IObAuthzPlugin::Status ObAzPluginInit (Oblix::IObAzServerContext* context, String* msg); IObAuthzPlugin::Status ObAzPluginFn(Oblix::IObAzServerContext* context, Oblix::IObAzPluginInfo* info); IObAuthzPlugin::Status ObAzPluginTerminate (Oblix::IObAzServerContext* context, String* msg); }; };
このクラスには、ObAuthzPluginという名前を付ける必要がありますが、名前空間に含まれていても含まれていなくてもかまいません。すべての関数にパブリック・アクセスが必要です。
アクセス・サーバーは、次の順序でこのクラスの関数をコールします。
ObAzGetVersion: プラグインの初回のロード時にコールされます。
ObAzPluginInit: プラグインの初回のロード時にコールされます。
ObAzPluginFn: プラグインの使用時に毎回コールされます。
ObAzPluginTerminate: アクセス・サーバーの停止時にコールされます。
アクセス・サーバーは、プラグインの初回ロード時にこの関数を1回コールします。プラグインは、ビルド時に使用されたmanaged_plugin_interface.hファイルに定義されているバージョン番号を戻します。アクセス・サーバーは、このバージョンを使用して、プラグインをサポート可能であるかどうかを確認します。つまり、古いバージョンのアクセス・サーバーがより新しいバージョンのAPIをサポートするよう求められていたのか、新しいバージョンのアクセス・サーバーがサポートの終了したバージョンのプラグインをサポートするよう求められていたのかを把握します。
アクセス・サーバーは、バージョンを確認した後、この関数をコールします。ObAsPluginInitを使用して、データベースへの接続やプラグインのグローバル・データの初期化などのタスクを含めるプラグインの作業領域を初期化します。
名前 | 説明 |
---|---|
pServerContext |
アクセス・サーバーから提供されるコンテキスト情報構造にプラグインから割り当てられる名前 |
この関数は、次の表に示すObAzASStatusの2つの値のいずれかを戻す必要があります。
名前 | 説明 |
---|---|
ObAzpluginStatusContinue |
作業領域は正常に初期化されました。 |
ObAzpluginStatusAbort |
初期化に失敗しました。 |
アクセス・サーバーは、終了時にこの関数をコールします。この関数は、データベースからの切断などのため、プラグインの作業領域を消去します。
名前 | 説明 |
---|---|
pServerContext |
アクセス・サーバーから提供されるコンテキスト情報構造にプラグインから割り当てられる名前 |
この関数は、次の表に示すObAzASStatus_tの2つの値のいずれかを戻す必要があります。
名前 | 説明 |
---|---|
ObAzpluginStatus Continue |
作業領域は正常に初期化されました。 |
ObAzpluginStatusAbort |
初期化に失敗しました。 |
保護されているリソースがプラグインが含まれるポリシーの適用対象である認可を必要とする場合、アクセス・サーバーはこの関数をコールします。この関数を使用して、アクセスの拒否または許可に関する詳細な決定または一連の決定を下します。この関数は、カスタム認可またはカスタム・アクション・プロセスを定義します。
名前 | 説明 |
---|---|
pServerContext |
アクセス・サーバーから提供されるコンテキスト情報構造に割り当てる名前。 |
pInfo |
アクセス・サーバー内のObAzPluginInfo構造体を指すハンドル。この構造体には名前を指定します。 |
この関数は、次の表に示すObAzpluginstatus_tの値のいずれかを戻します。
名前 | 説明 |
---|---|
ObAzpluginStatus Continue |
プラグインのタイプとは関係なく、次のプラグインに進むようアクセス・サーバーに指示します。認可プラグインの場合、これは、プラグインがリクエスタに対してアクセスを明示的に許可または拒否しなかったことを示します。 |
ObAzpluginStatus AccessAllowed |
この結果が認可プラグインから得られた場合、リクエスタはターゲットへのアクセスを許可されます。アクセス・サーバーは、認可プラグインの評価を中止し、拒否されたアクション・プラグイン(存在する場合)に進みます。カスタム・アクション・プラグインの場合、このステータスは無視されます。 |
ObAzpluginStatus AccessDenied |
この結果が認可プラグインから得られた場合、リクエスタはターゲットへのアクセスを拒否されます。アクセス・サーバーは、認可プラグインの評価を中止し、拒否されたアクション・プラグイン(存在する場合)に進みます。カスタム・アクション・プラグインの場合、このステータスは無視されます。 |
ObAzpluginStatus Abort |
この関数の後は、プラグインのタイプと関係なく、処理は続行されません。この結果が認可プラグインから得られた場合、認可は失敗です。 |
プラグインの単体テストでは、この章にあげた例のように結果をファイルへ書き込むのが最善の方法です。pResultテキストが取得されるのは、認証が失敗した場合で、アクセス・サーバーがSolaris上で動作している場合のみです。結果をファイルに書き込む場合、ファイルを格納するディレクトリに書き込むための適切な権限があることを確認してください。
パフォーマンスに関する責務はユーザーにあり、プラグインの設計時に考慮する必要があります。1つの認可リクエストの処理に要する合計時間は、リクエストの処理時に起動されるすべてのプラグインのパフォーマンスによって決まります。
プラグインは、アクセス・サーバーによって信頼されています。事前構成情報をプラグインに提供する場合、アクセス・チェックは実行されません。
メモリーまたはアクセス違反、セグメンテーション、バス・エラー障害などのプラグインのシステム・レベルのコーディング・エラーは、アクセス・サーバーで障害の原因となる可能性があります。
プラグインではオプションのパラメータを使用できます。通常、これらのパラメータは、委任管理者がスキームの作成時に入力します。プラグインは、これらのパラメータの値が指定されない状況にも問題なく対応できる必要があります。
理由がなくリクエストが失敗するような場合は、共有ライブラリのパスが正しいかどうか確認してください。