前へ     目次     索引     DocHome     次へ     
iPlanet Application Server 開発者ガイド



第 13 章   安全なアプリケーションの作成


この章では、ユーザの認証を実行し、Servlet と EJB ビジネスロジックへの認可にアクセスするコンポーネントを持つ、iPlanet Application Server の安全な J2EE アプリケーションを作成する方法について説明します。

この章には次の節があります。



iPlanet Application Server のセキュリティの目標

企業のコンピューティング環境には、多くのセキュリティ上のリスクがあります。iPlanet Application Server の目標は、J2EE セキュリティモデルをベースとして、高度に安全で相互利用可能な分散コンポーネントコンピューティング環境を実現することです。iPlanet Application Server のセキュリティの目標は次のとおりです。

  • J2EE v1.2 セキュリティモデル (J2EE 仕様書バージョン 1.2 の第 3 章「Security」を参照) への完全準拠

  • EJB v1.1 セキュリティモデル (Enterprise JaveBeans 仕様書バージョン 1.1 の第 15 章「Security Management」を参照) への完全準拠。EJB ロールベースの認可も含まれます

  • Java Servlet v2.2 セキュリティモデル (Java Servlet 仕様書バージョン 2.2 の第 11 章「Security」を参照) への完全準拠。Servlet ロールベースの認可も含まれます

  • iPlanet Application Server アプリケーション全体のシングルサインオンをサポート

  • RMI/IIOP クライアントのセキュリティをサポート

  • LDAP をセキュリティのバックエンドとして使い、実行時のユーザ管理を実現

  • iPlanet Application Server 固有の XML ベースの明確なロールマッピング情報を実装

  • iPlanet Application Server 配置ツールによって作成された、宣言によるセキュリティを持つ iPlanet Application Server 固有の XML ファイル

  • AppLogic セキュリティ API との互換性



iPlanet Application Server 固有のセキュリティ機能

iPlanet Application Server は、次の iPlanet Application Server 固有の機能だけでなく、J2EE v1.2 セキュリティモデルをサポートします。

  • iPlanet Application Server アプリケーション全体にわたるシングルサインオン

  • RMI/IIOP クライアントのセキュリティ

  • iPlanet Application Server 固有の XML ベースのロールマッピング情報

  • GUI ベースの配置ツールを、セキュリティ情報を保持する XML ファイルの作成に使用

  • 実行時のユーザ管理 LDAP

  • LDAP をセキュリティのバックエンドとして使用



iPlanet Application Server のセキュリティモデル

安全なアプリケーションでは、クライアントを有効なアプリケーションユーザとして認証する必要があり、EJB ビジネスロジックにアクセスする認可を持っています。iPlanet Application Server は Web クライアントと RMI/IIOP クライアントの両方のセキュリティをサポートします。

Web クライアントはブラウザと Web サーバを使い、HTTP を使って iPlanet Application Server 上で実行中の Servlet と通信します。これらのクライアントには、Web サーバの機能を拡張するために Servlet および JSP を使った通信が必要です。

安全な Web コンテナと安全な EJB コンテナを使ったアプリケーションは、Web クライアントの次のセキュリティプロセスを強化できます。

  • 呼び出し側を認証する

  • 呼び出し側に URL へのアクセスを認可する

  • 呼び出し側に EJB ビジネスメソッドへのアクセスを認可する

RMI/IIOP クライアントは RMI/IIOP を使ってブリッジを介した通信を行い、iPlanet Application Server 上で実行中の EJB に直接アクセスします。RMI/IIOP クライアントは Bean メソッドを直接起動します。

安全な EJB コンテナを使ったアプリケーションは、RMI/IIOP クライアントの次のセキュリティプロセスを強化できます。

  • 呼び出し側に EJB ビジネスメソッドへのアクセスを認可する

次の図に iPlanet Application Server セキュリティモデルを示します。




Web クライアントと URL の認可

安全な Web コンテナは認証および認可のプロパティを持つことができます。コンテナは基本、証明書、およびフォームベースの 3 つのタイプの認証をサポートします。Web クライアントがメインアプリケーションの URL を要求したときは、Web サーバが Web クライアントからのユーザ認証情報 (たとえば、ユーザ名とパスワード) の収集と iPlanet Application Server への転送を受け持ちます。

iPlanet Application Server は Web リソースに関連付けられたセキュリティポリシー (配置記述子 (DD) から取得される) を調べ、リソースアクセスの許可に使うセキュリティロールを調べます。Web コンテナは各ロールに対してユーザの証明書をテストし、ロールにユーザを割り当てることができるかどうかを判断します。ユーザ、グループ、およびロールについての情報を管理する企業規模のディレクトリサービスである LDAP サーバによって、ユーザの証明書が取得されます。


Web クライアントによる Enterprise Bean メソッドの呼び出し

