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

前
前へ
次
次へ

19 アカウントの管理

この章では、コンテンツ・サーバーで定義および管理されるコンテンツ・サーバー・アカウントについての情報を提供します。アカウントの権限はOracle WebLogic Server管理コンソールを使用してユーザー・ログインに割り当てられます。

この章の内容は次のとおりです。

19.1 コンテンツ・サーバー・アカウントの概要

アカウントを使用すると、セキュリティ・グループのみの場合よりも、セキュリティ構造の柔軟性と精度が向上します。アカウントとアカウントの権限は、Oracle WebLogic Server管理コンソールを使用してユーザーに割り当てられ、グループはサーバーによりコンテンツ・サーバーのロールおよびアカウントにマップされます。アカウントは各コンテンツ・アイテムにも割り当てることができます。アカウントが割り当てられたコンテンツ・アイテムにアクセスするには、そのアカウントに対する適切な権限を持っている必要があります。

@(アット)記号で始まるOracle WebLogic Serverユーザー・グループはコンテンツ・サーバー・アカウントにマップされます。

注意:

アカウントを有効化して使用し、その後アカウントを無効化すると、データを損失する場合があります。リポジトリは変更されません。ただし、セキュリティ・モデルに特定の変更を行う場合、セキュア・コンテンツへのアクセスを継続できるように、ユーザーのアクセス権を更新する必要もあります。

この状況を避けるため、要件と、グループおよびアカウントのWebCenter Contentセキュリティ・モデルについて調査して、要件に最適なのは何かを判断します。確実に使用する必要がある場合以外は、アカウントを有効化しないでください。

アカウントは、いくつかの方法で作成できます。

注意:

アカウント名にストップワードを使用することはお薦めできません。ストップワードとは、他のキーワードと組み合せて使用したときに、検索問合せの中で検索エンジンが除外または無視する語のことです。アカウント名での検索がOracleTextSearchコンポーネントを使用して実行された場合、問合せにストップワードが含まれていると、返された検索結果に悪影響がおよぶ場合があります。ストップワードの使用の詳細またはストップワードを削除する手順については、『Oracle Textリファレンス11g』ドキュメントを参照してください。

使用するアカウントを有効化する必要があります。詳細は、「コンテンツ・サーバーのアカウントの有効化」を参照してください。

19.1.1 アカウントおよびセキュリティ・グループ

アカウントを使用する場合、アカウントが、セキュリティ・グループ権限より優先されるプライマリ権限になります。特定のドキュメントへのユーザーのアクセスを、アカウント権限とセキュリティ・グループ権限の共通部分と考えることもできます。

たとえば、EngAdminロールには、EngDocsセキュリティ・グループ内のすべてのコンテンツに対する読取り、書込み、削除および管理権限があるとします。ユーザーはEngAdminロールに割り当てられ、AcmeProjectアカウントに対する読取りおよび書込み権限も割り当てられます。その結果、ユーザーは、EngDocsセキュリティ・グループとAcmeProjectアカウント内のコンテンツ・アイテムに対する読取りおよび書込み権限のみを持ちます。

図19-1に、AcmeProjectアカウント権限とEngDocsセキュリティ・グループ権限の共通部分を示します。

図19-1 セキュリティ・グループ権限の例

図19-1の説明が続きます
「図19-1 セキュリティ・グループ権限の例」の説明

アカウントで任意のコンテンツへのアクセスが許可されていない場合、セキュリティ・グループ権限は無視されます。アカウントは、ユーザーのロールによって定義された権限より優先されるフィルタとして機能します。

19.1.2 階層アカウント

アカウントは階層構造に設定することができ、これにより、一部のユーザーには構造のブランチ全体に対するアクセス権を付与する一方で、構造の下位レベルのアカウントを割り当てることによりその他のユーザーの権限を制限できます。図19-2に、典型的な階層アカウント構造を示します。

図19-2 階層アカウント構造の例

図19-2の説明が続きます
「図19-2 階層アカウント構造の例」の説明

重要

