Sun ONE ロゴ      前へ      目次      索引      次へ     

Sun ONE Web Server 6.1 管理者ガイド

第 4 章
Web コンテナと Web アプリケーションの J2EE ベースのセキュリティ

この章では、Sun ONE Web Server 6.1 Web コンテナおよび Web アプリケーションの J2EE ベースセキュリティの基本機能について説明します。まず、Web サーバーでサポートされる 2 つの主要認証、承認モデルである、ACL (アクセス制御リスト) ベースのセキュリティモデルと、J2EE/サーブレットベースのセキュリティモデルについて説明します。また、両方のセキュリティシステムを活用した Java Web アプリケーションを配備できる Sun ONE Web Server 6.1 の新機能についても説明します。

この章の残りのページでは、J2EE/サーブレットの設定に関する問題について説明します。関連するセキュリティの問題については、次の各章で説明します。

この章では、次の項目について説明します。

Sun ONE Web Server のセキュリティについて

Web サーバー上のリソースを、認証、承認、アクセス制御などのセキュリティサービスおよびメカニズムで保護することができます。

認証とは、同一性 (ID) を確認するためのプロセスのことです。承認とは、アクセスが制限されたリソースへのアクセス権を ID に与え、アクセス制御メカニズムはその制限を強化します。認証と承認は、多数のセキュリティモデルおよびサービスによって強化することができます。

Sun ONE Web Server 6.1 は、HTTP エンジンによって提供される ACL ベースのセキュリティモデルと、Web コンテナによって提供される J2EE Servlet バージョン 2.3 仕様に基づくセキュリティモデルの 2 モデルをサポートしています。

Sun ONE Web Server 6.1 プロセスのライフタイムでは、両方のモデルが共存します。それぞれのモデルが、クライアント認証と承認の両方のセキュリティ サービスをサポートします。

Sun ONE Web Server 6.1 の Web コンテナは、JAAS (Java Authentication and Authorization Service) ベースのレルムメカニズムによりクライアント認証を提供し、J2EE ロールベースのメカニズムにより承認を提供します。Sun ONE Web Server 6.1 が提供するレルムの一つに native レルムがあります。このレルムは、2 つのセキュリティモデルを結びつけています。

Sun ONE Web Server 6.1 は、宣言によるセキュリティとプログラムによるセキュリティの両方をサポートします。

Sun ONE Web Server 6.1 は、J2EE プラットフォームの機能を利用して、アプリケーションコンポーネントの開発およびアセンブル実行者と、操作環境でのアプリケーション設定者の間の宣言的契約を定義します。アプリケーションセキュリティの面では、アプリケーションの設定時にセキュリティ要件を満たせるように、アプリケーションプロバイダはアプリケーションのセキュリティ要件を宣言する必要があります。アプリケーションで使用される宣言によるセキュリティのメカニズムは、配備記述子というドキュメントに宣言構文として記述されます。アプリケーションの配備担当者はコンテナ固有のツールを使用して、配備記述子に定義されているアプリケーション要件を、J2EE コンテナによって実装されるセキュリティメカニズムにマッピングします。Sun ONE Web Server 6.1 の Web アプリケーション用配備記述子ファイルは、web.xml および sun-web.xml です。

プログラムによるセキュリティは、セキュリティ認識アプリケーションによるセキュリティに関する決定を参照します。プログラムによるセキュリティは、アプリケーションのセキュリティモデルを設計する上で、宣言によるセキュリティだけでは不十分な場合に便利です。たとえば、時刻、呼び出しのパラメータ、およびWeb コンポーネントの内部状態に基づいて認証を決定するアプリケーションがあります。また、データベースに格納されているユーザー情報に基づいてアクセスを制限するアプリケーションもあります。

この章の残りのページでは、Sun ONE Web Server 6.1 がサポートする次の認証および承認の主要概念について説明します。

ACL ベースのアクセス制御の概要

ACL ベースのアクセス制御については、第 9 章「サーバーへのアクセス制御」で詳しく説明します。次の項では、主要概念についてその概念を簡単に説明します。

Sun ONE Web Server 6.1 では、ローカルに保存されている ACL (アクセス制御リスト) により認証と承認を行います。ACL では、リソースに対してユーザーがどのようなアクセス権を持つかを規定しています。たとえば、ACL 内のエントリは、John というユーザーに、特定のフォルダ misc に対する読み取りアクセス権を与えることができます。

