WebLogic Security について
|
 |
 |
|
以下の各節では、WebLogic Security サービスとその特徴を紹介します。
セキュリティのデプロイメント、管理、および保守は、Web を使用する顧客に対して新しいさまざまなサービスを提供している IT (情報技術) 企業にとって大きな課題です。IT 企業は、Web ベースのユーザに世界規模のネットワークを提供できるよう、システムとそのデータの機密性、整合性、および可用性の保持という基本的な問題に取り組まなければなりません。セキュリティに対する取り組みは、ネットワーク自体から個々のクライアント マシンに至るまで、システムのすべてのコンポーネントに関係します。インフラストラクチャ全体のセキュリティの実現は、確立されたセキュリティ ポリシーと周知徹底された手順に加え、不断の警戒が要求される大変な作業です。
WebLogic Server には、Web を介して使用できるアプリケーション用にユニークでセキュアな基盤を提供するセキュリティ アーキテクチャが含まれています。企業は、WebLogic Server の新しいセキュリティ機能を利用することで、Web 上で使用できるアプリケーションの作成というセキュリティ課題に対処できるように設計された、包括的で柔軟性の高いセキュリティ インフラストラクチャのメリットを得ることができます。WebLogic セキュリティは、WebLogic Server アプリケーションを保護するためにスタンドアロンで使用することも、最高レベルのセキュリティ管理ソリューションを表す企業全体のセキュリティ管理システムの一部として使用することもできます。
WebLogic Server のセキュリティ アーキテクチャはオープンで柔軟性が高いため、すべてのレベルのユーザが利点を生かすことができ、アプリケーション サーバに対して高度なセキュリティ設計を導入できます。アプリケーション サーバのユニークなセキュリティ ソリューション、および明確なセキュリティ ポリシーと文書で確立された手順を有している企業であれば、サーバとそのデータの機密性、整合性、および可用性を確保できます。
WebLogic Security サービスの主な特長は、以下のとおりです。
WebLogic Security サービスのコンポーネントおよびサービスでは、エンド ユーザと管理者による使いやすさと管理しやすさ、およびアプリケーション開発者とセキュリティ開発者によるカスタマイズしやすさの両立が求められます。以下の節で、いくつか例を示します。
使いやすさ : セキュアな WebLogic Server 環境では、エンド ユーザに対して、ユーザ認証用のシングル サインオン (ユーザ ID の確認) のみを要求します。ユーザは、アプリケーションのリソースを含む WebLogic Server ドメイン内では再認証の必要はありません。シングル サインオンを利用すれば、ユーザはセッションごとに 1 回だけドメインにログオンすればよくなり、各リソースやアプリケーションにアクセスしようとするたびに個別にログオンを要求されることはなくなります。
開発者や管理者に対しては、新しくドメイン コンフィグレーション ウィザードが用意されています。ドメイン コンフィグレーション ウィザードは、管理サーバ、管理対象サーバ、および必要に応じてクラスタを含む新しいドメインの作成と、個々のサーバを追加することによる既存のドメインの拡張を支援します。ドメイン コンフィグレーション ウィザードは、config.xml ファイルと新しいドメインに追加するよう選択したサーバの起動スクリプトも自動的に生成します。
管理しやすさ : WebLogic Server 環境でアプリケーションをコンフィグレーションおよびデプロイする管理者は、製品に付属している WebLogic セキュリティ プロバイダを使用できます。これらのデフォルトのプロバイダは、そのままの状態で、必要なすべてのセキュリティ機能をサポートしています。管理者は、WebLogic Server に用意されているセキュリティ ストア (特殊用途の組み込み LDAP ディレクトリ サーバ) にセキュリティ データを保存したり、外部 LDAP サーバ、データベース、またはユーザ ソースを使用したりできます。WebLogic Server のセキュリティのコンフィグレーションと管理を簡素化するために、堅牢なデフォルトのセキュリティ コンフィグレーションが用意されています。
カスタマイズしやすさ : アプリケーション開発者に対しては、WebLogic セキュリティ API と、JAAS、JSS、JCE、JACC などの J2EE セキュリティ標準がサポートされています。これらの API と標準を使用して、WebLogic Server に接続するアプリケーションに対して、きめ細かい、カスタマイズされたセキュリティ環境を作成できます。
セキュリティ開発者は、セキュリティ サービス プロバイダ インタフェース (SSPI) を使用して、WebLogic Server 環境向けのカスタム セキュリティ プロバイダを開発できます。
この節では、WebLogic Server のこのリリースで追加された機能について説明します。
注意 : WebLogic Server バージョン 9.0 で提供された新しい機能については、『リリース ノート』の「WebLogic Server 9.0 の新機能」を参照してください。
WebLogic Server バージョン 9.1 には、OASIS の XACML (eXtensible Access Control Markup Language) 2.0 標準をサポートする認可プロバイダとロール マッピング プロバイダが実装されています。XACML 認可プロバイダと XACML ロール マッピング プロバイダの 2 つが WebLogic Server に含まれる新しいセキュリティ プロバイダです。
これらのプロバイダでは、標準 XACML 2.0 のあらゆる関数、属性、およびスキーマ要素で表されるポリシーのインポート、エクスポート、永続化、および実行が可能です。
9.1 を使用して新しく作成したドメインでは、デフォルトで XACML 認可プロバイダと XACML ロール マッピング プロバイダが使用されます。既存のドメインを 9.1 にアップグレードした場合、サード パーティ製パートナ プロバイダやオリジナルの WebLogic Server 専用プロバイダなどの、現行で指定されている認可プロバイダおよびロール マッピング プロバイダが引き続き使用されます。既存のドメインで使用するプロバイダを WebLogic Server 専用プロバイダから XACML プロバイダに移行することは可能です。この場合、既存のポリシーを大量に移動する作業が伴います。
WebLogic Server Administration Console を使用して認可プロバイダやロール マッピング プロバイダを新しく追加する場合、新しいプロバイダを DefaultAuthorizer プロバイダ、DefaultRoleMapper プロバイダ、または XACML プロバイダとして追加できます。
カスタム XACML プロバイダはこのリリースではサポートされていません。
XACML 2.0 仕様は、http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml で参照できます。
この節では、WebLogic Server 9.1 で新規に追加されたり変更されたりした SAML の機能について説明します。
WebLogic Server 9.0 では、すべての SAML コンフィグレーションが SAML プロバイダ MBean のコンフィグレーション属性を使って行われていました。WebLogic Server 9.1 では、SAML プロバイダおよびサービスのコンフィグレーションが以下のように強化されています。
WebLogic Server 9.0 の SAML ではサーバの SSL サーバの ID 資格 (プライベート キーと証明書チェーン) を使用して、アサーションおよび SAML プロトコル要素の署名と、SSL クライアント資格が必要な場合の外部 SAML サービスへの接続を行っていました。
WebLogic Server 9.1 でも SAML はサーバのキーストアに依存し、キーストアを使用するには SSL をコンフィグレーションする必要がありますが、個々のエリアスやパスフレーズをアサーション署名キー、プロトコル署名キー、および SSL クライアント ID という 3 つの別々の資格としてコンフィグレーションできるようになりました。それぞれの資格は、指定されていない場合、デフォルトでサーバの SSL ID になります。こうした変更は新しいバージョンのプロバイダにのみ実装されます。
さらに SAML キー管理コードも強化され、関連する MBean に対する変更をリスンして、キーストアやエリアスのコンフィグレーションの変更に動的に応答できるようになりました。
WebLogic Server 9.1 では信頼性の管理機能が向上しています。各パートナのコンフィグレーションで、アサーションの署名、SAML プロトコル要素の署名、SSL クライアントの認証といった特定の目的用に信頼された証明書のエリアスの指定が必要になりました。
WebLogic Server 9.0 の場合、証明書が信頼されるには SAML 証明書レジストリに登録されている必要がありました。登録が必須である一方で、信頼するための条件は十分ではありませんでした。登録された証明書であればどのような目的でも信頼される WebLogic Server 9.0 と違い、WebLogic Server 9.1 ではパートナ単位で近い将来の特定の目的用にコンフィグレーションされている特定の証明書のみが信頼されます。
WebLogic Server 9.1 では、署名の検証に使用できる証明書が記述された <ds:keyinfo> という要素を署名に含める必要がなくなりました。特定の署名用に信頼されている証明書がコンフィグレーションを通じて認識されるので、SAML ランタイムでは署名の検証に <ds:keyinfo> が必要ありません。
ブラウザ/アーティファクト プロファイルでは特定する「アーティファクト」をクエリ パラメータとして渡すことで SSO アサーションを ACS サービスに送信する方法を指定しますが、この実行中に、SAML アーティファクトを受信した送り先サイトがアーティファクトを発行したソース サイトと通信して対応するアサーションを取得します。
SAML 仕様では、アサーションを要求している送り先サイトがアーティファクトの元の送信先サイトであることを、ソース サイトで検証する必要があります。
WebLogic Server 9.0 のアサーション検索サービス (ARS) では双方向の SSL 使用時に送り先サイトの信頼を検証できますが、アサーションを要求している送り先サイトがアーティファクトの元の送信先サイトであるかどうかは検証できません。
WebLogic Server 9.1 では、ARS で送り先サイト用の複数の認証方法 (SSL クライアント証明書、ユーザ名/パスワード) がサポートされ、アサーションを要求しているサイトが対応するアーティファクトの送信されたサイトであるかどうかが検証されます。
こうした変更を実現するには、SAMLAssertionStoreV2 アサーション ストア プラグインがコンフィグレーションされている必要があります。デフォルトのアサーション ストア プラグインではこの機能がサポートされています。
WebLogic Server 9.1 の SAML パートナ コンフィグレーションには、SSO プロファイルの実行中に、リダイレクト時にクエリ パラメータとして追加するパラメータや POST 時にフォーム変数として含めるパラメータを指定する機能があります。さらにこの実装では SAML サービスの URL で受信されたすべてのクエリ パラメータ/フォーム変数が、SSO プロファイルの実行中にエンドツーエンドで伝播されます。
この機能の重要な使用法の 1 つに、パートナ ID をリクエスト パラメータとして含めるということがあります (多くの SAML 実装では、パートナ ID を受信 SSO プロファイル リクエストのクエリ パラメータとして指定する必要があります)。さらに WebLogic Server 9.1 ではパートナ ID が存在していることも必須で、パートナ ID を使用してパートナのコンフィグレーション情報をルックアップします。
WebLogic Server には、SAML サービスにアプリケーション コンテキストを提供するためにデフォルトでデプロイされる、アプリケーション WAR ファイルが複数用意されています。これらの WAR ファイルには表示可能なファイルや実行可能なコードは含まれません。SAML サービスに適したアプリケーション コンテキストおよびデプロイメント記述子を提供するためだけに存在しているものです。
WebLogic Server 9.0 では、これらのアプリケーションが常にすべてのサーバにデプロイされます。WebLogic Server 9.1 では、こうしたアプリケーションは実際に必要な場合にのみ、つまり 1 つまたは複数の SAML サービスがアプリケーションのデプロイされたサーバでそのアプリケーション コンテキストで実行されるようにコンフィグレーションされている場合にのみ、個別にデプロイされます。
|
|
|