アカウント名は、コンテンツ・アイテムのURLのディレクトリ・パスの一部を形成するため、30文字を超えることはできません。

  • アカウント名のレベルを区切るためにスラッシュを使用すると(Eng/Acme/Budgetなど)、コンテンツ・サーバーによりアカウント構造に応じてWebレイアウト・ディレクトリ構造が作成されます(ただし、実際の各ディレクトリは、チェックイン・プロセス中にコンテンツ・アイテムがアカウントに割り当てられるまで作成されません)。アカウント名の各下位レベルは、そのディレクトリがアカウント・レベルであることを示す@記号接頭辞付きの上位レベルのサブディレクトリになります。

    重要

    組込みLDAPサーバーを使用している場合は、スラッシュを使用しないでください。Oracle WebLogic Server Consoleを使用している場合、バックスラッシュ(/)およびスラッシュ(\)はセキュリティ・グループにはお薦めできません。

  • ユーザーが特定の接頭辞のアカウントに対する権限を持っている場合、その接頭辞の付くすべてのアカウントへのアクセス権があります。たとえば、Eng/XYZアカウントにを割り当てられている場合、Eng/XYZアカウントおよびEng/XYZ接頭辞で始まる任意のアカウント(Eng/XYZ/Schedule、Eng/XYZ/Budgetなど)へのアクセス権があります。

    重要

    アカウント接頭辞にスラッシュを含める必要はありません。たとえば、abc、abc_docs、abcdefgというアカウントがある場合、abcアカウントへのアクセス権を持つすべてのユーザーには、その他2つのアカウントに対するアクセス権もあります。

前述のセキュリティ構造に対応するには、次のアカウントを作成します。

  • Eng

  • Eng/Acme

  • Eng/XYZ

  • Eng/Acme/Schedule

  • Eng/Acme/Budget

  • Eng/XYZ/Schedule

  • Eng/XYZ/Budget

図19-3 セキュリティ・ファイル構造の例

図19-3の説明が続きます
「図19-3 セキュリティ・ファイル構造の例」の説明

19.1.3 パフォーマンスに関する考慮事項

セキュリティ・モデルでアカウントを使用するときには次の作業効率の問題を考慮してください。

  • 理論上、コンテンツ・サーバーのパフォーマンスに影響を与えずに無制限にアカウントを作成できます。100,000を超えるコンテンツが存在するシステムでは、1人当たり200アカウントの場合に管理効率上の限られた問題があります。ただし、1人当たり100を超えるアカウントがあると、検索効率に重大な影響があります(これは明示的なアカウントであり、階層アカウント接頭辞を介して暗黙的にユーザーに関連付けられたアカウントではありません。ユーザーは単一の接頭辞を介して多数の暗黙的アカウントに対する権限を持つことができます)。

  • アカウントを有効化する場合は、作業効率上の理由から、使用するセキュリティ・グループが50を超えないようにしてください。

  • セキュリティ・グループおよびアカウントには、比較的短い名前を付けるようにしてください。

19.1.4 外部ディレクトリ・サーバーの考慮事項

アカウントはコンテンツ・サーバー・インスタンスが外部ディレクトリ・サーバー(デフォルトのOracle WebLogic Serverなど)と統合されているかどうかに関係なく使用できます。外部ディレクトリを使用するアカウントを使用する場合は、次のガイドラインに従ってください。

  • 適切なユーザーを含むグローバル・グループをアカウントに一致するように設定します。

  • マッピング接頭辞を構成して、グループ名をロールまたはアカウントに関連付けます。

19.2 コンテンツ・サーバー・アカウントの管理

次のタスクがアカウントの管理に含まれます。

19.2.1 コンテンツ・サーバーでのアカウントの有効化

コンテンツ・サーバー・インスタンスでアカウントを有効化する手順は、次のとおりです。

重要

アカウントを有効化して使用し、その後アカウントを無効化すると、データを損失する場合があります。リポジトリは変更されません。ただし、セキュリティ・モデルに特定の変更を行う場合、コンテンツへのアクセスを継続できるように、ユーザーのセキュリティの設定を更新する必要もあります。

  1. コンテンツ・サーバー・ポータルで、「管理」「管理サーバー」「一般構成」を選択します。
  2. 「一般構成」ページで、「アカウントの有効化」を選択します。
  3. 変更を保存します。
  4. Content Serverインスタンスを再起動します。

または、「一般構成」ページにアクセスし、DomainHome/ucm/cs/config/config.cfgファイルのコンテンツを示す、「追加の構成変数」フィールドに次の行を追加します。

