|
| Sun ONE Application Server 7 Web アプリケーション開発者ガイド |
Web アプリケーションのセキュリティこのmoduleでは、Sun ONE Application Server でユーザー認証とアクセス承認を実行するコンポーネントを持つ、安全な Web アプリケーションを作成する方法について説明します。
この moduleには次の節があります。
サーブレットによるユーザー認証
J2EE 仕様バージョン 1.3 で要求される Web ベースのログインメカニズムは Sun ONE Application Server でサポートされています。これらのメカニズムは次のとおりです。
web.xml 配備記述子ファイルの login-config 要素は、使用される認証方法、HTTP 基本認証で表示されるアプリケーションのレルム名、およびフォームログインメカニズムの属性を記述します。
login-config 要素の構文は次のとおりです。
<!ELEMENT login-config (auth-method?,realm-name?,form-login-config?)>
注 login-config の auth-method サブ要素は公式には省略可能ですが、このサブ要素がないと、サーバーはデフォルトで HTTP 基本認証を使用します。この認証はあまり安全ではありません。
web.xml の要素の詳細については、Java Servlet 仕様バージョン 2.3 の第 13 章「Deployment Descriptor」を参照してください。
sun-web.xml の要素の詳細については、「Web モジュールの構築と配備」を参照してください。
プログラムによるログインの詳細については、『Sun ONE Application Server 開発者ガイド』を参照してください。
HTTP 基本認証
HTTP 基本認証 (RFC2068) は Sun ONE Application Server でサポートされています。パスワードは base64 エンコード方式で送信されるので、この種の認証はそれほど安全ではありません。転送時にパスワードを保護するために、SSL または同等のトランスポートの暗号化を使用することをお勧めします。
SSL 相互認証
Secure Socket Layer (SSL) 3.0、およびクライアントとサーバーの相互の証明書ベースの認証を実行する方法は、J2EE 仕様バージョン 1.3 の要件です。このセキュリティメカニズムによって、HTTPS (SSL 上の HTTP) を使ったユーザー認証が提供されます。
Sun ONE Application Server の SSL 相互認証メカニズム (HTTPS 認証とも呼ばれる) は、次の一連の暗号をサポートしています。
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHAフォームによるログイン
ログイン画面の見た目と使いやすさは、HTTP ブラウザの組み込みメカニズムでは制御できません。J2EE では、ログイン用の標準 HTML フォームやサーブレットまたは JSP ベースのフォームをパッケージ化する機能を導入しています。ログインフォームは Web 保護ドメイン (HTTP レルム) に関連付けられ、まだ認証されていないユーザーを認証するために使われます。
基礎となっているトランスポートで保護されていない限り、パスワードがセキュリティで保護されずに送信されるため、この種の認証はあまり安全ではありません。転送時にパスワードを保護するために、SSL または同等のトランスポートの暗号化を使用することをお勧めします。
認証を適切に処理するには、ログインフォームのアクションが常に j_security_check である必要があります。
HTML ページ内でフォームをプログラムする方法を示す HTML サンプルは次のとおりです。
<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="password" name="j_password">
</form>フォームのパラメータエンコードを指定できます。詳細については、「parameter-encoding」を参照してください。
シングルサインオンでのユーザー認証
Sun ONE Application Server 上の複数のアプリケーションにわたるシングルサインオンは、Sun ONE Application Server のサーブレットおよび JSP によってサポートされます。この機能によって、同一のサインオン情報を複数のアプリケーションで共有できるので、ユーザーはアプリケーションごとにサインオンする必要がありません。これらのアプリケーションはユーザー認証を 1 度だけ行うように作成されており、この認証情報は必要に応じてほかの関連するアプリケーションに伝えられます。
シングルサインオンのシナリオを使うアプリケーションの例としては、すべての航空会社を検索し、各航空会社の Web サイトへのリンクを提供する、統合航空券予約サービスがあります。ユーザーが統合予約サービスにサインオンすると、そのユーザー情報を各航空会社のサイトで使用できるので、別のサインオンを要求する必要はありません。
シングルサインオンは次の規則に従って動作します。
- シングルサインオンは、同じレルムと仮想サーバー向けに設定された Web アプリケーションに適用される。レルムは web.xml ファイル内の realm-name 要素で定義される。仮想サーバーについては、『Sun ONE Application Server 管理者ガイド』または『Sun ONE Application Server 管理者用設定ファイルリファレンス』を参照
- 仮想サーバー上にある任意の Web アプリケーション内の保護されていないリソースだけにユーザーがアクセスしている場合、ユーザー認証は行われない
- 仮想サーバーに関連付けられている任意の Web アプリケーション内の保護されているリソースにユーザーがアクセスすると、ユーザーに対して認証が要求される。このとき、現在アクセス中の Web アプリケーションに定義されているログイン方法が使用される
- ユーザーが認証されると、関連付けられているすべての Web アプリケーションで、このユーザーに関連付けられているロールがアクセス許可の判断に使用される。各アプリケーションで個別にユーザー認証を行う必要はない
- ユーザーが 1 つの Web アプリケーションからログアウトすると (たとえば、フォームベースのログインを使用している場合は、対応するセッションを無効またはタイムアウトにして)、ユーザーのセッションはすべての Web アプリケーションで無効になる。その後、いずれかの Web アプリケーションで保護されているリソースにアクセスしようとすると、もう一度認証が要求される
シングルサインオン機能は、保存されているユーザー識別情報を各要求に関連付けるトークンを送信するために HTTP cookie を使用します。したがって、cookie がサポートされているクライアント環境でのみ使用できます。
シングルサインオン機能を設定するには、server.xml ファイルの virtual-server 要素内に次のプロパティを設定します。
- sso-enabled : false の場合、この仮想サーバーに対してシングルサインオンが無効になり、ユーザーは仮想サーバー上のアプリケーションごとに個別に認証を行う必要がある。デフォルトは true
- sso-max-inactive-seconds : クライアントが活動停止後、ユーザーのシングルサインオンの記録がパージされるまでの時間を指定する。シングルサインオンは同一仮想サーバー上の複数のアプリケーションに適用されるので、これらのアプリケーションのいずれかにアクセスすることでシングルサインオンの記録は有効なまま確保される。デフォルト値は 5 分 (300 秒)。値を大きくすればユーザーのシングルサインオンの持続時間が長くなるが、サーバー上のメモリー消費量も増える
- sso-reap-interval-seconds : 期限切れのサインオンの記録がパージされる間隔を指定する。デフォルト値は 60
次に、すべてデフォルト値を設定した例を示します。
<virtual-server id="server1" ... >
...
<property name="sso-enabled" value="true"/>
<property name="sso-max-inactive-seconds" value="300"/>
<property name="sso-reap-interval-seconds" value="60"/>
</virtual-server>サーブレットによるユーザー承認
適切な承認レベルを持つユーザーのアクセスだけを許可するようにサーブレットを設定できます。この節では次のトピックについて説明します。
ロールの定義
ロールは、J2EE 配備記述子ファイル web.xml に定義し、対応するロール割り当ては、Sun ONE Application Server 配備記述子ファイル sun-application.xml (個別に配備された Web モジュールの場合は sun-web.xml) 内に定義します。sun-web.xml の詳細については、「Web モジュールの構築と配備」を参照してください。
sun-application.xml ファイルまたは sun-web.xml ファイル内の各 security-role-mapping 要素は、アプリケーションで許可されるロール名を宣言し、それを主体とグループに割り当てます。たとえば、個別に配備された Web モジュールの sun-web.xml ファイルには次の内容が含まれています。
<sun-web-app>
<security-role-mapping>
<role-name>manager</role-name>
<principal-name>jgarcia</principal-name>
<principal-name>mwebster</principal-name>
<group-name>team-leads</group-name>
</security-role-mapping>
<security-role-mapping>
<role-name>administrator</role-name>
<principal-name>dsmith</principal-name>
</security-role-mapping>
</sun-web-app>この例での role-name は、対応する web.xml ファイル内の security-role 要素の role-name と一致する必要があります。
J2EE アプリケーション (EAR ファイル) の場合、アプリケーションモジュールのすべてのセキュリティロールの割り当ては sun-application.xml ファイルに指定する必要があります。個別に配備された Web モジュールについては、常に sun-web.xml ファイルでロールを指定します。ロールは特定の主体またはグループ、あるいはその両方に割り当てることができます。割り当てに使用する主体名やグループ名は、現在のデフォルトレルムで有効な主体またはグループであることが必要です。
サーブレットによる承認の制約の定義
サーブレットレベルでは、web.xml ファイルの auth-constraint 要素を使ってアクセス権を定義します。
リソースコレクションの auth-constraint 要素を使って、リソースコレクションが許可されるユーザーロールを指定する必要があります。サーブレットによる承認の制約を設定する方法については、サーブレットの仕様を参照してください。
クライアント証明書のフェッチ
SSL を有効にしてクライアント証明書の承認を行う場合、サーブレットは次の例のようにクライアント証明書へアクセスします。
if (request.isSecure()) {
java.security.cert.X509Certificate[] certs;
certs = request.getAttribute("javax.servlet.request.X509Certificate");
if (certs != null) {
clientCert = certs[0];
if (clientCert != null) {
// ユーザーの識別名を取得します。
java.security.Principal userDN = clientCert.getSubjectDN();
...
}
}
}userDn はユーザーの完全修飾識別名です。
SHTML と CGI のセキュリティ
セキュリティ確保のために、サーバーでパースされる HTML タグや CGI スクリプトは、サーバーのセキュリティの設定に依存します。次の J2EE 固有のセキュリティ機能は、サーバーでパースされる HTML タグや CGI スクリプトには使用できません。
- J2EE レルム
- J2EE ロール
- フォームベースログイン
- シングルサインオン
- プログラムによるログイン
- J2EE 承認の制約
サーバーセキュリティの設定の詳細については、『Sun ONE Application Server セキュリティ管理者ガイド』を参照してください。