| IceWall の自動フォーム認証機能を設定するには、接続する
Web システムから送信されるログインフォームページのテキストコンテンツから、ログイン用ページであることを特定できるキーワードを抽出する必要があります。
今回の検証当初、 EP のフォーム認証用ログイン画面を表示させたブラウザの「ページのソース」メニューによる情報から抽出したキーワードで、自動フォーム認証設定を行いましたが、正しく動作しませんでした。原因を調査した結果、ブラウザから
” Accept-Encoding: gzip, deflate” ヘッダを含んだリクエストが送信されているため、 EP が圧縮したログインコンテンツを返却していることがわかりました。
IceWall の自動フォーム認証機能は、 ” Content-Encoding: gzip” ヘッダが付加された圧縮コンテンツに対して動作しません。
そこで、ブラウザから受信した ” Accept-Encoding” ヘッダを EP へ送信しないようにする追加設定（ EP 用ホスト設定ファイルの「
HEADER 」項目）を行いました。
EP 用ホスト設定ファイルへの設定例
| HEADER=HTTP_ACCEPT_ENCODING,NOTSEND
|
HEADER 項目が設定されていない場合
HEADER 項目が設定されている場合
この設定により、 EP がログイン画面のコンテンツを圧縮せずに IceWall へ返却し、 IceWall がコンテンツの解析を行えるようになったため、自動フォーム認証機能が正しく動作するようになりました。
ただし、コンテンツ圧縮せずに通信するため、ブラウザと EP が直接通信する場合より、下りのデータ量が多くなり、より大きな帯域を必要とする恐れがあります。
ログアウト時の動作には多少の工夫が必要です。 EP の右上部にある「ログオフ」をクリックしてログオフが完了すると、 EP のセッション
Cookie がない状態で EP 自体にリダイレクトされ、ログイン画面が返却されるフローとなっています。それを IceWall
の自動フォーム認証機能が検出して自動認証を行い、 EP への再ログインが実行されてしまいます。
一方、 IceWall 側のログアウト処理を行う（ IceWall のログアウト用 URL を指定してアクセスする）と、 EP
のログオフは行われず、ブラウザには EP のセッション Cookie が残されます。
この現象を解決するには、ユーザ Exit ルーチンを使用して、 IceWall でログアウト処理を行うタイミングに、 EP に対してログオフの
POST 電文を送信する等の対策が考えられます。（今回は未検証）
この現象は EP 特有のものではなく、自動フォーム認証機能を使用する場合に多く発生するケースであり、同様の対策によって、 IceWall
・バックエンドアプリケーション双方でログアウトを実施することが可能となります。
今回の検証では、フォーム認証を使って EP へのログインを行いました。 EP はヘッダ認証を使ったログインも可能とのことですので、その場合には、自動フォーム認証機能ではなく情報継承機能で
IceWall と EP の認証連携も可能と考えられます。
|
