|
|
ここでは、WebLogic Integration の Trading Partner Integration ソリューションのセキュリティの概念およびタスクについて説明します。内容は以下のとおりです。
WebLogic Integration の Trading Partner Integration のセキュリティの実装を始める前に、以下のドキュメントを必ずお読みください。
ここでは、WebLogic Integration の Trading Partner Integration のセキュリティ フレームワークについて説明します。内容は以下のとおりです。
WebLogic Integration は、WebLogic Server セキュリティ フレームワークの特定の機能を利用して、Trading Partner Integration のための機能を追加します。WebLogic Integration では、以下の機能を使用して、トレーディング パートナ間のセキュアなビジネス トランザクションをサポートしています。
WebLogic Integration のセキュリティは、WebLogic Server のセキュリティ フレームワーク、すなわちデフォルトのセキュリティ コンフィグレーションに基づきます。詳細については、『WebLogic Server のセキュリティ』の「セキュリティ管理の概要」を参照してください。
Trading Partner Integration の WebLogic セキュリティ モデルには、次の特長があります。
図 4-1 は、Trading Partner Integration をサポートする WebLogic Server および WebLogic Integration のエンティティと機能を示しています。
表 4-1 は、このセキュリティ モデルの各機能の説明です。
|
|
TPMUserNameMapper クラスは、トレーディング パートナ証明書を、そのトレーディング パートナに対してコンフィグレーションされた WebLogic Server ユーザにマップする。TPMUserNameMapper クラスは、weblogic.security.providers.authentication.UserNameMapper インタフェースを実装する。このクラスをコンフィグレーションするか、独自のクラスを作成することができる。詳細については、「双方向認証でのリモート ユーザの認証」と、UserNameMapper インタフェースのリファレンス情報を参照。
|
|
|
|
|
WebLogic Platform の Configuration Wizard と WebLogic Integration テンプレートを使用して新しいドメインを作成すると、新しいドメインには、以下のようなデフォルトのセキュリティ設定が含まれます。
WebLogic Integration では、パスワード、プライベート キー、および証明書を格納するために、以下の資格ストアを用意しています。
パスワードはすべて、暗号化形式で PasswordStore に保管されます。WebLogic Integration では、クリアテキストのパスワードは不要です。PasswordStore は、JCE セキュリティ プロバイダを使用します。パスワードのコンフィグレーションは MBean API によって制御され、パスワードはパスワード エリアスを使用してアクセスされます。
PasswordStore 内のパスワードは、WebLogic Integration Administration Console で管理できます。詳細については、『WebLogic Integration Administration Console の使用』の「システム コンフィグレーション」にある以下のトピックを参照してください。
WebLogic Integration では、すべてのプライベート キーと証明書をキーストアに格納する必要があります。キーストアは、キーおよび証明書を保持する、保護されたデータベースです。キーおよび証明書を使用して、メッセージを暗号化したり、デジタル署名や SSL を使用したりする場合は、それらのキーおよび証明書をキーストアに格納し、認証や署名の目的でキーおよび証明書を必要とするアプリケーションに対してキーストアを使用可能にしておく必要があります。
Trading Partner Integration 用に WebLogic Integration ドメインをセットアップすると、以下のキーストアがコンフィグレーションされます。
WebLogic Platform の Configuration Wizard と WebLogic Integration テンプレートを使用して新しいドメインを作成すると、新しいドメインには、JKS タイプのデモ キーストアが含まれます。これらのキーストアには、次の特長があります。
開発環境やテスト環境ではデモ キーストアを使用できますが、プロダクション環境の場合は、新しい ID と信頼キーストアを明示的に作成する必要があります。キーストアを作成し、Trading Partner Integration でこのキーストアを使用できるようにするには、以下の手順を実行します。
WebLogic Integration Administration Console でのキーストアの更新方法については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」の「キーストアの更新」を参照してください。
| 注意 : | クラスタ化されたドメインでは、WebLogic サーバごとに独立したキーストアを作成およびコンフィグレーションする必要があります。 |
Trading Partner Integration リソース用として、次のようなセキュリティ ポリシーをコンフィグレーションできます。
詳細については、『ロールおよびポリシーによる WebLogic リソースの保護』を参照してください。
「転送レベルのセキュリティ」には、転送レベル (HTTP および HTTPS) での認証および暗号化と、エンドポイントでの認可が関与します。ここでは、Trading Partner Integration のための転送レベルのセキュリティの概念とタスクについて説明します。内容は以下のとおりです。
WebLogic Integration では、「認証」とは、システム エンティティによって宣言された ID、またはシステム エンティティに対して宣言された ID を検証するプロセスです。認証の対象は、エンティティが何者であるか、です。つまり、認証は、ID とエンティティとの関連付けです。WebLogic Integration では、TPM リポジトリに格納されているセキュリティ情報に基づいて、デジタル証明書を検証します。
Trading Partner Integration に関しては、WebLogic Integration は次の方法で認証を行います。
トレーディング パートナの認証は、トレーディング パートナ間の通信を定義するプロトコル バインディング内でコンフィグレーションされます。詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある「プロトコル バインディングの定義」を参照してください。
SSL プロトコルは、ネットワーク接続を介してリンクされた 2 つのアプリケーションが相手の ID を認証できるようにすること、およびアプリケーション間で交換されるデータを暗号化することにより、セキュアな接続を実現します。SSL 接続では、まずハンドシェイクが行われます。ハンドシェイクでは、アプリケーション同士がデジタル証明書を交換し、使用する暗号化アルゴリズムについて合意し、そのセッションで使用する暗号化キーを生成します。
WebLogic Integration では、SSL プロトコルの以下のセキュリティ機能をサポートしています。
トレーディング パートナ間でビジネス メッセージを交換する際は、両方のタイプの認証を使用できます。さらに、管理者は Web ブラウザから HTTPS を使用して、WebLogic Integration Administration Console と WebLogic Server Administration Console にアクセスできます。
管理者は、Web ブラウザを使用して、WebLogic Integration Administration Console にアクセスできます。このタイプのネットワーク通信は、HTTPS (Hypertext Transfer Protocol with SSL) を使用することにより保護できます。SSL の詳細については、以下を参照してください。
WebLogic Integration は、以下のタイプの認証をサポートします。
Trading Partner Integration には、以下の 2 レベルの認証プロセスが組み込まれています。
WebLogic Integration リソースのエンドツーエンド アクセス制御 (認可) には、両方のレベルの認証が必要です。トレーディング パートナのビジネス メッセージが両方のレベルの認証に成功した後、Trading Partner Integration エンジンがそのビジネス メッセージに対して認可プロセスを実行します。Trading Partner Integration の各種リソースを保護するには、認可プロセスで少なくとも基本認証または相互認証を実行する必要があります。これらについては、「認証のタイプ」を参照してください。
デジタル証明書は、インターネットなどのネットワークを通じてプリンシパルやエンティティのユニークな ID を検証するために使用される電子ドキュメントです。デジタル証明書は、ユーザまたはエンティティの ID を安全にバインドします。この安全性は、信頼性のある第三者機関 (認証局) が特定の公開鍵に対して検証します。公開鍵とプライベート キーを組み合わせることにより、デジタル証明書のオーナーをユニークに識別できます。
デジタル証明書は、特定の公開鍵が特定のユーザまたはエンティティに実際に帰属するという主張を裏付けることができます。デジタル証明書の受信者は、その証明書が、サブジェクトの公開鍵を含んでおり、信頼性のある認証局 (CA) によって発行および署名されたものであることを確認できます。受信者はこの確認を行うために、信頼性のある認証局の公開鍵を使用して、デジタル署名が認証局のプライベート キーで作成されていることを確認します。この確認が成功すれば、論理的なつながりとして、そのプライベート キーの所有者が、デジタル証明書で名前を指定されているサブジェクトであること、ならびに、デジタル署名がその認証局によって作成されたことが保証されます。
デジタル証明書は、ID キーストアに格納されます。詳細については、「プライベート キーと証明書のキーストア」を参照してください。
デジタル証明書には、以下のようなさまざまな情報が含まれています。
デジタル証明書のフォーマットとしては、ITU-T X.509 国際標準で定義されたものが最も広く使用されています。したがって、X.509 標準に準拠しているアプリケーションであれば、どのアプリケーションでも、デジタル証明書の読み書きが可能です。WebLogic Server の公開鍵インフラストラクチャ (PKI) は、X.509 バージョン 1 (X.509v1) またはバージョン 3 (X.509v3) に準拠するデジタル証明書を認識します。
デジタル証明書は、認証局が発行します。デジタル証明書と公開鍵を発行してその対象の身元を保証する機関または企業が認証局です。認証局は、デジタル証明書を作成するとき、プライベート キーを使用して証明書に署名します。これにより、改ざんを確実に検出できます。その後、認証局は、署名したデジタル証明書を要求元のサブジェクトに返します。
サブジェクトは、発行元の認証局の署名を、認証局の公開鍵を使用して確認できます。認証局は、自身の公開鍵を使用可能にするために、上位の認証局から発行されたデジタル証明書を提供します。この証明書は、下位の認証局の公開鍵の有効性を保証するものです。この認証局の階層は、ルート証明書と呼ばれる自己署名デジタル証明書で終端します。この様子を図 4-2 で示します。
デジタル証明書を使用したり、デジタル署名を検証したり、ビジネス メッセージを復号化したりするためには、デジタル証明書の発行元が信頼性のある認証局であることを確認する必要があります。ビジネス メッセージを誰が暗号化したかにかかわらず、ビジネス メッセージのデジタル証明書は信頼性のあるものである必要があり、またそのことが認証局によって立証されなければなりません。
WebLogic Integration では、以下のタイプの証明書を Trading Partner Integration でサポートしています。
|
|||
トレーディング パートナ証明書のコンフィグレーションについては、以下の一般ルールに注意してください。
デジタル証明書に関するコンフィグレーション要件は、ローカル トレーディング パートナとリモート トレーディング パートナとで異なります。
デジタル証明書のコンフィグレーションは、WebLogic Integration Administration Console で行います。デジタル証明書は、ID キーストアに格納されます。デジタル証明書をコンフィグレーションするためには、トレーディング パートナを TPM リポジトリで定義し、ID キーストアをコンフィグレーションする必要があります。詳細については、「プライベート キーと証明書のキーストア」を参照してください。
コンフィグレーションの手順については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」の「証明書のトレーディング パートナへの追加」を参照してください。
| 注意 : | トレーディング パートナ証明書をキーストアにロードする際、WebLogic Integration では、信頼性のある認証局に基づくトレーディング パートナ証明書の検証を行いません。 |
「認証レベル」での説明のとおり、トレーディング パートナの証明書が WebLogic Server によって検証された後は、Trading Partner Integration エンジンでトレーディング パートナ メッセージが認証されない限り、そのメッセージ自体がサービスを受けることはできません。トレーディング パートナ メッセージの認証処理には、ビジネス メッセージの送信者が有効なトレーディング パートナとして TPM リポジトリにリストされていることの確認が含まれます。トレーディング パートナ メッセージが認証されると、そのメッセージの処理プロセスで、そのトレーディング パートナの ID が認識され、コンフィグレーション済みポリシーに基づいて Trading Partner Integration の各種リソースへのアクセスが許可されます。
図 4-3 は、トレーディング パートナ メッセージを認証するプロセスを表しています。
図 4-3 は、次の点に注目してください。
ここでは、リモート トレーディング パートナの ID と WebLogic Server ユーザとの間の関連付けを検出するのに役立つ TPMUserNameMapper クラスの使用方法について説明します。
| 注意 : | TPMUserNameMapper は、双方向認証にのみ適用されます。別の認証メカニズムを使用してデプロイメントを行う場合は、このセクションをスキップできます。 |
| 注意 : | TPMUserNameMapper は、「リモート」トレーディング パートナにのみ適用されます。ローカル トレーディング パートナには適用されません。ローカル トレーディング パートナをコンフィグレーションする場合は、そのトレーディング パートナに WebLogic Server ユーザ名を付ける必要はありません。 |
TPMUserNameMapper クラスは、リモート トレーディング パートナの ID と WebLogic Server ユーザとの間の関連付けを検出するのに役立ちます。WebLogic Integration でトレーディング パートナ プロファイルをコンフィグレーションする際、そのプロファイルにバインドするトレーディング パートナ名も指定します。WebLogic Integration Administration Console で、ユーザとトレーディング パートナを関連付けるには、WebLogic Server ユーザ名であるトレーディング パートナ ユーザ名を指定します。
実行時、WebLogic Server が、そのトレーディング パートナのデジタル証明書をトレーディング パートナ ユーザにマップします。この動作を図 4-4 に示します。
相互認証が使用されている場合 (web.xml 内の CLIENT-CERT と SSL が WebLogic Server での相互認証向けにコンフィグレーションされている場合)、TPMUserNameMapper は、以下のように 2 つの仕組みを使用して、ユーザ マッパーに対する証明書を検索します。トレーディング パートナ メッセージがリモート トレーディング パートナから WebLogic Server に到着すると、SSL ハンドシェイクの完了直前に TPMUserNameMapper が起動します。TPMUserNameMapper はまず、TPM リポジトリで、リモート トレーディング パートナのクライアント証明書のフィンガープリントを使用して、トレーディング パートナと WebLogic Server ユーザとの関連付けを探します。見つからない場合は、クライアント証明書の属性を WLS ユーザにマッピングしようとします。
WebService/SOAP、ebXML、RosettaNet の各プロトコルが WebLogic Integration 内で同じ UserNameMapper を使用できるようにするためには、TPMUserNameMapper を使用するよう、WebLogic Server 内で DefaultIdentityAsserter 設定をコンフィグレーションする必要があります。
TPMUserNameMapper をコンフィグレーションするには
[セキュリティ レルム
myrealm プロバイダ 認証 DefaultIdentityAsserter]
WebLogic Server Administration Console に、DefaultIdentityAsserter のコンフィグレーション タブが表示されます。
com.bea.b2b.security.TPMUserNameMapper」と入力します。X.509] を選択し、右矢印をクリックします。
com.bea.b2b.security.TPMUserMapper クラスは、WebLogic Server の weblogic.security.providers.authentication.UserNameMapper インタフェースを実装します。必要であればこの API の独自の実装を作成することも可能ですが、TPMUserNameMapper クラスを使用しても同様に、TPM リポジトリにアクセスすることができます。詳細については、「Interface UserNameMapper」を参照してください。
WebLogic Integration でトレーディング パートナのデジタル証明書を検証するには、証明書検証プロバイダ (CVP) を使用します。Trading Partner Integration セキュリティ フレームワークは、サード パーティ サービスを呼び出してトレーディング パートナ証明書を検証する SPI を実装する Java クラスを挿入できるサービス プロバイダ インタフェース (SPI) を備えています。証明書検証プロバイダと呼ばれるこのような実装は、以下のいずれかの証明書検証アプリケーションを呼び出すことができます。
証明書検証プロバイダ (CVP) を使用する場合は、これを WebLogic Integration Administration Console でコンフィグレーションする必要があります。これについては、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」の「証明書検証プロバイダの指定」を参照してください。
トレーディング パートナ証明書検証の目的は、トレーディング パートナのデジタル証明書を検証することです。たとえば、証明書の検証では、以下のタスクの一部またはすべてを行います。
CVP 実装をコンフィグレーションして使用することは必須ではありませんが、そうすることにより、証明書検証プロセスにおけるセキュリティのレベルを高めることができます。
WebLogic Integration では、以下の場合に CVP を使用します。
図 4-7 は、SSL と相互認証を使用する着信メッセージに対する WebLogic Integration の証明書検証プロセスで発生するイベントのシーケンスの例です。
図 4-7 の以下の番号の箇所に注目してください。
証明書検証プロバイダ (CVP) の Java クラスは、com.bea.wli.security.verification.CertificateVerificationProvider インタフェースを実装する必要があります。CVP クラスが何を呼び出せるかについては、次の 2 つの選択肢があります。
どれを選択するかにかかわらず、実際に証明書検証を実行するアプリケーションを呼び出す CVP SPI の Java 実装を作成する必要があります。この CVP アプリケーションを作成、コンパイル、コンフィグレーションする方法について、この後に説明します。
Trading Partner Integration では、CVP サービス プロバイダ インタフェース (SPI) を提供する com.bea.wli.security.verification.CertificateVerificationProvider インタフェースを使用して CVP を実装できます。ここで説明する SPI を使用して CVP を実装または使用する場合は、後でその CVP を WebLogic Integration Administration Console でコンフィグレーションして、実行時に正しく呼び出されるようにする必要があります。
com.bea.wli.security.verification.CertificateVerificationProvider インタフェースには、以下のメソッドがあります。CVP アプリケーションはこれらを実装する必要があります。
void init()
このメソッドは、Trading Partner Integration エンジンによって自動的に呼び出され、このインタフェースを実装する、ユーザが作成したクラス内で、カスタム初期化プロセスを起動します。このメソッドは、WebLogic Integration の起動時に一度だけ呼び出されます。
public String verify(X509Certificate[] certs)
このメソッドは、SSL ハンドシェイク中に取得した証明書チェーンを検証します。その結果として、以下のいずれかの String 値を返します。
good - トレーディング パートナ証明書が有効であり、期限切れではありません。revoked - トレーディング パートナ証明書が、証明書チェーン内のいずれかの認証局によって取り消されているか、期限切れです。unknown - 証明書チェーン内のどの認証局も、トレーディング パートナ証明書が有効であることを立証できません。
実装者は、このメソッドで実行される検証の手順を選択できます。たとえば、このメソッドは、ファイルに格納されている証明書失効リスト (CRL) をチェックするか、Online Certificate Status Protocol (OCSP) を使用して証明書の状態をリアルタイムでチェックするか、あるいは必要に応じて、その他のメカニズムを使用することができます。
| 注意 : | CVP を実装する場合は、CVP 用のデフォルトのパブリック コンストラクタを引数なしで追加する必要があります。このコンストラクタもクラス内のどのメソッドも例外を送出しません。 |
| 注意 : | CVP をコンフィグレーションしない場合は、信頼性のある認証局で発行されたすべての証明書が、Trading Partner Integration エンジンによって、有効と見なされます。 |
CVP を実装する場合は、CVP Java クラスを作成した後に、それをコンパイルして、システム CLASSPATH に配置する必要があります。
WebLogic Integration Administration Console または Bulk Loader ユーティリティを使用して、CVP をコンフィグレーションする必要があります。CVP をコンフィグレーションした後、WebLogic Server を再起動すると、CVP が有効になります。CVP をコンフィグレーションしない場合は、信頼性のある認証局で発行されたすべての証明書が、Trading Partner Integration エンジンによって、有効と見なされます。
CVP のコンフィグレーションは、WebLogic Integration Administration Console で行います。詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある「証明書検証プロバイダの指定」を参照してください。
CVP をコンフィグレーションした後、WebLogic Server を再起動すると、CVP が有効になります。
| 注意 : | WebLogic Integration を反復型開発モードで実行しているときは、セキュリティ検証設定はアクティブになりません。開発モード中は CVP だけがアクティブになります。 |
認可では、以下のような Trading Partner Integration リソースに対してアクセスが許可されているかどうかが判定されます。
トレーディング パートナ リソースにアクセスするためのパーミッションは、ポリシーとロールに基づいて割り当てられます。つまり、保護の必要があるリソースについては、そのセキュリティ ポリシーがロールに基づいて定義されます。したがって、個々のユーザやエンティティは、それぞれが属するロールに基づいてアクセス権を取得できます。認証は、エンティティが「誰」なのか (つまり、ID とエンティティとの関連付け) を問題にしますが、認可は、その ID が何を見て、何をすることが「できる」かを問題にします。
| 注意 : | 認可は、基本認証、一方向基本認証、および相互認証で利用できます (必須ではありません)。 |
トレーディング パートナ統合については、次の 2 レベルの認可が WebLogic Integration に組み込まれています。
WebLogic Server は、トレーディング パートナの認可を実行します。トレーディング パートナのメッセージが WebLogic Server に到着し、トレーディング パートナと WebLogic Server が相互認証または基本認証 (ユーザ名とパスワード) の手続きを完了すると、Transport Servlet Filter へのアクセスの認可が WebLogic Server によって実行されます。
B2BDefaultWebApp をコンフィグレーションする場合は、WebLogic Server Administration Console で、URL へのアクセスに関して B2BDefaultWebApp に対するポリシーを設定する方法をお勧めします。コンフィグレーションの手順については、『ロールおよびポリシーによる WebLogic リソースの保護』の「ポリシーで保護できるリソースのタイプ」の「URL (Web) リソース」と「EJB (エンタープライズ JavaBean) リソース」を参照してください。
B2BDefaultWebApp のコンフィグレーションだけでなく、同様にコンフィグレーションを必要とする他の Trading Partner Integration リソースもコンフィグレーションできます。たとえば、TPM リポジトリ、Workshop for WebLogic ビジネス プロセス、JMS 送り先などへのアクセスで使用される JDBC データ ソースをコンフィグレーションできます。詳細については、「認可」を参照してください。また、web.xml ファイルで Transport Servlet Filter ACL を指定することができます。ただし、この方法は推奨しません。以下の例は、B2BTransport という名前の Transport Servlet Filter の ACL を指定している web.xml ファイルを示しています。
Transport Servlet Filter ACL の例
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 1.2//EN
" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
<web-resource-name>B2BTransport</web-resource-name>
<role-name>PremiumTradingPartner</role-name>
<auth-method>CLIENT-CERT</auth-method>
<role-name>PremiumTradingPartner</role-name>
B2BTransport は、エンドポイントが TPM リポジトリで定義されている Transport Servlet Filter です。
PremiumTradingPartner は、すべてのトレーディング パートナ WebLogic Server ユーザがメンバーである WebLogic Server ユーザ グループです。
CLIENT-CERT は、Transport Servlet Filter へのアクセスに必要な認証モードが SSL 相互認証であることを示しています。また、HTTP 基本認証も使用できます。
Trading Partner Integration エンジンがサービス認可を実行すると、サーバは、トレーディング パートナのビジネス メッセージの内容を、そのトレーディング パートナがバインドされているサービス プロファイルに基づいて検査します。つまり、トレーディング パートナは、1 つのサービス プロファイルについて、ある特定のセットのビジネス メッセージだけを送信することができます。Trading Partner Integration エンジンは、特定のサービスのサービス プロファイルで指定されている以下の情報に基づいて、ビジネス メッセージを検証します。
着信ビジネス メッセージに対するサービス認可が完了すると、WebLogic リソース ポリシーによって、B2B リソースへのアクセスが指示されます。
「メッセージレベルのセキュリティ」には、個々のビジネス メッセージのデジタル署名、暗号化、および否認防止性が含まれます。ここでは、Trading Partner Integration のためのメッセージレベルのセキュリティの概念とタスクについて説明します。内容は以下のとおりです。
デジタル署名を使用すると、ビジネス メッセージの改ざんを防ぐことができます。暗号化を行うと、メッセージのプライバシを確保できます。否認防止性を使用すると、トレーディング パートナが、以前に他のトレーディング パートナと特定のビジネス メッセージをやりとりしたことを立証または反証できます。
メッセージレベルのセキュリティは、トレーディング パートナ間の通信を定義するプロトコル バインディング内でコンフィグレーションされます。詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある「プロトコル バインディングの定義」を参照してください。
「デジタル署名」は、特にビジネス メッセージがトレーディング パートナ間で送信されているときに起こりうる、何者か、または何物かによるビジネス メッセージの内容の改ざんを防ぐ手段です。WebLogic Integration は、署名を検証した後に、証明書検証プロバイダを使用します (双方向認証がコンフィグレーションされている場合)。これについては、「双方向認証でのリモート ユーザの認証」を参照してください。デジタル署名は、否認防止性に必要です。これについては、「否認防止性」を参照してください。
WebLogic Integration は、以下のタイプのデジタル署名をサポートします。
デジタル署名自体は、ビジネス メッセージの末尾に付加された一組のデータであり、特定のフォーマット (たとえば、PKCS7 SignedData や XMLDSIG 署名) でパッケージ化されたデータの、暗号化された一方向ハッシュ値で構成されます。デジタル署名には、次の特長があります。
デジタル署名の作成に必要なデータは、TPM リポジトリにあるトレーディング パートナのコンフィグレーション データから取得されます。デジタル署名の作成には、以下の情報も必要です。
トレーディング パートナ間の通信を定義するプロトコル バインディングにおいて、ビジネス メッセージに署名するかどうかをコンフィグレーションできます。詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある「プロトコル バインディングの定義」を参照してください。
WebLogic Integration は、署名を検証した後、証明書検証プロバイダ (CVP) を呼び出します。これについては、「証明書検証プロセス」を参照してください。
WebLogic Integration は、トレーディング パートナ間の ebXML 1.0 および ebXML 2.0 メッセージ交換のための XMLDSig をサポートしています。
WebLogic Integration は、以下の XMLDSig 機能をサポートしています。
XMLDSig の詳細については、下記 URL の W3C Web サイトの「XML-Signature Syntax and Processing」を参照してください。
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/Overview.html
WebLogic Integration では、XMLDSig のアルゴリズムとして以下のものを使用しています。
WebLogic Integration では、RosettaNet 1.1 および 2.0 に対して、PKCS7 エンベロープ データによるデジタル署名をサポートしています。
WebLogic Integration では、RosettaNet 1.1 および 2.0 のデジタル署名用として、PKC7 エンベロープ データをサポートしています。マルチパート メッセージのデジタル署名は、以下のものに適用されます。
WebLogic Integration では、以下の PKC7 エンベロープ データ アルゴリズムをサポートしています。
「否認防止性」は、関与を否認するパーティの関与を法的に立証する機能です。この機能は、重要なビジネス メッセージの法的要件です。否認防止性は、トレーディング パートナが、以前に他のトレーディング パートナと特定のビジネス メッセージをやりとりしたことを立証または反証できる機能です。WebLogic Integration は、以下の否認防止性をサポートしています。
否認防止性は、トレーディング パートナ間の通信を定義するプロトコル バインディング内でコンフィグレーションされます。詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある「プロトコル バインディングの定義」を参照してください。
トレーディング パートナ A が、トレーディング パートナ B から人間工学に基づく椅子を 1000 脚購入することで、トレーディング パートナ B と合意しました。この合意の過程で、トレーディング パートナ A は椅子を指定価格で購入することに同意するビジネス メッセージをトレーディング パートナ B に送信しました。しかし、後になってトレーディング パートナ A は、最初に決めた価格に異議を唱え、その価格での支払に両者が合意したメッセージを送信したことを否認しました。
信頼性のある否認防止性システムが設置されていれば、トレーディング パートナ B は、トレーディング パートナ A が支払に同意した価格を明示している、トレーディング パートナ A からのドキュメントを出力することによって、トレーディング パートナ A の主張を反証することができます。さらに、そのオリジナルのドキュメントが、信頼性のあるサード パーティ ソースによってデジタル的に署名され、タイムスタンプを付加され、記録され、セキュリティ保護されていれば、そのドキュメントは法的に完全に有効です。
WebLogic Integration は、否認防止性をサポートするために、以下のサービスを提供します。
デジタル署名は、特にビジネス メッセージがトレーディング パートナ間で送信されているときに起こりうる、何者か、または何物かによるビジネス メッセージの内容の改ざんを防ぐ手段となるため、否認防止性には不可欠です。詳細については、「デジタル署名」を参照してください。
「セキュアな監査ログ」は、概して、各ビジネス メッセージをデジタル署名およびセキュアなタイムスタンプとともに保管します。これにより、トレーディング パートナは、他のトレーディング パートナとのビジネス メッセージの交換中に発生したメッセージや他のシステム イベントの順序を、交換したデータとともに再構成できます。したがって、セキュアな監査ログは否認防止性に不可欠です。
デフォルトの監査ログ プロバイダ (com.bea.wli.security.audit.DefaultAuditLogProvider) は、secureaudit.log というファイルにログを保存します。このファイルは、ロギング サブシステムをベースとし、基底のオペレーティング システムのファイル パーミッション システムによってのみ保護されます。このファイルは、デジタル的に署名されたり、暗号化されたりしません。このファイルはデモ用途または開発用途にのみ使用します。プロダクション環境には使用しないでください。
監査ログの有効/無効の切り替え、および監査ログ クラスの指定は、WebLogic Integration Administration Console で行います。詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある「セキュア監査ログのコンフィグレーション」を参照してください。
ログ メッセージはすべて、各メッセージ タイプの内容を定義する DTD log-message.dtd に対応します。
すべての監査ログ メッセージに、以下の 3 つの識別子が含まれます。
次の表は、各メッセージ タイプのデータの内容についての説明です。すべてのログ メッセージに、WebLogic Integration でコンフィグレーションされているタイムスタンプ プロバイダから取得したタイムスタンプが含まれます。
以下のコードは、log-message.dtd ファイルの例です。
<!ELEMENT LOG (起点の否認防止性 | 受信の否認防止性 | アプリケーション)>
<!ATTLIST LOG タイムスタンプ CDATA #REQUIRED >
<!ATTLIST LOG 場所 CDATA #IMPLIED >
<!ATTLIST LOG プリンシパル CDATA #IMPLIED >
<!ELEMENT 起点の否認防止性 (#PCDATA)>
<!ELEMENT 受信の否認防止性 (#PCDATA)>
<!ELEMENT アプリケーション (#PCDATA)>
Trading Partner Integration エンジンが提供するサービス プロバイダ インタフェース (SPI) を使用して、信頼性のある、セキュアな監査ログのサード パーティ プロバイダをコンフィグレーションできます。信頼性のあるサード パーティ プロバイダのセキュアな監査ログ サービスを組み込むには、com.bea.wli.security.audit.AuditLogProvider インタフェースを実装するクラスを作成する必要があります。作成したクラス (たとえば、log) のメソッドで、サード パーティ監査ログ プロバイダを呼び出します。
| 注意 : | ここで説明する SPI を使用して監査ログサービスを実装する場合は、後でそのサービスを WebLogic Integration Administration Console でコンフィグレーションして、実行時に正しく呼び出されるようにする必要があります。 |
com.bea.wli.security.audit.AuditLogProvider インタフェースには、以下のメソッドがあります。セキュアな監査ログ アプリケーションはこれらを実装する必要があります。
セキュアな監査インタフェースの実装には、デフォルトのパブリック コンストラクタを引数なしで含める必要があります。このコンストラクタも、AuditLogProvider インタフェースを実装するクラス内のどのメソッドも、例外を送出しません。
監査ログに書き込むアプリケーションを呼び出す com.bea.wli.security.audit.AuditLogProvider インタフェースの Java 実装を作成する代わりに、com.bea.wli.security.audit.Audit.log(byte[] data) メソッドを呼び出して監査ログに直接書き込むアプリケーションを作成できます。ビジネス プロセスでのコード例を以下に示します。この例で、太字のコードは、監査ログへの書き込みを表示するために追加された文を示します。
package orderprocessing;
import com.bea.jpd.JpdContext;
import org.apache.xmlbeans.XmlObject;
import com.bea.data.MessageAttachment;
// Import the Audit class from the WLI security package
import com.bea.wli.security.audit.Audit;
/**
* @jpd:process process::
* <process name="ServerBuyer">
* <clientRequest name="Receive order request from client" method="start"/>
* <controlSend name="Send PO to enterprise server seller"
method="sendOrder"/>
* <controlReceive name="Receive PO receipt from enterprise server seller"
method="orderService_onMessage"/>
* <clientCallback name="sendAck" method="sendAck"/>
* </process>::
*
*/
@com.bea.wli.jpd.Process(process = "<process name=\"ServerBuyer\">" +
" <clientRequest name=\"Receive order request from client\" method=\"start\"/>" +
" <controlSend name=\"Send PO to enterprise server seller\" method=\"sendOrder\"/>" +
" <controlReceive name=\"Receive PO receipt from enterprise server seller\" method=\"orderService_onMessage\"/>" +
" <clientCallback name=\"sendAck\" method=\"sendAck\"/>" +
"</process>")
public class EnterpriseServerBuyer implements com.bea.jpd.ProcessDefinition
{public com.bea.tutorial.b2B.order.OrderDocument pcOrder;
/**
* @jc:ebxml ebxml-service-name="SecureOrderService" from="BEA-IT-id" to="SUN-id" ebxml-action-mode="default"
* @common:control
*/
@Control()
@EBXMLControl.EbXML(serviceName = "SecureOrderService",
from = "BEA-IT-id",
to = "SUN-id",
ebXMLActionMode = EBXMLControl.EbXML.ActionMode.DEFAULT)
private SecureOrderServiceControl orderService;
/**
*@common:context
*/
@com.bea.wli.jpd.Context()
JpdContext context;
public void start( String str )
{//create an order
pcOrder = ...
}
public void sendOrder()
{//#START: CODE GENERATED - PROTECTED SECTION - you can safely add code
above this comment in this method. #//
// input transform
// method call
orderService.sendOrder(pcOrder);
// output transform
// output assignments
//#END : CODE GENERATED - PROTECTED SECTION - you can safely add code
below this comment in this method. #//
}
public void orderService_onMessage(MessageAttachment[] reply)
{//assume only one object of type XmlObject in reply
XmlObject xo = reply[reply.length - 1].getXmlObject();
if(Audit.isEnabled()) {Audit.log(xo.toString().getBytes());
}
}
public Callback callback;
public interface Callback {public void onAck(String reply);
}
void sendAck() {callback.onAck("This is an ACK from ServerBuyer.jpd.");}
}
セキュアなタイムスタンプ サービスは、セキュアな監査ログにビジネス メッセージも記録されるときに、UTC (Coordinated Universal Time: 協定世界時) タイムスタンプをセキュアな監査ログに付加して、時刻と日付の情報の正確性を保ちます。そのため、「タイムスタンプ プロバイダ」は否認防止性に不可欠です。
たとえば、トレーディング パートナがビジネス メッセージを受信すると、受信の否認防止性 (NRR) メッセージとしてタイムスタンプが監査ログに入力されます。また、トレーディング パートナがビジネス メッセージを送信すると、起点の否認防止性 (NRO) メッセージとしてタイムスタンプが監査ログに入力されます。
タイムスタンプ プロバイダのコンフィグレーションは、WebLogic Integration Administration Console で行います。詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある「セキュア監査ログのコンフィグレーション」を参照してください。
Trading Partner Integration エンジンでは、複数のセキュアなタイムスタンプ プロバイダが WebLogic Integration に登録されることを禁止しています。この制限により、WebLogic Integration で作成されたタイムスタンプはすべて、時間の経過順に並びます。
| 注意 : | セキュアなタイムスタンプ サービス プロバイダを WebLogic Integration にコンフィグレーションしない場合、デフォルトのログ プロバイダが使用されていれば、タイムスタンプ システム イベントおよび署名にシステム時刻が使用されます。 |
Trading Partner Integration に含まれるサービス プロバイダ インタフェース (SPI) を使用すると、信頼性のあるサード パーティ プロバイダのセキュアなタイムスタンプ サービスを組み込むことができます。
信頼性のあるサード パーティ プロバイダのセキュアなタイムスタンプ サービスを組み込むには、com.bea.wli.security.time.TimestampProvider インタフェースを実装する Java クラスを作成する必要があります。com.bea.wli.security.time.TimestampProvider インタフェースを実装するクラスのメソッド (たとえば、getTimestamp) 内で、サード パーティ タイムスタンプ プロバイダを呼び出します。
Trading Partner Integration では、com.bea.wli.security.time.TimestampProvider インタフェースを実装することにより、カスタマイズした、セキュアなタイムスタンプ サービスを作成できます。 ここで説明する SPI を使用してタイムスタンプを実装する場合は、後でそのサービスを WebLogic Integration Administration Console でコンフィグレーションして、実行時に正しく呼び出されるようにする必要があります。
com.bea.wli.security.time.TimestampProvider インタフェースには、以下のメソッドがあります。タイムスタンプ アプリケーションはこれらを実装する必要があります。
タイムスタンプ インタフェースの実装には、デフォルトのパブリック コンストラクタを引数なしで含める必要があります。このコンストラクタも、TimeStampProvider インタフェースを実装するクラス内のどのメソッドも、例外を送出しません。
WebLogic Integration では、暗号化を必要とするビジネス プロトコルのビジネス メッセージを暗号化できます。この WebLogic Integration リリースでは、RosettaNet 2.0 に対してのみ、メッセージ暗号化をサポートしています。
| 注意 : | メッセージを暗号化するには、暗号化サービスを使用するための有効なライセンスが必要です。 |
図 4-8 は、公開鍵とプライベート キーを使用してデータの暗号化が実行される様子を表したものです。
データ暗号化は、送信者の証明書とプライベート キー、および受信者の証明書を組み合わせてビジネス メッセージをエンコードすることにより行われます。暗号化されたメッセージは、受信者が受信者のプライベート キーを使用することによってのみ復号化できます。
| 注意 : | WebLogic Integration では、暗号化はライセンス (Encryption/Domestic または Encryption/Export) で管理されますが、ビジネス メッセージの復号化は管理されません。Trading Partner Integration エンジンでは、有効な暗号化ライセンスがない場合、暗号化サービスは無効化されます。ただし、受信したビジネス メッセージはいつでも復号化できます。 |
WebLogic Integration のメッセージ暗号化サービスは、以下のアルゴリズムをサポートしています。
トレーディング パートナ間の通信を定義するプロトコル バインディングでのビジネス メッセージの暗号化の有効/無効の切り替えは、WebLogic Integration Administration Console で行います。詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある「プロトコル バインディングの定義」を参照してください。
ここでは、Trading Partner Integration でプロキシ サーバを使用する方法を説明します。内容は以下のとおりです。
高度なセキュリティで保護する必要のある環境で WebLogic Integration を使用する場合、WebLogic Integration をプロキシ サーバの後ろで使用すると効果的です。プロキシ サーバを使用することにより、セキュリティで妥協せずに、トレーディング パートナ同士がイントラネットやインターネットを経由して通信できます。プロキシ サーバは、以下の用途で使用されます。
ローカル ネットワーク上にプロキシ サーバを構成すると、ネットワーク トラフィックは、プロキシ サーバを経由して、あるいはプロキシ サーバに委託して外部ネットワークに出ていきます。図 4-9 は、WebLogic Integration 環境でのプロキシ サーバの使用方法の例を示しています。
WebLogic Integration Administration Console でのプロキシ サーバのコンフィグレーション方法については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」の「プロキシ ホストのコンフィグレーション」を参照してください。
| 注意 : | プロキシ サーバをコンフィグレーションするには、WebLogic Server の ssl.proxyHost および ssl.proxyPort システム プロパティを読み書きするパーミッションの追加も必要です。これらのシステム プロパティは、weblogic.policy ファイルに格納されます。このファイルは、WebLogic Server をインストールしたディレクトリにあります。weblogic.policy ファイルの grant セクションに以下の行を追加してください。 |
permission java.util.PropertyPermission "ssl.proxyHost", "read, write";
permission java.util.PropertyPermission "ssl.proxyPort", "read, write";| 注意 : | さらに、次の WebLogic Web Server システム プロパティを指定する必要があります。 |
| 注意 : | -http.proxyHost (プロキシ サーバが SSL を経由するようにコンフィグレーションされている場合)-https.proxyPort (プロキシ サーバが SSL を経由するようにコンフィグレーションされている場合) |
| 注意 : | プロキシと通信するための認証情報は、weblogic.common.ProxyAuthenticator インタフェースを使用して取得されます。詳細については、「Interface ProxyAuthenticator」を参照してください。 |
リモート トレーディング パートナからのビジネス メッセージを処理するようにプログラムされた、Apache サーバなどの Web サーバで WebLogic Integration をコンフィグレーションできます。Web サーバは、以下のサービスを提供できます。
Web サーバで WebLogic プロキシ プラグインを使用して、以下のサービスが提供されるようにコンフィグレーションできます。
図 4-10 は、Web サーバ、WebLogic プロキシ プラグイン、および WebLogic Integration を使用する環境のトポロジを表しています。
WebLogic プロキシ プラグインを使用する場合は、以下の点に注意してください。
Web サーバをコンフィグレーションする方法については、「Web サーバ機能のコンフィグレーション」を参照してください。
次のサンプル コードは、プロキシ プラグインのコンフィグレーションに必要な httpd.conf (Apache サーバ用) の一部です。
# LoadModule foo_module libexec/mod_foo.so
LoadModule weblogic_module libexec/mod_wl_ssl.extension
<Location /weblogic>
SetHandler weblogic-handler
PathTrim /weblogic
WebLogicHost myhost
WebLogicPort 80
</Location>
extension は、Unix でのインストールで使用されるファイルの拡張子です。
開発用途およびテスト用途では、WebLogic Platform の Configuration Wizard を使用して新しい WebLogic Integration ドメインを作成したときに生成された、デフォルトのセキュリティ コンフィグレーションを使用します。詳細については、「デフォルトのドメイン セキュリティ コンフィグレーション」を参照してください。
プロダクション環境については、デプロイメントの一環としてセキュリティをコンフィグレーションする必要があります。ここでは、実行する必要があるタスクの概要を示します。内容は以下のとおりです。
デフォルトのセキュリティ レルムで定義されているユーザ、グループ、およびロールを管理するには、WebLogic Integration Administration Console の「ユーザ管理」モジュールを使用します。WebLogic Integration Administration Console でユーザ、グループ、およびロールをコンフィグレーションする手順については、『Worklist Console の使い方』の「ユーザ管理」を参照してください。
ビジネス メッセージの交換相手のトレーディング パートナのプロファイルをコンフィグレーションする必要があります。トレーディング パートナ プロファイルの概要については、「トレーディング パートナ プロファイル」を参照してください。WebLogic Integration Administration Console でのトレーディング パートナ プロファイルのコンフィグレーション方法については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある以下のトピックを参照してください。
証明書およびプライベート キーの ID と信頼キーストアを作成およびコンフィグレーションする必要があります。キーストアの概要については、「プライベート キーと証明書のキーストア」を参照してください。キーストアを作成およびコンフィグレーションする手順については、以下のトピックを参照してください。
トレーディング パートナにデジタル証明書を追加する必要があります。証明書の概要については、「デジタル証明書」を参照してください。WebLogic Integration Administration Console での証明書のコンフィグレーション方法については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」の「証明書のトレーディング パートナへの追加」を参照してください。
WebLogic Server Administration Console で、転送レベルのセキュリティについて SSL をコンフィグレーションする必要があります。概要については、「SSL プロトコル」を参照してください。コンフィグレーション手順については、『WebLogic Server のセキュリティ』の「SSL のコンフィグレーション」を参照してください。
メッセージ交換で使用する転送レベルおよびメッセージ レベルのセキュリティ オプションを決定する必要があります。次に、それらのオプションを、各トレーディング パートナのサービス プロファイルにコンフィグレーションする必要があります。たとえば、あるトレーディング パートナとは相互認証を使用し、別のトレーディング パートナとは基本認証を使用することが可能です。同様に、顧客やベンダに対しては否認防止性を実装し、自社内のトレーディング パートナに対しては実装しないようにできます。
WebLogic Integration Administration Console でのサービス プロファイルの管理の手順については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある以下のトピックを参照してください。
The WebLogic Platform ドキュメント セットには、さまざまなセキュリティ関連トピックが含まれています。
セキュリティに関する最新の勧告を常に通知し、セキュリティ関連パッチが入手可能になったときにただちにアクセスできるようにするために、BEA では、次の URL で「BEA Advisories Notifications」ページを管理しています。
http://dev2dev.bea.com/advisories
WebLogic Platform 10.0 またはそのコンポーネントで発生する可能性があるセキュリティ上の問題を発見した場合は、secalert@bea.com (US) に報告をお願いします。
BEA dev2dev Web サイトには、以下を含むさまざまなセキュリティ固有のリソースへのリンクを提供する Web ページが用意されています。
dev2dev サイトには、BEA WebLogic Platform とその他の BEA Products に関してよく聞かれる質問 (FAQ) に対する答えを示す Web ページも含まれています。サイトは毎月更新されます。dev2dev FAQ ページにアクセスするには、次のリンクをクリックします。
http://dev2dev.bea.com/topitems/topsolutions/index.jsp
  
|
