| Oracle® Fusion Middleware Oracle WebCenter Contentの管理 11g リリース1 (11.1.1) B72425-03 |
|
 前 |
 次 |
この章では、コンテンツ・サーバーで定義および管理されるコンテンツ・サーバー・アカウントについての情報を提供します。アカウントの権限はOracle WebLogic Server管理コンソールを使用してユーザー・ログインに割り当てられます。
この章の内容は次のとおりです。
アカウントを使用すると、セキュリティ・グループのみの場合よりも、セキュリティ構造の柔軟性と精度が向上します。アカウントとアカウントの権限は、Oracle WebLogic Server管理コンソールを使用してユーザーに割り当てられ、グループはサーバーによりコンテンツ・サーバーのロールおよびアカウントにマップされます。アカウントは各コンテンツ・アイテムにも割り当てられます。アカウントが割り当てられたコンテンツ・アイテムにアクセスするには、そのアカウントに対する適切な権限を持っている必要があります。
@(アット)記号で始まるOracle WebLogic Serverユーザー・グループはコンテンツ・サーバー・アカウントにマップされます。
|
注意: アカウントを有効化して使用し、その後アカウントを無効化すると、データを損失する場合があります。リポジトリは変更されません。ただし、セキュリティ・モデルに特定の変更を行う場合、セキュア・コンテンツへのアクセスを継続できるように、ユーザーのアクセス権を更新する必要もあります。 この状況を避けるため、要件と、グループおよびアカウントのWebCenter Contentセキュリティ・モデルについて調査して、要件に最適なのは何かを判断します。確実に使用する必要がある場合以外は、アカウントを有効化しないでください。 |
アカウントは、いくつかの方法で作成できます。
コンテンツ・サーバー管理者による、ユーザー管理ツールを使用した事前定義済アカウントの作成。詳細は、第19.2.2項を参照してください。
ユーザー管理者による、コンテンツのチェックイン時におけるアカウントの作成。詳細は、第19.2.3項を参照してください。
使用するアカウントを有効化する必要があります。詳細は、第19.2.1項を参照してください。
アカウントを使用する場合、アカウントが、セキュリティ・グループ権限より優先されるプライマリ権限になります。特定のドキュメントへのユーザーのアクセスを、アカウント権限とセキュリティ・グループ権限の共通部分と考えることもできます。
たとえば、EngAdminロールには、EngDocsセキュリティ・グループ内のすべてのコンテンツに対する読取り、書込み、削除および管理権限があるとします。ユーザーはEngAdminロールに割り当てられ、AcmeProjectアカウントに対する読取りおよび書込み権限も割り当てられます。その結果、ユーザーは、EngDocsセキュリティ・グループとAcmeProjectアカウント内のコンテンツ・アイテムに対する読取りおよび書込み権限のみを持ちます。
図19-1に、AcmeProjectアカウント権限とEngDocsセキュリティ・グループ権限の共通部分を示します。
アカウントで任意のコンテンツへのアクセスが許可されていない場合、セキュリティ・グループ権限は無視されます。アカウントは、ユーザーのロールによって定義された権限より優先されるフィルタとして機能します。
アカウントは階層構造に設定することができ、これにより、一部のユーザーには構造のブランチ全体に対するアクセス権を付与する一方で、構造の下位レベルのアカウントを割り当てることによりその他のユーザーの権限を制限できます。図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
セキュリティ・モデルでアカウントを使用するときには次の作業効率の問題を考慮してください。
理論上、コンテンツ・サーバーのパフォーマンスに影響を与えずに無制限にアカウントを作成できます。100,000を超えるコンテンツが存在するシステムでは、1人当たり200アカウントの場合に管理効率上の限られた問題があります。ただし、1人当たり100を超えるアカウントがあると、検索効率に重大な影響があります(これは明示的なアカウントであり、階層アカウント接頭辞を介して暗黙的にユーザーに関連付けられたアカウントではありません。ユーザーは単一の接頭辞を介して多数の暗黙的アカウントに対する権限を持つことができます)。
アカウントを有効化する場合は、作業効率上の理由から、使用するセキュリティ・グループが50を超えないようにしてください。
セキュリティ・グループおよびアカウントには、比較的短い名前を付けるようにしてください。
次のタスクがアカウントの管理に含まれます。
コンテンツ・サーバー・インスタンスでアカウントを有効化する手順は、次のとおりです。
|
重要: アカウントを有効化して使用し、その後アカウントを無効化すると、データを損失する場合があります。リポジトリは変更されません。ただし、セキュリティ・モデルに特定の変更を行う場合、コンテンツへのアクセスを継続できるように、ユーザーのセキュリティの設定を更新する必要もあります。 |
コンテンツ・サーバー・ポータルで、「管理」→「管理サーバー」→「一般構成」を選択します。
「一般構成」ページで、「アカウントの有効化」を選択します。
変更を保存します。
コンテンツ・サーバー・インスタンスを再起動します。
または、「一般構成」ページにアクセスし、DomainHome/ucm/cs/config/config.cfgファイルのコンテンツを示す、「追加の構成変数」フィールドに次の行を追加します。
UseAccounts=true
変更を保存して、コンテンツ・サーバー・インスタンスを再起動します。
コンテンツ・サーバー・インスタンスで定義済アカウントを作成するには、次の手順を実行します。
「ユーザー管理」ページから、「セキュリティ」、「定義済アカウント」の順に選択します。
「定義済アカウント」ウィンドウで、「追加」をクリックします。
「新しい定義済アカウントの追加」ウィンドウで、新規アカウントの名前を追加します。名前は簡潔で一貫性のあるものにします。たとえば、場所や部門による3文字の略語(MSP、NYCなど)を使用してすべてのアカウントを設定します。アカウント名は30以内にする必要があり、空白、タブ、行送り、改行および; ^ ? : & + " # % < > * ~の記号は使用できません。
「OK」をクリックします。
すでにコンテンツ・サーバー・リポジトリにコンテンツがチェックインされていて、フルテキスト索引付けのデータベースを使用している場合は、検索索引を再作成します。
メタデータ・データベースの検索インデクサ・エンジンのみを使用している場合は、検索索引を再作成する必要はありません。
一般的に、コンテンツのチェックイン時にアカウントを作成するのではなく、事前定義済アカウントを作成する必要があります。定義済アカウントの詳細は、第19.2.2項を参照してください。
コンテンツ・アイテムのチェックイン時にアカウントを作成するには、ユーザー管理権限が必要で、次の手順を実行する必要があります。
「コンテンツ・チェックイン・フォーム」ページを表示します。
必須およびオプションの情報をすべて入力します。
「アカウント」フィールドにアカウント名を入力します。
「チェックイン」をクリックします。コンテンツ・アイテムに新規アカウントが割り当てられます。
アカウントを含むコンテンツが存在する場合にもアカウントを削除できます。アカウント値はコンテンツ・アイテムに割り当てられたままですが、ユーザー定義のアカウントとみなされるようになります。
|
重要: コンテンツ・サーバー・リポジトリに格納されたコンテンツ・アイテムと関連付けられているアカウントは、絶対に削除しないでください。 |
コンテンツ・サーバー・インスタンスで定義済アカウントを削除するには、次の手順を実行します。
「ユーザー管理」ページから、「セキュリティ」、「定義済アカウント」の順に選択します。
「定義済アカウント」ウィンドウで、削除するアカウントを選択します。
「削除」をクリックします。アカウントが即時に削除されます。
アカウントをユーザーに割り当てるには、Oracle WebLogic Server管理コンソールを使用してグループを作成し、それを1つまたは複数のユーザーに割り当てます。グループ名は@記号で始まり、アンダースコアで区切られた権限で終わる必要があります。次の例は、testaccountという名前のグループを作成し、それに読取り、書込みおよび削除権限を割り当てたものです(@testaccount_RWD)。JpsUserProviderを変更して、「アカウント権限のデリミタ」フィールドにアンダースコアが使用されていることを確認する必要もあります。JpsUserProviderの詳細は、第13.2.5項を参照してください。
Oracle WebLogic Server上のユーザーに割り当てられたアカウントはコンテンツ・サーバー・インスタンスにマップされます。Oracle WebLogic Serverにおけるユーザーの作成とアカウントの割当ての詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。
この例において、Xalcoはロンドン、ニューヨーク、パリに支社のある世界的なソフトウェア企業です。コンテンツ・サーバー・インスタンスはロンドン支社にホストされていて、企業WAN経由で他のオフィスからアクセスされています。また、XalcoはパブリックWebサイトにの一部のファイルをレプリケートしています。まず、各地の営業部および経理部で、ファイルを公開するためにそのインスタンスを使用する必要があります。ニューヨーク支社は小規模で、営業部がありません。
次の各項では、Xalcoの事例に関するサンプル情報を示します。
Xalcoの従業員およびセキュリティ・レベル:
ロンドン: David Smith(全社CFO)、Jim McGuire(イギリス営業部長)
ニューヨーク: Catherine Godfrey(地域経理部長)
パリ: Helene Chirac(ヨーロッパ財務係)
Xalco社のコンテンツのセキュリティ検査(セキュリティ・グループ)のレベル:
パブリック: パブリックのメンバーに公開できるファイル(パブリック・コンテンツはXalco Webサイトにレプリケートされます)
内部: 社内ではアクセスの制限はないが、パブリックには公開できないファイル
機密: 業務上機密が要求され、中間管理職以上に制限されているファイル
極秘: 機密性が高く、役員にのみ公開されるファイル
Xalco社の従業員のアクセス権:
David Smith: 全社CFOとして、インスタンスに保持されているすべてのファイルへのフル・アクセス権が必要です。
Jim McGuire: イギリスの営業部長として、ロンドンの営業ファイルへのフル・コントロールのアクセス権を持ち、パリの営業活動を把握できる必要があります。部長として、機密レベルへの許可があります。
Helene Chirac: パリ支社を本拠地としていて、ヨーロッパの経理に関するファイルのみを参照する必要があり、内部レベルの許可のみがあります。
Catherine Godfrey: ニューヨークを本拠地としちていて、地域経理部長として、ニューヨークの経理ファイルの登校、およびその他のすべての経理ドキュメントの参照を実行できる必要があります。部長として、機密レベルへの許可があります。
アクセス権は場所や職務により異なるため、アカウント構造に反映されています。
ロンドンには経理部および営業部があるため、次の2つのアカウントが必要です。
London/Finance
London/Sales
ニューヨークには経理部のみがあります。
NewYork/Finance
パリには経理および営業部の両方があります。
Paris/Finance
Paris/Sales
このため、最上位レベルのアカウントは3つ(London、NewYork、Paris)で、下位レベルのアカウントは5つになります。
各セキュリティ・グループに2つのロール(1つはコンシューマ用、もう1つはコントリビュータ用)を作成する必要があります。
PublicConsumer
PublicContributor
InternalConsumer
InternalContributor
SensitiveConsumer
SensitiveContributor
ClassifiedConsumer
ClassifiedContributor
特定のユーザーにワークフローを開始する機能を付与するには、コントリビュータ・ロールに管理権限とワークフロー権限を追加する必要があります。
| ロール | パブリック | 内部 | 機密 | 極秘 |
|---|---|---|---|---|
|
PublicConsumer |
R |
|
|
|
|
PublicContributor |
RWD |
|
|
|
|
InternalConsumer |
|
R |
|
|
|
InternalContributor |
|
RWD |
|
|
|
SensitiveConsumer |
|
|
R |
|
|
SensitiveContributor |
|
|
RWD |
|
|
ClassifiedConsumer |
|
|
|
R |
|
ClassifiedContributor |
|
|
|
RWD |
| ロール | David Smith | Helene Chirac | Jim McGuire | Catherine Godfrey |
|---|---|---|---|---|
|
PublicConsumer |
|
× |
|
|
|
PublicContributor |
× |
|
× |
× |
|
InternalConsumer |
|
× |
|
|
|
InternalContributor |
× |
|
× |
× |
|
SensitiveConsumer |
|
|
|
|
|
SensitiveContributor |
× |
|
× |
× |
|
ClassifiedConsumer |
|
|
|
|
|
ClassifiedContributor |
× |
|
× |
× |
David Smithにはロンドン、ニューヨークおよびパリのアカウントのRWDA権限を付与する必要があります。
| Account | 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 |
|