Web クライアントが Web コンテナによって認証および認可され、JSP が EJB のリモートメソッド呼び出しを実行すると、認証プロセスで収集されたユーザの証明書を使って JSP と Bean の安全な関連付けが確立されます。安全な EJB コンテナには、Bean メソッドのアクセス制御の強化に使う認可プロパティを持つ DD が含まれています。EJB コンテナは LDAP サーバから受信したロール情報を使って、呼び出し側をロールに割り当てることができるかどうかと、Bean メソッドへのアクセスを許可するかどうかを判断します。


RMI/IIOP クライアントによる Enterprise JavaBeans メソッドの呼び出し

RMI/IIOP クライアントの場合、安全な EJB コンテナはセキュリティポリシーを調べて、呼び出し側が Bean メソッドへのアクセス権限を持っているかどうかを判断します。このプロセスは、RMI/IIOP クライアントおよび Web クライアントで同じです。



セキュリティの責任の概要


J2EE プラットフォームの主な目標はセキュリティメカニズムから開発者を解放し、さまざまな環境に安全かつ容易にアプリケーションを配置できるようにすることです。この目標を達成するには、アプリケーションセキュリティの仕様要件のメカニズムをアプリケーションの外側に明確に設定する必要があります。


アプリケーション開発者

アプリケーションの開発者は、次のプログラムセキュリティを指定します。

  • セキュリティレベルの指定

  • 保護されたオペレーションにアクセスされた場合、セキュリティパーミッションレベルの確認


アプリケーション編成者

アプリケーション編成者またはアプリケーションコンポーネントプロバイダは、コンポーネントに組み込まれた次のようなセキュリティ関連事項をすべて確認する必要があります。

  • コンポーネントが isCallerInRole または isUserInRole を呼び出すときに使うすべてのロール名

  • コンポーネントがアクセスするすべての外部リソースへの参照

  • コンポーネントが行うすべての内部コンポーネント呼び出しへの参照

  • 編成者が各コンポーネントの機能のパラメータのメソッド呼び出しをすべて指定すること、および機密性や整合性のために戻り値を保護することをお勧めします。配置記述子 (DD) はこの目的に使います。


アプリケーション配置者

iPlanet Application Server 配置ツールは、編成者が提供したビューを運用環境固有のポリシーとメカニズムに割り当てるために使います。アプリケーション配置者が設定したセキュリティメカニズムは、コンテナ内で管理されるコンポーネントのためにコンテナによって実装されます。

アプリケーション配置者は編成者が提供したすべてのコンポーネントのセキュリティビューを受け取り、それを使って次のようなアプリケーションにおける特定の企業環境を保護します。

  • ユーザグループをセキュリティレベルに割り当てる

  • コンポーネントメソッドへのアクセス権限、および呼び出し側が指定するセキュリティ属性とコンテナ権限の対応を定義する権限の改訂



セキュリティの一般的な用語

もっとも一般的なセキュリティプロセスは、認証、認可、およびロールマッピングです。次の節でそれらの用語を定義します。


認証

認証ではユーザを確認します。たとえば、ユーザが Web ブラウザ内でユーザ名とパスワードを入力し、その証明書が LDAP サーバ内に保存されているパーマネントプロファイルと一致したとき、ユーザは認証されます。ユーザは、それ以降のセッションで使われるセキュリティ ID に関連付けられます。


認可

認証された後、認可によってユーザは希望する操作を実行することができます。たとえば、人事管理アプリケーションでは、管理者には社員全員の個人情報を見ることを認可し、社員には自身の個人情報だけを見ることを認可します。


ロールマッピング

クライアントはセキュリティロールによって定義できます。たとえば、会社が社員のデータベースを使って、社内電話帳アプリケーションと支払給与情報の両方を生成します。電話番号と電子メールアドレスには、すべての社員がアクセスできますが、給与情報にアクセスできるのは一部の社員に限られます。給与を表示あるいは変更する権限を持つ社員は、特別なセキュリティロールを持つように定義できます。

ロールはアプリケーション内での職能を定義するのに対し、グループはある方法で関連付けられているユーザの集まりに過ぎません。この点で、ロールとユーザグループは異なります。たとえば、astronauts、scientists、および場合によっては politicians というグループのメンバーはすべて、SpaceShuttlePassenger のロールに該当します。

EJB セキュリティモデルは、アプリケーション開発者の記述どおりに、特定のドメインとは関係なくロール (ユーザグループとは区別された) を記述します。グループは配置ドメインに固有です。アプリケーション配置者のロールは 1 つまたは複数のグループにロールを割り当てることです。

iPlanet Application Server では、ロールは Directory Server に設定されているユーザグループに対応しています。LDAP グループにはユーザとほかのグループの両方を含めることができます。



コンテナセキュリティ


コンポーネントコンテナは、J2EE アプリケーションのセキュリティを確保する役目を果たします。コンテナによって確保されるセキュリティ形式には、次の 2 つがあります。

  • プログラムによるセキュリティ

  • 宣言によるセキュリティ


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

