WebLogic Platform 8.1 のセキュリティ
|
 |
 |
|
WebLogic Platform 8.1 は、WebLogic Server で実行するポータル アプリケーション、統合アプリケーション、J2EE アプリケーションなどの、すべてのデプロイメントに対応する統一された単一のセキュリティ フレームワークです。すべての WebLogic Platform コンポーネントは、7.0 で導入された WebLogic Server LDAP ベースのセキュリティ モデルを使用するため、互換性セキュリティは必要ありません。また、追加するサードパーティのセキュリティ プロバイダは、WebLogic Platform のすべてのコンポーネントに同じように適用されます。
以下の節では、WebLogic Platform 8.1 セキュリティの概要を説明します。
WebLogic Platform セキュリティ モデルでは、以下の操作を実行できます。
WebLogic Platform 製品のすべてのコンポーネントのセキュリティは、WebLogic セキュリティ サービスに基づいています。このサービスの概要については、『WebLogic Security の紹介』を参照してください。このドキュメントを後続の章とともに参照してください。
この節では、プラットフォーム ベースのアプリケーションの保護に関する以下の基本概念を紹介します。
これらの節では、必要に応じて、適宜 end-to-end WebLogic Platform ツアー (このドキュメントでは単に「ツアー」と呼びます) から引用された例を示します。ツアーに含まれるセキュリティの基本設定は、プラットフォーム ベースのアプリケーションでリソースを保護する方法を示しています。以降の節では、これらのセキュリティ設定について詳しく説明し、このようなアプリケーションで WebLogic Platform セキュリティがどのように役立つかを示します。さらに、セキュリティ設定 (たとえばプロダクション環境の) を拡張して WebLogic Platform セキュリティのその他の機能を利用し、セキュリティが完備されたプラットフォーム アプリケーション環境を構築する方法についても説明します。
ツアーの詳細については、『WebLogic Platform ツアー ガイド』を参照してください。
WebLogic Platform の完全インストールでは、すべての WebLogic Platform コンポーネントとサンプル アプリケーション ファイルが、一連の WebLogic Server ドメイン内のシステムにインストールされます。ドメインは、WebLogic Server を管理するための基本単位です。ドメインは、1 つまたは複数の WebLogic Server インスタンスと、論理的に関連付けられたリソースおよびサービスで構成され、これらは 1 つの単位として集合的に管理されます。
インストール後には、通常、コンフィグレーション ウィザードを使用して新しいドメインを作成します。管理者は、ドメイン全体に適用されるセキュリティ設定や、特定の Platform コンポーネントに適用されるセキュリティ設定を定義できます。一般的に、ドメイン全体にわたるセキュリティ リソースは、1 つのドメイン内で実行されているアプリケーションによって共有されます。
プラットフォーム ドメインの例には、ツアーの end2end という名前ドメインがあります。このドメインのファイルは、次のディレクトリにあります。
BEAHOME/weblogic81/samples/domains/end2end
ツアー アプリケーション自体は、BEAHOME/weblogic81/samples/platform/end2end ディレクトリにあります。
ツアーのドメインを使用するには、ツアーを実行できるようにそのドメインで WebLogic Server、WebLogic Portal、WebLogic Integration、WebLogic Workshop コンポーネントをコンフィグレーションする必要があります。ツアーのドメインでは、以下のような操作を行います。
WebLogic Server ドメインの詳細については、『WebLogic Server のコンフィグレーションと管理』の「WebLogic Server ドメインの概要」を参照してください。
プラットフォーム ベース アプリケーションのセキュリティをコンフィグレーションする目的は、アプリケーションのリソースを保護することです。たとえば、ツアーには、保護の必要な 2 つのポータル (従業員用ポータルとマネージャ用ポータル) が含まれます。これらのリソースのセキュリティを維持するには、管理者は以下の項目を確実に実行する必要があります。
マネージャ ポータル用へのアクセス権をマネージャのみに限定すると、そのポータルからのみアクセスできるバックエンドのリソースは、デフォルトで保護されます。
以下の節では、バックエンド リソースの保護について説明します。
ユーザおよびグループは、アプリケーション リソースへのアクセスを制御するための分類です。ユーザは、認証可能な 1 つのエンティティです。ユーザには、人や、Java クライアントなどのソフトウェア エンティティを指定できます。各ユーザには、セキュリティ レルム内で固有の ID が与えられます。セキュリティ管理を効率化するために、ユーザをさらにグループに分類することをお勧めします。グループは、社内の同じ部署で働くなど、一般に何らかの共通点を持つユーザの集合です。
効率化を図るために、グループの使用をお勧めします。ユーザをグループに割り当てておけば、いつでも多数のユーザを管理することができます。たとえば、ツアーの場合、以下のユーザとグループが事前にコンフィグレーションされています。
注意 : portaladmin というユーザは、Administrators および PortalSystemAdministrators グループに属します。これらのグループは、すべての WebLogic Platform ドメインで事前にコンフィグレーションされています。
WebLogic Platform では、ユーザ情報の追加、修正、または削除を行う場合に複数の方法から選択することができます。
アプリケーション ドメインの作成時にユーザおよびグループを追加する場合は、アプリケーションを開始する前に、初期のユーザの集合を設定することができます。この機能は、既存のアプリケーションとユーザ情報を新しいドメインに伝播するときに便利です。詳細については、『コンフィグレーション ウィザードの使い方』の「セキュリティのコンフィグレーション」にある「ユーザとグループのコンフィグレーション」を参照してください。
アプリケーションの実行中にユーザとグループ、ロール、またはポリシーをコンフィグレーションし、いつでもその情報を修正または削除できます。
WebLogic Server Administration Console を使用して基本的なユーザ情報を追加し、WebLogic Server リソースのセキュリティをコンフィグレーションします。WebLogic Portal または WebLogic Integration の専用リソースにセキュリティをコンフィグレーションする (たとえば、トレーディング パートナを追加したり、ポータル リソースへのアクセスを指定する) 場合、それらのコンポーネント専用の管理コンソールが存在しているときは、そのコンソールを使用する必要があります。専用のコンソールで指定したセキュリティ情報は、デフォルトの WebLogic Server セキュリティ ストアに保存されます。
いずれかのコンソールを使用してユーザを追加すると、そのユーザは他のすべてのコンソールにも表示されます。同様に、ユーザを WebLogic Platform のいずれかの管理コンソールから削除すると、そのユーザは他のコンソールにも表示されなくなります。
このように、ユーザ情報は複数のコンポーネントからアクセスされますが、ユーザ プロファイルは例外です。ユーザ プロファイルは、特定のタイプのユーザに追加データを指定するものです。ユーザ プロファイルは、WebLogic Integration と WebLogic Portal で使用されます。詳細については、「ユーザ プロファイル情報の管理」を参照してください。
すべてのユーザとグループの情報は、デフォルトのセキュリティ ストアである LDAP セキュリティ ディレクトリに格納されます。このストアについては、「ユーザ情報の保存場所」を参照してください。
詳細については、『WebLogic リソースのセキュリティ』の「ユーザとグループ」を参照してください。ここでは、リソースのセキュリティを確保する方法、およびユーザとグループを作成、追加、修正、削除する方法が説明されています。
セキュリティ ロールは、特定の条件に基づいてユーザまたはグループに付与される特権です。たとえば、管理者は、AppAdmin という、特定のサーブレットへのアクセスが可能なセキュリティ ロールを定義する場合があります。この AppAdmin セキュリティ ロールを付与された任意のユーザまたはグループは、そのサーブレットにアクセスすることができます。1 つのセキュリティ ロールは、複数のユーザまたはグループに付与することができます。セキュリティ ロールを使用すると、グループと同様に、WebLogic Platform リソースへの複数のユーザのアクセスを同時に制限することができます。ただし、セキュリティ ロールは、以下の点でグループと異なります。
ユーザまたはグループにセキュリティ ロールを付与すると、そのユーザまたはグループにセキュリティ ロールが与えられている限り、事前定義されたアクセス特権がそのユーザまたはグループに付与されます。1 つのセキュリティ ロールは、複数のユーザまたはグループに付与することができます。1 つのロールで、ゼロ個以上のリソースへのアクセスを保護することもできます。
たとえば、ツアーのポータル アプリケーション e2ePortal には、以下のロールがコンフィグレーションされています。
ツアーでは、従業員だけが従業員ポータルにアクセスでき、マネージャだけがマネージャ ポータルにアクセスできるよう、これらのロールを使用してポータル アクセスを保護します。ツアーでこの操作を行うには、以下の手順に従います。
Controller.jpf ファイルは、ポータル アプリケーションにおいて各種 JSP ページフローを定義します。このポータル アプリケーションの詳細については、『WebLogic Platform ツアー ガイド』の「Avitek 社の企業イントラネットにログインする」にある「Avitek イントラネット ポータルを検討する」を参照してください。
セキュリティ ロールのコンフィグレーションの詳細については、以下のトピックを参照してください。
リソースへのアクセスは、常にセキュリティ ポリシーに基づいて実行されます。セキュリティ ポリシーは、WebLogic リソースと、ユーザ、グループ、セキュリティ ロールとの間に関連性を定義するときに作成します。
WebLogic Platform ツアーのセキュリティ ポリシーは、e2ePortal Web アプリケーションの従業員ポータルおよびマネージャ ポータルへのアクセスを制限するようにコンフィグレーションされています。これらのセキュリティ ポリシーは、web.xml デプロイメント記述子ファイルの宣言で指定されており、e2ePortal リソースを次のように保護します。
employee または manager ロールのユーザだけがログイン ポータルにアクセスできる。employee ロールのユーザだけが従業員ポータルにアクセスできる。manager ロールのユーザだけがマネージャ ポータルにアクセスできる。ツアーの場合、web.xml ファイルは e2ePortalProject フォルダの WEB-INF フォルダにあります。また、ツアーで使用する web.xml ファイルの詳細については、『WebLogic Platform ツアー ガイド』の「Avitek 社の企業イントラネットにログインする」にある「Web アプリケーションのセキュリティをコンフィグレーションする」を参照してください。
セキュリティ ポリシーは、特定のアプリケーション リソースへのアクセスを保護するために定義することができます。これらのセキュリティ ポリシーは、スコープ指定セキュリティ ポリシーと呼ばれます。デフォルトでは、全員にアクセスを許可するセキュリティ ポリシーがリソースにコンフィグレーションされています。スコープ指定セキュリティ ポリシーは、WebLogic Platform 付属の管理コンソールで定義します。たとえば、特定のポートレットへのアクセスを制限するときは、WebLogic Administration Portal を使用します。
セキュリティ ポリシーのコンフィグレーションの詳細については、以下のトピックを参照してください。
J2EE 仕様では、Web アプリケーション、EJB、Web サービスなどの J2EE アプリケーション コンポーネントに対応する、移植可能で標準的なデプロイメント記述子が定義されています。これらのエンティティのデプロイメント記述子では、セキュリティ情報を宣言によって定義できます。デプロイメント記述子は、アプリケーションの論理セキュリティ要件を、実行時の定義にマッピングするためのものです。実行時には、アプリケーション コンテナがセキュリティ定義を基に要件を適用します。この宣言型セキュリティの例は、ツアーの e2ePortal アプリケーションの web.xml ファイルにあります (詳細については、『WebLogic Platform ツアー ガイド』の「Avitek 社の企業イントラネットにログインする」にある「Web アプリケーションのセキュリティをコンフィグレーションする」を参照してください)。
WebLogic Workshop を使用すると、Web アプリケーション、Web サービス、コントロール、ビジネス プロセス、EJB のセキュリティ制約を、アノテーションを使用して宣言することもできます。WebLogic Workshop でアプリケーションを構築するときは、アプリケーションの対応する J2EE セキュリティ記述子で必要なセキュリティ情報が自動的に生成されます。
デプロイメント記述子でのセキュリティの指定の詳細については、以下のトピックを参照してください。
WebLogic Workshop は、WS-Security OASIS Web サービス セキュリティ標準の実装により、Web サービスに対するメッセージレベルのセキュリティ機能を備えています。WebLogic Workshop の WS-Security の実装によって、Web サービス間を転送される SOAP (Simple Object Access Protocol) メッセージを以下の機能で保護することができます。
WebLogic Workshop における Web サービス セキュリティのプログラミングでは、以下を処理するコードを作成します。
WebLogic Workshop でプログラミングされた宣言型セキュリティには、WebLogic Platform と同じ認証メカニズムおよび認可メカニズムが使用されます。Workshop のセキュリティ プログラミング メカニズムだけで、Workshop フレームワークで生成される実行時コードのデプロイメント記述子にポリシーを指定することができます。
Workshop IDE で Web サービスを実装する際の WS-Security の使用法の詳細、およびその例については、WebLogic Workshop ヘルプの「Web サービス セキュリティ (WS-Security)」を参照してください。
WS-Security は、WebLogic Server プログラミング環境で作成した Web サービスにも実装することができます。詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「セキュリティのコンフィグレーション」にある「Web サービス セキュリティの概要」を参照してください。
注意 : BEA が現在実装している Web サービス セキュリティ コア仕様は、2002 年 4 月 5 日現在の草案 (バージョン 1.0) です。この仕様はまだ OASIS 標準になっていないため、将来の WebLogic Server のバージョンでは現在の実装が変更になる可能性があります。『WebLogic Web サービス プログラマーズ ガイド』の「セキュリティのコンフィグレーション」の「Web サービス セキュリティの概要」で説明されているメッセージレベルのセキュリティ機能を使用している場合は、この実装が、他のバージョンのコア仕様に基づいた Web サービス セキュリティの実装と互換性を持たない場合があることを理解しておく必要があります。
WebLogic Platform には、アプリケーションのエンドツーエンド セキュリティを定義する方法がいくつかあります。それらは以下のとおりです。
ツアーでは、複数の WebLogic Platform コンポーネントを使用するアプリケーションでエンドツーエンド セキュリティを実現する WebLogic セキュリティ サービスの動作が示されています。このシナリオでは、john という従業員が Avitek 社の従業員ポータルにログインして、以下の操作を行います。
以下の手順では、john が発行した 2 つの要求の処理に関係するすべてのアプリケーション リソースを WebLogic セキュリティ サービスが保護する動作について詳しく説明します。
コンフィグレーション ウィザードを使用して新しいドメインを作成するときに、この認可済みユーザを事前にコンフィグレーションすることもできます。ツアーは「開発モード」で実行されるため、起動スクリプトは、管理者ユーザ名の weblogic でサーバを起動するように事前にコンフィグレーションされています。
e2ePortal は、FORM 認証を使用します。この認証スタイルは WebLogic Server サーブレット コンテナにより提供されているもので、WebLogic Server 認証プロバイダ (この場合は、WebLogic Server に組み込まれている LDAP ディレクトリ) に格納されているデータを基にユーザ名とパスワードが検証されます。FORM 認証の定義は、e2ePortal アプリケーションのデプロイメント記述子 web.xml の <login-config> セクションで指定します。認証が有効な場合は、現在のスレッドが認証済みユーザのサブジェクトの情報と関連付けられ、コントロールが e2ePortal ページフローの Controller.jpf ファイルの begin アクションにリダイレクトされます。このアクションによりサブジェクトからロールが抽出され、そのロールに応じて、フローが Employee.portal または Manager.portal ポータルのいずれかにリダイレクトされます。
john が認証されると、従業員ポータル (Workshop では e2ePortalProject の employee ディレクトリ内) のページフロー コントローラ、Controller.jpf がそのサブジェクトを使用して適切なユーザ名を抽出し、データベース コントロールを使用してデータベースに格納されている情報を取得します。この情報は、対応するポートレットに表示されます。 john が新しいラップトップ コンピュータの注文申請を入力すると、XML フォームが作成され、WorkflowInvoker Web サービス コントロールを経由して注文申請ビジネス プロセスに送信されます (このコントロールは、Workshop では e2ePortal ディレクトリの WorkflowInvoker フォルダにあります)。この WorkflowInvoker コントロールは、標準的な Web サービス ベースの呼び出しメカニズムを使用して、注文申請プロセスを開始します。現在、JMS は呼び出し元の資格を受信者に自動的に伝播せず、HTTP ベースの SOAP 要求では ID を自動的に伝播できないため、必要であれば、これらの資格を受信者へ転送するメカニズム (資格を XML メッセージに追加するなど) を設計する必要があります。 このように、アプリケーションのセキュリティの設計と計画は最初から行う必要があります。WebLogic Platform には、使用するコンポーネントに応じて使い分けられる、複数のセキュリティ コンフィグレーション ツールがあります。アプリケーションのセキュリティを設計する前に、これらのツールに慣れておくことをお勧めします。さまざまな WebLogic Platform コンポーネントに関する有効で詳細なドキュメントへのリンクについては、「詳細情報の入手」を参照してください。
|
|
|
