特集 ASP.NET vs. Struts フレームワーク徹底比較［後編］ 山田 祥寛 2004/08/25
Page1 Page2 Page3 Page4

セキュリティ管理

　アプリケーションがますますミッション・クリティカルな分野に適用されるに及んで、セキュリティに対する意識は高まりつつある。クラッカーからの攻撃によって、アプリケーションが停止すれば、時として業務に重大な支障をきたすこともあるし、場合によっては、顧客の信頼を損なうことにもなりかねない。

　アプリケーションが確実に、かつ、堅牢なセキュリティ機能を実装する方法を提供するのは、いまやアプリケーション・フレームワークの重要な命題の1つともいえる。

■認証

　ASP.NETでは、「Windows」「フォーム」「Passport」という3種類の認証機能にデフォルトで対応しており、Windowsプラットフォーム上のユーザー管理と連動した認証から、インターネット上の.NET Passportサービスを利用した認証までを実現することができる。

　例えば、イントラネット内のある程度限定された環境下で、既存のユーザー管理情報を利用したい場合には、Windows認証を利用すればよいし（参考「Windows認証を実装したWebアプリケーション」）、インターネット上で複数のアプリケーションに対してシングル・サインオンを実現したい場合にはPassport認証が有効だ。

　一般的なインターネット上のアプリケーションでは、柔軟性に富んでおり、外部サービスにも依存しないフォーム認証を利用するとよいだろう（参考「構成ファイルのみでフォーム認証を実現するには？」）。フォーム認証では、ログイン画面を自由にカスタマイズできるのみならず、ユーザー情報を管理するためのデータストアを自由に選択できるというメリットもある。詳細は、別稿「フォーム認証のユーザー管理をXMLファイルで行うには？」「フォーム認証のユーザー管理をデータベース・サーバで行うには？」などを参照していただきたい。

　一方のStrutsは、J2EEの基本的な認証機能（「基本認証」「フォーム認証」「ダイジェスト認証」「クライアント証明書」）を利用することができる。

　.NET特有のPassport認証は例外として、ほぼASP.NETと同等の認証機能を実装していると思ってよいだろう（参考「アクセス制限をweb.xmlの記述だけで実現する」「フォーム認証でログイン画面をカスタマイズする」）。

■認定

　ユーザー認証が完了した後は、アプリケーション配下のどのリソースに対してアクセスを認めるかが決定される。この機能は一般的に「認証」とは区別して「認定」と呼ばれる。

　ASP.NETでは、この認定処理をweb.config上のエントリに従って行う。

　詳細は別稿「構成ファイルの適用範囲を限定するには？」をご覧いただくとして、細かいアクセス制御を行うには、この方法が決してシンプルでないことは一目見てお分かりになると思う。

　アプリケーション構成の保守性を考慮した場合、フォルダ単位の認定設定を行うのがより好ましい。もしもページ単位に認定設定を細かく制御したい場合には、自前の仕組みを構築する必要があるだろう。方法の詳細については、別稿「ページ単位にユーザーのアクセス可否を制御するには？）」を参照いただきたい。

　一方、すでに何度か述べているように、Strutsではコンフィグレーション・ファイルがすべてのアクションに関する情報をあらかじめ管理している。

　従って、認定情報を追加するのも容易だ。以下のように、<action>要素にアクションの可否を認めるロールに関する情報を追加すればよい。アプリケーション情報を一元的に管理する強みが、ここでも現れてくるというわけだ。

<action path="/Sample" type="net.wings.SampleAction"       name="SampleBean" scope="request" roles="admin,manager">   <forward name="success" path="/sample.jsp" /> </action>

アクションの可否を認めるロール情報を追加した<action>要素

この記述はStrutsのコンフィグレーション・ファイル「struts-config.xml」より抜粋したもの。Strutsではコンフィグレーション・ファイルがすべてのアクションに関する情報をあらかじめ管理しているため、認定情報を追加するのも容易だ。

■ユーザー情報のデータストア

　ASP.NETでは、ユーザー情報のデータストアは認証方法に依存する。

　Windows認証であれば、Windowsプラットフォームのデフォルトのユーザー情報が利用されるし、Passport認証ではインターネット上で公開されている.NET Passportサービスがデータストアとなる。フォーム認証では、デフォルトではweb.config上でユーザー情報を管理する。

　ただし、ユーザー管理のデータストアが、それぞれに独自の形式であることに抵抗を感じる方は意外と少なくないはずだ。例えば、Windowsプラットフォームによるユーザー管理も、ユーザー数が限られた（管理者が厳密にユーザーを把握できる規模の）イントラネット環境ならば問題ないが、不特定多数のユーザーを管理するインターネット環境においては不便を感じることが少なくないはずだ。

　ユーザー管理工数自体が、アプリケーションのボトルネックとなる可能性も少なくない。また、.NET Passportサービスによるユーザー管理の場合、ユーザー管理を完全に外部サービスに委ねられるという利点はあるものの、半面でユーザー管理がブラックボックス化してしまうという難点もある。

　そして、web.configによるユーザー管理では、やはり形式がXMLであることに抵抗を感じる方は、意外と少なくないだろう。XMLというデータ形式はいまやデータ記述言語として確実に定着しつつあるものの、まだまだ登場して日が浅いアーキテクチャでもある。そもそも不特定多数のユーザーをXMLファイル上で管理しようとした場合、更新の仕組みを用意するのが煩雑であるなど、開発者にとってなかなか厄介な問題も多い。セキュリティの観点からも、データ管理の側面からも、一般的にはデータベース・サーバによるユーザー管理が、より簡便でもある。