acl "path=/export/user/990628.1/docs/misc/";

  authenticate (user,group) {

      database = "default";

      method = "basic";

  };

  deny (all) (user="anyone");

  allow (read) (user = "John");

Sun ONE Web Server 6.1 内のコア ACL は、基本、SSL、ダイジェスト、という 3 種類の認証をサポートします。

基本認証は、クリアテキストとして渡される、ユーザー名とパスワードのリストを使用します。SSL 認証では、ブラウザがユーザー証明書を持つ必要があります。この証明書には、ユーザーの公開鍵と、名前や電子メールアドレスなど、その他のユーザー情報が含まれます。ダイジェスト認証は、暗号化方式を使用して、ユーザーの証明情報を暗号化します。

ACL ベースのアクセス制御モデルの主な機能は次のとおりです。

さらに、Sun ONE Web Server 6.1 の SSL エンジンは、SSL 処理の負荷を低減できるように外部の暗号化ハードウェアをサポートし、改ざん性に優れた鍵のストレージを提供します。

アクセス制御、および外部暗号化ハードウェアの使用については、第 9 章「サーバーへのアクセス制御」を参照してください。

J2EE/サーブレットベースのアクセス制御の概要

J2EE/サーブレットベースのアクセス制御については、『Sun ONE Web Server 6.1 Programmer's Guide to Web Applications』で詳しく説明しています。次の項では、主要概念についてその概念を簡単に説明します。

Sun ONE Web Server 6.1 は、ACL ベースの認証のほかに、J2EE 1.3 Specification で定義されているセキュリティモデルを利用し、安全な Java ベースの Web アプリケーションの開発および使用に役立ついくつかの機能を備えています。

J2EEベースの一般的な Web アプリケーションは、次の項目から構成されます。一部またはすべての項目へのアクセスは制限することが可能です。

J2EE/サーブレットベースのアクセス制御インフラストラクチャは、セキュリティレルムを使用します。ユーザーが Web ブラウザ経由でアプリケーションのアクセス保護対象セクションにアクセスしようとすると、Web コンテナはユーザーに証明情報の入力を要求し、そのアプリケーション用のセキュリティサービスで現在有効になっているレルムにその情報を渡して検証します。

J2EE/サーブレットベースのアクセス制御モデルの主な機能は次のとおりです。

次の節では、セキュリティレルムの概念について簡単に説明します。J2EE セキュリティモデルとレルムベースの認証の詳細な解説については、『Sun ONE Web Server 6.1 Programmer's Guide to Web Applications』を参照してください。

レルムベースのセキュリティ

J2EE ベースのセキュリティモデルは、ユーザーの識別および認証を行うセキュリティレルムを提供します。ユーザー情報は、基礎となるセキュリティレルムから取得されます。レルムベースのセキュリティは、次の 2 つの要素から構成されます。

レルムベースのユーザー認証

認証プロセスは、セキュリティドメインとも呼ばれる、基本となるレルムを使用してユーザーを検証します。レルムは、ユーザーのセット、オプションのグループマッピング、および認証要求を評価する認証ロジックから構成されます。設定されているレルムによって認証要求が検証され、セキュリティコンテキストが確立されると、run-as 条件によって否定されない限り、以後のすべての認証決定にこの ID が適用されます。

サーバーインスタンスに設定できるレルムの数に制限はありません。設定情報は、server.xml ファイルの AUTHREALM 要素に記録されます。

Sun ONE Web Server では、認証サービスは、プラグイン可能なセキュリティドメインを提供する JAAS を使用して行われます。Sun ONE Web Server 6.1 の Java 認証レルムは、Sun ONE Application Server 7.0 のレルムと互換性があります。

Sun ONE Web Server 6.1 には、次のレルムが用意されています。

LDAP レルム

ldap レルムを使用することで、LDAP データベースからユーザーのセキュリティ情報を取得できます。LDAP ディレクトリサービスは、属性と、それぞれの一意の ID の集合です。ldap レルムは、運用システムへの配備に適しています。

ldap レルムに対してユーザーを認証するには、LDAP ディレクトリ内に必要なユーザーを作成しておく必要があります。ユーザーの作成は管理サーバーの「Users & Groups」タブ、または LDAP ディレクトリ製品のユーザー管理コンソールから行えます。詳細は、「LDAP ベース認証データベースの新規ユーザーの作成」を参照してください。

file レルム

file レルムは、Sun ONE Web Server のインストール時のデフォルトレルムです。これは、設定が簡単で、開発者には便利なレルムです。

