プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle WebCenter Contentの管理
12c (12.2.1.2.0)
E82742-01
目次へ移動
目次

前
前へ
次
次へ

20 アクセス制御リストのセキュリティの管理

この章では、コンテンツ・アイテムに対するアクセス権限または操作権限が指定された、ユーザー、グループまたはエンタープライズ・ロールのリストである、コンテンツ・サーバーのアクセス制御リスト(ACL)の情報を提供します。

この章の構成は、次のとおりです。

20.1 アクセス制御リストのセキュリティの概要

コンテンツ・サーバー・システムは、標準のコンテンツ・サーバー・セキュリティ・ロール、セキュリティ・グループおよびアカウントの他に、アクセス制御リスト(ACL)をサポートするように構成できます。アクセス制御リストは、ユーザー、グループまたはエンタープライズ・ロールのリストであり、コンテンツ・アイテムに対するアクセス権限または操作権限が指定されています。

アクセス制御リスト・セキュリティの構成時に、コンテンツ・アイテムのチェックイン、更新または検索などのインタフェースのいくつかの場所で、次の3つの新規フィールドを使用できます。フィールドは次のとおりです。

  • ユーザー・アクセス・リスト

  • グループ・アクセス・リスト

  • ロール・アクセス・リスト

アクセス制御リストのセキュリティ機能がコンテンツ・サーバーに構成されると、Oracle WebLogic Serverドメインとともに動作する、Oracle Access Manager (OAM) Authenticationプロバイダを含む、Oracle Platform Security Services (OPSS)を使用してアクセス制御リストを管理できます。『Oracle Platform Security Servicesによるアプリケーションの保護』のOracle Platform Security Servicesの概要に関する項を参照してください。

注意:

Oracle WebLogic Server管理コンソールを介してユーザー・アクセスを認証および管理するために、Oracle Content ServerインスタンスでOracle Platform Security Services (OPSS)を使用している場合、OpssPolicyStoreコンポーネントは、有効になった後は無効にしないでください。OPSSベースのポリシー・ストアからOracle WebCenter Contentのスキーマ・ベースのポリシー・ストアに戻ることはサポートされません。

コンテンツ・サーバーのアクセス制御リストはOracle Secure Enterprise Searchでサポートされ、ユーザーはアクセス制御リストの情報を使用して検索を実行できます。詳細は、「Oracle Secure Enterprise Search」を参照してください。

注意:

RoleEntityACLコンポーネントをOracle WebCenter Content: Recordsとともに使用している場合、このコンポーネントは、カテゴリやレコード・フォルダなどの保存オブジェクトには影響しません。したがって、RecordsロールでACLを使用する機能は、RoleEntityACLコンポーネントが有効であっても、カテゴリ作成ページまたはフォルダ作成ページでは無効化されています。ただし、ロールACL機能は、コンテンツのチェックイン・ページでは有効になっています。

注意:

NeedtoKnow (NtkDocDisclosure、NTK)コンポーネントはコンテンツ・サーバー・セキュリティのカスタマイズをサポートしますが、セキュリティ・モデルと競合するため、アクセス制御リストとともには動作できません。詳細は、「Need to Knowコンポーネントの管理」を参照してください。

20.2 アクセス制御リストのセキュリティの構成