プログラムによるセキュリティは、EJB または Servlet が J2EE セキュリティモデルによって指定されたセキュリティ API へのメソッド呼び出しを使って、呼び出し側、またはリモートユーザのセキュリティロールに基づいてビジネスロジックの決定を行う場合です。プログラムによるセキュリティは、宣言によるセキュリティ単独ではアプリケーションのセキュリティモデルの要求を十分に満たすことができない場合に限って使う必要があります。

J2EE 仕様書バージョン 1.2 では、EJBの EJBContext インタフェースの 2 つのメソッドおよび Servlet の HttpServletRequest インタフェースの 2 つのメソッドで構成されるものとして、プログラムによるセキュリティを定義しています。iPlanet Application Server は、この仕様書で規定されているようにこれらのインタフェースをサポートします。プログラムによるセキュリティの詳細については、J2EE 仕様書バージョン 1.2 の第 3.3.6 節「Programmatic Security」および「プログラムによるログイン」を参照してください。


宣言によるセキュリティ

宣言によるセキュリティは、アプリケーションのセキュリティメカニズムが宣言され、アプリケーションの外部で処理されるときのものです。DD は セキュリティロール、アクセス制御、および認証の要件を持つ J2EE アプリケーションのセキュリティ構造を記述するために iPlanet Application Server によって使われます。

セキュリティを認識するアプリケーションの DD、すなわち web-app コンテナおよび EJB コンテナはセキュリティ要素として XML タグを持ち、アプリケーションのセキュリティの特性を表現します。セキュリティの特性には認証および認可があります。

iPlanet Application Server は、J2EE v1.2 が指定する DTD をサポートし、さらに別のセキュリティ要素が DD に含まれています。

宣言によるセキュリティはアプリケーション配置者に責任があります。XML DD は iPlanet Application Server 配置ツールによって生成されます。詳細については、iPlanet Application Server 配置ツールのオンラインヘルプおよび『管理者ガイド』を参照してください。


アプリケーションレベルのセキュリティ

アプリケーションの XML DD には、アプリケーションの Servlet と EJB にアクセスするときの、すべてのユーザロールの認可記述子が含まれています。アプリケーションレベルでは、アプリケーションのコンテナが使うすべてのロールがこのファイル内に一覧表示される必要があります。これらのロールは、アプリケーションの XML DD ファイル内の role-name 要素によって記述されます。ロール名は、EJB XML DD (ejb-jar ファイル) および Servlet の XML DD (web-war ファイル) の適用対象となります。


Servlet レベルのセキュリティ

安全な Web コンテナはユーザを認証し、Servlet へのアクセスを認可します。ユーザが認証され認可されると、Servlet はユーザの証明書を EJB に転送して Bean との安全な関連付けを確立します。


EJB レベルのセキュリティ

EJB コンテナは EJB XML DD 内に展開されているセキュリティポリシーを使って、Bean メソッドへのアクセスを認可する役割を果たします。



Servlet によるユーザ認証


J2EE 仕様書バージョン 1.2 で要求される 3 つの Web ベースのログインメカニズムは iPlanet Application Server でサポートされています。3 つのメカニズムは次のとおりです。

Web アプリケーション DD の login-config 要素は、使用される認証メソッド、HTTP 基本認証が使うアプリケーションの範囲名、およびフォームログインメカニズムの属性を記述します。

login-config 要素のシンタックスは次のとおりです。

<!ELEMENT login-config (auth-method?,realm-name?,from-login-config?)>

Web アプリケーションの DD の要素の詳細については、Java Servlet 仕様書バージョン 2.2 の第 13 章「Deployment Descriptor」を参照してください。


HTTP 基本認証

HTTP 基本認証 (RFC2068) は iPlanet Application Server にサポートされています。HTTP 基本認証プロトコルはアクセスが協定される HTTP 領域を示します。パスワードは base64 エンコード方式で送信されるので、この認証のタイプはそれほど安全ではありません。


SSL (Secure Socket Layer) 相互認証

Secure Socket Layer (SSL) 3.0、およびクライアントとサーバの相互の証明書ベースの認証を実行する方法は、J2EE 仕様書 v1.2 の要件です。このセキュリティメカニズムによって、HTTPS (SSL 上の HTTP) を使ってユーザ認証が提供されます。

iPlanet 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_RSA_EXPORT_WITH_DES40_CBC_SHA


フォームベースログイン

ログイン画面の見た目と使いやすさは、HTTP ブラウザの組み込みメカニズムでは制御できません。J2EE では、ログインするための標準 HTML または Servlet/JSP ベースフォームをパッケージングする機能を説明しています。ログインフォームは Web 保護ドメイン (HTTP 領域) に関連付けられ、まだ認証されていないユーザを認証するために使われます。

認証を適切に進めるために、ログインフォームのアクションは常に 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>


プログラムによるログイン