file レルムは、テキストファイルに保存されているユーザーデータに対してユーザーを認証します。file レルムがサポートする認証データベースは、次のとおりです。

ファイルベースの各種認証データベースについて詳細は、<add> を参照してください。

file レルムが使用するユーザー情報ファイルは、最初は空なので、file レルムを使用し始める前にユーザーを追加する必要があります。この方法については、「ファイルベース認証データベースの新規ユーザーの作成」を参照してください。

solaris レルム

solaris レルムでは、認証に Solaris のユーザー名とパスワードのデータを使用できます。このレルムをサポートしているのは、Solaris 9 のみです。このレルムは Solaris 9 オペレーティング環境のデータベースを使用するため、データベースを別に設定する手順は必要ありません。

証明書レルム

証明書レルムは、SSL 認証をサポートします。証明書レルムは、Sun ONE Web Server のセキュリティコンテキストにユーザー ID を設定し、その ID にクライアント証明書からのユーザーデータを移行します。次に、J2EE コンテナが、証明書に含まれる各ユーザーの DN に基づいて認証処理を行います。このレルムは、X.509 証明書による SSL または TLS クライアント認証を使用してユーザーを認証します。

サーバーとクライアントの証明書を設定する方法については、第 6 章「証明書と鍵の使用」を参照してください。

カスタムレルム

プラグイン可能な JAAS ログインモジュールと、レルムの実装を使用して、特定の用途に合わせて Oracle などのその他のデータベース用にレルムを作成することができます。クライアント側の JAAS ログインモジュールは、Sun ONE Web Server での使用に適していないことに注意してください。

Sun ONE Web Server 6.1 のサンプルレルムをテンプレートとして使用できます。

native レルム

native レルムは、ACL ベースのコア認証モデルと、J2EE/サーブレット認証モデルの間を結びつける特殊なレルムです。Java Web アプリケーションで native レルムを使用することで、Java Web コンテナを使用する代わりに ACL サブシステムを使用して認証を行い、この ID を Java Web アプリケーションで使用できるようにすることができます。

認証処理が開始されると、native レルムはこの認証をコア認証サブシステムに委託します。ユーザー側では、これはたとえば、設定されている LDAP サーバーに LDAP レルムが認証を委託するのと同じように見えます。native レルムで処理されるグループメンバーシップクエリも、コア認証サブシステムに委託されます。Java Web モジュールおよび開発者側から見ると、native レルムは Web モジュールで利用できるその他の Java レルムと変わりません。

native レルムは認証をコアに委託するため、追加設定が必要になります。詳細は、「native レルムの設定」を参照してください。

『Sun ONE Web Server 6.1 Programmer's Guide to Web Applications』には、J2EE セキュリティレルムと、セキュリティレルムの設定パラメータに関する詳細な情報が記載されています。

ロールベースの認証

Java Servlet 2.3 Specification には、アクセス制御規則を作成して、さまざまな J2EE アプリケーションリソースへのアクセスを制御する方法が定義されています。

ロールと制限対象領域のマッピング

J2EE アクセス制御は、ロールに基づいて行われます。特定の HTML ページ、サーブレット、JSP などへのアクセスを制限するには、次の項目を定義する必要があります。

ユーザーには複数のロールを割り当てることができます。検証時に、少なくとも 1 つのロールが割り当てられていれば、そのロールに対応する領域へのアクセスが許可されます。

webapps/security ディレクトリに保存されている、Sun ONE Web Server 6.1 での各種アクセス制限のサンプルをテンプレートとして使用できます。サーブレットロールベースのセキュリティの詳細は、Servlet 2.3 仕様を参照してください。

ロールによるアクセス制御の定義

J2EE アプリケーションロールは抽象的で、特定のアプリケーションに適用されます。実際の環境で、アクセスが認証ユーザーに限定されたアプリケーションを実行するには、sun-web.xml 記述子でユーザー名とロールをマッピングする必要があります。これは、次のいずれか、または両方の方法で行います。

主体マッピング - sun-web.xml 内で、1 つまたは複数のユーザー名をロールに直接マッピングします。この方法はテストには便利ですが、各ロールにマッピングできるユーザー数が限定されています。

グループマッピング - sun-web.xml 内で、1 つまたは複数のグループを指定して、1 つまたは複数のユーザー名を間接的にロールにマッピングします。(たとえば、engineers、managers、staff などのグループ名を指定します。) 指定したグループに所属する認証ユーザーに、アプリケーションロールが割り当てられます。指定したグループにどのユーザーが所属しているかは、有効なレルム実装 (または参照されるデータベース) によって決定されることに注意してください。