アクセス制御リスト(ACL)を設定するには、次に示すコンテンツ・サーバーのアイテムを構成します。

  • ユーザーおよびグループのアクセス制御リストをサポートするには、次の構成変数がコンテンツ・サーバーのconfig.cfgファイルで設定されている必要があります。

    • UseEntitySecurity: この変数をtrueに設定します。

    • SpecialAuthGroups: この変数は、ACLセキュリティを使用するコンテンツ・サーバー・セキュリティ・グループの名前に設定します。初期状態のコンテンツ・サーバーのセキュリティ・グループは、「Public」と「Secure」の2つのみです。通常、サイトでは、ACLセキュリティが適用される3番目のセキュリティ・グループが作成されます。

      注意:

      デフォルトで、セキュリティ・グループはSpecialAuthGroupsリストに追加されません。

    変数を設定するには、次のようにします。

    1. Content Serverインスタンス用の管理インタフェースを使用して、「一般構成」ページを選択します。

    2. このページで、「追加の構成変数」フィールドに変数を入力します。

    3. 「更新」をクリックします。

    構成変数UseEntitySecurity=trueは、コンテンツ・サーバーのセキュリティを、ユーザーおよびグループのアクセス制御リストのコンテンツ・アイテムを常に評価するように設定します。このパラメータは2つのメタデータ・フィールド、xClbraUserListおよびxClbraAliasListを作成します。

  • エンタープライズ・ロールのアクセス制御リストをサポートするには、RoleEntityACLコンポーネントがコンテンツ・サーバーで有効にされる必要があります。このコンポーネントはデフォルトでコンテンツ・サーバーにインストールされ、無効化されています。コンポーネントを有効にするには、次のようにします。

    1. Content Serverインスタンス用の管理インタフェースを使用して、コンポーネント管理ページを選択します。

    2. このページの説明の段落で「拡張コンポーネント・マネージャ」をクリックします。

    3. 「無効なコンポーネント」リストでコンポーネントRoleEntityACLを選択してから、「有効化」をクリックします。

    4. Content Serverインスタンスを再起動します。

    注意:

    ロール名は30文字未満であるか、先頭から30文字までは一意であることが必要です。既存の外部ロール名が30文字を超える場合は、資格証明マップを使用してロール名を短い名前にマップします。

    資格証明マップの詳細は、「資格証明マッピング」を参照してください。

    RoleEntityACLコンポーネントは、コンテンツ・サーバーを、別のアプリケーションと連携してエンタープライズ・ロールのアクセス制御リストを評価するように構成します。このコンポーネントはUseRoleSecurityパラメータをオンにして、コンテンツ・サーバー・セキュリティが、コンテンツ・アイテムに対するエンタープライズ・ロールのアクセス・リストの情報を統合するように設定します。UseRoleSecurityパラメータはxClbraRoleListメタデータ・フィールドを作成します。

    ACLのロールを定義する利点は、ユーザー・ロールがエンタープライズ・セキュリティ・ディレクトリ(OID、Active Directoryなど)から来ることであり、そのため、WebCenter Content管理者はACLグループで行うようにそれらを定義する必要がありません。詳細は、ブログ記事「ロールのアクセス制御リストについて」を参照してください。

  • コンテンツ・アイテムのチェックイン時に、管理者ではないユーザーに「ユーザーの追加」メニューを使用して「ユーザー・アクセス・リスト」でユーザーを選択できるようにする場合は、構成変数AllowQuerySafeUserColumns=trueを設定します。この変数が設定されていないと、「ユーザー・アクセス・リスト」フィールドのメニューに値が表示されません。

20.3 メタデータ・フィールド

アクセス制御リストは3つのメタデータ・フィールド、xClbraUserList、xClbraAliasListおよびxClbraRoleListの値に基づき処理されます。メタデータ値がユーザー、グループまたはエンタープライズ・ロール名およびコンテンツ・アイテムへの権限により移入される場合、コンテンツ・アイテムでの検索または動作がどのユーザー、グループまたはエンタープライズ・ロールに許可されるのかに影響します。

これらのメタデータ・フィールドはユーザー・アクセス・リスト、グループ・アクセス・リストおよびロール・アクセス・リスト・フィールドから移入され、コンテンツ・アイテムのチェックイン、更新、および拡張フォームを使用した検索の実行時に、表示またはアクセスできます。

管理者はスクリプトを使用して、アクセス・リストのメタデータ・フィールドに移入する値を指定できます。

20.3.1 xClbraUserListメタデータ・フィールド

xClbraUserListメタデータ・フィールドを使用して、コンテンツ・アイテムに対するユーザーとその権限を指定します。

次のリストでは、管理者がスクリプトにxClbraUserList値を指定する要件について説明します。

  • 各ユーザー名の前にアンド記号(&)が付きます。

  • ユーザー名の後に各ユーザーの権限がカッコで囲われて続きます。

  • ユーザー名はカンマで区切られます。

  • 例: xClbraUserList=&sysadmin(RWDA),&user1(RW),&guest(R)

20.3.2 xClbraAliasListメタデータ・フィールド

xClbraAliasListメタデータ・フィールドを使用して、コンテンツ・アイテムに対するグループとその権限を指定します。

注意:

コンテンツ・サーバーでは、エイリアスを使用してユーザーのグループ(LDAPグループとは異なる)を指定できます。ACLでは、エイリアス・アクセス・リストの実装を呼び出す代わりに、グループ・アクセス・リストが呼び出されます。ただし、メタデータ・フィールド名はエイリアスという用語を使用します。

次のリストでは、管理者がスクリプトにxClbraAliasList値を指定する要件について説明します。

  • 各グループ名の前にはアット記号(@)が付きます。

  • グループ名の後に各グループの権限がカッコで囲われて続きます。

  • グループ名はカンマで区切られます。

  • 例: xClbraAliasList=@Mktg(RWDA),@Mktg_ext(RW)

20.3.3 xClbraRoleListメタデータ・フィールド

xClbraRoleListメタデータ・フィールドを使用して、コンテンツ・アイテムに対するエンタープライズ・ロールとその権限を指定します。

次のリストでは、管理者がスクリプトにxClbraRoleList値を指定する要件について説明します。

  • 各ロール名の前にはコロン記号(:)が付きます。

  • ロール名の後に各ロールの権限がカッコで囲われて続きます。

  • ロール名はカンマで区切られます。

  • 例: xClbraRoleList=:role1(RWDA),:role2(RW)