UseAccounts=true

変更を保存して、コンテンツ・サーバー・インスタンスを再起動します。

19.2.2 コンテンツ・サーバーでの定義済アカウントの作成

コンテンツ・サーバー・インスタンスで定義済アカウントを作成するには、次の手順を実行します。

  1. 「ユーザー管理」ページから、「セキュリティ」「定義済アカウント」の順に選択します。
  2. 「定義済アカウント」ウィンドウで、「追加」をクリックします。
  3. 「新しい定義済アカウントの追加」ウィンドウで、新規アカウントの名前を追加します。名前は簡潔で一貫性のあるものにします。たとえば、場所や部門による3文字の略語(MSP、NYCなど)を使用してすべてのアカウントを設定します。アカウント名は30以内にする必要があり、空白、タブ、行送り、改行および; ^ ? : & + " # % < > * ~の記号は使用できません。
  4. 「OK」をクリックします。
  5. すでにコンテンツ・サーバー・リポジトリにコンテンツがチェックインされていて、フルテキスト索引付けのデータベースを使用している場合は、検索索引を再作成します。

    メタデータ・データベースの検索インデクサ・エンジンのみを使用している場合は、検索索引を再作成する必要はありません。

19.2.3 コンテンツ・サーバーでのコンテンツのチェックイン時のアカウントの作成

一般的に、コンテンツのチェックイン時にアカウントを作成するのではなく、事前定義済アカウントを作成する必要があります。事前定義済アカウントの詳細は、「コンテンツ・サーバーでの定義済アカウントの作成」を参照してください。

コンテンツ・アイテムのチェックイン時にアカウントを作成するには、ユーザー管理権限が必要で、次の手順を実行する必要があります。

  1. 「コンテンツ・チェックイン・フォーム」ページを表示します。
  2. 必須およびオプションの情報をすべて入力します。
  3. 「アカウント」フィールドにアカウント名を入力します。
  4. 「チェックイン」をクリックします。コンテンツ・アイテムに新規アカウントが割り当てられます。

注意:

アカウントに対する書込み(W)権限がある場合、コンテンツ・アイテムにチェックインしている間に、このアカウントを接頭辞として使用して別のアカウントを作成できます。たとえば、brアカウントへの書込み権限がある場合、brownアカウントを作成し、チェックイン中にコンテンツ・アイテムと関連付けることができます。

19.2.4 コンテンツ・サーバーでの定義済アカウントの削除

アカウントを含むコンテンツが存在する場合にもアカウントを削除できます。アカウント値はコンテンツ・アイテムに割り当てられたままですが、ユーザー定義のアカウントとみなされるようになります。

重要

コンテンツ・サーバー・リポジトリに格納されたコンテンツ・アイテムと関連付けられているアカウントは、絶対に削除しないでください。

コンテンツ・サーバー・インスタンスで定義済アカウントを削除するには、次の手順を実行します。

  1. 「ユーザー管理」ページから、「セキュリティ」「定義済アカウント」の順に選択します。
  2. 「定義済アカウント」ウィンドウで、削除するアカウントを選択します。
  3. 「削除」をクリックします。アカウントが即時に削除されます。

19.2.5 Oracle WebLogic Serverでのユーザーへのアカウントの割当て

アカウントをユーザーに割り当てるには、Oracle WebLogic Server管理コンソールを使用してグループを作成し、それを1つまたは複数のユーザーに割り当てます。グループ名は@記号で始まり、アンダースコアで区切られた権限で終わる必要があります。次の例は、testaccountという名前のグループを作成し、それに読取り、書込みおよび削除権限を割り当てたものです(@testaccount_RWD)。JpsUserProviderを変更して、「アカウント権限のデリミタ」フィールドにアンダースコアが使用されていることを確認する必要もあります。JpsUserProviderの詳細は、「JpsUserプロバイダの使用が必要な状況」を参照してください。

Oracle WebLogic Server上のユーザーに割り当てられたアカウントはコンテンツ・サーバー・インスタンスにマップされます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザーの作成に関する項を参照してください。

19.3 コンテンツ・サーバー・アカウントの事例

