WebLogic セキュリティプロバイダの開発

概要とロードマップ

以下の節では、このマニュアルの内容と構成について説明します。

マニュアルの内容

このマニュアルでは、セキュリティベンダやアプリケーション開発者向けに、BEA WebLogic Server で使用するセキュリティプロバイダの新規開発に必要な情報を提供します。

対象読者

このマニュアルは、WebLogic Server 用に独自のセキュリティプロバイダを記述する独立系ソフトウェアベンダ (ISV) 向けです。ここでは、このマニュアルをお読みになる ISV の大半はセキュリティの概念をしっかりと理解している高機能アプリケーションの開発者であり、セキュリティの基礎概念については説明を要しないものと想定しています。また、このマニュアルでは、セキュリティベンダおよびアプリケーション開発者は BEA WebLogic Server と Java (JMX (Java Management eXtensions) を含む) に精通しているものと想定しています。

このマニュアルの手引き

このマニュアルの構成は次のとおりです。

「WebLogic Server で使用するセキュリティプロバイダの開発について」では、WebLogic Server で使用するセキュリティプロバイダの開発について概説します。このマニュアルの前提条件を明記し、開発プロセスの概要を説明します。
「設計上の考慮事項」では、セキュリティプロバイダの一般的なアーキテクチャと、SSPI の実装および MBean タイプの生成に関する重要な基本情報について説明します。また、任意で利用できる管理ユーティリティの使い方や、セキュリティプロバイダの WebLogic リソースとの対話方法に関する情報もあります。この章の終わりでは、カスタムセキュリティプロバイダが必要な情報を保持するデータベースと連携して動作する方法がいくつか提示されます。
「認証プロバイダ」では、認証プロセス (簡単なログイン用) と、カスタム認証プロバイダに関連付けられるセキュリティサービスプロバイダインタフェース (security service provider interface : SSPI) の各タイプを実装する手順について説明します。また、JAAS LoginModule についての説明もあります。
「ID アサーションプロバイダ」では、認証プロセス (トークンを使用する境界認証用) と、カスタム ID アサーションプロバイダに関連付けられるセキュリティサービスプロバイダインタフェース (SSPI) の各タイプを実装する手順について説明します。
「プリンシパル検証プロバイダ」では、プリンシパル検証プロバイダでサブジェクトに格納されているプリンシパルの信頼性を署名して検証することにより、認証プロバイダの処理を簡略化する方法について説明します。また、カスタムプリンシパル検証プロバイダを開発する手順についても示します。
「認可プロバイダ」では、認可プロセスと、カスタム認可プロバイダに関連付けられるセキュリティサービスプロバイダインタフェース (SSPI) の各タイプを実装する手順について説明します。
「裁決プロバイダ」では、裁決プロセスと、カスタム裁決プロバイダに関連付けられるセキュリティサービスプロバイダインタフェース (SSPI) の各タイプを実装する手順について説明します。
「ロールマッピングプロバイダ」では、ロールマッピングプロセスと、カスタムロールマッピングプロバイダに関連付けられるセキュリティサービスプロバイダインタフェース (SSPI) の各タイプを実装する手順について説明します。
「監査プロバイダ」では、監査プロセスと、カスタム監査プロバイダに関連付けられるセキュリティサービスプロバイダインタフェース (SSPI) の各タイプを実装する手順について説明します。また、他のタイプのセキュリティプロバイダから監査を行う方法についての説明もあります。
「資格マッピングプロバイダ」では、資格マッピングプロセスと、カスタム資格マッピングプロバイダに関連付けられるセキュリティサービスプロバイダインタフェース (SSPI) の各タイプを実装する手順について説明します。
「カスタムセキュリティプロバイダからのイベントの監査」では、開発するカスタムセキュリティプロバイダに監査機能を追加する方法について説明します。
「サーブレット認証フィルタ」では、サーブレット認証フィルタプロセスと、サーブレット認証フィルタに関連付けられるセキュリティサービスプロバイダインタフェース (SSPI) の各タイプを実装する手順について説明します。
「バージョン管理可能なアプリケーションのプロバイダ」では、バージョン管理可能なアプリケーションの概念と、カスタムのバージョン管理可能なアプリケーションのプロバイダに関連付けられるセキュリティサービスプロバイダインタフェース (SSPI) の各タイプを実装する手順について説明します。
「証明書パスプロバイダ」では、証明書の検索と検証のプロセスと、カスタム証明書パスプロバイダに関連付けられるセキュリティサービスプロバイダインタフェース (SSPI) の各タイプを実装する手順について説明します。
「MBean 定義ファイル (MDF) 要素の構文」では、有効な MDF で使用できるすべての要素と属性について説明します。MDF とは MBean タイプの生成に使用する XML ファイルで、これを使用してカスタムセキュリティプロバイダを管理できます。