主体 (ユーザー) が、たとえば サーブレットや JSP などの特定の Web リソースを要求すると、Web コンテナがセキュリティ制約、または配備記述子ファイル内のリソースに関連付けられているアクセス権を確認し、その主体がリソースへのアクセスを承認されているかどうかを決定します。

ロールマッピングのエントリは、モジュール記述子内でロールとユーザーまたはグループをマッピングします。その例を次に示します。

<sun-web-app>

   <security-role-mapping>

   <role-name>manager</role-name>

   <principal-name>jsmith</principal-name>

   <group-name>divmanagers</group-name>

</sun-web-app>

配備記述子ファイルについては、『Sun ONE Web Server 6.1 Programmer's Guide to Web Applications』を参照してください。

レルムの設定方法

レルムの設定は、次のいずれかの方法で行います。

管理インタフェースの使用

管理インタフェースを使用してレルムを設定するには、次の手順を実行します。

  1. 管理サーバーインタフェースから対象サーバーインスタンスにアクセスし、「Java」タブをクリックします。
  2. 「Security Realms」リンクをクリックします。

    3. デフォルトでは、次のレルムが用意されています。

    - file

    - native

    - ldap

  3. レルムを追加するときは、「New」ボタンをクリックします。レルムを削除するときは、レルム名の隣のチェックボックスにチェックマークを付け、「OK」をクリックします。レルムを編集するときは、レルム名をクリックします。
  4. レルムを追加または編集するときは、レルム名、クラス名、プロパティ、ユーザー (file レルムのみ) を入力し、「OK」ボタンをクリックします。
  5. 「OK」をクリックします。

server.xml ファイルの編集

レルムは、実際には server.xml ファイルの SECURITY 要素に設定されます。SECURITY 要素は、次のように設定されます。

<SECURITY defaultrealm="file" anonymousrole="ANYONE"
      audit="false">
   <AUTHREALM name="file"
         classname="com.iplanet.ias.security.auth.realm.file.FileRe alm">
      <property name="file" value="instance_dir/config/keyfile"/>
      <property name="jaas-context" value="fileRealm"/>
   </AUTHREALM>
   ...
</SECURITY>

defaultrealm 属性は、サーバーがデフォルトで使用するレルムを指定します。デフォルトレルムは、それぞれの web.xml ファイルに有効なレルムが指定されていないすべての Web アプリケーションで使用されます。デフォルトレルムには、設定されているいずれかの AUTHREALM 名を指定する必要があります。デフォルトは file レルムです。

audit フラグは、監査情報をログに記録するかどうかを決定します。true に設定すると、サーバーは認証および承認イベントのすべての監査メッセージをログに記録します。

レルムの設定を変更した場合、その変更を適用するにはサーバーを再起動する必要があります。

server.xml ファイルについては、『Sun ONE Web Server 6.1 Administrator's Configuration File Reference』を参照してください。

native レルムの設定

すべてのレルムと同様に、native レルムも設定できます。設定には、server.xml ファイルの SECURITY 要素に含まれる AUTHREALM 要素を使用します。その例を次に示します。

<AUTHREALM name="native" classname="com.sun.enterprise.security.auth.realm.webcore.NativeRea lm">

   <PROPERTY name="auth-db" value="mykeyfile">

   <PROPERTY name="jaas-context" value="nativeRealm"/>

</AUTHREALM>

auth-db プロパティは、この native レルムがすべての認証要求の処理を委託するコア認証データベースを指定します。この例では、認証データベースの名前は「mykeyfile」です。このプロパティはオプション (オプション) です。指定しない場合、コア認証エンジンはデフォルトの auth-db を使用して、native レルムからのすべての要求を処理します。ほとんどのレルムでは、jaas-context プロパティは JAAS ログインコンテキスト (login.conf に定義されています) を指定します。

native レルムでは、その他の設定は必要ありません。ただし、要求がコア認証データベースに委託されるため、その認証データベースを適切に設定しておく必要があります。この節の残りのページでは、コア認証データベースの設定例を紹介します。

コア (native) 認証データベースを設定するには、auth-db 名とデータベース名をマッピングする USERDB 要素が、server.xml ファイルの VS 要素に含まれている必要があります。その例を次に示します。

