| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
|
前 |
次 |
条件を追加するメカニズムは、どのタイプを選択しても同じです。
認可ポリシー内で条件を使用する目的は、次のとおりです。
ユーザー名、ロールまたは、ユーザーが満たす必要のある基準を含むLDAPフィルタによって、ユーザーを識別します。
ユーザーがリソースへのアクセスに使用できるコンピュータを指定します。
ルールが適用される時間帯を設定します。
リクエスト・コンテキスト、ユーザー・セッションの状態およびユーザー属性の評価を実行する属性の指定。
表示されたダイアログ・ボックスで、名前およびタイプを定義して条件のコンテナを作成します。その後、提供されたコントロールを使用して条件の詳細を定義します。
この項の内容は次のとおりです。
この項では次のトピックを記載しています:
ポリシー内では、特定の条件タイプのインスタンスを複数保持できます。
管理者が条件を認可ポリシーに追加すると、名前、タイプおよびオプションの説明を入力できるウィンドウ(図25-17)が表示されます。送信されると、この情報を使用して、同じく指定する必要がある条件詳細のコンテナが作成されます。
表25-12は、「条件の追加」の要素を説明しています。
表25-12 「条件の追加」ウィンドウの要素
| 要素 | 説明 |
|---|---|
名前 |
この条件の一意の名前。 |
タイプ |
次のタイプから1つのみ指定できます。
|
説明 |
オプション。 |
コンテナを追加すると、図25-18のように、そのコンテナが「条件」タブに表示されます。「名前」、「タイプ」および「説明」は、タブの最上部にある「結果」表に表示されます。下部のパネルには、条件の詳細が含まれます。
関連項目:
詳細および手順は、「認可ポリシー条件の定義」を参照してください。
この項では、アイデンティティ条件に関するすべての情報を提供します。内容は次のとおりです。
アイデンティティ条件を定義する場合、1つ以上のユーザー・アイデンティティ・ストアから、ユーザー移入の1つ以上のメンバーを追加する必要があります。
ユーザー移入は、ユーザーまたはグループのリストとして追加できます。また、実行時に使用するLDAP検索フィルタを追加して、ユーザー移入を識別することもできます。LDAP検索フィルタを使用すると、アイデンティティ・ストア(ディレクトリ・サーバー)内に新しいグループを再編成または作成することなく、ターゲット・アイデンティティの移入を簡単に指定できます。詳細は、次の各項を参照してください。
条件コンテナを開いた後、定義されたユーザー移入が表示されます。他の条件タイプと同様、アイデンティティ・タイプはアイデンティティ条件および一時的条件と組み合せて使用できます。
アイデンティティ条件を追加する場合、「追加」(+)ボタンの横にあるポップアップ・メニューを開き(図25-19の1)、「ユーザーとグループの追加」または「検索フィルタの追加」(2)を選択します。図25-19は、ポップアップ・メニューおよび表示される「アイデンティティの追加」ウィンドウ(3)を示しています。目的のアイデンティティを検索したら、それらを選択し、「選択済の追加」(4)をクリックします。
表25-13は、「アイデンティティの追加」の要素を示しています。
表25-13 「アイデンティティの追加」の要素
| 要素 | 説明 |
|---|---|
ストア名 |
この検索に使用するLDAPストアを、登録されたLDAPストアのリストから選択します。 |
エンティティ・タイプ |
「ユーザー」、「グループ」または「すべて」を選択して、検索基準を定義します。 |
エンティティ名 |
情報を入力して検索基準をさらに絞り込みます。 |
検索 |
検索基準が定義されたときにこのボタンをクリックします。 |
結果表 |
検索結果を表示します。 |
選択済の追加 |
クリックして、選択したユーザーまたはグループを結果表から条件の詳細に追加します。 |
1つ以上のアイデンティティを選択し、「選択済の追加」ボタンをクリックすると、「条件」タブは図25-20のようになります。
条件としてこれらの詳細を保存するには、タブの右上の「保存」ボタンをクリックします。
Access Manager 11gの認可条件では、許可または拒否されるアイデンティティの一部として、ユーザー、グループおよびLDAP検索フィルタのリストが受け入れられます。LDAPフィルタは、検索操作の特定の基準を表現するテキスト文字列です。LDAP検索フィルタを使用すると、アイデンティティ・ストア(ディレクトリ・サーバー)内に新しいグループを再編成または作成することなく、ターゲット移入を簡単に指定できます。
Access Manager 11gでは、次の条件およびリソース・タイプ用のLDAP検索フィルタ・データが受け入れられます。
アイデンティティ条件
トークン・リクエスタ・アイデンティティ条件
すべてのリソース・タイプ(HTTP、TokenServiceRPおよびその他のカスタム・リソース・タイプ)
ユーザーがLDAP検索フィルタを含む条件によって保護されているリソースへのアクセスを試行すると、Access Managerによって、フィルタの一部として指定されたアイデンティティ・ドメイン(アイデンティティ・ストア)に対するディレクトリ検索(LDAP検索)が実行されます。検索結果はキャッシュされるため、ディレクトリ・サーバー検索が繰り返し実行されることはありません。
「検索フィルタの追加」を選択すると、図25-21のようなコントロールが表示されます。複数のLDAP検索フィルタを認可ルールに追加し、実行時の評価に使用できます。LDAP検索フィルタを入力したフィールドは、許可または拒否されるユーザーの識別に使用されます。
表25-14は、検索フィルタの追加に関連付けられている要素を示しています。
表25-14 「検索フィルタの追加」の要素
| 要素 | 説明 |
|---|---|
ドメイン |
実行時に検索する必要があるアイデンティティ・ドメイン(登録されたユーザー・アイデンティティ・ストア)。各フィルタは特定のユーザー・アイデンティティ・ストアに関連付けられている必要があります。Access Manager 11gでは、指定されたアイデンティティ・ドメイン(アイデンティティ・ストア)に対してのみディレクトリ検索(LDAP検索)が実行されます。 |
検索フィルタ |
LDAP検索フィルタを入力するフィールド。次に例を示します。 ((|dept=sales)(dept=support)) 関連項目: 「LDAP検索フィルタの構文」 |
テスト・フィルタ |
このボタンを使用すると、LDAP検索フィルタをテストして、予想した結果が返されるかどうかを確認できます。 |
テスト結果 |
フィルタ・テストの結果は、独自に指定した次の内容とともに表示されます。
|
フィルタの追加 |
このアイデンティティ条件にフィルタを追加するときにクリックします。 |
取消 |
フィルタを追加せずに「検索フィルタの追加」ダイアログを閉じるときにクリックします。 |
図25-22は、LDAP検索フィルタの追加後に表示される、アイデンティティ条件の詳細ページを示しています。
LDAP検索フィルタの定義に使用できるのは、標準LDAP属性のみです。正確な構文はアイデンティティ・ストアによって異なるため、ベンダーのドキュメントを参照してください。
表25-15は、Access ManagerのLDAP検索フィルタの例を示しています。
表25-15 Access ManagerのLDAP検索フィルタの例
| フィルタ・タイプおよび演算子 | 説明 | 構文の例 |
|---|---|---|
静的LDAP検索フィルタ |
静的検索フィルタの実装では、すべての検索結果が固定値に一致する必要があります。たとえば、ディレクトリ・プロファイルの組織単位がSalesの人々のみを戻すように検索を制限できます。 単純な静的フィルタの例として、seeAlso属性でセレクタ検索を使用する場合を検討します。このフィルタにより、ディレクトリ・プロファイルにbusinessCategory値としてdealershipを含む人々のみが検索結果として戻されます。 |
(attribute=value) 次に例を示します。 (businessCategory=dealership) |
ワイルド・カードを使用した静的検索 |
ワイルド・カードを使用する静的フィルタの例として、セレクタを使用した検索時にManagerという語を含む役職の人々のみを戻す場合を検討します。アスタリスク(*)ワイルドカードを使用して文字列Managerを検索するフィルタを作成できます。 |
(attribute=*value*) 次に例を示します。 (title=*manager*) |
動的LDAP検索フィルタ |
動的フィルタにより、ユーザー・プロファイルに基づいた検索結果を戻すことができます。動的フィルタは、フィルタ置換構文を使用する従来のLDAP検索フィルタです。 |
(attribute=$attribute$) |
置換構文 |
置換構文は、タスクを実行するユーザーに応じて動的に評価されます。たとえば、置換構文を入力すると、ソースDN(アプリケーションにログインしているユーザー)の属性値が代入され、ターゲットDN(参照しようとしているエントリ)に対して評価されます。 ノート: 検索ベースを設定すると深刻な管理オーバーヘッドが発生する可能性があります。置換構文で指定されるフィルタ・ベース・アプローチにより提供される機能は、よりスケーラブルで簡易化された設計と同一です。 置換構文を使用すると、ディレクトリ構造の上位検索を開始する関数を作成できますが、この関数は、検索イニシエータのレコードの情報の属性(たとえば、置換 ノート: 選択された検索ベースでは、ユーザーは自分と同じ |
(attribute=$attribute$) たとえば、次のフィルタでは、同じ組織単位に属するすべてのエントリが、アプリケーションにログインしているユーザーとして検索されます。 (ou=$ou$) |
ワイルド・カードを使用した動的検索 |
動的フィルタでは、ワイルドカードがサポートされます。 例として、organizationalUnitオブジェクトのcontactPerson属性を指定する場合を検討します。contactPerson属性により、organizationalUnitオブジェクトと同じ郵便番号の人々を戻す必要があります。organizationalUnitプロファイルにzipCodeという属性が含まれており、postalAddressディレクトリ属性の最後に郵便番号が指定されている場合があります。 |
(attribute=*$attribute$) 次に例を示します。 (postalAddress=*$zipCode$) |
否定演算子(!)を使用した検索 |
フィルタの構築時には、否定演算子がサポートされます。最適化されたアルゴリズムを使用する場合、フィルタ(!(sn=white))では期待した結果は得られません。 |
((!(sn=white))(objectclass=personOC)) |
関連項目:
(10gから) Access Manager 11gへの移行中、各LDAPルールは、Oracle Access Manager 10gディレクトリ・プロファイルに基づいて、対応する11gアイデンティティ・ドメイン(ユーザー・アイデンティティ・ストア)にマップされます。Access Manager 11gアイデンティティ・ドメイン(ユーザー・アイデンティティ・ストア)は、各LDAP検索フィルタに関連付ける必要があります。
関連項目:
この項では、次の情報について説明します。
IP4範囲条件タイプを使用すると、管理者はアクセスを許可または拒否されるIPアドレス範囲のリストを指定できます。他の認可条件と同様、IP4範囲条件タイプはアイデンティティ条件および一時的条件と組み合せて使用できます。
明示的なアドレス: 指定する各IPアドレスは、明示的で有効なアドレス(形式nnn.nnn.nnn.nnn)である必要があります。たとえば、192.2.2.2のように指定します。
ノート:
Oracle Access Manager 10gでは、ワイルドカードが最後の入力として受け入れられます(192.2.2.*や192.2.*など)。ワイルドカードを含まないIP4範囲は、複数のIP4範囲の値を含む条件を作成することによって、簡単に11gに移植できます。ただし、ワイルドカードを含む10gのIP4範囲は、アップグレード・ツールの使用によって、そのワイルドカードに関連する複数の範囲に拡張されます。
IP4範囲: 「開始」(開始)および「終了」(範囲の終了)にアドレスを入力することによって、範囲を定義します。指定する各IPアドレスは、明示的で有効なアドレス(形式nnn.nnn.nnn.nnn)である必要があります。たとえば、192.2.2.2のように指定します。「終了」フィールドには、「開始」フィールドよりも値の大きいアドレスを指定する必要があります。認可中、Access Managerによって、クライアントのIPアドレスが「開始」(開始)および「終了」(範囲の終了)に指定したアドレスの範囲に含まれているかどうかが確認されます。複数の重複する範囲が指定され、クライアントのIPアドレスがその範囲の1つにでも含まれている場合、条件によってtrueと評価され、その条件に設定された条件に基づいてアクセスが許可(または拒否)されます。
複数の重複する範囲が指定され、クライアントのIPアドレスがそのいずれかの範囲に含まれている場合は、条件によってtrueと評価され、その条件に基づいてアクセスが許可(または拒否)されます。
ノート:
「開始」のIPアドレスが「終了」のアドレスよりも大きい場合、条件はどのクライアントのIPアドレスにも一致しません。
図25-23は、開始および終了が指定されたサンプルIP4範囲を含むIP4範囲条件の表を示しています。無効な値を指定すると、そのことが通知され、値は保存できません。
一時的条件タイプを使用する場合、管理者は、開始時間、終了時間および曜日を追加する必要があります。他の条件のように、アイデンティティ条件およびIP4範囲条件と組み合せてこれを使用できます。
図25-24では何も選択されていませんが、デフォルトですべての曜日が有効です。
グリニッジ標準時(GMT)の24時間制に基づくHH:MM:SS(時間、分、秒)形式で期間を指定する必要があります。深夜は00:00:00(開始)に指定します。24:59:59で1日が終了します。
表25-16 一時的条件の詳細
| 要素 | 説明 |
|---|---|
開始時間 ノート: 完全な24時間の範囲で時間を指定します。たとえば、深夜を00:00:00に指定して、午後11時を23:00:00に指定します。 |
この条件が開始する時間、分および秒を指定します。 ノート: 時間はグリニッジ標準時(GMT)に基づいています。GMTは、夏時間またはサマー・タイムの調整がなく1年中同じです。 |
終了時間 |
この条件が終了する時間、分および秒を指定します。 |
日 |
このポリシーがアクティブな日を指定します。 デフォルト: すべての日(すべての曜日が未選択の場合を含む) |
このページを閉じる前に、詳細を保存します。
関連項目:
この項では次のトピックを記載しています:
属性タイプ条件では、アプリケーション・ドメイン内のすべてのリソース・タイプおよび認可ポリシーに関連する許可または拒否アクセスのリクエスト・コンテキスト、ユーザー・セッションの状態およびユーザー属性が評価されます。
属性タイプ条件を定義すると、アクセスは次の項目によってスコープ指定される、名前と値のペアのリストに基づきます。
リクエスト・コンテキスト: リクエストしたリソース、リクエストを実行したクライアントおよび評価中に一致したポリシーの情報。
セッション: ユーザーがセッションを確立したときのユーザー・セッションの詳細(事前定義済のセッション属性または任意のセッション属性の参照)。
ユーザー: ユーザー属性の情報(LDAP属性の参照)。この条件は、ユーザーの任意のLDAP属性の参照に対する条件を定義する場合のみ使用されます。ただし、userIDまたはgroupIDに基づく条件は、アイデンティティ条件を使用して定義されます。
アクセスが表25-17で説明されているいずれかの状況に基づく場合は、属性タイプ条件が必要です。
表25-17 属性タイプ条件を必要とするアクセス条件
| アクセスが基づく内容 | 説明 |
|---|---|
セッション属性 |
ユーザーにリソースへのアクセスが認可されるのは、セッション属性「認証レベル」がxx、セッション属性s1がv1およびセッションの開始時間がxxxxである場合です。 関連項目: 表25-20 |
リクエストされたリソース |
ホスト名およびポート番号 関連項目: 表25-19 |
ユーザーの詳細 |
ユーザーにリソースへのアクセスが認可されるのは、そのリソースのEmpnoがxxxxである(department=salesなど)場合です。 関連項目: 表25-21 |
セッション属性に基づくトークン発行 |
リクエスタ・パートナでは、要求に含まれる属性SessionActiveTimeが15000である場合、リライイング・パーティにトークンを発行できます。 トークン発行ポリシーの要求ベースの条件は、セッション・データを使用して作成されたアサーションに基づいて定義します。 |
属性タイプ条件を定義する管理者は、組込み属性および既知の属性のフィールドにデータを入力します。属性名は、テキスト・フィールドに入力するか、値のリストから選択できます。実行する条件は、その条件にANDまたはOR接続詞を使用して構築されます。図25-25は、属性条件のページを示しています。
図25-26は、「属性条件の追加」ダイアログ・ボックスを示しています。各属性条件は、表25-18で説明されているフィールドによって定義されます。
関連項目:
表25-18 属性条件の要素
| 条件 | 説明 |
|---|---|
ネームスペース |
サポートされるネームスペース:
|
名前 |
属性名。次の内容に従って追加できます。 |
演算子 |
使用可能な演算子:
|
値 |
特殊なワイルドカード文字を含まないリテラル値。 |
組込みリクエスト
表25-19は、組込みリクエストの組込み属性名のリストを示しています。
表25-19 組込みリクエストの属性名
| 属性名 | 説明 |
|---|---|
agent_id |
リクエストしているエージェントの名前。 |
client_ip |
ユーザー・ブラウザのIPアドレス。 |
Policy_appdomain |
リクエストに一致するポリシーを保持するアプリケーション・ドメインの名前。 |
Policy_res |
リクエストに一致するリソース・ホストIDおよびURLパターン。 |
policy_name |
リクエストに一致する特定のポリシーの名前。 |
res_host |
リクエストしたリソースのホスト名。 |
res_port |
リクエストしたリソースのポート番号。 |
res_type |
リクエストしたリソースのタイプ。 |
res_url |
リクエストしたリソースURL。 |
組込みセッション
表25-20は、セッション・ベースの属性タイプ条件の属性名のリストを示しています。
表25-20 組込みセッションの属性名
| 属性名 | 説明 |
|---|---|
認証レベル |
セッションの現在の認証レベル。 |
認証スキーム |
現在の認証レベルを実現するために実行される認証スキームの名前。 |
セッション・カウント |
セッションにバインドされたユーザーのセッション数。 |
セッション作成時間 |
セッションの作成時間。 |
セッション有効期限時間 |
セッションの有効期間。 |
例: 属性条件のデータ(条件の集約)
表25-21は、許容できる各ネームスペースのサンプル条件データを示しています。
表25-21 属性条件のデータ(条件の集約)
| ネームスペース | 名前 | 演算子 | 値 |
|---|---|---|---|
組込みリクエスト |
Res_host |
次と等しい |
7777 |
組込みセッション |
Authn_level |
次と等しい |
2 |
セッション |
Sessionattr1 |
次を含む |
Foo |
ユーザー |
department |
次と等しい |
sales |