プログラムによるログインを使うと、ユーザはプログラムによって Web コンテナおよび EJB コンテナにログインできます。プログラムによるログインが有益な理由を次に示します。

  • ユーザ認証の柔軟性を提供する

  • ログアウトのための API を提供する

  • シンプルで拡張可能である

  • フォームベースなど、中間の Servlet を使うほかの認証タイプと比べて必要なメソッド呼び出しが少ない

  • Web および EJB コンテナ全体に一般的なインタフェースを提供する


フォームベースログインとプログラムによるログイン

フォームベース認証を使ってセキュリティ制約付きで Web リソースが配置されると想定します。これらのリソースにアクセスするには、Web コネクタは、ユーザがすでにログインしているかどうかを確認する FormAuthServlet を呼び出す必要があります。ユーザがログインしていない場合は、認証を有効にするためにログインページが表示されます。

プログラムによるログインでは、セキュリティ制約なしで Web リソースが配置されます。ユーザが Web リソースにアクセスした場合、FormAuthServlet は呼び出されません。その代わり、IProgrammaticLogin.login メソッドが呼び出され、明示的にそのユーザを認証します。このメソッドが失敗した場合は、AuthenticationException がスローされます。それ以外では、ユーザはログインしています。


IProgrammaticLogin インタフェース

com.iplanet.ias.security.IProgrammaticLogin インタフェースを使うと、Web または EJB コンテナ内のユーザがプログラムによってログインできます。このインタフェースには次のメソッドがあります。

  • login

  • logout

  • isLoggedIn

  • loggedUserName

このインタフェースは、2 つの Java クラスによって実装されます。

IProgrammaticLogin を実装する独自のクラスを作成できますが、お勧めしません。提供されたクラスを使うと、ログイン API ディレクトリを処理する必要がありません。


WebProgrammaticLogin クラス

com.iplanet.ias.security.WebProgrammaticLogin クラスによって、Web コンテナを使ったプログラムによるログインのデータメンバーが初期化されます。このクラスを現状のまま使ったり、サブクラスを作成したりできます。そのシグネチャは次のとおりです。

public class WebProgrammaticLogin extends java.lang.Object implements IProgrammaticLogin

その １ つのコンストラクタは次のとおりです。

public WebProgrammaticLogin(
   javax.servlet.ServletContext p_ServletContext、
   javax.servlet.http.HttpServletRequest p_HttpServletRequest、
   javax.servlet.http.HttpServletResponse p_HttpServletResponse)
throws NullValueException

必要な WebProgrammaticLogin 入力パラメータに NULL がある場合、com.iplanet.ias.security.NullValueException がスローされます。そのシグネチャは次のとおりです。

public class NullValueException extends java.lang.Exception

その １ つのコンストラクタは次のとおりです。

public NullValueException(java.lang.String Msg)

WebProgrammaticLogin メソッドは次の節で説明します。


login メソッド
login メソッドを使って、ユーザはプログラムによってログインできます。そのシグネチャは次のとおりです。

public void login(java.lang.String UserName, java.lang.String Password) throws ProgAuthenticationException, NullValueException

login メソッドは次のとおりです。

  • ユーザ名およびパスワードが有効であることを確認する

  • 別のユーザがログインしているかどうかを確認する

  • ServletContext、HttpRequest、またはHttpResponse が NULL かどうかを確認する

  • 認証を実行する

必要な login 入力パラメータに NULL がある場合、com.iplanet.ias.security.NullValueException がスローされます。

認証が失敗した場合は、com.iplanet.ias.security.ProgAuthenticationException がスローされます。そのシグネチャは次のとおりです。

public class ProgAuthenticationException extends com.netscape.server.servlet.servletrunner.AuthenticationException

その １ つのコンストラクタは次のとおりです。

public ProgAuthenticationException(java.lang.String Msg)


logout メソッド
logout メソッドを使って、ユーザはログアウトできます。そのシグネチャは次のとおりです。

public void logout(boolean flag)

実行される logout は flag の設定によって異なります。

  • flag が false の場合は、セッションから主要属性を削除する (ソフトログアウト)

  • flag が true の場合は、セッションを無効にする (ディープログアウト)


isLoggedIn メソッド
ユーザがすでにログインしている場合は、isLoggedIn メソッドが true を返します。そのシグネチャは次のとおりです。

public boolean isLoggedIn()


loggedUserName メソッド
loggedUserName メソッドでは、ログインしているユーザの主要名を返すか、またはどのユーザもログインしていない場合は、NULL を返します。そのシグネチャは次のとおりです。

public java.lang.String loggedUserName()


EjbProgrammaticLogin クラス

com.iplanet.ias.security.EjbProgrammaticLogin クラスによって、EJB コンテナを使ったプログラムによるログインのデータメンバーが初期化されます。このクラスを現状のまま使ったり、サブクラスを作成したりできます。そのシグネチャは次のとおりです。

