日々の破片

_ Webアプリケーション境界とセキュリティ境界

1個のでっかなWARとするのは、webアプリケーションが論理的に複数のサブシステムに分割できる場合、あまりうまい方法とは思えない。

複数のWARで管理すれば、サブシステム単位の独立性が上がるから、たとえば1部のバージョンアップなんかが全体に与える影響を抑制できるからだ。

でも、このwebサーバーが業務システムサーバーだと、今度はセキュリティ境界の設定が難しくなる。特にセッション情報に依存させる場合だ。

具体的には、webサーバー全体をカバーする仕組みとしてはBasic認証とかあるけれど、3種類のロール、5000人の（しかも頻繁に移動があり得る）ユーザーというような場合には、既存のアクセス管理の仕組みを利用したくないからだ。

#とは言うもののJDBCレルム使って、ユーザー登録時にテーブルを同時にメンテする仕組みを作ればいいような気もする。

いずれにしても、Webアプリケーションのコンテキストをまたがるセッション情報の引き継ぎはできないから、/をレルムとするBasic認証以外ではコンテキストをまたがった時点で以前の情報は失われてしまう(はず)。

しかしBasic認証であれば、セッション情報は消えてもレルムが/である限り、ブラウザーがAuthentication:フィールドを送ってくるからHttpservletRequest#getUserPrincipalでユーザー名が取得できる（はず）。ーDigest認証でも同様（のはず）。

ところが、望まれているのはユーザーアプリケーションによるビジネスルールに基づく認証（たとえば、社員コードの範囲チェックによるロールの割当など）だとする。

この場合、クッキーの読み取り範囲を/とすれば実現できなくはない。SSLセッションっていうのは、ログインしたHTTPSの範囲内でUserPrincipalを保持するんだろうか？ ならば、これも大丈夫だ。だが、クッキーを利用しない前提ならどうすれば良いのだろう？

ビジネスルールを生かそうとして、かえって問題が生じて面倒な回避策を考えなければならない例にはなってないだろうか？ セッションのチェックをRequesetProcessorかFilterで一元化して実行すれば、昇格は防御できるだろう（この場合も昇格で良いのかな？）。その場合の手数は、user/roll表の作成/管理よりも少ないか？ （管理は無限に続くが、開発は1回かも知れない）