このリリースでの新機能と変更点

このリリースでは、WebLogic Security サービスに以下の機能が追加されています。

注意 : WebLogic Server バージョン 9.0 で提供された新しい機能については、『リリースノート』の「WebLogic Server 9.0 の新機能」を参照してください。

XACML 2.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 にアップグレードした場合、サードパーティ製プロバイダやオリジナルの WLS 専用プロバイダなどの、現行で指定されている認可プロバイダおよびロールマッピングプロバイダが引き続き使用されます。既存のドメインで使用するプロバイダを WLS 専用プロバイダから XACML プロバイダに移行することは可能です。この場合、既存のポリシーを大量に移動する作業が伴います。

WebLogic Server Administration Console を使用して認可プロバイダやロールマッピングプロバイダを新しく追加する場合、新しいプロバイダを DefaultAuthorizer プロバイダ、DefaultRoleMapper プロバイダ、または XACML プロバイダとして追加できます。

カスタム XACML プロバイダはこのリリースではサポートされていません。

XACML 2.0 仕様は、http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml で参照できます。

SAML の新機能

この節では、WebLogic Server 9.1 で新規に追加されたり変更されたりした SAML の機能について説明します。

プロバイダとサービスのコンフィグレーション

WebLogic Server 9.0 では、すべての SAML コンフィグレーションが SAML プロバイダ MBean のコンフィグレーション属性を使って行われていました。WebLogic Server 9.1 では、SAML プロバイダおよびサービスのコンフィグレーションが以下のように強化されています。

新しいバージョンの SAMLCredentialMapper プロバイダと SAMLIdentityAsserter プロバイダが追加された。SAML V1 プロバイダは非推奨になりました。SAMLCredentialMapper プロバイダおよび SAMLIdentityAsserter プロバイダの V2 バージョンを使用する必要があります。

プロバイダのバージョン番号は V2 と大きくなりましたが、どちらのプロバイダも SAML 1.1 のプロバイダです。
SAML パートナ (アサーティングパーティとリライイングパーティ) のコンフィグレーションが、プロバイダから組み込み LDAP サーバの SAML パートナレジストリに移動した。
SAML サービス (SSO プロトコル応答システム) のコンフィグレーションが、プロバイダから Server MBean の子である新しい Federation Services MBean に移動した。
新しいコンフィグレーションオプションが複数追加された。主として、SSO プロファイルで使用するキー、信頼性のある証明書、およびクエリパラメータに関するオプションが追加されています。

キー管理の強化

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 を使用してパートナのコンフィグレーション情報をルックアップします。

SAML アプリケーションの条件付きデプロイメント

WebLogic Server には、SAML サービスにアプリケーションコンテキストを提供するためにデフォルトでデプロイされる、アプリケーション WAR ファイルが複数用意されています。これらの WAR ファイルには表示可能なファイルや実行可能なコードは含まれません。SAML サービスに適したアプリケーションコンテキストおよびデプロイメント記述子を提供するためだけに存在しているものです。

WebLogic Server 9.0 では、これらのアプリケーションが常にすべてのサーバにデプロイされます。WebLogic Server 9.1 では、こうしたアプリケーションは実際に必要な場合にのみ、つまり 1 つまたは複数の SAML サービスがアプリケーションのデプロイされたサーバでそのアプリケーションコンテキストで実行されるようにコンフィグレーションされている場合にのみ、個別にデプロイされます。