TAM研修3日目
の続き。
ジャンクション
WebSEALの特徴的なところ。WebSEALのバックエンドには複数のWebサーバがあるわけだが、どうやって振り分けてるの？ ってところの解決法なんだが、WebSEALはかなり無理している。
WebSEALはURLのホスト・ドメイン後のパスの部分にマッピングして解決している。バックエンドのWebサーバではhttp://hogehoge/path1/となるところへWebSEAL経由でアクセスするとhttp://hogehoge/junction_name/path1としてアクセスさせる。junction_nameにWebサーバ個々のアドレスを割り当てる方式だ。
実はバージョン6辺りからバーチャルホストで割り当てる方式が追加されたが、それまではジャンクションによる解決のみだった。
かなり無理している
というのは例えば、HTMLのリンクが/path1/hoge.htmlという様な絶対パスでの記述やhttp://hoge/path1/hoge.html等を想像してみると分かり易い。WebSEAL経由でアクセスするとジャンクションが無いため404が返ってしまう。解決に次回アクセスにはHTTPリファラーを見たり、ジャンクション名をCookeiに仕込んだり、フィルターでリンクの書き換えを行ったりする。なんだかどれもその場しのぎである。AppletやFlash等のバイナリ内でのリンクには手が出せないこともあり完璧でない。
新たに加わったバーチャルホストでの解決の方がスマートと言える。他社の製品ではバーチャルホストでの解決が一般的らしい。当然だ。
SSO (Single Sign-On)
Webサーバ自信でも認証を行っている場合、WebSEALで認証後またWebサーバで認証が発生してしまう。その解決としてSSOがある。WebSEALでの認証で用いたユーザ名等からマップされたユーザ名、パスワードを用いてWebSEAL-Webサーバ間で認証を済ませてしまうのである。強引なイメージだ。
また、マップは自信で定義する必要があり、かなり面倒。