public class EjbProgrammaticLogin extends java.lang.Object implements IProgrammaticLogin

その 1 つのコンストラクタは次のとおりです。

public EjbProgrammaticLogin() throws NullValueException

SecurityContext メンバー変数が NULL で、EjbProgrammaticLogin のインスタンスを作成しようとした場合は、com.iplanet.ias.security.NullValueException がスローされます。そのシグネチャは次のとおりです。

public class NullValueException extends java.lang.Exception

その 1 つのコンストラクタは次のとおりです。

public NullValueException(java.lang.String Msg)

EjbProgrammaticLogin メソッドは次の節で説明しています。


login メソッド
login メソッドを使って、ユーザはプログラムによってログインできます。そのシグネチャは次のとおりです。

public void login(java.lang.String userName, java.lang.String password) throws ProgAuthenticationException, NullValueException

login メソッドは次のとおりです。

  • ユーザ名およびパスワードが有効であることを確認する

  • 別のユーザがログインしているかどうかを確認する

  • SecurityContext が NULL かどうかを確認する

  • 認証を実行する

必要な login 入力パラメータに NULL がある場合、com.iplanet.ias.security.NullValueException がスローされます。

認証が失敗した場合は、com.iplanet.ias.security.ProgAuthenticationException がスローされます。そのシグネチャは次のとおりです。

public class ProgAuthenticationException extends com.netscape.server.servlet.servletrunner.AuthenticationException

その １ つのコンストラクタは次のとおりです。

public ProgAuthenticationException(java.lang.String Msg)


logout メソッド
logout メソッドを使って、ユーザはログアウトできます。そのシグネチャは次のとおりです。

public void logout(boolean flag)

EJB コンテナのこのメソッドは flag 値にかかわらず、SecurityContext からログインしているユーザの主要名を削除します。


isLoggedIn メソッド
ユーザがすでにログインしている場合は、isLoggedIn メソッドが true を返します。そのシグネチャは次のとおりです。

public boolean isLoggedIn()


loggedUserName メソッド
loggedUserName メソッドでは、ログインしているユーザの主要名を返すか、またはどのユーザもログインしていない場合は、NULL を返します。そのシグネチャは次のとおりです。

public java.lang.String loggedUserName()



Servlet によるユーザ認可


適切な認可レベルを持つユーザのアクセスだけを許可するように Servlet を設定できます。これには iPlanet Application Server 配置ツールを使い、アプリケーションの .ear ファイルおよび Servlet の .war ファイルの DD を生成します。


ロールの定義

アプリケーション全体のすべてのロール名がアプリケーションの XML DD 内で宣言されます。アプリケーションの XML DD 内の security-role および role-name 要素によって、アプリケーションで許可されるすべてのロール名が宣言されます。これらのセキュリティロールは J2EE Web アプリケーションの DD の適用対象となります。

アプリケーションの XML DD 内の security-role 要素は application 要素のサブ要素です。security-role 要素のシンタックスは次のとおりです。

<!--
security-role 要素は、アプリケーションに対してグローバルなセキュリティロールを 定義します。2 つのサブ要素があります。一つはセキュリティロールの記述で、もう一つ はセキュリティロールの名前です。

