WebLogic Portal での WSRP の使用
|
 |
 |
|
WSRP 標準では、現在具体的なセキュリティ標準は施行されていませんが、WSRP 準拠のポートレットの実装時には WS-Security や SAML などのセキュリティ標準に従うように推奨されています。WSRP 標準では、コンシューマがエンドユーザに代わってプロデューサを呼び出す場合のセキュリティの問題に対処するために、SSL/TLS などの転送レベルのセキュリティ標準の使用が強く推奨されています。これらのセキュリティ標準では、プロデューサの WSDL で HTTPS サービスのエントリ ポイント用のポートを宣言することが要求されているだけです。コンシューマでは、サービスのエントリ ポイントのアクセス制御については、URL を解析することにより、セキュアな転送がサポートされているかどうかを判別することしかできません。
注意 : ポートレットが Web アプリケーション リソースを使用する場合、それらのリソースに対してはセキュリティ制約が適用されないというのは、J2EE セキュリティの一般的な制限です。この制限は、リモート ポートレットとローカル ポートレットの両方に該当します。この制限に対処するために、コンシューマ ポータルに対して資格を使用し、特定のコンテンツへのアクセスを制限することをお勧めします。
この節では、実行をお勧めするいくつかのセキュリティ対策について説明します。ここでは、以下のトピックについて説明します。
実装されたセキュリティ対策を実施することにより、プロデューサとコンシューマの両方でアクセスを制御できるようになります。
WSRP 標準ではセキュリティ要件は指定されていませんが、以下の推奨事項は WSRP 準拠のポートレットのセキュアな実装を確実に行うためのガイドラインになります。
基本的なルールおよびベスト プラクティスとして、管理者はプロダクション環境で実行するすべての Web アプリケーションとそのリソースを保護する必要があります。セキュリティが特に重要となるのは、WSRP でリソース URL (プロデューサのファイルや画像へのリンク) を使用する場合です。WSRP 1.0 仕様に従って、リソース URL は絶対 URL であり、最終的な URL の一部となります。これは、wsrp-url パラメータで確認できます。
ブラウザでポータル ページのソースを表示すると、リソース URL がわかります。これらの URL により、プロデューサ マシン上の Web アプリケーション ホストへの URL が提供されるため、プロデューサ上のすべてのリソースを保護することが重要です。たとえば、この情報を使用して、ユーザがプロデューサ上の WebLogic Server Console などの URL を推測し、直接にアクセスを試みる可能性があります。
警告 : プロデューサの管理者は、Web アプリケーションとリソースを適切に保護する必要があります。
WebLogic Server へのセキュリティ制約の追加については、以下の URL にある「URL (Web) リソースおよび EJB (エンタープライズ JavaBean) リソース」および「security-constraint」を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs81/secwlres/types.html#1208206
http://edocs.beasys.co.jp/e-docs/wls/docs81/webapp/web_xml.html#1017885
前の節で説明したように、wsrp-url パラメータはプロデューサ マシンのリソース URL を公開します。
デフォルトでは、コンシューマは、コンシューマが現在認識している WSRP プロデューサのホスト マシンでホストされている URL へのアクセスを許可します。これらのプロデューサは、WebLogic Workshop、Portal Administration Portal、または WebLogic Portal API でコンシューマに追加されたものです。このデフォルトの動作をオーバーライドするには、次の手順を実行します。
com.bea.wsrp.consumer.resource.ResourceConnectionFilter インタフェースを実装するクラスを作成します。このインタフェースにはメソッドが 1 つ含まれます。public boolean allowedURL(String url);
このメソッドを実装すると、wsrp-url パラメータによるアクセスを許可する URL の場合にのみ true を返します。
この実装クラス ファイルを WEB-INF/lib/classes に置きます。たとえば、WEB-INF/lib/classes/MyResourceProxyServletImpl.class です。
WEB-INF/web.xml ファイルの ResourceProxyServlet 定義に <init-param> 要素を追加します。<param-name> は resourceConnectionFilter に、<param-value> は ResourceConnectionFilter 実装クラスの完全修飾クラス名に設定する必要があります。 コード リスト 9-1 は、ResourceProxyServlet サーブレット定義のサンプルを示します。
コード リスト 9-1 ResourceProxyServlet のコンフィグレーション (WEB-INF/web.xml)
<servlet>
<servlet-name>ResourceProxyServlet</servlet-name>
<servlet-class>com.bea.wsrp.consumer.resource.ResourceProxyServlet</servlet-class>
<init-param></servlet>
<param-name>resourceConnectionFilter</param-name>
<param-value>myClasses.MyResourceProxyServletImpl</param-value>
</init-param>
WSRP メッセージの安全確保により、関係者間のみで機密を保持できます。ポートレットのメッセージングの安全確保を行うと、そのポートレットのメッセージの内容を処理することを許可された人物のみがメッセージを見ることができます。WSRP メッセージの安全を確保するには
WEB-INF/wsrp-producer-config.xml ファイルの <service-config> 要素内のすべての secure 属性に "true" を指定することにより、プロデューサがセキュアなポートレットを提供するようにコンフィグレーションする。コード リスト 9-2 セキュリティ用にコンフィグレーションされた <service-config> 要素
<service-config>
<registration required="true" secure="true"/>
<service-description secure="true"/>
<markup secure="true"rewrite-urls="true" transport="string"/>
<portlet-management required="true" secure="true"/>
</service-config>
注意 : wsrp-producer-config.xml を変更した場合、変更をアクティブにするにはサーバを再デプロイまたはバウンスする必要があります。
シングル サインオン (SSO) は、1 回のアクションでユーザの認証と許可を行い、アクセス パーミッションが付与されているすべてのコンピュータやシステムにユーザがアクセスできるようにするメカニズムです。複数のパスワードを入力する必要がありません。シングル サインオンは、システム障害の大きな要因である人的エラーを削減する機能です。
SSO サポートは、コンシューマからプロデューサにユーザ ID を伝播するためのものです。つまり、コンシューマが認証を行い、WSRP スタックは、ユーザが対話する各プロデューサで同じユーザ ID が確立されるようにします。実際の動作を確認する最適な方法は、プロデューサ側またはコンシューマ側の SOAP メッセージ ログをモニタすることです。コンシューマ側でのログイン後、各リクエストには追加の SOAP ヘッダが含まれています。
各 Web アプリケーションには、SOAP メッセージを記録するモニタがあります。モニタを表示するには、http://<machine>:<port>/<webapp>/monitor にアクセスしてください。SOAP メッセージのモニタの詳細については、次の URL にある「プロデューサおよびコンシューマのメッセージ ログのモニタ」を参照してください。
http://edocs.beasys.co.jp/e-docs/wlp/docs81/wsrp/monlog.html#999496
プロデューサは、クライアント証明書と SSL/TLS を組み合わせて使用することによってコンシューマを認証します。したがって、推奨に従って SSO を使用し、ユーザがコンシューマ ポータルにログインできるようにしている場合は、プロデューサはそのコンシューマを信頼する必要があります。この信頼を確立するために、コンシューマに VeriSign, Inc. などの承認された認証局 (CA) によって署名された認証証明書が必要です。この節では、Java keytool ユーティリティを使用して自己署名証明書を生成する方法を説明します。この章の後半では、CA からの署名付き証明書の取得も含め、keytool の詳しい使用例を示します。
WebLogic Platform をインストールすると、インストール プロセスの一部として、Java 実行時環境 (Java Runtime Environment : JRE) がインストールされます。JRE 内には、keytool.exe というユーティリティが含まれます。keytool は、鍵と証明書の管理ユーティリティで、これを使用して、公開鍵/プライベート キーのペア、およびこれらに関連付けられた自己認証 (ユーザが他のユーザやサービスに対して自分自身を認証すること) 用の証明書を管理したり、デジタル署名を使用してデータの整合性や認証サービスを管理することができます。
WSRP 準拠のポートレットでセキュリティを実装する際には、以下の用語について理解しておく必要があります。
公開鍵証明書とも呼ばれる。あるエンティティ (発行者) からのデジタル署名されたステートメントで、別のエンティティ (サブジェクト) の公開鍵 (およびその他の情報) が何らかの特定の値を持っていることを示します。
認証局に送られるファイル。認証局は、証明書要求者 (通常オフライン) を認証し、要求者に証明書または証明書チェーンを返します。CSR は、キーストア内の既存の証明書チェーン (最初は自己署名証明書で構成される) を置き換えるために使用されます。
プライベート キー、およびそれに関連付けられた X.509 証明書チェーン (プライベート キーに対応する公開鍵の認証に使用される) のデータベース。キーストア ファイルには、拡張子 .jks が付きます。このキーストアのスコープはドメインであるため、キーストアは <BEA_HOME>/user_projects/domains/specificDomain フォルダ (specificDomain は、安全確保するポイントを含むアプリケーションのドメイン) にあります。WebLogic Platform には、wsrpKeystore.jks という名前のデフォルトのキーストアが含まれています。このファイルを実行する予定のドメインごとに、ファイル名を変更することを強くお勧めします。名前を変更しないと、アプリケーションのセキュリティが損なわれます。
keytool は、Sun Microsystems によって作成されたものです。このユーティリティの詳細については、以下の URL にある「keytool - Key and Certificate Management Tool 」を参照してください。
http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html
デフォルトでは、プロデューサ サーブレットは保護されていません。プロデューサへのアクセスを制限するには、パス <webAppPath>/producer をネットワークまたはファイアウォール レベルで保護します (webAppPath は Web アプリケーションの URL)。
以下の例は、コンシューマからプロデューサへの SSO を確立する方法を示します。この単純な例では、コンシューマのローカル ポートレットからリモート ポートレットにログインできるようにします。
この実習を行う前に、前の節「ユーザ ID の管理」を必ず読んでください。
この例で必要な環境を設定するには、「リモート ポートレットでのポートレット間通信の確立」の「手順 1 : 環境の設定」を参照してください。この節の手順に従います。すでに「手順 1: 環境の設定」どおりに環境を設定している場合は、この手順を実行する必要はありません。
注意 : <BEA_HOME>/user_projects フォルダを壊さないように、「リモート ポートレットでのポートレット間通信の確立」と同じ環境を使用することを強くお勧めします。新しいドメインまたはポータル アプリケーション (あるいはその両方) でこの実習を行う場合は、次の手順でコンポーネントに選択する名前を置き換えてください。
この手順では、BEA 提供のログイン コントローラ ページ フローを使用して、ログイン ポートレットをコンシューマに作成します。また、単純な JSP ポートレットをプロデューサに作成します。次に、JSP ポートレットとコンシューマを結合します。その後、ログイン ポートレットを使用してリモート ポートレットへのログインを試行します。
[ページ フロー ウィザード - ページ フロー名] ダイアログ ボックスが表示されます (図 9-1)。
図 9-1 [ページ フロー ウィザード - ページ フロー名] ダイアログ ボックス
[ページ フロー ウィザード - ページ フロー タイプを選択] ダイアログ ボックスが表示されます (図 9-2)
図 9-2 [ページ フロー ウィザード - ページ フロー タイプを選択] ダイアログ ボックス
[ページ フロー ウィザード - アクションを選択] ダイアログ ボックスが表示されます (図 9-3)。
図 9-3 [ページ フロー ウィザード - アクションを選択] ダイアログ ボックス
ページ フロー ファイルが作成されます。LoginController.jpf がアプリケーション ツリーの consumerWeb の下に表示され、ページ フロー図が IDE ワークスペースに表示されます (図 9-4)。
図 9-4 IDE ワークスペースでの LoginController.jpf ページ フロー
図 9-5 LoginController.jpf のソース
com.bea.p13n.usermgmt.profile.ProfileWrapper var = myControl.login
(aForm.username, aForm.password, aForm.request );
com.bea.p13n.usermgmt.profile.ProfileWrapper var = myControl.login
(aForm.username, aForm.password,super.getRequest());
呼び出しは、コード リスト 9-2 の例のようになります。
コード リスト 9-3 更新された Forward login(LoginForm aForm) 呼び出し
public Forward login(LoginForm aForm)
throws Exception
{
com.bea.p13n.usermgmt.profile.ProfileWrapper var =
myControl.login(aForm.username, aForm.password,
super.getRequest() );
getRequest().setAttribute("results", var);
return new Forward("success");
}
LoginController.jpf がアプリケーション ツリーの consumerWeb/login の下に表示されます (/login は LoginController.jpf を保存したときに作成されます。図 9-6 を参照)。
図 9-6 consumerWeb/login 内の LoginController.jpf
ポートレット ウィザードの [ポートレットの詳細] ダイアログ ボックスが表示されます (図 9-7)。
図 9-7 LoginController.jpf のポートレット ウィザードの [ポートレットの詳細] ダイアログ ボックス
この手順では、「ログイン ページ フロー ポートレットの作成」で作成したログイン ポートレットを含めるポータルを作成します。
login.portal がアプリケーション ツリーの consumerWeb/login の下に表示され、ポータルのレイアウトが WebLogic Workshop ワークスペースに表示されます (図 9-8)。
図 9-8 WebLogic Workshop ワークスペースでの login.portal
LoginController.portlet] をポータル レイアウトの左側の欄にドラッグします。図 9-9 ポータル レイアウトでの LoginController.portlet
次に、プロデューサに JSP ファイルとポートレットを作成します。これは、「ログイン ポータルの作成」で作成したコンシューマ ポータルに結合するポートレットです。また、ログイン ポータルをテストするときは、このポートレットへのログインを試行します。
cPortlet.jsp と入力して、[作成] をクリックします。cPportlet.jsp が WebLogic Workshop ワークスペースに表示されます (図 9-10)。
図 9-10 デザイン ビューでの cPortlet.jsp
cPortlet.jsp ソース コードと置き換えます。<%
String username=null;
if(request.getUserPrincipal() !=null ){
username=request.getUserPrincipal().getName();
}
%>
Username = <%=username%>
WebLogic Workshop ワークスペースは、図 9-12 の例のようになります。
cPortlet.jsp の [ポートレットの詳細] ダイアログ ボックスが表示されます (図 9-13)。
図 9-13 cPortlet.jsp の [ポートレットの詳細] ダイアログ ボックス
次は、「プロデューサでのポートレットの作成」で作成した JSP ポートレットをコンシューマに表示しますそのためには、次の手順に従います。
注意 : WebLogic Workshop が実行中であることを確認します。
[プロデューサの検索] セクションと [プロデューサの選択] セクションがあるダイアログ ボックスが表示されます (図 9-15)。[プロデューサの検索] があらかじめ選択されています。
図 9-15 [プロデューサの検索] または [プロデューサの選択] ダイアログ ボックス
http://localhost:7001/producerWeb/producer?WSDL
[リストからポートレットを選択] ダイアログ ボックスが表示されます (図 9-16)。
図 9-16 [リストからポートレットを選択] ダイアログ ボックス
cPrime.portlet がアプリケーション ツリーの consumerWeb の下に表示され、ポートレットのレイアウトが WebLogic Workshop ワークスペースに表示されます (図 9-17)。
最後に、リモート ポートレットにログインできることを確認するために、「ログイン ページ フロー ポートレットの作成」で作成したログイン ポートレットをテストする必要があります。テストが成功したら、アプリケーションを「分割」します。これで、リモート ポートレットへのログインを防ぎます。
注意 : WebLogic Server が実行中であることを確認します。
cPrime.portlet の名前です。データ パレットが表示されていない場合は、[表示｜ウィンドウ｜データ パレット] を選択します。図 9-18 cPortlet が追加された login.portal
しばらくすると、ポータルがブラウザに表示されます (図 9-19)。
図 9-19 ブラウザに表示された login.portal
cPortlet には「Username = null」というテキストが表示されています。
LoginController が更新され、ログインのためのフィールドが表示されます (図 9-20)。
図 9-20 LoginController.portlet のログイン フィールド
[Password] と [Username] の両方に weblogic と入力し、[Submit] をクリックします。
ポータルが更新されます。cPortlet には「Username = weblogic」と表示されます。
この手順では、ポータルを構築するために必要なすべてのコンポーネントを作成しました。これにより、プロデューサからこのポータルに結合されたポートレットにログインすることができます。次に、デフォルトのリソースを組み合わせてログイン ポータルを構築し、ポータルをブラウザに表示し、リモート ポートレットにログインしました。次の手順では、このポータルを「分割」します。
この手順では、キーストア ファイルの名前を変更します。名前の変更により、login.portal でのリモート ポートレットへのログインを防ぎます。次に、ポータルへのログインを試行して、ログインに失敗することで、ポータルにログインできないことを確認します。
.jks ファイルの名前を変更するには、次の手順に従います。
注意 : WebLogic Workshop が実行中であることを確認します。
ここで、ログイン ポータルを起動し、リモート ポートレットへのログインを再試行します。この手順は、次のとおりです。
注意 : アプリケーション ipcWsrpTest が開いている必要があります。
login.portal がすでに開いている場合は、この手順を省略できます)。図 9-22 ログイン試行失敗時の login.portal
この手順では、Java keytool ユーティリティを使用して、自己署名証明書を作成し、その過程で新しいキーストアを作成します。次に、証明書署名要求 (CSR) を生成し、その CSR を認証局 (CA) に送信します。CA から返される署名付き証明書を使用して、リモート ポートレットへのログインを確立します。
この手順を開始する前に、「Java keytool ユーティリティ」を必ず読んでください。以下の URL にある「keytool - Key and Certificate Management Tool」の情報も確認することをお勧めします。
http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html
注意 : <BEA_HOME> は、WebLogic Platform をインストールしたディレクトリです。
注意 : keytool ユーティリティのスコープは使用している JVM です。WebLogic Server の実装のコンフィグレーションで別の JVM を選択した場合 (たとえば BEA WebLogic JRockit)、その JVM のディレクトリに移動して以下のコマンドを実行する必要があります。
<BEA_HOME>\jdk142_05\bin>keytool -genkey -keypasstestkeypass-keystore <BEA_HOME>\user_projects\domains\ipcWsrpDomain\wsrpKeystore.jks-storepassteststorepass-aliastestalias
testkeypass は、生成された鍵ペアのプライベート キーの保護に使用されるパスワード。\user_projects\domains\ipcWsrpDomain\ は、ドメイン ディレクトリ。wsrpKeystore は、新しい .jks ファイル。teststorepass は、キーストアの整合性の保護に使用されるパスワード。testalias は、エリアスとして指定した名前。キーストア内のエンティティへのアクセスに使用されます。注意 : 詳細なオプション一覧については、以下の URL にある「keytool - Key and Certificate Management Tool」を参照してください。
http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html
keytool のオプションは、必須ではありません。オプションを指定しなかった場合、デフォルト値を持つオプションについてはデフォルトが使用され、必要な値があればプロンプトが表示されます。
これまでに自己署名証明書を生成しました。認証局 (CA) によって署名されている証明書は信頼を得やすくなるため、CA の署名を取得するために証明書署名要求 (CSR) を生成する必要があります。CSR を作成するには、次の手順に従います。
keytool -certreq -keystore<BEA_HOME>\user_projects\domains\ipcWsrpDomain\wsrpKeystore.jks -alias testalias
システムが応答し、以下のように表示されます。
キーストアのパスワードを入力してください:
システムが応答し、以下のように表示されます。
<mykey> の鍵パスワードを入力してください。
-----BEGIN NEW CERTIFICATE REQUEST-----
MIICYzCCAiACAQAwXjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNPMRAwDgYDVQQHEwdCb3VsZGVy
MRQwEgYDVQQKEwtCRUEgU3lzdGVtczENMAsGA1UECxMERG9jczELMAkGA1UEAxMCRWQwggG3MIIB
LAYHKoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZ
PY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7V+fGqKYVDwT7
g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCPFSMLzLKSuYKi64QL8Fgc9QKB
gQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wLPQeCZ1FZV4661FlP5nEHEIGAtEkWcSPoTCgW
E7fPCTKMyKbhPBZ6i1R8jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD3+Fa5Z8G
kotmXoB7VSVkAUw7/s9JKgOBhAACgYBkQ10+BRJVVzMgZTQJiUDYdK+5WOI1EkvXbyZPmvYzAfch
vtR7WKJZMPcbAyq9mtrOXFY7TTEkupXlY4R8c5DdLW0db3YB1eV4gUGQOXn4Y+zE8Z4LxKNhkKLk
yEUQhv0JkyzIReV7sioJahf7AiOwqs2cW1r4dNt4y42duwrdsKAAMAsGByqGSM44BAMFAAMwADAt
AhRARh4iBbioO+Jn3qc/bXOpjr+cqgIVAI78/s8hMqhFkTJxt/qtE3L3F1aP
-----END NEW CERTIFICATE REQUEST-----
注意 : .pem ファイルの CA への送付については、このドキュメントでは説明しません。使用できる CA は多数ありますが、会社がすでに特定の CA と契約を結んでいることもあります。契約によって CSR の送付方法が定められます。CA の Web サイトにアクセスして、送付プロセスを確認することもできます。
CA からは、コンシューマ証明書と CA 証明書の 2 つが返されます。CA 証明書は、コンシューマ証明書の CA の署名を保証するために使用されます。keytool -import コマンドを使用して、CA 署名付き証明書とコンシューマ証明書の両方をキーストアに格納します。
注意 : 使用する CA によっては、両方の証明書が 1 つのファイルで返されることがあります。Internet Explorer の証明書インポート/エクスポート ウィザードなど証明書変換ツールを使用して、2 つの証明書に分ける必要があります。このプロセスはこのドキュメントでは説明しません。会社のセキュリティ管理者または使用している CA に問い合わせてください。
これから、コンシューマ証明書と CA 証明書の両方をキーストアにインポートします。インポート コマンドを実行するときは、この後の手順で説明するように、証明書ごとに異なるエリアスを使用する必要があります。
keytool -import -alias testalias -file<BEA_HOME>\user_projects\domains\ipcWsrpDomain\wsrpKeystore.pem -keypass testkeypass -keystore<BEA_HOME>\user_projects\domains\ipcWsrpDomain\wsrpKeystore.jks -storepass teststorepass
注意 : -import コマンドの使用方法の詳細については、以下の URL を参照してください。
http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html#importCmd
Owner: CN=Your Name, OU=WLP Docs, O=WLP, L=Boulder, ST=Colorado, C=US
Issuer: CN=Thawte Test CA Root, OU=TEST TEST TEST, O=CA NameCertification, ST=FO
R TESTING PURPOSES ONLY, C=ZA
Serial number: 121e
Valid from: Mon Dec 13 11:18:17 MST 2004 until: Mon Jan 03 11:18:17 MST 2005
Certificate fingerprints:
MD5: 87:29:4B:7F:02:7D:2B:90:EF:FA:7D:02:50:82:7D:FF
SHA1: 25:08:1E:98:7D:76:31:48:B3:6B:4B:5F:81:24:59:1D:41:CA:A2:DB
この証明書を信頼しますか? [no]:
CAcert.pem というファイルに保存します。keytool -import コマンドを実行するとき、.pem ファイル名 (-file) とエリアス (-alias) として以下の値を使用します。 -file <BEA_HOME>\user_projects\domains\ipcTestDomain\CAcert.pem
-alias CAtestalias
以下を実行して、コンシューマ MBean を新しい証明書情報で更新します。
コンフィグレーション設定のページが表示されます (図 9-23)。
右側のペインに [WSRP Consumer Security Service のコンフィグレーション設定] ダイアログ ボックスが表示されます (図 9-24)。
図 9-24 [WSRP Consumer Security Service のコンフィグレーション設定] ダイアログ ボックス
プロデューサがコンシューマを信頼するためには、コンシューマの署名付き証明書を認識できる必要があります。この認識を確実にするには、プロデューサにコンシューマの公開鍵を提供する必要があります。この公開鍵は、管理者がプロデューサのキーストアに追加する必要があります。
WSRP ID アサータを更新するには、以下の手順を実行します。
http://localhost:7001/console
注意 : フィールド ラベルの横に黄色のアイコンが点滅している場合は、変更を有効にするためにサーバを再起動する必要があります。
新しいキーストアをテストするには、「ログイン ポートレットのテスト」と同様にリモート ポートレットへのログインを試行します。次の手順を実行します。
ポータル ドメインのポータル アプリケーションの META-INF ディレクトリには、application-config.xml ファイルが含まれます。ポータル ドメインを新規作成してポータル アプリケーションをデプロイする場合は、このファイルには暗号化されていないパスワードが含まれます。ポータル管理ツールの [サービス管理] ページを使用して、このコンフィグレーション ファイルに含まれる属性を編集して保存するか、パスワードを使用するアプリケーションがコンフィグレーション ファイルにアクセスしない限り、これらのパスワードはクリア テキストのままです (ポータル アプリケーションが ear ファイルとしてデプロイされている場合、このファイルの編集や保存はできません)。
通常、開発時には、管理者は weblogic/weblogic などの一般的なログオン情報 (ログオン ID とパスワード) を使用します。たとえば、コード リスト 9-4 に最初のデプロイメント当初の application-config.xml の WSRP 要素を示します。
コード リスト 9-5 application-config.xml の開発段階のクリア テキスト パスワード
<ConsumerSecurityAdminPassword="weblogic" AdminUserName="weblogic"CertAlias="wsrpConsumer" CertPrivateKeyPassword="wsrppassword"
ConsumerName="wsrpConsumer"
IdentityAssertionProviderClass="com.bea.wsrp.security.
DefaultIdentityAssertionProvider"
Keystore="wsrpKeystore.jks" KeystorePassword="password"
Name="ConsumerSecurity"/>
[サービス管理] ツールを使用して属性を編集してから、ファイルを保存すると、コード リスト 9-5 のようにパスワードは自動的に暗号化されます。
コード リスト 9-6 application-config.xml の暗号化されたパスワード
<ConsumerSecurityAdminPassword="{3DES}3QrrUeIwN/DxlDI++1ixPw=="AdminUserName="weblogicc" CertAlias="wsrpConsumer"
CertPrivateKeyPassword="{3DES}g7h+VOSAsO9pSlvYSSB2iw=="ConsumerName="wsrpConsumer"
IdentityAssertionProviderClass="com.bea.wsrp.security.
DefaultIdentityAssertionProvider"
Keystore="wsrpKeystore.jks" KeystorePassword=
"{3DES}1OLYVirMWOo+3sEU80cMqw=="
Name="ConsumerSecurity" />
アプリケーションのライフサイクルを通してパスワードのセキュリティを確保するには、EncryptDomainString コマンドライン ユーティリティを使用して暗号パスワードを生成する必要があります。その後、開発環境では、暗号パスワードを application-config.xml ファイルに格納します。その後、必要に応じて、アプリケーションの EAR ファイルをビルドしてデプロイできます。
domain/portal/ (domain はアプリケーションのドメイン ディレクトリ) にナビゲートし、setDomainEnv.cmd を実行します。java com.bea.p13n.util.EncryptDomainString -targetDomainDird-inputStrings
java com.bea.p13n.util.EncryptDomainString -targetDomainDir \bea\weblogic81b\samples\domain\portal -inputString weblogic
この例では、入力文字列 weblogic は管理者のパスワードを表します (adminpassword=weblogic、コード リスト 9-6 を参照)。コマンドライン ユーティリティによって、ドメイン固有の暗号化された文字列が出力されます。
図 9-28 WebLogic Workshop でファイルを開く
コード リスト 9-7 application-config.xml のクリア テキスト パスワード
<ConsumerSecurityAdminPassword="weblogic"AdminUserName="weblogic"CertAlias="wsrpConsumer"CertPrivateKeyPassword="wsrppassword"ConsumerName="wsrpConsumer"
IdentityAssertionProviderClass="com.bea.wsrp.security.
DefaultIdentityAssertionProvider"
Keystore="wsrpKeystore.jks"KeystorePassword="password"Name="ConsumerSecurity"/>
<ConsumerSecurity>(コード リスト 9-6) 要素の各パスワードについて EncryptDomainString を実行する必要があります。コード リスト 9-8 EncryptDomainString ユーティリティで生成された暗号パスワード
<ConsumerSecurityAdminPassword="{3DES}3QrrUeIwN/DxlDI++1ixPw=="AdminUserName="weblogicc" CertAlias="wsrpConsumer"
CertPrivateKeyPassword="{3DES}g7h+VOSAsO9pSlvYSSB2iw=="ConsumerName="wsrpConsumer"
IdentityAssertionProviderClass="com.bea.wsrp.security.
DefaultIdentityAssertionProvider"
Keystore="wsrpKeystore.jks"KeystorePassword="{3DES}1OLYVirMWOo+3sEU80cMqw=="
Name="ConsumerSecurity" />
これで、EAR ファイルを構築しアプリケーションをデプロイできます。
理由にかかわらず、管理者のパスワードを変更する必要がある場合、単にパスワードを変更するだけでは、EAR の再ビルドと再デプロイが必要になります。これには時間がかかり効率が低下します。この問題を回避するために、次の手順に従います。
application-config.xml ファイルに格納します。
|
|
|