ディプロイリスナー

ディプロイリスナーを使用すると、Enterprise Developer IDE や imtkmake ユーティリティなどのディプロイクライアントで、COBOL Web サービスまたは EJB を Enterprise Server インスタンスにディプロイできます。ディプロイリスナー、関連するディプロイサービス、およびディプロイディレクトリ内の .mfdeploy ファイルを組み合わせて、ディプロイ要求の処理方法を制御します。

ディプロイの一部の側面は、ディプロイリスナーの構成情報の設定によって決まります。これらのセクションは、次のセクションで構成されています。

[virtual paths] セクション。URL の最上位ディレクトリおよびそれらが変換されるパスのリストを含みます。
[allow] セクション。仮想パスから何を取得できるかについてのルールを含みます。
(オプション) [security] セクション。ディプロイ用にセキュリティを構成します。

たとえば、ESDEMO の Deployer サービスで使用される Web リスナーは次のようになります。

[virtual paths]
cgi=<ES>/bin
uploads=<ES>/deploy
<default>=/dev/null
docs=<ES>/help

[allow]
cgi=mfdeploy.exe
uploads=*.txt *.car *.wsdl

cgi 仮想パスは、ディプロイされる COBOL アーカイブファイルを受け取る mfdeploy.exe プログラムの場所の指定に使用されます。uploads 仮想パスは、アップロードされた COBOL アーカイブファイルのディレクトリの作成場所を mfdeploy.exe に伝えます。

mfdeploy.exe は、 %ProgramFiles(x86)%\Micro Focus\Enterprise Developer\bin and \bin64 にあります。

Windows プラットフォームでは、特別なトークン <ES> はインストールディレクトリに変換されます。たとえば、Enterprise Server が Enterprise Developer の一部としてデフォルトのインストールディレクトリにインストールされている場合、「<ES>/deploy」は %ProgramFiles(x86)%\Micro Focus\Enterprise Developer\deploy になります。

ディプロイを実行するクライアントで指定される URL の最初のディレクトリのみがリストに照らし合わせてチェックされ、リストのエントリは単一ディレクトリ名でなければなりません。

<default> ディレクトリは、クライアントで指定された URL の最初のディレクトリがリストのどのエントリとも一致しない場合に使用されます。デフォルトのディレクトリは、存在しないディレクトリでなければなりません。そのため、通信プロセスが URL をフルパスに変換する場合、要求は失敗します。これにより、クライアントによるマシン上の任意のディレクトリの参照が停止します。通信プロセスはいずれにしても安全なデフォルトを使用するため、デフォルトのディレクトリを指定する必要はありません。

「docs」仮想パスは製品ドキュメントを取得するために使用できますが、主に歴史的な理由で存在しています。

別の例を示します。

[virtual paths]
 <default>=c:/web
 docs=c:/web/documents
 images=d:/media/images

この構成では、URL http://host:port/docs/a.html はファイル c:\web\documents\a.html を戻し、URL http://host:port/images/gif/b.gif はファイル d:\media\images\gif\b.gif を戻します。

「[allow]」セクションのエントリは、仮想パスから取得できるファイルを制限します。そのエントリは仮想パスの名前であり、それらの値はファイル名パターンです (スペースで区切られます)。そのうちの 1 つは、要求されたファイルと一致しなければなりません。新しいディプロイサービス用に作成された構成では、「cgi」仮想ディレクトリでは mfdepinst.exe のみが許可され、「uploads」仮想ディレクトリではその下のディプロイディレクトリのテキスト (*.txt)、COBOL アーカイブ (*.car)、および WSDL (*.wsdl) ファイルのみが許可されます。

[security] セクション

Enterprise Server 5.0以降、ディプロイリスナーには以下の追加のオプションセキュリティ機能が用意されています。

ディプロイリスナーは、リクエストごとにユーザー認証を要求できます。これにより、ディプロイへの匿名アクセスが阻止され、ディプロイは有効な資格情報を持つクライアントによってのみ実行されます。資格情報は、Enterprise Server インスタンスのセキュリティ構成に対して検証されたユーザー名とパスワードのペア、またはクライアント証明書です (リスナーの構成に応じて異なります)。
ユーザー認証が有効になっている場合は、特定のユーザーへのアクセスを制限するように Enterprise Server のセキュリティシステムを構成することもできます。
また、ユーザー認証を有効にすると、Micro Focus Directory Server (MFDS) にバインドする際に認証済みユーザーを使用するように mfdepinst プログラムを構成して、新しいサービスオブジェクトおよびパッケージオブジェクトを作成できます。これは、Enterprise Server 構成情報の更新をより緻密に制御する必要がある管理者にとって便利です。詳細については、.mfdeploy ファイルのドキュメントを参照してください。

