28 RIDCを使用したコンテンツ・サーバーへのアクセス
この章では、Oracle WebCenter Content Serverとの通信のためのシン通信APIを提供するRemote Intradoc Client (RIDC)の初期化および使用方法について説明します。
Remote Intradoc Client (RIDC)は、Oracle Technology Network (OTN) (http://www.oracle.com/technetwork/index.html
)からダウンロードできます。
ノート:
-
Remote Intradoc Client (RIDC) 12c (12.2.1.0.0以降)では、Java Runtime Environment (JRE) 1.8以上が必要です。最新のJava JRE/JDKは、Oracle Technology Network (OTN) (
http://www.oracle.com/technetwork/index.html
)からダウンロードできます。 -
Remote Intradoc Client (RIDC)の詳細は、『Oracle Fusion Middleware Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンス』を参照してください。
この章の内容は次のとおりです。
28.1 Remote Intradoc Clientについて
Remote Intradoc Client (RIDC)は、コンテンツ・サーバーとの通信を行うためのシン通信APIです。その主な機能は、コンテンツ・サーバー・サービスをリモートで実行できるようにすることです。さらに、RIDCは、接続プーリング、セキュリティ、プロトコルの固有情報などを処理します。
主な機能
Remote Intradoc Client (RIDC)には次のような機能があります。
- Intradocソケットベース通信、およびHTTPプロトコルとJAX-WSプロトコルをサポートします。
- コンテンツ・サーバーとのSecure Socket Layer (SSL)通信をサポートします。
- ソケットのタイムアウトや接続プールのサイズなどの設定を含むクライアント構成を提供します。
- RIDCオブジェクトは、標準のJava Collectionパラダイムに従います。
28.1.1 サポートされているプロトコル
Remote Intradoc Client (RIDC) 12c (12.2.1.3.0)は、idc
、idcs
、http
、https
およびjax-ws
のプロトコルをサポートしています。
Intradoc: Intradocプロトコルは、Intradocソケット・ポート(通常は4444
)経由でコンテンツ・サーバーと通信します。このプロトコルは、クライアントとコンテンツ・サーバー間の信頼できる接続を必要とし、パスワード検証は行いません。このプロトコルを使用するクライアントには、RIDCコールを行う前に、必要な認証を自身で実行することが求められます。Intradoc通信は、SSL経由で実行するように構成することもできます。
HTTP: RIDCは、サポートされている次の3つのHTTPクライアント・パッケージのいずれかを使用して、コンテンツ・サーバーへのHTTP接続を作成できます。
-
Oracle HTTPClient
-
JDK HttpURLConnection
Intradocとは異なり、このプロトコルでは、各リクエストについて有効なユーザー名とパスワード認証資格証明が必要です。
詳細は、「HttpClientライブラリ」を参照してください。
JAX-WS: JAX-WSプロトコルは、適切に構成されたコンテンツ・サーバー・インスタンスとRIDCクライアントがインストールされているOracle WebCenter Content 12cでのみサポートされます。JAX-WSは、この環境の外部ではサポートされません。
JAX-WSの詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』のJAX-WS Webサービスの概要に関する項および『Oracle Fusion Middleware Oracle WebLogic Server JAX-WS Webサービスの高度な機能のプログラミング』のJAX-WS参照実装の使用に関する項を参照してください。また、Java Community Process Webサイト(http://www.jcp.org/)で、
Java API for XML Web Services (JAX-WS)のドキュメントも参照してください。
28.1.2 サポートされているURLフォーマット
次の表に、サポートされているURLフォーマットを示します。
URL | 説明 |
---|---|
|
Intradocポートを使用します。ホスト名とポート番号のみが必要です。 |
|
Intradocポート経由でSSLを使用します。SSL証明書をロードするための追加の構成が必要です。 |
|
コンテンツ・サーバーCGIパスへのURLを指定します。 |
|
SSL over HTTPを使用します。SSL証明書をロードするための追加の構成が必要です。 |
|
JAX-WSプロトコルを使用してコンテンツ・サーバーに接続します。 |
28.1.3 必要な環境
次の表は、RIDCが各接続タイプをサポートするために必要な環境についてまとめたものです。
URL | 説明 |
---|---|
|
|
|
|
|
|
|
|
|
|
28.1.4 HttpClientライブラリ
RIDCでは、HTTP接続を使用してコンテンツ・サーバー・インスタンスに添付されているWebサービスと通信するために、HTTPクライアント・ライブラリをサポートする必要があります。現在は、次の2つのライブラリがサポートされています。
-
Oracle HTTPClient
-
JDK HttpURLConnection
ノート:
デフォルトでは、RIDCはHTTP/HTTPSプロトコル接続に、JVMの内部HTTPクライアント・ライブラリであるjava.net.HttpURLConnection
を使用します。JVMのHTTPクライアントを、 RIDCではhttpurlconnection
クライアントと呼んでいます。アプリケーションでRIDCのhttpurlconnection
クライアント実装を使用する場合、静的なjava.net
構成を変更またはオーバーライドする補助アプリケーション・コードまたはクラスパスのライブラリがあると、RIDCの動作に影響することがあります。たとえば、補助コードがjava.net.CookieHandler setDefault()
メソッドを使用して処理される静的なカスタムCookieを設定する場合、そのカスタムCookieハンドラは誤ってRIDC HTTP/HTTPS URL接続リクエストにCookieを送信することがあり、これはRIDC Cookie管理フレームワークで認識されないことがあります。言い換えれば、グローバルCookieストアからのCookieは誤ってUCMバックエンドに送信される場合があるということです。
Oracle HttpClientをJavaコードでリクエストするには:
IdcClient idcClient = manager.createClient("http://localhost/cs/idcplg"); idcClient.getConfig ().setProperty ("http.library", "oracle");
JDeveloper拡張機能を使用して新規のRIDCアプリケーションを作成している場合は、「構成パラメータ」セクションで、適切な値( oracle
など)を指定したパラメータhttp.library
を接続に追加することができます。
JDeveloperでSite Studio for External Applications (SSXA)アプリケーションを使用している場合、ユーザー・インタフェースがないため、まず接続を作成し、その接続をテストせずに保存する必要があります。その後で、「接続」→「ディスクリプタ」→「ADF META-INF」ノードのconnections.xml
ファイルを開きます。connections.xml
ファイルにStringRefAddr
セクションを追加し、ファイルを保存します。
Connection Example in connections.xml <Reference name="sample" className="oracle.stellent.ridc.convenience.adf.mbeans.IdcConnection" xmlns=""> <Factory className= "oracle.stellent.ridc.convenience.adf.mbeans.IdcConnectionFactory"/> <RefAddresses> <StringRefAddr addrType="oracle.stellent.idc.connectionUrl"> <Contents>idc://<IPv6 Hostname>:4444</Contents> </StringRefAddr> <StringRefAddr addrType="oracle.stellent.idc.idcServerURL"> <Contents>http://localhost/cs/idcplg</Contents> </StringRefAddr> <StringRefAddr addrType="oracle.stellent.idc.http.library"> <Contents>oracle</Contents> </StringRefAddr> </RefAddresses> </Reference>
SSXAとRIDCの接続タイプは類似していることに注意してください。
-
JDeveloperでSSXA接続を使用する場合、
connections.xml
ファイルのaddrType
値はoracle.stellent.idc.http.library
です。 -
JDeveloperでRIDC接続を使用する場合、
connections.xml
ファイルのaddrType
値はoracle.stellent.ridc.http.library
です。
28.1.5 コンビニエンス・クラス
多数のアプリケーションがRIDCを使用して実行するアクションのパターンがいくつかあります。コンビニエンス・パッケージで、それらのパターンの一部が再利用のために提供されています。コンビニエンス・パッケージ領域内のクラスは、RIDCコードのコンシューマであり、そのため、新しい機能を追加することはありません。それらは、RIDCの上の新たなレイヤーと考えることができます。
コンビニエンス・クラスの使用の詳細は、「ユーザー・セキュリティの設定」を参照してください。
28.2 接続の初期化
この項では、Intradoc接続とHTTP接続を初期化するサンプル・コード、およびJAX-WSクライアントを初期化するコードを示します。
次のコードは、Intradoc接続を初期化します。
Intradoc Connection Initialization // create the manager IdcClientManager manager = new IdcClientManager(); // build a client that will communicate using the intradoc protocol IdcClient idcClient = manager.createClient("idc://localhost:4444");
次のコードは、HTTP接続を初期化します。Intradoc接続との唯一の違いはURLです。
HTTP Connection Initialization // create the manager IdcClientManager manager = new IdcClientManager(); // build a client that will communicate using the HTTP protocol IdcClient idcClient = manager.createClient("http://localhost:16200/cs/idcplg");
次のコードは、JAX-WSクライアントを初期化します。URLにはidcnativews
Webコンテキスト・ルートが含まれています。このWebコンテキスト・ルートは(デフォルトでは)、コンテンツ・サーバーにより公開される2つのWebサービス、login
サービスおよびrequest
サービスにより使用されます。
JAX-WS Client Initialization // create the manager IdcClientManager manager = new IdcClientManager(); // build a client that will communicate using the JAXWS protocol IdcClient idcClient = manager.createClient ("http://wlsserver:16200/idcnativews");
28.3 クライアントの構成
クライアントの構成は、クライアントの作成後に実行できます。構成パラメータには、ソケット・タイムアウトの設定、接続プール・サイズなどがあります。構成はプロトコルに固有です。IdcClientオブジェクトを特定のタイプにキャストすると、そのタイプのプロトコル構成オブジェクトを取得できます。
28.3.1 Intradoc接続のためのクライアント構成
次のコードは、Intradoc接続のためのソケット・タイムアウトおよび待機時間を設定します。
Client Configuration for Intradoc Connections // build a client as cast to specific type IntradocClient idcClient = (IntradocClient)manager.createClient("http://localhost/cs/idcplg"); // get the config object and set properties idcClient.getConfig().setSocketTimeout(30000); // 30 seconds idcClient.getConfig().setConnectionSize(20); // 20 connections
28.3.2 SSLの構成
Remote Intradoc Client (RIDC)では、Intradoc通信プロトコルを使用してコンテンツ・サーバーとSecure Socket Layer (SSL)通信を行うことが可能です。使用される通常のポートは4444です。SSLの構成とポートの有効化の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』のSSLを使用するためのOracle WebCenter Contentの構成に関する項を参照してください。
SSL通信の場合、アクセス先のコンテンツ・サーバー・インスタンスにSecurityProvidersコンポーネントをインストールして有効化する必要があります。新しい受信プロバイダとのSSL通信のためにコンテンツ・サーバーを構成し、トラストストアまたはキーストアに関する情報を指定する必要があります。クライアントとコンテンツ・サーバーの両方で、署名付きの信頼できる証明書のある有効なキーストアまたはトラスト・マネージャが必要です。
Oracleでは、署名付き証明書を提供していません。ほとんどの実装では、広く認められている認証局による署名付きの証明書を求めることになります。
コンテンツ・サーバーとのSSL通信を構成するには、次のタスクを実行します。
28.3.2.1 SecurityProvidersコンポーネントのインストールと有効化
28.3.2.2 自己署名のキーのペアと証明書の作成
ほとんどの実装で、広く認められている認証局による署名付きの証明書が必要です。ただし、クライアントとサーバーの両方を制御し、通信が傍受されないようにする必要のみがある場合、または単に実装をテストする場合、keytoolというJDKユーティリティを使用して自己署名のキーのペアおよび証明書を作成できます。Key and Certificate Management Tool (keytool)は、キーと証明書の管理ユーティリティで、自己認証で使用する独自の公開キーと秘密キーのペアおよびこれに関連付けられる証明書をユーザーが管理できます。これは、Sun JDKに含まれています。keytoolはコマンドライン・ユーティリティです。実行可能ファイルは、binサブディレクトリにあります。
28.3.2.2.1 クライアントとサーバーのキーの作成
コマンドライン・プロンプトからJDK-Home/binサブディレクトリに移動し、-genkey
コマンドを発行します。このコマンドで新しいキーが生成されます。コマンドにはいくつかの引数があります。次の表の引数がこのコマンドで使用されます。
引数 | 説明 |
---|---|
-alias |
作成するキーの別名。操作を実行する際に参照するファイル内の要素をキーストアに示すことができます。 |
-keyalg |
キーに使用する暗号化アルゴリズム。 |
-keystore |
キーストアのバイナリ出力ファイルの名前。 |
-dname |
キーを識別する識別名 |
-keypass |
生成されるキーのパスワード。 |
-storepass |
キーストアへのアクセスの制御に使用するパスワード。 |
クライアントとサーバーの両方に別のキーのペアを生成します。これを行うには、-genkey
コマンドを2回実行します。実行ごとに別のキーストアにキーのペアを格納します。キーおよびキーストアの別名、使用するアルゴリズム、キーストア名、識別名およびパスワードを指定します。
この例では、アルゴリズムとしてRSAを使用し、キーとキーストアのパスワードとしてidcidcを使用します。次の引数値をクライアントに使用します。
-alias SecureClient
-keyalg RSA
-keystore client_keystore
-dname "cn=SecureClient"
-keypass idcidc
-storepass idcidc
# keytool -genkey -alias SecureClient -keyalg RSA -keystore client_keystore -dname "cn=SecureClient" -keypass idcidc -storepass idcidc
次の引数値をサーバーに使用します。
-alias SecureServer
-keyalg RSA
-keystore server_keystore
-dname "cn=SecureServer"
-keypass idcidc
-storepass idcidc
# keytool -genkey -alias SecureClient -keyalg RSA -keystore client_keystore -dname "cn=SecureClient" -keypass idcidc -storepass idcidc
# keytool -genkey -alias SecureServer -keyalg RSA -keystore server_keystore -dname "cn=SecureServer" -keypass idcidc -storepass idcidc
# keytool -importcert -file $WL_HOME/server/lib/CertGenCA.der -keystore server_truststore.jks
-storepass idcidc –noprompt
ノート:
これらの各コマンドで、自己署名証明書でラップされたキーのペアが生成され、単一要素証明書チェーンに格納されます。28.3.2.2.2 証明書への自己署名
署名されていないキーは使用できません。keytoolユーティリティで自己署名し、証明書を内部のテストで使用できます。ただし、これらのキーは、一般的に使用するためには署名されません。
コマンドライン・プロンプトから-selfcert
コマンドを発行します(このコマンドで証明書が自己署名されます。コマンドにはいくつかの引数があります)。-selfcert
コマンドを、クライアント用に1回、サーバー用に1回の合計2回実行します。
次の引数値をクライアントに使用します。
-alias SecureClient
-keystore client_keystore
-keypass idcidc
-storepass idcidc
次の引数値をサーバーに使用します。
-alias SecureServer
-keystore server_keystore
-keypass idcidc
-storepass idcid
-selfcert
コマンドの例を次に示します。
# keytool -selfcert -alias SecureClient -keystore client_keystore -keypass idcidc -storepass idcidc
# keytool -selfcert -alias SecureServer -keystore server_keystore -keypass idcidc -storepass idcidc
これで、証明書が秘密キーおよび公開キーによって署名され、単一要素証明書チェーンが生成されます。これによって、以前に生成したものが置き換えられます。
28.3.2.2.3 証明書のエクスポート
クライアントとサーバーのキーを作成し、証明書に自己署名したら、公開キーと秘密キーの2つのキーのペアが2つの証明書に含まれ、2つのキーストアにロックされます。各アプリケーションはデータを暗号化および復号化するために通信相手の公開キーを必要とするため、各公開キーのコピーを相手のアプリケーションのキーストアに配置する必要があります。
コマンドライン・プロンプトから-export
コマンドを発行します。このコマンドで証明書がエクスポートされます。コマンドにはいくつかの引数があります。-export
コマンドを、クライアント用に1回、サーバー用に1回の合計2回実行します。-file
引数を使用して、コンソールではなくファイルに出力をリダイレクトします。
-alias SecureClient
-file client_cert
-keystore client_keystore
-storepass idcidc
次の引数値をサーバーに使用します。
-alias SecureServer
-file server_cert
-keystore server_keystore
-storepass idcidc
-export
コマンドの例を次に示します。
- ファイル
client_cert
に格納された証明書
# keytool -export -alias SecureClient -file client_cert -keystore client_keystore -storepass idcidc
- ファイル
server_cert
に格納された証明書
# keytool -export -alias SecureServer -file server_cert -keystore server_keystore -storepass idcidc
これで、公開キーと署名者の情報を含む証明書がバイナリ証明書ファイルにエクスポートされました。
28.3.2.2.4 証明書のインポート
自己署名証明書の設定の最後のステップは、各プログラムの公開証明書を相手のキーストアにインポートすることです。keytoolによって、インポートを要求した証明書の詳細が示され、リクエストが確認されます。
コマンドライン・プロンプトから-import
コマンドを発行します。このコマンドで証明書がインポートされます。コマンドにはいくつかの引数があります。-import
コマンドを、クライアント用に1回、サーバー用に1回の合計2回実行します。-keystore
値が逆になっていることに注意してください。
次の引数値をクライアントに使用します。
-alias SecureClient
-file client_cert
-keystore server_keystore
-storepass idcidc
次の引数値をサーバーに使用します。
-alias SecureServer
-file server_cert
-keystore client_keystore
-storepass idcidc
-import
コマンドの例を次に示します。
# keytool -import -alias SecureClient -file client_cert -keystore server_keystore -storepass idcidc
Owner: CN=SecureClient Issuer:
CN=SecureClient
Serial number: 3c42e605
Valid from: Mon Jan 14 08:07:01 CST 2002 until: Sun Apr 14 09:07:01 CDT 2002
Certificate fingerprints:
MD5: 17:51:83:84:36:D2:23:A2:8D:91:B7:14:84:93:3C:FF
SHA1: 61:8F:00:E6:E7:4B:64:53:B4:6B:95:F3:B7:DF:56:D3:4A:09:A8:FF
Trust this certificate? [no]: y
Certificate is added to keystore
# keytool -import -alias SecureServer -file server_cert -keystore client_keystore -storepass idcidc
Owner: CN=SecureServer
Issuer: CN=SecureServer
Serial number: 3c42e61e
Valid from: Mon Jan 14 08:07:26 CST 2002 until: Sun Apr 14 09:07:26 CDT 2002
Certificate fingerprints:
MD5: 43:2F:7D:B6:A7:D3:AE:A7:2E:21:7C:C4:52:49:42:B1
SHA1: ED:B3:BB:62:2E:4F:D3:78:B9:62:3B:52:08:15:8E:B3:5A:31:23:6C
Trust this certificate? [no]: y
Certificate is added to keystore
これで、各プログラムの証明書が相手のキーストアにインポートされました。
28.3.2.3 SSL通信のための受信プロバイダの構成
新しいキープアライブ受信ソケット・プロバイダまたは新しいSSL受信ソケット・プロバイダを設定できます。キープアライブを使用すると、セッションのパフォーマンスが向上するため、ほとんどの実装で推奨されます。
28.3.2.3.1 SSL受信プロバイダを検証するためのサンプル・コード
RIDCコードがクライアントであるため、クライアント・キーストアおよびトラストストアの詳細を指定できます。
ノート:
SSL受信プロバイダの作成時に指定したものと同じポート番号を使用します。public static void main(String[] args)
throws IdcClientException, FileNotFoundException, IOException
{
//ssl provider test
IdcClientManager manager = new IdcClientManager();
IdcClient idcClient = manager.createClient("idcs://localhost:6666");
IdcContext userContext = new IdcContext("weblogic");
IntradocClientConfig config = (IntradocClientConfig)idcClient.getConfig();
config.setKeystoreFile("D:/OraclePS4/Middleware/Oracle_Home/user_projects/domains/base_domainNew/ucm/cs/data/providers/sslincomingcs/client_keystore.jks");
config.setKeystorePassword("welcome1");
config.setKeystoreAliasPassword("SecureClient");
config.setKeystoreAliasPassword("welcome1");
idcClient.initialize();
DataBinder dataBinder = idcClient.createBinder();
dataBinder.putLocal("IdcService", "PING_SERVER");
ServiceResponse response = idcClient.sendRequest(userContext, dataBinder);
DataBinder responseData = response.getResponseAsBinder();
System.out.println(responseData.getLocal("StatusMessage"));
}
}
28.3.3 JAX-WSの構成
JAX-WS接続を設定するには、RIDCクライアントとコンテンツ・サーバーがそれぞれ、互換性のあるクライアントおよびサービスのWebサービス・ポリシーによって構成されている必要があります。
RIDCクライアントの場合、jaxwsConfig.setClientSecurityPolicy(...)
を使用して明示的なクライアント・ポリシー(LPAモード)を設定するか、または、RIDCを使用するアプリケーションが、ws-client
のGPAポリシーが正しく構成され、ターゲットになっている状態でOracle WebLogic Serverドメインにデプロイされている場合に、GPAクライアント・ポリシーを継承することができます。
サービス・ポリシーは、Oracle WebCenter ContentのWebサービス(IdcWebLoginPort
)エンドポイント(LPAモード)に直接添付するか、GPA ws-serviceポリシーをドメイン用に構成して、サービスにより継承することができます。
28.3.3.1 サービスのLPAモードの設定
サービスのLPAモードは、Oracle Enterprise Manager Fusion Middleware Controlを使用して設定できます。
Fusion Middleware Controlを使用してサービスのLPAモードを設定するには:
- Oracle Enterprise Manager 12c Fusion Middleware Controlにログインします。
- 左側のナビゲーション・ツリーで「アプリケーション・デプロイメント」を開き、「Oracle UCM Native Web Services」をクリックします。
- 「Oracle UCM Native Web Service」ページの「アプリケーション・デプロイメント」ドロップダウン・メニューから、「Webサービス」を選択します。
- 「Webサービス(Oracle Infrastructure Web Services)」ページの「Webサービスの詳細」で、「Webサービス・エンドポイント」タブをクリックします。
- 「エンドポイント名」列の「IdcWebLoginPort」をクリックします。
- IdcWebLoginPort (「Webサービス・エンドポイント」)ページで、「OWSMポリシー」タブをクリックします。
- 「直接アタッチされたポリシー」の下で「アタッチ/デタッチ」をクリックし、適切なポリシー(例:
oracle/wss_saml_or_username_token_service_policy
)を選択します。
28.3.3.2 ドメインのGPAサービス・ポリシーの設定
WebLogic Scripting Tool (WLST)のコマンドを使用して、GPAポリシーの継承を構成できます。
WLSTを使用してドメインのGPA ws-serviceポリシーを設定するには:
-
WebLogic Server Administration Scripting Shellを使用して、WebLogic Scripting Tool (WLST)を初期化します。
(/u01/app/oracle/product/Middleware/oracle_common/common/bin)% ./wlst.sh ... Initializing WebLogic Scripting Tool (WLST) ... Welcome to WebLogic Server Administration Scripting Shell Type help() for help on available commands
-
次の
base_domain
というドメインに対する一連のコマンドと類似したコマンドを起動します。$MW_HOME/Oracle_ECM1/common/bin/wlst.sh connect(username='weblogic',password='password',url='t3://localhost:7001') beginRepositorySession() createPolicySet('base_domain-ws-service','ws-service','Domain("base_domain")') attachPolicySetPolicy('oracle/wss_saml_or_username_token_service_policy') validatePolicySet() commitRepositorySession() listPolicySets() exit()
-
GPAサービス・ポリシーが設定されていることを検証します。
-
GPAサービス・ポリシーが
IdcWebLoginPort
によってピックアップされるまでしばらく待ちます。 -
WSDLを検査して
wsp:PolicyReference
を探し、変更が適用されたかどうかを確認します。http://server:16200/idcnativews/IdcWebLoginPort?WSDL
-
GPA Webサービス・クライアント・ポリシーの設定の詳細は、「ドメインのGPAサービス・ポリシーの設定」および「Webサービス・クライアントに対するGPAの追加」を参照してください。
28.3.3.3 ドメインのGPAクライアント・ポリシーの設定
LPAが明示的に設定されていない場合にJAX-WS経由でRIDCによって活用されるWSクライアントに対するGPAポリシーを特定するには、WebLogic Scripting Tool (WLST)を初期化し、WebLogic Server Administration Scripting Shellを使用します。
次にコードの例を示します。
例28-1 WebLogic Scripting Toolを使用したGPAポリシーの特定
(/u01/app/oracle/product/Middleware/oracle_common/common/bin)% ./wlst.sh
...
Initializing WebLogic Scripting Tool (WLST) ...
Welcome to WebLogic Server Administration Scripting Shell
Type help() for help on available commands
wls:/offline> connect('weblogic','password','t3://localhost:7001')
Connecting to t3://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'base_domain'.
wls:/base_domain/serverConfig> help('wsmManage')
Operations that provide support to manage the global policy attachments and
Oracle MDS repository.
help('abortRepositorySession')
Abort the current repository session,
discarding the changes made to repository.
help('attachPolicySet')
Attach a policy set to the specified resource scope.
help('attachPolicySetPolicy')
Attach a policy to a policy set using the policy's URI.
help('beginRepositorySession')
Begin a session to modify the repository.
help('clonePolicySet')
Clone a new policy set from an existing policy set.
help('commitRepositorySession')
Write the contents of the current session to the repository.
help('createPolicySet')
Create a new, empty policy set.
help('deletePolicySet')
Delete a specified policy set.
help('describeRepositorySession')
Describe the contents of the current repository session.
help('detachPolicySetPolicy')
Detach a policy from a policy set using the policy's URI.
help('displayPolicySet')
Display the configuration of a specified policy set.
help('enablePolicySet')
Enable or disable a policy set.
help('enablePolicySetPolicy')
Enable or disable a policy attachment
for a policy set using the policy's URI.
help('exportRepository')
Export a set of documents from the repository into a supported ZIP archive.
help('importRepository')
Import a set of documents from a supported ZIP archive into the repository.
help('listPolicySets')
Lists the policy sets in the repository.
help('migrateAttachments')
Migrates direct policy attachments to global policy attachments
if they are identical.
help('modifyPolicySet')
Specify an existing policy set for modification in the current session.
help('resetWSMPolicyRepository')
Clean the Oracle MDS repository and re-seed with the current set
of WSM policies.
help('setPolicySetDescription')
Specify a description for the policy set selected within a session.
help('upgradeWSMPolicyRepository')
Add newly introduced WSM policies to the Oracle MDS repository.
help('validatePolicySet')
Validate an existing policy set in the repository or in a session.
wls:/base_domain/serverConfig> listPolicySets()
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help(domainRuntime)
Global Policy Sets in Repository:
base-domain-ws-client
wls:/base_domain/serverConfig> displayPolicySet('base-domain-ws-client')
Policy Set Details:
-------------------
Name: base-domain-ws-client
Type of Resources: Web Service Client
Scope of Resources: Domain("base_domain")
Description: Global policy attachments for Web Service Client resources.
Enabled: true
Policy Reference: security : oracle/wss10_saml_token_client_policy, enabled=true
28.3.4 Webサービス・クライアントに対するGPAの追加
次のコードは、WSクライアントのGPAポリシーを設定します。
例28-2 Webサービス・クライアントに対するGPAの追加
# add GPA for the web service client assuming domain name is base_domain beginRepositorySession() createPolicySet('base_domain-ws-client','ws-client','Domain("base_domain")') # assuming service policy is hardcoded to # oracle/wss11_saml_token_with_message_protection_service_policy # and that we want the RIDC client to leverage client policy: # oracle/wss11_saml_token_with_message_protection_client_policy attachPolicySetPolicy ('oracle/wss11_saml_token_with_message_protection_client_policy') validatePolicySet() commitRepositorySession() # confirm policy set created listPolicySets()
# add GPA for the web service client assuming domain name is base_domain beginRepositorySession() createPolicySet('base_domain-ws-client','ws-client','Domain("base_domain")') # assuming service policy is hardcoded to # oracle/wss11_saml_token_with_message_protection_service_policy # and that we want the RIDC client to leverage client policy: # oracle/wss11_saml_token_with_message_protection_client_policy attachPolicySetPolicy ('oracle/wss11_saml_token_with_message_protection_client_policy') validatePolicySet() commitRepositorySession() # confirm policy set created listPolicySets()
28.3.5 デフォルト設定の変更
クライアントの作成後に実行可能な、JAX-WS固有の構成がいくつかあります。ただし、ほとんどの場合、デフォルト設定を使用する必要があります。
このコードは、クライアントをJAX-WSタイプのキャストとしてビルドします。
JaxWSClient jaxwsClient = (JaxWSClient) manager.createClient ("http://wlsserver:7044/idcnativews"); JaxWSClientConfig jaxwsConfig = jaxwsClient.getConfig();
接続先のコンテンツ・サーバーのインスタンス名を設定できます。これはデフォルトで、コンテンツ・サーバーのインストール用のデフォルトWebコンテキストの/cs/
に設定されます。サーバーのWebコンテキストがデフォルトと異なる場合、次のように設定できます。
// set the property jaxwsConfig.setServerInstanceName("/mywebcontext/");
JPS構成ファイルの場所を設定します。JPS構成ファイルは、SAMLやメッセージ・トークンなど、ほとんどのポリシーで必要です。
jaxwsConfig.setJpsConfigFile("/my/path/to/the/jps-config.xml");
次のように、セキュリティ・ポリシーを設定します。
jaxwsConfig.setClientSecurityPolicy("policy:oracle/wss11_username_token_with_message_protection_client_policy");
ログイン・ポートのWSDL URLの変更
RIDCでは、インストールされたWebサービスに対してデフォルト値が使用されます。なんらかの理由でWebサービスが変更されており、デフォルトのURIまたはURLと一致しない場合は、デフォルト値の変更が必要になる可能性があります。
次のように、ログイン・ポートのWSDL URLを変更します。
jaxwsConfig.setLoginServiceWSDLUrl (new URL("http://server:7044/webservices/loginPort?WSDL"));
次のように、リクエスト・サービスURLを変更します。
jaxwsConfig.setRequestServiceWSDLUrl (new URL("http://server:7044/anotherservice/myrequestport?WSDL"));
デフォルトのストリーム・チャンク・サイズは8192です。次の例では、チャンク・サイズを変更します。
jaxwsConfig.setStreamingChunkSize(8190);
28.4 ユーザーの認証
Remote Intradoc Client (RIDC)へのすべてのコールで、認証のためのなんらかのユーザーIDが必要です。オプションで、このID資格証明に、プロトコルで必要なパスワードなど、他のパラメータを添付することができます。ユーザーIDは、IdcContext
オブジェクトに保持されます。いったん作成されると、以降のすべてのコールでそれを再利用できます。コンテキストを作成するには、ユーザー名と、オプションでなんらかの資格証明を渡します。
次のように、(idc://
URLに対して)パスワードなしの単純なコンテキストを作成します。
IdcContext userContext = new IdcContext("weblogic");
次のように、パスワード付きのコンテキストを作成します。
IdcContext userPasswordContext = new IdcContext("weblogic", "password");
Intradoc URLの場合、リクエストがコンテンツ・サーバーとクライアントの間で信頼されているため、資格証明でパスワードは必要ありません。
JAX-WS URLの場合、資格証明の要件は、サーバーによってWebサービスが使用するように構成されているサービス・ポリシーによって異なります。
28.5 サービスの使用
サービスを起動するには、IdcClient
クラス・メソッドを使用します。
public ServiceResponse sendRequest (IdcContext userContext, DataBinder dataBinder) throws IdcClientException
次のコードは、サービス・リクエストを実行し、結果のデータ・バインダを戻します。
Executing a Service Request // get the binder DataBinder binder = idcClient.createBinder(); // populate the binder with the parameters binder.putLocal ("IdcService", "GET_SEARCH_RESULTS"); binder.putLocal ("QueryText", ""); binder.putLocal ("ResultCount", "20"); // execute the request ServiceResponse response = idcClient.sendRequest (userContext, binder);
ServiceResponse
オブジェクトには、コンテンツ・サーバーからのレスポンスが含まれます。このレスポンスから、コンテンツ・サーバーのストリームに直接アクセスできます。または、それをDataBinder
に解析し、結果を問い合せることができます。
次のコードは、ServiceResponse
オブジェクトを取得し、検索結果を取得して、タイトルと作成者の値を出力します。
Get the Binder and Loop Over the Results // get the binder DataBinder binder = response.getResponseAsBinder (); DataResultSet resultSet = binder.getResultSet ("SearchResults"); // loop over the results for (DataObject dataObject : resultSet.getRows ()) { System.out.println ("Title is: " + dataObject.get ("dDocTitle")); System.out.println ("Author is: " + dataObject.get ("dDocAuthor")); }
ストリームを使用する場合、ストリームのクローズはコードで行います。次のコードは、ストリームを閉じます。
Closing a Stream
IdcContext user = new IdcContext ("weblogic", "password");
IdcClientManager manager = new IdcClientManager ();
IdcClient idcClient = manager.getClient ("some url");
DataBinder binder = idcClient.createBinder ();
binder.putLocal ("IdcService", "GET_FILE");
binder.putLocal ("dID", "12345");
ServiceResponse response = idcClient.sendRequest (user, binder);
InputStream stream = null;
try {
stream = response.getResponseStream ();
int read = 0;
int total = 0;
byte[] buf = new byte[256];
while ((read = stream.read (buf)) != -1) {
total += read;
}
} finally {
if (stream != null) {
stream.close ();
}
}
接続プーリングとストリームを介して閉じる方法の詳細は、「接続プーリングの処理」を参照してください。
28.6 接続プーリングの処理
IdcClientConfig#getConnectionPool
プロパティは、RIDCが接続のプーリングをどのように処理するかを決定します。simple
とpool
の2つのオプションがあります。
-
simple
オプションがデフォルトです。simple
オプションでは、接続の最大数の制限は適用されず、すべての接続がブロックされることなく処理されます。ほとんどの場合、このオプションを使用する必要があります。 -
pool
オプションでは、一度にアクティブにする接続数を構成可能な内部プールを使用することが指定されます(IdcClientConfig#getConnectionSize
プロパティを通じて構成可能で、デフォルトのアクティブ・サイズは20
に設定されます)。
通常、RIDCライブラリが、それ自体がアプリケーション・コンテナ内に存在するアプリケーション(Webアプリケーションなど)からの通信に使用される場合、インバウンド・リクエストはすでに調整されています。そのため、simple
オプションを使用することが適切です。pool
オプションを使用する唯一のシナリオは、スタンドアロン・サーバーを作成しており、かつコンテンツ・サーバーの過負荷を生じさせる可能性がある大量の同時コールをコンテンツ・サーバーに対して行う場合です。
IdcClientManager#getConnectionPoolManager()#registerPool()
メソッドによって別のプール実装を登録できます。このメソッドは、名前をConnectionPool
インタフェースの実装にマップします。マップされた名前は、IdcClientConfig
オブジェクトで使用されて、特定のクライアントに対してそのプールが選択されます。
28.7 ストリームの送受信
ストリームは、TransferFile
クラスを通じてコンテンツ・サーバーに送信されます。このクラスは、実際のストリームを、ストリームに関するメタデータ(長さや名前など)とともにラップします。ファイルとストリームのチェックインを可能にするメソッドの詳細は、Oracle Fusion Middleware Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。
次のコードは、コンテンツ・サーバーへのチェックインを実行します。
Content Server Check-In // create request DataBinder binder = idcClient.createBinder(); binder.putLocal ("IdcService", "CHECKIN_UNIVERSAL"); // get the binder binder.putLocal ("dDocTitle", "Test File"); binder.putLocal ("dDocName", "test-checkin-6"); binder.putLocal ("dDocType", "ADACCT"); binder.putLocal ("dSecurityGroup", "Public"); // add a file binder.addFile ("primaryFile", new TransferFile ("test.doc")); // check in the file idcClient.sendRequest (userContext, binder);
コンテンツ・サーバーからのレスポンス
コンテンツ・サーバーからのストリームは、ServiceResponse
オブジェクトを通じて受信されます。使用可能なメソッドのサマリーは、『Oracle Fusion Middleware Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンス』を参照してください。
特に要求されないかぎり、レスポンスは、DataBinderに変換されません。単に未加工のHDAデータが必要な場合は、それを直接取得し、レスポンスをStringまたはDataBinderに変換できます。
次のコードは、サービスを実行し、レスポンスを文字列として取得して、それをデータ・バインダに解析します。
Parsing a String into a DataBinder // create request DataBinder binder = idcClient.createBinder (); // execute the service ServiceResponse response = idcClient.sendRequest (userContext, binder); // get the response stream InputStream stream = response.getResponseStream (); // get the response as a string String responseString = response.getResponseAsString (); // parse into data binder DataBinder dataBinder = response.getResponseAsBinder ();
コンテンツ・サーバーのほとんどのサービス・リクエストは、クライアント上でDataBinderを使用してモデル化される構造化HDAペイロードを返します。HDAペイロードは基本的にマップのような構造であり、オプションとして、表に似たResultSetが含まれています。
ダウンロード・スタイルのサービス・リクエスト(GET_FILE
など)は通常、リクエストされたドキュメントのコンテンツをRAWバイト・ストリームとして返すと予想されています。ただし、GET_FILE
リクエストに指定されたパラメータが無効な場合、またはエンド・ユーザーの権限が十分でない場合などには、コンテンツ・サーバーは、エラー情報を含めたHDAペイロードで応答することがあります。したがって、GET_FILE
のようなリクエストを実行するときには、次に示すように、ServiceResponse
オブジェクトに質問して、返されるレスポンス・タイプを決定する必要があります。
Response Type Returned DataBinder binder = idcClient.createBinder (); binder.putLocal ("IdcService", "GET_FILE"); binder.putLocal ("dID", "12345"); ServiceResponse response = idcClient.sendRequest (user, binder); if (response.getResponseType().equals(ServiceResponse.ResponseType.BINDER)) { DataBinder responseBinder = response.getResponseAsBinder(false); // do not check for errors int statusCode = m_binder.getLocalData ("StatusCode").getInteger("StatusCode"); String statusMessage = m_binder.getLocal ("StatusMessage"); throw new IllegalStateException("Download response was not a stream - Error: " + statusCode + " - " + statusMessage); }
28.8 複数のリクエストに対するバインダの再利用
バインダは、複数のリクエスト間で再利用できます。あるリクエストからのバインダを別のリクエストに送信できます。あるコールからのバインダを次のコールで再利用する場合、次のコールに影響する可能性のあるものがバインダに残っていないように、細心の注意を払う必要があります。RIDCは、各コールの後にバインダをクリーンアップしません。
次のコードは、コンテンツ・サーバーへの複数のコールで同じバインダを再利用することで、検索結果をページングする例を示しています。
Reusing Binders // create the user context IdcContext idcContext = new IdcContext ("sysadmin", "idc"); // build the search request binder DataBinder binder = idcClient.createBinder(); binder.putLocal("IdcService", "GET_SEARCH_RESULTS"); binder.putLocal("QueryText", ""); binder.putLocal("ResultCount", "20"); // send the initial request ServiceResponse response = idcClient.sendRequest (idcContext, binder); DataBinder responseBinder = response.getResponseAsBinder(); // get the next page binder.putLocal("StartRow", "21"); response = idcClient.sendRequest (idcContext, binder); responseBinder = response.getResponseAsBinder(); // get the next page binder.putLocal("StartRow", "41"); response = idcClient.sendRequest (idcContext, binder); responseBinder = response.getResponseAsBinder();
28.9 ユーザー・セキュリティの設定
コンテンツ・サーバーには、コンテンツ・サーバー上の設定によって制御されるいくつかのセキュリティ・モデルがあります。特定のユーザーがあるドキュメントへのアクセス権を持っているかどうかを判断するには、ユーザーの権限コントロール、ドキュメントの権限コントロール、コンテンツ・サーバーのセキュリティ環境設定という3つのものが必要です。
UserSecurityモジュールをコールするアプリケーション・プログラムは、スーパーユーザーとして(ドキュメントのバインダ、通常は検索結果で)ドキュメントおよびDOC_INFOメタデータをフェッチし、その情報をキャッシュすると想定されます。アプリケーション・プログラムで、特定のユーザーがドキュメントへのアクセス権を持っているかどうかを把握する必要がある場合、そのユーザーの権限をフェッチするために、そのユーザーとしてコンテンツ・サーバーへのコールが行われます。いったんユーザーの権限コントロールが把握されると、それらをドキュメントのメタデータ内の情報と照合してそのユーザーのアクセス・レベルを判断することができます。(アクセス・レベルは、READ、READ/WRITEまたはREAD/WRITE/DELETEです)。したがって、必要なのは、(キャッシュによって)コンテンツ・サーバーへのコール数を減らし、ユーザーの権限情報とドキュメントの権限情報を照合するデフォルトの実装を用意することです。さらに複雑化させる1つの要因は、コンテンツ・サーバーが一部のサーバー環境プロパティ(UseAccounts=true
およびUseCollaboration=true
またはUseEntitySecurity=1
)でどのセキュリティのタイプが使用されるかを制御することです。さらに、メソッドによって、そのドキュメントのセキュリティ・タイプに管理者権限が割り当てられているかどうかをテストすることができます。
ユーザー・セキュリティ・コンビニエンスには、IUserSecurityCache
インタフェースを通じてアクセスできます。それらのクラスは、オプションのコンテンツ・サーバー・セキュリティを実装します。
-
UserSGAcctAclCache
クラスは、常にコールする必要があります。このクラスは、セキュリティ構成についてコンテンツ・サーバーをチェックし、それに合せて自身を内部的に調整します。 -
UserSecurityGroupsCache
クラスは、ユーザー権限のキャッシュを保持し、セキュリティ・グループ情報のみを考慮してドキュメントを照合します。このクラスを直接コールしないでください。UserSGAcctAclCache
クラスは、セキュリティ構成についてコンテンツ・サーバーをチェックし、それに合せて自身を内部的に調整します。 -
コンテンツ・サーバーにUseAccounts=true設定がある場合、
UserSGAccountsCache
クラスは、アカウント情報も考慮するためのリゾルバを追加します。このクラスを直接コールしないでください。UserSGAcctAclCache
クラスは、セキュリティ構成についてコンテンツ・サーバーをチェックし、それに合せて自身を内部的に調整します。
次のコードは、ユーザー・セキュリティの設定の例を示しています。
Setting User Security IdcClientManager m_clientManager = new IdcClientManager (); IdcClient m_client = m_clientManager.createClient ("http://localhost/scs/idcplg"); //RIDC superuser context IdcContext m_superuser = new IdcContext("sysadmin", "idc"); //This class will self-adjust (downwards) to match the security model // on Content Server. IUserSecurityCache m_userSecurityCache = new UserSGAcctAclCache (m_client, 20, 1000, 20000, m_superuser); ITrace trace = null; //Example test testDocPermission () { //If you don't want to do any logging, you can leave trace as null if (m_log.isLogEnabled(ILog.Level.TRACE)) { trace = new Trace (); } DataBinder m_doc1 = getDataBinder ("TEST"); //Get the document information (typically in the first row of DOC_INFO) DataObject docInfo = m_doc1.getResultSet ("DOC_INFO").getRows ().get (0); //Get the cache id for this user //This makes a live call to content server to get the user ID for "Acme1" //CacheId acme1 = m_userSecurityCache.getCacheIdForUser // (new IdcContext("Acme1", "idc"), trace); IdcContext context = new IdcContext("Acme1", "idc"); CacheId acme1 = new CacheId (context.getUser (), context); //Get the access level for this document by this user int access = m_userSecurityCache.getAccessLevelForDocument (acme1, docInfo, trace); //Check if user has ACL admin permissions boolean aclAdmin = m_userSecurityCache.isAdmin (acme1, docInfo, IUserSecurityCache.AdminType.ACL, trace); if (m_log.isLogEnabled(ILog.Level.TRACE)) { m_log.log (trace.formatTrace (), ILog.Level.TRACE); } } //Example code to get a Document's DOC_INFO databinder DataBinder getDataBinder (String dDocName) throws IdcClientException { DataBinder dataBinder = m_client.createBinder (); dataBinder.putLocal ("IdcService", "DOC_INFO_BY_NAME"); dataBinder.putLocal ("dDocName", dDocName); ServiceResponse response = m_client.sendRequest (m_superuser, dataBinder); return response.getResponseAsBinder (); } //Example code to create a DataObject DataObject dataObject = m_client.getDataFactory ().createDataObject (); dataObject.put ("dSecurityGroup", "public"); dataObject.put ("dDocAccount", "Eng/Acme");
内部的に、ドキュメントからのこれらのフィールドは、getAccessLevelForDocument()
の間に調査されます。
-
AccessResolverSecurityGroups
クラスの場合:dSecurityGroup
-
AccessResolverAccounts
クラスの場合:dDocAccount
-
AccessResolverSecurityGroups
クラスの場合:xClbraUserList
、xClbraAliasList
およびxClbraRoleList
IAccessResolver
クラスは、コンテンツ・サーバーからキャッシュされた情報に基づいて参加するかどうかを決定します。参加する場合、複数のアクセス・レベルは論理積(AND)になります。hasAdmin()
メソッドを使用して、管理アクセス権があるかどうかを判断できます。
28.10 RIDCフィルタの使用
Remote Intradoc Client (RIDC) 12cでは、DataBinderが処理されてコンテンツ・サーバーに送信される前に、アプリケーション・コードでフィルタを追加することが可能です。IdcFilterAdapter
クラスのいずれかを拡張してフィルタを作成し、そのフィルタを登録してIdcFilterManager
クラスで実行できます。フィルタは、登録時に指定された順番で実行されます。すでに登録済のフィルタを取得したり、削除したりすることもできます。
次のコードは、アダプタを拡張し、アクションを実行するメソッドをオーバーライドします。
Calling RIDC Filter Before Service Request public class IdcFilterAddComment extends BeforeServiceRequestFilter { @Override public void beforeServiceRequest (IdcClient client, IdcContext context, DataBinder binder) throws IdcClientException { String existingComments = binder.getLocal("xComments"); if (existingComments != null) { binder.putLocal("xComments", String.format ("%s %s", existingComments, "--DGT WAS HERE--")); } else { binder.putLocal("xComments", "--DGT WAS HERE--"); } } }
Remote Intradoc Client (RIDC) 12cでは、JAX-WS処理領域にさらに2つのフィルタの場所が提供されます。それらのフィルタを使用するには、BeforeJaxwsServiceFilter
クラスを拡張します。
次のコードは、BeforeJaxwsServiceFilter
クラスを拡張します。
Calling RIDC Filter Before JAX-WS Call /** * RIDC filter called just before jaxws call is made to * loginPort.contentServerLogin () in authenticateUser () **/ public void beforeJaxwsAuthenticateUser (IdcContext context, DataBinder binder, Map<String, Object> requestContext) throws IdcClientException { requestContext.put(oracle.wsm.security.util.SecurityConstants. ClientConstants.WSM_SUBJECT_PRECEDENCE, “false"); } /** * RIDC filter called just before jaxws call is made to * loginPort.contentServerRequest () in performServiceRequest () **/ public void beforeJaxwsServiceRequest (IdcContext context, DataBinder binder, Map<String, Object> requestContext) throws IdcClientException { //Override this class and implement your filter here }
次のコードは、フィルタ・クラス(複数可)を登録します。
Register Filer Classes // If you are at the start of a pure RIDC application, you typically // will create a ClientManager, for example: IdcClientManager m_clientManager = new IdcClientManager(); // New method added to IdcClient to get the ClientManager // if you do not have the ClientManager instance: IdcClient client = myClient; client.getClientManager(); // From the ClientManager, you can get the FilterManager: IdcFilterManager fmanager = m_clientManager.getFilterManager(); // Then register your filter: IIdcFilter addCommentFilter = new IdcFilterAddComment(); int slot = fmanager.registerFilter(100, addCommentFilter); // Optionally, you can deregister. However, it might not be in the slot you // assigned because there might have already been a filter in that slot. // When registering, the next available higher slot will be used. You also need // to pass in the instance currently in the slot you want to remove: fmanager.deRegisterFilter(slot, addCommentFilter); // Here is an example to remove all the filters, // including the ones you did not register for (Integer slot:fmanager.getUsedSlots()) { fmanager.deRegisterFilter(slot, fmanager.getFilter (slot)); }