<VS id="https-plaza.com"  ....

....

   <USERDB id="mykeyfile" database="myalt"/>

....

</VS>

auth-db プロパティを指定しない場合 (この場合は「default」が使用されます)、USERDB エントリの一部のデータベース名には 「id="default"」 がマッピングされます。マッピングが指定されていない場合は、default にマッピングされます。

次に、install-root/userdb/dbswitch.conf ファイルには、myalt データベースが設定されている必要があります。次の例は、ファイルベースの認証データベースとして myalt を定義しています。

directory myalt file

myalt:syntax keyfile

myalt:keyfile /local/ws61/https-plaza.com/config/keyfile

これは、native レルムに固有の設定ではありません。native レルムでは、処理の委託先認証データベースとして、任意の認証ディレクトリの有効な設定を使用できます。つまり、ネイティブ LDAP 認証データベースや、カスタムネイティブ認証データベースにさえも処理を委託するように native レルムを設定することができます。

注

Sun ONE Web Server 6.1 の Web アプリケーションには、認証エンジンとして LDAP を使用する次の 2 つの異なるメカニズムがあります。

  • Java LDAP レルムを使用する
  • ネイティブ LDAP 認証データベースに処理を委託するように設定された Java Native レルムを使用する

デフォルトレルムの指定

デフォルトレルムは、それぞれの web.xml 配備記述子ファイルに有効なレルムが指定されていない、すべての Web アプリケーションの認証イベントの処理に使用されます。有効な認証レルムをサーバーインスタンスに指定するには、次の手順を実行します。

  1. サーバーマネージャにアクセスし、「Java」タブを選択します。
  2. 「Java Security」リンクをクリックします。
  3. 次の情報を設定します。
    • Default Realm: このサーバーインスタンスの、有効な認証レルム (name 属性 AUTHREALM) を指定する
    • Anonymous Role (オプション): デフォルトの名前、つまり匿名ロールとして使用
    • Audit Enabled: (オプション)「true」の場合、アクセスの追加情報がログに記録され、監査情報が提供される。監査情報には、次の情報が含まれる
      • 認証の成功と失敗のイベント
      • サーブレットアクセスの認可と拒否
    • Log Level: (オプション) エラーログに記録されるメッセージの種類を制御
  4. 「OK」をクリックします。

プログラムによるセキュリティの使用

Sun ONE Web Server 6.1 は、レルムが提供するコンテナ管理による認証のほかに、プログラム化されたログインインタフェースによりアクセスを可能にする、管理型認証をサポートしています。このインタフェースは、レルムのインフラストラクチャには適さないカスタム認証モデルをサポートしています。プログラムによるログインは、それ自体の認証コンテキストを直接確立するために J2EE アプリケーションでも使用されます。ただし、アプリケーションの移植性は低下し、保守も困難になるため、このような手法はお勧めできません。

アプリケーションでプログラムによるログインメカニズムを呼び出すには、ProgrammaticLoginPermission アクセス権が必要です。これは J2EE の標準メカニズムではないため、このアクセス権は配備されるアプリケーションにデフォルトでは与えられません。

Sun ONE Web Server 6.1 は、Security Manager をサポートしています。製品インストール時のデフォルト設定では、Security Manager は無効に設定されています。サーバーインスタンスで Java Security Manager を有効にしたときは、プログラムによるログインを使用するすべての Web アプリケーションにこのアクセス権を与える必要があります。

必要なアクセス権をアプリケーションに与えるには、server.policy ファイルを編集する必要があります。

標準の Java ポリシーエントリを server.xml ファイルに指定することで、ポリシーのサポートを有効にすることができます。

<JVMOPTIONS>-Djava.security.manager</JVMOPTIONS>

<JVMOPTIONS>-Djava.security.policy=install-root/https-servername/config/se rver.policy</JVMOPTIONS>

server.policy ファイルについては、『Sun ONE Web Server 6.1 Programmer's Guide to Web Applications』を参照してください。

どのような場合に J2EE/サーブレット認証モデルを使用するか

この節では、どのような場合に J2EE/サーブレットベースの認証モデルを使用するかについて説明します。

J2EE/サーブレット認証モデルは、次のような場合に使用します。

ACL ベースのインフラストラクチャを使用する場合でも、Java レルムである native レルムを使用して、ユーザー ID をサーブレットで利用できるようにすることができます。



前へ      目次      索引      次へ     

Copyright 2004 Sun Microsystems, Inc. All rights reserved.