これらの機能は、ディプロイリスナーの構成テキスト領域の [security] セクション (任意指定) で有効になります。次に例を示します。

[security]
restricted=yes
authentication=MF, HTTP

詳細は次のとおりです。

restricted=yes 設定では、ユーザー認証が有効になります。また、この設定によりアクセス制限も有効になります (サーバーのセキュリティ構成がリソースアクセス制御をサポートし (最も一般的には Enterprise Server 用の LDAP ベースのセキュリティを使用)、リソースクラス「Enterprise Server Web」が External Security Manager に定義されている場合)。class 設定を使用することで、このクラスに別の名前を構成できます。トピック「サービスディプロイへのアクセス制限」を参照してください。
authentication=MF, HTTP 設定は、クライアントからのユーザー名とパスワードのユーザー資格情報をサポートするようにリスナーに指示します。資格情報は、旧バージョンの Enterprise Developer で使用される独自メカニズム (下位互換性用)、または標準 HTTP 基本認証のどちらかによって渡されます。

[security] セクションの構文の詳細については、「Web 対話タイプ」トピックを参照してください。

ディプロイ用の証明書認証

ディプロイリスナーを構成して、クライアント証明書を使用してユーザーを識別できます。この構成でディプロイクライアントがディプロイリスナーに接続すると、証明書が送信されます (TLS ハンドシェイクの一部として、証明書に対応するプライベートキーが証明書に含まれていることが証明されます)。リスナーは証明書を Enterprise Server ユーザーに関連付けてから、そのユーザーがサービスのディプロイを承認されているかどうかを確認できます。

証明書認証には以下の要件があります。

Enterprise Server インスタンスは、外部セキュリティ (ESF) を使用するように構成する必要があります。これは、あらゆる種類のディプロイリスナー認証およびアクセス制御に該当します。
ディプロイリスナーは SSL/TLS を使用するように構成する必要があります。
1. リスナーのSSL/TLS 構成は、クライアント証明書を要求してそれらを検証する (証明書を必要とする) ように設定するか、クライアント証明書が存在する場合にはそれらを検証する (許可するが必須ではない、つまり証明書認証を省略可能にする) ように設定する必要があります。
2. SSL/TLS 構成では、信頼された証明機関の署名証明書 (ルート証明書とも呼ばれます) のコレクションを指定する必要があります。
リスナーの構成では、構成テキスト領域で証明書認証を有効にする必要があります。certificate または register トークン (あるいはその両方) を指定する Authentication を含む [Security] セクションを含める必要があります。
クライアント証明書を送信するには、通常は mf-client.dat ファイルを使用してディプロイクライアントを設定する必要があります。この証明書は、リスナーに指定されたコレクション内のいずれかの証明機関の署名証明書によって署名されている必要があります。
クライアント証明書は、Enterprise Server インスタンスに認識され、ユーザーに関連付けられている必要があります。これを行うには、次の 2 つの方法があります。
1. 証明書は、cascertreg コマンドラインユーティリティを使用して Enterprise Server に登録できます。
2. 次のセクションで説明するとおり、自動登録が有効になっている場合、ユーザーは同じクライアント証明書を送信するように構成されている Web ブラウザーを使用してディプロイリスナーに接続できます。ブラウザーは、証明書に関連付ける Enterprise Server のユーザー名およびパスワードの入力を求めます。Enterprise Server がユーザー名およびパスワードの認証に成功すると、証明書が登録されます。
  自動登録は、ユーザーがユーザー名およびパスワードを指定できるようにするディプロイクライアントでも実行できます。ディプロイクライアントがクライアント証明書を使用するように構成されており、さらにユーザー名およびパスワードも構成されている場合、サーバーが証明書を認識しないと自動的に証明書を登録しようとします。証明書が登録されたら、ユーザー名およびパスワードをクライアントの構成から削除できます。