<!ELEMENT security-role (description?, role-name)>
role-name 要素にはロールの名前が入ります。
<!ELEMENT role-name (#PCDATA)>


セキュリティロールの参照

各 Servlet では、Web アプリケーションの DD はアクセスを認可されたすべてのロールを宣言します。web-app XML DD 内の security-rol-ref および role-link 要素は、認可されたロールをアプリケーションレベルのロール名にリンクします。

アプリケーション編成者は、security-role-ref 要素内で宣言されたセキュリティロールのすべての参照を、security-role 要素で定義されたセキュリティロールにリンクする必要があります。

アプリケーション編成者は、role-link 要素を使って各セキュリティロールの参照をセキュリティロールにリンクします。role-link 要素の値は security-role 要素で定義されたセキュリティロールの名前の一つである必要があります。

次の DD の例は、セキュリティロール参照をセキュリティロールにリンクする方法を示します。

<!ELEMENT security-role-ref (description?, role-name, role-link)>
<!ELEMENT role-link (#PCDATA)>


メソッドのパーミッションの定義

Servlet レベルでは、web-app XML DD の auth-constraint 要素を使ってメソッドのパーミッションを定義します。

リソースコレクション上の auth-constraint 要素を使って、リソースコレクションが許可されるユーザロールを指定する必要があります。ここで使うロールは security-role-ref 要素内に存在する必要があります。

<!ELEMENT auth-constraint (description?, role-name*)>


Web アプリケーション DD のサンプル

Web アプリケーションの DD のサンプルのセキュリティセクションは次のようになります。

<web-app>

   <display-name>A Secure Application</display-name>
   <security-role>
       <role-name>manager</role-name>
   </security-role>

   <Servlet>
       <servlet-name>catalog</servlet-name>
       <servlet-class>com.mycorp.CatalogServlet</servlet-class>

       <init-param>
          <param-name>catalog</param-name>
          <param-value>Spring</param-value>
       </init-param>

   <security-role-ref>
       <role-name>MGR</role-name><!-- コードで使われるロール名 -->
       <role-link>manager</role-link>
       </security-role-ref>
   </servlet>

   <servlet-mapping>
       <servlet-name>catalog</servlet-name>
       <url-pattern>/catalog/*</url-pattern>
   </servlet-mapping>

   <web-resource-collection>
       <web-resource-name>SalesInfo</web-resource-name>
       <urlpattern>/salesinfo/*</urlpattern>
       <http-method>GET</http-method>
       <http-method>POST</http-method>

       <user-data-constraint>
       <transport-guarantee>SECURE</transport-guarantee>
       </user-data-constraint>

       <auth-constraint>
          <role-name>manager</role-name>
       </auth-constraint>
   </web-resource-collection>
</web-app>



EJB によるユーザ認可


適切な認可レベルを持つユーザのアクセスだけを許可するように EJB を設定できます。これには iPlanet Application Server 配置ツールを使い、アプリケーションの .ear ファイルおよび EJB の .jar ファイルの DD を生成します。

EJB では、Servlet と同じようにプログラムによるログインを使います。詳細については、「プログラムによるログイン」を参照してください。


ロールの定義

アプリケーション配置者は、動作環境で定義したユーザグループおよびユーザアカウントを、アプリケーション編成者が定義したセキュリティロールに割り当てます。

アプリケーション編成者は DD 内に 1 つまたは複数のロールを定義します。アプリケーション編成者は、Enterprise JavaBeans のホームおよびリモートインタフェースのメソッドグループをセキュリティロールに割り当て、アプリケーションのセキュリティビューを定義します。

アプリケーション編成者は次の項目を定義する必要があります。

  • security-role 要素を使って各セキュリティロールを定義する

  • role-name 要素を使ってセキュリティロール名を定義する

  • description 要素を使ってセキュリティロールの説明を提供する (オプション)

security-role 要素によって定義したセキュリティロールは ejb-jar ファイルレベルの適用対象となり、ejb-jar ファイル内のすべての Enterprise JavaBeans に適用されます(J2EE 仕様書はグローバルロール、つまりコンテナに対して包括的なグローバルロールの定義方法を示していません)。

次に DD 内のセキュリティロール定義の例を示します。

...
<assembly-descriptor>
   <security-role>
       <description>
            このロールには、自分の目的に使うアプリケーションに
            アクセスできる社員が含まれています。
            このロールは、その社員の情報への
            アクセスだけが許可されています。
       </desciption>
       <role-name>employee</role-name>
       </security-role>
       <security-role>
          <description>
                このロールは、自分の目的に使う
                アプリケーションの管理業務を実行する権限を持つ
                担当者に割り当てる必要があります。このロールでは
                機密情報である人事および給与情報に
                直接アクセスすることはありません。
          </desciption>
       <role-name>admin</role-name>
       <security-role>
... <assembly-descriptor>


メソッドのパーミッションの定義

アプリケーション編成者は、次のように method permission 要素を使って、DD 内でメソッドのパーミッションの関係を定義します。

各 method-permission 要素には、1 つまたは複数のセキュリティロールのリストと 1 つまたは複数のメソッドのリストが含まれています。一覧表示されたセキュリティロールは一覧表示されたすべてのメソッドを起動できます。リスト内の各セキュリティロールは role-name 要素によって識別され、各メソッド (または下記の一連のメソッド) は method 要素によって識別されます。description 要素を使って オプションの説明を method-permission 要素に関連付けることができます。

メソッドパーミッションの関係は、個々の method permission 要素に定義したすべてのメソッドパーミッションの結合として定義されます。

セキュリティロールまたはメソッドは複数の method-permission 要素内に存在することがあります。

次の例は、DD 内でセキュリティロールがメソッドパーミッションに割り当てられる方法を示します。

...
<method-permission>
   <role-name>employee</role-name>
       <method>
       <ejb-name>EmployeeService</ejb-name>
       <method-name>*</method-name>
   </method>
</method-permission>

<method-permission>
   <role-name>employee</role-name>
   <method>
       <ejb-name>AardvarkPayroll</ejb-name>
       <method-name>findByPrimaryKey</method-name>
   </method>
   <method>
       <ejb-name>AardvarkPayroll</ejb-name>
       <method-name>getEmployeeInfo</method-name>
   </method>
   <method>
       <ejb-name>AardvarkPayroll</ejb-name>
       <method-name>updateEmployeeInfo</method-name>
   </method
</method-permission>
...

ここでの相互作用はありません。配置ツールはこれらをセキュリティ要素に変換します。


「セキュリティロール参照」

Bean の提供者は、DD の security-rol-ref 要素内に、Enterprise JavaBeans で使うすべてのセキュリティロール名を宣言する必要があります。

アプリケーション編成者は、security-role-ref 要素内で宣言されたセキュリティロールのすべての参照を、security-role 要素で定義されたセキュリティロールにリンクする必要があります。アプリケーション編成者は、role-link 要素を使って各セキュリティロールの参照をセキュリティロールにリンクします。role-link 要素の値は、security-role 要素で定義されたセキュリティロールの名前の一つである必要があります。

次の DD の例は、payroll という名前の Sudety のロール参照を payroll-department という名前のセキュリティロールにリンクする方法を示します。

...
<enterprise-beans>
   ...
   <entity>
       <ejb-name>AardvarkPayroll</ejb-name>
       <ejb-class>com.aardvark.payroll.PayrollBean</ejb-class>
   ...
       <security-role-ref>
       <description>

このロールは給与支払い部門の社員に割り当てる必要があります。このロールが割り当てられたメンバーは全員の給与記録にアクセスできます。ロールは payroll-department ロールにリンクされています。

             </description>
             </security-role-ref>
          ....
       </entity>
   ...
</enterprise-bean>



シングルサインオンでのユーザ認証


iPlanet Application Server 上でのアプリケーション全体のシングルサインオンは iPlanet Application Server の Servlet および JSP によってサポートされます。この機能によって、ユーザを個別のアプリケーションに対して別々にサインオンさせずに、同一のサインオン情報が必要な複数のアプリケーションでこの情報を共有できます。これらのアプリケーションは一回でユーザを認証できるように作成され、この認証情報は必要に応じてほかの関連するアプリケーションに伝えられます。

シングルサインオンのシナリオを使うアプリケーションの例としては、すべての航空会社を検索し、各航空会社の Web サイトへのリンクを提供する、統合航空券予約サービスがあります。ユーザが統合予約サービスにサインオンすると、そのユーザ情報を各航空会社のサイトで使用できるので、別のサインオンを要求する必要はありません。


シングルサインオンの設定方法

Web コンテナの iPlanet Application Server 固有の DD には session-info という名前の要素があり、コンテナ内の Servlet および JSP の認証を指定するフィールドがあります。DD は配置ツールによって作成されます。この節では、DD 内の session-info 要素のセキュリティフィールドが連動してシングルサインオン認証を実行する方法を中心に説明します。iPlanet Application Server 固有の Web コンテナの DD の作成方法の詳細については、iPlanet Application Server 配置ツールのオンラインヘルプおよび『管理者ガイド』を参照してください。すべての session-info フィールドの詳細な説明については、第 11 章「配置のためのパッケージ化」を参照してください。

表 13-1は、認証プロセスで使う session-info 要素フィールドを示しています。


表 13-1    シングルサインオンのためのセキュリティフィールド  

フィールド

説明

domain  

このフィールドはブラウザから cookie を送り返すドメインを指定します。デフォルト (ユーザがドメインを指定しない場合) では、cookie を設定する URL のドメインが cookie を送り返すドメインと見なされます。domain には cookie を送る任意のドメインを指定できます。domain には少なくとも 2 つのピリオドが必要で、3 つの場合もあります(.acme.com、.acme.co.inなど)。  

path  

このフィールドはセッションの cookie へのパスを指定します。これはブラウザから cookie を送り返すために URL に必要な最低限のパスです。たとえば、パスを /phoenix に設定すると、次の URL のどれかがアクセスされたときに cookie が送り返されます。

http://my.Who.com/phoenix/birds.html
または
http://my.Who.com/phoenix/bees.html

パスは "/" で始まる必要があります。パスが設定されていない場合、デフォルトのパスが cookie を設定している URL と見なされます。  

scope  

このフィールドは同じユーザセッションを共有するアプリケーションを「関連付ける」グループの名前を指定します。すなわち、1 つのアプリケーションにサインオンすると、ユーザはほかのアプリケーションにサインオンせずに自動的にアクセスできます。グループ化されたアプリケーションは、iPlanet Application Server 固有のそれぞれの Web XML DD ファイル内に、同じ scope フィールド値を持つ必要があります。  


シングルサインオンの例

AirlineSearch および AirlineBooking という名前の iPlanet Application Server 上で管理される 2 つのアプリケーションを考えます。両方とも myairlines.com ドメインの一部で、この 2 つのアプリケーション内のリソースへのアクセスの認証をユーザに要求します。AirlineSearch では、ユーザは利用可能なさまざまな航空会社を検索できます。また、AirlineBooking では、座席、メニュー、出発時刻などのユーザの特別な希望に基づいて予約できます。

AirlineSearch および AirlineBooking の ias-web.xml には次の記述が含まれています。

<session-info>
   <path>/iASApp</path>
   <scope>AirlineSignon</scope>
</session-info>

ここで、次の URL を使って、AirlineSearch アプリケーションが提供するサービスにまずアクセスします。

http://www.myairlines.com/iASApp/AirlineService/showFlights

showFlights は、ユーザが要求した時刻のすべてのフライトを表示する Servlet です。ここで、ユーザはログインする必要があります。ユーザはすべてのフライトを参照し、チケットの予約を決めたら、アクセスします。

http://www.myairlines.com/iASApp/AirlineService/bookFlights

このサイトでは、ユーザの希望に基づいてフライトを予約するサービスを提供します。このサービスは、前のアクセスおよび前の AirlineService アプリケーションに提供されたサインオン情報によって利用可能になります。

両方のアプリケーションは同一のドメイン内にあるので、この例では domain フィールドは設定されていません。ただし、複数ドメイン間でサインオン情報を共有するように拡張できます。



RMI/IIOP クライアントのユーザ認証


RMI/IIOP クライアントパスでのセキュリティは、iPlanet Application Server のセキュリティインフラストラクチャに統合されています。CXS は iPlanet Application Server のセキュリティマネージャを使って、LDAP に保存されているユーザ情報によってクライアントを認証します。クライアントの証明書はブリッジを介してクライアントから EJB に渡されます。クライアントサイドのコールバックによって、ユーザ名とパスワードでのクライアントのログインが開始されます。この情報を得るためにインスタンス化されるオブジェクトタイプは、クライアント上の環境設定によって指定されます。認証に失敗した場合、クライアント側はログインプロセスを再試行するようにセットアップされます。現在、再試行の数は 3 回にハードコードされています。

RMI/IIOP クライアントの DD 内の要素の詳細については、「RMI/IIOP クライアント XML DTD」を参照してください。



セキュリティ情報のガイド


次の種類の各情報を、短い説明、情報の保存場所、情報の作成方法、情報へのアクセス方法、および詳しい情報を参照できる場所とともに示します。

  • ユーザ情報

  • セキュリティロール


ユーザ情報

ユーザ名、パスワードなど


場所:
Directory Server


作成方法
Mission Console を使って作成するか、LDAP SDK を使ってプログラムで作成します。詳細については、iPlanet Application Server 配置ツールのオンラインヘルプおよび『管理者ガイド』を参照してください。


セキュリティロール

アプリケーションの機能を定義するロール。多数のユーザやグループから構成されています。LDAP グループは、iPlanet Application Server 内のロールとして機能します。


場所:
Directory Server


作成方法
iPlanet Application Server 配置ツールを使います。


アクセス方法
isCallerInRole() を使ってユーザのロールメンバーシップをテストします。



Web サーバからアプリケーションサーバのコンポーネントのセキュリティ


iPlanet Application Server 6.0 SP2 以降では、開発者はコンポーネントごとに Web サーバと KXS の間のトラフィックを選択して暗号化できます。暗号化は、128 ビットキー と RSA Bsafe3.0 ライブラリを使って行います。クレジットカード情報収集 Servlet、ログイン Servlet などの高度なセキュリティが必要なコンポーネント (Servlet や JSP) では、開発者が暗号化を有効にすることをお勧めします。

これらのコンポーネント間でトラフィックの暗号化を有効にするには、暗号化をサポートするアプリケーションサーバ自体を有効にする必要があります。必要な手順は次のとおりです。

  1. CCS0¥¥SECURITY¥¥EnableEncryption=D を設定します (内部 128 ビット、データタイプはstring)。

  2. KXS ログ内のログメッセージの暗号化を確認する場合、CCS0¥¥SECURITY¥¥LogEncryption=1 のエントリまたは値を作成します (データタイプはinteger)。

  3. CCS0¥¥EXTENSIONS¥¥CRYPTEXT¥¥CRYPTSVC¥¥ENGINES¥¥0 キーを作成します。

  4. Web サーバと iPlanet Application Server を再起動します。

暗号化を有効にする必要があるすべてのコンポーネントでは、次の手順を行います。

  1. j2eeappreg、webappreg、または iasdeploy (推奨) を使ってアプリケーションを登録します。

  2. 暗号化するコンポーネント (Servlet や JSP) の ias-web.xml ファイル内の <encrypt>true</encrypt> を設定します。

暗号化が有効で正しく動作することを確認するには、KXS ログを開き、次のようなメッセージを検索します。

[11/Jan/2001 19:58:43:0] info:CRYPT-003:Encrypting 2309 bytes, keysize = 128 bits

[11/Jan/2001 19:58:43:5] info:NSAPICLI-012:plugin reqstart, tickct: 1903570535

[11/Jan/2001 19:58:43:5] info:NSAPICLI-009:plugin reqexit:0s+.12995s. (198114 0537)

[11/Jan/2001 19:58:52:2] info:CRYPT-004:Decrypting 1897 bytes, keysize = 128 bits


前へ     目次     索引     DocHome     次へ     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

最新更新日 2002 年 3 月 6 日