| Oracle® WebCenter Content Content Serverシステム管理者ガイド 11g リリース1 (11.1.1) B65037-02 |
|
 前 |
 次 |
この章では、Oracle WebCenter Content Serverシステムのセキュリティおよびユーザー・アクセスの管理の概念とタスクについて説明します。内容は次のとおりです。
コンテンツ・サーバー・インスタンスは、Oracle Fusion MiddlewareのOracle WebLogic Serverドメインでデプロイされる、Oracle WebCenter Content(WebCenter Content)ドメインでデプロイされます。セキュリティは、コンテンツ・サーバー・インスタンス、Oracle WebLogic Serverドメイン、Oracle Platform Security Services(OPSS)を含む、複数のレベルでサポートされます。
コンテンツ・サーバー・リポジトリのコンテンツへのアクセスには、コンテンツ、ユーザーおよびグループを、ロール、権限およびアカウントとともに管理するコンテンツ・サーバー管理者が必要です。Oracle WebLogic Server管理者はコンテンツ・サーバー管理者と同様の働きをします。Oracle WebLogic Server管理者はコンテンツ・サーバー・インスタンスにログインしますが、デプロイ中に該当ユーザーが構成されなかった場合には、プライマリ・コンテンツ・サーバー管理者アカウントおよびパスワードを設定します。コンテンツ・サーバー管理者が構成されたら、管理タスクをコンテンツ・サーバー・インスタンスで実行できるようになります。
ほとんどのユーザー管理タスクは、コンテンツ・サーバー・インスタンスのユーザー管理アプレットではなく、Oracle WebLogic Server管理コンソールを使用して実行する必要があります。デフォルトでは、WebCenter ContentはOracle WebLogic Serverユーザー・ストアを使用してコンテンツ・サーバー・インスタンスのユーザー名およびパスワードを管理します。エンタープライズ・レベルのシステムの場合、ユーザーを認証するために、デフォルトのOracle WebLogic Serverユーザー・ストアではなく、Oracle Platform Security Services(OPSS)を使用できます。
コンテンツ・サーバー・ソフトウェアのリポジトリ・コンテンツのレベルには、セキュリティ・グループ(必須)およびアカウント(オプション)の2つがあります。各コンテンツ・アイテムはセキュリティ・グループに割り当てられ、アカウントが有効な場合は、アカウントにも割り当てることができます。ユーザーには各セキュリティ・グループおよびアカウントに応じ特定のレベルの権限(読取り、書込み、削除または管理)が割り当てられ、これによりユーザーは、アイテムのセキュリティ・グループおよびアカウントへの権限の範囲内でコンテンツ・アイテムを操作できます。
アクセス制御リスト(ACL)がコンテンツ・サーバー・インスタンス用に構成され、エンタープライズ・ユーザーへのコンテンツ・アクセスの拡張された制御を提供します。アクセス制御リストは、ユーザー、グループまたはエンタープライズ・ロールのリストであり、コンテンツ・アイテムに対するアクセス権限または操作権限が指定されています。
この項の内容は次のとおりです。
WebCenter Content 11g リリース1(11.1.1)では、コンテンツ・サーバー・インスタンスはOracle WebLogic Server上のWebCenter Contentドメインでデプロイされます。WebCenter Contentとコンテンツ・サーバー・システムは、通常、Oracle Platform Security Services(OPSS)を使用して、Oracle WebLogic Server管理コンソールを介してユーザー・アクセスを認証および管理します。
コンテンツ・サーバーのバージョン10gR3およびそれ以前を使用していた場合、セキュリティに対する次の主な変更点を認識してください。
コンテンツ・サーバーのインストールおよび構成時に、Oracle WebLogic Server管理ユーザーはコンテンツ・サーバー・システム管理ユーザーに指定される必要があります。詳細は、Oracle WebCenter Contentインストレーション・ガイドを参照してください。
コンテンツ・サーバー・ソフトウェアがインストールされると、JPSユーザー・プロバイダ(JpsUserProvider)がデフォルトで設定され、ユーザー認証およびアクセスのためにOracle WebLogic Serverユーザー・ストアと通信します。
外部セキュリティ経由で認証されているすべてのユーザーは、外部コンテンツ・サーバー・ユーザーと見なされます。ユーザーがコンテンツ・サーバー・システムにOracle WebLogic Server経由で初めてログインすると、コンテンツ・サーバー・データベースに追加され、管理者はリポジトリ・マネージャを使用して外部ユーザー情報を表示できます。外部ユーザーは、コンテンツの「チェックイン」ページの「作成者」フィールドなどの、コンテンツ・サーバーのユーザー・リストに自動的には含まれません。
デフォルトでは、コンテンツ・サーバー・システムはOracle WebLogic Serverユーザー・ストアを使用してユーザー名およびパスワードを管理します。ほとんどのユーザー管理タスクは、コンテンツ・サーバーのユーザー管理アプレットではなく、Oracle WebLogic Server管理コンソールを使用して実行する必要があります。コンテンツ・サーバー管理者は、管理アプレットを使用してローカル・ユーザーを作成し、パスワードとロールをコンテンツ・サーバー・システムで割り当てることができますが、コンテンツ・サーバー・システムへのアクセスが認証されたローカル・ユーザーの場合、Oracle WebLogic Server管理コンソールを使用して作成し、パスワードとロールを割り当てることも必要です。
|
注意: コンテンツ・サーバー・システムでのみ作成されたユーザーは、Oracle WebLogic Serverドメインでは認識されません。 |
Oracle WebLogic Serverユーザーは、電子メールや表示名などの追加のユーザー・メタデータも管理します。Oracle WebLogic Server管理サーバー・インタフェースを使用してこのような値を編集できます。
ユーザー・メタデータはコンテンツ・サーバー・システムで変更できますが、ユーザーがコンテンツ・サーバー・インスタンスに少なくとも一度はログインして、コンテンツ・サーバー・メタデータに自分自身をユーザーとして確立した後にかぎられます。最初のログインの後、ユーザーが「ユーザー・プロファイル」ページを更新することも、コンテンツ・サーバー管理者がユーザー管理アプレットでユーザー属性値を設定することもできます。
ユーザーはOracle WebLogic Server管理コンソールを使用してグループに割り当てることができます。ユーザーがコンテンツ・サーバー・インスタンスにログインすると、ユーザーのグループがコンテンツ・サーバーのロールにマップされます。コンテンツ・サーバー・インスタンスで認識されるOracle WebLogic Serverグループでは、Oracle WebLogic Serverグループと正確に同じ名前のロールがコンテンツ・サーバー・インスタンスに作成され、セキュリティ・グループに割り当てられる必要があります。それが行われていないと、ユーザーに割り当てられたOracle WebLogic Serverグループは、コンテンツ・サーバーでのユーザーの権限に何の影響も及ぼしません。
外部ユーザー・ストアを含む構成(Oracle Internet Directory(OID)のLDAPサーバーなど)は、コンテンツ・サーバーの管理サーバーのかわりに、Oracle WebLogic Server管理サーバーを使用して実行されます。Oracle WebLogic Server管理サーバーには組込みのLightweight Directory Access Protocol(LDAP)サーバーが含まれますが、エンタープライズ・レベル・システム向けのOracle Internet Directory(OID)のような、その他のLDAPサーバーと連携するように構成できます。外部ユーザー・ストアとの統合は、ドメインおよびそのすべてのサーバーに適用され、Oracle WebLogic Server管理サーバーをシャットダウンしても、WebCenter Contentおよびその他のアプリケーションは構成済のLDAPサーバーを使用し続けることができます。
セキュリティの統合と構成の詳細は、5.2項「WebCenter Content用のOracle Fusion Middlewareセキュリティ構成」を参照してください。
管理者はコンテンツ・サーバー・システム内の初期ユーザーとコンテンツのセキュリティを、ユーザー管理アプリケーションを使用して設定し、ユーザー・ロール、グループへの権限およびアカウントを定義します。次に、管理者はOracle WebLogic Server管理コンソールを使用してユーザーを作成し、各ユーザーを1つ以上のコンテンツ・サーバーのロールに割り当てると、セキュリティ・グループに対する特定の権限が割り当てられます。アカウントがコンテンツ・サーバー・システムで有効な場合、管理者は特定のアカウントに対する特定の権限をユーザーに割り当てることができ、これにより、割り当てられたロールを介して付与される可能性のある権限を制限できます。
詳細は、5.3項「ユーザー・タイプ、ログインおよびエイリアス」、5.4項「セキュリティ・グループ、ロールおよび権限」および5.5項「アカウント」を参照してください。
次のコンポーネントも、追加の内部コンテンツ・サーバー・セキュリティを提供するために使用できます。
コンテンツ・サーバーとともにインストールされて無効化されるエクストラネット検索コンポーネントを使用して、ユーザー・アクセスのセキュリティをカスタマイズできます。詳細は、5.9.1項「ログイン/ログアウトのカスタマイズ」を参照してください。
|
注意: エクストラネット検索コンポーネントは、Oracle WebLogic Serverドメインがコンテンツ・サーバー・インスタンスのWebサーバーとして使用されている場合には適用できません。セキュリティの実装の変更は、Oracle WebLogic Serverドメインおよび管理構成を直接カスタマイズすることで制御できます。 |
Need to Knowコンポーネントを使用して、ユーザー・アクセスおよび検索結果のセキュリティをカスタマイズできます。このコンポーネントを使用すると、ユーザー・アクセスの制限の追加構成、検索結果の表示の変更、検索動作の変更、およびヒット・リスト・ロールの設定を実行できます。このコンポーネントを使用するには、これをインストールして有効化する必要があります。詳細は、付録B「Need to Knowコンポーネント」を参照してください。
Internet Explorer 7では、安全な接続を使用しないBasic認証でログインしているユーザーに対して、次のメッセージが表示されることに注意してください。
Warning: This server is requesting that your username and password be sent in an insecure manner
この動作(ユーザー名とパスワードのテキストでの送信)は、Basic認証では新しいことではなく、問題は発生しません。
コンテンツ・サーバーでは認証方式を組み合せることができます。たとえば、Oracle WebLogic Server管理コンソールを使用してユーザーを定義して、一部のユーザーにはMicrosoftドメインのIDを使用したログインを許可し、その他のユーザーには外部のLightweight Directory Access Protocol(LDAP)資格証明に基づいてコンテンツ・サーバー・インスタンスへのアクセス権を付与できます。しかし、認証はOracle WebLogic Serverを介して構成されるので、方式の組合せには制限があります。ユーザーは複数の認証ストアに対し認証できますが、Oracle Platform Security Services (OPSS)とOracle WebLogic Serverの統合により、認証(グループ)情報を抽出するのに使用できるのは、構成済みユーザー・ストアのうちいずれか1つのみです。
|
注意: 11g リリース1(11.1.1.6.0)以後、Oracle WebCenter ContentではOracle Virtual Directoryライブラリ(libOVD)機能の使用がサポートされており、この機能を使用すると、ログインやグループ・メンバーシップ情報に対してサイトで複数のプロバイダを使用できます。たとえば、Oracle Internet Directory(OID)とActive Directoryの両方をユーザーおよびロール情報のソースとして使用できます。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「Oracle WebLogic Serverにおける複数LDAP構成」を参照してください。 |
次のオプションを使用して、追加のセキュリティを提供できます。
セキュリティ・プロバイダ・コンポーネント(このコンポーネントはデフォルトでコンテンツ・サーバーとともにインストールされ、有効化されます)を使用して、暗号化されたソケット通信および認証をサポートするようにセキュリティをカスタマイズできます。このコンポーネントは、ソケットまたはサーバー認証用の証明書を使用するように構成できるSecure Sockets Layer (SSL)プロバイダを有効化します。
WebCenter Contentへの接続にSSLおよびHTTPSを使用していて、WebDAVを介して接続できない場合は、WebDAV接続文字列に使用したのと同じURLを使用してブラウザからコンテンツ・サーバー・インスタンスへの接続を試行してください。これにより、暗号化に使用する証明書に問題があるかどうかが確認できます。証明書に問題があることを示すダイアログ・ボックスが表示された場合は、問題を解決して、WebDAVを介した接続を再試行します。
ユーザーが異なるWebサーバーのフロント・エンド(一方のサーバーのフロント・エンドがHTTPSでもう一方はHTTP)を使用してコンテンツ・サーバー・インスタンスにアクセスできるようにする場合は、BrowserUrlPathコンポーネントを使用してコンテンツ・サーバーの構成をカスタマイズできます。このコンポーネントはデフォルトでコンテンツ・サーバー・システムとともにインストールされて無効化され、HTTPSを使用するWebサーバーのフロント・エンドと、HTTPホスト・ヘッダーとして転送されるロード・バランサをサポートします。1つのアクセス方式のみ(HTTPSのみまたはHTTPのみ)を使用する場合や、ブラウザからのホスト・パラメータをブロックするロード・バランサを使用していない場合は、このコンポーネントは必要ありません。詳細は、5.9.2項「ブラウザURLのカスタマイズ」を参照してください。
拡張セキュリティ属性は外部ユーザーまたは特定のアプリケーションのユーザーに割り当てることができます。拡張属性は既存のユーザー属性とマージされ、ユーザーの管理の柔軟性を向上させることができます。詳細は、5.9.3項「拡張ユーザー属性」を参照してください。
無効または破損したHTML構造のデータ入力をフィルタするようコンテンツ・サーバー・インスタンスをカスタマイズできます。詳細は、5.9.4項「データ入力フィルタ」を参照してください。
すべての環境で、組織のセキュリティの要望と、完全な計画フェーズを包括的に理解することは、セキュリティの統合の成功にとって非常に重要です。
この項では、Oracle WebLogic ServerおよびOracle Platform Security Services(OPSS)を含む、Oracle Fusion Middlewareと、WebCenter Contentおよびコンテンツ・サーバー・システムとの統合用のセキュリティ構成情報について説明します。
Oracle WebLogic Serverドメインには、デフォルト認証、認可、資格証明マッピングおよびロール・マッピング・プロバイダ用のデフォルトのセキュリティ・プロバイダ・データ・ストアとして動作する、組込みLightweight Directory Access Protocol (LDAP)サーバーが含まれます。WebCenter Contentでは、Oracle WebLogic Serverと通信するデフォルトのJPSユーザー・プロバイダを提供しています。組込みLDAPサーバーの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の組込みLDAP サーバーの管理に関する説明、およびOracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプの組込みLDAP サーバーの構成に関する説明を参照してください。
ほとんどの場合、組込みLDAPサーバーを使用するのではなく、WebCenter Content本番システムのアイデンティティ・ストアを外部LDAP認証プロバイダに再度関連付ける必要があります。新規LDAP認証プロバイダを構成した後、組込みLDAPプロバイダから新規LDAPプロバイダにユーザーを移行します。外部LDAPプロバイダのWebCenter Content構成の詳細は、Oracle WebCenter Contentインストレーション・ガイドを参照してください。
|
注意: 11g リリース1(11.1.1.6.0)以後、Oracle WebCenter ContentではOracle Virtual Directoryライブラリ(libOVD)機能の使用がサポートされており、この機能を使用すると、ログインやグループ・メンバーシップ情報に対してサイトで複数のプロバイダを使用できます。たとえば、2つのOracle Internet Directory(OID)プロバイダをユーザーおよびロール情報のソースとして使用できる場合もあります。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「Oracle WebLogic Serverにおける複数LDAP構成」を参照してください。 |
表5-1に、ユーザー認証用に構成できるLDAPプロバイダを示します。
表5-1 LDAP認証タイプ
| LDAP認証プロバイダ | 認証タイプ |
|---|---|
|
Microsoft AD |
ActiveDirectoryAuthenticator |
|
SunOne LDAP |
IPlanetAuthenticator |
|
Directory Server Enterprise Edition(DSEE) |
IPlanetAuthenticator |
|
Oracle Internet Directory |
OracleInternetDirectoryAuthenticator |
|
Oracle Virtual Directory |
OracleVirtualDirectoryAuthenticator |
|
EDIRECTORY |
NovellAuthenticator |
|
OpenLDAP |
OpenLDAPAuthenticator |
|
EmbeddedLDAP |
DefaultAuthenticator |
SSLを使用してWebCenter Contentとセキュアな通信を行うようにOracle Fusion Middlewareを構成できます。Oracle Fusion MiddlewareではSSLバージョン3に加えて、TLSバージョン1をサポートしています。
この項の内容は次のとおりです。
詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のSSLの構成に関する説明を参照してください。Web層の構成の詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Fusion MiddlewareでのSSL構成に関する項を参照してください。
Oracle WebCenter Contentでは、双方向SSL通信を構成するために、Oracle WebLogic ServerおよびSun社のSecure Socket Layer(SSL)スタックの両方を使用します。
インバウンドのWebサービス・バインディングの場合、WebCenter ContentではOracle WebLogic Serverインフラストラクチャを使用し、SSL用にOracle WebLogic Serverライブラリを使用します。
アウトバウンドのWebサービス・バインディングの場合、WebCenter ContentではJRF HttpClientを使用し、SSL用にSun JDKライブラリを使用します。
このように違いがあるため、次のJVMオプションを使用してOracle WebLogic Serverを起動します。
次のファイルを開きます。
UNIXオペレーティング・システムでは、$MIDDLEWARE_HOME/user_projects/domains/domain_name/bin/setDomainEnv.shを開きます。
Windowsオペレーティング・システムでは、MIDDLEWARE_HOME\user_projects\domains\domain_name\bin\setDomainEnv.batを開きます。
サーバーが一方向SSL(サーバー認可のみ)に対して有効な場合は、次の行をJAVA_OPTIONSセクションに追加します。
-Djavax.net.ssl.trustStore=your_truststore_location
双方向SSLの場合は、キーストア情報(場所とパスワード)は不要です。
さらに、次の手順を実行して、WebCenter Contentの双方向SSLを有効にして、別のアプリケーションを呼び出せるようにします。
|
注意: サーバーとクライアントの両方が相互認証でSSL用に構成されていることが前提となります。 |
「SOAインフラストラクチャ」メニューから、「SOA管理」、「共通プロパティ」の順に選択します。
ページの下部で、「詳細SOAインフラ拡張構成プロパティ」をクリックします。
「KeystoreLocation」をクリックします。
「値」列に、キーストアの場所を入力します。
「適用」をクリックします。
「戻る」をクリックします。
クライアント側のDOMAIN_HOME\config\soa-infra\configuration\soa-infra-config.xmlでキーストアの場所を指定します。
<keystoreLocation>absolute_path_to_the_keystore_location_and_the_file_name
</keystoreLocation>
Oracle JDeveloperでの設計時に、composite.xmlファイル内の参照セクションをoracle.soa.two.way.ssl.enabledプロパティで更新します。
<reference name="Service1"
ui:wsdlLocation=". . .">
<interface.wsdl interface=". . ."/>
<binding.ws port=". . .">
<property name="oracle.soa.two.way.ssl.enabled">true</property>
</binding.ws>
</reference>
Oracle Enterprise Manager Fusion Middleware管理コンソールで、「WebLogicドメイン」、ドメイン名の順に選択します。
ドメイン名を右クリックし、「セキュリティ」、「資格証明」の順に選択します。
「マップの作成」をクリックします。
「マップ名」フィールドに名前(SOAなど)を入力し、「OK」をクリックします。
「キーの作成」をクリックします。
次の詳細を入力します。
| フィールド | 説明 |
|---|---|
|
マップの選択 |
ステップ7で作成したマップ(この例ではSOA)を選択します。 |
|
キー |
キー名を入力します( |
|
タイプ |
「パスワード」を選択します。 |
|
ユーザー名 |
ユーザー名を入力します( |
|
パスワード |
キーストアに対して作成したパスワードを入力します。 |
|
注意: WebLogic ServerドメインでSSLを設定する場合、キーの別名が必要です。別名の値として「 |
Oracle Enterprise Manager Fusion Middleware Controlコンソールでキーストアの場所を設定します。方法については、ステップ1を参照してください。
httpsおよびsslportを使用してWebCenter Contentを起動するようにcomposite.xml構文を変更します。たとえば、次の太字で示されている構文を変更します。
<?xml version="1.0" encoding="UTF-8" ?> <!-- Generated by Oracle SOA Modeler version 1.0 at [4/1/09 11:01 PM]. --> <composite name="InvokeEchoBPELSync" revision="1.0" label="2009-04-01_23-01-53_994" mode="active" state="on" xmlns="http://xmlns.oracle.com/sca/1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" xmlns:ui="http://xmlns.oracle.com/soa/designer/"> <import namespace="http://xmlns.oracle.com/CustomApps/InvokeEchoBPELSync/BPELProcess1" location="BPELProcess1.wsdl" importType="wsdl"/> <import namespace="http://xmlns.oracle.com/CustomApps/EchoBPELSync/ BPELProcess1"location="http://hostname:port/soa-infra/services/default/EchoBPEL Sync/BPELProcess1.wsdl" importType="wsdl"/>
httpsおよびsslportを使用するように変更します。
location="https://hostname:sslport/soa-infra/services/default/EchoBPELSync /BPELProcess1.wsdl"
Webサービスを一方向SSL環境でWebCenter Contentからの外部参照として呼び出す場合は、サーバーの証明書名(CN)とホスト名が完全に一致することを確認します。これにより、正しいSSLハンドシェイクが保証されます。
たとえば、Webサービスの名前がadfbcで、証明書のサーバー名がhostの場合は、次のコードでSSLハンドシェーク例外が発生します。
<import namespace="/adfbc1/common/"
location="https://host.example.com:8002/CustomApps-adfbc1-context-root/AppModuleService?WSDL"
importType="wsdl"/>
<import namespace="/adfbc1/common/" location="Service1.wsdl"
importType="wsdl"/>
importの順序を入れ替えると、SSLハンドシェイクに成功します。
<import namespace="/adfbc1/common/" location="Service1.wsdl"
importType="wsdl"/>
<import namespace="/adfbc1/common/"
location="https://host.example.com:8002/CustomApps-adfbc1-context-root/AppModuleService?WSDL"
importType="wsdl"/>
この問題に関連して次の制限があります。
Oracle WebLogic Server管理コンソールにあるようなホスト名の検証を無視するオプションはOracle JDeveloperにありません。これは、Oracle JDeveloperで使用されているSSLキットが異なるためです。トラスト・ストアのみコマンドラインから構成できます。他のすべての証明書引数は渡されません。
WSDLファイルで、https://hostnameは前述のように証明書内の名前と一致する必要があります。ブラウザで行う場合と同じ手順は実行できません。たとえば、証明書のCNのホスト名がhost.example.comの場合、ブラウザではhost、host.example.comまたはIPアドレスを使用できます。Oracle JDeveloperでは、必ず証明書内の名前と同じ名前(host.example.com)を使用する必要があります。
ここでは、WebCenter ContentとOracle HTTP Server間でSSL通信を構成する手順について説明します。
詳細は、『Oracle Fusion Middleware管理者ガイド』のWeb層のSSLの構成に関する項を参照してください。
Oracle HTTP ServerのSSL通信を構成するには:
ssl.confに<Location /cs>ロケーション・ディレクティブを追加します。この場合のportはターゲットの管理対象サーバーのポート番号です。
<Location /cs>
WebLogicPort 8002
SetHandler weblogic-handler
ErrorPage http://host.example.com:port/error.html
</Location>
5.2.2.1項「WebCenter Contentの双方向SSL通信の構成」の説明に従って、Oracle WebLogic Serverを起動します。
Oracle Client、Oracle HTTP ServerおよびOracle WebLogic Serverの証明書の構成
Oracle HTTP Serverウォレットからユーザー証明書をエクスポートします。
orapki wallet export -wallet . -cert cert.txt -dn 'CN=\"Self-Signed Certificate for ohs1 \",OU=OAS,O=ORACLE,L=REDWOODSHORES,ST=CA,C=US'
エクスポートした証明書をOracle WebLogic Serverトラストストアに信頼できる証明書としてインポートします。
keytool -file cert.txt -importcert -trustcacerts -keystore DemoTrust.jks
Oracle WebLogic Serverトラストストアから証明書をエクスポートします。
keytool -keystore DemoTrust.jks -exportcert -alias wlscertgencab -rfc -file certgencab.crt
エクスポートした証明書をOracle HTTP Serverウォレットに信頼できる証明書としてインポートします。
orapki wallet add -wallet . -trusted_cert -cert certgencab.crt -auto_login_only
Oracle HTTP Serverを再起動します。
5.2.2.1項「WebCenter Contentの双方向SSL通信の構成」の説明に従って、Oracle WebLogic Serverを再起動します。
WebCenter Contentで非SSLからSSL構成に切り替えるには、Oracle WebLogic Server管理コンソールで「フロントエンド・ホスト」および「フロントエンドHTTPSポート」フィールドを設定する必要があります。設定しないと、To-Doタスクを作成するときに例外エラーが発生します。
Oracle WebLogic Server管理コンソールにログインします。
「環境」セクションで、「サーバー」を選択します。
管理対象サーバーの名前(UCM_server1など)を選択します。
「プロトコル」を選択し、次に「HTTP」を選択します。
「フロントエンド・ホスト」フィールドで、WebCenter Contentドメインが配置されているホスト名を入力します。
「フロントエンドHTTPSポート」フィールドに、SSLリスナー・ポートを入力します。
「保存」をクリックします。
Oracle WebCacheおよびOracle HTTP Server環境では、「Webサービスのテスト」ページでOracle WebCacheとの通信が必要になる場合があります。したがって、WebCenter ContentインスタンスとOracle WebCache間でSSLを構成する必要があります(つまり、ユーザー証明書をOracle WebCacheウォレットからエクスポートし、その証明書をOracle WebLogic Serverトラストストアに信頼できる証明書としてインポートします)。
『Oracle Fusion Middleware管理者ガイド』のOracle Web CacheエンドポイントのSSLの有効化に関する項を参照してください。
keytoolやorapkiなどのツールで作成したカスタム・トラスト・ストアを使用している場合にHTTPSを介してWebCenter Contentを起動するには、Oracle JDeveloperで次の操作を実行します。
参照セクションでWSDLファイルをフェッチするには、「ツール」、「プリファレンス」、「HTTPアナライザ」、「HTTPS設定」、「クライアントの信頼する証明書キーストア」の順でトラスト・ストア情報を設定します。
SSL対応サーバーへのデプロイメント時に、コマンドラインでJSSEプロパティを使用します。
jdev -J-Djavax.net.ssl.trustStore=your_trusted_location
SSL対応の管理対象サーバーにデプロイされた非同期プロセスを有効化して、別の非同期プロセスをHTTPで呼び出すには、まず次の環境を作成することを前提とします。
非同期BPELプロセスAが非同期BPELプロセスBを呼び出す
非同期BPELプロセスAは一方向SSL対応の管理対象サーバーにデプロイされる
すべてのWSDL参照およびバインディングでプレーンHTTPを使用する
実行時に、WSDLはHTTPSを介して検索され、非同期BPELプロセスBからのコールバック・メッセージが失敗します。
この問題を解決するには、callbackServerURLプロパティをcomposite.xmlファイルの参照バインディング・レベルで渡す必要があります。これは、特定の参照呼出しのコールバックURLの値を示します。クライアント・コンポジットがSSL管理対象サーバーで実行されている場合、コールバックはデフォルトでSSLになります。
<reference name="Service1" ui:wsdlLocation="http://localhost:8000/soa-infra/services/default/
AsyncSecondBPELMTOM/BPELProcess1.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/Async/AsyncSecondBPELMTOM/BPELProcess1#
wsdl.interface(BPELProcess1)" callbackInterface="http://xmlns.oracle.com/Async/
AsyncSecondBPELMTOM/BPELProcess1#wsdl.interface(BPELProcess1Callback)"/>
<binding.ws port="http://xmlns.oracle.com/Async/AsyncSecondBPELMTOM/BPELProcess1#
wsdl.endpoint(bpelprocess1_client_ep/BPELProcess1_pt)"
location="http://localhost:8000/soa-infra/services/default/AsyncSecondBPELMTOM
/bpelprocess1_client_ep?WSDL">
<wsp:PolicyReference URI="oracle/wss_username_token_client_policy"
orawsp:category="security" orawsp:status="enabled"/>
<wsp:PolicyReference URI="oracle/wsaddr_policy" orawsp:category="addressing"
orawsp:status="enabled"/>
<property name="callbackServerURL">http://localhost:8000/</property>
</binding.ws>
<callback>
<binding.ws port="http://xmlns.oracle.com/Async/AsyncSecondBPELMTOM/BPELProcess1#
wsdl.endpoint(bpelprocess1_client_ep/BPELProcess1Callback_pt)">
<wsp:PolicyReference URI="oracle/wss_username_token_service_policy"
orawsp:category="security" orawsp:status="enabled"/>
</binding.ws>
</callback>
</reference>
Remote Intradoc Client (RIDC)および自己署名証明書を使用するには、証明書をローカルのJVM証明書ストアにインポートして証明書が信頼されるようにする必要があります。
コンテンツ・サーバー・インスタンスからキーを取得します。例:
openssl s_client -connect host.example.com:7045 2>/dev/null
CONNECTED(00000003)
---
Certificate chain
0 s:/C=US/ST=MyState/L=MyTown/O=MyOrganization/OU=FOR TESTING ONLY/CN=hostname
i:/C=US/ST=MyState/L=MyTown/O=MyOrganization/OU=FOR TESTING ONLY/CN=CertGenCAB
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIB6zCCAZUCEItVMwHDFXAnYG//RoVbXQgwDQYJKoZIhvcNAQEEBQAweTELMAkG
A1UEBhMCVVMxEDAOBgNVBAgTB015U3RhdGUxDzANBgNVBAcTBk15VG93bjEXMBUG
A1UEChMOTXlPcmdhbml6YXRpb24xGTAXBgNVBAsTEEZPUiBURVNUSU5HIE9OTFkx
EzARBgNVBAMTCkNlcnRHZW5DQUIwHhcNMDkwMzI5MjM0NDM0WhcNMjQwMzMwMjM0
NDM0WjB5MQswCQYDVQQGEwJVUzEQMA4GA1UECBYHTXlTdGF0ZTEPMA0GA1UEBxYG
TXlUb3duMRcwFQYDVQQKFg5NeU9yZ2FuaXphdGlvbjEZMBcGA1UECxYQRk9SIFRF
U1RJTkcgT05MWTETMBEGA1UEAxYKZGFkdm1jMDAyMjBcMA0GCSqGSIb3DQEBAQUA
A0sAMEgCQQCmxv+h8kzOc2xyjMCdPM6By5LY0Vlp4vzWFKmPgEytp6Wd87sG+YDB
PeFOz210XXGMx6F/14/yFlpCplmazWkDAgMBAAEwDQYJKoZIhvcNAQEEBQADQQBn
uF/s6EqCT38Aw7h/406uPhNh6LUF7XH7QzmRv3J1sCxqRnA/fK3JCXElshVlPk8G
hwE4G1zxpr/JZu6+jLrW
-----END CERTIFICATE-----
subject=/C=US/ST=MyState/L=MyTown/O=MyOrganization/OU=FOR TESTING
ONLY/CN=host
issuer=/C=US/ST=MyState/L=MyTown/O=MyOrganization/OU=FOR TESTING
ONLY/CN=CertGenCAB
---
No client certificate CA names sent
---
SSL handshake has read 625 bytes and written 236 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 512 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID: 23E20BCAA4BC780CE20DE198CE2DFEE4
Session-ID-ctx:
Master-Key:
4C6F8E9B9566C2BAF49A4FD91BE90DC51F1E43A238B03EE9B700741AC7F4B41C72D2990648DE103
BB73B3074888E1D91
Key-Arg : None
Start Time: 1238539378
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
-----BEGIN CERTIFICATE-----と-----END CERTIFICATE-----行で囲まれたサーバー証明書をコピーして貼り付けます。証明書を新しいファイルに保存します。例:
/tmp/host.pem: -----BEGIN CERTIFICATE----- MIIB6zCCAZUCEItVMwHDFXAnYG//RoVbXQgwDQYJKoZIhvcNAQEEBQAweTELMAkG A1UEBhMCVVMxEDAOBgNVBAgTB015U3RhdGUxDzANBgNVBAcTBk15VG93bjEXMBUG A1UEChMOTXlPcmdhbml6YXRpb24xGTAXBgNVBAsTEEZPUiBURVNUSU5HIE9OTFkx EzARBgNVBAMTCkNlcnRHZW5DQUIwHhcNMDkwMzI5MjM0NDM0WhcNMjQwMzMwMjM0 NDM0WjB5MQswCQYDVQQGEwJVUzEQMA4GA1UECBYHTXlTdGF0ZTEPMA0GA1UEBxYG TXlUb3duMRcwFQYDVQQKFg5NeU9yZ2FuaXphdGlvbjEZMBcGA1UECxYQRk9SIFRF U1RJTkcgT05MWTETMBEGA1UEAxYKZGFkdm1jMDAyMjBcMA0GCSqGSIb3DQEBAQUA A0sAMEgCQQCmxv+h8kzOc2xyjMCdPM6By5LY0Vlp4vzWFKmPgEytp6Wd87sG+YDB PeFOz210XXGMx6F/14/yFlpCplmazWkDAgMBAAEwDQYJKoZIhvcNAQEEBQADQQBn uF/s6EqCT38Aw7h/406uPhNh6LUF7XH7QzmRv3J1sCxqRnA/fK3JCXElshVlPk8G hwE4G1zxpr/JZu6+jLrW -----END CERTIFICATE-----
証明書をローカルのJVM証明書ストアにインポートします。キーストア・パスワードが必要になります。例を次に示します(パスワードはchangeitです)。
sudo /opt/java/jdk1.6.0_12/bin/keytool -import -alias host -keystore
/opt/java/jdk1.6.0_12/jre/lib/security/cacerts -trustcacerts -file
/tmp/host.pem
Enter keystore password: changeit
Owner: CN=hostd, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown,
ST=MyState, C=US
Issuer: CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown,
ST=MyState, C=US
Serial number: -74aaccfe3cea8fd89f9000b97aa4a2f8
Valid from: Sun Mar 29 16:44:34 PDT 2009 until: Sat Mar 30 16:44:34 PDT 2024
Certificate fingerprints:
MD5: 94:F9:D2:45:7F:0D:E3:87:CF:2B:32:7C:BF:97:FF:50
SHA1: A8:A5:89:8B:48:9B:98:34:70:56:11:01:5C:14:32:AC:CB:18:FF:1F
Signature algorithm name: MD5withRSA
Version: 1
Trust this certificate? [no]: yes
Certificate was added to keystore
Oracleではいくつかのシングル・サインオン・ソリューションを提供しています。Oracle Access Manager(OAM)は、WebCenter Contentを含むOracle Fusion Middlewareエンタープライズ・クラスのインストールに推奨するシングル・サインオン(SSO)ソリューションです。OAMはOracleのアイデンティティ管理およびセキュリティ用のエンタープライズ・クラス製品スイートの一部です。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のデプロイに応じた正しいSSOソリューションの選択に関する項を参照してください。
エンタープライズ・クラスのインストールが、Microsoftドメイン・コントローラを使用してActive Directory内のユーザー・アカウントを認証するMicrosoftデスクトップ・ログインを使用する場合、Windows Native Authentication(WNA)のシングル・サインオンの構成はオプションの場合があります。5.2.3.6項「WNA用のWebCenter Contentおよびシングル・サインオンの構成」を参照してください。
|
注意: WebDAV(/dav)は、WebDAVプロトコルごとにBasic認証によって保護されていますが、通常はフォームベースのログインが必要となるSSOによっては保護されていません。WebDAVに対してカスタムSSOソリューションを使用する場合は、カスタム・コンポーネントが必要となります。 |
構成情報は次の項で説明します。
5.2.3.1項「WebCenter Contentを使用したOracle Access Manager 11gの構成」
5.2.3.2項「WebCenter Contentを使用したOracle Access Manager 10gの構成」
この項では、WebCenter ContentとOracle Access Manager(OAM)11gの統合方法について説明します。WebCenter Content: コンテンツ・サーバー(CS)、WebCenter Content: Records(URM)、WebCenter Content: Inbound Refinery(IBR)およびWebCenter Content: Site Studio(SS)用の構成情報を提供します。
OAM 11gを構成する前に、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』のOracle Identity Management 11gソフトウェアのインストールに関する説明で提供されている手順に従って、ソフトウェアをインストールします。
『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』のOAMエージェントの設定に関する説明で説明しているように、OAM 11g、Oracle HTTP Server(OHS)およびWebGateを構成します。
mod_wl_ohs.confファイルにエントリを追加して、転送するWebCenter Content Uniform Resource Identifier(URI)を追加します。次の例から適切なロケーション・エントリを使用します。例の各エントリは受信パスを対応するアプリケーションが存在する適切なOracle WebLogic Serverにマップします。
次のエントリのリストで、hostnameはWebCenter Content Serverをホストしているコンピュータ名を示し、portnumberは対応するアプリケーションが存在するOracle WebLogic Serverのポート番号を示します。hostnameおよびportnumberは、使用しているシステムのホスト名とポート名に置き換えます。
|
注意: 転送するURIはインストールしたWebCenter Content機能により異なります。機能に応じて適切なロケーション・エントリを使用します。たとえば、 Site Studioの場合、転送するURIはお客様が構成します。たとえば、サイトが |
|
注意: コンテンツ・サーバーのロケーション |
# WebCenter Content Server
<Location /cs>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
# WebCenter Content Server authentication
<Location /adfAuthentication>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
# WebCenter online help
<Location /_ocsh>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
# IBR
<Location /ibr>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
# URM
<Location /urm>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
# SS
<Location /customer-configured-site-studio
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
OAM 11gリモート登録ツール(oamreg)を使用して、保護およびパブリックにするWebCenter ContentのURIを指定して、OAMエージェントを登録します。『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOracle Access Manager 11gでのOAMエージェントのプロビジョニングに関する項を参照してください。
詳細は、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』のOAMエージェントの設定に関する説明を参照してください。
|
注意: 保護およびパブリックにするURIは、コンテンツ・サーバー(UCM)、Inbound Refinery(IBR)、Records(URM)、Site Studio(SS)など、インストールしたWebCenter Content機能により異なります。 Site Studioの場合、保護するURIはお客様が構成します。たとえば、サイトが |
| 機能 | タイプ | URI |
|---|---|---|
|
UCM |
保護 |
|
|
UCM |
パブリック |
|
|
UCM |
パブリック |
|
|
IBR |
保護 |
|
|
IBR |
パブリック |
|
|
URM |
保護 |
|
|
URM |
パブリック |
|
|
SS |
保護 |
/customer-configured-for-site-studio |
|
注意: OAM 11gの構成が完了した後で、WebCenter ContentのURLが正しくリンクしていない場合、サーバー・ホストとサーバーのポート値の変更が必要な場合があります。詳細は、5.2.3.5項「シングル・サインオン用のWebCenter Content URLの構成」を参照してください。 |
これらのタスクを確実に実行することにより、WebCenter Contentドメインを構成します。『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOracle Access Manager 11g SSOソリューションのデプロイに関する項を参照してください。
OAM ID アサーション・プロバイダを構成します。OAM IDアサーション・プロバイダの制御フラグは、REQUIREDに設定される必要があり、OAM_REMOTE_USERおよびObSSOCookieはアクティブなタイプとして選択される必要があります。
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のシングル・サインオン用のIDアサーション・プロバイダ、About Using the Identity Asserter for SSO with OAM 11gおよび11g WebGatesでのSSO用IDアサーション・プロバイダの使用について、およびOracle Access Manager 11gでのSSO用IDアサーション・プロバイダの構成に関する項を参照してください。
認証プロバイダを構成します。これはOracle Internet Directory (OID)またはOracle Virtual Directory (OVD)のような、OAMで使用されるLDAPサーバーと一致する、ユーザー・ストア用の外部LDAPサーバーを指定するのに必要です。たとえば、OAMでOIDを使用している場合、OID認証プロバイダがWebCenter Contentドメインに追加される必要があります。
|
注意: WebCenter Content用のOracle WebLogic ServerドメインがDefaultAuthenticatorプロバイダとは異なる認証プロバイダを使用するように構成される場合、新しい認証プロバイダはセキュリティ・レルム構成にリストされた最初の認証プロバイダである必要があり、そうでないと、WebCenter Contentはユーザー権限をロードできません。新しい認証プロバイダがDefaultAuthenticatorプロバイダよりも前にリストされるように、認証プロバイダの順番を変更してください。また、 |
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOracle Access Manager 11gでの認証プロバイダのインストールおよびOracle Access Manager IDアサーション・プロバイダのプロバイダの設定に関する項を参照してください。
OAM 10gとOAM 11gで認証プロバイダをデプロイするときの違いについての詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の表12-1を参照してください。
OPSS (OAM)シングル・サインオン・プロバイダを構成します。
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のADFセキュリティ、OAM SSOおよびOPSS SSOを使用した、Webアプリケーション用のOracle WebLogic Serverの構成についての項を参照してください。
OAM 11gのインストールおよび構成後、すべての構成済みアプリケーションにアクセスできることと、ログインにより再度サインインすることを要求されずにすべての構成済みアプリケーションにアクセスできることを確認します。また、可能な場合、グローバル・ログアウトをテストし、その他のすべての関連アプリケーションからログアウトしていることを確認します。
詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』およびOracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドのOracle Access Manager 11gの集中管理されたログアウトの構成に関する説明を参照してください。
この項では、WebCenter ContentとOracle Access Manager(OAM)10gの統合方法について説明します。WebCenter Content Server(CS)、WebCenter Content: Records(URM)およびWebCenter Content: Inbound Refinery(IBR)用の構成情報を提供します。
|
注意: WebCenter Contentバージョン11gR1をOAMバージョン10gを使用する環境にデプロイするには、ログアウト・リクエストを適切に処理するための追加の構成が必要です。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOracle Access Manager 10gおよび10g WebGatesのグローバル・ログアウトの構成に関する項を参照してください。 |
OAMを構成する前に、ソフトウェアをインストールします。OAM統合の詳細は、Oracle Fusion Middleware Oracle Enterprise Content Management Suiteエンタープライズ・デプロイメント・ガイドを参照し、OAM 10gソフトウェアのインストールの詳細は、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOracle Access Manager 10gでのSSOのデプロイに関する説明で説明しているように、OAM 10g、Oracle HTTP Server(OHS)およびWebGateを構成します。
mod_wl.confファイルにエントリを追加して、転送するWebCenter Content Uniform Resource Identifier(URI)を追加します。次の例から適切なロケーション・エントリを使用します。次のLocationリストのエントリは、対応するアプリケーションが存在する適切なOracle WebLogic Serverへの受信パスをマップします。
次のエントリのリストで、hostnameはWebCenter Content Serverをホストしているコンピュータ名を示し、portnumberは対応するアプリケーションが存在するOracle WebLogic Serverのポート番号を示します。hostnameおよびportnumberは、使用しているシステムのホスト名とポート名に置き換えます。
|
注意: 転送するURIはインストールしたWebCenter Content機能により異なります。機能に応じて適切なロケーション・エントリを使用します。たとえば、 Site Studioの場合、転送するURIはお客様が定義します。たとえば、サイトが |
|
注意: コンテンツ・サーバーのロケーション |
# WebCenter Content Server
<Location /cs>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
# WebCenter Content Server authentication
<Location /adfAuthentication>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
# WebCenter online help
<Location /_ocsh>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
# IBR
<Location /ibr>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
# URM
<Location /urm>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
# SS
<Location /customer-configured-for-site-studio>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portname>
</Location>
OAM 10g構成ツール(oamcfgtool)を使用して保護するWebCenter Content URIを指定します。
OAM構成ツールはコマンドライン・ユーティリティで、情報を要求する一連のスクリプトを起動し、OAMで必要なプロファイルとポリシーを設定するのに使用します。oamCtgToolの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
|
注意: 保護するURIは、WebCenter Content(UCM)、Inbound Refinery(IBR)、Records(URM)、Site Studio(SS)など、インストールしたWebCenter Content機能により異なります。 Site Studioの場合、保護するURIはお客様が構成します。たとえば、サイトが |
| 機能 | URI |
|---|---|
|
UCM |
|
|
IBR |
|
|
URM |
|
|
SS |
/customer_configured_site_studio |
|
注意: OAMの構成が完了した後で、WebCenter ContentのURLが正しくリンクしていない場合、サーバー・ホストとサーバーのポート値の変更が必要な場合があります。詳細は、5.2.3.5項「シングル・サインオン用のWebCenter Content URLの構成」を参照してください。 |
OAMグローバル・ログアウトの設定を完了するには、end_urlが処理されるようWebGateを構成します。この構成を追加しない場合、ログアウトしても、OAM 10gのWebGateでend_urlが処理されないため、終了URLへのリダイレクトが行われません。構成手順の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
シングル・サインオン・ログアウトが正常に機能するよう、URL /oamsso/logout.htmlをAccessGateのログアウトURL設定に追加します。詳細は、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドのシングル・サインオン・ログアウトURLおよびAccessGate構成パラメータの構成に関する説明を参照してください。
次のタスクを実行して、WebCenter Contentドメインを構成します。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOracle Access Manager 10gでのSSOソリューションのデプロイに関する項を参照してください。
OAM IDアサーション・プロバイダを構成します。OAM IDアサーション・プロバイダの制御フラグをREQUIREDに設定する必要があります。
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOracle Access Manager 10gでのOAM IDアサーション・プロバイダの構成に関する項を参照してください。
認証プロバイダを構成します。これはOracle Internet Directory (OID)またはOracle Virtual Directory (OVD)のような、OAMで使用されるLDAPサーバーと一致する、ユーザー・ストア用の外部LDAPサーバーを指定するのに必要です。たとえば、OAMでOIDを使用している場合、OID認証プロバイダがWebCenter Contentドメインに追加される必要があります。
|
注意: WebCenter Content用のOracle WebLogic Serverドメインが |
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOAM 10gの認証プロバイダのインストールおよび設定およびOracle Access Manager 10gの認証の構成に関する項を参照してください。
OAM 10gとOAM 11gで認証プロバイダをデプロイするときの違いについての詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の表12-1を参照してください。
OPSS (OAM)シングル・サインオン・プロバイダを構成します。
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOracle Access Manager 10gを使用したシングル・サインオンの構成に関する項を参照してください。
OAM 10gのインストールおよび構成後、すべての構成済みアプリケーションにアクセスできることと、ログインにより再度サインインすることを要求されずにすべての構成済みアプリケーションにアクセスできることを確認します。また、可能な場合、グローバル・ログアウトをテストし、その他のすべての関連アプリケーションからログアウトしていることを確認します。
詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』およびOracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドのOracle Access Manager 10gおよび10g WebGatesのグローバル・ログアウトの構成に関する説明を参照してください。
Oracle Single Sign-On (OSSO)は10g Oracle Application Serverスイートの一部です。OSSOは、Oracle Internet DirectoryおよびOracle HTTP Server (OHS)11gと組み合せたOC4Jアプリケーション・サーバーで使用できるエンタープライズ・レベルのシングル・サインオン・ソリューションです。
既存のOracleデプロイメントにOSSOがエンタープライズ・ソリューションとしてすでにデプロイされている場合、Oracle Fusion Middlewareは、既存のOSSOソリューションを引き続きサポートします。ただし、OAM 11g Single Sign-onソリューションへのアップグレードを検討することをお薦めします。
この項では、WebCenter ContentとOSSOの統合に関する情報について説明します。WebCenter Content(UCM)、Records(URM)、Inbound Refinery(IBR)およびSite Studio(SS)用の構成情報を提供します。
『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』、『Oracle Fusion Middlewareアップグレード・プランニング・ガイド』および『Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド』も参照してください。
OSSOを構成する前に、ソフトウェアがインストールされていることを確認します。OSSOおよびOracle Delegated Administration Serviceは11g リリースの一部ではありません。お客様は、11g Oracle Internet DirectoryおよびOracle Directory Integration Platformと互換性があり、いわゆる10gでのApplication Serverインフラストラクチャを形成する、これらの製品の10.1.4.*バージョンをダウンロードする必要があります。これらの10g製品でのデプロイ手順については、Oracle Identity Managementリリース10.1.4.0.1用のOracle Application Serverエンタープライズ・デプロイメント・ガイドの第4章「JAZN-SSO/DASのインストールおよび構成」を参照してください。このマニュアルは次のOracle Technology Networkから使用可能です。
http://download.oracle.com/docs/cd/B28196_01/core.1014/b28184/toc.htm
OSSOを構成します。『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
WebCenter Content Uniform Resource Identifier(URI)エントリをmod_wl_ohs.confファイルに追加します。次の例から適切なロケーション・エントリを使用します。例の各エントリは受信パスを対応するアプリケーションが存在する適切なOracle WebLogic Serverにマップします。
次のエントリのリストで、hostnameはWebCenter Content Serverをホストしているコンピュータ名を示し、portnumberは対応するアプリケーションが存在するOracle WebLogic Serverのポート番号を示します。hostnameおよびportnumberは、使用しているシステムのホスト名とポート名に置き換えます。
|
注意: 転送するURIはインストールしたWebCenter Content機能により異なります。機能に応じて適切なロケーション・エントリを使用します。たとえば、 Site Studioの場合、転送するURIはお客様が構成します。たとえば、サイトが |
|
注意: コンテンツ・サーバーのロケーション |
# WebCenter Content Server
<Location /cs>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
# WebCenter Content Server authentication
<Location /adfAuthentication>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
# WebCenter online help
<Location /_ocsh>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
# IBR
<Location /ibr>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
# URM
<Location /urm>
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
# SS
<Location /customer-configured-site-studio
SetHandler weblogic-handler
WebLogicHost <hostname>
WebLogicPort <portnumber>
</Location>
保護するWebCenter Content Uniform Resource Identifier(URI)を含めるようにmod_osso.confファイル(ORACLE_HOME/ohs/conf/)を変更します。
|
注意: 保護するURIは、コンテンツ・サーバー(UCM)、Inbound Refinery(IBR)、Records(URM)、Site Studio(SS)など、インストールしたWebCenter Content機能により異なります。 Site Studioの場合、保護するURIはお客様が構成します。たとえば、サイトが |
| 機能 | URI |
|---|---|
|
UCM |
|
|
IBR |
|
|
URM |
|
|
SS |
/customer_configured_site_studio |
これらのタスクを確実に実行することにより、WebCenter Contentドメインを構成します。『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOracle AS SSO 10gを使用したシングル・サインオンの構成に関する項を参照してください。
WebCenter Content用のOracle WebLogic ServerのOSSO IDアサーション・プロバイダを追加および構成します。認証プロバイダとして、OSSO IDアサーション・プロバイダ、OID認証、デフォルト認証を推奨します。
OID認証プロバイダはOracle Internet Directoryサーバー用で、本稼働レベルのシステムで使用されます。デフォルト認証プロバイダは、Oracle WebLogic Server組込みLDAPサーバー用です。
OSSOIdentityAsserterをドメイン用のプライマリ・プロバイダ認証として設定し、ユーザー・プロファイルが関連Oracle Internet Directoryサーバーから取得できるようにします。必要な場合、リストされているように制御フラグを設定し、プロバイダの順序を変更して次の順序で表示されるようにします。
OSSOIdentityAsserter (REQUIRED)
OIDAuthenticator (SUFFICIENT)
DefaultAuthenticator (SUFFICIENT)
|
注意: WebCenter Content用のOracle WebLogic ServerドメインがDefaultAuthenticatorプロバイダとは異なる認証プロバイダを使用するように構成される場合、新しい認証プロバイダはセキュリティ・レルム構成にリストされた最初の認証プロバイダである必要があり、そうでないと、WebCenter Contentはユーザー権限をロードできません。新しい認証プロバイダがDefaultAuthenticatorプロバイダよりも前にリストされるように、認証プロバイダの順番を変更してください。また、 |
認証プロバイダを構成します。これはOracle Internet Directory (OID)またはOracle Virtual Directory (OVD)のような、OAMで使用されるLDAPサーバーと一致する、ユーザー・ストア用の外部LDAPサーバーを指定するのに必要です。たとえば、OSSOがOIDを使用している場合、OID認証プロバイダがOracle UCMドメインに追加される必要があります。
|
注意: OSSOの構成が完了した後で、WebCenter ContentのURLが正しくリンクしていない場合、サーバー・ホストとサーバーのポート値の変更が必要な場合があります。詳細は、5.2.3.5項「シングル・サインオン用のWebCenter Content URLの構成」を参照してください。 |
WebCenter Content用のOracle WebLogic Serverドメインが、ユーザー認証(Oracle Internet Directoryまたはその他のLDAPプロバイダなど)用にデフォルトの認証プロバイダ以外の認証プロバイダを使用するように構成されている場合、プライマリ・プロバイダはセキュリティ・レルム構成の最初の認証プロバイダである必要があります。そうでないと、ログイン認証が失敗します。
プライマリ・プロバイダが最初にリストされていない(たとえば、Oracle WebLogic ServerプロバイダであるDefaultAuthenticatorの下にリストされている)場合、WebCenter Contentはユーザーのグループ・メンバーシップを正常にロードできず、その結果、ユーザー権限もロードできません。Oracle WebLogic Server管理コンソールを使用して、構成済み認証プロバイダが呼び出される順番を変更できます。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』を参照してください。
|
注意: Oracle Internet Directoryを使用する場合、すべてのWebCenter Content管理者とその他のユーザーは、Oracle Internet Directoryで定義される必要があります。 |
|
注意: コンテンツ・サーバー・システムはコンテンツ・サーバー管理者ロールを、内部Oracle WebLogic Serverユーザー・ストアに定義された管理ユーザーに割り当てます。これはOracle Internet Directoryが使用されているかどうかに関わらず当てはまります。ただし、Oracle Internet DirectoryおよびOracle Internet Directory Authenticationプロバイダが最初にリストされていない場合、コンテンツ・サーバー・インスタンスによるOracle WebLogic Serverが定義した管理ユーザーのロールを取得するリクエストは失敗します。 |
|
注意: 11g リリース1(11.1.1.6.0)以後、Oracle WebCenter ContentではOracle Virtual Directoryライブラリ(libOVD)機能の使用がサポートされており、この機能を使用すると、ログインやグループ・メンバーシップ情報に対してサイトで複数のプロバイダを使用できます。たとえば、Oracle Internet Directory(OID)とActive Directoryの両方をユーザーおよびロール情報のソースとして使用できます。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOracle WebLogic Serverでの複数LDAP構成に関する説明を参照してください。 |
Oracleアプリケーションをシングルサインオン(SSO)とともに使用するように構成し、Oracle Access Manager(OAM)およびOracle Single Sign-On(OSSO)を設定した場合、WebCenter Content GET_ENVIRONMENTサービスにより、サーバー名、サーバー・ポート、アプリケーション・サービス・コール(Oracle WebCenter Doclibサービスなど)への相対Webルートが提供されます。ただし、GET_ENVIRONMENTにより提供される値は、使用するSSO構成には適切でない場合があります。
OHSサーバー・ホストおよびサーバー・ポートを使用するアプリケーション・サービスをリダイレクトする場合(OAMおよびOSSOソリューションは両方ともOHSを使用するフロント・エンド・アプリケーションが必要なため)、WebCenter Content Serverホストおよびサーバー・ポートの構成値を変更する必要があります。
次の2つのいずれかの方法を使用して、WebCenter Content Serverホストおよびサーバー・ポート値を変更できます。
Oracle WebLogic Server管理コンソールを使用します。2.4.1項「コンテンツ・サーバーのサーバー構成パラメータの変更」を参照してください。
SystemPropertiesという名前のWebCenter Contentスタンドアロン・アプリケーションを使用します。
WebCenter Contentドメイン・ディレクトリに移動します。
ディレクトリをucm/cs/binに変更します。
スタンドアロン・アプリケーションを実行します。./SystemProperties
システム・プロパティ画面で、「インターネット」タブを選択します。
HTTPサーバー・アドレスをOHS(またはロード・バランサ)サーバー・ホストおよびサーバー・ホスト値に更新します。
システム・プロパティ画面を閉じます。
Oracle WebLogic Serverドメインを再起動します。
Windows Native Authentication(WNA)用にWebCenter Contentおよびシングル・サインオン(SSO)を設定するには、Microsoft Active Directory、クライアントおよびOracle WebLogic Serverドメインが必要です。MicrosoftクライアントでのSSOへのシステム要件を含む詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のMicrosoftクライアントでのシングル・サインオンの構成に関する項に記載されています。
MicrosoftクライアントでのSSOの構成の一部として、外部Microsoft Active DirectoryにアクセスするようにLDAP認証プロバイダを指定する必要があります。Oracle WebLogic ServerではMicrosoft Active Directory用に構成済のLDAPプロバイダであるActive Directory Authentication providerが提供されます。『Oracle WebLogic Serverの保護』のConfiguring LDAP認証プロバイダの構成に関する項を参照してください。
|
注意: WebCenter Content用のOracle WebLogic ServerドメインがDefaultAuthenticatorプロバイダとは異なる認証プロバイダを使用するように構成される場合、新しい認証プロバイダはセキュリティ・レルム構成にリストされた最初の認証プロバイダである必要があり、そうでないと、WebCenter Contentはユーザー権限をロードできません。新しい認証プロバイダがDefaultAuthenticatorプロバイダよりも前にリストされるように、認証プロバイダの順番を変更してください。また、 |
MicrosoftクライアントでのSSOの構成の一部として、Oracle WebLogic Serverセキュリティ・レルムにネゴシエートIDアサーション・プロバイダを構成する必要があります。IDアサーション・プロバイダは、Simple and Protected Negotiate (SPNEGO)トークンをデコードしてKerberosトークンを取得し、このKerberosトークンを検証してWebLogicユーザーにマップします。Oracle WebLogic Server管理コンソールを使用して、ドメイン構造内の適切なセキュリティ・レルムに新しいプロバイダを追加し、名前を付けて、そのタイプとしてNegotiateIdentityAsserterを選択します。変更をアクティブ化して、Oracle WebLogic Serverを再起動します。サーバーはKerberosチケットを使用できるようになり、それはブラウザから受信します。
関連デプロイ・プランを使用して、Windows Native Authentication(Kerberos)環境で使用される各WebCenter Contentアプリケーション(コンテンツ・サーバー、Inbound Refinery、Records)を再デプロイする必要があります。デプロイ・プランはXMLドキュメントです。cs-deployment-plan.xml、ibr-deployment-plan.xmlおよびurm-deployment-plan.xmlの、3つのOracle UCMアプリケーションそれぞれに対してプランが提供されます。Oracle WebLogic Scripting Toolを使用してデプロイ・プランを実装することもできます。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ナビゲーション・ツリーで、「デプロイメント」をクリックします。
「制御」タブで、変更するWebCenter Contentデプロイメントが表示されるまで「次へ」をクリックします。
Oracle WebCenter Contentサーバー
Oracle WebCenter Content: Inbound Refinery
Oracle WebCenter Content: Records
変更するデプロイメントの左のチェックボックスを選択します。
「更新」をクリックします。
デプロイ・プラン・パスの下で「パスの変更」を選択します。
適切なプラン・ファイルに移動して選択します。
cs-deployment-plan.xml(Content Server用)
ibr-deployment-plan.xml(Inbound Refinery用)
urm-deployment-plan.xml(Records用)
「このアプリケーションを次のデプロイメント・ファイルを使用して再デプロイします。」が選択されていることを確認します。
「次へ」をクリックします。
「終了」をクリックします。
MicrosoftクライアントでのSSOが適切に構成されていることを確認するには、使用するMicrosoft WebアプリケーションまたはWebサービスへのブラウザをポイントします。Windowsドメインにログインし、ドメインのActive Directoryサーバーから取得したKerberos資格証明がある場合、ユーザー名またはパスワードを指定せずにWebアプリケーションまたはWebサービスにアクセスできるはずです。
cs-deployment-plan.xml
提供されたcs-deployment-plan.xmlファイルを使用するか、または.xmlファイルを作成してそれにcs-deployment-plan.xmlという名前を付けます。
<?xml version='1.0' encoding='UTF-8'?>
<deployment-plan
xmlns="http://xmlns.oracle.com/weblogic/deployment-plan"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/deployment-plan http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd"
global-variables="false">
<application-name>cs.ear</application-name>
<variable-definition>
<variable>
<name>http-only</name>
<value>false</value>
</variable>
</variable-definition>
<module-override>
<module-name>cs.war</module-name>
<module-type>war</module-type>
<module-descriptor external="false">
<root-element>weblogic-web-app</root-element>
<uri>WEB-INF/weblogic.xml</uri>
<variable-assignment>
<name>http-only</name>
<xpath>/weblogic-web-app/session-descriptor/cookie-http-only</xpath>
</variable-assignment>
</module-descriptor>
</module-override>
</deployment-plan>
ibr-deployment-plan.xml
提供されたibr-deployment-plan.xmlファイルを使用するか、または.xmlファイルを作成してそれにibr-deployment-plan.xmlという名前を付けます。
<?xml version='1.0' encoding='UTF-8'?>
<deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://xmlns.oracle.com/weblogic/deployment-plan http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd" global-variables="false">
<application-name>ibr.ear</application-name>
<variable-definition>
<variable>
<name>http-only</name>
<value>false</value>
</variable>
</variable-definition>
<module-override>
<module-name>ibr.war</module-name>
<module-type>war</module-type>
<module-descriptor external="false">
<root-element>weblogic-web-app</root-element>
<uri>WEB-INF/weblogic.xml</uri>
<variable-assignment>
<name>http-only</name>
<xpath>/weblogic-web-app/session-descriptor/cookie-http-only</xpath>
</variable-assignment>
</module-descriptor>
</module-override>
</deployment-plan>
urm-deployment-plan.xml
提供されたurm-deployment-plan.xmlファイルを使用するか、または.xmlファイルを作成してそれにurm-deployment-plan.xmlという名前を付けます。
<?xml version='1.0' encoding='UTF-8'?>
<deployment-plan
xmlns="http://xmlns.oracle.com/weblogic/deployment-plan"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/deployment-plan http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd"
global-variables="false">
<application-name>urm.ear</application-name>
<variable-definition>
<variable>
<name>http-only</name>
<value>false</value>
</variable>
</variable-definition>
<module-override>
<module-name>urm.war</module-name>
<module-type>war</module-type>
<module-descriptor external="false">
<root-element>weblogic-web-app</root-element>
<uri>WEB-INF/weblogic.xml</uri>
<variable-assignment>
<xpath>/weblogic-web-app/session-descriptor/cookie-http-only</xpath>
</variable-assignment>
</module-descriptor>
</module-override>
</deployment-plan>
Oracle Infrastructure Webサービスでは、ポリシー・セットを作成してグローバル・スコープのサブジェクト(ドメイン、サーバー、アプリケーションまたはSOAコンポジット)にアタッチする機能が提供されています。Oracle Infrastructure WebサービスはWeb Services for Java EE 1.2仕様に従って実装されます(この仕様は、JavaでWebサービスを実装するための標準のJava EEランタイム・アーキテクチャを定義したものです)。この仕様には、標準Java EE Webサービス・パッケージング形式、デプロイメント・モデルおよびランタイム・サービスも記述されており、Oracle Infrastructure Webサービスにはこれらがすべて実装されています。
WebサービスへのOWSMセキュリティの適用の詳細は、Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイドのWebサービスへのポリシーのアタッチに関する説明を参照してください。
IBM WebSphereでサポートされているOracle Infrastructure Webサービスの動作の違いや制限事項については、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドのIBM WebSphereでのWebサービスの管理に関する説明を参照してください。
この項の内容は次のとおりです。
Oracle WebCenter Content Serverソフトウェアは次のユーザー・ログイン・タイプをサポートします。
外部ユーザーはWebCenter Contentシステム外で定義され、Oracle WebLogic Server管理コンソールおよびOracle Platform Security Services(OPSS)を使用して、外部セキュリティにより認証されます。認証されると、外部ユーザーはOracle WebLogic Server経由でコンテンツ・サーバー・インスタンスにアクセスできます。一般的に、外部ユーザーは信頼できるドメインのユーザーで、アクセス権は付与されますが、WebCenter Contentシステムからは管理されないユーザーです。そのパスワードはOracle WebLogic Serverドメイン、ネットワーク・ドメイン、またはOracle Internet Directoryなどのその他のプロバイダにより所有されますが、ユーザー管理アプレットを使用して、外部ユーザーからローカル・ユーザーへの変換時にユーザー・パスワードを設定できます。ローカル・ユーザーとは異なり、未定義の外部ユーザーにはguestロールは割り当てられません。
ユーザーがコンテンツ・サーバー・インスタンスにOracle WebLogic Server経由で初めてログインすると、コンテンツ・サーバー・データベースに追加され、管理者はリポジトリ・マネージャを使用して外部ユーザー情報を表示できます。ただし、外部ユーザーは、コンテンツの「チェックイン」ページの「作成者」フィールドなどの、ユーザー・リストに自動的には含まれません。「オーバーライド」チェック・ボックスがユーザーの「ユーザー・プロファイル」ページで選択されている場合、コンテンツ・サーバー・データベースで定義されたユーザー情報により、外部ユーザー・ベースから導出されたユーザー情報は上書きされます。
管理ユーザー・アプレットは少なくとも一度はコンテンツ・サーバー・インスタンスにログインしたことのあるユーザーのみを表示します。Oracle WebLogic Serverユーザー・ストアまたはコンテンツ・サーバー・インスタンス外のその他のユーザーストアからのすべてのユーザーは、外部ユーザーとして表示されます。
デフォルトでは、外部セキュリティ統合は、外部ユーザー・ベースからの限定されたユーザー情報のセット(ユーザー名、パスワード、ロール、アカウントおよび電子メール・アドレスなどの追加情報)をコンテンツ・サーバー・インスタンスにマップします。LDAP統合を使用している場合、電子メール・アドレスやユーザー・ロケールなどの追加のユーザー情報は、Oracle WebLogic Server管理コンソールを使用して組込みLDAPサーバーからマップでき、Oracle Platform Security Servicesと統合できます。
次に外部ユーザーの共通の特性をリストします。
ログイン(認証)の定義: ユーザーIDおよびパスワードで定義され、これらは次に示すWebCenter Contentシステム以外のユーザー・データベースに格納されます。
信頼できるドメイン(Oracle WebLogic Serverなど)
Lightweight Directory Application Protocol (LDAP)
その他のデータベース
アクセス(認証)の決定: 信頼できるドメインまたはその他のユーザー・データベース(Oracle WebLogic Serverユーザー・ストア、Oracle Internet Directoryまたはその他のLDAPプロバイダなど)およびWebCenter Contentからの資格証明(ロールなど)により決定されます。
ユーザー・ログイン: ユーザーがログインするには、Oracle WebLogic Serverおよびコンテンツ・サーバー・インスタンスが実行されている必要があります。
ユーザー・パスワード: ユーザー・パスワードはOracle WebLogic Serverまたはその他のユーザー・データベース(LDAPサーバーなど)で管理者により定義されます。ユーザーはコンテンツ・サーバー・インスタンスでパスワードを変更できません。
インタフェースの問題: ユーザー名はコンテンツ・チェックイン・リストに表示されません。しかし、ユーザーはワークフローに参加できます。
このプロセスに従い、外部ユーザー用のロール、グループおよびアカウントを設定します。
セキュリティ・グループを設定します。5.4.2.1項「コンテンツ・サーバーでのセキュリティ・グループの追加」を参照してください。
ロールを設定します。5.4.4.1項「コンテンツ・サーバーでのロールの作成」を参照してください。
権限を配置します。5.4.4.5項「コンテンツ・サーバーでの権限の追加および編集」を参照してください。
(オプション)アカウントを使用します。5.5.2.1項「コンテンツ・サーバーでのアカウントの有効化」を参照してください。
外部ユーザーの詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプを参照してください。
ローカル・ユーザーは、コンテンツ・サーバー・インスタンス内で管理者によって定義されます。管理者はユーザーに1つ以上のロールを割り当て、これにより、ユーザーがセキュリティ・グループにアクセスできるようになります。
|
注意: ローカル・ユーザーはOracle WebLogic Serverドメインではサポートされません。Oracle WebCenter Content Server管理者はユーザー管理アプレットを使用してローカル・ユーザーを作成および構成できますが、コンテンツ・サーバー・インスタンスへのアクセスに対して認証されるローカル・ユーザーに対しては、ユーザーおよびパスワードもOracle WebLogic Server管理コンソールで作成することが必要です。11g リリース1(11.1.1)でサポートされるデフォルトのユーザー・タイプは外部ユーザーです。 |
次にローカル・ユーザーの一般的な特性を示します。
ログイン(認証)の作成: コンテンツ・サーバー・システムの管理者により作成されます。
アクセス(認証)の決定: セキュリティ・グループへのアクセスを提供する、コンテンツ・サーバーのロールにより決定されます。
ユーザー・ログイン: 管理サーバーはOracle WebLogic Server経由でのログインが必要なため、ローカル・ユーザーはコンテンツ・サーバー管理サーバーにログインできません。
ユーザー・パスワード: ユーザーはパスワードを変更できます。
インタフェースの問題: ユーザー名はコンテンツのチェックイン・リストに表示されます。ユーザーは、フルネーム、電子メール・アドレス、ユーザー・タイプを変更するかどうかを指定できます。
資格証明: 以前は1000またはそれ未満のユーザーに対して推奨されましたが、コンテンツ・サーバー・システムのトラブルシューティングなどの目的でシステム管理者により要求されるときのみの推奨になりました。パフォーマンス上の問題から、1000を超えるローカル・ユーザーを構成しないでください。
このプロセスに従ってローカル・ユーザーを設定します。
セキュリティ・グループを設定します。5.4.2.1項「コンテンツ・サーバーでのセキュリティ・グループの追加」を参照してください。
ロールを設定します。5.4.4.1項「コンテンツ・サーバーでのロールの作成」を参照してください。
権限を配置します。5.4.4.5項「コンテンツ・サーバーでの権限の追加および編集」を参照してください。
ユーザー・ログインを割り当てます。5.3.3.1章「ユーザー・ログインの追加」を参照してください。
(オプション)アカウントを使用します。5.5.2.1項「コンテンツ・サーバーでのアカウントの有効化」を参照してください。
ユーザー・ログインは、コンテンツ・サーバー・システムにアクセスするユーザーに関連付けられた名前です。11g リリース1(11.1.1)以降では、デフォルトでユーザー・ログインはWebCenter Contentおよびコンテンツ・サーバー・インスタンスをホストするOracle WebLogic Serverドメインに作成されます。認証および資格証明は、デフォルトではOracle WebLogic Serverユーザー・ストアで処理され、コンテンツ・サーバーによるかわりにセキュリティ・ソフトウェアに関連付けられます。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
|
注意: Oracle WebLogic Server管理コンソールを使用する手順は、Oracle WebLogic認証プロバイダのユーザーおよびグループにのみ適用されます。デフォルト・セキュリティ構成をカスタマイズしてカスタム認証プロバイダを使用している場合、ユーザーを作成するにはそのセキュリティ・プロバイダの管理ツールを使用します。Oracle WebLogic Server認証プロバイダにアップグレードする場合、既存のユーザーとグループをWebLogic認証プロバイダのデータベースにロードできます。『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のセキュリティ・データの移行に関する説明を参照してください。 |
|
注意: ユーザー・ログインは、ユーザー管理アプレットを使用してコンテンツ・サーバーで作成および管理できますが、Oracle WebLogic Server管理コンソールでも作成されるまで、認証目的にとって有効ではありません。 LDAPサーバーを使用して、コンテンツ・サーバー・システムでユーザー管理アプレットを使用して定義したローカル・ユーザーと同じ名前のユーザー・ログインを作成する場合、LDAPユーザーはログイン時にLDAPに対して認証されますが、ローカル・ユーザーに割り当てられたロールを受信します。 |
Oracle WebLogic Server管理者は、各ユーザーに1つ以上のグループを割り当てます。グループによって、セキュリティ・グループ内のファイルに対するアクセス権限がユーザーに付与されます。未定義のユーザーはゲスト・グループに割り当てられ、デフォルトで表示できるのはパブリック・セキュリティ・グループ内のドキュメントのみです。
ワークフロー、サブスクリプションおよびプロジェクトに、単一の名前またはエイリアスで参照できるユーザーのグループを作成することもできます。たとえば、user1、user2、user3、などを追加するよりも、Supportというエイリアスをワークフローに追加する方が簡単です。
異なるログイン方法(標準ログイン、Microsoftログインまたは自動登録ログインなど)で同じコンピュータ上の複数のブラウザ・ウィンドウにログインすると、それぞれのウィンドウにどのユーザーがログインしているかに関してコンテンツ・サーバーが混乱する可能性があります。異なるログイン方法のテスト中は、開いているブラウザ・ウィンドウを閉じてください。
|
重要: ユーザー・ログインでは、大文字と小文字が区別されます。 |
デフォルトでは、ユーザー・ログインはOracle WebLogic Server管理コンソールで作成され、管理されます。ユーザー・ログインの作成および管理の情報および手順については、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプを参照してください。デフォルト・セキュリティ構成をカスタマイズして、Oracle Internet Directoryなどの別の認証プロバイダを使用している場合、ユーザー・ログインを作成および管理するには、そのセキュリティ・プロバイダの管理ツールを使用します。
システム・プロパティなどのスタンドアロンのコンテンツ・サーバー・ユーティリティを使用するユーザー(コンテンツ・サーバー管理者以外)を設定する必要がある場合、コンテンツ・サーバー・システムのユーザー管理アプレットを使用してローカル・ユーザーを作成できます。ただし、ユーザー管理アプレットで作成したユーザーは、ユーザーがOracle WebLogic Server管理コンソールでも作成されないかぎり、スタンドアロンのコンテンツ・サーバー・ユーティリティ以外の機能に対しては認証されません。
この項の残りの部分では、スタンドアロン・ユーティリティ用のコンテンツ・サーバーのユーザー・ログイン管理にのみ関連するタスクについて説明します。
|
注意: 11g リリース1(11.1.1)からは、ユーザー・ログインはOracle WebLogic Server管理コンソールを使用して追加する必要があります。ユーザー・ログインは特別な目的のためにコンテンツ・サーバー・システムで管理できますが、Oracle WebLogic Server管理コンソールで作成されるまでは、コンテンツ・サーバー・システムへの認証に有効ではありません。これらのユーザー・ログインの作成および管理の情報および手順については、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプを参照してください。 |
コンテンツ・サーバーのスタンドアロン・ユーティリティでの使用にかぎりユーザー・ログインを追加するには、次の手順を実行します。
「ユーザー管理」画面: 「ユーザー」タブで、「追加」をクリックします。
メニューから「認可タイプ」を設定します。詳細は、5.3.1項「ユーザー・ログイン・タイプの概要」を参照してください。
「OK」をクリックします。
「ユーザーの追加/編集」画面が表示されます。
ユーザーに関する情報を入力します。
パスワードを入力した場合、「パスワードの確認」フィールドに同じパスワードを再入力する必要があります。
ユーザー名とパスワードでは、大文字と小文字が区別されます。
ロールをユーザーに割り当てます。
アカウントが有効化されている場合は、アカウントをユーザーに割り当てます。
「OK」をクリックします。
|
注意: 11g リリース1(11.1.1)からは、ユーザー・ログインはOracle WebLogic Server管理コンソールを使用して編集する必要があります。ユーザー・ログインは特別な目的のためにコンテンツ・サーバー・システムで管理できますが、Oracle WebLogic Server管理コンソールで作成されるまでは、コンテンツ・サーバー・システムへの認証に有効ではありません。ユーザー・ログインの編集および管理の情報および手順については、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプを参照してください。 |
コンテンツ・サーバーのスタンドアロン・ユーティリティでの使用にかぎりユーザー・ログインを編集するには、次の手順を実行します。
「ユーザー管理」画面の「ユーザー」タブで、ユーザー名をダブルクリックするか、ユーザー名を選択して「編集」をクリックします。
必要に応じてユーザー・ログインを編集します。
sysmanagerロールを持つユーザーのユーザー・ロケールを変更する場合は、管理サーバー・サービスを再起動して、そのユーザーのロケール言語で管理サーバー・インタフェースが表示されるようにする必要があります。
|
注意: 11g リリース1(11.1.1)からは、ユーザー・ログインはOracle WebLogic Server管理コンソールを使用して削除する必要があります。ユーザー・ログインは特別な目的のためにコンテンツ・サーバー・システムで管理できますが、Oracle WebLogic Server管理コンソールで作成されるまでは、コンテンツ・サーバー・システムへの認証に有効ではありません。ユーザー・ログインの削除および管理の情報および手順については、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプを参照してください。 |
コンテンツ・サーバーのスタンドアロン・ユーティリティでの使用にかぎりユーザー・ログインを削除するには、次の手順を実行します。
「ユーザー管理」画面の「ユーザー」タブで、ユーザー名を選択します。
「削除」をクリックします。
確認画面が表示されます。
「Yes」をクリックします。
ワークフローに関連するユーザーを削除した場合は、削除を確認するよう要求されます。ワークフローを調整し、ワークフロー・レビューアのリストからそのユーザーを削除する必要があります。
|
注意: 11g リリース1(11.1.1)からは、ユーザー・ログインはOracle WebLogic Server管理コンソールを使用して管理する必要があります。ユーザー・ログインは特別な目的のためにコンテンツ・サーバー・システムで管理できますが、Oracle WebLogic Server管理コンソールで作成されるまでは、コンテンツ・サーバー・システムへの認証に有効ではありません。ユーザー・ログインの作成および管理の情報および手順については、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプを参照してください。 |
コンテンツ・サーバーのスタンドアロン・ユーティリティでの使用にかぎりエイリアスを定義するには、次の手順を実行します。
「ユーザー管理」: 「エイリアス」タブを表示します。
「追加」をクリックします。
「新しいエイリアスの追加」/「エイリアスの編集」画面が表示されます。
「エイリアス名」フィールドに、ユーザーのグループを識別するための名前を入力します。
「説明」フィールドに、エイリアスの詳細な説明を入力します。
「追加」をクリックします。
「ユーザーの選択」画面が表示されます。
リストからユーザー名を選択します。
「ユーザーの選択」画面のユーザーのリストを絞り込むには、「フィルタの使用」を選択し、「フィルタの定義」をクリックしてフィルタ基準を選択し、「OK」をクリックします。
一連のユーザーを選択するには、1つのユーザー・ログインをクリックしてから、[Shift]キーを押しながら別のユーザー・ログインをクリックします。
ユーザーを個別に選択するには、[Ctrl]キーを押しながら各ユーザー・ログインをクリックします。
「OK」をクリックします。
「ユーザー管理」画面を閉じます。
|
注意: 11g リリース1(11.1.1)からは、ユーザー・ログインはOracle WebLogic Server管理コンソールで管理する必要があります。ユーザー・ログインは特別な目的のためにコンテンツ・サーバー・システムで管理できますが、Oracle WebLogic Server管理コンソールで作成されるまでは、コンテンツ・サーバー・システムへの認証に有効ではありません。ユーザー・ログインの編集および管理の情報および手順については、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプを参照してください。 |
コンテンツ・サーバーのスタンドアロン・ユーティリティでの使用にかぎりエイリアスを編集するには、次の手順を実行します。
「ユーザー管理」: 「エイリアス」タブを表示します。
エイリアスをハイライトして「編集」をクリックします。
「新しいエイリアスの追加」/「エイリアスの編集」画面が表示されます。
必要に応じて情報を変更します。
「説明」フィールドに、エイリアスの詳細な説明を入力します。
「OK」をクリックします。
「ユーザー管理」画面を閉じます。
|
注意: 11g リリース1(11.1.1)からは、ユーザー・ログインはOracle WebLogic Server管理コンソールで管理する必要があります。ユーザー・ログインは特別な目的のためにコンテンツ・サーバー・システムで管理できますが、Oracle WebLogic Server管理コンソールで作成されるまでは、コンテンツ・サーバー・システムへの認証に有効ではありません。ユーザー・ログインの削除および管理の情報および手順については、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプを参照してください。 |
コンテンツ・サーバーのスタンドアロン・ユーティリティでの使用にかぎりエイリアスを削除するには、次の手順を実行します。
「新しいエイリアスの追加」/「エイリアスの編集」画面が表示されます。
削除するエイリアスを選択し、「削除」をクリックします。
削除の確認を要求する画面が表示されます。エントリを削除するには、「はい」をクリックし、保持するには「いいえ」をクリックします。
「ユーザー管理」画面を閉じます。
この項の内容は次のとおりです。
ユーザー情報では、フル・ネーム、パスワード、電子メール・アドレスなど、ユーザー固有の属性を定義します。ユーザー情報フィールドでは、メタデータ・フィールドでコンテンツ・アイテムを説明するのと同様にユーザーを説明します。ユーザー情報はコンテンツ・サーバー・データベースに格納され、ユーザーのソート、コンテンツ・サーバーWebページでのユーザー情報の表示、またはユーザー属性に基づいたWebページの表示のカスタマイズに使用できます。
次のユーザー情報のフィールドがシステムで事前定義されています。これらのフィールドの削除、およびフィールド名やタイプの変更はできません。
この項では、ユーザー情報フィールドの管理に関連するタスクについて説明します。
新しいユーザー情報フィールドを追加するには:
「ユーザー管理」画面: 「情報フィールド」タブで、「追加」をクリックします。
「メタデータ・フィールド名の追加」画面が表示されます。
新しいフィールド名を入力します。重複する名前は使用できません。最大フィールド長は29文字です。次の文字は使用できません。空白、タブ、行送り、改行および ^ ? : @ & + " # % < * ~ |
「OK」をクリックします。
「メタデータ・フィールドの編集」画面が表示されます。
フィールドのプロパティを構成し、「OK」をクリックします。
「データベース設計の更新」をクリックします。
「オプション・リスト・キー」を編集するには:
「メタデータ・フィールドの編集」画面で、「オプション・リストの有効化」を選択します。
「編集」をクリックします。
「オプション・リスト」画面が表示されます。
オプションの値を追加、編集または削除します。
各値は、別々の行に表示される必要があります。
空白の行は、オプション・リストで空白の値になります。
リストをソートするには、ソート・オプションを選択して「今すぐソートする」をクリックします。
「OK」をクリックします。
ユーザー情報フィールドを編集するには:
フィールドをダブルクリックするか、フィールドを選択して「編集」をクリックします。
「メタデータ・フィールドの編集」画面が表示されます。
オプションの値を追加、編集または削除します。
「OK」をクリックします。
この項の内容は次のとおりです。
セキュリティ・グループは、一意の名前でグループ化された一連のファイルです。コンテンツ・サーバー・リポジトリ内のすべてのファイルはセキュリティ・グループに属します。セキュリティ・グループへのアクセスは権限によって制御され、権限はコンテンツ・サーバー・システムのロールに割り当てられます。ロールはOracle WebLogic Serverで管理されるユーザーに割り当てられます。
ユーザーはOracle WebLogic Server管理コンソールを使用してグループに割り当てられます。ユーザーがコンテンツ・サーバー・インスタンスにログインすると、ユーザーのグループがコンテンツ・サーバーのロールにマップされます。@(アット)記号で始まるOracle WebLogic Serverユーザー・グループはコンテンツ・サーバー・アカウントにマップされます。
コンテンツ・サーバー・システムで認識されるOracle WebLogic Serverグループでは、正確に同じ名前のロールがコンテンツ・サーバー・システムに作成され、セキュリティ・グループに割り当てられる必要があります。これが行われていないと、ユーザーに割り当てられたOracle WebLogic Serverグループは、コンテンツ・サーバー・システムでのユーザーの権限に何の影響も及ぼしません。
セキュリティ・グループを使用すると、コンテンツ・ファイルを特定のユーザーのみがアクセス可能な個別のグループに編成できます。たとえば、人事指定のドキュメントを表すHRDocsという名前のセキュリティ・グループにファイルを割り当て、このグループには人事部門で働く人のみがアクセスするようにできます。事前定義済みのセキュリティ・グループが2つあります。
セキュリティ・グループを定義するときには、次の考慮事項に注意してください。
セキュリティ・グループは、保護する必要のあるファイルがチェックされる前に定義してください。
検索およびユーザー管理の効率を最適化するために、セキュリティ・グループの数は最小限に維持する必要があります。セキュリティ・モデルに50を超えるセキュリティ分類が必要な場合は、アカウントを有効化し、それらを使用してユーザーの権限を制御する必要があります。この数は検索効率およびユーザー管理効率により異なります。
同じアクセスを共有するすべてのファイルを1つのセキュリティ・グループに含めます。
セキュリティ・グループに論理ネーミング規則を設定します。たとえば、イントラネットを設定している場合は部門名を使用し、エクストラネットを設定している場合にはセキュリティのレベル(内部や分類済みなど)を使用します。
たとえば、図5-1に3つの定義されたセキュリティ・グループを示します(Public、HRDocs、EngDocs)。これらは異なるロール(Admin、Contributor、Guest、Sysadmin、Subadmin)と特定の権限のセット(読取り、書込み、削除、管理者)に割り当てられた5ユーザーに関連付けられています。
セキュリティ・グループおよびロールに関するユーザー・アクセス設定は、システム効率の次の内容に影響する可能性があります。
検索効率は、ユーザーがアクセス権を持つセキュリティ・グループの数に影響されます。ユーザーが表示権限を持つコンテンツのみを戻すには、データベースのWHERE句にセキュリティ・グループのリストを含めます。WHERE句には、ユーザーがアクセス権を持っているすべてのセキュリティ・グループ、アクセス権を持っていないすべてのセキュリティ・グループを含めます。どちらの方法にするかは、ユーザーの持っている権限が、定義されているセキュリティ・グループの50%を超えているかまたは50%に満たないかにより異なります。
たとえば、100のセキュリティ・グループが定義されていて、ユーザーが10のセキュリティ・グループの権限を持っている場合は、WHERE句に10のセキュリティ・グループを含めます。反対に、ユーザーが90のセキュリティ・グループのアクセス権を持っている場合は、そのユーザーがアクセス権を持っていない10のセキュリティ・グループをWHERE句に含めます。
そのため、ユーザーが50%に近いセキュリティ・グループに対する権限を持っている場合、検索効率は低下します。ユーザーがすべてのセキュリティ・グループに対する権限を持っている場合、またはどのセキュリティ・グループに対する権限も持っていない場合は、検索効率が向上します。
セキュリティ・グループの合計数にロールの合計数を掛けた数が、RoleDefinitionデータベース表の行数になります。この数は、ユーザー管理アプリケーションのローカル・ユーザーに関連する作業効率に影響します。ユーザー管理アプリケーションにおける、セキュリティ・グループの追加やロールの権限の変更などの操作の実行に必要な概算の時間を判断するには、次の式を使用します。
(# of security groups) X (# of roles) / 1000 = Time of operation in seconds
たとえば、400 MHzプロセッサと128 MBのRAMを備えたPCを使用すると、RoleDefinition表に10,000行ある場合、ユーザー管理アプリケーションを使用したセキュリティ・グループまたはロール(あるいはその両方)の追加には約10秒かかります。
セキュリティ・グループの数が増加すると、使用者の検索効率よりも管理効率が影響を受けます。
コンテンツ・サーバー・システムを使用して、次のタスクによりセキュリティ・グループを管理します。
グループ管理の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』を参照してください。
セキュリティ・グループを作成し権限を割り当てるには:
「ユーザー管理」画面で「セキュリティ」、「グループの権限」の順に選択します。
「グループの権限」画面が表示されます。
「グループの追加」をクリックして、「新しいグループの追加」画面を表示します。
グループ名および摘要を入力します。
「OK」をクリックします。
セキュリティ・グループに権限を設定します。
セキュリティ・グループを選択します。
編集するロールを選択します。
「アクセス権の編集」をクリックします。
グループのロールに必要な権限を有効化したら、「OK」をクリックして、「グループの権限」画面を閉じます。
|
注意: コンテンツ・サーバー・リポジトリに格納されたコンテンツ・アイテムと関連付けられているセキュリティ・グループまたはアカウントは、絶対に削除しないでください。 |
セキュリティ・グループを削除するには:
削除するセキュリティ・グループにコンテンツ・アイテムが関連付けられていないことを確認します。コンテンツが存在しているセキュリティ・グループを削除することはできません。
「ユーザー管理」画面で「セキュリティ」、「グループの権限」の順に選択します。
「グループの権限」画面が表示されます。
削除するグループを選択します。
「グループの削除」をクリックします。
確認画面が表示されます。
「Yes」をクリックします。
セキュリティ・グループが削除されます。
セキュリティ・グループを削除したら、「OK」をクリックして、「グループの権限」画面を閉じます。
ロールは、各セキュリティ・グループに対する一連の権限(読取り、書込み、削除、管理者)です。ロールはユーザーのジョブと考えられます。ユーザーは、様々なセキュリティ・グループに対して異なるジョブを持つことができます。ユーザーは参加する様々なチームを識別するために、異なるジョブを持つこともできます。次のことを実行できます。
ロールを定義します。
1人のユーザーに複数のロールを割り当てます。
複数のユーザーで1つのロールを共有するよう設定します。
ロールの権限を複数のセキュリティ・グループに設定できます。
たとえば、図5-2に、3つのロールと、そのロールが同じセキュリティ・グループに対して持つ権限を示します。
ロールは、セキュリティ・グループにアクセス権を提供するためにシステム管理者によって1人以上のユーザーに割り当てられます。図5-3に、HRDocsセキュリティ・グループに対して読取り権限のみを持つEngUsersロールを示します。ただし、このロールは、EngDocsセキュリティ・グループに対して読取り、書込みおよび削除権限も持っています。これにより、セキュリティが強化され、特定のドキュメントにアクセスする必要のあるユーザーのみがそれらのドキュメントを変更できるようになります。
次のロールがコンテンツ・サーバー・システムで事前定義されています。
| ロール | 説明 |
|---|---|
|
adminロールはシステム管理者に割り当てられます。デフォルトでは、このロールには、すべてのセキュリティ・グループおよびすべてのアカウントに対する管理権限があり、すべての管理ツールにアクセスできます。 |
|
|
contributorロールには、パブリック・セキュリティ・グループに対する読取りおよび書込みの権限があり、コンテンツを検索、表示、チェックインおよびチェックアウトできます。 |
|
|
guestロールには、パブリック・セキュリティ・グループに対する読取り権限があり、コンテンツを検索および表示できます。 |
|
|
sysmanagerロールには、コンテンツ・サーバー・システムの管理サーバーへアクセスできる権限があります。 |
各ロールでは、各セキュリティ・グループに対して、読取り(R)、書込み(W)、削除(D)または管理者(A)の各権限が許可されます。セキュリティ・グループのファイルにアクセスするためにユーザーが持つ権限は、任意のユーザーのロールにより定義されている最高の権限です。ユーザーにguestロールとcontributorロールがあり、guestにはパブリック・セキュリティ・グループに対する読取り権限、contributorには書込み権限が付与されている場合、そのユーザーがパブリック・セキュリティ・グループのコンテンツに対して持つのは書込み権限です。
図5-4に示すように、Joe SmithおよびAnn Wallaceは2つのセキュリティ・グループに対する権限を持っています。
Joe Smithには、EngDocsセキュリティ・グループに対して読取り、書込みおよび削除権限を持っていますが、HRDocsセキュリティ・グループに対しては読取り権限のみを持っています。EngUsersロールのメンバーとして、エンジニアリング・ドキュメントには読取り、書込みおよび削除のアクセス権が付与されていますが、人事ドキュメントには読取りアクセス権のみが付与されています。
Ann Wallaceは、HRDocsセキュリティ・グループに対して読取り、書込みおよび削除権限を持っていますが、EngDocsセキュリティ・グループに対しては読取り権限のみを持っています。HRUsersロールのメンバーとして、人事ドキュメントには読取り、書込みおよび削除のアクセス権が付与されていますが、エンジニアリング・ドキュメントには読取りアクセス権のみが付与されています。
各ロールには、各セキュリティ・グループに対して次の各権限を割り当てることができます。
| 権限 | 説明 |
|---|---|
|
セキュリティ・グループ内のドキュメントを表示できます。 |
|
|
セキュリティ・グループ内のドキュメントを表示、チェックイン、チェックアウトおよびコピーできます。作成者がドキュメントのセキュリティ・グループの設定を変更できるのは、新しいセキュリティ・グループで書込み権限がある場合です。 |
|
|
セキュリティ・グループ内のドキュメントを表示、チェックイン、チェックアウト、コピーおよび削除できます。構成設定 |
|
|
セキュリティ・グループ内のファイルを表示、チェックイン、チェックアウト、コピーおよび削除できます。ワークフロー権限があるユーザーは、そのセキュリティ・グループ内のワークフローを開始または編集できます。 該当するセキュリティ・グループ内にある、別のユーザーが作成者として指定されているドキュメントをチェックインすることもできます。ドキュメントの作成者以外のユーザーがドキュメントのセキュリティ・グループの設定を変更できるのは、新しいセキュリティ・グループで書込み権限がある場合です。 |
ロールおよび権限はコンテンツ・サーバー・システムで定義および管理されます。ロールはユーザー・ログインに割り当てられ、デフォルトで、Oracle WebLogic Server管理コンソールで管理されます。
次のタスクを使用してユーザー・ロールを管理します。
コンテンツ・サーバー・システムでロールを作成し、権限を構成するには、次の手順を実行します。
「ユーザー管理」画面で「セキュリティ」、「ロールの権限」の順に選択します。
「ロールの権限」画面が表示されます。
「新しいロールの追加」をクリックします。
「新しいロールの追加」画面が表示されます。
ロール名を入力します。
次のようにロールに権限を設定します。
ロールを選択します。
編集するセキュリティ・グループを選択します。
「アクセス権の編集」をクリックします。
権限を編集します。
「OK」をクリックして、「ロールの権限」画面を閉じます。
コンテンツ・サーバー・システムでロールを削除するには、次の手順を実行します。
削除するロールにユーザーが割り当てられていないことを確認します(ロールにユーザーが割り当てられている場合は、そのロールを削除できません)。
「ユーザー管理」画面で「セキュリティ」、「ロールの権限」の順に選択します。
「ロールの権限」画面が表示されます。
削除するロールを選択します。
「ロールの削除」をクリックします。
確認画面が表示されます。
「Yes」をクリックします。
コンテンツ・サーバー・システムのユーザーにロールを割り当てるには、Oracle WebLogic Server管理コンソールを使用します。ロールはコンテンツ・サーバーで定義されますが、管理コンソールを使用してユーザーに割り当てる必要があります。
ユーザーはOracle WebLogic Server管理コンソールを使用してグループに割り当てることができます。コンテンツ・サーバー・システムで認識されるOracle WebLogic Serverグループでは、正確に同じ名前のロールがコンテンツ・サーバー・システムに作成され、セキュリティ・グループに割り当てられる必要があります。
別のユーザー・ログインと類似のアクセス権を持つ、コンテンツ・サーバー・システムのユーザーを作成するときにロールを割り当てるには、Oracle WebLogic Server管理コンソールを使用します。ロールはコンテンツ・サーバー・システムで定義されますが、管理コンソールを使用してユーザーに割り当てる必要があります。
ユーザーはOracle WebLogic Server管理コンソールを使用してグループに割り当てることができます。コンテンツ・サーバー・システムで認識されるOracle WebLogic Serverグループでは、正確に同じ名前のロールがコンテンツ・サーバー・システムに作成され、セキュリティ・グループに割り当てられる必要があります。
コンテンツ・サーバー・システムでロールに権限を追加するか、または既存の権限を編集するには、次の手順を実行します。
「ユーザー管理」画面で「セキュリティ」、「ロールの権限」の順に選択します。
「ロールの権限」画面が表示されます。
既存のロールを選択するか、新しいロールを追加します。
セキュリティ・グループに関連付けられた権限が表示されます。
「グループ/権限」列でアイテムを選択します。
「アクセス権の編集」をクリックします。
「アクセス権の編集」画面が表示されます。
このロールおよびセキュリティ・グループに関連付ける権限を指定します。5.4.3.3項「事前定義済みの権限」を参照してください。
「OK」をクリックします。
アカウントはコンテンツ・サーバー・システムで定義および管理されます。アカウントの権限はOracle WebLogic Server管理コンソールを使用してユーザー・ログインに割り当てられます。
この項の内容は次のとおりです。
アカウントを使用すると、セキュリティ・グループのみの場合よりも、セキュリティ構造の柔軟性と精度が向上します。アカウントとアカウントの権限は、Oracle WebLogic Server管理コンソールを使用してユーザーに割り当てられ、グループはサーバーによりコンテンツ・サーバーのロールおよびアカウントにマップされます。アカウントは各コンテンツ・アイテムにも割り当てることができます。アカウントが割り当てられたコンテンツ・アイテムにアクセスするには、そのアカウントに対する適切な権限を持っている必要があります。
@(アット)記号で始まるOracle WebLogic Serverユーザー・グループはコンテンツ・サーバー・アカウントにマップされます。
|
注意: アカウントを有効化して使用し、その後アカウントを無効化すると、データを損失する場合があります。リポジトリは変更されません。ただし、セキュリティ・モデルに特定の変更を行う場合、セキュア・コンテンツへのアクセスを継続できるように、ユーザーのアクセス権を更新する必要もあります。 この状況を避けるため、要件と、グループおよびアカウントのWebCenter Contentセキュリティ・モデルについて調査して、要件に最適なのは何かを判断します。確実に使用する必要がある場合以外は、アカウントを有効化しないでください。 |
アカウントの作成方法はいくつかあります。
システム管理者による、ユーザー管理ツールを使用した事前定義済みのアカウントの作成。5.5.2.2項「コンテンツ・サーバーでの事前定義済のアカウントの作成」を参照してください。
ユーザー管理者による、コンテンツのチェックイン時におけるアカウントの作成。5.5.2.3項「コンテンツ・サーバーでのコンテンツのチェックイン時のアカウントの作成」を参照してください。
使用するアカウントを有効化する必要があります。詳細は、5.5.2.1項「コンテンツ・サーバーでのアカウントの有効化」を参照してください。
アカウントを使用する場合、アカウントが、セキュリティ・グループ権限より優先されるプライマリ権限になります。特定のドキュメントへのユーザーのアクセスを、アカウント権限とセキュリティ・グループ権限の共通部分と考えることもできます。
たとえば、EngAdminロールには、EngDocsセキュリティ・グループ内のすべてのコンテンツに対する読取り、書込み、削除および管理権限があるとします。ユーザーはEngAdminロールに割り当てられ、AcmeProjectアカウントに対する読取りおよび書込み権限も割り当てられます。その結果、ユーザーは、EngDocsセキュリティ・グループとAcmeProjectアカウント内のコンテンツ・アイテムに対する読取りおよび書込み権限のみを持ちます。
図5-5に、AcmeProjectアカウント権限とEngDocsセキュリティ・グループ権限の共通部分を示します。
アカウントで任意のコンテンツへのアクセスが許可されていない場合、セキュリティ・グループ権限は無視されます。アカウントは、ユーザーのロールによって定義された権限より優先されるフィルタとして機能します。
アカウントは階層構造に設定することができ、これにより、一部のユーザーには構造のブランチ全体に対するアクセス権を付与する一方で、構造の下位レベルのアカウントを割り当てることによりその他のユーザーの権限を制限できます。図5-6に、典型的な階層アカウント構造を示します。
|
重要: アカウント名は、コンテンツ・アイテムのURLのディレクトリ・パスの一部を形成するため、30文字を超えることはできません。 |
アカウント名のレベルを区切るためにスラッシュを使用すると(Eng/Acme/Budgetなど)、コンテンツ・サーバー・システムによりアカウント構造に応じてWebレイアウト・ディレクトリ構造が作成されます(ただし、実際の各ディレクトリは、チェックイン・プロセス中にコンテンツ・アイテムがアカウントに割り当てられるまで作成されません)。アカウント名の各下位レベルは、そのディレクトリがアカウント・レベルであることを示す@記号接頭辞付きの上位レベルのサブディレクトリになります。
組込みLDAPサーバーを使用している場合は、スラッシュを使用しないでください。WebLogic 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を超えないようにしてください。
セキュリティ・グループおよびアカウントには、比較的短い名前を付けるようにしてください。
次のタスクがアカウントの管理に含まれます。
コンテンツ・サーバー・システムでアカウントを有効化するには、次の手順を実行します。
|
重要: アカウントを有効化して使用し、その後アカウントを無効化すると、データを損失する場合があります。リポジトリは変更されません。ただし、セキュリティ・モデルに特定の変更を行う場合、コンテンツへのアクセスを継続できるように、ユーザーのセキュリティの設定を更新する必要もあります。 |
コンテンツ・サーバー・ポータルで、「管理」、「管理サーバー」の順に選択します。
「管理サーバー」ページで、「一般構成」を選択します。
「一般構成」ページで「アカウントの有効化」 を選択して、アカウントを有効化します。
変更を保存します。
Oracle WebCenter Content Serverインスタンスを再起動します。
または、「管理サーバー」から「一般構成」ページでにアクセスし、IntradocDir/config/config.cfgファイルのコンテンツを示す、追加の構成変数フィールドに次の行を追加します。
UseAccounts=true
変更を保存して、コンテンツ・サーバー・インスタンスを再起動します。
コンテンツ・サーバー・システムで定義済アカウントを作成するには、次の手順を実行します。
「ユーザー管理」画面から、「セキュリティ」、「定義済アカウント」の順に選択します。
「定義済アカウント」画面が表示されます。
「追加」をクリックします。
「新しい定義済アカウントの追加」画面が表示されます。
新規アカウントの名前を追加します。名前は簡潔で一貫性のあるものにします。たとえば、場所や部門による3文字の略語(MSP、NYCなど)を使用してすべてのアカウントを設定します。アカウント名は30以内にする必要があり、空白、タブ、行送り、改行および; ^ ? : & + " # % < > * ~の記号は使用できません。
「OK」をクリックします。
すでにコンテンツ・サーバー・システムにコンテンツがチェックインされていて、フルテキスト索引付けのデータベースを使用している場合は、検索索引を再作成します。
メタデータ・データベースの検索インデクサ・エンジンのみを使用している場合は、検索索引を再作成する必要はありません。
一般的に、コンテンツのチェックイン時にアカウントを作成するのではなく、事前定義済みのアカウントを作成する必要があります。5.5.2.2項「コンテンツ・サーバーでの事前定義済のアカウントの作成」を参照してください。
コンテンツ・アイテムのチェックイン時にアカウントを作成するには、ユーザー管理権限が必要で、次のタスクを実行する必要があります。
「コンテンツ・チェックイン・フォーム」ページを表示します。
必須およびオプションの情報をすべて入力します。
「アカウント名」フィールドにアカウント名を入力します。
「チェックイン」をクリックします。
コンテンツ・アイテムに新規アカウントが割り当てられます。
|
注意: コンテンツ・サーバー・リポジトリに格納されたコンテンツ・アイテムと関連付けられているアカウントは、絶対に削除しないでください。 |
コンテンツ・サーバー・システムで定義済アカウントを削除するには、次の手順を実行します。
「セキュリティ」、「定義済アカウント」の順に選択します。
「定義済アカウント」画面が表示されます。
削除するアカウントを選択します。
「削除」をクリックします。
アカウントが即時に削除されます。
アカウントを含むコンテンツが存在する場合にもアカウントを削除できます。アカウント値はコンテンツ・アイテムに割り当てられたままですが、ユーザー定義のアカウントとみなされるようになります。
アカウントをユーザーに割り当てるには、Oracle WebLogic Server管理コンソールを使用してグループを作成し、それを1つまたは複数のユーザーに割り当てます。グループ名は@記号で始まり、アンダースコアで区切られた権限で終わる必要があります。次の例は、testaccountという名前のグループを作成し、それに読取り、書込みおよび削除権限を割り当てたものです(@testaccount_RWD)。JpsUserProviderを変更して、「アカウント権限のデリミタ」フィールドにアンダースコアが使用されていることを確認する必要もあります。詳細は、4.5.1.2.6項「JpsUserProviderの使用が必要な状況」を参照してください。
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 |
|
X |
|
|
|
PublicContributor |
X |
|
X |
X |
|
InternalConsumer |
|
X |
|
|
|
InternalContributor |
X |
|
X |
X |
|
SensitiveConsumer |
|
|
|
|
|
SensitiveContributor |
X |
|
X |
X |
|
ClassifiedConsumer |
|
|
|
|
|
ClassifiedContributor |
X |
|
X |
X |
コンテンツ・サーバー・システムは、標準のコンテンツ・サーバー・セキュリティ・ロール、セキュリティ・グループおよびアカウントの他に、アクセス制御リスト(ACL)をサポートするように構成できます。アクセス制御リストは、ユーザー、グループまたはエンタープライズ・ロールのリストであり、コンテンツ・アイテムに対するアクセス権限または操作権限が指定されています。
アクセス制御リスト・セキュリティの構成時に、コンテンツ・アイテムのチェックイン、更新または検索などのインタフェースのいくつかの場所で、次の3つの新規フィールドを使用できます。フィールドは次のとおりです。
ユーザー・アクセス・リスト
グループ・アクセス・リスト
ロール・アクセス・リスト
アクセス制御リストのセキュリティ機能がコンテンツ・サーバー・システムに構成されると、Oracle WebLogic Serverドメインとともに動作する、Oracle Access Manager(OAM)Authenticationプロバイダを含む、Oracle Platform Security Services(OPSS)を使用してアクセス制御リストを管理できます。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』および『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』を参照してください。
コンテンツ・サーバーのアクセス制御リストはOracle Secure Enterprise Searchでサポートされ、ユーザーはアクセス制御リストの情報を使用して検索を実行できます。詳細は、7.2項「Oracle Secure Enterprise Search」を参照してください。
|
注意: RoleEntityACLコンポーネントをOracle WebCenter Content: Recordsとともに使用している場合、このコンポーネントは、カテゴリやレコード・フォルダなどの保存オブジェクトには影響しません。したがって、RecordsロールでACLを使用する機能は、RoleEntityACLコンポーネントが有効であっても、カテゴリ作成ページまたはフォルダ作成ページでは無効化されています。ただし、ロールACL機能は、コンテンツのチェックイン・ページでは有効になっています。 |
|
注意: Need to Know(NtkDocDisclosure、NTK)コンポーネントはコンテンツ・サーバー・セキュリティのカスタマイズをサポートしますが、セキュリティ・モデルと競合するため、アクセス制御リストとともには動作できません。 詳細は、付録B「Need to Knowコンポーネント」を参照してください。 |
アクセス制御リスト(ACL)を設定するには、次に示すコンテンツ・サーバー・システムのアイテムを構成します。
ユーザーおよびグループのアクセス制御リストをサポートするには、次の構成変数がコンテンツ・サーバーのconfig.cfgファイルで設定されている必要があります。
UseEntitySecurity: この変数をtrueに設定します。
SpecialAuthGroups: この変数を、ACLセキュリティを使用するOracle WebCenter Content Serverセキュリティ・グループの名前に設定します。初期状態のコンテンツ・サーバーのセキュリティ・グループは、「Public」と「Secure」の2つのみです。通常、サイトでは、ACLセキュリティが適用される3番目のセキュリティ・グループが作成されます。
「一般構成」画面の「追加の構成変数」フィールドに変数を入力します(コンテンツ・サーバー・インスタンスの「管理サーバー」画面からアクセスできます)。詳細は、A.1.2.1.2項「管理サーバー: 「一般構成」ページ」を参照してください。
構成変数UseEntitySecurity=trueは、コンテンツ・サーバーのセキュリティを、ユーザーおよびグループのアクセス制御リストのコンテンツ・アイテムを常に評価するように設定します。このパラメータは2つのメタデータ・フィールド、xClbraUserListおよびxClbraAliasListを作成します。
エンタープライズ・ロールのアクセス制御リストをサポートするには、RoleEntityACLコンポーネントがコンテンツ・サーバー・システムで有効にされる必要があります。
このコンポーネントはデフォルトでコンテンツ・サーバー・システムにインストールされ、無効化されています。コンテンツ・サーバー拡張コンポーネント・マネージャを使用してこのコンポーネントを有効化します。詳細は、A.3.6項「「拡張コンポーネント・マネージャ」ページ」を参照してください。
RoleEntityACLコンポーネントは、コンテンツ・サーバー・システムを、別のアプリケーションと連携してエンタープライズ・ロールのアクセス制御リストを評価するように構成します。このコンポーネントはUseRoleSecurityパラメータをオンにして、コンテンツ・サーバー・セキュリティが、コンテンツ・アイテムに対するエンタープライズ・ロールのアクセス・リストの情報を統合するように設定します。UseRoleSecurityパラメータはxClbraRoleListメタデータ・フィールドを作成します。
コンテンツ・アイテムのチェックイン時に、管理者ではないユーザーに「ユーザーの追加」メニューを使用して「ユーザー・アクセス・リスト」でユーザーを選択できるようにする場合は、構成変数 AllowQuerySafeUserColumns=trueを設定します。この変数が設定されていないと、「ユーザー・アクセス・リスト」フィールドのメニューに値が表示されません。
アクセス制御リストは3つのメタデータ・フィールド、xClbraUserList、xClbraAliasListおよびxClbraRoleListの値に基づき処理されます。メタデータ値がユーザー、グループまたはエンタープライズ・ロール名およびコンテンツ・アイテムへの権限により移入される場合、コンテンツ・アイテムでの検索または動作がどのユーザー、グループまたはエンタープライズ・ロールに許可されるのかに影響します。
これらのメタデータ・フィールドはユーザー・アクセス・リスト、グループ・アクセス・リストおよびロール・アクセス・リスト・フィールドから移入され、コンテンツ・アイテムのチェックイン、更新、および拡張フォームを使用した検索の実行時に、表示またはアクセスできます。
管理者はスクリプトを使用して、アクセス・リストのメタデータ・フィールドに移入する値を指定できます。
xClbraUserListメタデータ・フィールドを使用して、コンテンツ・アイテムに対するユーザーとその権限を指定します。
次のリストでは、管理者がスクリプトにxClbraUserList 値を指定する要件について説明します。
各ユーザー名の前にアンド記号(&)が付きます。
ユーザー名の後に各ユーザーの権限がカッコで囲われて続きます。
ユーザー名はカンマで区切られます。
例: xClbraUserList=&sysadmin(RWDA),&user1(RW),&guest(R)
xClbraAliasListメタデータ・フィールドを使用して、コンテンツ・アイテムに対するグループとその権限を指定します。
|
注意: コンテンツ・サーバー・システムでは、エイリアスを使用してユーザーのグループ(LDAPグループとは異なる)を指定できます。ACLでは、エイリアス・アクセス・リストの実装を呼び出す代わりに、グループ・アクセス・リストが呼び出されます。ただし、メタデータ・フィールド名はエイリアスという用語を使用します。 |
次のリストでは、管理者がスクリプトにxClbraAliasList値を指定する要件について説明します。
各グループ名の前にはアット記号(@)が付きます。
グループ名の後に各グループの権限がカッコで囲われて続きます。
グループ名はカンマで区切られます。
例: xClbraAliasList=@Mktg(RWDA),@Mktg_ext(RW)
アクセス制御リストの権限により、ユーザー、グループ、またはエンタープライズ・ロールのコンテンツ・アイテムに対するアクセス権のタイプが決まります。次の権限を付与できます。
| 権限 | 説明 |
|---|---|
|
読取り(R) |
コンテンツ・アイテムを表示できます。 |
|
書込み(W) |
コンテンツ・アイテムを表示、チェックイン、チェックアウト、更新およびコピーできます。 |
|
削除(D) |
コンテンツ・アイテムを表示、チェックイン、チェックアウト、更新、コピーおよび削除できます。 |
|
管理(A) |
コンテンツ・アイテムを表示、チェックイン、チェックアウト、更新、コピーおよび削除でき、「作成者」の指定とは別のユーザーでコンテンツ・アイテムをチェックインできます。 |
|
注意: アクセス制御リストの権限はコンテンツ・サーバーのadminロールのユーザーには適用されません。 |
アクセス制御リストをコンテンツ・アイテムと関連付けるには、コンテンツ・アイテムのチェックインまたは更新時に、1つまたは複数のユーザー、グループまたはエンタープライズ・ロールを追加します。アクセス・リストに追加する各ユーザー、グループまたはロールに対し、適切な権限である読取り(R)、書込み(W)、削除(D)または管理(A)を割り当てます。アクセス制御リストの権限レベルは、コンテンツ・サーバーのセキュリティ・グループおよびアカウントに対して定義されたものと同じです。ユーザーがいずれかのアクセス・リストに追加されると、そのユーザーはコンテンツ・アイテムへアクセスする指定した権限を持ちます。
特定の権限が付与されたユーザーに対し、すくなくとも次のいずれかが当てはまる必要があります。
ユーザー名がxClbraUserListメタデータ・フィールドに適切な権限とともに表示されている。
ユーザーがxClbraAliasListメタデータ・フィールドに適切な権限とともに表示されているグループに属している。
ユーザーがxClbraRoleListメタデータ・フィールドに適切な権限とともに表示されているエンタープライズ・ロールの一部である。
アクセス制御リストの権限は累積です。書込みを割り当てると、自動的に読取りが割り当てられます。管理者を割り当てると、読取り、書込みおよび削除が自動的に割り当てられます。ただし、ユーザーはコンテンツ・サーバーのセキュリティ・グループおよびアカウント(アカウントが有効な場合)経由でのアクセスのセキュリティ基準も満たしている必要があります。これらのセキュリティ基準が特定の権限を拒否する場合、ユーザーはコンテンツ・アイテムへの権限を持たなくなります。
すべてのユーザー・アクセス・リスト、グループ・アクセス・リストおよびロール・アクセス・リスト・フィールドが空の場合、デフォルトで権限がすべてのユーザーに付与されます。ユーザー・アクセス・リストおよびグループ・アクセス・リスト・フィールドだけが空白の場合(およびRoleEntityACLコンポーネントが有効化されていないためにロール・アクセス・リストが存在しない場合)、権限がすべてのユーザーに付与されます。この動作は、デフォルトでtrueに設定される、AccessListPrivilegesGrantedWhenEmpty変数により構成されます。
AccessListPrivilegesGrantedWhenEmpty変数がfalseに設定されている場合、すべてのアクセス制御リストが空白だと、権限はadminロールを除くすべてのユーザーに対して拒否されます。adminロールを付与されていないユーザーがドキュメントをチェックインできるようにするには、読取り/書込み(RW)権限を含むアクセス制御リストのロール(testroleなど)がユーザーに付与されており、ドキュメントのチェックイン時にこのロールを指定する必要があります。
|
注意: コンテンツ・サーバー・インスタンスがリリース10gからアップグレードされた場合、空のアクセス制御リストは、リリース11gでは異なった動作をすることに注意してください。リリース10gおよびそれ以前では、 |
JpsUserProviderプロバイダは、Oracle WebLogic Server管理コンソールで管理されるユーザー情報および資格証明と通信するための、コンテンツ・サーバー・インスタンスのデフォルトのプロバイダです。WebCenter Contentおよびコンテンツ・サーバー・インスタンスの場合、JpsUserProviderを使用することをお薦めします。詳細は、4.5.1.2.6項「JpsUserProviderの使用が必要な状況」を参照してください。
サイトがコンテンツ・サーバー・ソフトウェアの以前のリリースからアップグレードしている場合、またActive Directory、LDAPまたはActive DirectoryとLDAPを使用している場合、これらのプロバイダに関する情報は、リリース10gR3ドキュメントセキュリティおよびユーザー・アクセスの管理で参照できます。JpsUserProviderを使用するようにサイトをアップグレードすることをお薦めします。
この項では、コンテンツ・サーバー・システムの追加のセキュリティ通信接続オプションについて説明します。内容は次のとおりです。
プロキシ接続、またはコンテンツ・サーバー・インスタンス間の接続を使用すると、次の機能により、コンテンツ・サーバー・システムのセキュリティ・レベルが向上します。
あるコンテンツ・サーバー・インスタンスから別のコンテンツ・サーバー・インスタンスへのセキュリティ資格証明マッピング
コンテンツ・サーバー・インスタンスへのセキュアな名前付きパスワード接続(パスワードで保護されたプロバイダ接続)
コンテンツ・サーバー・インスタンス間のHTTPプロトコルによる通信
名前付きパスワード接続とHTTPベースのコンテンツ・サーバー接続の両方が使用できますが、多くの場合、どちらかのタイプの接続を使用する方が便利です。どちらのタイプの接続でも、資格証明マッピングによりセキュリティが向上します。
|
注意: 1つのサイトに複数のContent Serverインスタンスが存在できますが、各Content Serverインスタンスはその固有のOracle WebLogic Serverドメインにインストールされる必要があります。 |
プロキシ接続コンポーネントはデフォルトでコンテンツ・サーバー・ソフトウェアを使用してインストールされ、有効化されます。プロキシ接続コンポーネントの通常の使用方法には、次のものが含まれます。
HTTPまたはHTTPSを介してコンテンツ・アイテムのアーカイブ・レプリケーションの実行を可能にするため。たとえば、ある企業が別の企業買収したが、情報を共有するための共通のインフラストラクチャがないとします。どちらの企業もSecure Sockets Layer(SSL)接続を使用してインターネットに接続しています。この企業で、2つのサイト間のコンテンツを共有するとします。プロキシ接続を使用してこの企業のサーバー間にセキュアなインターネット接続を設定できるため、コンテンツには一方のサイトから安全にアクセスでき、もう一方のサイトでレプリケートおよびアーカイブできます。
ターゲット・プロキシ接続に対して名前付きパスワードを使用することにより、コンテンツ・サーバー・インスタンスへのアクセス制限を向上させるため。たとえば、ある企業が、1つのコンテンツ・サーバー・インスタンスから別のコンテンツ・サーバー・インスタンスへの接続に追加のセキュリティを適用するとします。名前付きパスワードを使用すると、受信接続によるアクセスを、管理者はプロキシ接続および名前付きパスワードが事前に設定されている接続に制限できます。
資格証明マップは、コンテンツ・サーバー・インスタンスにより使用される資格証明の、リモート・システムで使用される資格証明へのマッピングであり、これにより、そのシステムでの指定されたリソースへの接続方法がコンテンツ・サーバー・インスタンスに通知されます。管理者はユーザー、ロールおよびアカウントに複数の資格証明マップを作成できます。資格証明マッピングは、プロキシのシナリオで有用な場合があります。たとえば、あるContent Serverインスタンスで作成されたユーザー、ロールまたはアカウントの資格証明を、別のContent Serverインスタンスのユーザー、ロールまたはアカウントにマップできるため、ユーザーは、1つまたは複数のContent Serverインスタンスの情報への制御されたアクセスを許可されます。
この項の内容は次のとおりです。
資格証明マップを作成する際には、マップの一意識別子、およびユーザー、ロールやアカウントの固有の資格証明値を入力します。プロキシ接続では、ユーザー資格証明が入力値に一致すると、出力値で指定した資格証明がユーザーに付与されます。ユーザー資格証明は次の順序で評価されます。
すべてのロール
すべてのアカウント
ユーザー名
変換の実行後、ユーザーは入力値から正常にマップされた属性値のみを持ちます。
資格証明マップを作成したら、送信プロバイダの構成時に、名前付きパスワード接続とともに資格証明マップを指定できます。ユーザー・プロバイダ(LDAPなど)の構成時にも資格証明マップを指定できます。
LDAPプロバイダのデフォルトの動作では、guestロールは自動的にユーザーに割り当てられません。
資格証明マッピングの実装は、WebCenter ContentのWebサーバー・プラグインで複製されます。最適なパフォーマンスを実現するために設計および実装されているため、マッピングでの変更はすぐに適用されます(変更内容はキャッシュされ、最大で2、3分間はコンテンツ・サーバー・インスタンスに反映されない、NTやNT管理者インタフェースを使用するADSIユーザー記憶域のパフォーマンスと比較できます)。
|
注意: コンテンツ・サーバー・インスタンス以外の資格証明マッピングの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』の資格証明マッピング・プロバイダに関する説明を参照してください。 |
ロールまたはユーザー名の場合、資格証明の入力値は、完全一致である場合に一致します。入力アカウント値は、フィルタの場合を除き、いずれかのユーザー・アカウントに接頭辞がある場合に一致します(5.8.2.3項「アカウントおよびロールの一致」を参照してください)。たとえば、次の資格証明値により、adminロールを持つすべてのユーザーがguestロールを持つユーザーに変更されます。
admin, guest
次の表に、資格証明値の基本的な構文を示します。
| 値 | 接頭辞または順序 | 例 |
|---|---|---|
|
ユーザー名 |
& |
&name |
|
ロール |
admin |
|
|
アカウント |
@ |
@marketing |
|
空のアカウント |
@#none |
@#none |
|
すべてのアカウント |
@#all |
@#all |
|
値を無視または値をコメントアウト |
# |
#comment |
資格証明マップが割り当てられていない場合は、どの資格証明がデフォルトで適用されているかを表示できます。変更せずにすべてをマップする次のマッピングを使用します。このマッピングでは、まずすべてのロールがフィルタされ、次にすべてのアカウントがフィルタされます。
|#all|,%% @|#all|,@%%
マッピング構文の詳細は、5.8.2.3項「アカウントおよびロールの一致」を参照してください。
|
注意: 資格証明マップに、匿名ユーザーがコンテンツ・サーバーWebサイトに接続する際に付与される最小限の権限も割り当てられていない場合、ログイン済のユーザーが異常な動作を体験する可能性があります。たとえば、 |
アカウントおよびロールの一致には特別なフィルタを使用できます。たとえば、アカウント・フィルタの構文は、アカウント値を接頭辞@|で開始し、|で終了することで指定されます(たとえば@|accountname|)。パイプ(|)はフィルタを介して値を処理するコマンド・リダイレクト演算子を表します。プロキシ接続の場合は、空白で区切られたアカウントのリストが指定されます。アカウントをダッシュ(-)で開始して、負の値を指定することもできます。ダッシュで開始されていない指定した任意のアカウント文字列がユーザー・アカウントの接頭辞である場合や、ダッシュで開始されているすべてのアカウント文字列がそのユーザー・アカウントの接頭辞ではない場合に、フィルタが一致します。
|
注意: フィルタでは、アカウント |
ロールは、フィルタの先頭から@記号を削除することで、同じルールを使用して、マップできます。たとえば、次の入力値では、接頭辞visitorで開始されるロールを除くすべてのロールが取得されます。#allという式では、すべてのロールが一致することに注意してください。
|#all -visitor|, %%
出力値の特別な配列%%を使用して、入力値を参照できます。たとえば、次のマッピングでは、接頭辞financialで開始されないすべてのアカウントは同じアカウントにマップされますが、先頭に接頭辞employee/が追加されます。
@|#all -financial|, @employee/%%
ユーザーのアカウントがmarketingの場合、マッピング後、ユーザーのアカウントはemployee/marketingになります。
カッコで囲まれた文字"R"、"W"、"D"、"A"を使用したアカウント指定に準拠することで、出力値のアカウントに特定の権限レベル(読取り、書込み、削除、すべて)を付与できます。たとえば、次の構文で、すべてのアカウントのすべての権限レベルを読取り権限に変更できます。
@|#all -financial|, @employee/%%(R)
置換%%を適用する前に、接頭辞を削除すると便利な場合があります。構文%%[n]を使用して、置換のオフセットを指定できます。ここで、nは、%%式に入力値をマップする前に使用する開始のオフセットです。オフセットはゼロベースであるため、%%[1]では入力値の先頭の文字が削除されます。たとえば、すべてのロールから接頭辞DOMAIN1\を削除するには、次の式を使用します。
|domain1\|, %%[8]
この機能を使用して、接頭辞marketing/で開始されるすべてのアカウントを、接頭辞org1/mktで置換することもできます。この場合の式は次のようになります。
@|marketing/|, @org1/mkt/%%[10]
プロキシ資格証明マップは、最初の資格証明がユーザーに割り当てられた後に適用されます。このマッピング例では、(LDAPグループではなく)ユーザーに割り当てられたアカウント値が使用され、同じアカウント値が付与されています。
@|Public|, @Public
(R)などの接尾辞を適用しない場合、マッピング前にアカウントが付与されていた権限はすべて、マッピング後も保持されます。LDAPマップによって割り当てられるデフォルトの権限から権限を降格する場合は、次の構成を試します。
@|Public|, @%%(R)
%%は、接頭辞Publicと一致した入力アカウント値を表します。たとえば、ユーザーのアカウントがPublic/mysuffixであり、|Public|接頭辞フィルタによって取得される場合、%%の値はPublic/mysuffixになります。
新しいブラウザ・ウィンドウを開き、システム管理者としてコンテンツ・サーバー・インスタンスにログインします。
「管理」、「資格証明マップ」の順に選択します。
「資格証明マップ」画面が表示されます。
作成する資格証明マップの一意の識別子を入力します。
コンテンツ・サーバー・インスタンスへの接続に、複数の名前付きパスワード接続を使用できます。それぞれの名前付きパスワード接続に、異なる資格証明マップを使用できます。
値を2列で入力します。列はカンマで区切り、値の各行の間には改行を使用します。最初の列では入力値を、2番目の列では出力値を指定します。
「更新」をクリックします。
NT統合を使用して取得したロールおよびアカウントに資格証明マップを適用するには、コンテンツ・サーバー構成エントリExternalCredentialsMapを、適用する資格証明マップの名前に設定します。
コンテンツ・サーバー・インスタンスへのセキュアな接続は、着信リクエストにパスワードの保護を作成することでサポートできます。パスワードを保護すると、コンテンツ・サーバー・インスタンスは別のコンテンツ・サーバー・インスタンスと通信できます。
この項の内容は次のとおりです。
「プロキシ接続の認証/認可情報」画面を使用して、名前付きパスワードを作成できます。これは特定の接続に名前で割り当てるパスワードです。 各名前付きパスワードを関連付けられるのは、コンテンツ・サーバー・インスタンスへのダイレクト・ソケット通信と、コンテンツ・サーバー・インスタンスのWebサーバー(HTTPフィルタ)を制御することで実行される任意の通信の両方に対するホストおよびIPアドレス・フィルタです。外部エージェント(別のコンテンツ・サーバー・インスタンスのWebサーバーなど)でコンテンツ・サーバー・インスタンスと通信する必要がある場合、名前付きパスワード接続を使用できます。名前付きパスワード接続は、資格証明マップにも関連付けられるため、コンテンツ・サーバー・インスタンスにアクセスするユーザーの権限を引き下げることや変更することができます。
プロキシ接続のエントリ・フィールドは、送信ソケット・プロバイダおよび送信HTTPプロバイダを構成するためのフォームに提供されており、名前付きパスワード接続を指定できます(インスタンスに選択されているプロバイダを表示するには、「管理」、「プロバイダ」の順に選択します)。
パスワードは、クライアント側の許可されているホストおよびIPアドレス・ワイルドカード・フィルタを使用してハッシュされます(SHA1メッセージ・ダイジェスト)。これは、格納されているパスワードのコピーが露呈した場合、ホストおよびIPアドレス・フィルタの両方を満たすクライアントからのアクセスのみが許可されることを意味します。
パスワードに有効期限を実装する場合は、関連する様々なサーバーの時計がかなり正確(最低数分以内)に同期している必要があります。
|
注意: すべてのパスワードは、サーバーに送信される前にタイムアウト値でハッシュされます。これは、サーバーへの通信中にパスワード値が露呈した場合、有効期限(リクエストが発行された後の約15分)までの間のみパスワードが使用できることを意味します。また、前述した同じソース・ホストおよびIPアドレスからの再生攻撃でのみ、パスワードは使用できます。ファイアウォールで保護された内部ホストおよびIPアドレスが使用されていない場合は、その実行した攻撃者が主要なDNSサーバーのいずれかをハイジャックすることで、ホストおよびIPアドレスが偽装される可能性があります(少なくとも数件発生しています)。 |
「プロキシ接続の認証/認可情報」画面に入力するデータにより、外部エージェントがコンテンツ・サーバー・インスタンスに接続する際に使用可能な異なるパスワードを定義できます。様々な理由 (メッセージ・ダイジェスト・アルゴリズムはクリア・テキスト・パスワードが使用されていないなど)で クライアントに対して利用できない可能性があるため、 外部エージェントに各ユーザーのパスワードの入力を要求するのではなく、プロキシ接続を使用します。これにより、ユーザーは単一の名前付き接続パスワードを使用して認証できます。各名前付きパスワード接続をルールにリンクし、コンテンツ・サーバー・インスタンスに接続できるホストを制限したり、ユーザーに付与される権限を制御できます。各名前付きパスワード接続は一意に識別されますが、呼出し側のエージェントはパスワードとともに識別子を指定する必要があります。
ホスト名およびIPアドレス・フィルタは、コンテンツ・サーバー・インスタンスへのダイレクト・ソケット接続を実行する際に、どのホスト名またはIPアドレスで名前付きパスワード接続の使用が許可されているかの判断に使用されます。フィルタの定義ルールは、システム・プロパティ・エディタに定義されているルールと同様です( 0または複数の一致を表す*およびいずれかの一致を表す| のワイルドカード記号を使用して、柔軟なルールを作成できます)。エントリが空の場合には、ターゲット属性の制限はありません (次の2つのフィールドのどちらが関連するかによって、クライアントのホスト名またはIPアドレスのいずれかになります)。
「プロバイダ」ページを介して、次の2つのオプションが実装されます。
送信プロバイダを追加する場合には、名前付きパスワード接続の使用、および(Webアクセスとセキュリティがリモート・サーバーを介して制御されるように)プロバイダを接続サーバーにするかどうかの選択のオプションがあります。
ユーザー・プロバイダ(LDAPなど)を追加した場合は、使用可能な資格証明マップの使用を選択できます。
資格照明マップは、「プロキシ接続の認証/認可情報」画面には定義されていません。資格証明マップの作成の詳細は、5.8.2項「資格証明マッピング」を参照してください。
新しいWebブラウザ・ウィンドウを開き、システム管理者としてコンテンツ・サーバー・インスタンスにログインします。
「管理」を選択します。
「接続パスワード」を選択します。
「プロキシ接続の認証/認可情報」画面が表示されます。
プロキシ接続ページのフィールドに情報を入力します。
資格証明マップが存在する場合、既存の資格証明マップを使用することも、プロキシ接続用に作成することもできます。
「更新」をクリックします。
管理者はHTTPプロトコルを使用してコンテンツ・サーバー・インスタンス間のプロキシ接続を作成できます。たとえば、どちらもそれぞれの機能にアクセスするためのWebサーバーを持つ、2つのコンテンツ・サーバー・インスタンスを作成できます。多数のユーザーがコンテンツ・サーバー・インスタンスのいずれかにある情報へのアクセスにWebブラウザを使用する必要があるが、すべてのユーザーがそのサーバーに直接アクセスできるわけではない場合に、この機能は便利です。
コンテンツ・サーバー・アーカイブの転送には、HTTPプロトコルも便利です。HTTPプロバイダは、Secure Sockets Layer(SSL)を使用したHTTPSプロトコルと連携し、2つのコンテンツ・サーバー・インスタンス間のセキュアな通信を可能にします。
このセクションの内容は次のとおりです。
管理者は、「プロバイダ」ページで構成可能なhttp送信プロバイダを実装でき、このプロバイダにより、コンテンツ・サーバー・インスタンス間の通信が可能になります。
http送信プロバイダの追加を選択した場合、次の追加のオプションがあります。
CGI URLの指定。
名前付きパスワード接続およびクライアントIPフィルタの指定。
http送信HTTPプロバイダの選択を表示するには、「WebCenter Content」ナビゲーション・パネルから「管理」、「プロバイダ」の順に選択します。
コンテンツ・サーバー・インスタンス間にプロキシ接続を作成するには、いくつかの準備が必要です。コンテンツ・サーバー・インスタンスで、Webレイアウト・ディレクトリに、同じ相対Webルートを使用することはできません。サーバー間の追加のナビゲーション・リンクを提供するには、コンポーネント・アーキテクチャを一部変更する必要があります。
WebサーバーでSSLが使用され、その他のサーバーのフロント・エンドでHTTPが使用されている状態で、コンテンツ・サーバー・インスタンスを設定した場合、ユーザーがWebブラウザでその他のサーバーのURLを変更して、最初のサーバーへのアクセスを試行すると、HTTPS(資格証明が必要)とHTTP間の差異が原因で、エラーが発生する可能性があります。この問題を解決するには、コンテンツ・サーバー・システムとともに入手可能なBrowserUrlPathコンポーネントを使用してください。詳細は、5.9.2項「ブラウザURLのカスタマイズ」を参照してください。
最初のコンテンツ・サーバー・インスタンスにhttp送信プロバイダを追加します。
ブラウザで「管理」ページに移動し、「プロバイダ」をクリックします。
htt送信プロバイダ・タイプの横の「追加」をクリックします。
http送信プロバイダの必要な情報を入力します。詳細は、送信Httpプロバイダ・ページの表を参照してください。
前の手順で指定した名前付きパスワード接続および接続パスワードを使用する2番目のコンテンツ・サーバー・インスタンスにプロキシ接続を作成します。
このサーバーで、「管理」、「接続パスワード」の順に選択します。
接続に関する情報を入力します。IPアドレス・フィルタ・エントリには最初のサーバーのIPアドレスが含まれている必要があります。
次の項では、コンテンツ・サーバー・インスタンスへのアクセスおよび通信方法に関する情報を提供します。次が含まれています。
エクストラネット検索コンポーネントを使用して、Webサーバーが発行したエラーと問題のページを介してOracle WebLogic Serverユーザー・ストアにより認証されないユーザーに対するインタフェースを抑制して、ユーザー・アクセスをカスタマイズできます。インタフェースの変更の詳細は、『Oracle WebCenter Content Content Server開発者ガイド』を参照してください。
エクストラネット検索コンポーネントはデフォルトでコンテンツ・サーバー・システムとともにインストールされ、無効化されます。このコンポーネントを使用するには、拡張コンポーネント・マネージャを使用して有効化する必要があります。
BrowserUrlPathコンポーネントは、コンテンツ・サーバー・システムおよびWebサーバーの特定の構成で使用されるURLパスの特定をサポートします。このコンポーネントはデフォルトでコンテンツ・サーバー・システムにインストールされ、無効化されています。このコンポーネントを使用するには、拡張コンポーネント・マネージャを使用して有効化する必要があります。
このコンポーネントはOracle WebLogic Serverドメインにデプロイされ、ロード・バランサの背後に配置されたコンテンツ・サーバー・インスタンスに対して有効です。
この項で説明する項目は、次のとおりです。
BrowserUrlPathコンポーネントにより、特定のIdocスクリプト変数および関数の上書き、特定の変数に対する計算の追加、およびURLパスを判断するための追加の構成エントリの提供が行われます。BrowserUrlPathコンポーネントはコンテンツ・サーバーのユーザー・インタフェース用の「トレイ」および「トップ・メニュー」レイアウトでのみサポートされます。
異なるWebサーバー・フロント・エンドを使用してシステムを構成できます。一方のフロント・エンドにはHTTPを使用し、もう一方にはHTTPSを使用できるため、HTTPおよびHTTPSを使用して複数のWebサイトから同時にコンテンツ・サーバー・インスタンスにアクセスできます。BrowserUrlPathコンポーネントを適用して、コンテンツ・サーバー・インスタンスでどちらのタイプのアクセスも処理できるようにする必要があります。
HTTPホスト・ヘッダーとして転送されるロード・バランサを使用している場合は、BrowserUrlPathコンポーネントを適用する必要があります。
BrowserUrlPath構成変数はWL_WEBCENTER_CONTENT_HOME/ucm/idc/components/ BrowserUrlPath/config.cfgファイルにあります。
|
注意: BrowserUrlPathコンポーネントには変数を使用した拡張構成が必要です。変数を変更する前に構成をバックアップする必要がある場合があります。 |
一般的なシナリオでは、Webサーバーにより、2つの重要な情報がコンテンツ・サーバー・インスタンスに転送されます。
HTTP_HOST: ブラウザにより送信されるホスト・ヘッダー。ブラウザのアドレス・バーに表示される際にホストを識別します。
SERVER_PORT: コンテンツ・サーバー・インスタンスへの接続時にブラウザにより使用されるポート。
2つの重要な機能には、ブラウザ・ベースのフル・アドレスが使用されます。
コンテンツ・サーバー・インスタンスの「トレイ」レイアウトのサイド・フレームにおけるURLの自動作成。特に、サイドのミニ検索には、相対URLではなく、フルURLを予測する必要があります。
PDFドキュメントを強調表示するセカンダリURL (PDFのURLの後に続く#xml-http...の部分)。
BrowserUrlPathコンポーネントにより、追加の構成なしで特定の変数の機能が強化され、SERVER_PORTの値が433の場合、コンポーネントではプロトコルはHTTPではなくHTTPSであると推測されます。同様に、SERVER_PORTの値が433ではない場合、コンポーネントではブラウザがHTTPSではなくHTTPを使用してリクエストを発行したと推測されます。この拡張により、SSL(HTTPS)および非SSL Webサーバー(HTTP)の両方から、同じコンテンツ・サーバー・インスタンスにアクセスできます。
このコンポーネントにはWebDAVアクセスに関する特別な機能もあります。構成エントリWebDavBaseUrlが追加されたため、動的に使用されます(ホストおよびプロトコルが絶対パス・ルールを使用して変更されます)。
|
注意: WebDAVアクセスの機能により、一部のコンテンツ・サーバーのページにおけるCHECKOUTおよびOPEN関数の動作、およびSite Studioクライアントの一部の動作が変更されます。 |
BrowserUrlPathコマンドは、次のIdocスクリプト変数および関数の計算を上書きします。
HttpBrowserFullCgiPath
HttpWebRoot
HttpCgiPath
HttpAdminCgiPath
HttpImagesRoot
BrowserUrlPathコンポーネントにより、次の変数に計算が追加されます。
HttpBrowserFullWebRoot: ユーザーが現在使用しているブラウザのアドレス・バーから提供される値を使用して、現在のコンテンツ・サーバー・インスタンスのWebルートへのフルURLパスを定義します。この変数は、Webルート用であることを除きHttpBrowserFullCgiPathに似ています。
HttpAbsoluteWebRoot: 現在のコンテンツ・サーバー・インスタンスのWebルートへの汎用フルURLパスを定義します。HttpBrowerFullWebRootのパスとは異なるプロトコルまたはホスト名を使用できます。たとえば、ユーザーがホスト名に対するIPアドレスを指定した場合、HttpBrowserFullWebRoot変数ではそのIPアドレスが使用されますが、HttpAbsoluteWebRoot変数では無視され、内部的に構成された適切なホスト名が使用されます。
HttpAbsoluteCgiPath: 現在のコンテンツ・サーバー・インスタンスの汎用フル動的ルートURLを定義します。これはコンテンツ・サーバー・インスタンスの動的コンテンツを呼び出すWebサーバーでプラグイン・コードを実行するパスです。HttpBrowserFullCgiPathのパスとは異なるプロトコルまたはホスト名を使用できます。たとえば、ユーザーがホスト名のIPアドレスを指定した場合、HttpBrowserFullCgiPath変数ではそのIPアドレスが使用されますが、HttpAbsoluteCgiPath変数では無視され、内部的に構成された適切なホスト名が使用されます。
ブラウザ・パス変数HttpBrowserFullCgiPathおよびHttpBrowserFullWebRootの場合、ユーザーが現在使用しているブラウザのプロトコル(HTTPとHTTPS)、ポート番号およびホスト名は実装コードにより判断されます。この判断は、Webサーバーがリクエストで何を受信するかに基づいています。
BrowserUrlPathコンポーネントでは、ブラウザがURLパスを判断する際にそれを推測するための次の構成エントリがサポートされています。
HttpIgnoreWebServerInternalPortNumber: trueに設定すると、SERVER_PORTパラメータを使用できなくなります。このエントリは、SERVER_PORTがブラウザにより使用されるポートではなく、Webサーバーと通信するためにロード・バランサで使用されるポートであるロード・バランシングのシナリオに便利です。このエントリを有効にすると、コンテンツ・サーバー・インスタンスは、BrowserUrlPathコンポーネントなしでは、ブラウザがWebサーバーへのアクセスに使用したポートを判断できなくなります。追加のBrowserUrlPath構成がない場合、この変数が原因で、同じコンテンツ・サーバー・インスタンスへのSSLおよび非SSLアドレスの両方をサポートできなくなります。この変数を使用すると、ロード・バランシング・サーバーで、内部Webサーバーが実際にリクエストへの応答の送信に使用しているのとは異なるポート番号が使用されるというロード・バランシング構成の問題を防ぐことができます。
HttpIgnoreServerNameForHostName: trueに設定すると、HTTP_HOSTパラメータが欠落している場合には、通常、コンテンツ・サーバー・システムによりパラメータSERVER_NAME(Webサーバーの自己識別)が検索されるというフォールバック・ロジックが無効化されます。
HttpBrowserSSLPort: この構成エントリは、SERVER_PORTエントリがコンテンツ・サーバー・インスタンスと通信するWebサーバーに転送される場合にのみ使用します。このエントリは、SERVER_PORTパラメータと比較することで、リクエストがHTTPSとHTTPのいずれであるかを判断する際に使用されます。デフォルトのSERVER_PORT値は443です。HTTPSを使用するが、443以外のポートを使用する場合は、使用するHTTPSポート番号をこのエントリを使用して設定する必要があります。
HttpBrowserUseIsSslCookie: SSLを使用するかどうかが特定されていることを確認するためにCookieを調査する必要がある場合は、このエントリをtrueに設定します。
HttpBrowserIsSslCookieName: このエントリはHttpBrowserUseIsSslCookieエントリが有効化されている場合にのみ使用します。ブラウザでSSLが使用されているかどうかをサーバーが判断するために使用するCookieの名前にこのエントリを設定します。デフォルトはCookie名UseSSLです。Cookieの値は1または0(ゼロ)です。この名前のCookieが存在する場合、SSLを使用するかどうかを判断するためのその他のルールより優先されます。
HttpBrowserUseHostAddressCookie: trueに設定すると、ブラウザのフル・ホスト名(プロトコルおよび相対Webアドレスの間の部分)の判断にCookieを使用することが指定されます。
HttpBrowserHostAddressCookieName: このエントリはHttpBrowserUseHostAddressCookieが有効化されている場合にのみ有効化されます。このエントリは、サーバーがブラウザの現在のホスト名であると判断した内容の確認に使用されるCookie名の指定に使用します。プロトコルのホスト名の部分には、ポート番号が含まれる場合があります。たとえば、HttpbrowserHostAddressCookieName=myhost:81では、Webポート81を使用するホストmyhostが指定されています。このCookieを使用する場合、myhost:433を使用するとhttps://myhost/%rest-of-url%に変換されるため、HttpBrowserUseIsSslCookieを有効化する必要はありません。
BrowserUrlPathコンポーネントでは、絶対フル・パスの計算方法を変更するため次の構成エントリがサポートされています。ブラウザで別のURLが示されていても、固有のホスト名とプロトコルを使用する方がよい電子メールに便利です。このパスは絶対または汎用パスとみなされます。
HttpBrowserAbsoluteUrlHasRelativeSSL: trueに設定すると、コンテンツ・サーバー・システムがユーザーのブラウザで現在使用されていると判断した内容に応じ、HTTPからHTTPS(config.cfgファイルでUseSSLが有効化されている場合はHTTPSからHTTP)に変更するために、「コンテンツ情報」ページでURLを計算できるようになります。HTTPとHTTPSを変更すると複数の電子メールの宛先リンクに対して電子メールの本文を作成するためのURLの計算も変更されます。この構成は自動的に生成される電子メールには影響しません。
HttpBrowserAlternateWebAddress: 代替の絶対ホストWebアドレス(ホスト名とオプションでポート番号)を指定します。たとえば、HttpBrowserAlternateWebAddresss=host_name:447です。このWebアドレスは、現在のSSLの選択がコンテンツ・サーバー・インスタンスのデフォルトと異なる場合に、絶対パスの計算に使用されます。この構成は自動的に生成される電子メールには影響しません。
HttpBrowserAbsoluteUrlUsesBrowserPath: trueに設定すると、ブラウザ・パス情報が計算される場合、絶対パスにブラウザ・パスが使用されます。これにより、基本的に、バックグラウンド・アクティビティ(電子メール通知の送信など)を除く絶対パスが無効化されます。
BrowserUrlPathコンポーネントでは、「管理」トレイまたは上部のメニュー・リンクのパスの計算方法を変更するための次の構成エントリがサポートされています。たとえば、管理パスは、管理サーバーのCGIを管理サーバーへの相対URLとして取得する変数HttpAdminCgiPathにより計算されます。
HttpBrowserAdminUsesAbsolutePath: trueに設定すると、構成変数HttpBrowserUseAdminSSLにより決定されるプロトコルを除き、ブラウザベースのパス(BrowserUrlPathコンポーネントのデフォルト)を使用するかわりに、管理パスの計算のベースとして絶対パスが使用されます。
HttpBrowserUseAdminSSL: この構成エントリは、HttpBrowserAdminUsesAbsolutePath変数が設定されている場合にのみ関連します。trueに設定すると、HttpBrowserAbsoluteUrlHasRelativeSSLが設定されている場合でも、この変数により管理パスのプロトコル(HTTPまたはHTTPS)が決定されます。HttpBrowserUseAdminSSLのデフォルト値はUseSSLの反対の値です。これにより、管理パスはその他のすべてのパスに対するデフォルトのURL構成の標準ではなくなります。変数HttpBrowserAlternateWebAddressが設定されている場合には、HttpBrowserUseAdminSSLがUseSSLの反対の値に設定されている際に、この変数を使用して管理パスに別のWebアドレスを指定できます。
変数およびBrowserUrlPathコンポーネントの有効化の詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドおよびOracle WebCenter Contentインストレーション・ガイドを参照してください。
拡張ユーザー属性コンポーネントにより、管理者は拡張セキュリティ属性をコンテンツ・サーバーのユーザーに追加できます。拡張セキュリティ属性は既存のユーザー属性とマージされ、ユーザーの管理に柔軟性を追加できます。たとえば、内部の設定を実行する必要なく、ロールおよびアカウント属性を外部LDAPユーザーに追加できます。また、ロールおよびアカウント属性を、ベース・ユーザー属性とは別に、カスタマイズされたアプリケーション用のユーザーに追加できます。
コンテンツ・サーバー・システムとともに、デフォルトで、拡張ユーザー属性コンポーネントがインストールされて有効化されます。拡張ユーザー属性コンポーネントにインストールされるサービスについては、Oracle WebCenter Contentサービス・リファレンス・ガイドを参照してください。
この項では、拡張ユーザー属性の次のトピックについて説明します。
これらのリソースに加えて、拡張ユーザー属性用のデータを収集するのに使用できる追加された問合せがあります。問合せはコンポーネント・ウィザードまたはWC_CONTENT_ORACLE_HOME/ucm/idc/components/ExtendedUserAttributes/resources/extendeduserattributes_query.htmファイルで検索することにより表示できます。
ExtUserAttribInfoは、コンテンツ・サーバー・システムが拡張ユーザー属性を処理するのに使用する結果セットです。これは標準のユーザー属性の処理に使用されるUserAttribInfo結果セットと同様で、いくつかの追加の情報を使用します。
この結果セットには3つの列があります。1つの行につき1つの属性、または1つの行に複数の属性(アプリケーションごと)を指定できます。次の列が含まれます。
dUserName: 属性が記載されているユーザー。
dApplication: 属性がリンクされている先のアプリケーション
AttributeInfo: 属性情報。これは3アイテムからなるカンマ区切りエントリです。
属性タイプ: 通常はロールまたはアカウントのいずれか。セキュリティ・グループまたはアカウントがユーザーに対して定義されているかどうかによります。
属性名: ロールまたはアカウントのタイトル
権限の属性: ユーザーに付与された権限の定義。UNIXの規則に従い権限が定義されます。
1: 読取り権限
2: 書込み権限
4: 削除権限
8: 管理
たとえば、エントリrole,contributor,3では、読取りおよび書込みのユーザー権限をコントリビュータ・セキュリティ・グループに付与します。
複数のAttributeInfoエントリをカンマで区切って1つの行に追加できます。たとえば、このエントリは2つの属性をAttributeInfo行に追加します: role,guest,15,account,\#all,15
次にこの結果セットの例を示します。
@ResultSet ExtUserAttribInfo 3 dUserName dApplication AttributeInfo jsmith appl role,contributor,15 jsmith app2 account,abc,15,account,xyz,15 @end
encodeHtml Idocスクリプト機能およびフィルタ・フックを使用することで、すべての入力データの危険なHTML構成を自動的に修正し、無効または破損したHTML構成のデータ入力をフィルタするようにコンテンツ・サーバー・システムをカスタマイズできます。encodeHtml関数は特定の文字列に適用できます。HtmlDataInputFilterLevel構成変数は、あるレベルのエンコーディングを適用して、コンテンツ・サーバー・システムへのすべてのデータ入力をフィルタするために使用できます。
この項の内容は次のとおりです。
encodeHtml Idoc関数は、無効または破損したHTML構成のデータ入力をフィルタするために使用できます。出力はエンコードされた文字列です。encodeHtml関数はThreaded Discussionsコンポーネントのディスカッションにデフォルトで適用されます。
HtmlDataInputFilterLevel構成変数はunsafeとしてエンコードされているため、encodeHtml関数は、一般的にexceptsafe以上のレベルのエンコーディングで使用されます(デフォルト構成が使用されている場合)。
encodeHtml関数の定義は次のとおりです。
encodeHtml (string, rule, wordbreakrules)
string: エンコードする文字列。
rule: HTML構成をエンコードする際に適用するルール。許容される値は次のとおりです。
none: HTML構成は変換されません。
unsafe: 既知の安全ではないスクリプト・タグのみがエンコードされます。リストに含まれているのは、script、applet、object、html、body、head、form、input、select、option、textareaです。
exceptsafe: 既知の安全なスクリプト・タグのみがエンコードされません。リストに含まれているのは、font、span、strong、p、b、i、br、a、img、hr、center、link、blockquote、bq、fn、note、tab、code、credit、del、dfn、em、h1、h2、h3、h4、h5、blink、s、small、sub、sup、tt、u、ins、kbd、q、person、samp、var、ul、li、math、over、left、right、text、above、below、bar、dot、ddot、hat、tilde、vec、sqrt、root、of、array、row、itemです。
lfexceptsafe: (ユーザーにより拡張コメントが入力され、コメントで元のテキストの行送りによる改行を保持する必要がある場合にお薦めします)exceptsafeに似ていますが、行送り(ASCII 10)文字がHTMLの改行タグ(br)に変換されます。HTMLタグ内の行送りは改行タグに変換されません。exceptsafeで安全とみなされるbr、p、ul、liのスクリプト・タグは、lfexceptsafeでは安全と見なされません。
ruleのnoneを除き、すべてのルールには独特のHTMLコメントの処理方法があります。特に、すべてのHTMLコメントはフィルタを介して許可されます。ただし、HTMLコメント内の、小なり(<)記号および大なり(>)記号はすべてエンコードされます。これはHTMLの終了記号(-->)には適用されません。また、終了していないコメントがある場合、エンコード機能により、HTMLコメントの終了記号(-->)が追加されます。
さらに、ruleのnone以外、タグの内に配置された属性値では、カッコは%28(左カッコ)または%29(右カッコ)にエンコードされます。それ以外の場合、エスケープされている文字は、XML(&xxxx;)タイプ・エンコーディングを使用してエスケープされます。
wordbreakrules: 空白文字のない長い文字列を改行するかどうか、および適用する最大ワード・サイズを指定するオプションのパラメータです。文字列wordbreakまたはnowordbreakを指定できます。このパラメータはencodeHtmlの任意のルールとともに使用できます。デフォルトでは、ruleにlfexceptsafeが指定されている場合はwordbreakが有効化され、maxlinelengthの120文字が使用されます。
追加のパラメータmaxlinelength=xxxはwordbreakパラメータとともに使用して、必要な最大の行の長さを指定できます。例:
encodeHtml ("exceptsafe", "<bad> text", "wordbreak, maxlinelength=80")
wordbreak関数は表示用に使用され、データが保存される前には適用されないため、encodeHtml関数でのみ使用可能です。
Idocスクリプトの詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。
HtmlDataInputFilterLevel構成変数は、あるレベルのエンコーディングを適用して、不正なHTML構成に関するコンテンツ・サーバー・システムへのすべての入力データをフィルタするために使用できます。std_resources.htmファイルのHtmlDataInputEncodingRulesForSpecialFields表は、特別な場合のエンコーディング・ルールに使用され、特定のパラメータのこの構成エントリを上書きする場合があります。
HtmlDataInputFilterLevel値を変更した場合は、コンテンツ・サーバー・インスタンスを再起動する必要があることに注意してください。
HtmlDataInputFilterLevel変数を使用しても、IdocスクリプトのencodeHtml関数の動作に影響はありません。
HtmlDataInputFilterLevel構成変数は次の値に設定できます。
none: (非推奨)すべてのフィルタが無効化されます。
unsafe: (デフォルト。推奨)不正なHTML構成から保護されます。不正な構成の例は、script、applet、object、html、body、head、form、input、select、option、textareaです。
exceptsafe: (非推奨)フィルタを介して既知の安全な構成のみが許可されます。exceptsafeを選択すると、GETスタイル・リクエストを使用したリクエストにunsafeオプションが適用されます。GETリクエストにこれより高いレベルのエンコードを実行すると、<$...$>およびその他のタグがパラメータ・データまたはURLの一部として定期的に渡されるため、コンテンツ・サーバーの操作が分断されます。より高いレベルのフィルタリングは、スクリプト化できないサービス(通常POSTを使用して呼び出されるサービス)にのみ適用されます。
既知の安全な構成の例は、font、span、strong、p、b、i、br、a、img、hr、center、link、blockquote、bq、fn、note、tab、code、credit、del、dfn、em、h1、h2、h3、h4、h5、blink、s、small、sub、sup、tt、u、ins、kbd、q、person、samp、var、ul、li、math、over、left、right、text、above、below、bar、dot、ddot、hat、tilde、vec、sqrt、root、of、array、row、itemです。
HTMLコメントの処理に関する情報は、encodeHtml関数のruleの説明を参照してください。この説明は、HtmlDataInputFilterLevel構成変数値にも当てはまります。
HtmlDataInputFilterLevel構成変数では、値lfexceptsafeはサポートされていません。encodeHtml関数でのみサポートされています。