20.4 アクセス制御リストの権限

アクセス制御リストの権限により、ユーザー、グループ、またはエンタープライズ・ロールのコンテンツ・アイテムに対するアクセス権のタイプが決まります。次の権限を付与できます。

権限 説明

読取り(R)

コンテンツ・アイテムを表示できます。

書込み(W)

コンテンツ・アイテムを表示、チェックイン、チェックアウト、更新およびコピーできます。

削除(D)

コンテンツ・アイテムを表示、チェックイン、チェックアウト、更新、コピーおよび削除できます。

管理者(A)

コンテンツ・アイテムを表示、チェックイン、チェックアウト、更新、コピーおよび削除でき、「作成者」の指定とは別のユーザーでコンテンツ・アイテムをチェックインできます。

注意:

アクセス制御リストの権限はコンテンツ・サーバーのadminロールのユーザーには適用されません。

ただし、ユーザーがOracle WebCenter Contentのadminロールを持っている場合、またはユーザー管理権限がコンテンツ・アイテムのセキュリティ・グループに付与されている場合、ユーザーはACLに含まれていなくてもコンテンツにアクセスできます。

アクセス制御リストをコンテンツ・アイテムと関連付けるには、コンテンツ・アイテムのチェックインまたは更新時に、1つまたは複数のユーザー、グループまたはエンタープライズ・ロールを追加します。アクセス・リストに追加する各ユーザー、グループまたはロールに対し、適切な権限である読取り(R)、書込み(W)、削除(D)または管理(A)を割り当てます。アクセス制御リストの権限レベルは、コンテンツ・サーバーのセキュリティ・グループおよびアカウントに対して定義されたものと同じです。ユーザーがいずれかのアクセス・リストに追加されると、そのユーザーはコンテンツ・アイテムへアクセスする指定した権限を持ちます。

特定の権限が付与されたユーザーに対し、すくなくとも次のいずれかが当てはまる必要があります。

  • ユーザー名がxClbraUserListメタデータ・フィールドに適切な権限とともに表示されている。

  • ユーザーがxClbraAliasListメタデータ・フィールドに適切な権限とともに表示されているグループに属している。

  • ユーザーがxClbraRoleListメタデータ・フィールドに適切な権限とともに表示されているエンタープライズ・ロールの一部である。

アクセス制御リストの権限は累積です。書込みを割り当てると、自動的に読取りが割り当てられます。管理者を割り当てると、読取り、書込みおよび削除が自動的に割り当てられます。

ただし、ユーザーはコンテンツ・サーバーのセキュリティ・グループおよびアカウント(アカウントが有効な場合)経由でのアクセスのセキュリティ基準も満たしている必要があります。これらのセキュリティ基準が特定の権限を拒否する場合、ユーザーはコンテンツ・アイテムへの権限を持たなくなります。

ユーザーがコンテンツ・アイテムを検索する場合は、3つのACL権限フィールドすべてがOR条件で結合されます。結果は、AND条件により、「セキュリティ・グループ」および「アカウント」フィールドの結果と結合されます。検索を実行するユーザーは、コンテンツ・アイテムを検索するためには、セキュリティ・グループ、アカウント(アカウントが有効にされている場合)、および3つのACLフィールドのうち少なくとも1つに対する読取り権限を保持している必要があります。

20.4.1 空のアクセス制御リスト・フィールド

すべてのユーザー・アクセス・リスト、グループ・アクセス・リストおよびロール・アクセス・リスト・フィールドが空の場合、デフォルトで権限がすべてのユーザーに付与されます。ユーザー・アクセス・リストおよびグループ・アクセス・リスト・フィールドだけが空白の場合(およびRoleEntityACLコンポーネントが有効化されていないためにロール・アクセス・リストが存在しない場合)、権限がすべてのユーザーに付与されます。この動作は、デフォルトでTRUEに設定される、AccessListPrivilegesGrantedWhenEmpty変数により構成されます。

AccessListPrivilegesGrantedWhenEmpty変数がFALSEに設定されている場合、すべてのアクセス制御リストが空白だと、権限はadminロールを除くすべてのユーザーに対して拒否されます。adminロールを付与されていないユーザーがドキュメントをチェックインできるようにするには、読取り/書込み(RW)権限を含むアクセス制御リストのロール(testroleなど)がユーザーに付与されており、ドキュメントのチェックイン時にこのロールを指定する必要があります。

注意:

コンテンツ・サーバー・インスタンスがリリース10gからアップグレードされた場合、空のアクセス制御リストは、リリース11gでは異なった動作をすることに注意してください。リリース10gおよびそれ以前では、AccessListPrivilegesGrantedWhenEmpty=falseの構成と同等です。リリース11gのデフォルトは、AccessListPrivilegesGrantedWhenEmpty=trueです。