　しかし、残念ながら、ASP.NET 1.1ではデータベース・サーバによるユーザー管理にデフォルトで対応していない。別稿「フォーム認証のユーザー管理をデータベース・サーバで行うには？」のように、自前の仕組みを用意する必要がある。

　一方、Struts（J2EE）では、使用しているアプリケーション・サーバの種類に依存はするものの、例えばTomcatならば、デフォルトのXMLファイル（tomcat-users.xml）のほか、データベース・サーバやLDAPサーバをデータストアとして利用することができる。

　別稿「Tomcatのユーザー情報をデータベースで管理する」などを参照いただくと分かるように、アプリケーション・サーバ組み込みの機能を利用できるので、ユーザー管理にデータベース・サーバを使うための特別なコーディングは不要であることが分かるはずだ。

　ただし、ASP.NETでも次期バージョンの2.0では、メンバシップ機能を利用することで、セキュリティ管理が大幅に簡素化される予定だ。Microsoft AccessやSQL Serverをユーザー管理のストアとして採用することも可能になる（参考「ASP.NET 2.0の新しいメンバシップ機能」）。また、「セキュリティ・コントロール」と呼ばれる一連のサーバ・コントロールを利用することで、ログイン画面やパスワード問い合わせ画面の構築など、セキュリティ機能にかかわる一連のコーディングが大部分不要になる。

セッション管理

　ステートレスな（状態を持たない）HTTPプロトコルをベースとするサーバ・サイド技術の世界では、「セッション管理」機能が重要だ。

　複数のリクエスト間で情報を維持するために、かつてはクエリ情報や隠しフィールドなどを利用していたものだが、管理すべき情報量が多くなればコーディングも煩雑となり、誤りの原因ともなった。しかし、セッション機能を利用することで、通常の変数にデータを出し入れするのとほとんど同じ感覚で、情報を維持することができる。

　詳細は別稿「セッションとビューステート」「画面間の共有データを管理する−sessionオブジェクト−」などをご覧いただければ分かるように、ASP.NET／Struts（J2EE）はよく似たセッションの仕組みを提供している。

　ただし、セッション情報を格納するための機構として、ASP.NETは以下の3つのアプローチを提供している。

モード	概要
インプロセス	サーバのメモリ上でセッション情報を保持する（デフォルト）
ステート・サービス	専用のASP.NET State Service（Windowsサービスとして動作する）でセッション情報を管理する
データベース	SQL Serverデータベースでセッション情報を管理する
ASP.NETが提供する3つのセッション・モード

　同様の機能は一部のJ2EE対応アプリケーション・サーバでは対応しているものの、Struts（J2EE）標準の機能としては実装されていない。

　なお、ASP.NETにおけるステート・サービス、データベースそれぞれに関する詳細は「セッション情報を外部プロセスで管理するには？」「セッション情報をSQL Server上で管理するには？」を参照いただきたい。

国際化機能

　Webアプリケーションの役割がますますビジネス密着型のものとなり、対象となる顧客層もグローバルなものとなる中、アプリケーションを「国際化対応」したいというニーズは、いわば必須の要件となりつつある。

　しかし、国際化対応と一口にいっても、その作業は大概にして煩雑だ。例えば、最も原始的な国際化の手法として、必要な言語の数だけアプリケーションを多重化する方法が挙げられる。しかし、この方法を採用した場合、対応すべき言語の数が増加するほどにアプリケーション全体としての保守性は低下する。何かしらバグフィックスや改訂を行わなければならない状況が発生するたびに、言語の数だけ同じ修正を施さなければならないからだ。当然、増えるのは修正それ自体の手間だけではなく、テストの手間もリリース（配置）の手間も増える。保守性の低下は、また同時に、バグを混在させる原因ともなるだろう。

　しかし、ASP.NET／Strutsではいずれも国際化対応を支援するための専用の機能が実装されており、開発者の負担を大幅に軽減してくれる。

　詳細は、別稿「リソース・ファイル活用で国際化対応サイトを構築するには？」（ASP.NET）や「国際化対応アプリケーションの作成」（Struts）をご覧いただけば分かるように、両者のアプローチは比較的よく似ている。

　要は、言語（地域）依存要素を言語ごとのリソース・ファイル（プロパティ・ファイル）にあらかじめ切り出しておき、アプリケーションからはクライアントの言語設定によって適切なリソースを参照するというものだ。これによって、言語がいくら増えようとも、リソース・ファイルを増やせばよいだけなので、アプリケーションに対するインパクトは最小化できる。

　ただし、Strutsでは国際化対応ページをプログラム・レスで実現するために、専用の<bean:message>タグが用意されているのに対して、ASP.NETの世界ではこれに該当するものが存在しない。別稿「国際化対応サイトをプログラムレスで実現するには？」でも紹介しているように、自前でカスタム・コントロールを組み込むなどの対応が必要になるだろう。

INDEX
	［特集］ASP.NET vs. Struts フレームワーク徹底比較［前編］
	1．フレームワークとは何か？
	2．実行環境から見るASP.NETとStruts
	3．開発環境から見るASP.NETとStruts
	4．フレームワークの内部構成
	［特集］ASP.NET vs. Struts フレームワーク徹底比較［後編］
	1．ユーザー・インターフェイス構築要素
	2．入力妥当性チェック機能／アプリケーションの構成ファイル
	3．セキュリティ管理／セッション管理／国際化機能
	4．キャッシング機能／テンプレート機能

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）