この例において、Xalcoはロンドン、ニューヨーク、パリに支社のある世界的なソフトウェア企業です。コンテンツ・サーバー・インスタンスはロンドン支社にホストされていて、企業WAN経由で他のオフィスからアクセスされています。また、XalcoはパブリックWebサイトにの一部のファイルをレプリケートしています。まず、各地の営業部および経理部で、ファイルを公開するためにそのインスタンスを使用する必要があります。ニューヨーク支社は小規模で、営業部がありません。

次の各項では、Xalcoの事例に関するサンプル情報を示します。

19.3.1 Xalcoのセキュリティ

  • Xalcoの従業員およびセキュリティ・レベル:

    • ロンドン: David Smith(全社CFO)、Jim McGuire(イギリス営業部長)

    • ニューヨーク: Catherine Godfrey(地域経理部長)

    • パリ: Helene Chirac(ヨーロッパ財務係)

  • Xalco社のコンテンツのセキュリティ検査(セキュリティ・グループ)のレベル:

    • パブリック: パブリックのメンバーに公開できるファイル(パブリック・コンテンツはXalco Webサイトにレプリケートされます)

    • 内部: 社内ではアクセスの制限はないが、パブリックには公開できないファイル

    • 機密: 業務上機密が要求され、中間管理職以上に制限されているファイル

    • 極秘: 機密性が高く、役員にのみ公開されるファイル

  • Xalco社の従業員のアクセス権:

    • David Smith: 全社CFOとして、インスタンスに保持されているすべてのファイルへのフル・アクセス権が必要です。

    • Jim McGuire: イギリスの営業部長として、ロンドンの営業ファイルへのフル・コントロールのアクセス権を持ち、パリの営業活動を把握できる必要があります。部長として、機密レベルへの許可があります。

    • Helene Chirac: パリ支社を本拠地としていて、ヨーロッパの経理に関するファイルのみを参照する必要があり、内部レベルの許可のみがあります。

    • Catherine Godfrey: ニューヨークを本拠地としちていて、地域経理部長として、ニューヨークの経理ファイルの登校、およびその他のすべての経理ドキュメントの参照を実行できる必要があります。部長として、機密レベルへの許可があります。

19.3.2 Xalcoのアカウント

アクセス権は場所や職務により異なるため、アカウント構造に反映されています。

  • ロンドンには経理部および営業部があるため、次の2つのアカウントが必要です。

    • London/Finance

    • London/Sales

  • ニューヨークには経理部のみがあります。

    • NewYork/Finance

  • パリには経理および営業部の両方があります。

    • Paris/Finance

    • Paris/Sales

このため、最上位レベルのアカウントは3つ(London、NewYork、Paris)で、下位レベルのアカウントは5つになります。

19.3.3 Xalcoのロール

各セキュリティ・グループに2つのロール(1つはコンシューマ用、もう1つはコントリビュータ用)を作成する必要があります。

  • PublicConsumer

  • PublicContributor

  • InternalConsumer

  • InternalContributor

  • SensitiveConsumer

  • SensitiveContributor

  • ClassifiedConsumer

  • ClassifiedContributor

19.3.4 ロールおよび権限の表

特定のユーザーにワークフローを開始する機能を付与するには、コントリビュータ・ロールに管理権限とワークフロー権限を追加する必要があります。

ロール パブリック 内部 機密 極秘

PublicConsumer

R

PublicContributor

RWD

InternalConsumer

R

InternalContributor

RWD

SensitiveConsumer

R

SensitiveContributor

RWD

ClassifiedConsumer

R

ClassifiedContributor

RWD

19.3.5 ロールおよびユーザーの表

ロール David Smith Helene Chirac Jim McGuire Catherine Godfrey

PublicConsumer

X

PublicContributor

X

X

X

InternalConsumer

X

InternalContributor

X

X

X

SensitiveConsumer

SensitiveContributor

X

X

X

ClassifiedConsumer

ClassifiedContributor

X

X

X

19.3.6 アカウントおよびユーザーの表

David Smithにはロンドン、ニューヨークおよびパリのアカウントのRWDA権限を付与する必要があります。

アカウント David Smith Helene Chirac Jim McGuire Catherine Godfrey

London/Finance

RWDA

R

R

London/Sales

RWDA

RWDA

NewYork/Finance

RWDA

RW

Paris/Finance

RWDA

R

Paris/Sales

RWDA

R