| Oracle Access Managerアクセス管理ガイド 10g（10.1.4.3） B55477-01 |
|
 戻る |
 次へ |
アクセス・システムでは、Webページやアプリケーションなどのリソースを保護できます。これらのリソースは、ポリシー・ドメインおよび個別のポリシーに属するものとして定義されます。アクセス・システムを使用してこれらのリソースを定義し、リソースの使用を許可されるユーザーとそうでないユーザー、およびその条件を指定します。
この章では、認可について説明し、認可ルールおよび認可条件式を構成してポリシー・ドメインおよびポリシーの要件を満たす方法を示します。認可ルールを組み合せて、認可条件式を作成します。ポリシー・ドメインは、そのリソースの保護方法を指定するデフォルト・ルールのセット内に、認可条件式を含んでいる必要があります。
この章の内容は次のとおりです。
認可とは、リソースに対するアクセスをユーザーに許可するかどうかを判定するプロセスです。リソースを保護するには、認可ルールを定義します。ルールには、1つ以上の条件が含まれます。1つ以上の認可ルールを使用して、認可条件式を構成します。ポリシー・ドメインおよびポリシーには、それぞれ1つの認可条件式のみを含めることができます。
最初にポリシー・ドメインを作成し、その後でポリシー・ドメインのルールおよび式を定義します。ポリシー・ドメインには、認証ルール、認可ルール、認可条件式および監査ルールを任意の順序で作成できます。
この章を読む前に、次の章を参照してください。
第3章「WebGateおよびアクセス・サーバーの構成」: アクセス・ゲートおよびアクセス・サーバーの構成について説明しています。構成は、作成したポリシー・ドメインを有効にする前に行う必要があります。
第4章「ポリシー・ドメインによるリソースの保護」: ポリシー・ドメインおよびポリシーの作成方法とテスト方法、リソース・タイプの定義方法および監査ルールの定義方法について説明しています。
第5章「ユーザー認証の構成」: 認証スキームおよびルールの作成および使用方法について説明しています。
認可ルールには次の条件を含めることができます。
保護されているリソースに誰がアクセスする権限があるかを指定する条件。
この条件は、ルールにおけるアクセスの許可条件と呼ばれます。
保護されているリソースへのアクセスを誰が拒否されるかを明示的に指定する条件。
この条件は、ルールにおけるアクセスの拒否条件と呼ばれます。
アクセスの許可条件またはアクセスの拒否条件、あるいはその両方が指定され、ユーザーがこれらの条件に該当しない場合、そのユーザーはルールの適用対象外とみなされ、デフォルトでは、リクエストしたリソースへのアクセスを拒否されます。
ルールでは、リソースへのアクセスをユーザーに許可するか否かを指定するために次のことができます。
ユーザー名、ロールまたは、ユーザーが満たす必要のある基準を含むLDAPフィルタによって、ユーザーを識別します。
ユーザーがリソースへのアクセスに使用できるコンピュータを指定します。
ルールが適用される時間帯を設定します。
また、ルールによって、ユーザーがリソースに対するアクセスを許可された場合とアクセスを拒否された場合に実行するアクションも設定できます。
ポリシー・ドメインのリソースを保護するには、1つ以上の認可ルールを含む認可条件式を構成します。
認可ルール。ポリシー・ドメインに定義された認可ルールから選択します。
ルールを組み合せるための演算子。ルールの組合せにより、ポリシー・ドメインに必要な認可保護を提供します。
認可条件式には、単一のルールを指定することも、より複雑な条件を表現するために組み合せた複数ルールのグループを指定することもできます。たとえば、ユーザーがリソースへのアクセス権を付与されるために2つのルールのアクセスの許可条件を満たすことを要求する式を作成できます。ルールを組み合せて式とするには、ポリシー・マネージャのユーザー・インタフェースを使用します。
この章では、ポリシー・マネージャの認可コンポーネントとその動作方法について説明します。また、リソースを認可条件式で保護する手順についても説明します。
次に、ポリシー・ドメインおよびポリシーの認可条件式を作成する手順の概要を示します。
第4章「ポリシー・ドメインによるリソースの保護」の手順に従って、ポリシー・ドメインを作成します。
「ユーザーの分類ガイドライン」を使用して、誰にどのような条件でポリシー・ドメインのリソースを使用する権限を持たせるかを決定します。
「認可ルールの概要」も参照してください。
特定のユーザーにリソースへのアクセスを許可し、特定のユーザーに対してアクセスを拒否することができます。ユーザーにアクセスを許可する場合も明示的に拒否する場合も、すべてのユーザーに適用できるルールを作成する必要はありません。
一部のユーザーをルールの条件の対象外とすることができます。これらのユーザーは、式のその他のルールの対象とすることも、どのルールの条件の対象ともしないこともできます。ユーザーが式のどのルールの条件の対象にもならない場合、デフォルトでは、このユーザーはリソースへのアクセスを拒否されます。
ポリシー・ドメインおよびポリシーのリソースを保護するために必要なすべての認可ルールを作成します。
詳細は、「認可ルールの構成」を参照してください。
これらのルールはすべてポリシー・ドメインのレベルで作成します。ルールを作成する際には、認可スキームを組み入れます。アクセス・システムに付属の認可スキームを使用しない場合は、1つ以上のカスタム認可スキームを構成する必要があります。この場合、カスタム・プラグインを用意する必要があります。詳細は、「カスタム・プラグインの認可スキームの概要」を参照してください。
ポリシー・ドメインの認可条件式を作成します。
ポリシー・ドメインに設定できる認可条件式は1つのみです。詳細は、「認可条件式の概要」を参照してください。
ポリシー・ドメインの各ポリシーの認可条件式を作成します。
詳細は、「認可条件式の概要」を参照してください。
|
注意: 認可条件式を構成して、ユーザーにリソースへのアクセスを許可するかどうかを決定する必要があります。認可条件式が定義されていない場合、ターゲット・リソースへのアクセスは拒否されます。 |
ユーザーの分類時は次のガイドラインに従ってください。
ユーザーおよびユーザー・グループを、異なる条件を適用するグループに分類します。
たとえば、ユーザーがリソースにアクセスできる時間帯や、ユーザーがリクエストを行う場合に使用する必要があるコンピュータなどの条件を指定できます。詳細は、「認可ルールの内容の概要」を参照してください。
ユーザーが複数のカテゴリに分類される場合、たとえば、マーケティング・グループに属するユーザーがTeleonプロジェクト・グループに属する場合、あるいは人事管理グループに属するユーザーがTeleonプロジェクト・グループにも属する場合などは、そのユーザーを両方のカテゴリに入れます。ユーザーが2つのルールの条件を満たすことを必須にすることができます。
|
注意: どの条件でもポリシー・ドメインのリソースへのアクセスを拒否するユーザーについて検討する必要はありません。式のどのルールの対象にもならないユーザーは、デフォルトでアクセスを拒否されます。 |
個別のルールを作成する各カテゴリに対し、ルールによりユーザーにリソースの使用を許可または拒否するかに応じて、実行するアクションを検討します。
たとえば、戻されたユーザー・プロファイル情報を次のように下流のアプリケーションに渡すこともできます。
ユーザーに使用権が認可された場合は、ユーザーのcn（共通名）を別のアプリケーションに渡し、そのアプリケーションでカスタマイズされた応答をユーザーに表示することが可能です。
ユーザーに使用権が認可されない場合も、ユーザーに関する情報が戻されると、セキュリティのために役立ちます。
アクションの詳細は、「認可アクションの概要」を参照してください。
この分析は、ポリシー・ドメインのリソースを使用する認可を付与するユーザー、および明示的に拒否するユーザーとグループに対して行います。
ポリシー・ドメイン内でリソースのサブセットに対してポリシーを作成し、そのサブセットを別の認可ルールで保護するには、ポリシーに対して同じ情報、つまり、誰にどのような条件でポリシーのリソースへのアクセスを許可し、誰にどのような条件でリソースへのアクセスを明示的に拒否するのかを検討します。
認可ルールは、リソースにアクセスできるユーザーと、リソースへのアクセスを明示的に拒否されるユーザーを識別します。ポリシー・ドメインまたはポリシーの認可条件式に、1つ以上の認可ルールを含めることができます。
ユーザーがリソースへのアクセスをリクエストし、そのリソースが認可条件式に含まれる認可ルールで保護されている場合、そのユーザーに関する情報がルールのとおりであるかどうかを確認します。ルールにその他の情報（ルールが適用される時間帯や日時など）が指定されている場合は、その情報もチェックされます。このプロセスは、ルールの評価と呼ばれます。
認可ルールの評価結果（認可条件式に複数の認可ルールが含まれている場合は、それらの認可ルールとも組み合せた評価結果）により、リクエストしたリソースへのアクセス権がユーザーに付与されるかどうかが判定されます。
ポリシー・ドメインまたはそのすべてのポリシーに使用する認可ルールは、すべてポリシー・ドメイン・レベルで作成します。これらのルールを組み合せて認可条件式を作成します。認可条件式の詳細は、「認可条件式の概要」を参照してください。
この項では、認可ルールと、その作成および管理方法について説明します。内容は次のとおりです。
アクセスの許可と呼ばれ、リソースへのアクセスをユーザーに付与する条件
アクセスの拒否と呼ばれ、リソースへのアクセスをユーザーに対して拒否する条件
ユーザーが認可ルールの対象であるということは、ルールで保護されているリソースを使用する権限があるということではありません。ルールの条件を満たす場合に、ユーザーはルールの対象になります。
アクセスの許可条件を満たす場合、ユーザーはルールのアクセスの許可部分の対象になります。
アクセスの拒否条件を満たす場合、ユーザーはルールのアクセスの拒否部分の対象になります。
アクセスの許可条件もアクセスの拒否条件も満たさない場合、ルールはそのユーザーにとって対象外と呼ばれます。これは、ユーザーがルールの対象外であることと同じ意味です。ルールを評価した結果、ユーザーが対象外となった場合、ユーザーはそのルールに基づいてリソースへのアクセスを拒否されます。
複数のルールを含む認可条件式に対しては、ユーザーは式のどのルールの対象にもならない場合や、1つのルールの対象になる場合、または複数のルールの条件の対象になる場合があります。どの場合にも、ユーザーがリソースへのアクセスを許可されるか拒否されるかは、いずれか1つのルールの評価ではなく、式、つまり、式のすべてのルールとその組合せ方法を評価した結果により決定されます。
ポリシー・ドメインには、1つの認可条件式のみを指定できます。認可条件式には、ポリシー・ドメインのリソースの保護要件を表現するために必要なすべての認可ルールを含めることができます。ポリシー・ドメインに含まれる各ポリシーには、独自の認可条件式を指定できます。
ポリシー・ドメインに定義するすべての認可ルールは、ポリシー・ドメインまたはポリシー・ドメインに含まれるすべてのポリシーに対して次の方法で使用できます。
複数の認可条件式に使用できます。
1つの認可条件式に複数回使用できます。
認可条件式の詳細は、「認可条件式の概要」を参照してください。
認可ルールには次の情報が含まれます。
一般情報: 認可ルールの名前と説明。また、ルールを有効化するか無効化するか。詳細は、「認可ルールの構成」を参照してください。
アクセスの許可: 認可ルールのアクセスの許可条件。ここには、ルールで保護されるリソースへのアクセスを許可するエンドユーザーおよびユーザー・グループを指定します。詳細は、「アクセスの許可の設定」を参照してください。
アクセスの拒否: 認可ルールのアクセスの拒否条件。ここには、ルールで保護されるリソースへのアクセスを明示的に拒否するエンドユーザーおよびユーザー・グループを指定します。詳細は、「アクセスの拒否の設定」を参照してください。
タイミング条件: 認可ルールは、リソースへのアクセスを特定の時間帯に制限する値を含むように構成できます。たとえば、あるユーザー・グループに平日の午前9時から午後5時までを設定し、別のユーザー・グループに午前10時から午後4時までを設定できます。詳細は、「タイミング条件の設定」を参照してください。
アクション: 認可ルールのいずれかの結果に対し、つまり、保護されているリソースへのアクセスをリクエストしているユーザーに対する認可成功または認可失敗という評価結果に対し、その結果に対応して実行する一連のアクションを関連付けて指定できます。たとえば、アクセス・システムでは下流のアプリケーションに渡すヘッダー変数を戻すことができます。指定可能なアクションの種類は次のとおりです。
アクションの詳細は、「認可アクションの概要」を参照してください。
保護されているリソースへのアクセスをリクエストしているユーザーに関する情報が認可ルールの条件に対してチェックされ、ユーザーがルールのいずれかの条件の対象になると、そのルールが評価されて次のいずれかの結果になります。
認可成功
この場合、ユーザーはリクエストしたリソースにアクセスできます。この結果は、ルールのアクセスの許可条件に関連付けられています。
認可失敗
この場合、ユーザーはリクエストしたリソースにアクセスできません。この結果は、ルールのアクセスの拒否条件に関連付けられています。
保護されているリソースへのアクセスをリクエストしているユーザーがルールのアクセスの許可条件にもアクセスの拒否条件にも指定されていない場合、ルールの評価結果はこのどちらにもなりません。この場合、ルールの評価は未確定となり、ユーザーはリクエストしたリソースへのアクセスを拒否されます。
ここでは、認可ルールの構成および管理の詳細について説明します。
認可ルールを構成するには、その一般情報を定義し、アクセスの許可およびアクセスの拒否条件を設定して、ルールのアクションを必要に応じて定義します。この項では、ルールの一般情報の構成方法について説明します。
認可ルールの一般情報は、ルールの識別、ルールの認可スキームの指定、ルールの有効化または無効化などを行うために指定できます。構成可能な情報にはオプションも含まれます。
定義する各認可ルールには、認可スキームを指定する必要があります。アクセス・システムに付属の認可スキームを使用することも、カスタム認可スキームを選択する（構成済の場合）こともできます。詳細は、「カスタム・プラグインの認可スキームの概要」を参照してください。
ポリシー・ドメインまたはそのすべてのポリシーに使用する認可ルールは、すべてポリシー・ドメイン・レベルで作成します。
表示するポリシー・ドメインを選択します。
「認可ルール」タブを選択します。
ポリシー・ドメインの既存の認可ルールをリストしたページが表示されます。
|
注意: ポリシー・ドメインの作成中である場合は、構成済認可ルールは表示されません。 |
「追加」をクリックします。
「認可ルール」の「一般」ページが表示されます。
次のテキスト・ボックスで、認可ルールに対して名前（および必要な場合には簡単な説明）を指定します。
名前: この認可ルールの名前。
説明: この認可ルールの簡単な説明。
たとえば、カスタム認可スキームを含む認可ルールには、カスタム・プラグインが提供する機能の説明を指定できます。
「有効」のリストから「はい」を選択して認可ルールを有効化するか、「いいえ」を選択して無効化します。
「保存」のクリック後すぐに認可ルールをアクティブ化する場合は、「はい」を選択します。有効化した認可ルールは、認可条件式に組入れ可能な候補となります。ルールはデフォルトでは無効化されています。
認可ルールは、認可条件式での使用開始以降は、そのルールを使用するすべての式から削除しないかぎり無効化できません。
「優先を許可」で次のいずれかを選択します。
はい: アクセスの許可条件をアクセスの拒否条件より優先する場合
いいえ: アクセスの拒否条件をアクセスの許可条件より優先する場合
ルールにアクセスの許可およびアクセスの拒否条件を構成する場合は、このオプションを使用して、ユーザーがルールの両方の条件の対象になる場合にどちらの条件を優先するかを指定します。
アクセス・サーバーのキャッシュをいつ更新するかを設定します。
即時: 「キャッシュの更新」を選択すると、アクセス・サーバーのキャッシュがすべて、この新規の接頭辞の情報を使用して即時に更新されます。
後で: 「キャッシュの更新」を選択しなかった場合、アクセス・サーバーのキャッシュは、タイムアウトになってディレクトリ・サーバーから新しい情報を読み取ったときに更新されます。
「保存」をクリックします。
指定した情報が「一般」ページに表示されます。
認可ルールに組み入れる認可スキームを選択します。
マスター・アクセス管理者がカスタム認可スキームを作成していない場合は、選択可能なスキームはOracle認可スキームのみです。
「追加」をクリックします。
認可ルールの「一般」ページが表示されます。
認可ルールのアクセスの許可部分では、保護されているリソースを使用する権限のあるユーザーおよびグループを定義します。
アクセス・システムのランディング・ページで、「ポリシー・マネージャ」リンクをクリックします。
アクセス・システム・コンソールで作業している場合は、ページの最上部にある「ポリシー・マネージャ」のリンクをクリックします。
左側のナビゲーション・ペインにある「ポリシー・ドメイン」をクリックします。
表示するポリシー・ドメインを選択します。
「認可ルール」タブを選択します。
ポリシー・ドメインの認可ルールをリストしたページが表示されます。
ポリシー・ドメインの作成中である場合は、構成済認可ルールは表示されません。
アクセスの許可条件を設定する認可ルールを選択します。
「アクセスの許可」タブをクリックします。
条件が存在しない場合は「追加」を、存在する場合は「変更」をクリックします。
「人々」、「ロール」、「ルール」および「IPアドレス」コントロールを使用して、このルールで保護するリソースへのアクセスを許可するユーザーおよびグループを指定します。次は、これらのコントロールのリストです。
|
注意: これらのオプションは選択一致です。これらのフィールドのいずれかで指定されているエンドユーザーまたはグループが、アクセスを許可されます。 |
人々: ユーザー名で選択するには「ユーザーの選択」をクリックします。
構成済ユーザーを表示するには「検索」機能を使用します。
このルールで保護するリソースへのアクセスを許可するユーザーごとに、ユーザー名の前にある「追加」をクリックします。
ロール: ユーザーがロール・ベースで許可されることのないようにするには「ロール」選択ボックスで「ロールなし」を選択し、保護されているリソースへのアクセスをすべてのユーザーに許可するには「すべてのユーザー」を選択します。
ルール: 保護されているリソースへのアクセスを許可するユーザーおよびグループを指定するLDAPフィルタを入力します。フィルタを別に追加する場合は、プラス・ボタンを使用します。既存のフィルタを削除する場合は、マイナス・ボタンを使用します。
IPアドレス: アクセスを許可するユーザーのコンピュータのIPアドレスを入力します。
別途記載のないかぎり、アクセス・システムでは、アクセス・システムおよびポリシー・マネージャのIPアドレスに対して次の表現規約がサポートされています。
- 明示アドレス（192.2.2.2など）。
- ワイルドカードを含むアドレス。ただし、ワイルドカードの指定は末尾にある必要があります（192.2.2.*、192.2.*、192.*など）。
アクセス・システムでは次のような表現はサポートされていません。
- ワイルドカードが末尾以外に指定されたアドレス。たとえば、192.128.*.2はサポートされません。
- ワイルドカードのみの指定（***.*.*.*など）。
サポートされていない形式を使用してIPアドレスを入力すると、「入力したIPアドレスが無効です。」というエラー・メッセージが表示されます。
「IPアドレス」フィールドでは、IPアドレスを別に追加する場合はプラス・ボタンを使用し、既存のIPアドレスを削除する場合はマイナス・ボタンを使用します。
アクセス・サーバーのキャッシュをいつ更新するかを設定します。
即時: 「キャッシュの更新」を選択すると、アクセス・サーバーのキャッシュがすべて、この新規の接頭辞の情報を使用して即時に更新されます。
後で: 「キャッシュの更新」を選択しない場合は、アクセス・サーバーのキャッシュは、タイムアウトになってディレクトリ・サーバーから新しい情報を読み取ったときに更新されます。
「保存」をクリックします。
認可ルールのアクセスの拒否部分では、このルールで保護されるリソースを使用する権限を拒否するユーザーおよびグループを指定します。
「ポリシー・マネージャ」で、「ポリシー・ドメイン」を選択し、表示するポリシー・ドメインをクリックします。
ルールの定義中で、ルールの一般情報を構成済の場合は、このパスをあらためて選択する必要はありません。
「認可ルール」タブを選択します。
ポリシー・ドメインの認可ルールをリストしたページが表示されます。
ポリシー・ドメインの作成中である場合は、認可ルールは表示されません。
アクセスの拒否条件を設定する認可ルールを選択します。
認可ルールの一連のパネルが、「一般」パネルが選択された状態で表示されます。ルールのその他のパネルとしては、「タイミング条件」、「アクセスの許可」および「アクセスの拒否」があります。
「アクセスの拒否」パネルをクリックし、認可ルールが存在しない場合は「追加」を、存在する場合は「変更」をクリックします。
「人々」、「ロール」、「ルール」および「IPアドレス」コントロールを使用して、このルールで保護するリソースへのアクセスを拒否するユーザーおよびグループを指定します。次は、これらのコントロールのリストです。
|
注意: これらのオプションは選択一致です。これらのフィールドのいずれかで指定されているエンドユーザーまたはグループが、アクセスを拒否されます。 |
人々: ユーザー名で選択するには「ユーザーの選択」をクリックします。
構成済ユーザーを表示するには「検索」機能を使用します。
このルールで保護するリソースへのアクセスを拒否するユーザーごとに、ユーザー名の前にある「追加」をクリックします。
ロール: ユーザーがロール・ベースで許可されることのないようにするには「ロール」選択ボックスで「ロールなし」を選択し、保護されているリソースへのアクセスをすべてのユーザーに拒否するには「すべてのユーザー」を選択します。
ルール: 保護されているリソースへのアクセスを拒否するユーザーおよびグループを指定するLDAPフィルタを入力します。フィルタを別に追加する場合は、プラス・ボタンを使用します。既存のフィルタを削除する場合は、マイナス・ボタンを使用します。
IPアドレス: アクセスを拒否するユーザーのコンピュータのIPアドレスを入力します。
別途記載のないかぎり、アクセス・システムでは、アクセス・システムおよびポリシー・マネージャのIPアドレスに対して次の表現規約がサポートされています。
- 明示アドレス（192.2.2.2など）。
- ワイルドカードを含むアドレス。ただし、ワイルドカードの指定は末尾にある必要があります（192.2.2.*、192.2.*、192.*など）。
アクセス・システムでは次のような表現はサポートされていません。
- ワイルドカードが末尾以外に指定されたアドレス。たとえば、192.128.*.2はサポートされません。
- ワイルドカードのみの指定（***.*.*.*など）。
サポートされていない形式を使用してIPアドレスを入力すると、「入力したIPアドレスが無効です。」というエラー・メッセージが表示されます。
「IPアドレス」フィールドでは、IPアドレスを別に追加する場合はプラス・ボタンを使用し、既存のIPアドレスを削除する場合はマイナス・ボタンを使用します。
アクセス・サーバーのキャッシュをいつ更新するかを設定します。
「保存」をクリックします。
認可ルールを有効とする時間帯を設定するには、「タイミング条件」オプションを使用します。たとえば、ルールを月曜から金曜の営業時間帯にのみ有効とすることができます。タイミング条件を設定しないと、認可ルールはデフォルトにより常時有効となります。ルールのアクセスの許可条件およびアクセスの拒否条件は、指定の時間帯には有効なままになっています。
表示するポリシー・ドメインを選択します。
「認可ルール」タブを選択します。
ポリシー・ドメインの認可ルールをリストしたページが表示されます。
ポリシー・ドメインの作成中である場合は、認可ルールは表示されません。
タイミング条件を設定する認可ルールを選択します。
認可ルールの「一般」パネルが表示されます。認可ルールのその他のパネルとしては、「タイミング条件」、「アクション」、「アクセスの許可」および「アクセスの拒否」があります。
「タイミング条件」パネルをクリックします。
タイミング条件が存在する場合は、タイミング条件がリストされます。存在しない場合は、認可ルールにはタイミング条件が存在しないことがこのページで報告されます。
タイミング条件がまだ定義されていない場合は「追加」をクリックして新しい条件を作成し、存在する場合は「変更」をクリックします。
「タイミング条件」ページが表示されます。
「グリニッジ標準時」または「Webサーバー上のローカル時間」を選択します。
グリニッジ標準時: 世界標準時。「グリニッジ標準時」を使用する場合、この認可ルールは世界中で同時に有効になります。
世界中に分散している要員に対してこのルールを同時に有効にする場合は、このオプションを使用します。
Webサーバー上のローカル時間: サーバーのタイムゾーン外のユーザーにはアクセスを拒否することがあることを指定します。
たとえば、サーバーがニューヨークにあり、タイミング条件で午後5時以降のアクセスを許可していない場合、西海岸のユーザーは午後2時1分からアクセスを拒否されます。
|
注意: 複数のタイムゾーンに属するユーザーに対して時間帯を制限する場合は、このオプションは使用しないでください。かわりに、西海岸のユーザーに東部標準時の午後8時までアクセスを許可するなどの、別の認可ルールを作成してください。 |
「開始日」および「終了日」を選択します。
|
注意: 「開始日」に「-」のオプションを選択すると、このルールは、事実上開始日を持たなくなり、最初から有効となります。「終了日」に「-」のオプションを選択すると、このルールは、事実上終了日を持たなくなり、永久に有効になります。 |
「開始時間」および「終了時間」を選択します。
「開始時間」と「終了時間」の一方のみを選択することはできません。「開始時間」を指定する場合は、「終了時間」を選択する必要があります。
デフォルトでは、「開始時間」および「終了時間」フィールドは「-」に設定されます。つまり、このルールの開始時間と終了時間は未設定になります。つまり、1日24時間有効になります。
「開始時間」および「終了時間」を選択するときは、3つのすべてのフィールド（「時間」、「分」、「秒」）で選択を行う必要があります。選択を行わないと、「開始時間」および「終了時間」は無効になります。
このルールを有効とする時間帯の「月」、「日付」および「曜日」を選択します。
|
注意: 1つの項目（月など）を選択するには、それをクリックします。複数の項目を選択するには、[Shift]キーを押しながら同じリスト内の追加項目を選択します。「-」オプションを選択すると、このルールは毎日有効になります。 |
これらのタイミング条件に関する情報を使用してアクセス・ゲートおよびアクセス・サーバーのすべてのキャッシュを即時に更新する場合は、「キャッシュの更新」を選択します。
「保存」をクリックします。
認可条件式に含まれる認可ルールを変更または使用しようとする前に、そのルールの一般情報を表示すると便利な場合があります。
アクセス・システムを起動し、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択します。
表示するポリシー・ドメインを選択します。
「認可ルール」タブを選択します。
ポリシー・ドメインの認可ルールをリストしたページが表示されます。
一般情報の構成を表示する認可ルールを選択します。
認可ルールの「一般」情報パネルに、ルールの「名前」、「説明」、「有効」ステータスおよび「優先を許可」の値が表示されます。ルールのその他のパネルとしては、「タイミング条件」、「アクション」、「アクセスの許可」および「アクセスの拒否」があります。
ポリシー・ドメインの認可ルールはいつでも変更できます。ただし、ルールを変更する前に無効化するようにしてください。
アクセス・システムを起動し、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択します。
表示するポリシー・ドメインを選択します。
「認可ルール」タブを選択します。
ポリシー・ドメインの認可ルールをリストしたページが表示されます。
変更する認可ルールを選択します。
「変更」をクリックします。
編集可能なテキスト・ボックスのある「一般」ページが表示されます。
情報を変更する前に、「有効」ステータス・ボックスが空白であり、ルールが無効化されていることを確認します。
一般情報や次の情報を必要に応じて変更します。
タイミング条件: 同名のタブをクリックし、指示に従ってタイミング条件を定義します。
アクション: 「アクション」タブをクリックし、「認可条件式の概要」の指示に従ってアクションを定義します。
アクセスの許可またはアクセスの拒否: これらのうち必要な方のリンクをクリックし、指示に従ってルールを定義します。
「保存」をクリックします。
場合によっては、1つの認可ルールのみで、ポリシー・ドメインまたはポリシーのすべてのリソースを保護できます。ルールを構成する際には、そのルールで保護されるリソースへのアクセスを誰に許可または拒否するのか、およびどのような条件の場合にこれらのアクセス制御を適用するのかを指定できます。たとえば、どのコンピュータからのアクセスをいつ制御するのかを指定できます。認可ルールでは、どのユーザーもアクセスの許可条件またはアクセスの拒否条件に指定してある、という状態になっている必要はありません。ルールで保護されているリソースへのアクセスをリクエストしても、そのユーザーがどの条件の対象にもならない場合、ユーザーはデフォルトでリソースへのアクセスを拒否されます。
または、複数の認可ルールを構成してリソースを保護することが必要な場合もあります。異なるユーザーに対して複雑な制限を設けることもできます。たとえば、様々な認可ルールを含むポリシーを定義し、それらのルールのいずれかの一部をユーザーが満たしているときにのみ、保護されているリソースへのアクセスを許可（または拒否）する場合などです。また、同じポリシー・ドメインで複数の条件をユーザーが満たす必要があると指定することもできます。たとえば、ユーザーがリソースへのアクセス権を付与されるには、2つの条件（あるグループに属し、かつ特定のIPアドレスが割り当てられているコンピュータを使用している、など）を満たす必要があると指定することもできます。保護するリソースに必要な、完ぺきな認可条件を定義するには、認可条件式を作成します。ポリシー・マネージャには、認可条件式を簡単に作成できるようにするインタフェースがあります。ポリシー・ドメインにはデフォルトの認可条件式を作成する必要がありますが、これとは別にドメイン内のポリシーに特定の認可条件式を作成することも可能です。
この項では、認可条件式と、その作成および管理方法について説明します。内容は次のとおりです。
認可条件式には、一連のリソースに対する認可要件を定義します。認可条件式は、ポリシー・ドメイン全体やドメインの1つのポリシーのリソースに適用できます。
認可条件式には次のものを組み入れます。
ポリシー・ドメインに定義できる認可条件式は1つのみです。これが、ポリシー・ドメインのデフォルト認可条件式になります。ドメイン内の各ポリシーには1つの認可条件式を定義できます。認可条件式には、ポリシー・ドメイン・レベルで定義されている認可ルールも含めることができます。図6-1で、ポリシー・ドメインのデフォルト認可条件式を図解します。ポリシー・ドメインのデフォルト・ルールは、デフォルトの保護対象URLに対する認証ルール、認可条件式および監査ルールの3つで構成されています。
認可条件式は、常に左から右に評価されます。式のルールは演算子を使用してグループ化でき、グループ化の方法によって式全体の評価結果が影響を受けます。
2つの演算子、ANDとORを使用して式の複数のルールを組み合せることができます。認可条件式を作成する際、認可ルールを組み合せて次のタイプの条件が含まれるようにします。
論理積条件: ユーザーが満たす必要のある複数の条件を指定します。式の残りの部分の評価結果に応じて、リクエストしたリソースへのアクセス権を付与されるか、またはアクセスを明示的に拒否されます。この目的にはAND演算子を使用します。「認可ルールの使用例」を参照してください。
論理和条件: ここに指定する代替可能な複数の条件のうち、いずれかをユーザーが満たす必要があります。論理和条件全体の評価と、論理和条件と式の残りのルールとの関係がどうなるかに応じて、リクエストしたリソースへのアクセスを許可または拒否されます。この目的にはOR演算子を使用します。「認可ルールの使用例」を参照してください。
ANDおよびORを使用した式のルールのグループがどのように解釈されるかの詳細は、「式のルールの評価の概要」を参照してください。
認可条件式の評価結果には、次の3つの状態があります。
認可成功: この場合、ユーザーはリクエストしたリソースにアクセスできます。この結果は、式のアクセスの許可条件に関連付けられています。
認可失敗: この場合、ユーザーはリクエストしたリソースにアクセスできません。この結果は、式のアクセスの拒否条件に関連付けられています。
認可未確定: この場合、式のルールにより矛盾する結果がいくつか生成され、ユーザーはリソースへのアクセスを拒否されます。
式では未確定という結果を戻す場合があります。この場合、アクセス・システムではメジャー・ステータス・コードとしてDeny（拒否）を、マイナー・ステータス・コードとしてInconclusive（未確定）を戻します。
Denyというメジャー・ステータス・コードは、旧リリースのシステムとの互換性を保つために、未確定結果に対して戻されるものです。Inconclusiveというマイナー・ステータス・コードはOracle Access Managerシステムで使用可能であり、Oracle Access Managerシステムが、真の拒否結果と、未確定状態が原因で戻される拒否結果とを識別できるようにするものです。
認可条件式の結果が拒否や未確定の場合、ユーザーはリソースへのアクセスを拒否されますが、拒否と未確定は同じではありません。Oracle Access Managerを使用して実行されるように作成されているアプリケーションは、未確定結果に対する2つのステータス・コードを解釈でき、この追加情報をその他の目的に使用できます。たとえば、リソースへのアクセスをユーザーに対して拒否するのではなく、その他の認可エンジンを起動できます。
認可条件式に論理積条件と論理和条件の組合せを指定して、この式で保護するリソースにユーザーにアクセスさせるかどうかを設定しておくことができます。保護されているリソースへのアクセスをユーザーがリクエストすると、ユーザーの情報が式のルールに対してチェックされます。
式のルールに対するユーザー情報のチェック結果、式におけるルールの位置、および式内でのルールの組合せ方法に応じて、評価には多様な結果がありえます。認可条件式がどの範囲まで実行されるかは、これらの変数に応じて決まります。つまり、ルールの一部が評価されないこともあります。
優先度および位置: アクセス・サーバーでは式のルールを次のように処理します。
演算子の優先度: 式のルールの組合せ方法に関しては、AND演算子がOR演算子より優先されます。
すなわち、式に3つ以上のルールが含まれていてなんらかの順序でAND演算子とOR演算子で組み合されている場合、アクセス・サーバーでは常にAND演算子の両側のルールを最初にAND演算子で結び付け、次にOR演算子を使用するルール同士を組み合せます。
たとえば、次の認可条件式があるとします。
R1 OR R2 AND R3
アクセス・サーバーの内部では、次のグループ化がデフォルトで行われます。
R1 OR (R2 AND R3)
アクセス・サーバーでは、ユーザーの情報をルールに対してチェックする前に、ANDをORより優先することでこのグループ化を行って、式全体を解釈します。
演算子の詳細は、「認可ルールの使用例」を参照してください。
式におけるルールの位置: アクセス・サーバーでは式を左から右に評価します。
認可ルールには、その他のルールと比較しての優先度は割り当てません。各認可ルールに評価の優先度を割り当てると、認可ルールが再利用できなくなります。かわりに、評価される順序である左から右への方向にルールを式の中で配置し、ルール同士を演算子によって組み合せます。演算子の詳細は、「認可ルールの使用例」を参照してください。
カッコによるデフォルトの優先度の変更: カッコを使用すると、アクセス・サーバーで式のルールをグループ化するデフォルトの方法を変更できます。アクセス・サーバーが式のルールを左から右に評価することは不変ですが、カッコを使用して作成した組合せおよびグループに含まれるルールを優先して評価します。「カッコの使用方法の概要」を参照してください。
認可条件式の最終結果の概要: アクセス・サーバーでは、最終的な結果を得られるまで、式に含まれる各ルールを評価します。認可条件式の評価では、最終結果として、アクセスの許可、アクセスの拒否または未確定のいずれかが戻されます。
たとえば、ユーザーが次の式で、ルール1ではアクセスの許可条件の対象に、ルール2ではアクセスの拒否条件の対象に、ルール3ではアクセスの拒否条件の対象になるとします。
(Rule 1 AND Rule 2) OR Rule 3
この場合、ルール3の評価により式の最終的な結果が戻され、ユーザーはリソースへのアクセスを拒否されます。ルール1とルール2はAND条件の構成要素としては互いに矛盾する結果を戻すので、式の結果には影響を与えません。ルール3は、OR条件の構成要素であるため、独立しています。ユーザーがルール3のアクセスの許可条件またはアクセスの拒否条件を満たしている場合は、ルール3で式の結果が決まります。
ルール2で最終結果が決まるようにするには、ユーザーはルール1とルール2の両方でアクセスの許可条件またはアクセスの拒否条件の対象になる必要があります。この場合、ルール1とルール2の評価で最終結果が戻されるため、ルール3が評価されることはありません。つまり、ルール3は評価が不要になります。
表6-1に、認可ルールの例を示します。認可ルールは、ポリシー・ドメイン・レベルに定義した場合は、ドメインおよびドメインのすべてのポリシーに組み入れる認可条件式で使用できます。表6-1に記載の各認可ルールの例には、各認可ルールの全体ではなく、ルールの1つの条件、つまり、アクセスの許可条件またはアクセスの拒否条件のみを示しています。
認可ルールには、アクセスの許可条件とアクセスの拒否条件の両方を指定する必要はなく、一方のみの条件を指定するのみで済みます。ですが、両方の条件を指定してもかまいませんし、一方の条件のみを指定することも、どちらの条件も指定しないことも可能です。表6-1は、この章の残り全体にわたる使用例で使用される認可ルールの例を示しています。
表6-1 認可ルールおよびその条件の例
| 認可ルール | 条件 |
|---|---|
|
Rule 1 |
マーケティング部門グループのすべてのユーザーに、リクエストしたリソースへのアクセスを許可する。 |
|
Rule 2 |
IPアドレスが192.168.2.123のコンピュータを使用するすべてのユーザーに、リクエストしたリソースへのアクセスを許可する。 |
|
Rule 3 |
人事管理部門グループのすべてのユーザーに、リクエストしたリソースへのアクセスを許可する。 |
|
Rule 4 |
Teleonプロジェクト・グループのすべてのユーザーに、リクエストしたリソースへのアクセスを許可する。 |
|
Rule 5 |
コンサルタント・グループのすべてのユーザーに対して、リクエストしたリソースへのアクセスを拒否する。 |
|
Rule 6 |
Saberプロジェクト・グループのすべてのユーザーに対して、リクエストしたリソースへのアクセスを拒否する。 |
|
Rule 7 |
IPアドレスが192.168.5.123のコンピュータを使用しているすべてのユーザーに対して、リクエストしたリソースへのアクセスを拒否する。 |
|
Rule 8 |
管理者グループのすべてのユーザーに、保護されているリソースへのアクセスを許可する。 |
|
Rule 9 |
運営職アシスタント・グループのすべてのユーザーに、保護されているリソースへのアクセスを許可する。 |
AND演算子は、認可ルールを組み合せて論理積条件を作成するのに使用します。AND演算子を使用すると、任意の数のルールを組み合せ、ユーザーが認可要件を満たすために従う必要がある一連の条件を実装できます。ただし、AND句の最終的な結果を得るには、ユーザーは、論理積条件の全ルールで同様の条件（アクセスの許可またはアクセスの拒否）を満たす必要があります。
認可条件式には、ANDで組み合されたルールの組合せまたはグループを複数個含めることができます。たとえば、複数のAND句を含めて、それぞれの句をOR演算子で接続できます。
|
注意: ユーザーが同じルールのアクセスの許可条件とアクセスの拒否条件の両方の対象になる場合があります。この場合、優先されるように構成されている条件が優先されます。この設定は、「優先を許可」フィールドで構成します。 |
次の各使用例では、表6-1に記載した認可ルールの例を使用した論理積条件の例を示します。これらの例の一部では、式の作成に使用するため、ポリシー・マネージャの「認可条件式」ページが表示されます。このページを使用して認可条件式を作成する方法の詳細は、次の各項を参照してください。
認可条件式を作成する手順は、「認可条件式の作成」を参照してください。
ポリシー・マネージャの「認可条件式」インタフェースを使用して式を作成する方法の詳細は、「作成中の認可条件式の変更」を参照してください。これらの手順と方法は、式の作成と既存の式の変更の両方に適用されます。
アクセスの許可条件が指定されている2つの認可ルール間の論理積条件: 次の認可条件式で保護されているリソースへのアクセスを許可されるには、ユーザーはマーケティング部門グループに属していて、コンピュータのIPアドレスが192.168.2.123である必要があります。
Rule 1 AND Rule 2
アクセスの許可条件が指定されている3つの認可ルール間の論理積条件: 次の認可条件式で保護されているリソースへのアクセスを許可されるには、ユーザーはマーケティング部門グループおよび管理者チームに属しているか、リソースにIPアドレス192.168.2.123からアクセスする必要があります。
Rule 1 AND Rule 2 AND Rule 4
「認可条件式」サブタブの「式」パネルを使用して式を構成する場合、式は次のように表示されます。
アクセスの拒否条件が指定されている2つの認可ルール間の論理積条件: 次の認可条件式で保護されているリソースへのアクセスを明示的に拒否されるには、ユーザーはコンサルタント・グループとSaberプロジェクト・グループに属している必要があります。
Rule 5 AND Rule 6
認可条件式には、複数の代替可能な認可ルールが含まれる論理和条件を含めることができます。論理和条件を構成する認可ルールは、OR演算子を使用して組み合せます。OR論理和条件で指定した各認可ルールは、独立したルールになります。AND演算子を使用する論理積条件とは異なり、ユーザーは、OR演算子で接続された認可ルールのうち、ただ1つのルールの条件に対してのみ対象になる必要があります。
認可条件式には、保護するリソースに対して認可ポリシーを表すのに必要な数の認可ルールをOR演算子で接続して含めることができます。OR演算子は、アクセスの拒否条件のみを持つ認可ルール同士、アクセスの許可条件のみを持つ認可ルール同士、またはアクセスの拒否条件とアクセスの許可条件を組み合せて指定した認可ルール同士を接続するのに使用できます。ORを使用して1つのルールを1つのルールに接続できるのみでなく、ANDで組み合されたルールを含む句に1つのルールを接続することもできます。
次の各使用例では、表6-1に記載した認可ルールの例を使用しています。
アクセスの許可条件が指定されている2つのルール間の論理和条件: 次のルールで保護されているリソースをリクエストしてアクセスを許可されるには、ユーザーはマーケティング部門グループまたは人事管理部門グループのメンバーである必要があります。
Rule 1 OR Rule 3
アクセスの拒否条件が指定されている3つの認可ルール間の論理和条件: リクエストしたリソースへのアクセスを明示的に拒否されるには、ユーザーはコンサルタント・グループまたはプロジェクトXYZグループに属しているか、IPアドレスが192.168.5.123のコンピュータを使用している必要があります。
Rule 5 OR Rule 6 OR Rule 7
「認可条件式」の「式」ページを使用して式を構成する場合、式は次のように表示されます。
アクセスの許可条件およびアクセスの拒否条件の組合せを指定したルール間の論理和条件: 次の式で保護されているリソースへのアクセスをリクエストして許可されるには、ユーザーはマーケティング部門グループまたは管理者チームのメンバーである必要があります。リクエストしたリソースへのアクセスを明示的に拒否されるには、ユーザーはコンサルタント・グループに属しているか、XYZプロジェクト・グループのメンバーである必要があります。
Rule 1 OR Rule 2 OR Rule 5 OR Rule 6
「認可条件式」タブの「式」パネルを使用して式を構成する場合、式は次のように表示されます。
次の各使用例では、表6-1に記載した認可ルールの例を使用した論理積条件式と論理和条件式が両方含まれた認可条件式の例を示します。
3つのルール間の論理和条件の認可条件式: 委任アクセス管理者が次の式を作成したとします。
Rule 2 OR Rule 4 AND Rule 1
「認可条件式」の「式」ページを使用して式を構成する場合、式は次のように表示されます。
Janeがこの認可条件式で保護されているリソースへのアクセスをリクエストするとします。アクセス・サーバーではこの式を評価し、リソースへのアクセスを許可する次のいずれかの条件をJaneが満たすかどうかを判定します。
JaneのコンピュータのIPアドレスは192.168.2.123で、かつJaneは管理者グループのメンバーである（Rule 4 AND Rule 1）。
Janeはマーケティング部門グループのメンバーである（Rule 2）。
アクセス・サーバーによる認可条件式の評価方法に従い、カッコを使用してルールを明示的にグループ化すると、式は次のようになります。
Rule 2 OR (Rule 4 AND Rule 1)
式は左から右に評価され、最終的な結果を決定できた時点で評価が終了します。JaneはRule 1の条件を満たしていて、Rule 1の後にはOR演算子があるため、リソースへのアクセス権を付与されます。
4つのルール間の論理和条件の式: 委任アクセス管理者が次の式を作成するとします。
(Rule 2 AND Rule 4) AND (Rule 7 OR Rule 8)
「認可条件式」の「式」ページを使用して式を作成する場合、式は次のように表示されます。
Mauriceは次の条件を満たすため、この認可条件式で保護されているリソースへのアクセスを許可されます。
マーケティング部門のメンバーで、かつコンピュータのIPアドレスは192.168.2.123である。（Rule 2 AND Rule 4）。
管理者でもあり、管理者グループに所属している。（Rule 8）
MauriceのコンピュータのIPアドレスが、192.168.5.123ではない（Rule 7）。しかし、認可条件式で満たす必要があるのは、ルール7とルール8の両方ではなく、どちらか一方であるため、この理由ではアクセスを拒否されません。
6つのルール間の論理和条件の式: 委任アクセス管理者が次の式を作成するとします。
Rule 2 OR Rule 4 OR Rule 1 AND Rule 9 OR Rule 5 AND Rule 6
「認可条件式」の「式」ページを使用して式を構成する場合、式は次のように表示されます。ただし、「認可条件式」リスト・ボックスには最後のルールが表示されていません。最後のルールを表示するには、スクロールが必要です。一方、「テキスト形式の認可条件式」ボックスでは、テキストが折り返されて式全体が示されています。
カッコを使用してルールを明示的にグループ化した場合、式は次のようになります。
Rule 2 OR Rule 4 OR (Rule 1 AND Rule 9) OR (Rule 5 AND Rule 6)
ルールのグループ化や左から右への処理ではANDがORより優先されるため、ユーザーがリクエストしたリソースへのアクセスを許可されるには次のいずれかの条件を満たす必要があります。
論理和条件の最初の単一ルール（Rule 2）
マーケティング部門グループに属するユーザーはリソースへのアクセスを許可されます。
論理和条件の2番目の単一ルール（Rule 4）
コンピュータのIPアドレスが192.168.2.123のユーザーはリソースへのアクセスを許可されます。
最初の論理積条件（Rule 1 AND Rule 9）
管理者チームおよびABCプロジェクト・グループに属するユーザーはアクセスを許可されます。
2番目の論理積条件（Rule 5 AND Rule 6）
コンサルタント・グループおよびXYZプロジェクト・グループに属するユーザーはリソースへのアクセスを拒否されます。
アクセス・サーバーによる式の評価は、式の最終的な結果を決定するルールが評価された時点で完了します。アクセス・サーバーで式の評価が完了し、ユーザーがその式のどの条件も満たさない場合、評価の結果は未確定となります。この場合、ユーザーにはどのルールも適用されないため、ルールに関連付けられているアクションは実行されません。ただし、式の結果が未確定になった場合に対して構成されているアクションは実行されます。アクションの詳細は、「認可アクションの概要」を参照してください。結果が未確定な場合に戻されるステータス・コードの詳細は、「未確定結果のステータス・コード」を参照してください。
デフォルトでは、AND演算子で2つのルールを組み合せたものが、AND論理積条件になります。OR演算子の両側にあるルールは、少なくとも一方が満たされれば条件は成立します。カッコを使用してルールをグループ化しない場合は、AND演算子がOR演算子より優先されます。
たとえば、次の式でカッコが使用されず、式のルールを評価するデフォルトの方法が変更されない場合、
R1 OR R2 AND R3 OR R4 AND R5
この式は次のように解釈されます。
R1 OR (R2 AND R3) OR (R4 AND R5)
カッコを使用すると、式のルールの通常のグループ化を変更できます。たとえば、OR条件をAND条件より優先できます。
次の例では同じ式が使用されています。しかし、この例では、カッコを使用してデフォルトのグループ化が変更されています。
(R1 OR R2) AND (R3 OR R4) AND R5
ディレクトリ・サーバーによっては、属性値に制限が課される場合があります。たとえば、Oracle Internet Directoryでは、属性値が4000文字を超えてはいけないという制限を課されます。認可条件式が4000文字を超えると、式を保存するときにエラー・メッセージが表示されます。
No Authorization Defined
長い認可条件式を追加する前に、ポリシー・マネージャのglobalparams.xmlファイルにpolicyDSMaxAttrValueLengthパラメータを追加する必要があります。追加する値は、ディレクトリ・サーバーによって制限される属性の最大長にします。Oracle Internet Directoryでは、この値は4000文字を超えてはいけません。その他のディレクトリ・サーバーについては、詳細はベンダー固有のドキュメントを参照してください。
Access Manager SDKのAPIを使用してポリシーを追加する場合は、policyDSMaxAttrValueLengthパラメータを関連するアクセス・サーバーのglobalparams.xmlファイルに追加する必要があります。この機能は、デフォルトでは無効です（デフォルトではファイルにこのパラメータはありません）。パラメータを手動で追加してください。
|
注意: ディレクトリの制限を変更できない場合または条件式のサイズに対応させられない場合は、policyDSMaxAttrValueLengthパラメータによってOracle Access Managerで制限が補正され、より長い式の作成ができるようになります。 |
このタスクの実行方法については、「長い認可条件式での問題」を参照してください。
次の各項目は、認可条件式を操作する手順について説明しています。
ポリシー・ドメインに設定できる認可条件式は1つのみです。そのポリシーにも認可条件式を1つずつ設定できます。いずれかのポリシーに式がすでに定義されている場合、その定義はいつでも表示できます。
ポリシー・ドメインまたはポリシーに認可条件式が存在する場合、「式」ページにはその認可条件式全体が表示されます。認可条件式が長い場合、テキストは後続の行に折り返され、式全体が表示されます。
認可条件式には、式の内容（ルールおよび演算子）と、式自体の構成が含まれます。
アクセス・システムを起動し、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択します。
認可条件式を表示するポリシー・ドメインを選択します。
「デフォルト・ルール」を選択します。
「認可条件式」タブを選択します。
次のスクリーン・ショットに示すように、「認可条件式」ページが表示されます。このページには、式の名前と、その式に対してポリシー・ドメインに構成されている値が表示されます。また、「式」、「重複アクション」および「アクション」という3つのパネルもあります。
式に構成されている値を表示する手順:
このセクションでは、「重複アクション」ポリシーが認可条件式に構成されている場合に、この認可条件式で保護するポリシー・ドメインに対する重複アクションの処理方法を定義します。ポリシー・ドメインには1つ以上のポリシーを含めることができます。
詳細は、「重複アクションの概要」を参照してください。
「アクション」をクリックします。
このセクションでは、この認可条件式に構成するアクションを定義します。
「変更」をクリックして、式の内容を表示します。
式の構成が、式の作成または変更に使用するページに表示されます。
式の各ルールに構成されているアクションを表示するには、ルールの構成を確認する必要があります。「認可ルールの概要」を参照してください。
各ポリシーには独自の認可条件式を設定できます。認可条件式は、ポリシーの定義内から表示できます。
認可条件式には、式の内容（ルールおよび演算子）と、式自体の構成が含まれます。
アクセス・システムを起動し、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択します。
認可条件式を表示するポリシーが含まれるポリシー・ドメインを選択します。
「ポリシー」を選択します。
認可条件式を表示するポリシーを選択します。
「認可条件式」をクリックします。
次のスクリーン・ショットに示すように、「認可条件式」ページが表示されます。このページには、式の名前（「認可ルールなしのロスト・パスワード管理」）が表示されます。
「変更」をクリックして、式の内容を表示します。
式の構成が、式の作成または変更に使用するページに表示されます。
（オプション）式に構成されている値を表示するには、次のようにします。
このポリシーで保護されているリソースに対する重複アクションの処理方法を定義するセクションを表示するには、「重複アクション」をクリックします。ポリシーの認可条件式の重複アクションに対する設定は、ポリシー・ドメインの設定より優先されます。詳細は、「重複アクションの概要」を参照してください。
ポリシーの認可条件式には、独自の重複アクション設定を含めることができます。この場合、ポリシーの重複アクション設定は、ポリシー・ドメインの設定より優先されます。
この認可条件式に構成するアクションを定義するセクションを表示するには、「アクション」をクリックします。
ポリシー・ドメインの認可条件式は、式を含むポリシーによって保護されていないドメインのすべてのリソースに適用されます。
アクセス・システムを起動し、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択します。
認可条件式を作成するポリシー・ドメインを選択します。
「デフォルト・ルール」を選択します。
「認可条件式」タブを選択します。
「認可条件式」ページが表示されます。認可条件式が定義されていない場合は、「認可条件式が定義されていません。」というメッセージが表示されます。
|
注意: 認可条件式が存在する場合、その内容のみが変更可能です。認可条件式全体を置き換えるには、そのすべての部分を変更する必要があります。 |
「追加」をクリックします。
次のスクリーン・ショットに示すように、式の作成に使用する「認可条件式」ページが表示されます。
「認可条件式」ページを使用して、認可条件式を作成します。
次の手順に従い、認可条件式の認可ルールと、それらのルールを組み合せるのに使用する演算子を選択します。
|
注意: 最初のルールをカッコで囲まれた句に含める場合は、最初のルールを式に追加する前に左カッコのボタンをクリックします。 |
「認可ルールの選択」リストから、式に追加する最初のルールを選択し、「追加」をクリックします。
認可条件式に複数のルールを含める場合、最初の2つのルールを組み合せるために使用する演算子を選択します。
AND演算子の場合は、「セパレータの選択」の横の「AND」ボタンをクリックします。
OR演算子の場合は、「セパレータの選択」の横の「OR」ボタンをクリックします。
カッコで囲まれた句を開始するには、左カッコのボタンをクリックします。
カッコで囲まれた句を終了するには、右カッコのボタンをクリックします。
認可条件式で認可要件を表せるまで、認可条件式でのルールの追加と組合せを繰り返し、式を完成させます。
「保存」をクリックして式を保存します。
「認可条件式」ページの「重複アクション」タブを選択します。
次のスクリーン・ショットに示すように、「重複アクション・ヘッダー」ページが表示されます。
「変更」をクリックして「重複アクション」ポリシーを選択します。次のスクリーン・ショットに示すように、「重複アクション」ページが表示されます。
最初のチェック・ボックスを選択し、実行する重複アクション処理のタイプを示すラジオ・ボタンをクリックします。
認可条件式レベルで設定した「重複アクション」ポリシーは、アクセス・システム・コンソール・レベルの設定より優先されます。
アクセス・サーバーのキャッシュをいつ更新するかを設定します。
即時: 「キャッシュの更新」を選択すると、アクセス・サーバーのキャッシュがすべて、この新規の接頭辞の情報を使用して即時に更新されます。
後で: 「キャッシュの更新」を選択しない場合は、アクセス・サーバーのキャッシュは、タイムアウトになってディレクトリ・サーバーから新しい情報を読み取ったときに更新されます。
構文エラーが含まれる認可条件式は保存できません。「保存」をクリックすると、認可条件式の構文が正しいかどうかがアクセス・サーバーによりチェックされます。認可条件式に構文エラーが含まれる場合は（たとえば、式の最後にANDまたはOR演算子を指定するとエラーが発生します）、エラーを修正してから式を保存する必要があります。
「保存」をクリックします。
認可条件式を保存すると、「認可条件式」表示ページに式全体が表示されます。「認可条件式」ページの機能を使用して式を作成する方法の詳細は、「作成中の認可条件式の変更」を参照してください。
ポリシーの認可条件式の作成に使用する手順は、ポリシーの作成手順と類似しています。詳細は、「認可条件式の作成」を参照してください。すでにポリシー・ドメインを選択している場合は、手順1と2はスキップして手順3から開始できます。
アクセス・システムを起動し、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択します。
認可条件式を作成するポリシーが含まれるポリシー・ドメインを選択します。
「ポリシー」ページを選択します。
認可条件式を作成するポリシーの名前を選択します。
「認可条件式」タブを選択します。
「認可条件式」ページに、このポリシーに対して認可条件式が定義されていません、というメッセージが表示されます。
「追加」をクリックします。
「認可条件式」ページで、リスト・ボックス、テキスト・エントリ・ボックスおよびスクロール・リストがアクティブになります。
認可条件式の作成中に、必要に応じて式のルールの組合せ方法を変更できます。たとえば、式の作成中に構文を変更して、異なる認可ポリシーを表現したりエラーを修正することができます。
認可条件式に多数のコンポーネント（ルールおよび演算子）が含まれる場合は、項目をスクロールして表示できるように、認可条件式のリスト・ボックスの右側にスクロールバーが表示されます。
認可条件式は次のどちらかの方法で変更できます。
「認可条件式」リスト・ボックス内で変更
「テキスト形式の認可条件式」ボックス内で変更
一方のボックスで認可条件式に行った変更は、他方のボックスに次のように反映されます。
ルールと演算子を「認可条件式」リスト・ボックスに追加して認可条件式を作成していくと、「テキスト形式の認可条件式」ボックスが自動的に更新されて追加や変更が反映されていきます。
「テキスト形式の認可条件式」ボックスで式を変更した場合は、「更新」ボタンをクリックすると、これらの変更が「認可条件式」リスト・ボックスに反映されます。
一部の演算子は、「認可条件式」リスト・ボックスと「テキスト形式の認可条件式」ボックスとで表示が異なります。次の表にこの相違を示します。
「認可条件式」リスト・ボックスで演算子を入力するには、ボタンを使用します。「テキスト形式の認可条件式」テキスト・ボックスで演算子を入力するには、キーを使用します。
「認可条件式」リスト・ボックスには、それを使用して認可ルールと演算子を選択および追加して式を作成する際、認可ルールと、ルールを組み合せるのに使用する演算子が表示されます。
|
注意: 「認可条件式」リスト・ボックスを使用して認可条件式を作成していくと、その式の内容が「テキスト形式の認可条件式」編集可能テキスト・ボックスに反映されていきます。 |
「認可条件式」リスト・ボックスで式の内容を操作するには、次のボタンを使用します。
変更: 認可条件式の1つのルールを「認可ルールの選択」リストから選択した別のルールと置換する。
演算子を置換するには、一方の演算子を選択して置換後の演算子のボタンをクリックすると、2つの演算子が直接入れかわります。
削除: 「認可ルールの選択」リストで、選択した任意の項目（ルール、演算子、左カッコ、右カッコなど）を削除する。
すべて削除: 認可条件式の内容全体をクリアする。
アクセス・システムを起動し、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択します。
認可条件式を変更するポリシー・ドメインを選択します。
「デフォルト・ルール」を選択します。
「認可条件式」タブを選択します。
「認可条件式」表示ページに既存の認可条件式が表示されます。
「変更」をクリックします。
「認可条件式」ページで、選択リスト、テキスト・エントリ・ボックスおよびスクロール・リスト・ボックスがアクティブになります。
「認可条件式」リストで、置換元のルールを選択します。
置換後のルールを「認可ルールの選択」リストで選択します。
「変更」ボタンをクリックします。
「認可条件式」リストの置換前のルールが新しいルールと置換されます。
アクセス・システムを起動し、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択します。
認可条件式を変更するポリシー・ドメインを選択します。
「デフォルト・ルール」を選択します。
「認可条件式」タブを選択します。
「認可条件式」表示ページに既存の認可条件式が表示されます。
「変更」をクリックします。
「認可条件式」ページで、選択リスト、テキスト・エントリ・ボックスおよびスクロール・リスト・ボックスがアクティブになります。
「認可条件式」リストで、置換元の演算子を選択します。
置換後の演算子のボタンをクリックします。
OR演算子をAND演算子と置換するには、式でORを選択して「AND」ボタンをクリックする。
式のAND演算子を置換するには、それを選択して「OR」ボタンをクリックする。
「認可条件式」リストで置換前の演算子が新しい演算子と置換されます。
「認可条件式」リストに移動します。
「すべて削除」ボタンをクリックします。
ルールと演算子を「認可条件式」リストに追加して認可条件式を作成していくと、「テキスト形式の認可条件式」ボックスが更新されて追加および変更が反映されていきます。
「テキスト形式の認可条件式」ボックスを使用すると、認可条件式のテキスト内容を直接変更できます。
新しいテキストの入力: テキストの変更処理として、キーボードまたはキーパッドのキーと記号を使用して、新しいテキストを入力するか既存のテキストを上書きします。（テキストを入力すること以外にも、リスト・ボックスとの主な相違として、演算子を表す記号を入力することがあります）。演算子に使用する記号は、表6-2を参照してください。
テキストの削除: テキストを認可条件式から削除するには、フラット・テキスト・ファイルでのテキストの処理に通常使用する任意の方法を使用します。
「認可条件式」リストの更新: 「テキスト形式の認可条件式」テキスト・ボックスで行った変更でこのリストを更新するには、テキスト・ボックスのすぐ下にある「更新」ボタンをクリックします。
ポリシー・ドメインまたはポリシーに認可条件式が存在する場合、「認可条件式」表示ページにはその式全体が表示されます。認可条件式が長い場合、テキストは後続の行に折り返され、式全体が表示されます。
認可条件式は、その作成対象であるポリシー・ドメインまたはポリシーの保護に使用され始めた後でも変更できます。
認可条件式を変更する際には、式の作成時に使用したものと同じ手順に従います。この項では、ポリシー・ドメインおよびポリシーの式の変更に使用する「認可条件式」ページへの移動方法について説明します。
ポリシー・ドメインの認可条件式を変更するページを表示する手順
アクセス・システムを起動し、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択します。
認可条件式を作成するポリシー・ドメインを選択します。
「デフォルト・ルール」を選択します。
「認可条件式」タブを選択します。
「認可条件式」表示ページに既存の認可条件式が表示されます。
「変更」をクリックします。
「認可条件式」ページで、選択リストと2つのテキスト・エントリ・ボックスがアクティブになります。
この手順の残りは、認可条件式の作成および変更に関する次の各項の手順を参照してください。
アクセス・システムを起動し、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択します。
認可条件式を作成するポリシーが含まれるポリシー・ドメインを選択します。
「ポリシー」タブを選択します。
認可条件式を変更するポリシーの名前を選択します。
「認可条件式」タブを選択します。
「認可条件式」表示ページに既存の認可条件式が表示されます。
「変更」をクリックします。
「認可条件式」ページで、リスト・ボックス、テキスト・エントリ・ボックスおよびスクロール・リスト・ボックスがアクティブになります。
この手順の残りは、認可条件式の作成および変更に関する次の各項の手順を参照してください。
ポリシー・ドメインまたはポリシー・ドメインのいずれかのポリシーに対して新しい認可条件式を作成する場合は、その前に既存の式を削除する必要があります。
アクセス・システムを起動し、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択します。
認可条件式を削除するポリシー・ドメインを選択します。
「デフォルト・ルール」を選択します。
「認可条件式」タブを選択します。
「認可条件式」表示ページに既存の認可条件式が表示されます。
「変更」をクリックします。
「認可条件式」編集ページに既存の認可条件式の内容が表示されます。
「認可条件式」テキスト・ボックスの下にある「すべて削除」ボタンをクリックします。
アクセス・システムを起動し、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択します。
認可条件式を削除するポリシーが含まれるポリシー・ドメインを選択します。
「ポリシー」タブを選択します。
認可条件式を削除するポリシーの名前を選択します。
「デフォルト・ルール」を選択します。
「認可条件式」タブを選択します。
「認可条件式」表示ページに既存の認可条件式が表示されます。
「変更」をクリックします。
「認可条件式」編集ページに既存の認可条件式の内容が表示されます。
「認可条件式」リスト・ボックスの下にある「すべて削除」ボタンをクリックします。
すべての認可ルールに対し、ルール評価の後でユーザーがリクエストしたリソースへのアクセス権を付与された場合に実行する一連のアクションと、リソースへのアクセスを拒否された場合に実行する一連のアクションを構成できます。認可条件式全体の結果に応じて実行する一連のアクションも構成できます。
ルールと式全体の両方のエンティティによる、式評価の最終的な結果により、実行するアクションが決定されます。認可条件式のすべてのルールが式の最終的な結果に影響を与えるわけではありません。式の最終的な結果に影響を与えたルールに対するアクションのみが実行されます。最終的な結果の詳細は、「式のルールの評価の概要」を参照してください。
この項では、アクションに関する次の内容について説明します。
ルールの構成時には、ルールのアクセスの許可部分とアクセスの拒否部分を適用する対象者を定義できるだけではなく、ルールの各結果に応じて異なった一連のアクションも指定できます。ルールと式の評価の次の結果に対してアクションを構成できます。
認可成功: ルールと式の両方
認可失敗: ルールと式の両方
認可未確定: 式のみ
認可未確定は、ユーザーが対象となる式のルールの評価によって矛盾する結果が戻された場合、またはユーザーが式のどのルールの対象にもならなかった場合です。
これらの条件に関する詳細は、次の各項を参照してください。
式のルールの結果の詳細は、「認可ルールの評価の概要」を参照してください。
式の結果の詳細は、「認可条件式の評価の概要」を参照してください。
アクションにより次の操作が可能です。
別のURLへのユーザーのブラウザのリダイレクト
URLをアクセス・サーバーからアクセス・ゲートまたはWebGateにリダイレクトできます。
同一または別のポリシー・ドメイン内の下流アプリケーションへのユーザー情報の引渡し
HTTPヘッダー変数またはCookieを使用すると、アクションを使用して次の種類の情報を渡すことができます。
ユーザー・プロファイル
ユーザーのDN
静的なテキスト文字列
ヘッダー変数を使用して情報を下流のアプリケーションに渡す方法の詳細は、「HTTPヘッダー変数およびCookieの使用方法の概要」を参照してください。
ヘッダー変数およびCookieの使用に関するガイドラインは、第5章の「HTTPヘッダー変数およびCookieの使用方法の概要」の項を参照してください。
ヘッダー変数の値が動的であっても、その値はアクセス・サーバーのキャッシュがリフレッシュされるまでは使用できるようになりません。
リフレッシュ間隔は、「アクセス・サーバー構成/<アクセス・サーバー名>」画面の「ポリシー・キャッシュ・タイムアウト」フィールドで設定します。動的な値を持つヘッダー変数を使用する場合は、リフレッシュ間隔をマスター管理者に確認してください。
Webサーバーによってヘッダー変数の処理方法は異なります。これは、アプリケーションで必要となる、ヘッダー変数の実装方法にも影響します。
次に例をあげます。
Netscape/iPlanet Webサーバーでは、Oracle Access Managerの変数の前に文字列HTTPが付加されます。
HTTP_CNという変数を定義すると、Netscape/iPlanetではHTTP_HTTP_CNという変数が生成されます。
作成するアプリケーションでヘッダー変数を読み取る必要がある場合、そのアプリケーションでは、HTTP_CNではなくHTTP_HTTP_CNという変数を検索する必要があります。
Microsoft IISでは、ヘッダー変数の定義にはアンダースコアではなくダッシュを使用する必要があります。このため、HTTP_CNではなくHTTP-CNと入力する必要があります。
受信側アプリケーションでは、この変数を、アンダースコアが含まれているものとして読み替える必要があります。つまり、アプリケーションでは、HTTP-CNではなくHTTP_CNを検索します。
Lotus Domino Webサーバーでは、Oracle Access Managerのヘッダー変数を渡すことはできません。
各種サーバーでのヘッダー変数の使用方法の詳細は、使用しているWebサーバーのドキュメントを参照してください。
アクションにより、ユーザーに関する情報を同一または別のポリシー・ドメイン内のその他のアプリケーションに渡すことができます。表6-3に、アクションの使用方法の例を示します。
表6-3 アクションによるその他のアプリケーションへの情報の引渡し
| タスク | 例 |
|---|---|
|
受信側アプリケーションとのエンドユーザーのインタラクションのパーソナライズ |
アクションを使用して、ユーザーの名前を下流のアプリケーションに送信できる。 アプリケーションでは、この名前を使用して、パーソナライズされたメッセージをユーザーのログイン時に表示できます。 |
|
ヘッダー変数での情報の引渡し |
ヘッダー変数は次の目的で使用できる。 SSOが機能するためには、ターゲット・アプリケーションで変数が使用可能である必要があります。 |
|
認可の試行が失敗または成功した場合の特定のURLへのユーザーのリダイレクト |
リダイレクションを使用してユーザーを別のサイトに転送できる。 たとえば、認可の後にユーザーをポータル・ページにリダイレクトできます。 |
認可アクションを構成する場合、HTTPヘッダー変数を使用して、静的な値を渡したり属性を識別したりできます。詳細は、「アクションおよびヘッダー変数」を参照してください。認可アクションでは、認可ルールを起動するすべてのHTTPリクエストでヘッダー変数が戻されます。ヘッダー変数は、認証に関連する最初のHTTPリクエストでのみ戻されます。
認証アクションにobmygroupsパラメータを構成した場合、ユーザーがリソースにアクセスし、関連付けられたルールに基づいてアクセスを認可されると、そのユーザーが特定のURLに対して認可されたという事実とともにヘッダー変数がキャッシュされます。URLにアクセスした後、ユーザーが新しいグループに追加された場合、キャッシュが期限切れになるか、キャッシュ内のアイテム数によりキャッシュから認可がプッシュされるか、ポリシーの変更によってキャッシュ・フラッシュが強制されるまで、新しいグループのメンバーシップはobmygroupsの結果に表示されません。ユーザーがリソースにアクセスする前にグループに追加された場合、ユーザーがリソースにアクセスして認可されると、グループが表示されます。これらの結果はキャッシュされます。ユーザーがグループから削除された場合、ユーザーの認可がキャッシュから削除されるまで、グループはobmygroupsに引き続き表示されます。
|
関連項目: obmygroupsの使用によるパフォーマンスへの影響およびチューニングのヒントについては、『Oracle Access Managerデプロイメント・ガイド』を参照してください。 |
認可条件式の結果に対して、またその最終的な結果を決定する要因となった1つ以上のルールの結果に対して、各アクションが戻されます。アクセス・サーバーがアクションを戻すのは、要因となったルールの結果に対してです。つまり、要因となった最後のルールと、それに影響を与えたルールの結果に対してです。戻されるアクションは、次のようにして決定されます。
認可条件式の結果がアクセスの拒否の場合、要因となったすべてのルールに対して認可失敗アクションが戻されます。
たとえば、次の、論理積条件と論理和条件の混合した認可条件式で、ユーザーがルール5、6および7のアクセスの拒否条件の対象になるとします。これらの各ルールに対しては認可失敗アクションが戻されますが、ルール3に対してはアクションは戻されません。
(R5 AND R6) AND (R3 OR R7)
認可条件式の結果がアクセスの許可の場合、要因となった各ルールに対して認可成功アクションが戻されます。
たとえば、次の、論理積条件と論理和条件の混合した認可条件式で、ユーザーがルール1、2および4のアクセスの許可条件の対象になるとします。アクセス・サーバーにより、要因となったルール1、2および4に対して認可成功アクションが戻されます。
(R1 AND R2) AND (R4 OR R3)
ルール4は要因となった最後のルールであるため、アクセス・サーバーではルール4の後に式の評価を終了します。ルール3は結果に影響を与えないため、評価されません。
2つ以上のルールの評価結果に対するアクションを組み合せて、目的の結果を得ることができます。たとえば、次の式のルール1および2に対する認可成功アクションを組み合せて、認可されたユーザーに対してパーソナライズされた応答を表示できます。
Rule 1 AND Rule 2 OR Rule 3
ルールに対するアクションの指定方法は次のとおりです。
ルール1に対する認可成功アクションでは、アクセス・サーバーはユーザーのcnをHTTP_CNヘッダー変数に入れて戻します。
ルール2に対する認可成功アクションでは、アクセス・サーバーはテキストHelloをヘッダー変数HTTP_GREETINGに入れて戻します。
たとえば、Sonalは式の論理積条件の両方のルールの対象になるとします。つまり、マーケティング部門グループのメンバーであると同時に、使用しているコンピュータのIPアドレスは192.168.2.123です。式の評価の後で、認可に成功したため、Sonalがリクエストしたリソースである下流のアプリケーションにログインすると、パーソナライズされた応答が表示されます。
ポリシー・ドメインのデフォルト認可ポリシーおよび個別ポリシーにアクションを設定した場合は、どのポリシーを強制するかによって、ユーザーに適用されるアクションは異なってきます。たとえば、ポリシー・ドメインに次の3つのポリシーを定義するとします。
Policy 1
Policy 2
Policy 3
各ポリシーは上から下に順番にチェックされます。ドメインにリストされている3番目のポリシーを強制する場合、ポリシー3に定義されているアクション（ヘッダー変数など）が採用されます。特定のアクションが常に使用されるようにするには、そのアクションをポリシー・ドメインの各ポリシーに追加します。
アクションを複数のポリシーに追加する場合は、そのアクションが複数回戻されないようにしてください。同じアクションが複数回戻される場合の問題点については、「重複アクションの概要」を参照してください。
次の各項目は、認可アクションを操作する手順について説明しています。
認可成功および認可失敗の結果に対応する認可ルールのアクションを定義するには、「アクション」機能を使用します。アクションを使用して、属性の値など、特定の値を戻します。
指定するアクションは、アクセス条件と次のように対応します。
認可成功アクションは、アクセスの許可条件に適用されます。
認可失敗アクションは、アクセスの拒否条件に適用されます。
アクセス・システムを起動し、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択します。
アクションを設定する認可ルールが含まれるポリシー・ドメインを選択します。
「認可ルール」タブを選択します。
ポリシー・ドメインの認可ルールをリストしたページが表示されます。
|
注意: ポリシー・ドメインの作成中である場合は、認可ルールは表示されません。 |
アクションを設定する認可ルールを選択します。
「アクション」をクリックします。
「追加」をクリックします。
次の各条件に対し、実行するアクション（リダイレクトURLおよび戻すユーザー情報）を構成します。
認可成功
認可失敗
「保存」をクリックします。
非結合ドメインがある場合は、認可スキームを構成して、非結合ドメインに存在する同一ユーザーIDのユーザーを検索できるようにする必要があります。
定義する成功時アクションに、次の値を設定する必要があります。
タイプ: HEADERVAR
名前: HTTP_OBLIX_UID
戻り属性: obuniqueid
|
注意: これは、デフォルトのIdentityドメインとアクセス・ポリシー・ドメインの両方に行う必要があります。 |
さらに、次の構成ファイルの変更を行う必要があります。
次のファイルでwhichAttrIsLoginの値をObUniqueIDに変更します。
PolicyManager_install_dir/access/oblix/apps/common/bin/globalparams.xml
同じ変更を次のファイルでも行います。
IdentityServer_install_dir/identity/oblix/apps/common/bin/globalparams.xml
認可条件式の評価の3種類の結果（式の評価の認可成功、認可失敗および未確定）に対して、アクションを定義できます。
アクセス・システムを起動し、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択します。
アクションを設定する認可条件式が属するポリシー・ドメインを選択します。
「デフォルト・ルール」を選択します。
「認可条件式」タブを選択します。
「アクション」をクリックします。
「追加」をクリックします。
次の各条件に対し、式の評価結果に応じて実行するアクション（つまり、使用するリダイレクトURLおよび戻すユーザー情報）を構成します。
認可成功
認可失敗
認可未確定
「保存」をクリックします。
次の2つの場合には、認可条件式に対して未確定結果が戻されます。
ユーザーが矛盾するアクセスの許可ルールとアクセスの拒否ルールの対象になった場合
ユーザーが式のどのルールの対象にもならなかった場合
式の評価結果が未確定の場合にアクセス・サーバーから戻されるステータス・コードの詳細は、「未確定結果のステータス・コード」を参照してください。
認可ルールは認可条件式内で再利用できるため、同じ結果を戻す各認可ルール・インスタンスが評価されることがあり、そのような場合は、アクセス・サーバーから同じアクションが複数回戻されることがあります。
また、式内の異なるルールにより同じアクションが戻される場合もあります。式の評価後に、最終的な結果を戻す複数のルールにより同様のアクションが生成される場合は、競合が発生することがあります。（最終的な結果の詳細は、「式のルールの評価の概要」を参照してください。）
たとえば、あるルールのアクションによりHTTP_GREETING変数がテキスト文字列に設定され、別のルールのアクションによりこの変数が別の値に設定される場合、両方のルールのアクションが戻されると競合が発生します。HTTP_GREETINGは1つのテキスト文字列にしか設定できないため、アクセス・サーバーではどちらを使用するかを決定する必要があります。
リダイレクトURL以外のアクションには、アクセス・サーバーによる重複アクションの処理方法を決定するオプションを設定できます。
|
警告: リダイレクトURLの場合は、アクセス・サーバーにより、前回受信されたURLが戻されます。この動作はオーバーライドできません。 |
アクセス・サーバーが重複アクションを処理する方法は、構成可能なシステム・デフォルト設定により決定されます。ただし、ポリシー・ドメインおよびポリシーの個々の認可条件式に対するシステム・デフォルト動作はオーバーライドできます。次の3つの動作のいずれかを選択できます。
重複: このオプションを選択すると、アクセス・サーバーでは、受信した新しい値のすべてを、ユーザーの認可をリクエストしているアプリケーションに戻す情報に付加します。（アクセス・サーバーでは、重複情報がないかどうかはチェックしません。）このオプションは、アプリケーションでアクションのすべてのインスタンスの情報を受信する必要がある場合に選択します。この場合、アプリケーションでは、受信したすべての重複アクションの値を処理する必要があります。このオプションを使用すると、パフォーマンス上の問題が発生する場合があります。
重複の無視: このオプションを選択すると、アクセス・サーバーではすべての重複アクションを削除し、ユーザーの認可をリクエストしているアプリケーションにはアクションの最初のインスタンスのみが戻されます。アクション値が追加されるたびに、アクセス・サーバーでは既存の値をチェックして、この新しいアクションが既存のアクションと重複していないかどうかを検出します。重複を検出した場合、アクセス・サーバーでは、アプリケーションに戻す情報に新しい値を追加しません。この場合、重複アクションの値に固有の情報は失われます。
アクセス・サーバーでは重複アクションがないかをチェックする必要があるため、このオプションを使用するとパフォーマンスに負荷をかける場合があります。
オーバーライド: このオプションを選択すると、アクションの最新のインスタンスの値のみが戻されます。新しい値を受信するたびに前の値が上書きされるため、前の値はすべて失われます。このオプションは、認可をリクエストしているアプリケーションですべての重複アクションの結果を受信する必要がある場合には選択しないでください。このオプションが最も高速です。
アクセス・サーバーによる重複アクション（存在する場合）の処理方法に対し、システム・デフォルト設定を指定できます。デフォルトでは、このシステム設定が、すべての認可条件式の評価時に発生する重複アクションのアクセス・サーバーによる処理に適用されます。ただし、個々の認可条件式に対しては、この設定をオーバーライドできます。
重複アクションに対するシステム・デフォルト動作をアクセス・サーバーに設定する手順
アクセス・システムを起動し、アクセス・システム・コンソール→「アクセス・システム構成」の順に選択します。
「共通情報の構成」を選択します。
「重複アクション」をクリックします。
ラジオ・ボタン（「重複」、「重複の無視」または「オーバーライド」）を選択して重複アクションに対する動作を設定します。
「保存」をクリックします。
サーバーを再起動して「重複アクション」ポリシーの変更を有効にします。
各認可条件式に対し、式の評価の結果として発生する重複アクションのアクセス・サーバーによる処理方法を指定できます。認可条件式の「重複アクション」値を設定すると、重複アクションに対するシステム・デフォルト動作がオーバーライドされます。
アクセス・システムを起動し、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択します。
認可条件式が属するポリシー・ドメインを選択します。
「デフォルト・ルール」を選択します。
ポリシー・ドメインのデフォルト・ルールと認可条件式をリストしたページが表示されます。
「認可条件式」タブを選択します。
「重複アクション」をクリックします。
「重複アクション・ヘッダー」ページが表示されます。
重複アクションに対する動作のラジオ・ボタン（「重複」、「重複の無視」または「オーバーライド」）を式に対して選択します。
ユーザーの認可成功または認可失敗の後に実行するカスタム・アクションを指定できます。カスタム・アクションを実装するには、認可プラグインが必要です。カスタム・アクションを定義すると次のようになります。
認可成功アクションは、アクセスの許可条件に適用されます。
認可失敗アクションは、アクセスの拒否条件に適用されます。
プラグインの作成の詳細は、『Oracle Access Manager開発者ガイド』を参照してください。アクションの詳細は、「認可アクションの概要」を参照してください。
アクセス・システムを起動し、「ポリシー・マネージャ」→「ポリシー・ドメイン」の順に選択します。
認可ルールが属するポリシー・ドメインを選択します。
「認可ルール」タブを選択します。
ポリシー・ドメインの認可ルールをリストしたページが表示されます。
ポリシー・ドメインの作成中である場合は、構成済認可ルールは表示されません。
カスタム・アクションを設定する認可ルールを選択します。
「カスタム・アクション」をクリックします。
認可プラグインが少なくとも1つ定義されていない場合は、「カスタム・アクション」は選択できません。
「追加」をクリックします。
ユーザーの認可成功または認可失敗の後に実行するカスタム・アクションに関する情報を入力します。
「保存」をクリックします。
|
注意: カスタム・アクションは、認可成功または認可失敗に対して複数個定義することができます。 |
認可タスクを実行するカスタム・プラグインに対して認可スキームを作成できます。認可スキームを作成および管理するには、マスター・アクセス管理者である必要があります。委任アクセス管理者ができるのは、作成された認可スキームを認可ルールに追加することです。
アクセス・システムには、Oracle認可スキームというデフォルト認可スキームが用意されており、作成した認可ルールで使用できます。なお、カスタム認可スキームを作成して、デフォルト・スキームのタスクとは異なるタスクや追加のタスクを実行するために使用するカスタム・プラグインを含めることもできます。委任アクセス管理者ができるのは、カスタム認可スキームが作成された後に、そのようなプラグインを認可ルールに追加することです。
アクセス・システムでは、C、C++、Visual Basicなど、Microsoft .NET Frameworkでサポートされているすべての言語での認可プラグインの作成をサポートしています。『Oracle Access Manager開発者ガイド』で、認可プラグインが管理コードであるかどうかの詳細を参照してください。
カスタム認可プラグインは、アクセス・サーバーがユーザー認可の権限およびアクションを判定する外部ビジネス・ロジックをコールする際に使用する共有ライブラリ（.dllまたは.so）です。
あらゆる用途用にカスタム・プラグインを作成できます。たとえば、ユーザーの銀行残高をメインフレーム・アプリケーションで検索して認可の権限を判定できます。
カスタム認可プラグインでは、認可アクションをその他のパラメータとともに渡すこともできます。カスタム・プラグインで渡すことができる情報のタイプは、認可ルールに構成可能な情報のタイプと同じです。この情報のタイプは次のとおりです。
ユーザー・プロファイルの属性
構成パラメータ（必須またはオプション）
コンテキスト固有の情報（HTTPヘッダー情報など）
カスタム認可プラグインを作成します。
詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
組織のOracle Access Manager開発者が、認可プラグイン・アプリケーション・プログラミング・インタフェース（API）を使用してカスタム認可プラグインを作成します。認可プラグインAPIを使用して、アクセス・サーバーは外部ビジネス・ロジックをコールし、ユーザーがリソースにアクセスする権限があるかどうかを判定できます。
マスター・アクセス管理者が、使用する各カスタム・プラグインに対して認可スキームを構成します。「カスタム・プラグインの認可スキームの概要」を参照してください。
スキームには、カスタム・プラグインに関する情報（プラグインの場所やプラグインが取るパラメータなど）を指定します。
ポリシー・ドメインの管理権限を持つ委任アクセス管理者が、認可スキームを認可ルールに追加します。これで、この認可ルールは、ポリシー・ドメインまたはポリシー・ドメインの任意のポリシーの1つ以上の認可条件式に追加できるようになりました。
|
注意: カスタム認可プラグインは、保護対象とするアプリケーション・サーバーごとにインストールする必要があります。 |
この項では、次の各項に分けて、カスタム・プラグインに対して認可スキームを作成および構成する方法について説明します。
認可スキームを作成するには、アクセス・システム・コンソールの「アクセス・システム構成」コンポーネントの「認可管理」機能を使用します。スキームを作成する際、共有ライブラリに渡す情報を「ユーザー・パラメータ」、「必須パラメータ」および「オプションのパラメータ」フィールドに入力します。また、認可スキームには1つ以上のカスタム・プラグインを指定します。
プラグインの共有ライブラリを指定する際は、プラグインの絶対パスまたは相対パスのいずれでも指定できます。相対パスは、アクセス・サーバーのインストール・ディレクトリとの関係で評価されます。
次に例を示します。
lib/myplug_in
これは、次のように評価されます。
AccesServer_install_dir/access/oblixaccess/oblix/lib/my_plug_in
共有ライブラリの作成方法の詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
ユーザー・パラメータは、認可スキームの起動時に共有ライブラリに渡されるユーザー属性です。
デフォルトでは、ユーザーのDN（識別名）とIPアドレスが共有ライブラリに渡されます。この設定は変更できません。ただし、保護されているリソースをリクエストしているユーザーを識別するために役立つその他の属性を選択することは可能です。
すべてのパラメータは名前/値のペアになっています。プラグインの必須パラメータは、マスター・アクセス管理者により構成されます。パラメータは、認可スキーム・レベルまたはルール・レベルで渡すことができます。
パラメータの名前/値ペアを認可スキーム・レベルで渡す場合、それをルール・レベルでオーバーライドすることはできません。
委任アクセス管理者は、プラグインを使用する認可ルールを構成する際、スキーム・レベルで指定されていないすべての必須パラメータの値をルールに指定する必要があります。これにより、これらのパラメータが実行時にプラグインに渡されるようになります。
必須パラメータの名前/値ペアをスキーム・レベルで指定しない場合は、ルール・レベルで指定する必要があるということです。
オプションのパラメータは、プラグインの動作を詳細に定義する際に役立ちます。プラグインのオプションのパラメータは、マスター・アクセス管理者により構成されます。委任アクセス管理者は、プラグインを使用するよう認可ルールを構成する際、これらの各パラメータに名前/値ペアを指定することも指定しないこともできます。指定されたオプションのパラメータは、実行時にプラグインに渡されます。
たとえば、銀行口座へのアクセスを許可されているユーザーが、口座の残高を超える金額を引き出すことを望んでいるとします。この場合、オプションのパラメータによりこの口座には当座貸越保護はないと指定することで、ユーザーのリクエストを拒否できます。
新しい認可スキームを作成する場合は、その前に既存の認可スキームの内容および定義を表示できると便利な場合があります。
アクセス・システムを起動し、アクセス・システム・コンソール→「アクセス・システム構成」→「認可管理」の順に選択します。
「認可管理: すべての認可スキームをリスト」画面が表示されます。
表示するスキームのリンクをクリックします。
「認可スキームの詳細」ページにそのスキームの設定が表示されます。
既存の認可スキームが要件を満たさない場合、新しい認可スキームを作成できます。その場合、前の各項で説明したように、カスタム・プラグインを新しいスキームに追加する必要があります。マスター・アクセス管理者のみが、認可スキームを作成できます。
アクセス・システムを起動し、アクセス・システム・コンソール→「アクセス・システム構成」→「認可管理」の順に選択します。
「認可管理: すべての認可スキームをリスト」ページが表示されます。
「追加」をクリックします。
「新規認可スキームの定義」ページが表示されます。
「名前」フィールドで、認可スキームの名前を入力します。
「説明」フィールドで、スキームの簡単な説明を入力します。
管理コードを使用するプラグインを開発する場合は、入力項目「プラグインは管理コードです」に対して「はい」を選択します。
管理コードを使用する場合は、「管理コードのネームスペース」フィールドにネームスペースを入力します。（管理コードを使用しない場合は、このフィールドは空白のままにします。）
「共有ライブラリ」フィールドで、プラグイン・ファイルのフルパス、またはアクセス・サーバーのインストール・ディレクトリからのプラグイン・ファイルの相対パスを、ファイル拡張子の指定なしで入力します。
「ユーザー・パラメータ」フィールドで、プラグインに渡すLDAP属性を入力します。
外部ソースからプラグインにデータを渡す（たとえばHTTPヘッダー変数などを渡す）手順については、「認可リクエストの外部データの取得」を参照してください。
「必須パラメータ」フィールドで、ポリシー・ドメインの認可ルールからプラグインへの送信が必須なパラメータの名前と値を入力します。
ここで指定したパラメータの値を、エンドユーザーが変更することはできません。
「オプションのパラメータ」フィールドで、ポリシー・ドメインの認可ルールからプラグインに追加で送信するパラメータの名前と値を入力します。
ここで指定したパラメータの値を、エンドユーザーが変更することはできません。
「ユーザー・パラメータ」、「必須パラメータ」および「オプションのパラメータ」フィールドで、フィールドを追加または削除するには、プラス（+）またはマイナス（-）記号をクリックします。
「保存」をクリックします。
認可スキームを変更できるのは、マスター・アクセス管理者のみです。
アクセス・システムを起動し、アクセス・システム・コンソール→「アクセス・システム構成」→「認可管理」の順に選択します。
「認可管理: すべての認可スキームをリスト」ページが表示されます。
変更するスキームのリンクをクリックします。
「認可スキームの詳細」画面が表示されます。
「変更」をクリックします。
「認可スキームの変更」画面が表示されます。
必要なパラメータ変更を行います。
「保存」をクリックします。
認可スキームは、外部ソースからデータを取得できます。これには、ポータルで設定されたセッション、Cookieまたはヘッダー変数などがあります。通常、このデータは、リソースに対するアクセスをリクエストしているユーザーに関する情報です。このデータは、カスタム認可プラグインに渡されます。外部データを取得すると、認可の決定を動的に行うことが可能になります。たとえば、ユーザーがフォームに移動して、ある品目を1,000ドルで購入する場合、この1,000ドルという金額が制限（データベースに格納されていることが多い）を超えていないかどうかが動的に評価され、購入が認可されるかどうかが判定されます。
Oracle Access Managerでは、外部データを取得するのに、リバース・アクションとして認可リクエストを使用します。リバース・アクションとは、データを取得するためのプロセスのことです。一般に、Oracle Access Managerを使用するときは、データはアクセス・サーバーからアクセス・ゲートまたはWebGateに流れます。これとは反対に、リバース・アクションでは、データはアクセス・ゲートまたはWebGateからアクセス・サーバーに送信されます。
リバース・アクション機能は、WebGateおよびカスタム・アクセス・ゲートを使用する場合に利用できます。どちらの場合も、カスタム認可プラグインを作成する必要があります。次に、このプラグインのベースとして使用できるソース・コード例を示します。
Access_Server_install_dir\oblix\sdk\authorization\samples\ req_context.c
認可スキームを構成する際に、このコードのコンパイル時に作成される共有ライブラリのパスと名前を指定するように要求されます。複数のプラットフォーム上に、このライブラリにアクセスするアクセス・サーバーがある場合は、ライブラリのパスと名前がすべてのアクセス・サーバーで同じである必要があります。
詳細は、『Oracle Access Manager開発者ガイド』を参照してください。特に、ObUserSessionクラスのisAuthorizedコールに関する情報を参照してください。
リバース・アクションを正しく処理するカスタム・アクセス・ゲートを作成した場合、このプラグインのエラー処理は次のように行われます。isAuthorizedコールが認可プラグインに必須データを渡すことに失敗すると、Access Manager SDKによりObUser_ERR_NEED_MORE_DATAが戻されます。この場合、アクセス・ゲートではObResourseRequest構造のgetAuthorizationParametersコールを使用して必要なデータを識別し、収集してisAuthorizedコールを再発行できます。Access Manager SDKのインストール・ディレクトリにあるaccess_test_cplusプログラムには、これらのコールの例が含まれています。
「カスタム・プラグインの認可スキームの概要」の手順に従って、認可スキームを作成します。
「ユーザー・パラメータ」フィールドで次のように入力します。
RA_source$name
または
RA_name
ここで、sourceは次のいずれかになります。
server
header
post
query
cookie
ユーザー・パラメータの詳細は、「ユーザー・パラメータ」を参照してください。
sourceの値を省略すると、リストに並んでいる順序どおりに各ソースが検索されます。Webサーバーのソース（serverパラメータ）がその他のソースより優先されるのです。これにより、ユーザーが設定するリクエスト・データがWebサーバーのデータをオーバーライドすることが防止されます。たとえば、ユーザーから送信されたremote_user Cookieが、Webサーバーから送信されたremote_user変数をオーバーライドすることがなくなります。WebGateは、リクエストされたデータをHTTPリクエストから自動的に抽出します。
このデータを収集するかどうかは、Access Manager APIをコールするアプリケーション・プログラムで決定します（Access Manager SDKを使用してカスタム・クライアントまたはアクセス・ゲートを作成する場合）。
WebGateまたはカスタム・アクセス・ゲートにより送信される外部データを処理して認可の決定を戻す（および必要に応じてアクション・データも戻す）カスタム認可プラグインを作成します。
この手順で定義した認可スキームでは、ユーザー・パラメータのRA接頭辞により、アクセス・サーバーは認可プラグインに制御を移動して外部リクエストを行うように指示されます。
ほとんどのブラウザでは、サーバーに送信するHTTPリクエスト内でいくつかの標準ヘッダーを使用できます。この例では、認可スキームは、accept-languageヘッダーを使用して、ユーザーのブラウザから送信されるこのヘッダーの値を取得するようWebGateに指示し、ブラウザの言語がen-usに設定されている場合にユーザーを認可します。
次の例では、サンプルとして同梱されているreq_contextという名前の認可プラグインにより、受信したヘッダー内の値がもう1つの値と比較されます。
req_context認可プラグインは、外部データを検索する認可アクションにより取得されるHTTPヘッダーなどの外部データをチェックする汎用プラグインです。このプラグインにより、外部データが指定の値（固定値またはユーザー属性値）と比較されます。「タイプ」パラメータがfixed（固定）の場合は、「名前」パラメータで指定されたデータを「値」パラメータ内の実際の文字列と比較することを意味します。「タイプ」パラメータがattribute（属性）の場合は、「名前」パラメータの名前付き外部データを「値」パラメータに指定されたユーザー属性の値と比較することを意味します。この例では固定値が使用されていますが、ターゲット値を属性にすることもできます。
たとえば、米語のブラウザのみを許可する1つの認可ルールに対するプラグイン・パラメータreq_contextは、次のように指定できます。
この例では、accept-languageヘッダーの値が固定値（つまりfixedの値）のen-usと比較されます。
フランス語のブラウザのみを許可する認可ルールは、次のように指定できます。
このreq_contextプラグインを使用すると、ユーザーのブラウザの言語がユーザーのディレクトリ・エントリ内のexpected-language属性でユーザーに構成されている言語に一致するかどうかを、次のようにしてチェックできます。
固定値を検索する別の方法として、en-usがないかのチェックのみを行う専用のプラグインも作成できます。その場合、必須パラメータはユーザー属性RA_accept-languageのみです。
|
注意: 次の手順に示すスキームをテストする場合、ブラウザによってはaccept-languageヘッダーの取得で大/小文字が区別されますので、注意してください。 |
アクセス・システム・コンソールで、Browser Languageという名前の認可スキームを作成します。
Browser Language認可スキームを定義すると、このスキームが「認可管理」ページのスキームのリストに表示されます。認可スキームの詳細は次のとおりです。
ここで、「共有ライブラリ」は、次のプラグインのサンプル・コードに基づいています。
oblix\sdk\authorization\samples\req_context.c
詳細は、「認可リクエストの外部データを取得する手順」を参照してください。また、このスキームでは、「ユーザー・パラメータ」にRA_accept_languageが使用されています。このスキームの「必須パラメータ」として、「名前」がaccept-languageに、「タイプ」がfixedに指定されていて、「値」は未指定です。
「ポリシー・マネージャ」で、新しいポリシー・ドメインを定義します。
このポリシー・ドメインの認可ルールでは、次のように、ユーザーのブラウザの言語設定を検索し、ブラウザの言語の値がen-usの場合にユーザーを認可します。
名前: Browser language
リソース: http（保護されているリソース）
認可ルール名: Browser Language English
認可ルール: 一般: 認可スキーム（アクセス・システム・コンソールで定義済）はBrowser Language
認可ルール: プラグイン・パラメータ: 渡されるプロファイル属性はRA_accept-language、値はen-us
このポリシー・ドメイン用のプラグイン・パラメータは、次のようになります。
監査ルールにより、イベント・ベースのデータが監査ログ・ファイルに書き込まれます。マスター・アクセス管理者は、マスター監査ルールをアクセス・システム・コンソールで作成する必要があります。委任アクセス管理者は、マスター監査ルールから自分のポリシー・ドメインおよびポリシー用に監査ルールを導出できますが、新しいマスター監査ルールは作成できません。
アクセス・サーバーごとに1つの監査ログ・ファイルがあります。サーバーに対して監査ログ・ファイルのサイズとローテーション間隔を構成できます。イベントによっては、監査ログに重複した監査エントリが含まれる場合があります。
ユーザーがリクエストしたリソースを使用する権限があるかどうかによって、異なる情報が監査ログに書き込まれます。
認可が失敗し、ユーザーの情報がディレクトリに存在しない場合は、アクセス・サーバーではリソースへのアクセスをユーザーに対して拒否します。この場合、cn属性がログ・エントリに書き込まれます。その他の属性は存在しないため、書き込まれません。givennameなどの属性は、ユーザーに関するエントリがないため無意味になります。これは、リソースへのアクセスをリクエストしたユーザーが以前に認証されたことがない場合です。
ポリシー・ドメインとポリシーの監査ルールを定義できます。定義する監査ルールは、マスター監査ルールから導出する必要があります。マスター監査ルールは、マスター・アクセス管理者が作成する必要があります。委任アクセス管理者はマスター監査ルールからアクセス・ルールを導出できますが、作成はできません。
ポリシー・ドメインおよびポリシーの監査ルールの作成、定義方法の詳細は、ポリシー・ドメインに関する章の次の各項を参照してください。
