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

12cリリース1(12.1.1)

B65927-02(原本部品番号:E24486-02)

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープ

- 対象読者

- このドキュメントの手引き

- 関連ドキュメント

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

2 WebLogic Serverで使用するセキュリティ・プロバイダの開発について

- 前提条件

- 開発プロセスの概要

- カスタム・セキュリティ・プロバイダの設計

- SSPIの実装によるカスタム・セキュリティ・プロバイダ用のランタイム・クラスの作成

- カスタム・セキュリティ・プロバイダを構成および管理するMBeanタイプの生成

- コンソール拡張機能の記述

- カスタム・セキュリティ・プロバイダの構成

- セキュリティ・ポリシー、セキュリティ・ロール、および資格証明マップを管理するメカニズムの提供

3 設計上の考慮事項

- セキュリティ・プロバイダの一般的なアーキテクチャ

- セキュリティ・サービス・プロバイダ・インタフェース(SSPI)

- 2つの重要な制限について

- 「Provider」SSPIの目的について

- バルク・アクセス・プロバイダの目的について

- 実装する「Provider」インタフェースの決定

- DeployableAuthorizationProviderV2 SSPI

- DeployableRoleProviderV2 SSPI

- DeployableCredentialProvider SSPI

- SSPI階層を理解し、ランタイム・クラスを1つ作成するか2つ作成するかを決定する

- SSPIクイック・リファレンス

- セキュリティ・サービス・プロバイダ・インタフェース(SSPI) MBean

- MBeanタイプが必要な理由について

- 拡張および実装するSSPI MBeanの決定

- MBean定義ファイル(MDF)の基本的な要素について

- カスタム・プロバイダとクラスパス

- MBean操作から例外のスロー

- MBean属性に対して非クリア・テキスト値の指定

- SSPI MBeanの階層と管理コンソールに対する影響について

- WebLogic MBeanMakerによって提供されるものについて

- MBean情報ファイルについて

- SSPI MBeanクイック・リファレンス

- セキュリティ・データの移行

- 移行の概念

- フォーマット

- 制約

- 移行ファイル

- カスタム・セキュリティ・プロバイダへの移行サポートの追加

- セキュリティ・データの移行に関する管理コンソールのサポート

- セキュリティ・プロバイダの開発者向け管理ユーティリティ

- セキュリティ・プロバイダとWebLogicリソース

- WebLogicリソースのアーキテクチャ

- WebLogicリソースのタイプ

- WebLogicリソース識別子

- toString()メソッド

- リソースIDとgetID()メソッド

- WebLogicリソースのデフォルト・グループの作成

- WebLogicリソースのデフォルト・セキュリティ・ロールの作成

- WebLogicリソースのデフォルト・セキュリティ・ポリシーの作成

- セキュリティ・プロバイダのランタイム・クラスでのWebLogicリソースのルックアップ

- 単一親リソース階層

- URLリソースのパターン・マッチング

- ContextHandlerとWebLogicリソース

- コンテキスト・ハンドラをサポートするプロバイダとインタフェース

- セキュリティ・プロバイダ・データベースの初期化

- ベスト・プラクティス:データベースがない場合のシンプルなデータベースの作成

- ベスト・プラクティス:既存のデータベースの構成

- ベスト・プラクティス:データベース初期化の委託

- ベスト・プラクティス: JDBC接続セキュリティ・サービスAPIを使用したデータベース接続の取得

- JDBC接続セキュリティ・サービスの実装: 主な手順

- 属性バリデータの相違点

- カスタム・バリデータの場合の属性バリデータの相違点

4 認証プロバイダ

- 認証の概念

- ユーザー/グループ、プリンシパル、サブジェクト

- 初期ユーザーおよびグループの指定

- LoginModules

- LoginModuleインタフェース

- LoginModuleとマルチパート認証

- Java Authentication and Authorization Service (JAAS)

- JAASがWebLogicセキュリティ・フレームワークとどう連携するか

- 例:スタンドアロンのT3アプリケーション

- 認証プロセス

- カスタム認証プロバイダを開発する必要があるか

- カスタム認証プロバイダの開発方法

- 適切なSSPIによるランタイム・クラスの作成

- AuthenticationProviderV2 SSPIの実装

- JAAS LoginModuleインタフェースの実装

- LoginModuleからカスタム例外のスロー

- 例:サンプル認証プロバイダのランタイム・クラスの作成

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- MBean定義ファイル(MDF)の作成

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

- WebLogic Server環境にMBeanタイプをインストールする

- 管理コンソールによるカスタム認証プロバイダの構成

- ユーザー・ロックアウトの管理

- 認証プロバイダの順序の指定

5 IDアサーション・プロバイダ

- IDアサーションの概念

- IDアサーション・プロバイダとLoginModule

- IDアサーションとトークン

- 新しいトークン・タイプの作成方法

- 新しいトークン・タイプをIDアサーション・プロバイダの構成で利用可能にする方法

- 境界認証用のトークンの渡し

- Common Secure Interoperability Version 2 (CSIv2)

- IDアサーション・プロセス

- カスタムIDアサーション・プロバイダを開発する必要があるか

- カスタムIDアサーション・プロバイダの開発方法

- 適切なSSPIによるランタイム・クラスの作成

- AuthenticationProviderV2 SSPIの実装

- IdentityAsserterV2 SSPIの実装

- 例:サンプルIDアサーション・プロバイダのランタイム・クラスの作成

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- MBean定義ファイル(MDF)の作成

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

- WebLogic Server環境にMBeanタイプをインストールする

- 管理コンソールによるカスタムIDアサーション・プロバイダの構成

- チャレンジIDアサーション

- JavaサーブレットAPI 2.3環境におけるチャレンジ/レスポンスの制限

- weblogic.security.services.Authenticationクラスのフィルタと役割

- チャレンジIDアサーション・プロバイダの開発方法

- ChallengeIdentityAsserterV2インタフェースの実装

- ProviderChallengeContextインタフェースの実装

- weblogic.security.servicesのチャレンジIDメソッドの呼出し

- weblogic.security.servicesのAppChallengeContextメソッドの呼出し

- フィルタからチャレンジIDアサーションを実装する

6 プリンシパル検証プロバイダ

- プリンシパル検証の概念

- プリンシパル検証とプリンシパル・タイプ

- プリンシパル検証プロバイダと他のタイプのセキュリティ・プロバイダの違い

- 無効なプリンシパルが原因のセキュリティ例外

- プリンシパル検証プロセス

- カスタム・プリンシパル検証プロバイダを開発する必要があるか

- WebLogicプリンシパル検証プロバイダの使い方

- カスタム・プリンシパル検証プロバイダの開発方法

- PrincipalValidator SSPIの実装

7 認可プロバイダ

- 認可の概念

- アクセス決定

- Java Authorization Contract for Containersの使用

- 認可プロセス

- カスタム認可プロバイダを開発する必要があるか

- カスタム認可プロバイダでアプリケーションのバージョン管理をサポートする必要があるか

- カスタム認可プロバイダはスレッド・セーフか

- カスタム認可プロバイダの開発方法

- 適切なSSPIによるランタイム・クラスの作成

- AuthorizationProvider SSPIの実装

- DeployableAuthorizationProviderV2 SSPIの実装

- AccessDecision SSPIの実装

- 例:サンプル認可プロバイダのランタイム・クラスの作成

- ポリシー・コンシューマSSPI

- 必要なSSPIインタフェース

- PolicyConsumerFactory SSPIインタフェースの実装

- PolicyConsumer SSPIインタフェースの実装

- PolicyCollectionHandler SSPIインタフェースの実装

- 更新後のポリシー・コレクションのサポート

- PolicyConsumerMBean

- PolicyStoreMBean

- XACML Policyファイルの形式の調べ

- WLSTを使用してPolicyStoreMBeanにポリシーの追加

- WLSTを使用してPolicySetをStringとして読み込む

- バルク認可プロバイダ

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- MBean定義ファイル(MDF)の作成

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

- WebLogic Server環境にMBeanタイプをインストールする

- 管理コンソールによるカスタム認可プロバイダの構成

- 認可プロバイダとデプロイメント記述子の管理

- セキュリティ・ポリシー・デプロイメントの有効化

- セキュリティ・ポリシーを管理するためのメカニズムの提供

- オプション1: セキュリティ・ポリシー管理用のスタンドアロン・ツールの開発

- オプション2 :既存のセキュリティ・ポリシー管理ツールを管理コンソールに統合する

8 裁決プロバイダ

- 裁決プロセス

- カスタム裁決プロバイダを開発する必要があるか

- カスタム裁決プロバイダの開発方法

- 適切なSSPIによるランタイム・クラスの作成

- AdjudicationProviderV2 SSPIの実装

- AdjudicatorV2 SSPIの実装

- バルク認可プロバイダ

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- MBean定義ファイル(MDF)の作成

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

- WebLogic Server環境にMBeanタイプをインストールする

- 管理コンソールによるカスタム裁決プロバイダの構成

9 ロール・マッピング・プロバイダ

- ロール・マッピングの概念

- セキュリティ・ロール

- 動的セキュリティ・ロール計算

- ロール・マッピング・プロセス

- カスタム・ロール・マッピング・プロバイダはスレッド・セーフか

- カスタム・ロール・マッピング・プロバイダを開発する必要があるか

- カスタム・ロール・マッピング・プロバイダでアプリケーションのバージョン管理をサポートする必要があるか

- カスタム・ロール・マッピング・プロバイダの開発方法

- 適切なSSPIによるランタイム・クラスの作成

- RoleProvider SSPIの実装

- DeployableRoleProviderV2 SSPIの実装

- RoleMapper SSPIの実装

- SecurityRoleインタフェースの実装

- 例:サンプル・ロール・マッピング・プロバイダのランタイム・クラスの作成

- ロール・コンシューマSSPI

- 必要なSSPIインタフェース

- RoleConsumerFactory SSPIインタフェースの実装

- RoleConsumer SSPIインタフェースの実装

- RoleCollectionHandler SSPIインタフェースの実装

- 更新後のロール・コレクションのサポート

- RoleConsumerMBean

- PolicyStoreMBean

- XACML Policyファイルの形式の調べ

- WLSTを使用してPolicyStoreMBeanにポリシーの追加

- WLSTを使用してPolicySetをStringとして読み込む

- バルク・ロール・マッピング・プロバイダ

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- MBean定義ファイル(MDF)の作成

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

- WebLogic Server環境にMBeanタイプをインストールする

- 管理コンソールによるカスタム・ロール・マッピング・プロバイダの構成

- ロール・マッピング・プロバイダとデプロイメント記述子の管理

- セキュリティ・ロール・デプロイメントの有効化

- セキュリティ・ロールを管理するためのメカニズムの提供

- オプション1: セキュリティ・ロール管理用のスタンドアロン・ツールの開発

- オプション2 : 既存のセキュリティ・ロール管理ツールを管理コンソールに統合する

10 監査プロバイダ

- 監査の概念

- 監査チャネル

- カスタム・セキュリティ・プロバイダからのイベントの監査

- 監査プロセス

- ContextHandler MBeanの実装

- ContextHandlerMBeanのメソッド

- 例: ContextHandlerMBeanの実装

- weblogic.management.security.audit.ContextHandlerImplの拡張

- カスタム監査プロバイダを開発する必要があるか

- カスタム監査プロバイダの開発方法

- 適切なSSPIによるランタイム・クラスの作成

- AuditProvider SSPIの実装

- AuditChannel SSPIの実装

- 例:サンプル監査プロバイダのランタイム・クラスの作成

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- MBean定義ファイル(MDF)の作成

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

- WebLogic Server環境にMBeanタイプをインストールする

- 管理コンソールによるカスタム監査プロバイダの構成

- 監査重大度の構成

- セキュリティ・フレームワークの監査イベント

- 付加的な監査情報の渡し

- 監査イベント・インタフェースと監査イベント

- AuditApplicationVersionEvent

- AuditAtnEventV2

- AuditAtzEvent

- AuditCerPathBuilderEvent、AuditCertPathValidatorEvent

- AuditConfigurationEvent

- AuditCredentialMappingEvent

- AuditLifecycleEvent

- AuditMgmtEvent

- AuditPolicyEvent

- AuditRoleDeploymentEvent

- AuditRoleEvent

11 資格証明マッピング・プロバイダ

- 資格証明マッピングの概念

- 資格証明マッピング・プロセス

- カスタム資格証明マッピング・プロバイダを開発する必要があるか

- カスタム資格証明マッピング・プロバイダでアプリケーションのバージョン管理をサポートする必要があるか

- カスタム資格証明マッピング・プロバイダの開発方法

- 適切なSSPIによるランタイム・クラスの作成

- CredentialProviderV2 SSPIの実装

- DeployableCredentialProvider SSPIの実装

- CredentialMapperV2 SSPIの実装

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- MBean定義ファイル(MDF)の作成

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

- WebLogic Server環境にMBeanタイプをインストールする

- 資格証明マップを管理するためのメカニズムの提供

- オプション1: 資格証明マップ管理用のスタンドアロン・ツールの開発

- オプション2 :既存のセキュリティ・ポリシー管理ツールを管理コンソールに統合する

12 カスタム・セキュリティ・プロバイダからのイベントの監査

- セキュリティ・サービスと監査サービス

- カスタム・セキュリティ・プロバイダからの監査方法

- 監査イベントの作成

- AuditEvent SSPIの実装

- 監査イベント・コンビニエンス・インタフェースの実装

- 監査重大度

- 監査コンテキスト

- 例: AuditRoleEventインタフェースの実装

- 監査サービスの取得、および取得した監査サービスによる監査イベントの書込み

- 例:監査サービスを取得および使用してロール監査イベントの書込み

- プロバイダのMBeanから管理操作の監査

- 例:プロバイダのMBeanから管理操作の監査

- ベスト・プラクティス:プロバイダのMBeanからの監査イベントのポスト

13 サーブレット認証フィルタ

- 認証フィルタの概念

- フィルタが必要な理由

- サーブレット認証フィルタ設計上の考慮事項

- フィルタが呼び出されるしくみ

- 認証プロバイダからサーブレット認証フィルタを呼び出さない

- フィルタを実装するプロバイダの例

- カスタム・サーブレット認証フィルタの開発方法

- 適切なSSPIによるランタイム・クラスの作成

- サーブレット認証フィルタSSPIの実装

- フィルタ・インタフェース・メソッドの実装

- フィルタからチャレンジIDアサーションを実装する

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

- 管理コンソールによる認証プロバイダの構成

14 バージョン管理可能なアプリケーションのプロバイダ

- バージョン管理可能なアプリケーションの概念

- バージョン管理可能なアプリケーションのプロセス

- バージョン管理可能なアプリケーションのカスタム・プロバイダを開発する必要があるか

- カスタムVersionableApplicationプロバイダの開発方法

- 適切なSSPIによるランタイム・クラスの作成

- VersionableApplication SSPIの実装

- 例:サンプルVersionableApplicationプロバイダのランタイム・クラスの作成

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

- 管理コンソールによるバージョン管理可能なアプリケーションのカスタム・プロバイダの構成

15 証明書パス・プロバイダ

- 証明書の検索と検証の概念

- 証明書の検索と検証のプロセス

- 証明書パス検証プロバイダと証明書パス・ビルダーを実装する必要があるか

- 証明書パス・プロバイダSPI MBean

- WebLogic証明書パス検証プロバイダSSPI

- WebLogic証明書パス・ビルダーSSPI

- WebLogic Server証明書パスSSPIとJDK SPIとの関係

- カスタム証明書パス・プロバイダを開発する必要があるか

- カスタム証明書パス・プロバイダの開発方法

- 適切なSSPIによるランタイム・クラスの作成

- JDK CertPathBuilderSpiインタフェース、CertPathValidatorSpiインタフェースのいずれか、または両方の実装

- 証明書パス・プロバイダSSPIの実装

- JDKセキュリティ・プロバイダSPIの実装

- CertPathBuilderSpi実装でCertPathBuilderParametersSpi SSPIの使用

- CertPathValidatorSpi実装でCertPathValidatorParametersSpi SSPIの使用

- ビルダーまたは検証プロバイダの結果の返し

- 例:サンプル証明書パス・プロバイダの作成

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- MBean定義ファイル(MDF)の作成

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

- WebLogic Server環境にMBeanタイプをインストールする

- 管理コンソールによるカスタム証明書パス・プロバイダの構成

A MBean定義ファイル(MDF)要素の構文

- MBeanType (ルート)要素

- MBeanAttributeサブ要素

- MBeanConstructorサブ要素

- MBeanOperationサブ要素

- MBean操作の例外

- 例:有効な整形式MBean定義ファイル(MDF)

Oracle® Fusion Middleware

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

12cリリース1(12.1.1)

B65927-02(原本部品番号:E24486-02)

2012年1月

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

Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発, 12cリリース1(12.1.1)

B65927-02

Copyright © 2007, 2012, Oracle and/or its affiliates.All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

はじめに

ここでは、このガイド『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のドキュメントのアクセシビリティ機能と使用されている表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

以下の節では、このドキュメントの内容と構成について説明します。

- ドキュメントのスコープ

- 対象読者

- このドキュメントの手引き

- 関連ドキュメント

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

ドキュメントのスコープ

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

対象読者

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

このドキュメントの手引き

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

このドキュメントの構成は次のとおりです。

- 第2章「WebLogic Serverで使用するセキュリティ・プロバイダの開発について」 WebLogic Serverで使用するセキュリティ・プロバイダの開発について概説します。このガイドの前提条件を明記し、開発プロセスの概要を説明します。

- 第3章「設計上の考慮事項」では、セキュリティ・プロバイダの一般的なアーキテクチャと、SSPIの実装およびMBeanタイプの生成に関する重要な基本情報について説明します。また、任意で利用できる管理ユーティリティの使い方や、セキュリティ・プロバイダのWebLogicリソースとの対話方法に関する情報もあります。この章の終わりでは、カスタム・セキュリティ・プロバイダが必要な情報を保持するデータベースと連携して動作する方法がいくつか提示されます。

- 第4章「認証プロバイダ」では、認証プロセス(簡単なログイン用)と、カスタム認証プロバイダに関連付けられるセキュリティ・サービス・プロバイダ・インタフェース(security service provider interface : SSPI)の各タイプを実装する手順について説明します。また、JAAS LoginModuleについての説明もあります。

- 第5章「IDアサーション・プロバイダ」では、認証プロセス(トークンを使用する境界認証用)と、カスタムIDアサーション・プロバイダに関連付けられるセキュリティ・サービス・プロバイダ・インタフェース(SSPI)の各タイプを実装する手順について説明します。

- 第6章「プリンシパル検証プロバイダ」では、プリンシパル検証プロバイダでサブジェクトに格納されているプリンシパルの信頼性を署名して検証することにより、認証プロバイダの処理を簡略化する方法について説明します。また、カスタム・プリンシパル検証プロバイダを開発する手順についても示します。

- 第7章「認可プロバイダ」では、認可プロセスと、カスタム認可プロバイダに関連付けられるセキュリティ・サービス・プロバイダ・インタフェース(SSPI)の各タイプを実装する手順について説明します。

- 第8章「裁決プロバイダ」では、裁決プロセスと、カスタム裁決プロバイダに関連付けられるセキュリティ・サービス・プロバイダ・インタフェース(SSPI)の各タイプを実装する手順について説明します。

- 第9章「ロール・マッピング・プロバイダ」では、ロール・マッピング・プロセスと、カスタム・ロール・マッピング・プロバイダに関連付けられるセキュリティ・サービス・プロバイダ・インタフェース(SSPI)の各タイプを実装する手順について説明します。

- 第10章「監査プロバイダ」では、監査プロセスと、カスタム監査プロバイダに関連付けられるセキュリティ・サービス・プロバイダ・インタフェース(SSPI)の各タイプを実装する手順について説明します。また、他のタイプのセキュリティ・プロバイダから監査を行う方法についての説明もあります。

- 第11章「資格証明マッピング・プロバイダ」では、資格証明マッピング・プロセスと、カスタム資格証明マッピング・プロバイダに関連付けられるセキュリティ・サービス・プロバイダ・インタフェース(SSPI)の各タイプを実装する手順について説明します。

- 第12章「カスタム・セキュリティ・プロバイダからのイベントの監査」では、開発するカスタム・セキュリティ・プロバイダに監査機能を追加する方法について説明します。

- 第13章「サーブレット認証フィルタ」では、サーブレット認証フィルタ・プロセスと、サーブレット認証フィルタに関連付けられるセキュリティ・サービス・プロバイダ・インタフェース(SSPI)の各タイプを実装する手順について説明します。

- 第14章「バージョン管理可能なアプリケーションのプロバイダ」では、バージョン管理可能なアプリケーションの概念と、カスタムのバージョン管理可能なアプリケーションのプロバイダに関連付けられるセキュリティ・サービス・プロバイダ・インタフェース(SSPI)の各タイプを実装する手順について説明します。

- 第15章「証明書パス・プロバイダ」では、証明書の検索と検証のプロセスと、カスタム証明書パス・プロバイダに関連付けられるセキュリティ・サービス・プロバイダ・インタフェース(SSPI)の各タイプを実装する手順について説明します。

- 付録A「MBean定義ファイル(MDF)要素の構文」では、有効なMDFで使用できるすべての要素と属性について説明します。MDFとはMBeanタイプの生成に使用するXMLファイルで、これを使用してカスタム・セキュリティ・プロバイダを管理できます。

関連ドキュメント

OracleのWebサイトでは、WebLogic Serverの全ドキュメントが公開されています。セキュリティ・プロバイダに関わるセキュリティ・ベンダーおよびアプリケーション開発者にとって重要と思われるWebLogic Serverドキュメントを以下に示します。

- 『Oracle WebLogic Serverのセキュリティの理解』

- 『Oracle WebLogic Serverの保護』

- 『Oracle WebLogic Serverセキュリティのプログラミング』

- 『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』

- 『Oracle WebLogic Server本番環境の保護』

以下の情報も利用できます。

- WebLogicクラスのJavaDoc

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

WebLogic Serverのこのリリースに追加された新機能の一覧については、『Oracle WebLogic Serverの新機能』を参照してください。

2 WebLogic Serverで使用するセキュリティ・プロバイダの開発について

以下の節では、セキュリティ・プロバイダの開発についての概要を示します。

- 前提条件

- 開発プロセスの概要

前提条件

このガイドを読む前に、『Oracle WebLogic Serverのセキュリティの理解』の次の項に目を通しておいてください。

- 「セキュリティ・プロバイダ」

- 「WebLogicセキュリティ・フレームワーク」

WebLogic Serverのセキュリティには、この他に理解しておく必要のある固有の用語や概念が多数あります。WebLogic Serverのセキュリティ関連ドキュメントに登場するこうした用語と概念については、『Oracle WebLogic Serverのセキュリティの理解』のセキュリティの基礎概念に関する項で定義されています。

開発プロセスの概要

この節では、新しいセキュリティ・プロバイダを開発するプロセスの概要を説明します。各手順の詳細は、このガイドの中で後述します。

カスタム・セキュリティ・プロバイダの主な開発手順は以下のとおりです。

- カスタム・セキュリティ・プロバイダの設計

- SSPIの実装によるカスタム・セキュリティ・プロバイダ用のランタイム・クラスの作成

- カスタム・セキュリティ・プロバイダを構成および管理するMBeanタイプの生成

- コンソール拡張機能の記述

- カスタム・セキュリティ・プロバイダの構成

- セキュリティ・ポリシー、セキュリティ・ロール、および資格証明マップを管理するメカニズムの提供

カスタム・セキュリティ・プロバイダの設計

設計プロセスには、次の手順があります。

1. WebLogicセキュリティ・プロバイダの説明を検討して、カスタム・セキュリティ・プロバイダを作成する必要があるかどうか判断します。
WebLogicセキュリティ・プロバイダの説明は、『Oracle WebLogic Serverのセキュリティの理解』のWebLogicセキュリティ・プロバイダに関する項と、このガイドの「カスタム<Provider_Typeプロバイダを開発する必要があるか」という項にあります。

2. 作成するカスタム・セキュリティ・プロバイダのタイプを決めます。
タイプには認証、IDアサーション、プリンシパル検証、認可、裁決、ロール・マッピング、監査、資格証明マッピング、バージョン管理可能なアプリケーション、証明書パスがあります。これらについては、『Oracle WebLogic Serverセキュリティの理解』のセキュリティ・プロバイダのタイプに関する項で説明します。カスタム・セキュリティ・プロバイダは、WebLogic Serverにあらかじめ用意されているWebLogicセキュリティ・プロバイダの補強または代わりとして使用できます。

3. カスタム・セキュリティ・プロバイダ用のランタイム・クラスを作成するために実装するセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を、作成するセキュリティ・プロバイダのタイプに基づいて特定します。
様々なタイプのセキュリティ・プロバイダのSSPIについては、「セキュリティ・サービス・プロバイダ・インタフェース(SSPI)」を参照してください。また、「SSPIクイック・リファレンス」でも要約を参照できます。

4. SSPIを1つのランタイム・クラスで実装するか、2つのランタイム・クラスで実装するかを決めます。
こうしたオプションについては、「SSPI階層を理解し、ランタイム・クラスを1つ作成するか2つ作成するかを決定する」を参照してください。

5. カスタム・セキュリティ・プロバイダを管理するMBeanタイプを生成するために拡張する必要のある必須SSPI MBeanを特定します。ユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーの処理など、カスタム・セキュリティ・プロバイダを管理する追加機能を提供するには、実装するオプショナルSSPI MBeanを特定することも必要です。
SSPI MBeanについては、「セキュリティ・サービス・プロバイダ・インタフェース(SSPI) MBean」を参照してください。また、「SSPI MBeanクイック・リファレンス」でも要約を参照できます。

6. カスタム・セキュリティ・プロバイダで必要なデータベースを初期化する方法を決めます。カスタム・セキュリティ・プロバイダで単純なデータベースを作成することも、情報の格納された既存のデータベースを使用するように構成することもできます。
この2つのデータベース初期化オプションについては、「セキュリティ・プロバイダ・データベースの初期化」を参照してください。

7. カスタム・セキュリティ・プロバイダがWebLogicリソースのセキュリティ・ポリシーとの対話の一部として実行する必要がある、データベースの「準備」について特定します。この準備には、デフォルト・グループ、セキュリティ・ロール、またはセキュリティ・ポリシーの作成などがあります。
詳細については、「セキュリティ・プロバイダとWebLogicリソース」を参照してください。

SSPIの実装によるカスタム・セキュリティ・プロバイダ用のランタイム・クラスの作成

1つまたは2つのランタイム・クラスにおいて、各メソッドの実装を提供することによって特定されたSSPIを実装します。それらのメソッドには、カスタム・セキュリティ・プロバイダから提供されるセキュリティ・サービスの具体的なアルゴリズムが組み込まれていなければなりません。それらのメソッドには、サービスがどのように動作すべきであるかが記述されています。

このタスクの手順は、作成するセキュリティ・プロバイダのタイプによって異なります。この手順については、各セキュリティ・プロバイダの詳細に関する節の「適切なSSPIによるランタイム・クラスの作成」を参照してください。

カスタム・セキュリティ・プロバイダを構成および管理するMBeanタイプの生成

MBeanタイプを生成するには、次の手順に従います。

1. 必須SSPI MBeanを拡張し、オプショナルSSPI MBeanを実装し、プロバイダの構成と管理に必要なカスタム属性および操作を追加するカスタム・セキュリティ・プロバイダのMBean定義ファイル(MDF)を作成します。
MDFの詳細は、「MBean定義ファイル(MDF)の基本的な要素について」を参照してください。このタスクの手順については、各セキュリティ・プロバイダの詳細に関する節の「MBean定義ファイル(MDF)の作成」を参照してください。

2. WebLogic MBeanMakerを通じてMDFを実行し、カスタム・セキュリティ・プロバイダのMBeanタイプの中間ファイル(MBeanインタフェース、MBean実装、およびMBean情報ファイルを含む)を生成します。
WebLogic MBeanMakerについて、およびWebLogic MBeanMakerがどのようにMDFを使用してJavaファイルを生成するかについては、「WebLogic MBeanMakerによって提供されるものについて」を参照してください。このタスクの手順については、各セキュリティ・プロバイダの詳細に関する節の「WebLogic MBeanMakerを使用してMBeanタイプを生成する」を参照してください。

3. MBeanの実装ファイルを編集して、オプショナルSSPI MBeanの実装から継承されるすべてのメソッドの内容のほか、MDFに追加されたカスタム属性および操作の結果として生成されるメソッド・スタブの内容も入力します。

4. 修正された中間ファイル(MBeanタイプ用)とランタイム・クラスをWebLogic MBeanMakerを通じて実行し、MBean JARファイル(MJF)というJARファイルを生成します。
このタスクの手順については、各セキュリティ・プロバイダの詳細に関する節の「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」を参照してください。

5. MBean JARファイル(MJF)をWebLogic Server環境にインストールします。
このタスクの手順については、各セキュリティ・プロバイダの詳細に関する節の「WebLogic Server環境にMBeanタイプをインストールする」を参照してください。

コンソール拡張機能の記述

コンソール拡張を使用すると、JavaServer Pages (JSP)をWebLogic Server管理コンソールに追加して、カスタム・セキュリティ・プロバイダの管理と構成をサポートできます。コンソール拡張を使用すると、存在しない管理コンソール・サポートを追加したり、管理目的の対話をカスタマイズしたりできます。

WebLogic Server管理コンソールでカスタム・セキュリティ・プロバイダ用の完全な構成および管理サポートを利用するには、以下の場合にコンソール拡張を記述する必要があります。

- カスタム・セキュリティ・プロバイダ用のMBeanタイプを生成するときにオプショナルSSPI MBeanを実装しないことを決定したが、管理コンソールでカスタム・セキュリティ・プロバイダを構成および管理する場合(つまり、WebLogic Serverコマンドライン・インタフェースを代わりに使用しない場合)
Oracleでは、MBeanタイプの生成(「カスタム・セキュリティ・プロバイダを構成および管理するMBeanタイプの生成」を参照)によってカスタム・セキュリティ・プロバイダを構成および管理することをお薦めします。しかし、ユーザーが記述したコンソール拡張を介してカスタム・セキュリティ・プロバイダを完全に構成および管理することもできます。

- カスタム認証プロバイダでないカスタム・セキュリティ・プロバイダ用にオプショナルSSPI MBeanを実装する場合
オプショナルSSPI MBeanを実装してカスタム認証プロバイダを開発する場合は、管理コンソールでMBeanタイプの属性が自動的にサポートされることになります(オプショナルSSPI MBeanから継承されます)。カスタム認可プロバイダなどの他のタイプのカスタム・セキュリティ・プロバイダでは、このサポートは受けられません。

- シンプルなデータ型としては表せないカスタム属性を、MBean定義ファイル(MDF)に追加する場合(MDFはカスタム・セキュリティ・プロバイダのMBeanタイプの生成に使用されます)
カスタム・セキュリティ・プロバイダの「詳細」タブにカスタム属性が自動的に表示されるのは、それらがシンプルなデータ型(文字列、MBean、ブール、整数値)として表される場合のみです。非定型のデータ型(フィンガ・プリントのイメージなど)として表されるカスタム属性がある場合、管理コンソールではカスタマイズを行わない限りその属性を表示できません。

- カスタム操作をMBean定義ファイル(MDF) (カスタム・セキュリティ・プロバイダのMBeanタイプを作成するために使用される)に追加します。
カスタム操作は様々なので、管理コンソールではそれらを自動的に表示または処理する方法が分かりません。カスタム操作の例としては、声紋用のマイクや、インポート/エクスポート・ボタンなどがあります。管理コンソールでは、カスタマイズしない限りこれらの操作を表示および処理できません。

管理コンソールは、以下の場合にも拡張します。

- 企業ブランディング - たとえば、カスタム・セキュリティ・プロバイダの構成および管理に使用するページにロゴを表示する場合など

- 連結 - たとえば、カスタム・セキュリティ・プロバイダの構成および管理に使用するすべてのフィールドを、個別のタブや場所ではなく1ページに表示する場合など

コンソールの拡張の詳細は、『Oracle WebLogic Server管理コンソールの拡張』を参照してください。

カスタム・セキュリティ・プロバイダの構成

注意:

構成プロセスは、カスタム・セキュリティ・プロバイダを開発した本人、または指定された管理者が遂行できます。

構成プロセスでは、WebLogic Server管理コンソールを使用してカスタム・セキュリティ・プロバイダに構成情報を提供します。カスタム・セキュリティ・プロバイダを管理するためのMBeanタイプを生成している場合、管理コンソールでカスタム・セキュリティ・プロバイダを「構成」することは、MBeanタイプの特定のインスタンスを作成することも意味します。

管理コンソールによるセキュリティ・プロバイダの構成の詳細は、『Oracle WebLogic Serverの保護』を参照してください。

セキュリティ・ポリシー、セキュリティ・ロール、および資格証明マップを管理するメカニズムの提供

特定のタイプのセキュリティ・プロバイダでは、それらに関連付けられているセキュリティ・データを管理する方法を管理者に提供する必要があります。たとえば認可プロバイダでは、セキュリティ・ポリシーを管理する方法を管理者に提供しなければなりません。同じように、ロール・マッピング・プロバイダではセキュリティ・ロールを、資格証明マッピング・プロバイダでは資格証明マップを管理する方法が管理者に必要になります。

WebLogic認可、ロール・マッピング、および資格証明マッピングの各プロバイダの場合、管理者用の管理メカニズムがWebLogic Server管理コンソールにすでに用意されています。ただし、これらのセキュリティ・プロバイダのカスタム版を開発する場合はこれらのメカニズムを継承しないで、セキュリティ・ポリシー、セキュリティ・ロール、および資格証明マップを管理するための独自の方法を提供する必要があります。これらのメカニズムにはカスタム・セキュリティ・プロバイダのデータベースから適切なセキュリティ・データを読み書きすることが必須となりますが、管理コンソールとは統合しても統合しなくてもかまいません。

詳細については、以下のいずれかの節を参照してください。

- 「セキュリティ・ポリシーを管理するためのメカニズムの提供」 (カスタム認可プロバイダの場合)

- 「セキュリティ・ロールを管理するためのメカニズムの提供」 (カスタム・ロール・マッピング・プロバイダの場合)

- 「資格証明マップを管理するためのメカニズムの提供」 (カスタム資格証明マッピング・プロバイダの場合)

3 設計上の考慮事項

開発作業を綿密に計画すると、カスタム・セキュリティ・プロバイダの開発に要する時間と労力を大幅に削減できます。以下の節では、最初に知っておくと役立つ、セキュリティ・プロバイダの概念と機能について詳しく説明します。

- セキュリティ・プロバイダの一般的なアーキテクチャ

- セキュリティ・サービス・プロバイダ・インタフェース(SSPI)

- セキュリティ・サービス・プロバイダ・インタフェース(SSPI) MBean

- セキュリティ・データの移行

- セキュリティ・プロバイダの開発者向け管理ユーティリティ

- セキュリティ・プロバイダとWebLogicリソース

- セキュリティ・プロバイダ・データベースの初期化

- 属性バリデータの相違点

セキュリティ・プロバイダの一般的なアーキテクチャ

作成できるセキュリティ・プロバイダには様々なタイプがありますが(『Oracle WebLogic Serverセキュリティの理解』のセキュリティ・プロバイダのタイプに関する項を参照)、それらのプロバイダはすべて同じアーキテクチャに基づきます。図3-1に、セキュリティ・プロバイダの一般的なアーキテクチャを示します。このアーキテクチャの説明については図の下を参照してください。

図3-1 セキュリティ・プロバイダのアーキテクチャ

「図3-1 セキュリティ・プロバイダのアーキテクチャ」の説明

注意:

SSPIおよびSSPIを使用して作成するランタイム・クラス(実装)は両方とも.javaファイルです。図3-1の左側を参照してください。

図3-1の右側のファイルと同様、MyFooMBeanは.xmlファイルとして開始します。このファイルで、SSPI MBeanを拡張(および任意で実装)します。このMBean定義ファイル(MDF)がWebLogic MBeanMakerユーティリティで実行される場合、このユーティリティではMBeanタイプ用の.javaファイルが生成されます。「カスタム・セキュリティ・プロバイダを構成および管理するMBeanタイプの生成」を参照してください。

図3-1は、カスタム・セキュリティ・プロバイダの開発時に作成された1つのランタイム・クラス(MyFooProviderImpl)とMBeanタイプ(MyFooMBean)の関係を示しています。プロセスはWebLogic Serverインスタンスの起動時に始まり、WebLogicセキュリティ・フレームワークは以下のことを行います。

1. セキュリティ・レルムでセキュリティ・プロバイダと関連付けられたMBeanタイプを見つけます。

2. MBeanタイプからセキュリティ・プロバイダのランタイム・クラス(2つある場合は「Provider」SSPIを実装する方のランタイム・クラス)の名前を取得します。

3. セキュリティ・プロバイダが初期化(構成データの読込み)に使用する適切なMBeanインスタンスを渡します。

このため、ランタイム・クラス(1つまたは複数)およびMBeanタイプの両方で「セキュリティ・プロバイダ」と呼ばれるものが形成されます。

セキュリティ・サービス・プロバイダ・インタフェース(SSPI)

「開発プロセスの概要」で説明されているように、カスタム・セキュリティ・プロバイダの開発ではまず最初に多くのセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を実装してランタイム・クラスを作成します。この節では、以下の助けになる情報を提供します。

- 2つの重要な制限について

- 「Provider」SSPIの目的について

- バルク・アクセス・プロバイダの目的について

- 実装する「Provider」インタフェースの決定

- SSPI階層を理解し、ランタイム・クラスを1つ作成するか2つ作成するかを決定する

また、この節では各タイプのセキュリティ・プロバイダでどのSSPIを実装できるのかを示す「SSPIクイック・リファレンス」も提供します。

2つの重要な制限について

セキュリティ・プロバイダは、以下の制限事項に準拠している必要があります。

- カスタム・セキュリティ・プロバイダのランタイム・クラスの実装には、WebLogicセキュリティ・フレームワークによるセキュリティ・チェックの実行を必要とするコードを含めることはできません。セキュリティ・プロバイダは実際にセキュリティ・チェックを実行し、WebLogicリソースへのアクセス権を付与するWebLogicセキュリティ・フレームワークのコンポーネントであるため、そのようなコードを含めると無限反復が発生します。

- セキュリティ・プロバイダの実装内で、ローカル(同じサーバー、クラスタ、またはドメイン内)のJava Platform, Enterprise Edition (Java EE)バージョン5サービスを使用することはできません。これらの使用を試行することもサポートされていません。たとえば、セキュリティ・プロバイダから現在のドメイン内のEJBを呼び出すことは禁止されています。
他のドメインのJava EEサービスであれば、セキュリティ・プロバイダからアクセスおよび使用できます。

「Provider」SSPIの目的について

名前が「Provider」という接尾辞で終わる各SSPI (たとえばCredentialProvider)は、セキュリティ・プロバイダのサービスをWebLogicセキュリティ・フレームワークに公開します。これによって、セキュリティ・プロバイダの操作(初期化、開始、停止など)が可能になります。

図3-2 「Provider」SSPI

「図3-2 「Provider」SSPI」の説明

図3-2,で示されているように、セキュリティ・サービスをWebLogicセキュリティ・フレームワークに公開するSSPIはWebLogic Serverによって提供され、そのすべてが以下のメソッドを持つSecurityProviderインタフェースを拡張します。

- initialize

public void initialize(ProviderMBean providerMBean, SecurityServices securityServices)

initializeメソッドは、セキュリティ・プロバイダの関連付けられたMBeanインスタンスに限定できるProviderMBeanを引数として取ります。そのMBeanインスタンスは生成するMBeanタイプから作成され、カスタム・セキュリティ・プロバイダをWebLogic Server環境で管理できるようにする構成データを含みます。この構成データがある場合は、initializeメソッドを使用してそれを抽出する必要があります。

securityServices引数は、カスタム・セキュリティ・プロバイダで監査サービスを取得して使用する際の取得先となるオブジェクトです。監査サービスと監査の詳細は、第10章「監査プロバイダ」および第12章「カスタム・セキュリティ・プロバイダからのイベントの監査」を参照してください。

- getDescription

public String getDescription()

このメソッドは、カスタム・セキュリティ・プロバイダについて簡単に説明したテキストを返します。

- shutdown

public void shutdown()

このメソッドは、カスタム・セキュリティ・プロバイダを停止させます。

SecurityProviderを拡張するものなので、名前が「Provider」で終わるSSPIを実装するランタイム・クラスは継承したメソッドの実装を提供する必要があります。

バルク・アクセス・プロバイダの目的について

WebLogic Serverのこのリリースには、以下に示すバルク・アクセス・バージョンの認可プロバイダ、裁決プロバイダ、およびロール・マッピング・プロバイダのSSPIインタフェースが含まれています。

- BulkAuthorizationProvider

- BulkAccessDecision

- BulkAdjudicationProvider

- BulkAdjudicator

- BulkRoleProvider

- BulkRoleMapper

バルク・アクセスSSPIインタフェースを使用すると、認可、裁決、およびロール・マッピング・プロバイダにおいて、1回の呼出しで複数の判定リクエストを取得できます。「for」ループなどで複数の呼出しを実行する必要がありません。バルクSSPIバリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡されたResourceオブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測できるようになります。

詳細については、「バルク認可プロバイダ」、「バルク認可プロバイダ」および「バルク・ロール・マッピング・プロバイダ」を参照してください。

実装する「Provider」インタフェースの決定

名前が「Deployable」で始まり、「Provider」で終わるSSPIの実装(DeployableRoleProviderV2など)は、カスタム・セキュリティ・プロバイダのサービスをWebLogicセキュリティ・フレームワークに公開します(「「Provider」SSPIの目的について」を参照)。ただし、それらのSSPIの実装では追加のタスクも実行されます。これらのSSPIはまた、サーブレット・デプロイメント記述子(web.xml、weblogic.xml)、EJBデプロイメント記述子(ejb-jar.xml、weblogic-ejb.jar.xml)、およびEARデプロイメント記述子(application.xml、weblogic-application.xml)をはじめとするデプロイメント記述子におけるセキュリティのサポートを提供します。

認可プロバイダ、資格証明マッピング・プロバイダ、およびロール・マッピング・プロバイダには、デプロイ可能バージョンの「Provider」SSPIがあります。

注意:

セキュリティ・ポリシー、セキュリティ・ロール、および資格証明を格納するセキュリティ・プロバイダ・データベースが読取り専用の場合、認可、ロール・マッピング、および資格証明マッピングの各セキュリティ・プロバイダ用にデプロイ可能ではないバージョンのSSPIを実装できます。ただし、その場合でも、デプロイメントを処理するセキュリティ・プロバイダのデプロイ可能バージョンを構成する必要があります。

DeployableAuthorizationProviderV2 SSPI

WebアプリケーションまたはEnterprise JavaBean (EJB)のデプロイメントにかわってポリシーをデプロイできる認可プロバイダでは、AuthorizationProvider SSPIではなくDeployableAuthorizationProviderV2 SSPIを実装する必要があります。しかし、DeployableAuthorizationProviderV2 SSPIはAuthorizationProvider SSPIの拡張なので、実際には両方のSSPIのメソッドを実装する必要があります。というのも、WebアプリケーションやEJBのデプロイメント作業では、認可プロバイダがポリシーの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ・レルムでは、少なくとも1つの認可プロバイダがDeployableAuthorizationProviderV2 SSPIをサポートする必要があり、サポートされていない場合、WebアプリケーションやEJBをデプロイできなくなります。

注意:

セキュリティ・ポリシーの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のセキュリティ・ポリシーに関する項を参照してください。

DeployableRoleProviderV2 SSPI

WebアプリケーションまたはEnterprise JavaBean (EJB)のデプロイメントにかわってロールをデプロイできるロール・マッピング・プロバイダでは、RoleProvider SSPIではなくDeployableRoleProviderV2 SSPIを実装する必要があります。しかし、DeployableRoleProviderV2 SSPIはRoleProvider SSPIの拡張なので、実際には両方のSSPIのメソッドを実装する必要があります。というのも、WebアプリケーションやEJBのデプロイメント作業では、ロール・マッピング・プロバイダがセキュリティ・ロールの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ・レルムでは、少なくとも1つのロール・マッピング・プロバイダがこのSSPIをサポートする必要があり、そうでなければ、WebアプリケーションやEJBをデプロイすることが不可能になります。

注意:

セキュリティ・ロールの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

DeployableCredentialProvider SSPI

注意:

DeployableCredentialProviderインタフェースは、このリリースのWebLogic Serverで非推奨になりました。

リソース・アダプタ(RA)のデプロイメントにかわってセキュリティ・ポリシーをデプロイできる資格証明マッピング・プロバイダでは、CredentialProvider SSPIではなくDeployableCredentialProvider SSPIを実装する必要があります。しかし、DeployableCredentialProvider SSPIはCredentialProvider SSPIの拡張なので、実際には両方のSSPIのメソッドを実装する必要があります。というのも、リソース・アダプタのデプロイメント作業では、資格証明マッピング・プロバイダが資格証明およびマッピングの作成や削除といった付加的な作業を実行する必要があるからです。セキュリティ・レルムでは、少なくとも1つの資格証明マッピング・プロバイダがこのSSPIをサポートする必要があり、そうでなければ、リソース・アダプタをデプロイすることが不可能になります。

注意:

資格証明の詳細は、「資格証明マッピングの概念」を参照してください。セキュリティ・ポリシーの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のセキュリティ・ポリシーに関する項を参照してください。

SSPI階層を理解し、ランタイム・クラスを1つ作成するか2つ作成するかを決定する

図3-3は、資格証明マッピング・プロバイダを使用してすべてのSSPIに共通の継承階層を示すとともに、ランタイム・クラスでどのようにそれらのインタフェースを実装できるのかを示します。この例では、Oracleが提供するSecurityProviderインタフェースと、CredentialProviderV2およびCredentialMapperV2 SSPIを使用します。図3-3は、CredentialProviderV2 SSPIおよびCredentialMapperV2 SSPIを実装するMyCredentialMapperProviderImplという単一のランタイム・クラスを表しています。

図3-3 資格証明マッピングSSPIと1つのランタイム・クラス

「図3-3 資格証明マッピングSSPIと1つのランタイム・クラス」の説明

ただし、図3-3 SSPIを実装できる1つの方法のみを示します(単一のランタイム・クラスを作成する方法)。必要に応じて、図3-4で示されているように2つのランタイム・クラスを使用することもできます。2つとは、名前が「Provider」で終わるSSPI (CredentialProviderV2など)の実装のためのランタイム・クラスと、他のSSPI (CredentialMapperV2 SSPIなど)の実装のためのランタイム・クラスです。

2つのランタイム・クラスがある場合、名前が「Provider」で終わるSSPIを実装するクラスは他のSSPIを実装するランタイム・クラスを生成するためのファクトリとして機能します。たとえば、図3-4では、MyCredentialMapperProviderImplがMyCredentialMapperImplを生成するためのファクトリとして機能します。

図3-4 資格証明マッピングSSPIと2つのランタイム・クラス

「図3-4 資格証明マッピングSSPIと2つのランタイム・クラス」の説明

注意:

実行時実装クラスを2つにする場合は、セキュリティ・プロバイダのMBeanタイプを生成するときに必ず両方の実行時実装クラスをMBean JARファイル(MJF)に格納する必要があります。詳細については、「カスタム・セキュリティ・プロバイダを構成および管理するMBeanタイプの生成」を参照してください。

SSPIクイック・リファレンス

表3-1に、セキュリティ・プロバイダのタイプ(およびそれらのコンポーネント)と、その開発に使用するSSPIおよびその他のインタフェースとの対応を示します。

表3-1 セキュリティ・プロバイダとそのコンポーネント、および対応するSSPI

タイプ/コンポーネント

SSPI/インタフェース

認証プロバイダ

AuthenticationProviderV2

LoginModule (JAAS)

LoginModule

IDアサーション・プロバイダ

AuthenticationProviderV2

IDアサータ

IdentityAsserterV2

プリンシパル検証プロバイダ

PrincipalValidator

認可

AuthorizationProvider

DeployableAuthorizationProviderV2

アクセス決定

AccessDecision

裁決プロバイダ

AdjudicationProviderV2

Adjudicator

AdjudicatorV2

ロール・マッピング・プロバイダ

RoleProvider

DeployableRoleProviderV2

ロール・マッパー

RoleMapper

監査プロバイダ

AuditProvider

監査チャネル

AuditChannel

資格証明マッピング・プロバイダ

CredentialProviderV2

資格証明マッパー

CredentialMapperV2

証明書パス・プロバイダ

CertPathProvider

バージョン管理可能なアプリケーションのプロバイダ

VersionableApplicationProvider

注意:

カスタム・セキュリティ・プロバイダのランタイム・クラスを作成するために使用するSSPIは、weblogic.security.spiパッケージに配置されます。このパッケージの詳細は、WebLogic Server APIリファレンスJavadocを参照してください。

セキュリティ・サービス・プロバイダ・インタフェース(SSPI) MBean

「開発プロセスの概要」で説明されているように、カスタム・セキュリティ・プロバイダ開発の2番目の手順では、カスタム・セキュリティ・プロバイダのMBeanタイプを生成します。この節では、以下の助けになる情報を提供します。

- MBeanタイプが必要な理由について

- 拡張および実装するSSPI MBeanの決定

- MBean定義ファイル(MDF)の基本的な要素について

- SSPI MBeanの階層と管理コンソールに対する影響について

- WebLogic MBeanMakerによって提供されるものについて

また、この節ではどの必須SSPI MBeanを拡張する必要があるのか、そしてどのオプショナルSSPI MBeanを各タイプのセキュリティ・プロバイダで実装できるのかを示す「SSPI MBeanクイック・リファレンス」も提供します。

MBeanタイプが必要な理由について

カスタム・セキュリティ・プロバイダのランタイム・クラスを作成することに加えて、MBeanタイプを生成することも必要です。MBeanという用語はマネージドBeanの略で、JMX (Java Management eXtensions)で管理可能なリソースを表すJavaオブジェクトのことです。

注意:

JMXは、標準的な管理アーキテクチャ、APIおよび管理サービスを定義する仕様です。『Oracle WebLogic Server JMXによる管理の容易なアプリケーションの開発』のJMXの理解に関する項を参照してください。

MBeanタイプは、MBeanのインスタンスのファクトリです。MBeanのインスタンスは、WebLogic Server管理コンソールを使用して作成できます。MBeanのインスタンスが作成されたら、管理コンソールでそのインスタンスを使用してカスタム・セキュリティ・プロバイダを構成および管理できます。

注意:

すべてのMBeanインスタンスは自分の親タイプを認識しているので、MBeanタイプの構成を変更すると、管理コンソールを使用して作成したすべてのインスタンスの構成も更新されます。(詳細については、「SSPI MBeanの階層と管理コンソールに対する影響について」を参照してください)。

拡張および実装するSSPI MBeanの決定

MBeanタイプを作成するにはSSPI MBeanというMBeanインタフェースを使用します。カスタム・セキュリティ・プロバイダ用のMBeanタイプを作成するのに利用できるSSPI MBeanには、以下の2つのタイプがあります。

- 必須SSPI MBean。セキュリティ・プロバイダをWebLogic Server環境内で構成および管理できるようにするための基本的なメソッドが定義されるので、拡張する必要があります。

- オプショナルSSPI MBean。セキュリティ・プロバイダを管理するための追加メソッドが定義されるので実装することができます。セキュリティ・プロバイダのタイプが異なれば、利用できるオプショナルSSPI MBeanも異なります。

詳細については、「SSPI MBeanクイック・リファレンス」を参照してください。

MBean定義ファイル(MDF)の基本的な要素について

MBean定義ファイル(MDF)は、WebLogic MBeanMakerユーティリティで、MBeanタイプを構成するJavaファイルを生成するために使用されるXMLファイルです。すべてのMDFでは、作成済のセキュリティ・プロバイダのタイプに固有の必須SSPI MBeanを拡張する必要があり、オプショナルSSPI MBeanを実装できます。

例3-1に、サンプルのMBean定義ファイル(MDF)を示します。その内容の説明については、リストの下を参照してください。(具体的には、WebLogic資格証明マッピング・プロバイダのMBeanタイプの生成に使用するMDFです。DeployableCredentialProviderインタフェースは、このリリースのWebLogic Serverで非推奨になったので注意してください。

注意:

MDF要素の構文についての詳細なリファレンスは、付録A「MBean定義ファイル(MDF)要素の構文」に収められています。

例3-1 DefaultCredentialMapper.xml

<MBeanType
Name = "DefaultCredentialMapper"
DisplayName = "DefaultCredentialMapper"
Package = "weblogic.security.providers.credentials"
Extends = "weblogic.management.security.credentials. DeployableCredentialMapper"
Implements = "weblogic.management.security.credentials. UserPasswordCredentialMapEditor,
weblogic.management.security.credentials.UserPasswordCredentialMapExtendedReader,
weblogic.management.security.ApplicationVersioner,
weblogic.management.security.Import,
weblogic.management.security.Export"
PersistPolicy = "OnUpdate"
Description = "This MBean represents configuration attributes for the WebLogic Credential
Mapping provider.&lt;p&gt;"
>
<MBeanAttribute
Name = "ProviderClassName"
Type = "java.lang.String"
Writeable = "false"
Default = "&quot;weblogic.security.providers.credentials. DefaultCredentialMapperProviderImpl&quot;"
Description = "The name of the Java class that loads the WebLogic Credential Mapping
provider."
/>
<MBeanAttribute
Name = "Description"
Type = "java.lang.String"
Writeable = "false"
Default = "&quot;Provider that performs Default Credential Mapping&quot;"
Description = "A short description of the WebLogic Credential Mapping provider."
/>
<MBeanAttribute
Name = "Version"
Type = "java.lang.String"
Writeable = "false"
Default = "&quot;1.0&quot;"
Description = "The version of the WebLogic Credential Mapping provider."
/>
:
:
</MBeanType>

<MBeanType>タグ内の太字の属性は、このMDFがDefaultCredentialMapperという名前であり、DeployableCredentialMapperという必須SSPI MBeanを拡張するものであることを示しています。また、UserPasswordCredentialMapEditorオプショナルSSPI MBeanを実装することで、追加の管理機能も含んでいます。

<MBeanAttribute>タブで定義されているProviderClassName、Description、およびVersionの各属性は、セキュリティ・プロバイダの基本的な構成方法を定義するものであり、Providerという基本必須SSPI MBeanから継承されるものなので、セキュリティ・プロバイダのMBeanタイプを生成するために使用されるどのようなMDFでも必須です(図3-5を参照)。ProviderClassName属性は特に重要です。ProviderClassName属性の値は、セキュリティ・プロバイダのランタイム・クラスのJavaファイル名(すなわち、「Provider」という文字列で終わる適切なSSPIの実装)です。例3-1で示されているサンプルのランタイム・クラスは、DefaultCredentialMapperProviderImpl.javaです。

例3-1では示されていませんが、<MBeanAttribute>タグや<MBeanOperation>タグを使用してMDFに属性や操作を追加できます。ほとんどのカスタム属性は、WebLogic Server管理コンソールのカスタム・セキュリティ・プロバイダの「プロバイダ固有」タブに自動的に表示されます。カスタム操作を表示するには、コンソール拡張を記述する必要があります。(「コンソール拡張機能の記述」を参照してください。)

注意:

サンプル監査プロバイダは、カスタム属性の追加例を提供しています。

カスタム・プロバイダとクラスパス

WL_HOME\server\lib\mbeantypesからロードされるクラスは、WebLogic Serverにデプロイされている他のJARファイルやEARファイルからは認識されません。共有する必要がある共通のユーティリティ・クラスがある場合、そのクラスはシステムのクラスパスに配置する必要があります。

注意:

MBeanタイプをインストールするデフォルトのディレクトリは、WL_HOME\server\lib\mbeantypesです。初めて使用するバージョンが9.0の場合、セキュリティ・プロバイダは...\domaindir\lib\mbeantypesからもロードできます。...\domaindir\lib\mbeantypesディレクトリから読み込まれるJARファイルは、アプリケーション間で共有できます。このファイルはシステム・クラスパスに明示的に格納する必要はありません。

MBean操作から例外のスロー

カスタム・プロバイダのMBeanは、JDK例外の型またはweblogic.management.utils例外の型のみをスローする必要があります。それ以外の場合、JMXクライアントには、例外を受け付ける必要があるコードが含まれていない可能性があります。

- 型付き例外の場合、その型から独自の例外の型を派生させてスローするのではなく、MBeanメソッドのthrow句から正しい型のみをスローする必要があります。

- ネストされた例外の場合は、JDK例外の型またはweblogic.management.utils例外のみをスローする必要があります。

- ランタイム例外の場合は、JDK例外のみをスローするか、JDK例外を介してのみ渡す必要があります。

MBean属性に対して非クリア・テキスト値の指定

表A-1に示すように、Encrypted属性を使用すると、MBean属性の値がクリア・テキストとして表示されないように指定できます。たとえば、パスワードの入力を取得したときにMBean属性の値を暗号化する場合などです。以下のコードでは、Encrypted属性の使用例を示します。

<MBeanAttribute
Name        = "PrivatePassPhrase"
Type        = "java.lang.String"
Encrypted   = "true"
Default     = "&quot;&quot;"
Description = "The Keystore password."
/>

SSPI MBeanの階層と管理コンソールに対する影響について

MBean定義ファイル(MDF)で拡張する必須SSPI MBean (基本SSPI MBeanであるProviderに至るまで)に指定されている属性と操作はすべて、関連するセキュリティ・プロバイダのWebLogic Server管理コンソール・ページに自動的に表示されます。これらの属性と操作は、カスタム・セキュリティ・プロバイダを構成および管理するために使用します。

注意:

認証セキュリティ・プロバイダに限っては、MDFで実装されるオプショナルSSPI MBeanで指定された属性と操作も管理コンソールで自動的にサポートされます。他のタイプのセキュリティ・プロバイダの場合、オプショナルSSPI MBeanから継承された属性/操作を管理コンソールで使用するには、コンソール拡張機能を記述する必要があります。詳細については、「コンソール拡張機能の記述」を参照してください。

図3-5は、WebLogic資格証明マッピングMDFを例に使用してセキュリティ・プロバイダのSSPI MBean階層を示すとともに、どの属性/操作がWebLogic資格証明マッピング・プロバイダの管理コンソールで表示されるのかを示します。

図3-5 資格証明マッピング・プロバイダのSSPI MBean階層

「図3-5 資格証明マッピング・プロバイダのSSPI MBean階層」の説明

図3-5で示されているように、DefaultCredentialMapper MDFのSSPI MBeanの階層を実装することにより、図3-6のページが管理コンソールで表示されます。DefaultCredentialMapper MDFの部分的なリストは、例3-1に示してあります。

図3-6 DefaultCredentialMapperの場合の管理コンソール・ページ

「図3-6 DefaultCredentialMapperの場合の管理コンソール・ページ」の説明

「名前」、「説明」、および「バージョン」の各フィールドは、Providerという基本必須SSPI MBeanから継承されDefaultCredentialMapper MDFに指定されている同名の属性から得られたものです。DefaultCredentialMapper MDF内のDisplayName属性から「名前」フィールドの値が生成されるほか、DescriptionとVersionの各属性からも、それぞれ対応するフィールドの値が生成されることに注意します。なお、「プロバイダ固有」ページの「資格証明マッピング・デプロイメントを有効化」フィールドが表示されているのは、DefaultCredentialMapper MDFの拡張元であるDeployableCredentialMapper必須SSPI MBeanにCredentialMappingDeploymentEnabled属性が定義されているためです。この管理コンソール・ページには、UserPasswordCredentialMapEditorオプショナルSSPI MBeanのDefaultCredentialMapperの実装に対応するフィールドは表示されません。

WebLogic MBeanMakerによって提供されるものについて

WebLogic MBeanMakerは、MBean定義ファイル(MDF)を入力とし、MBeanタイプのファイルを出力するコマンドライン・ユーティリティです。WebLogic MBeanMakerを使用して作成したMDFを実行すると、以下のことが行われます。

- 必須SSPI MBeanから継承された属性(MDFに追加されたカスタム属性も同様)により、WebLogic MBeanMakerによってMBeanタイプの情報ファイルに完全なゲッター/セッター・メソッドが生成されます。(MBean情報ファイルは図 3-7には示されていません。)MBean情報ファイルの詳細については、「MBean情報ファイルについて」を参照してください。
必要な開発者のアクション: なし。これらのメソッドでさらなる作業は必要ありません。

- オプショナルSSPI MBeanから継承された操作により、MBeanの実装ファイルでメソッドが継承されます(メソッドの実装は一から記述しなければなりません)
開発者のアクション: 現時点では、WebLogic MBeanMakerでは継承されたメソッドのメソッド・スタブが生成されません。したがって、適切な実装を提供する必要があります。

- MDFに追加されたカスタム操作により、WebLogic MBeanMakerがメソッド・スタブを生成します。
開発者のアクション: メソッドの実装を提供する必要があります。ただし、WebLogic MBeanMakerでスタブが生成されるので、Javaメソッドのシグネチャを参照する必要はありません。

このことを図3-7に示します。

図3-7 WebLogic MBeanMakerによって提供されるもの

「図3-7 WebLogic MBeanMakerによって提供されるもの」の説明

MBean情報ファイルについて

MBean情報ファイルには、MBean定義ファイル内のデータのコンパイル済みの定義が、JMX Model MBeansで要求される形式で含まれます。このファイルの形式は、それぞれがそのエンティティを記述する記述子タグのセットを持つ属性、操作、通知のリストです。加えて、MBean自体にも、一連の記述子タグがあります。この形式の例を次に示します。

MBean + tags
attribute1 + tags, attribute2 + tags ...
operation1 + tags, operation2 + tags ...
notification1 + tags, notification2 + tags ...

必要に応じて、標準のJMXサーバーのgetMBeanInfoメソッドを呼び出し、ModelMBeanInfoを取得することで、実行時にこの情報にアクセスできます。

注意:

返された構造を解釈する方法を決定するために、必ずJMX仕様を参照してください。

SSPI MBeanクイック・リファレンス

カスタム・セキュリティ・プロバイダの開発の一部として実装する必要のあるSSPIのリストに基づいて、拡張する必要のある必須SSPI MBeanを表3-2で特定できます。また、表3-3から表3-5では、セキュリティ・プロバイダを管理するために実装できるオプショナルSSPI MBeanを特定できます。

表3-2 必須SSPI MBean

タイプ

パッケージ名

必須SSPI MBean

認証プロバイダ

authentication

Authenticator

IDアサーション・プロバイダ

authentication

IdentityAsserter

認可プロバイダ

authorization

AuthorizerまたはDeployableAuthorizer

裁決プロバイダ

authorization

Adjudicator

ロール・マッピング・プロバイダ

authorization

RoleMapperまたはDeployableRoleMapper

監査プロバイダ

audit

Auditor

資格証明マッピング・プロバイダ

credentials

CredentialMapperまたはDeployableCredentialMapper

証明書パス・プロバイダ

pk

CertPathBuilderまたはCertPathValidator

注意:

表3-2に示した必須SSPI MBeanは、weblogic.management.security.<Package_Name>というパッケージに定義されています。

表3-3 認証用オプショナルSSPI MBean

オプショナルSSPI MBean

用途

GroupEditor

グループを作成します。当該グループがすでに存在する場合には、例外がスローされます。

GroupMemberLister

グループのメンバーを列挙します。

GroupReader

グループに関するデータを読み込みます。

GroupRemover

グループを削除します。

MemberGroupLister

あるユーザーまたはグループが所属するグループを列挙します。

UserEditor

ユーザーを作成、編集、および削除します。

UserPasswordEditor

ユーザーのパスワードを変更します。

UserReader

ユーザーに関するデータを読み込みます。

UserRemover

ユーザーを削除します。

注意:

表3-3に示した認証用オプショナルSSPI MBeanは、weblogic.management.security.authenticationパッケージに定義されています。また、これらはWebLogic Server管理コンソールでもサポートされます。

表3-4に示す認可用オプショナルSSPI MBeanの実装方法の例については、Manageable Sample Authentication Providerのコードを参照してください。

表3-4 認可用オプショナルSSPI MBean

オプショナルSSPI MBean

用途

PolicyConsumer

プロバイダでポリシーの消費をサポートすることを示します。

PolicyEditor

セキュリティ・ポリシーを作成、編集、および削除します。

PolicyLister

ポリシーに関するデータをリストします。

PolicyReader

セキュリティ・ポリシーに関するデータを読み込みます。

PolicyStore

ポリシーをポリシー・ストアで管理します。

RoleEditor

セキュリティ・ロールを作成、編集、および削除します。

RoleReader

セキュリティ・ロールに関するデータを読み込みます。

RoleLister

ロールに関するデータをリストします。

注意:

表3-4に示した認可用オプショナルSSPI MBeanは、weblogic.management.security.authorizationパッケージに定義されています。

表3-5 資格証明マッピング用オプショナルSSPI MBean

オプショナルSSPI MBean

用途

UserPasswordCredentialMapEditor

WebLogicユーザーをリモートのユーザー名およびパスワードにマップする資格証明マップを編集します。

UserPasswordCredentialMapExtendedReader

WebLogicユーザーをリモートのユーザー名およびパスワードにマップする資格証明マップを読み込みます。

UserPasswordCredentialMapReader

WebLogicユーザーをリモートのユーザー名およびパスワードにマップする資格証明マップを読み込みます。

注意:

表3-5に示した資格証明マッピング用オプショナルSSPI MBeanは、weblogic.management.security.credentialsパッケージに定義されています。

セキュリティ・データの移行

一部のWebLogicセキュリティ・プロバイダは、セキュリティ・データの移行をサポートするように開発されています。つまり、(WebLogic認証プロバイダの)ユーザーとグループ、(WebLogic認可プロバイダの)セキュリティ・ポリシー、(WebLogicロール・マッピング・プロバイダの)セキュリティ・ロール、または(WebLogic資格証明マッピング・プロバイダの)資格証明マップを、セキュリティ・レルムからエクスポートして別のセキュリティ・レルムにインポートできます。管理者は、これらのWebLogicセキュリティ・プロバイダのセキュリティ・データを個別に移行したり、すべてのWebLogicセキュリティ・プロバイダのセキュリティ・データ(セキュリティ・レルム全体のセキュリティ・データ)を一度に移行したりできます。

管理者にとって、セキュリティ・データの移行は次のような場合に有用です。

- 開発モードから本番モードへ移行します。

- 本番モードのセキュリティ構成を新しいWebLogic Serverドメインのセキュリティ・レルムに拡散します。

- 同じWebLogicドメインまたは別のWebLogicドメインの新しいセキュリティ・レルムにデータを移動します。

- 同じWebLogic Serverドメイン内のあるセキュリティ・レルムから新しいセキュリティ・レルムにデータを移動します(新しいセキュリティ・レルムで、1つまたは複数のWebLogicセキュリティ・プロバイダがカスタム・セキュリティ・プロバイダに置き換えられる場合)。この場合、管理者は、置換えの対象とならないセキュリティ・プロバイダのセキュリティ・データをコピーする必要があります。

以下の節では、セキュリティ・データの移行の詳細について説明します。

- 移行の概念

- カスタム・セキュリティ・プロバイダへの移行サポートの追加

- セキュリティ・データの移行に関する管理コンソールのサポート

移行の概念

セキュリティ・データを移行する前に、以下の概念を理解しておく必要があります。

- フォーマット

- 制約

- 移行ファイル

フォーマット

フォーマットとは単に、セキュリティ・データのエクスポートまたはインポート方法を指定するデータ・フォーマットです。現在、WebLogic Serverはセキュリティ・プロバイダの開発者に、標準の公開されたフォーマットを提供していません。そのため、使用するフォーマットはすべてユーザー次第です。ただし、データを任意のセキュリティ・プロバイダからエクスポートしてから、後で別のセキュリティ・プロバイダにインポートし、両セキュリティ・プロバイダは同一のフォーマットを処理する方法を認識する必要があることを銘記しておいてください。サポートされるフォーマットは、特定のセキュリティ・プロバイダが処理方法を理解しているデータ・フォーマットのリストです。

注意:

WebLogicセキュリティ・プロバイダで使用されるデータ・フォーマットは非公開であるため、現時点では、WebLogicセキュリティ・プロバイダとカスタム・セキュリティ・プロバイダの間でセキュリティ・データを移行することはできません。

また、別のベンダーのセキュリティ・プロバイダとセキュリティ・データを交換するには、セキュリティ・ベンダーがそのための標準フォーマットに従って連携する必要があります。

制約

制約は、エクスポートまたはインポート処理のオプションの指定に使用されるキーと値の組合せです。制約を使用すると、セキュリティ・プロバイダのデータベースからエクスポートまたはインポートするセキュリティ・データを管理者が制御できます。たとえば、管理者は、認証プロバイダのデータベースから、グループではなくユーザーまたはユーザーのサブセットだけをエクスポートすることができます。サポートされる制約は、特定のセキュリティ・プロバイダの移行処理で管理者が指定できる制約のリストです。たとえば、認証プロバイダのデータベースを使用して、ユーザーとグループをインポートできますが、セキュリティ・ポリシーはインポートできません。

移行ファイル

エクスポート・ファイルは、移行処理のエクスポートの段階で、セキュリティ・データを(指定されたフォーマットで)書き込むファイルです。インポート・ファイルは、移行処理のインポートの段階で、セキュリティ・データを(指定されたフォーマットで)読み込むファイルです。エクスポート・ファイルとインポート・ファイルのどちらも、あるセキュリティ・プロバイダのデータベースから別の場所に移行する際の、セキュリティ・データの一時的な格納場所です。

警告:

移行ファイルは、保護措置を取らない限り保護されません。移行ファイルには重要なデータが入っているので、扱いには十分な注意が必要です。

カスタム・セキュリティ・プロバイダへの移行サポートの追加

WebLogicセキュリティ・プロバイダのようにセキュリティ・データの移行をサポートするカスタム・セキュリティ・プロバイダを開発する場合、そのプロバイダのMBeanタイプを生成するためのMBean定義ファイル(MDF)でweblogic.management.security.ImportMBeanおよびweblogic.management.security.ExportMBeanオプショナルSSPI MBeanを拡張してから、そのメソッドを実装する必要があります。これらのオプショナルSSPI MBeanには、表3-6および表3-7に示されている属性と操作が含まれています。

表3-6 ExportMBeanオプショナルSSPI MBeanの属性と操作

属性/操作

説明

SupportedExportFormats

セキュリティ・プロバイダがサポートしているエクスポート・データ・フォーマットのリスト。

SupportedExportConstraints

セキュリティ・プロバイダがサポートしているエクスポート制約のリスト。

exportData

プロバイダ固有のセキュリティ・データを指定されたフォーマットでエクスポートします。

format

プロバイダ固有のデータをエクスポートするフォーマットを指定するexportData操作のパラメータ。

filename

プロバイダ固有のデータをエクスポートするためのファイルのフルパスを指定するexportData操作のパラメータ。

注意: セキュリティ・データの移行をサポートするWebLogicセキュリティ・プロバイダは、(作業対象のサーバーを基準とする)相対パスでも指定できるように実装されています。すでに存在しているディレクトリを指定する必要があります。ディレクトリはWebLogic Serverによって作成されません。

constraints

プロバイダ固有のデータをエクスポートする場合の制約を指定するexportData操作のパラメータ。

注意:

詳細は、Oracle WebLogic Server MBean APIリファレンスでExportMBeanインタフェースを参照してください。

表3-7 ImportMBeanオプショナルSSPI MBeanの属性と操作

属性/操作

説明

SupportedImportFormats

セキュリティ・プロバイダがサポートしているインポート・データ・フォーマットのリスト。

SupportedImportConstraints

セキュリティ・プロバイダがサポートしているインポート制約のリスト。

importData

プロバイダ固有のデータを指定されたフォーマットでインポートします。

format

プロバイダ固有のデータをインポートするフォーマットを指定するimportData操作のパラメータ。

filename

プロバイダ固有のデータをインポートするためのファイル名のフルパスを指定するimportData操作のパラメータ。

注意: セキュリティ・データの移行をサポートするWebLogicセキュリティ・プロバイダは、(作業対象のサーバーを基準とする)相対パスでも指定できるように実装されています。すでに存在しているディレクトリを指定する必要があります。ディレクトリはWebLogic Serverによって作成されません。

constraints

プロバイダ固有のデータをインポートする場合の制約を指定するimportData操作のパラメータ。

注意:

詳細は、Oracle WebLogic Server MBean APIリファレンスでExportMBeanインタフェースとImportMBeanインタフェースを参照してください。

セキュリティ・データの移行に関する管理コンソールのサポート

カスタム・セキュリティ・プロバイダのMDFで拡張可能な他のオプショナルSSPI MBeanと違い、ExportMBeanおよびImportMBeanオプショナルSSPI MBeanから継承した属性および操作は、関連付けられているセキュリティ・プロバイダのWebLogic Server管理コンソール・ページの「移行」タブに自動的に表示されます(図3-8を参照)。これにより、管理者は各セキュリティ・プロバイダのセキュリティ・データを個別にエクスポートおよびインポートすることができます。

注意:

セキュリティ・プロバイダが移行機能を持っていない場合、そのセキュリティ・プロバイダの「移行」タブは管理コンソールに表示されません。

管理コンソールを使用して個々のセキュリティ・プロバイダのセキュリティ・データを移行する手順については、『Oracle WebLogic Serverの保護』のセキュリティ・データの移行に関する項を参照してください。

図3-8 WebLogic認証プロバイダの「移行」タブ

「図3-8 WebLogic認証プロバイダの「移行」タブ」の説明

また、セキュリティ・レルムに移行機能を持つセキュリティ・プロバイダが構成されている場合、管理者はセキュリティ・レルム・レベルの「移行」タブ(図3-9を参照)を使用して、セキュリティ・レルムにあるすべてのセキュリティ・プロバイダのセキュリティ・データを一度にエクスポートまたはインポートできます。

注意:

セキュリティ・レルム・レベルの「移行」タブは、移行機能を持つセキュリティ・プロバイダがセキュリティ・レルムで構成されているかどうかにかかわらず、管理コンソールに常に表示されます。ただし、「移行」タブが機能するのは、1つまたは複数のセキュリティ・プロバイダが移行機能を持っている場合だけです。

すべてのセキュリティ・プロバイダのセキュリティ・データを一度に移行する手順については、『Oracle WebLogic Serverの保護』のセキュリティ・データの移行に関する項を参照してください。

図3-9 セキュリティ・レルムの「移行」タブ

「図3-9 セキュリティ・レルムの「移行」タブ」の説明

注意:

オプションのSSPI MBeanであるExportMBeanおよびImportMBeanを拡張する場合は、管理コンソールではなくWebLogic Scripting Tool (WLST)を使用してセキュリティ・データを移行することもできます。詳細は、『Oracle WebLogic Scripting Tool』を参照してください。

MDFに属性または操作を追加する場合、管理コンソールで使用できるように、やはりコンソール拡張を記述する必要があります。

セキュリティ・プロバイダの開発者向け管理ユーティリティ

weblogic.management.utilsパッケージには、開発者にとって特にカスタム・セキュリティ・プロバイダのMBeanタイプを生成する際に役立つ、補足的な管理インタフェースと例外が含まれています。カスタム・セキュリティ・プロバイダを開発する際に、これらのインタフェースと例外を実装する必要はありません(カスタム・セキュリティ・プロバイダのMDFでオプショナルSSPI MBeanを実装してこれらを継承する場合を除く)。

注意:

このインタフェースとクラスは、一般的な用途のユーティリティ、つまり非セキュリティMBeanにも使用できるものなので、weblogic.management.securityではなくこのパッケージに入っています。様々な種類のMBeanについては、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic ServerサブシステムMBeanの概要に関する項を参照してください。

weblogic.management.utilsパッケージには、以下のユーティリティが含まれています。

- 一般例外

- 大きなデータ・リストを扱うためのメソッドを提供するインタフェース

- 外部LDAPサーバーと通信するために必要な構成属性を含むインタフェース

注意:

Manageable Sample Authenticationは、データ・リストを扱うためだけでなく、例外用にもweblogic.management.utilsパッケージを使用します。

詳細は、Oracle WebLogic Server MBean APIリファレンスでExportMBeanインタフェースとweblogic.management.utilsパッケージを参照してください。

セキュリティ・プロバイダとWebLogicリソース

WebLogicリソースは、権限のないアクセスから保護することができるWebLogic Serverエンティティを表す構造化オブジェクトです。カスタムの認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダの開発者は、これらのセキュリティ・プロバイダが、WebLogicリソースおよびそれらのリソースのセキュリティに使用されるセキュリティ・ポリシーとどのように対話するかを理解しておく必要があります。

注意:

セキュリティ・ポリシーは、以前のリリースのWebLogic ServerでWebLogicリソースを保護するために使用していたアクセス制御リスト(ACL)と権限にかわるものです。

以下の節では、セキュリティ・プロバイダとWebLogicリソースについて説明します。

- WebLogicリソースのアーキテクチャ

- WebLogicリソースのタイプ

- WebLogicリソース識別子

- WebLogicリソースのデフォルト・グループの作成

- WebLogicリソースのデフォルト・セキュリティ・ロールの作成

- WebLogicリソースのデフォルト・セキュリティ・ポリシーの作成

- 単一親リソース階層

- ContextHandlerとWebLogicリソース

注意:

詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。

WebLogicリソースのアーキテクチャ

weblogic.security.spiパッケージに定義されているResourceインタフェースは、権限のないアクセスから保護できるWebLogicリソースを表すオブジェクトを定義します。weblogic.security.serviceパッケージに定義されているResourceBaseクラスは、より詳細なWebLogicリソース・タイプの抽象基底クラスで、リソースを拡張するためのモデルです(詳細については、図3-10と「WebLogicリソースのタイプ」を参照)。

図3-10 WebLogicリソースのアーキテクチャ

「図3-10 WebLogicリソースのアーキテクチャ」の説明

ResourceBaseクラスには、Oracleが提供するgetID、getKeys、getValues、およびtoStringメソッドの実装が含まれています。詳細は、WebLogic Server APIリファレンスJavadocのResourceBaseクラスに関する項を参照してください。

このアーキテクチャにより、特定のWebLogicリソースを意識することなくセキュリティ・プロバイダを開発できます。このため、新しいリソース・タイプが追加されても、セキュリティ・プロバイダを修正する必要がありません。

WebLogicリソースのタイプ

図3-10 「WebLogicリソースのアーキテクチャ」に示したように、weblogic.security.serviceパッケージの特定のクラスはResourceBaseクラスの拡張であるため、WebLogicリソースの特定のタイプの実装を提供します。以下のWebLogicリソースの実装を使用できます。

- 管理リソース

- アプリケーション・リソース

- COMリソース

- コントロール・リソース

- EISリソース

- EJBリソース

- JDBCリソース

- JMSリソース

- JNDIリソース

- リモート・リソース

- サーバー・リソース

- URLリソース

- Webサービス・リソース

- ワーク・コンテキスト・リソース

注意:

これらの各WebLogicリソースの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』と、WebLogic Server APIリファレンスJavadocでweblogic.security.serviceパッケージを参照してください。

WebLogicリソース識別子

各WebLogicリソース(「WebLogicリソースのタイプ」を参照)は、そのtoString()表現か、またはgetID()メソッドを使用して取得したIDによって識別できます。

toString()メソッド

WebLogicリソースの実装のtoString()メソッドを使用すると、そのWebLogicリソースの説明がString形式で返されます。最初に、WebLogicリソースのタイプが不等号カッコ内に出力されます。次に、各キーとその値が順番に出力されます。これらのキーはカンマで区切られます。示される値はカンマで区切られ、中カッコで囲まれます。各値はそのまま出力されますが、カンマ(,)、開き中カッコ({)、閉じ中カッコ(})、およびバック・スラッシュ(\)はそれぞれバック・スラッシュでエスケープされます。たとえば、次のようなEJBリソースがあるとします。

EJBResource ('myApp",
'MyJarFile",
'myEJB",
'myMethod",
'Home",
new String[] {'argumentType1", 'argumentType2"}
);

このリソースは、以下のtoString出力を生成します。

type=<ejb>, app=myApp, module="MyJarFile", ejb=myEJB, method="myMethod",
methodInterface="Home", methodParams={argumentType1, argumentType2}

toString()メソッドによって提供されるWebLogicリソース記述の形式は公開されており(つまりResourceオブジェクトを使用せずに記述を作成でき)、逆変換できます(つまりこのString形式を元のWebLogicリソースに戻せます)。

注意:

例3-2に、toString()メソッドを使用してWebLogicリソースを識別する方法を示します。

リソースIDとgetID()メソッド

定義済みの各WebLogicリソース・タイプに定義されているgetID()メソッドは、セキュリティ・プロバイダでWebLogicリソースを一意に識別するために使用できる64ビット・ハッシュ・コードを返します。リソースIDは、以下のアルゴリズムを使用して、高速の実行時キャッシングに効果的に使用できます。

1. WebLogicリソースを取得します。

2. getIDメソッドを使用してWebLogicリソースのリソースIDを取得します。

3. キャッシュ内でそのリソースIDをルックアップします。

4. リソースIDが見つかれば、それに対応するセキュリティ・ポリシーを返します。

5. リソースIDが見つからなければ、以下を実行します。

1. toString()メソッドを使用して、セキュリティ・プロバイダ・データベース内でWebLogicリソースをルックアップします。

2. リソースIDとセキュリティ・ポリシーをキャッシュに格納します。

3. セキュリティ・ポリシーを返します。

注意:

例3-3に、認可プロバイダでgetID()メソッドを使用してWebLogicリソースを識別する方法と、そのアルゴリズムの実装例を示します。

このメソッドは何度実行しても同じ値を返すという保証はないので、このリソースIDを使用してセキュリティ・プロバイダ・データベースにWebLogicリソースに関する情報を格納しないようにしてください。かわりに、WebLogicリソースのtoString()メソッドを使用して、リソース対セキュリティ・ポリシーおよびリソース対セキュリティ・ロール・マッピングを、対応するセキュリティ・プロバイダ・データベースに格納するようにします。

注意:

セキュリティ・プロバイダ・データベースの詳細は、「セキュリティ・プロバイダ・データベースの初期化」を参照してください。toStringメソッドの詳細は、「toString()メソッド」を参照してください。

WebLogicリソースのデフォルト・グループの作成

カスタム認証プロバイダのランタイム・クラスを記述する場合は、デフォルト・グループをいくつか作成しておく必要があります。表3-8は、このタスクを行う場合に役立つ情報を示しています。

表3-8 デフォルト・グループとグループ・メンバーシップ

グループ名

グループ・メンバーシップ

Administrators

空、または管理ユーザー

Deployers

空

Monitors

空

Operators

空

AppTesters

空

OracleSystemGroup

OracleSystemUser

WebLogicリソースのデフォルト・セキュリティ・ロールの作成

カスタム・ロール・マッピング・プロバイダのランタイム・クラスを記述する場合は、デフォルト・グローバル・ロールをいくつか作成しておく必要があります。表3-9は、このタスクを行う場合に役立つ情報を示しています。

表3-9 デフォルト・グローバル・ロールとグループの関連付け

グローバル・ロール名

グループの関連付け

Admin

Administratorsグループ

AdminChannelUser

AdminChannelUsers、Administrators、Deployers、Operators、Monitors、およびAppTestersグループ

Anonymous

weblogic.security.WLSPrincipals.getEveryoneGroupname()グループ

CrossDomainConnector

CrossDomainConnectorsグループ

Deployer

Deployersグループ

Monitor

Monitorsグループ

Operator

Operatorsグループ

AppTester

AppTestersグループ

OracleSystemRole

OracleSystemGroup

注意:

グローバルおよびスコープ指定のセキュリティ・ロールの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

WebLogicリソースのデフォルト・セキュリティ・ポリシーの作成

カスタム認可プロバイダのランタイム・クラスを記述する場合は、デフォルト・セキュリティ・ポリシーをいくつか作成しておく必要があります。これらのデフォルト・セキュリティ・ポリシーで、初期状態から様々なタイプのWebLogicリソースを保護します。表3-10は、このタスクを行う場合に役立つ情報を示しています。

表3-10 WebLogicリソースのデフォルト・セキュリティ・ポリシー

WebLogicリソース・コンストラクタ

セキュリティ・ポリシー

new AdminResource(null, null, null)

Adminグローバル・ロール

new AdminResource("Configuration", null, null)

Admin、Deployer、Monitor、またはOperatorグローバル・ロール

new AdminResource('FileDownload", null, null)

AdminまたはDeployerグローバル・ロール

new AdminResource('FileUpload", null, null)

AdminまたはDeployerグローバル・ロール

New AdminResource('ViewLog", null, null)

AdminまたはDeployerグローバル・ロール

new ControlResource(null, null, null)

weblogic.security.WLSPrincipals.getEveryoneGroupname()グループ

new EISResource(null, null, null)

weblogic.security.WLSPrincipals.getEveryoneGroupname()グループ

new EJBResource(null, null, null, null, null, null)

weblogic.security.WLSPrincipals.getEveryoneGroupname()グループ

new JDBCResource(null, null, null, null, null)

weblogic.security.WLSPrincipals.getEveryoneGroupname()グループ

new JNDIResource(null, null, null)

weblogic.security.WLSPrincipals.getEveryoneGroupname()グループ

new JMSResource(null, null, null, null)

weblogic.security.WLSPrincipals.getEveryoneGroupname()グループ

new ServerResource(null, null, null)

AdminまたはOperatorグローバル・ロール

new URLResource(null, null, null, null, null)

weblogic.security.WLSPrincipals.getEveryoneGroupname()グループ

new WebServiceResource(null, null, null, null)

weblogic.security.WLSPrincipals.getEveryoneGroupname()グループ

new WorkContext(null, null)

weblogic.security.WLSPrincipals.getEveryoneGroupname()グループ

注意:

アプリケーションおよびCOMリソースにはデフォルト・セキュリティ・ポリシーを設定しないでください(つまり、デフォルトですべてのユーザーに権限を付与しないでください)。

セキュリティ・プロバイダのランタイム・クラスでのWebLogicリソースのルックアップ

例3-2に、認可プロバイダのランタイム・クラスでWebLogicリソースをルックアップする方法について示します。このアルゴリズムは、認可プロバイダのセキュリティ・プロバイダ・データベースにWebLogicリソースとセキュリティ・ポリシーのマッピングが格納されていることを前提にしています。例3-2に示すアルゴリズムの使用、つまりgetParentResourceメソッドの呼出しの使用は必須ではありません(getParentResourceメソッドの詳細については、「単一親リソース階層」を参照)。

例3-2 認可プロバイダでWebLogicリソースをルックアップする方法: toStringメソッドの使用

Policy findPolicy(Resource resource) {
Resource myResource = resource;
while (myResource != null) {
String resourceText = myResource.toString();
Policy policy = lookupInDB(resourceText);
if (policy != null) return policy;
myResource = myResource.getParentResource();
}
return null;
}

getIDメソッドを使用することで、WebLogicリソースのルックアップ・アルゴリズムを最適化できます(例3-2に示したようにtoStringメソッドだけを使用すると、文字列が頻繁に連結されるためパフォーマンスが低下する場合があります)。getIDメソッドはWebLogicリソース自身の内部で計算されキャッシュされるハッシュ処理なのでより高速で効率的です。このため、getIDメソッドを使用すると、toString値の計算リソースにつき一度だけで済みます(例3-3を参照)。

例3-3 認可プロバイダでWebLogicリソースをルックアップする方法: getIDメソッドの使用

Policy findPolicy(Resource resource) {
Resource myResource = resource;
while (myResource != null) {
long id = myResource.getID();
Policy policy = lookupInCache(id);
if (policy != null) return policy;
String resourceText = myResource.toString();
Policy policy = lookupInDB(resourceText);
if (policy != null) {
addToCache(id, policy);
return policy;
}
myResource = myResource.getParentResource();
}
return null;
}

注意:

getIDメソッドは、パッチ・セット間または将来のWebLogic Serverリリース間で保証されません。このため、getID値はセキュリティ・プロバイダ・データベースに格納しないでください。

単一親リソース階層

WebLogicリソースの粒度は自由に設定できます。たとえば、Webアプリケーション全体、そのWebアプリケーション内の特定のEnterprise JavaBean (EJB)、あるいはそのEJB内の単一のメソッドをWebLogicリソースと見なすことができます。

WebLogicリソースは、特殊性が最も高いものから最も低いものまでの階層構造に整理されます。各WebLogicリソース・タイプでは、getParentResourceメソッドを使用できます(必須ではありません)。

WebLogicセキュリティ・プロバイダは、次のように単一親リソース階層を使用します。WebLogicセキュリティ・プロバイダが特定のWebLogicリソースにアクセスしようとして、そのリソースが見つからない場合、WebLogicセキュリティ・プロバイダはそのリソースのgetParentResourceメソッドを呼び出します。このメソッドによって現在のWebLogicリソースの親リソースが返され、WebLogicセキュリティ・プロバイダはリソース階層を上って次の(特殊性のより低い)リソースを保護できるようになります。たとえば、呼出し側が以下のURLリソースにアクセスしようとしたとします。

type=<url>, application=myApp, contextPath="/mywebapp", uri=foo/bar/my.jsp

このURLリソースが見つからない場合、WebLogicセキュリティ・プロバイダは以下のリソースを検索して保護しようとします。順序は以下のとおりです。

type=<url>, application=myApp, contextPath="/mywebapp", uri=/foo/bar/*
type=<url>, application=myApp, contextPath="/mywebapp", uri=/foo/*
type=<url>, application=myApp, contextPath="/mywebapp", uri=*.jsp
type=<url>, application=myApp, contextPath="/mywebapp", uri=/*
type=<url>, application=myApp, contextPath="/mywebapp"
type=<url>, application=myApp
type=<app>, application=myApp
type=<url>

注意:

getParentResourceメソッドの詳細は、Oracle WebLogic Server APIリファレンスで、定義済のWebLogicリソース・タイプのいずれか、またはResourceインタフェースを参照してください。

URLリソースのパターン・マッチング

Javaサーブレット2.3仕様のSRV.11.1およびSRV.11.2節では、(http://jcp.org/aboutJava/communityprocess/first/jsr053/index.html)サーブレット・コンテナのパターン・マッチングのルールが説明されています。これらのルールは、URLリソースに対しても使用されます。以下の例では、URLリソースのパターン・マッチングに関するいくつかの重要な概念を示します。

例1

URLリソースtype=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/my.jsp, httpMethod=GETの場合、リソース階層は次のように使用されます(予想と異なっている可能性があるURLパターンが含まれる、3行目と4行目に注意)。

1. type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/my.jsp, httpMethod=GET

2. type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/my.jsp

3. type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/my.jsp/*, httpMethod=GET

4. type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/my.jsp/*

5. type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/*, httpMethod=GET

6. type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/*

7. type=<url>, application=myApp, contextPath=/mywebapp, uri=*.jsp, httpMethod=GET

8. type=<url>, application=myApp, contextPath=/mywebapp, uri=*.jsp

9. type=<url>, application=myApp, contextPath=/mywebapp, uri=/*, httpMethod=GET

10. type=<url>, application=myApp, contextPath=/mywebapp, uri=/*

11. type=<url>, application=myApp, contextPath=/mywebapptype=<url>, application=myApp

12. type=<app>, application=myApp

13. type=<url>

例2

URLリソースtype=<url>, application=myApp, contextPath=/mywebapp, uri=/fooの場合、リソース階層は次のように使用されます(予想と異なっている可能性があるURLパターンが含まれる、2行目に注意)。

1. type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo

2. type=<url>, application=myApp, contextPath=/mywebapp, uri=/foo/*

3. type=<url>, application=myApp, contextPath=/mywebapp, uri=/*

4. type=<url>, application=myApp, contextPath=/mywebapp

5. type=<url>, application=myApp

6. type=<app>, application=myApp

7. type=<url>

ContextHandlerとWebLogicリソース

ContextHandlerは、リソース・コンテナから追加のコンテキスト情報およびコンテナ固有の情報を取得し、その情報をアクセス決定やロール・マッピング決定を行うセキュリティ・プロバイダに渡す高性能なWebLogicクラスです。ContextHandlerインタフェースを使用すると、内部WebLogicリソース・コンテナでWebLogicセキュリティ・フレームワーク呼出しに追加情報を渡すことができます。その結果、セキュリティ・プロバイダは、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。ContextHandlerは本質的には名前と値のリストなので、セキュリティ・プロバイダは検索する名前を認識しておく必要があります。つまり、ContextHandlerの使用には、WebLogicリソース・コンテナとセキュリティ・プロバイダの間の緊密な連携が不可欠です。ContextHandlerの名前と値の各組み合わせは、コンテキスト要素と呼ばれ、ContextElementオブジェクトによって表されます。

注意:

ContextHandlerインタフェースおよびContextElementクラスの詳細は、WebLogic Server APIリファレンスJavadocでweblogic.security.serviceパッケージを参照してください。

リソース・タイプには様々なコンテキスト要素があり、その値をカスタム・プロバイダ開発の一部として検査できます。つまり、すべてのコンテナがすべてのコンテキスト要素を渡すとは限らないことになります。

表3-11に、利用できるContextHandlerエントリの一覧を示します。

表3-11 コンテキスト・ハンドラのエントリ

コンテキスト要素名

説明とタイプ

com.bea.contextelement.

servlet.HttpServletRequest

HTTPによるサーブレット・アクセス・リクエストまたはSOAPメッセージ。

javax.http.servlet.HttpServletRequest

com.bea.contextelement.

servlet.HttpServletResponse

HTTPによるサーブレット・アクセス・レスポンスまたはSOAPメッセージ。

javax.http.servlet.HttpServletResponse

com.bea.contextelement.

wli.Message

WebLogic Integrationメッセージ。メッセージは監査ログに送られます。

java.io.InputStream

com.bea.contextelement.

channel.Port

リクエストの受け付けまたは処理を行うネットワーク・チャネルの内部リスニング・ポート。

java.lang.Integer

com.bea.contextelement.

channel.PublicPort

リクエストの受け付けまたは処理を行うネットワーク・チャネルの外部リスニング・ポート。

java.lang.Integer

com.bea.contextelement.

channel.RemotePort

リクエストの受け付けまたは処理を行うネットワーク・チャネルのTCP/IP接続のリモート・エンドのポート。

java.lang.Integer

com.bea.contextelement.

channel.Protocol

リクエストの受け付けまたは処理を行うネットワーク・チャネルのリクエストを行うためのプロトコル。

java.lang.String

com.bea.contextelement.

channel.Address

リクエストの受け付けまたは処理を行うネットワーク・チャネルの内部リスニング・アドレス。

java.lang.String

com.bea.contextelement.

channel.PublicAddress

リクエストの受け付けまたは処理を行うネットワーク・チャネルの外部リスニング・アドレス。

java.lang.String

com.bea.contextelement.

channel.RemoteAddress

リクエストの受け付けまたは処理を行うネットワーク・チャネルのTCP/IP接続のリモート・アドレス。

java.lang.String

com.bea.contextelement.

channel.ChannelName

リクエストの受け付けまたは処理を行うネットワーク・チャネルの名前。

java.lang.String

com.bea.contextelement.

channel.Secure

SSLによるリクエストの受け付けまたは処理を行うネットワーク・チャネルかどうかを示します。

java.lang.Boolean

com.bea.contextelement.

ejb20.Parameter[1-N]

パラメータに基づくオブジェクト。

com.bea.contextelement.

wsee.SOAPMessage

javax.xml.rpc.handler.MessageContext

com.bea.contextelement.

entitlement.EAuxiliaryID

WebLogic Server内部プロセスによって使用されます。

weblogic.entitlement.expression.EAuxiliary

com.bea.contextelement.

security.ChainPrevalidatedBySSL

SSLフレームワークが証明書チェーンを検証しました。つまり、チェーン内の証明書が相互に適切に署名しており、チェーンが終了する証明書がサーバーの信頼性のあるCAの1つであり、チェーンが基本制約ルールに準拠していて、チェーン内の証明書が期限切れではありませんでした。

java.lang.Boolean

com.bea.contextelement.

xml.SecurityToken

このリリースのWebLogic Serverでは使用されません。

weblogic.xml.crypto.wss.provider.SecurityToken

com.bea.contextelement.

xml.SecurityTokenAssertion

このリリースのWebLogic Serverでは使用されません。

java.util.Map

com.bea.contextelement.

webservice.Integrity{id:XXXXX}

javax.security.auth.Subject

com.bea.contextelement.

saml.SSLClientCertificateChain

SSLクライアント証明書チェーンがSSL接続から取得され、sender-vouches SAMLアサーションが受信されました。

java.security.cert.X509Certificate[]

com.bea.contextelement.

saml.MessageSignerCertificate

Webサービス・メッセージに署名するための証明書。

java.security.cert.X509Certificate

com.bea.contextelement.

saml.subject.ConfirmationMethod

SAMLアサーションのタイプ(bearer、artifact、sender-vouches、holder-of-key)。

java.lang.String

com.bea.contextelement.

saml.subject.dom.KeyInfo

holder-of-key SAMLアサーションでのサブジェクト確認のために使用される<ds:KeyInfo>要素。

org.w3c.dom.Element

例3-4では、URL (Web)リソースのContextHandlerを介して、HttpServletRequestおよびHttpServletResponseコンテキスト要素オブジェクトにアクセスする方法を示します。このコードはたとえば、AccessDecision SSPI実装のisAccessAllowed()メソッドで使用できます(詳細については、「AccessDecision SSPIの実装」を参照)。

例3-4 例: URLリソースContextHandlerでのコンテキスト要素へのアクセス

static final String SERVLETREQUESTNAME = 'com.bea.contextelement.servlet.HttpServletRequest";
if (resource instanceof URLResource) {
HttpServletRequest req =
(HttpServletRequest)handler.getValue(SERVLETREQUESTNAME);
}

注意:

RoleMapper SSPI実装のgetRoles()メソッドや、AuditContextインタフェース実装のgetContext()メソッドでこれらのコンテキスト要素にアクセスすることもできます。(詳細については、それぞれ「RoleMapper SSPIの実装」と「監査コンテキスト」を参照してください)。

コンテキスト・ハンドラをサポートするプロバイダとインタフェース

ContextHandlerインタフェースを使用すると、WebLogicセキュリティ・フレームワーク呼出しに追加情報を渡すことができます。その結果、セキュリティ・プロバイダまたはインタフェースで、特定のメソッドの引数で提供される以上のコンテキスト情報を取得できるようになります。

表3-12に、コンテキスト・ハンドラのサポートについて示します。

表3-12 コンテキスト・ハンドラがサポートされるメソッドとクラス

メソッド

説明

AccessDecision.isAccessAllowed()

isAccessAllowed()メソッドはContextHandlerオブジェクトを受け取り、これを必要に応じてアクセス決定で使用して、認可判定に使用可能な追加情報が取得されます。呼出し側で追加情報を提供できない場合、null値が指定されます。

AdjudicatorV2.adjudicate()

AdjudicatorV2 SSPIインタフェースの実装は裁決プロバイダの一部であり、すべてのアクセス決定のisAccessAllowedメソッドが正常に(例外をスローせずに)呼び出されて返された後で呼び出されます。AdjudicatorV2 SSPIは別の引数でリソースとContextHandlerを受け取ります。AuthorizationManagerが裁決プロバイダを呼び出すときに、AccessDecisionに渡されたのと同じリソースおよびContextHandlerが渡されます。このようにして、裁決プロバイダでAccessDecisionに利用できるすべての情報が入手されます。

AuditAtnEventV2.getContext()

JAAS LoginModule.login()メソッドとIdentityAsserter.assertIdentity()メソッドはContextHandlerにアクセスでき、AuditAtnEventV2インタフェースでもこのデータを取得できるので関連情報を監査できます。getContext()メソッドはweblogic.security.spi.AuditContextから継承されます。getContext()ではContextHandlerオブジェクトを取得し、ContextHandlerオブジェクトから付加的な監査情報を取得できます。

AuditCertPathBuilderEvent.getContext()、AuditCertPathValidatorEvent.getContext()

getContextメソッドでは必要に応じてContextHandlerオブジェクトを取得でき、ContextHandlerオブジェクトによって証明書パスのルックアップと検証の方法に関する付加的なデータが指定されます。

AuditConfigurationEvent.getContext()

AuditConfigurationEvent.getContext()メソッドではContextHandlerオブジェクトを取得し、ContextHandlerオブジェクトから付加的な監査情報を取得できます。

AuditContext.getContext()

AuditContext.getContext()メソッドではContextHandlerオブジェクトを取得し、ContextHandlerオブジェクトから付加的な監査情報を取得できます。

AuditCredentialMappingEvent.getContext()

getContextメソッドは必要に応じてContextHandlerオブジェクトを取得でき、ContextHandlerオブジェクトによって資格証明マッピングの監査イベントに関する付加的なデータが指定されます。

CertPathBuilderParameterSpi.getContextおよびCertPathValidatorParameterSpi.getContext

CertPathBuilderParameterSpiおよびCertPathValidatorParameterSpiインタフェースにはgetContext()メソッドがあり、このメソッドでContextHandlerを取得できます。ContextHandlerにより特別なパラメータで証明書パスの構築および検証に使用できる情報が渡されます。

ChallengeIdentityAsserterV2.assertChallengeIdentity()、ChallengeIdentityAsserterV2.continueChallengeIdentity()、およびChallengeIdentityAsserterV2.getChallengeIdentity()

ChallengeIdentityAsserterV2のメソッド群ではContextHandlerオブジェクトを受け取り、これは必要に応じてIDアサーション・プロバイダでチャレンジIDのアサーション用の追加情報の取得に使用できます。

CredentialMapperV2.getCredentials()

CredentialMapper.getCredentials()およびCredentialMapper.getCredential()メソッドには、任意の特別なデータが指定されるContextHandlerパラメータがあります。

IdentityAsserterV2.assertIdentity()

IdentityAsserterV2プロバイダを使用するとセキュリティ・フレームワークでassertIdentityメソッドにContextHandlerを渡すことが可能になります。ContextHandlerオブジェクトは必要に応じて、IDアサーションで使用する付加的な情報の取得に使用できます。ContextHandlerを使用すると、たとえばユーザーがHttpServletRequestから特別な情報を抽出したり、HttpServletResponseにCookieを設定したりできるようになります。

LoginModule.login()

ContextHandlerはJAAS CallbackHandlerパラメータに渡すことができます。CallbackHandlerは可変引数のデータ構造で、login()メソッドに渡されます。この方法でContextHandlerを追加すると、たとえばユーザーがHttpServletRequestから特別な情報を抽出したり、HttpServletResponseにCookieを設定したりできるようになります。この実装には、認証とIDアサーションの両方に使用されるLoginModule群が含まれます。

EJBおよびサーブレット・コンテナでは、Principal Authenticatorを呼び出す際にCallbackHandlerへContextHandlerを追加する必要があります。具体的には、weblogic.security.auth.callback.ContextHandlerCallbackをインスタンス化してCallbackHandlerのinvokeCallbackメソッドに渡し、このセキュリティ操作に関連するContextHandlerを取得する必要があります。この操作に関連付けられているContextHandlerがない場合、javax.security.auth.callback.UnsupportedCallbackExceptionがスローされます。

RoleMapper.getRoles()

getRoles()メソッドはContextHandlerオブジェクトを受け取り、これは必要に応じてロール・マッピング・プロバイダで認可判定に使用可能な追加情報の取得に使用されます。呼出し側で追加情報を提供できない場合、null値が指定されます。

URLCallbackHandlerおよびSimpleCallbackHandlerクラス

WebLogic Serverバージョン9.0以降では、weblogic.security.URLCallbackHandlerクラスおよびweblogic.security.SimpleCallbackHandlerクラスが更新されてContextHandlerを扱えるようになっています。

URLCallbackHandlerはアプリケーション開発者が認証APIの一部としてユーザー名、パスワード、URL、およびContextHandlerを返すために使用するCallbackHandler。

SimpleCallbackHandlerはアプリケーション開発者が認証APIの一部としてユーザー名、パスワード、およびContextHandlerを返すために使用する単純なCallbackHandler。

セキュリティ・プロバイダ・データベースの初期化

注意:

この項を読む前に、『Oracle WebLogic Serverのセキュリティの理解』のセキュリティ・プロバイダ・データベースに関する項に目を通しておいてください。

セキュリティ・プロバイダ・データベースは、少なくとも、認証、認可、ロール・マッピング、および資格証明マッピングの各プロバイダで必要なデフォルトのユーザー、グループ、セキュリティ・ポリシー、セキュリティ・ロール、または資格証明で初期化する必要があります。セキュリティ・プロバイダが使用可能になる前に、所定のセキュリティ・プロバイダのデータベースを初期化する必要があります。また、カスタム・セキュリティ・プロバイダのランタイム・クラスを記述する際に、データベースの機能を考慮する必要があります。セキュリティ・プロバイダのデータベースの初期化に使用する方法は、ユーザー、グループ、セキュリティ・ポリシー、セキュリティ・ロール、または資格証明情報の格納に外部管理のデータベースを使用するかどうか、およびデータベースがすでに存在するのか作成する必要があるのかなど、多くの要因に左右されます。

以下の節では、セキュリティ・プロバイダ・データベースを初期化するためのベスト・プラクティスについて説明します。

- ベスト・プラクティス:データベースがない場合のシンプルなデータベースの作成

- ベスト・プラクティス:既存のデータベースの構成

- ベスト・プラクティス:データベース初期化の委託

- ベスト・プラクティス: JDBC接続セキュリティ・サービスAPIを使用したデータベース接続の取得

ベスト・プラクティス:データベースがない場合のシンプルなデータベースの作成

認証プロバイダ、認可プロバイダ、ロール・マッピング・プロバイダ、または資格証明マッピング・プロバイダは、それが初めて使用されるときには、セキュリティ・サービスを提供するために必要な情報のあるデータベースを見つけようとします。セキュリティ・プロバイダがデータベースを見つけられない場合は、セキュリティ・プロバイダにデータベースを作成させて、デフォルトのユーザー、グループ、セキュリティ・ポリシー、セキュリティ・ロール、および資格証明を自動的に格納することができます。このオプションは、開発およびテストに便利です。

WebLogicセキュリティ・プロバイダとサンプル・セキュリティ・プロバイダは両方ともこのプラクティスに従います。WebLogicの認証プロバイダ、認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダは、ユーザー、グループ、セキュリティ・ポリシー、セキュリティ・ロール、および資格証明の情報を組込みLDAPサーバーに格納します。これらのWebLogicセキュリティ・プロバイダのいずれかを使用する場合は、『Oracle WebLogic Serverの保護』の組込みLDAPサーバーの構成に関する項で説明されている指示に従う必要があります。

注意:

サンプル・セキュリティ・プロバイダは、プロパティ・ファイルを作成し、それらのデータベースとして使用します。たとえば、サンプル認証プロバイダでは、ユーザーおよびグループについての必要な情報が格納されるSampleAuthenticatorDatabase.javaというファイルが作成されます。

ベスト・プラクティス:既存のデータベースの構成

外部LDAPサーバーなどのデータベースがすでにある場合は、認証プロバイダ、認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダが必要とするユーザー、グループ、セキュリティ・ポリシー、セキュリティ・ロール、および資格証明の情報をそのデータベースに格納できます。既存のデータベースへの情報の格納は、それを目的としてすでに用意されているどのようなツールを使用しても行うことができます。

データベースに必要な情報が格納されたら、そのデータベースを参照するようにセキュリティ・プロバイダを構成する必要があります。そのためには、セキュリティ・プロバイダのMBean定義ファイル(MDF)でカスタム属性を追加します。カスタム属性の例には、データベースのホスト、ポート、パスワードなどがあります。WebLogic MBeanMakerを通じてMDFを実行し、さらにいくつかの手順を行ってカスタム・セキュリティ・プロバイダのMBeanタイプを生成したら、WebLogic Server管理コンソールを使用してそれらの属性がデータベースを指すように設定します。

注意:

MDF、MBeanタイプ、およびWebLogic MBeanMakerの詳細は、「カスタム・セキュリティ・プロバイダを構成および管理するMBeanタイプの生成」を参照してください。

例3-5に、WebLogic LDAP認証プロバイダのMDFに属する一部のカスタム属性を例として示します。これらの属性を使用することにより、WebLogic LDAP認証プロバイダのデータベース(外部LDAPサーバー)についての情報を指定することができるので、プロバイダでユーザーおよびグループについての情報を見つけることができます。

例3-5 LDAPAuthenticator.xml

...
<MBeanAttribute
Name = "UserObjectClass"
Type = "java.lang.String"
Default = "&quot;person&quot;"
Description = "The LDAP object class that stores users."
/>
<MBeanAttribute
Name = "UserNameAttribute"
Type = "java.lang.String"
Default = "&quot;uid&quot;"
Description = "The attribute of an LDAP user object that specifies the name of
the user."
/>
<MBeanAttribute
Name = "UserDynamicGroupDNAttribute"
Type = "java.lang.String"
Description = "The attribute of an LDAP user object that specifies the
distinguished names (DNs) of dynamic groups to which this user belongs.
If such an attribute does not exist, WebLogic Server determines if a
user is a member of a group by evaluating the URLs on the dynamic group.
If a group contains other groups, WebLogic Server evaluates the URLs on
any of the descendents of the group."
/>
<MBeanAttribute
Name = "UserBaseDN"
Type = "java.lang.String"
Default = "&quot;ou=people, o=example.com&quot;"
Description = "The base distinguished name (DN) of the tree in the LDAP directory
that contains users."
/>
<MBeanAttribute
Name = "UserSearchScope"
Type = "java.lang.String"
Default = "&quot;subtree&quot;"
LegalValues = "subtree,onelevel"
Description = "Specifies how deep in the LDAP directory tree to search for Users.
Valid values are &lt;code&gt;subtree&lt;/code&gt;
and &lt;code&gt;onelevel&lt;/code&gt;."
/>
...

ベスト・プラクティス:データベース初期化の委託

可能な限り、セキュリティ・プロバイダとセキュリティ・プロバイダ・データベースの間の初期化呼出しは、データベース・デリゲータという中間クラスを介して行う必要があります。データベース・デリゲータは、図3-11で示されているようにセキュリティ・プロバイダのランタイム・クラスおよびMBeanタイプと対話する必要があります。

図3-11 データベース・デリゲータ・クラスの配置

「図3-11 データベース・デリゲータ・クラスの配置」の説明

データベース・デリゲータは、WebLogicの認証プロバイダと資格証明マッピング・プロバイダで使用されます。たとえば、WebLogic認証プロバイダはデータベース・デリゲータに働きかけてデフォルトのユーザーおよびグループで組込みLDAPサーバーを初期化します。デフォルトのユーザーおよびグループは、デフォルト・セキュリティ・レルムの認証サービスを提供するために必要な情報です。

カスタム・セキュリティ・プロバイダを開発するアプリケーション開発者およびセキュリティ・ベンダーは、データベース・デリゲータを使用することをお薦めします。データベース・デリゲータを使用すると、セキュリティ・プロバイダのデータベースが隠蔽され、データベースへの呼出しが一元化されるメリットがあります。

ベスト・プラクティス: JDBC接続セキュリティ・サービスAPIを使用したデータベース接続の取得

カスタム・セキュリティ・プロバイダのデータベースを作成または構成する際のベスト・プラクティスに代わる方法として、プロバイダの初期化中にのみJDBCConnectionService SSPIを使用し、WebLogicドメインに対して構成されているJDBCデータ・ソースにアクセスすることができます。

この機能を使用すると、カスタム・セキュリティ・プロバイダは、JDBCデータ・ソース(マルチ・データ・ソースを含む)を通じて提供されるデータベース・アクセス管理およびデータベース接続管理のあらゆる機能を利用できます。SQL文の実行方法と接続のコンテキスト内で結果を戻す方法については、http://download.oracle.com/javase/1.5.0/docs/api/java/sql/Connection.htmlを参照してください。

JDBCConnectionService SSPIを使用する際は、次の点に注意してください。

- JDBCConnectionServiceは、カスタム・プロバイダの initialize()メソッドで取得します。

- データ・ソースは、JNDIパスではなく、名前(sqlConnectionName)で識別されます。

- 初期化中はJDBCリソースを利用できないことがあります。JNDIおよびJDBCサブシステムが完全に初期化され、利用可能になるまでは、直接接続が戻されます。

- JDBCデータ・ソースから戻されたデータベース接続を使用し終わったら、セキュリティ・プロバイダはreleaseConnectionメソッドを呼び出し、(Connectionオブジェクトを指定して、)接続を解放する必要があります。

例3-6は、JDBCConnectionService SSPIを使用して、指定したJDBCデータ・ソースからデータベース接続を取得する方法を示しています。

例には示されていませんが、JDBCConnectionService.getConnectionは、指定したJDBCデータ・ソースが利用できない場合にJDBCConnectionServiceExceptionを、データベース接続が利用できない場合にSQLExceptionをスローする可能性があります。JDBCConnectionService.releaseConnectionは、データベース接続が利用できない場合にSQLExceptionをスローする可能性があります。

例3-6 JDBCConnectionService APIを使用したJDBCデータ・ソースへのアクセス

JDBCConnectionService dbService = null;
if (services instanceof SecurityServicesJDBC) {
try {

dbService = ((SecurityServicesJDBC)services).getJDBCConnectionService();

System.out.println("Obtained the JDBCConnectionService, " + dbService);

Connection conn = dbService.getConnection("oracle-database");

PreparedStatement statement = conn.prepareStatement("select sysdate from dual");
ResultSet rs= statement.executeQuery();

while (rs.next()) {
String s1 = rs.getString(1);
System.out.println("Sys date =" + s1);
}

dbService.releaseConnection(conn);
} catch(Exception e) {
e.printStackTrace();
}

JDBC接続セキュリティ・サービスの実装: 主な手順

JDBCデータ・ソースへのアクセスを取得するためにセキュリティ・サービスを実装するには、次の手順に従います。

1. プロバイダのinitialize()メソッドで、SecurityServicesJDBCインタフェースのgetJDBCConnectionServiceメソッドを呼び出して、JDBC接続サービスを取得します。

2. JDBC接続サービス・インスタンスに対してgetConnectionメソッドを呼び出し、WebLogicドメインで構成されているJDBCデータ・ソースの名前を渡します。

3. 適切なデータベース・コマンド(プリコンパイルされた文や問合せなど)を追加します。

4. 接続インスタンスを解放するには、JDBC接続サービス・インスタンスに対してreleaseConnectionメソッドを呼び出す必要があります。

属性バリデータの相違点

バリデータは、様々な種類の式を検証できるクラスによって実装されるインタフェースです。このリリースのWebLogic Serverでは、セキュリティ・プロバイダの属性バリデータ・メソッドの継承ルールが、8.1のルールとは異なっています。

8.1で属性バリデータを有効にする場合、派生したMBeanは、MBean実装ファイルでその属性バリデータのメソッドをカスタマイズするだけで済みました。バージョン9.0以降で属性バリデータを有効にする場合、派生したMBeanは、メソッドをカスタマイズするだけでなく、MDFファイルでその属性バリデータを明示的に宣言する必要もあります。明示的に宣言しなかった場合、カスタマイズされたメソッドのコードは無視されます。

以下の例では、すべてのIDアサーションMBean実装のベース・クラスweblogic.management.security.authentication.IdentityAsserterImplを示します。

IdentityAsserterImplは、認証プロバイダMBean実装を拡張し、認証プロバイダのMBean実装が構成属性にアクセスできるようにします。

8.1では、次の手順で可能になります。

1. IdentityAsserter1というIDアサーション・プロバイダを作成します。MDFファイルで、このプロバイダがweblogic.management.security.authentication.IdentityAsserterを拡張するように指定します。

2. MBeanタイプの生成するには、WebLogic MBeanMakerを使用します。MBeanMakerで生成された実装ファイルは通常、IdentityAsserter1Impl.javaという名前になります。これは、weblogic.management.security.authentication.IdentityAsserterImplを拡張します。
そのため、MBeanは、属性バリデータ・メソッドを持つactiveTypes属性を継承します。validateActiveTypes (String[] activeTypes)メソッドにより、サポートされているタイプのみがactiveTypesに含まれます。

3. 実装ファイルを変更し、validateActiveTypesメソッドの別の実装を指定します。たとえば、アクティブなタイプをさらに制限したり、ルールを緩めたりすることができます。

4. 8.1では、IdentityAsserter1のvalidateActiveTypes実装が使用されます。
バージョン9.0以降では、基本IdentityAsserterのvalidateActiveTypes実装がかわりに使用されます。つまり、IdentityAsserter1のvalidateActiveTypes実装は、通知なしで無視されます。

バージョン9.0以降でのこの違いに対処するには、IdentityAsserter1のMDFファイルのMBeanOperationサブ要素で属性バリデータを再宣言します。

カスタム・バリデータの場合の属性バリデータの相違点

セキュリティ・プロバイダの属性バリデータの継承ルールの相違点は、カスタム・バリデータにも適用されます。プロバイダに、カスタム・バリデータを持つ属性を宣言させることができます。そのプロバイダから別のプロバイダを派生させ、バリデータの別の実装を記述できます。8.1では、派生したプロバイダのバリデータが使用されます。バージョン9.0以降では、基本プロバイダのバリデータがかわりに使用され、派生したバリデータは通知なしで無視されます。

4 認証プロバイダ

この章では、認証プロバイダの概念と機能、およびカスタム認証プロバイダの開発手順について説明します。

認証は、呼出し側が、特定のユーザーまたはシステムのかわりに動作していることを証明する際に使用するメカニズムです。認証は、ユーザー名とパスワードの組合せなどの資格証明を使用して「あなたは誰」という問いに答えます。

WebLogic Serverでは、ユーザーまたはシステム・プロセスのIDを証明するために認証プロバイダを使用します。認証プロバイダでは、ID情報を記憶したり、トランスポートしたり、その情報が必要な場合にサブジェクトを通じてシステムの様々なコンポーネントで利用できるようにしたりします。認証プロセスでは、プリンシパル検証プロバイダが、サブジェクト内に格納されるプリンシパル(ユーザーおよびグループ)のセキュリティを強化するため、それらのプリンシパルに署名して信頼性を検証します。(詳細については、第6章「プリンシパル検証プロバイダ」を参照してください。)

以下の節では、認証プロバイダの概念と機能、およびカスタム認証プロバイダの開発手順について説明します。

- 認証の概念

- 認証プロセス

- カスタム認証プロバイダを開発する必要があるか

- カスタム認証プロバイダの開発方法

注意:

IDアサーション・プロバイダは、ユーザーまたはシステム・プロセスがトークンを使用してそれぞれのIDを証明する特殊な形態の認証プロバイダです。詳細については、第5章「IDアサーション・プロバイダ」を参照してください。

認証の概念

カスタム認証プロバイダの開発の詳細に立ち入る前に、以下の概念を理解しておくことが大切です。

- ユーザー/グループ、プリンシパル、サブジェクト

- LoginModules

- Java Authentication and Authorization Service (JAAS)

ユーザー/グループ、プリンシパル、サブジェクト

ユーザーは、人を表すという点でオペレーティング・システムのユーザーに似ています。一方、グループはユーザーのカテゴリで、肩書きなどの共通の特徴で分類されたものです。ユーザーをグループに分類すると、多数のユーザーに対するアクセス許可を管理しやすくなります。ユーザーおよびグループの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

WebLogic Serverのようなアプリケーション・サーバーでは、ユーザーもグループもプリンシパルとして使用することができます。プリンシパルは、認証の結果としてユーザーまたはグループに割り当てられるIDです。JAAS (Java Authentication and Authorization Service)では、プリンシパルなどの認証情報のコンテナとしてサブジェクトを使用することになっています。同じサブジェクト内に格納されている各プリンシパルは、ある人の財布に入っている複数のカードのように、同じユーザーのIDを異なる観点で表しています。たとえば、持ち主の身元を銀行に示すためにATMカードがあり、所属する組織に示すためにメンバーシップ・カードがある、という具合です。JAASの詳細は、「Java Authentication and Authorization Service (JAAS)」を参照してください。

注意:

サブジェクトは、WebLogic Server 6.xのユーザーに取ってかわるものです。

図4-1に、ユーザー、グループ、プリンシパル、およびサブジェクト間の関係を示します。

図4-1 ユーザー、グループ、プリンシパル、およびサブジェクト間の関係

「図4-1 ユーザー、グループ、プリンシパル、およびサブジェクト間の関係」の説明

認証に成功すると、その一環として、プリンシパルは署名され、その後の使用に備えてサブジェクトに格納されます。プリンシパルに署名するのはプリンシパル検証プロバイダであり、実際にプリンシパルをサブジェクトに格納するのはLoginModuleです。後で、サブジェクト内に格納されたプリンシパルに呼出し側がアクセスしようとすると、そのプリンシパルが署名されてから変更されていないことをプリンシパル検証プロバイダが確認したうえで、そのプリンシパルが呼出し側に返されます(それ以外のセキュリティ条件がすべて満たされている場合)。

注意:

プリンシパル検証プロバイダとLoginModuleの詳細は、それぞれ第6章「プリンシパル検証プロバイダ」と「LoginModule」を参照してください。

WebLogic Serverユーザーまたはグループを表すプリンシパルは、weblogic.security.spiパッケージのWLSUserインタフェースとWLSGroupインタフェースを実装する必要があります。

初期ユーザーおよびグループの指定

認証プロバイダでは、実行中のWebLogic Serverで認証を実行する前にユーザーとグループのリストが必要です。一部の認証プロバイダを使用すると、管理者は外部データベースを構成し(LDAPサーバーまたはDBMSにユーザーおよびグループを追加するなど)、そのデータベースを使用するようにプロバイダを構成できます。管理者が外部データベースのツールを使用してユーザーとグループをあらかじめ指定するので、これらのプロバイダはどのようにユーザーとグループが指定されたかを認識する必要はありません。

ただし、一部の認証プロバイダは、独自のユーザーとグループのリストを作成および管理します。ManageableSampleAuthenticatorプロバイダがそれに当てはまります。この場合、認証プロバイダは、ユーザーとグループの初期セットがどのように指定されたかを認識する必要があります。これを行う方法としては、プロバイダの初期化メソッドで、ユーザーとグループがまだないことを通知し、ユーザーとグループの初期セットを指定してリストを作成するというものがあります。

一部のプロバイダは、セキュリティ・レルムごとにユーザーとグループの個別のリストを持っているので、新しいレルムで最初にリストを使用する場合に、ユーザーとグループの初期セットを作成する必要があります。たとえば、ManageableSampleAuthenticatorプロバイダは、ユーザーとグループの個別のプロパティ・ファイルをレルムごとに作成します。この認証プロバイダのinitializeメソッドは、レルム名を取得して、そのレルムのプロパティ・ファイルが存在するかどうかを判別し、存在しない場合は、ユーザーとグループの初期セットでプロパティ・ファイルを作成します。

LoginModule

LoginModuleは、認証プロバイダの必須コンポーネントであり、境界認証用に別個のLoginModuleを開発する必要がある場合はIDアサーション・プロバイダのコンポーネントにもなります。

LoginModuleは、認証処理における「馬車馬」のような存在です。すべてのLoginModuleは、セキュリティ・レルム内のユーザーの認証と、サブジェクト内への必要なプリンシパル(ユーザー/グループ)の格納を担当します。境界認証に使用されないLoginModuleも、提示された証明情報(たとえば、ユーザーのパスワード)が正しいかどうかを確認します。

注意:

IDアサーション・プロバイダと境界認証の詳細は、第5章「IDアサーション・プロバイダ」を参照してください。

セキュリティ・レルムに複数の認証プロバイダが構成されている場合、各認証プロバイダのLoginModuleは同じサブジェクトにプリンシパルを格納します。したがって、ある認証プロバイダのLoginModuleによって、WebLogic Serverユーザー(WLSUserインタフェースの実装)を表すプリンシパル「Joe」が追加された場合、セキュリティ・レルム内の他のすべての認証プロバイダは、「Joe」に出会ったときに同じ人物を参照する必要があります。つまり、他の認証プロバイダのLoginModuleは、同じ人物を参照するために、WebLogic Serverユーザーを表す別のプリンシパル(「Joseph」など)をサブジェクトに追加しようとしてはなりません。ただし、別の認証プロバイダのLoginModuleは、WLSUser以外のタイプのプリンシパルを「Joseph」という名前で追加することができます。

LoginModuleインタフェース

LoginModuleは、ユーザー名とパスワードの組合せ、スマート・カード、バイオメトリック装置などの様々な認証メカニズムを扱うように作成することができます。LoginModuleを開発するには、JAAS (Java Authentication and Authorization Service)に基づき、認証情報のコンテナとしてサブジェクトを使用するjavax.security.auth.spi.LoginModuleインタフェースを実装します。LoginModuleインタフェースを使用すると、単一アプリケーション用に様々な種類の認証技術をプラグインすることができ、WebLogicセキュリティ・フレームワークはマルチパート認証用に複数のLoginModule実装をサポートするように設計されています。さらに、LoginModuleインスタンス間に依存関係を設けたり、それらのインスタンス間で資格証明を共有することもできます。ただし、LoginModuleと認証プロバイダの関係は1対1です。つまり、網膜スキャン認証を扱うLoginModuleと、スマート・カードのようなハードウェア・デバイスとのインタフェースを取るLoginModuleを用意するには、それぞれにLoginModuleインタフェースの実装が含まれる2つの認証プロバイダを開発して構成する必要があります。詳細については、「JAAS LoginModuleインタフェースの実装」を参照してください。

注意:

LoginModuleは、独自に開発するのではなくサード・パーティのセキュリティ・ベンダーから入手することもできます。

LoginModuleとマルチパート認証

複数の認証プロバイダ(その結果として複数のLoginModule)を構成する方法は、認証プロセスの全体的な結果に影響します。これは、さまざまな要素から成る認証で特に重要です。まず、LoginModuleは認証プロバイダのコンポーネントであるため、認証プロバイダが構成された順序で呼び出されます。通常、認証プロバイダの構成には、WebLogic Server管理コンソールを使用します。(詳細については、「認証プロバイダの順序の指定」を参照)次に、各LoginModuleの制御フラグがどのように設定されるかによって、認証プロセスでのエラーの処理方法が決まります。図4-2は、それぞれ別の認証プロバイダに属する3つのLoginModuleが関わるサンプル・フローを示すとともに、様々な認証結果でサブジェクトに何が起こるのかを示しています。

図4-2 LoginModuleのサンプル・フロー

「図4-2 LoginModuleのサンプル・フロー」の説明

カスタム認証プロバイダ#1の制御フラグがREQUIREDに設定されていた場合、ユーザー認証ステップで認証が失敗すると、認証プロセス全体が失敗します。また、ユーザーがWebLogic認証プロバイダ(またはカスタム認証プロバイダ#2)によって認証されなかった場合、認証プロセス全体が失敗します。認証プロセスがこのように失敗した場合、3つのLoginModuleすべてがロールバックされ、サブジェクトにプリンシパルが格納されません。

注意:

LoginModule制御フラグの設定とLoginModuleインタフェースの詳細は、『Java Authentication and Authorization Service (JAAS) 1.0 LoginModule Developer's Guide』(http://download.oracle.com/javase/6/docs/technotes/guides/security/)およびJava SE 6.0 API仕様のLoginModuleインタフェース(http://download.oracle.com/javase/6/docs/api/javax/security/auth/spi/LoginModule.html)をそれぞれ参照してください。

JAAS (Java Authentication and Authorization Service)

クライアントが認証の必要なアプリケーション、アプレット、Enterprise JavaBean (EJB)、あるいはサーブレットのいずれであろうと、WebLogic Serverでは、JAAS (Java Authentication and Authorization Service)クラスを用いて、信頼性とセキュリティを確保しつつクライアントに対する認証を行います。JAASは、プラガブルな認証モジュール(PAM)フレームワークのJavaバージョンを実装します。このフレームワークにより、アプリケーションは基底の認証技術から独立することができます。このため、PAMフレームワークを利用することで、アプリケーションに修正を加えることなく新しいまたは更新された認証技術を使用することができます。

WebLogic Serverは、リモートのファット・クライアントの認証および内部の認証でJAASを使用します。したがって、JAASに直に関与する必要があるのは、カスタム認証プロバイダの開発者とリモート・ファット・クライアント・アプリケーションの開発者だけです。シン・クライアントのユーザーまたはコンテナ内のファット・クライアント・アプリケーション(サーブレットからEnterprise JavaBeanを呼び出すものなど)の開発者は、JAASを直接使用したり、その知識を身につけたりする必要はありません。

JAASがWebLogicセキュリティ・フレームワークとどう連携するか

通常、JAASクラスとWebLogicセキュリティ・フレームワークを用いた認証は、以下のように実行されます:

1. クライアント側アプリケーションがユーザーまたはシステム・プロセスから認証情報を取得します。このときのメカニズムは、クライアントのタイプごとに異なります。

2. クライアント側アプリケーションでは、認証情報が格納されたCallbackHandlerを任意に作成できます。

1. クライアント側アプリケーションは、LoginContextクラスを使用してCallbackHandlerをローカル(クライアント側) LoginModuleに渡します。ローカルLoginModuleは、WebLogic Serverの一部として提供されているUsernamePasswordLoginModuleの場合があります。

2. ローカルLoginModuleは、認証情報が格納されたCallbackHandlerを適切なWebLogic Serverコンテナ(RMI、EJB、サーブレット、IIOPなど)に渡します。

注意:

CallbackHandlerは、可変個の引数を複合オブジェクトとしてメソッドに渡すことができるようにする高度に柔軟なJAAS規格です。CallbackHandlerのタイプは、NameCallback、PasswordCallback、およびTextInputCallbackの3つで、いずれもjavax.security.auth.callbackパッケージに収められています。NameCallbackとPasswordCallbackは、それぞれユーザー名とパスワードを返します。TextInputCallbackは、ユーザーがログイン・フォームの追加フィールド(ユーザー名とパスワードを取得するフィールド以外のフィールド)に入力したデータにアクセスするために使用します。TextInputCallbackはフォームの追加フィールドにつき1つ必要で、各TextInputCallbackのプロンプト文字列はフォームのフィールド名と一致する必要があります。WebLogic Serverは、フォームベースのWebアプリケーション・ログインに対してのみTextInputCallbackを使用します。CallbackHandlerの詳細は、Java SE 6.0 API仕様のCallbackHandlerインタフェース(http://download.oracle.com/javase/6/docs/api/javax/security/auth/callback/CallbackHandler.html)を参照してください。

LoginContextクラスの詳細は、Java SE 6.0 API仕様のLoginContextクラス(http://download.oracle.com/javase/6/docs/api/javax/security/auth/spi/LoginModule.html)を参照してください。

UsernamePasswordLoginModuleの詳細は、WebLogic Server APIリファレンスJavadocのUsernamePasswordLoginModuleクラスを参照してください。

クライアント側LoginModuleを使用しない場合、ユーザー名とパスワードを他の方法で(たとえば初期JNDIルックアップの一部として)指定できます。

3. WebLogic Serverコンテナは、WebLogicセキュリティ・フレームワークに働きかけを行います。認証情報が格納されたクライアント側CallbackHandlerが存在する場合、それがWebLogicセキュリティ・フレームワークに渡されます。

4. WebLogicセキュリティ・フレームワークにより、渡された認証情報を使用して、構成されている認証プロバイダごとにCallbackHandlerが作成されます。これらはWebLogicセキュリティ・フレームワークによってサーバー側に作成された内部的なCallbackHandlerであり、クライアントのCallbackHandlerとは関係ありません。

5. WebLogicセキュリティ・フレームワークは、認証プロバイダに関連付けられたLoginModule (認証情報を処理するために指定された特定のLoginModule)を呼び出します。

注意:

LoginModuleの詳細は、「LoginModule」を参照してください。

LoginModuleが認証情報を利用してクライアントを認証しようとします。

6. 認証に成功すると、以下の処理が行われます。

1. プリンシパル検証プロバイダによってプリンシパル(ユーザーおよびグループ)が署名され、プログラムによるサーバー呼出し間での信頼性が確保されます。プリンシパル検証プロバイダの詳細は、第6章「プリンシパル検証プロバイダ」を参照してください。

2. LoginModuleは署名済みのプリンシパルをサブジェクトに関連付けます。そのオブジェクトが認証対象のユーザーまたはシステム・プロセスを表します。サブジェクトとプリンシパルの詳細については、「ユーザー/グループ、プリンシパル、サブジェクト」を参照してください。

注意:

サーバー側ですべてが行われる認証の場合、プロセスはステップ3から始まり、WebLogic Serverコンテナはステップ4の前にweblogic.security.services.authentication.loginメソッドを呼び出します。

例:スタンドアロンのT3アプリケーション

スタンドアロンのT3アプリケーションの場合にJAASクラスがWebLogicセキュリティ・フレームワークとどう連携するかを図4-3に示し、続いてそれについて説明します。

図4-3 JAASクラスとWebLogic Serverを用いた認証

「図4-3 JAASクラスとWebLogic Serverを用いた認証」の説明

この例で、JAASクラスとWebLogicセキュリティ・フレームワークを用いた認証は以下のように実行されます。

1. T3アプリケーションがユーザーまたはシステム・プロセスから認証情報(ユーザー名、パスワード、およびURL)を取得します。

2. T3アプリケーションは、認証情報が格納されたCallbackHandlerを作成します。

1. T3アプリケーションは、LoginContextクラスを使用してCallbackHandlerをUsernamePasswordLoginModuleに渡します。

注意:

weblogic.security.auth.login.UsernamePasswordLoginModuleは標準のJAAS javax.security.auth.spi.LoginModuleインタフェースを実装し、クライアント側のAPIを使用してWebLogic Serverインスタンスに対するWebLogicクライアントの認証を行います。これは、T3クライアントとIIOPクライアントの両方で使用できます。このLoginModuleの呼出し側では、CallbackHandlerを実装してユーザー名(NameCallback)、パスワード(PasswordCallback)、およびURL (URLCallback)を渡す必要があります。

2. UsernamePasswordLoginModuleは、認証情報(ユーザー名、パスワード、およびURL)が格納されたCallbackHandlerをWebLogic Server RMIコンテナに渡します。

3. WebLogic Server RMIコンテナは、WebLogicセキュリティ・フレームワークに働きかけを行います。認証情報が格納されたクライアント側CallbackHandlerがWebLogicセキュリティ・フレームワークに渡されます。

4. WebLogicセキュリティ・フレームワークにより、渡されたユーザー名、パスワード、およびURLの格納されたCallbackHandlerが、構成されている認証プロバイダごとに作成されます。これらはWebLogicセキュリティ・フレームワークによってサーバー側に作成された内部的なCallbackHandlerであり、クライアントのCallbackHandlerとは関係ありません。

5. WebLogicセキュリティ・フレームワークは、認証プロバイダに関連付けられたLoginModule (認証情報を処理するために指定された特定のLoginModule)を呼び出します。
LoginModuleが認証情報を利用してクライアントを認証しようとします。

6. 認証に成功すると、以下の処理が行われます。

1. プリンシパル検証プロバイダによってプリンシパル(ユーザーおよびグループ)が署名され、プログラムによるサーバー呼出し間での信頼性が確保されます。

2. LoginModuleは署名済みのプリンシパルをサブジェクトに関連付けます。そのオブジェクトが認証対象のユーザーまたはシステムを表します。

3. WebLogicセキュリティ・フレームワークは認証ステータスをT3クライアント・アプリケーションに返し、T3クライアント・アプリケーションは認証済みのサブジェクトをWebLogicセキュリティ・フレームワークから受け取ります。

認証プロセス

図4-4に、ファット・クライアント・ログインの認証プロセスの仕組みを示します。JAASはサーバー上で動作してログインを実行します。シン・クライアント・ログイン(ブラウザ・クライアント)の場合でも、JAASはサーバー上で動作します。

図4-4 認証プロセス

「図4-4 認証プロセス」の説明

注意:

JAASプロセスを直接扱うのは、カスタム認証プロバイダの開発者だけです。クライアント・アプリケーションは、JNDI初期コンテキスト作成またはJAASのいずれかを使用してユーザー名とパスワードを受け渡します。

ユーザーがユーザー名とパスワードの組合せを使用してシステムにログインしようとすると、WebLogic Serverはそのユーザーのユーザー名とパスワードを検証することによって信頼を確立し、JAASの要件に従って、プリンシパルが格納されたサブジェクトを返します。図4-4にも示されているように、このプロセスではLoginModuleとプリンシパル検証プロバイダを使用する必要があります。これらについては、それぞれ「LoginModule」と第6章「プリンシパル検証プロバイダ」で詳しく解説されています。

呼出し側のIDの確認に成功すると、認証コンテキストが確立され、IDが確認されたユーザーまたはシステムに関しては、そのコンテキストを通じて他のエンティティに対する認証を行うことができます。認証コンテキストはまた、アプリケーション・コンポーネントに委託することもでき、それによって、そのコンポーネントは別のアプリケーション・コンポーネントを呼び出しつつ、元の呼出し側として動作できるようになります。

カスタム認証プロバイダを開発する必要があるか

WebLogic Serverのデフォルト(アクティブ)セキュリティ・レルムには、WebLogic認証プロバイダが含まれます。

注意:

WebLogic認証プロバイダをWebLogic認可プロバイダと組み合せれば、WebLogic Serverリリース6.xで利用できたファイル・レルムの機能のかわりになります。

WebLogic認証プロバイダは、ユーザー名とパスワードの委託認証をサポートし、組込みLDAPサーバーを利用してユーザーとグループの情報を格納します。WebLogic認証プロバイダを使用すると、ユーザーとグループ・メンバーシップを編集、表示、および管理できます。

WebLogic Serverでは、デフォルトのセキュリティ・レルムにおいて、以下の認証プロバイダをWebLogic認証プロバイダのかわりとして使用したり、WebLogic認証プロバイダと併用したりすることもできます。

- Open LDAP、iPlanet、Microsoft Active Directory、およびNovell NDSといった外部LDAPストアにアクセスする一連のLDAP認証プロバイダ

- 認証を行うために、データベースに格納されているユーザー、パスワード、グループ、およびグループ・メンバーシップ情報にアクセスする一連のデータベース管理システム(DBMS)プロバイダ

- 認証を行うためにWindows NTユーザーおよびグループを使用するWindows NT認証プロバイダ

- LDAP X509 IDアサーション・プロバイダ

デフォルトでは、これらの認証プロバイダは使用可能ですが、WebLogicデフォルト・セキュリティ・レルムには構成されていません。

追加の認証タスクを実行する場合は、カスタム認証プロバイダを開発する必要があります。

注意:

初期状態ではサポートされていない種類のトークン(新規、カスタム、サード・パーティのトークンなど)を使用して境界認証を行うには、カスタムIDアサーション・プロバイダを開発する必要があります。詳細については、第5章「IDアサーション・プロバイダ」を参照してください。

カスタム認証プロバイダの開発方法

WebLogic認証プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム認証プロバイダを開発することができます。

1. 適切なSSPIによるランタイム・クラスの作成

2. WebLogic MBeanMakerを使用してMBeanタイプを生成する

3. 管理コンソールによるカスタム認証プロバイダの構成

適切なSSPIによるランタイム・クラスの作成

ランタイム・クラスを作成する前に、以下の作業が必要です。

- 「Provider」SSPIの目的について

- SSPI階層を理解し、ランタイム・クラスを1つ作成するか2つ作成するかを決定する

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム認証プロバイダのランタイム・クラスを作成します。

- AuthenticationProviderV2 SSPIの実装

- JAAS LoginModuleインタフェースの実装

カスタム認証プロバイダのランタイム・クラスの作成例については、「例:サンプル認証プロバイダのランタイム・クラスの作成」を参照してください。

AuthenticationProviderV2 SSPIの実装

注意:

AuthenticationProvider SSPIは、このリリースのWebLogic Serverでは非推奨になっています。AuthenticationProviderV2 SSPIをかわりに使用してください。

AuthenticationProviderV2 SSPIを実装するには、「「Provider」SSPIの目的について」で説明されているメソッドおよび次のメソッドの実装を提供する必要があります。

- getLoginModuleConfiguration

public AppConfigurationEntry getLoginModuleConfiguration()

getLoginModuleConfigurationメソッドは、認証プロバイダの関連付けられたLoginModuleに関する情報を取得します。その情報は、AppConfigurationEntryとして返されます。AppConfigurationEntryは、LoginModuleのクラス名、認証プロバイダの関連するMBeanを通じて渡されたLoginModuleの制御フラグ、および他の構成情報をLoginModuleに渡すことを可能にするLoginModuleの構成オプション・マップの格納されたJAAS (Java Authentication and Authorization Service)クラスです。

(javax.security.auth.loginパッケージ内にある)AppConfigurationEntryクラスとLoginModuleの制御フラグ・オプションの詳細は、Java SE 6.0 API仕様のAppConfigurationEntryクラス(http://download.oracle.com/javase/6/docs/api/javax/security/auth/login/AppConfigurationEntry.html)およびConfigurationクラス(http://download.oracle.com/javase/6/docs/api/javax/security/auth/login/Configuration.html)を参照してください。LoginModuleの詳細は、「LoginModule」を参照してください。セキュリティ・プロバイダとMBeanの詳細は、「MBeanタイプが必要な理由について」を参照してください。

- getAssertionModuleConfiguration

public AppConfigurationEntry
getAssertionModuleConfiguration()

getAssertionModuleConfigurationメソッドは、IDアサーション・プロバイダの関連付けられたLoginModuleに関する情報を取得します。その情報は、AppConfigurationEntryとして返されます。AppConfigurationEntryは、LoginModuleのクラス名、IDアサーション・プロバイダの関連するMBeanを通じて渡されたLoginModuleの制御フラグ、および他の構成情報をLoginModuleに渡すことを可能にするLoginModuleの構成オプション・マップの格納されたJAASクラスです。

注意:

getAssertionModuleConfigurationメソッドの実装はnullを返す場合があります(IDアサーション・プロバイダが認証プロバイダと同じLoginModuleを使用する場合)。

IDアサーション・プロバイダのassertidentity()メソッドは、IDアサーションが発生するたびに呼び出されますが、サブジェクトがキャッシュされている場合、LoginModuleは呼び出されないことがあります。-Dweblogic.security.identityAssertionTTLフラグを使うと、この動作を変更する(たとえば、5分というデフォルトTTLを変更する、またはフラグを -1に設定してキャッシュを無効にする)ことができます。

トークンが有効なだけでなく、ユーザーも引続き有効であること(ユーザーが削除されていないことなど)を確認するのは、IDアサーション・プロバイダの役割です。

EJBの<run-as-principal>要素とカスタム認証プロバイダを併用する場合には、getAssertionModuleConfiguration()メソッドを使用します。このメソッドが実行するIDアサーションによって、<run-as-principal>要素に指定されているプリンシパルが検証されます。

- getPrincipalValidator

public PrincipalValidator getPrincipalValidator()

getPrincipalValidatorメソッドは、プリンシパル検証プロバイダのランタイム・クラス(PrincipalValidator SSPI実装)の参照を取得します。WebLogicプリンシパル検証プロバイダは、ほとんどの場合に使用できます。WebLogicプリンシパル検証プロバイダの返し方の例については、例4-1を参照してください。プリンシパル検証プロバイダの詳細は、第6章「プリンシパル検証プロバイダ」を参照してください。

- getIdentityAsserter

public IdentityAsserterV2 getIdentityAsserter()

AuthenticationProviderV2のgetIdentityAsserterメソッドは、新しいIDアサーション・プロバイダのランタイム・クラス(IdentityAsserterV2 SSPI実装)の参照を取得します。

ほとんどの場合、このメソッドの戻り値はnullになります(例については例4-1を参照)。IDアサーション・プロバイダの詳細は、第5章「IDアサーション・プロバイダ」を参照してください。

AuthenticationProviderV2 SSPIと前述のメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

JAAS LoginModuleインタフェースの実装

JAAS javax.security.auth.spi.LoginModuleインタフェースを実装するには、以下のメソッドを実装する必要があります。

- initialize

public void initialize (Subject subject, CallbackHandler callbackHandler, Map sharedState, Map options)

initializeメソッドはLoginModuleを初期化します。引数として取るのは、結果として得られるプリンシパルを格納するサブジェクト、認証プロバイダが認証情報のコンテナにコールバックするのに使用するCallbackHandler、任意の共有状態情報のマップ、および構成オプション(すなわち、LoginModuleに渡す任意の付加的情報)のマップです。

CallbackHandlerは、可変個の引数を複合オブジェクトとしてメソッドに渡すことができるようにする高度に柔軟なJAAS規格です。CallbackHandlerの詳細は、Java SE 6.0 API仕様のCallbackHandlerインタフェース(http://download.oracle.com/javase/6/docs/api/javax/security/auth/callback/CallbackHandler.html)を参照してください。

- login

public boolean login() throws LoginException

loginメソッドは、ユーザーを認証し、認証情報のコンテナにコールバックすることでそのユーザーのプリンシパルを作成しようと試みます。複数のLoginModuleが複数の認証プロバイダの一部として構成されている場合、このメソッドはLoginModuleごとにその構成の順序で呼び出されます。ログインが成功したかどうか(すなわち、プリンシパルが作成されたかどうか)についての情報は、LoginModuleごとに格納されます。

- commit

public boolean commit() throws LoginException

commitメソッドは、loginメソッドで作成されたプリンシパルをサブジェクトに追加しようと試みます。このメソッドも、複数の認証プロバイダの一部として構成されているLoginModuleごとに呼び出され、順番に実行されます。コミットが成功したかどうかの情報は、LoginModuleごとに格納されます。

- abort

public boolean abort() throws LoginException

abortメソッドは、構成されている認証プロバイダの一部として構成されているLoginModuleのコミットが失敗した(つまり、関連するREQUIRED、REQUISITE、SUFFICIENT、およびOPTIONAL LoginModuleが成功しなかった)場合にLoginModuleごとに呼び出されます。abortメソッドは、LoginModuleのプリンシパルをサブジェクトから削除し、実行されたアクションを効果的にロールバックします。使用可能な制御フラグ設定の詳細は、Java SE 6.0 API仕様のLoginModuleインタフェース(http://download.oracle.com/javase/6/docs/api/javax/security/auth/spi/LoginModule.html)を参照してください。

- logout

public boolean logout() throws LoginException

logoutメソッドは、ユーザーをシステムからログアウトさせようとします。また、サブジェクトのリセットも行うので、関連付けられているプリンシパルは格納されなくなります。

注意:

LoginModule.logoutメソッドはWebLogic認証プロバイダまたはカスタム認証プロバイダに対して呼び出されることはありません。これは単に、いったんプリンシパルが作成されサブジェクト内に入れられると、WebLogicセキュリティ・フレームワークはこのサブジェクトのライフサイクルを制御しなくなるからです。したがって、JAAS LoginContext を作成してログインおよびサブジェクトの取得を行う、開発者によって記述されたユーザー・コードでも、 LoginContext.logout メソッドを呼び出す必要があります。ユーザー・コードが、JAASを直接使用するJavaクライアントで実行される場合、このコードには LoginContext.logout メソッドを呼び出すというオプションがあります。これにより、サブジェクトはクリアされます。ユーザー・コードがサーブレットで実行される場合、サーブレットはサーブレット・セッションからユーザーをログアウトすることができます。これにより、サブジェクトはクリアされます。

JAAS LoginModuleインタフェースと前述のメソッドの詳細は、『Java Authentication and Authorization Service (JAAS) 1.0 Developer's Guide』(http://download.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html)およびJava SE 6.0 API仕様のLoginModuleインタフェース(http://download.oracle.com/javase/6/docs/api/javax/security/auth/spi/LoginModule.html)を参照してください。

LoginModuleからカスタム例外のスロー

記述したLoginModuleからカスタム例外をスローすることができます。そうすると、カスタム例外をアプリケーションおよび、実行された適切なアクションで捕捉できます。たとえば、LoginModuleからPasswordChangeRequiredExceptionがスローされると、その例外をアプリケーションで捕捉して、パスワードの変更が可能なページへユーザーを導くのに使用できます。

LoginModuleからカスタム例外をスローし、それをアプリケーション内で捕捉する場合には、以下のことを確認する必要があります。

1. 例外を捕捉するアプリケーションがサーバー上で実行されています。(ファット・クライアントはカスタム例外を捕捉できません。)

2. サーブレットが、コンパイル時でもデプロイメント時でもカスタム例外クラスにアクセスできます。これは、必要に応じて次の方法のいずれかで行えます。

- 方法1 :システム・クラスパスおよびコンパイラ・クラスパスを介してカスタム例外を使えるようにする

- 方法2 :アプリケーション・クラスパスを介してカスタム例外を使えるようにする

方法1 :システム・クラスパスおよびコンパイラ・クラスパスを介してカスタム例外を使えるようにする

1. LoginExceptionを拡張する例外クラスを記述します。

2. LoginModuleインタフェースおよびAuthenticationProviderインタフェースを実装するクラスでカスタム例外クラスを使用します。

3. セキュリティ・プロバイダの ランタイム・クラスをコンパイルする際に、カスタム例外クラスをシステム・クラスパスおよびコンパイラ・クラスパスの両方に入れます。

4. WebLogic MBeanMakerを使用してMBeanタイプを生成する

方法2 :アプリケーション・クラスパスを介してカスタム例外を使えるようにする

1. LoginExceptionを拡張する例外クラスを記述します。

2. LoginModuleインタフェースおよびAuthenticationProviderインタフェースを実装するクラスでカスタム例外クラスを使用します。

3. カスタム例外のソースをアプリケーションのビルドのクラスパスに入れ、それをアプリケーションのJAR/WARファイルのクラスパスに含めます。

4. WebLogic MBeanMakerを使用してMBeanタイプを生成する

5. WebLogic MBeanMakerで生成されたMJF (MBean JARファイル)にカスタム例外クラスを追加します。

6. アプリケーションのコンパイル時にMJFを含めます。

例:サンプル認証プロバイダのランタイム・クラスの作成

例4-1は、サンプル認証プロバイダの2つのランタイム・クラスの1つであるSimpleSampleAuthenticationProviderImpl.javaクラスを示しています。このランタイム・クラスには次の実装が含まれています。

- initialize、getDescription、およびshutdownというSecurityProviderインタフェースから継承した3つのメソッド(「「Provider」SSPIの目的について」を参照)。

- getLoginModuleConfiguration、getAssertionModuleConfiguration、getPrincipalValidator、およびgetIdentityAsserterというAuthenticationProviderV2 SSPIの4つのメソッド(「AuthenticationProviderV2 SSPIの実装」を参照)。

注意:

例4-1の太字のコードは、クラス宣言とメソッド・シグネチャを示しています。

例4-1 SimpleSampleAuthenticationProviderImpl.java

package examples.security.providers.authentication.simple;
import java.util.HashMap;
import javax.security.auth.login.AppConfigurationEntry;
import javax.security.auth.login.AppConfigurationEntry.LoginModuleControlFlag;
import weblogic.management.security.ProviderMBean;
import weblogic.security.provider.PrincipalValidatorImpl;
import weblogic.security.spi.AuthenticationProviderV2;
import weblogic.security.spi.IdentityAsserterV2;
import weblogic.security.spi.PrincipalValidator;
import weblogic.security.spi.SecurityServices;
import weblogic.security.principal.WLSGroupImpl;
import weblogic.security.principal.WLSUserImpl;
public final class SimpleSampleAuthenticationProviderImpl implements AuthenticationProviderV2
{
private String description;
private SimpleSampleAuthenticatorDatabase database;
private LoginModuleControlFlag controlFlag;
public void initialize(ProviderMBean mbean, SecurityServices services)
{
System.out.println("SimpleSampleAuthenticationProviderImpl.initialize");
SimpleSampleAuthenticatorMBean myMBean = (SimpleSampleAuthenticatorMBean)mbean;
description = myMBean.getDescription() + "\n" + myMBean.getVersion();
database = new SimpleSampleAuthenticatorDatabase(myMBean);
String flag = myMBean.getControlFlag();
if (flag.equalsIgnoreCase("REQUIRED")) {
controlFlag = LoginModuleControlFlag.REQUIRED;
} else if (flag.equalsIgnoreCase("OPTIONAL")) {
controlFlag = LoginModuleControlFlag.OPTIONAL;
} else if (flag.equalsIgnoreCase("REQUISITE")) {
controlFlag = LoginModuleControlFlag.REQUISITE;
} else if (flag.equalsIgnoreCase("SUFFICIENT")) {
controlFlag = LoginModuleControlFlag.SUFFICIENT;
} else {
throw new IllegalArgumentException("invalid flag value" + flag);
}
}
public String getDescription()
{
return description;
}
public void shutdown()
{
System.out.println("SimpleSampleAuthenticationProviderImpl.shutdown");
}
private AppConfigurationEntry getConfiguration(HashMap options)
{
options.put("database", database);
return new
AppConfigurationEntry(
"examples.security.providers.authentication.Simple.Simple.SampleLoginModuleImpl",
controlFlag,
options
);
}
public AppConfigurationEntry getLoginModuleConfiguration()
{
HashMap options = new HashMap();
return getConfiguration(options);
}
public AppConfigurationEntry getAssertionModuleConfiguration()
{
HashMap options = new HashMap();
options.put("IdentityAssertion","true");
return getConfiguration(options);
}
public PrincipalValidator getPrincipalValidator()
{
return new PrincipalValidatorImpl();
}
public IdentityAsserterV2 getIdentityAsserter()
{
return null;
}
}

例4-2は、サンプル認証プロバイダの2つのランタイム・クラスの1つであるSampleLoginModuleImpl.javaクラスを示しています。このランタイム・クラスは、JAAS LoginModuleインタフェースを実装するので(「JAAS LoginModuleインタフェースの実装」を参照)、そのinitialize、login、commit、abort、およびlogoutメソッドの実装を含んでいます。

注意:

例4-2の太字のコードは、クラス宣言とメソッド・シグネチャを示しています。

例4-2 SimpleSampleLoginModuleImpl.java

package examples.security.providers.authentication.simple;
import java.io.IOException;
import java.util.Enumeration;
import java.util.Map;
import java.util.Vector;
import javax.security.auth.Subject;
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.NameCallback;
import javax.security.auth.callback.PasswordCallback;
import javax.security.auth.callback.UnsupportedCallbackException;
import javax.security.auth.login.LoginException;
import javax.security.auth.login.FailedLoginException;
import javax.security.auth.spi.LoginModule;
import weblogic.management.utils.NotFoundException;
import weblogic.security.spi.WLSGroup;
import weblogic.security.spi.WLSUser;
import weblogic.security.principal.WLSGroupImpl;
import weblogic.security.principal.WLSUserImpl;
final public class SimpleSampleLoginModuleImpl implements LoginModule
{
private Subject subject;
private CallbackHandler callbackHandler;
private SimpleSampleAuthenticatorDatabase database;
// Determine whether this is a login or assert identity
private boolean isIdentityAssertion;
// Authentication status
private boolean loginSucceeded;
private boolean principalsInSubject;
private Vector principalsForSubject = new Vector();
public void initialize(Subject subject, CallbackHandler callbackHandler, Map
sharedState, Map options)
{
// only called (once!) after the constructor and before login
System.out.println("SimpleSampleLoginModuleImpl.initialize");
this.subject = subject;
this.callbackHandler = callbackHandler;
// Check for Identity Assertion option
isIdentityAssertion =
"true".equalsIgnoreCase((String)options.get("IdentityAssertion"));
database = (SimpleSampleAuthenticatorDatabase)options.get("database");
}
public boolean login() throws LoginException
{
// only called (once!) after initialize
System.out.println("SimpleSampleLoginModuleImpl.login");
// loginSucceeded       should be false
// principalsInSubject  should be false

Callback[] callbacks = getCallbacks();
String userName = getUserName(callbacks);
if (userName.length() > 0) {
if (!database.userExists(userName)) {
throwFailedLoginException("Authentication Failed: User " + userName
+ " doesn't exist.");
}
if (!isIdentityAssertion) {
String passwordWant = null;
try {
passwordWant = database.getUserPassword(userName);
} catch (NotFoundException shouldNotHappen) {}
String passwordHave = getPasswordHave(userName, callbacks);
if (passwordWant == null || !passwordWant.equals(passwordHave)) {
throwFailedLoginException(
"Authentication Failed: User " + userName + " bad password."
);
}
}
} else {
// anonymous login - let it through?
System.out.println("\tempty userName");
}
loginSucceeded = true;
principalsForSubject.add(new WLSUserImpl(userName));
addGroupsForSubject(userName);
return loginSucceeded;
}
public boolean commit() throws LoginException
{
// only called (once!) after login
// loginSucceeded      should be true or false
// principalsInSubject should be false
// user      should be null if !loginSucceeded, null or not-null otherwise
// group     should be null if user == null, null or not-null otherwise

System.out.println("SimpleSampleLoginModule.commit");
if (loginSucceeded) {
subject.getPrincipals().addAll(principalsForSubject);
principalsInSubject = true;
return true;
} else {
return false;
}
}
public boolean abort() throws LoginException
{
// The abort method is called to abort the authentication process. This is
// phase 2 of authentication when phase 1 fails. It is called if the
// LoginContext's overall authentication failed.
// loginSucceeded      should be true or false
// user      should be null if !loginSucceeded, otherwise null or not-null
// group     should be null if user == null, otherwise null or not-null
// principalsInSubject      should be false if user is null, otherwise true
//                          or false

System.out.println("SimpleSampleLoginModule.abort");
if (principalsInSubject) {
subject.getPrincipals().removeAll(principalsForSubject);
principalsInSubject = false;
}
return true;
}
public boolean logout() throws LoginException
{
// should never be called
System.out.println("SimpleSampleLoginModule.logout");
return true;
}
private void throwLoginException(String msg) throws LoginException
{
System.out.println("Throwing LoginException(" + msg + ")");
throw new LoginException(msg);
}
private void throwFailedLoginException(String msg) throws FailedLoginException
{
System.out.println("Throwing FailedLoginException(" + msg + ")");
throw new FailedLoginException(msg);
}
private Callback[] getCallbacks() throws LoginException
{
if (callbackHandler == null) {
throwLoginException("No CallbackHandler Specified");
}
if (database == null) {
throwLoginException("database not specified");
}
Callback[] callbacks;
if (isIdentityAssertion) {
callbacks = new Callback[1];
} else {
callbacks = new Callback[2];
callbacks[1] = new PasswordCallback("password: ",false);
}
callbacks[0] = new NameCallback("username: ");
try {
callbackHandler.handle(callbacks);
} catch (IOException e) {
throw new LoginException(e.toString());
} catch (UnsupportedCallbackException e) {
throwLoginException(e.toString() + " " + e.getCallback().toString());
}
return callbacks;
}
private String getUserName(Callback[] callbacks) throws LoginException
{
String userName = ((NameCallback)callbacks[0]).getName();
if (userName == null) {
throwLoginException("Username not supplied.");
}
System.out.println("\tuserName\t= " + userName);
return userName;
}
private void addGroupsForSubject(String userName)
{
for (Enumeration e = database.getUserGroups(userName);
e.hasMoreElements();) {
String groupName = (String)e.nextElement();
System.out.println("\tgroupName\t= " + groupName);
principalsForSubject.add(new WLSGroupImpl(groupName));
}
}
private String getPasswordHave(String userName, Callback[] callbacks) throws
LoginException
{
PasswordCallback passwordCallback = (PasswordCallback)callbacks[1];
char[] password = passwordCallback.getPassword();
passwordCallback.clearPassword();
if (password == null || password.length < 1) {
throwLoginException("Authentication Failed: User " + userName + ".
Password not supplied");
}
String passwd = new String(password);
System.out.println("\tpasswordHave\t= " + passwd);
return passwd;
}
}

WebLogic MBeanMakerを使用してMBeanタイプを生成する

カスタム・セキュリティ・プロバイダのMBeanタイプを生成する前に、以下の作業が必要です。

- MBeanタイプが必要な理由について

- 拡張および実装するSSPI MBeanの決定

- MBean定義ファイル(MDF)の基本的な要素について

- SSPI MBeanの階層と管理コンソールに対する影響について

- WebLogic MBeanMakerによって提供されるものについて

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム認証プロバイダのMBeanタイプを作成します。

1. MBean定義ファイル(MDF)の作成

2. WebLogic MBeanMakerを使用してMBeanタイプを生成する

3. WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

4. WebLogic Server環境にMBeanタイプをインストールする

注意:

複数のセキュリティ・プロバイダのサンプルで、これらの手順の実行方法を示します。

この節で説明する手順はすべて、Windows環境での作業を想定しています。

MBean定義ファイル(MDF)の作成

MBean定義ファイル(MDF)を作成するには、次の手順に従います。

1. サンプル認証プロバイダのMDFをテキスト・ファイルにコピーします。

注意:

サンプル認証プロバイダのMDFは、SimpleSampleAuthenticator.xmlです。

2. MDFで<MBeanType>要素と<MBeanAttribute>要素の内容をカスタム認証プロバイダに合わせて修正します。

3. カスタム属性および操作(つまり、<MBeanAttribute>および<MBeanOperation>要素)をMDFに追加します。

4. ファイルを保存します。

注意:

MDF要素の構文についての詳細なリファレンスは、付録A「MBean定義ファイル(MDF)要素の構文」に収められています。

WebLogic MBeanMakerを使用してMBeanタイプを生成する

MDFを作成したら、WebLogic MBeanMakerを使用してそれを実行できます。WebLogic MBeanMakerは現在のところコマンドライン・ユーティリティで、入力としてMDFを受け取り、MBeanインタフェース、MBean実装、関連するMBean情報ファイルなどの中間Javaファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム・セキュリティ・プロバイダのMBeanタイプになります。

MBeanタイプの作成手順は、カスタム認証プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。

- オプショナルSSPI MBeanとカスタム操作を追加しない場合

- オプショナルSSPI MBeanまたはカスタム操作を追加する場合

オプショナルSSPI MBeanとカスタム操作を追加しない場合

カスタム認証プロバイダのMDFがオプショナルSSPI MBeanを実装せず、かつ、いかなるカスタム操作も含まない場合、次の手順に従います。

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true
weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり認証プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

3. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

オプショナルSSPI MBeanまたはカスタム操作を追加する場合

カスタム認証プロバイダのMDFがオプショナルSSPI MBeanまたはカスタム操作を実装する場合、以下の質問に答えながら手順を進めてください。

MBeanタイプを作成するのは初めてですか。その場合は、次の手順に従ってください:

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true
weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり認証プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

3. オプショナルSSPI MBeanをMDFに実装した場合は、次の手順に従います。

1. MBean実装ファイルを見つけます。
WebLogic MBeanMakerによって生成されるMBean実装ファイルには、MBeanNameImpl.javaという名前が付けられます。たとえば、SampleAuthenticatorという名前のMDFの場合、編集されるMBean実装ファイルはSampleAuthenticatorImpl.javaという名前になります。

2. MDFで実装したオプショナルSSPI MBeanごとに、各メソッドを実装します。オプショナルSSPI MBeanが継承するメソッドもすべて実装してください。

4. MDFにカスタム属性/操作を含めた場合は、メソッド・スタブを使用してメソッドを実装します。

5. ファイルを保存します。

6. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

既存のMBeanタイプの更新ですか。その場合は、次の手順に従ってください:

1. WebLogic MBeanMakerによって現在のメソッドの実装が上書きされないように、既存のMBean実装ファイルを一時ディレクトリにコピーします。

2. 新しいDOSシェルを作成します。

3. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true
weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり認証プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

4. オプショナルSSPI MBeanをMDFに実装した場合は、次の手順に従います。

1. MBean実装ファイルを見つけて開きます。
WebLogic MBeanMakerによって生成されるMBean実装ファイルには、<MBeanName>Impl.javaという名前が付けられます。たとえば、SampleAuthenticatorという名前のMDFの場合、編集されるMBean実装ファイルはSampleAuthenticatorImpl.javaという名前になります。

2. ステップ1で一時ディレクトリに保存した既存のMBean実装ファイルを開きます。

3. 既存のMBean実装ファイルを、WebLogic MBeanMakerによって生成されたMBean実装ファイルと同期させます。
これには、メソッドの実装を既存のMBean実装ファイルから新しく生成されたMBean実装ファイルにコピー(または、新しく生成されたMBean実装ファイルから既存のMBean実装ファイルに新しいメソッドを追加)し、いずれのMBean実装ファイルにも入っているメソッドのメソッド・シグネチャへの変更が、使用するMBean実装ファイルに反映されていることを確認するといった作業が必要です。

4. MDFを修正して元のMDFにはないオプショナルSSPI MBeanを実装した場合は、各メソッドを実装します。オプショナルSSPI MBeanが継承するメソッドもすべて実装してください。

5. MDFを変更して元のMDFにはないカスタム操作を含めた場合、メソッド・スタブを使用してメソッドを実装します。

6. 完成した、つまりすべてのメソッドを実装したMBean実装ファイルを保存します。

7. このMBean実装ファイルを、WebLogic MBeanMakerがMBeanタイプの実装ファイルを配置したディレクトリにコピーします。このディレクトリは、手順3でfilesdirとして指定したものです。(ステップ3の結果としてWebLogic MBeanMakerで生成されたMBean実装ファイルがオーバーライドされます)。

8. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

生成されるMBeanインタフェース・ファイルについて

MBeanインタフェース・ファイルは、ランタイム・クラスまたはMBean実装ファイルが構成データを取得するために使用するMBeanとのクライアント側APIです。「「Provider」SSPIの目的について」で説明されているように、これはinitializeメソッドで使用するのが一般的です。

WebLogic MBeanMakerでは、作成済のMDFからMBeanタイプを生成するので、生成されるMBeanインタフェース・ファイルの名前は、そのMDF名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMakerを使用してSimpleSampleAuthenticator MDFを実行すると、SimpleSampleAuthenticatorMBean.javaという名前のMBeanインタフェース・ファイルが生成されます。

WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

WebLogic MBeanMakerでMDFを実行して中間ファイルを作成し、MBean実装ファイルを編集して適切なメソッドの実装を提供したら、カスタム認証プロバイダのMBeanファイルとランタイム・クラスをMBean JARファイル(MJF)にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMakerによって自動化されます。

カスタム認証プロバイダのMJFを作成するには、次の手順を行います。

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMJF=jarfile -Dfiles=filesdir
weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMJFフラグはWebLogic MBeanMakerが新しいMBeanタイプを含むJARファイルを構築すべきであることを示し、jarfileはMJFの名前、filesdirはWebLogic MBeanMakerでMJFにJAR化する対象ファイルが存在する場所を示します。

この時点でコンパイルが行われるので、エラーが発生するおそれがあります。jarfileが指定されていて、エラーが発生しなかった場合には、指定された名前のMJFが作成されます。

注意:

カスタム・セキュリティ・プロバイダのJARファイルを作成する際には、一連のXMLバインディング・クラスと1つのスキーマも生成されます。そのスキーマに関連付けるネームスペースを選択できます。それにより、使用しているカスタム・クラスとOracleのカスタム・クラスとの競合を防ぐことができます。ネームスペースのデフォルトはvendorです。-targetNameSpace引数をWebLogicMBeanMakerまたは関連するWLMBeanMaker antタスクに渡すことで、このデフォルトを変更できます。

既存のMJFを更新する場合は、単純にMJFを削除して再生成します。WebLogic MBeanMakerにも -DIncludeSourceオプションがあり、それを指定すると、生成されるMJFにソース・ファイルを含めるかどうかを制御できます。ソース・ファイルには、生成されたソースとMDFそのものがあります。デフォルトはfalseです。このオプションは、-DMJFを使用しない場合には無視されます。

生成されたMJFは、自らのWebLogic Server環境にインストールすることも、顧客に配布してそれぞれのWebLogic Server環境にインストールしてもらうこともできます。

WebLogic Server環境にMBeanタイプをインストールする

MBeanタイプをWebLogic Server環境にインストールするには、MJFをWL_HOME\server\lib\mbeantypesディレクトリにコピーします。ここで、WL_HOMEはWebLogic Serverの最上位のインストール・ディレクトリです。これで、カスタム認証プロバイダが「デプロイ」されます。つまり、カスタム認証プロバイダがWebLogic Server管理コンソールから管理できるようになります。

注意:

MBeanタイプをインストールするデフォルトのディレクトリは、WL_HOME\server\lib\mbeantypesです。初めて使用するバージョンが9.0の場合、セキュリティ・プロバイダは...\domaindir\lib\mbeantypesからもロードできます。ただし、サーバーを起動するときに-Dweblogic.alternateTypesDirectory=<dirコマンドライン・フラグを使用すれば、WebLogic Serverが追加ディレクトリでMBeanタイプを検索します。<dirは、ディレクトリ名のカンマ区切りのリストです。このフラグを使用する場合、WebLogic Serverは常に最初にWL_HOME\server\lib\mbeantypesからMBeanタイプをロードします。その後で、追加ディレクトリにあるすべての有効なアーカイブを検索して、ロードします。このとき拡張子は考慮されません。たとえば、-Dweblogic.alternateTypesDirectory = dirX,dirY,の場合、WebLogic Serverは最初にWL_HOME\server\lib\mbeantypesからMBeanタイプをロードしてから、dirXおよびdirYにある有効なアーカイブをロードします。WebLogic Serverに追加ディレクトリでMBeanタイプを検索するよう指示する際に、Javaセキュリティ・マネージャを使用している場合は、weblogic.policyファイルを更新して、MBeanタイプ(その結果として、カスタム・セキュリティ・プロバイダ)に適した許可を付与することも必要になります。詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』のJavaセキュリティを使用したWebLogicリソースの保護に関する項を参照してください。

カスタム認証プロバイダを構成することによって(「管理コンソールによるカスタム認証プロバイダの構成」を参照)、MBeanタイプのインスタンスを作成して、GUI、他のJavaコード、またはAPIからそれらのMBeanインスタンスを使用することができます。たとえば、WebLogic Server管理コンソールを使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他のJavaオブジェクトを開発して、そのオブジェクトでMBeanをインスタンス化し、それらのMBeanから提供される情報に自動的に応答させることもできます。なお、これらのMBeanインスタンスをバックアップしておくことをお薦めします。

管理コンソールによるカスタム認証プロバイダの構成

カスタム認証プロバイダを構成するということは、そのカスタム認証プロバイダをセキュリティ・レルムに追加するということです。追加されたカスタム認証プロバイダには、認証サービスを必要とするアプリケーションからアクセスできます。

カスタム・セキュリティ・プロバイダの構成は管理タスクですが、カスタム・セキュリティ・プロバイダの開発者が行うこともできます。この節では、カスタム認証プロバイダの構成担当者にとって重要な情報を提供します。

- ユーザー・ロックアウトの管理

- 認証プロバイダの順序の指定

注意:

WebLogic Server管理コンソールを使用してカスタム認証プロバイダを構成する手順は、『Oracle WebLogic Serverの保護』のWebLogicセキュリティ・プロバイダの構成に関する項で説明されています。

ユーザー・ロックアウトの管理

カスタム認証プロバイダを使用する一環として、ユーザー・ロックアウトを構成および管理する方法を検討する必要があります。以下の2つの選択肢があります。

- レルム・ワイドのユーザー・ロックアウト・マネージャの使用

- 独自のユーザー・ロックアウト・マネージャの実装

レルム・ワイドのユーザー・ロックアウト・マネージャの使用

WebLogicセキュリティ・フレームワークは、WebLogicセキュリティ・フレームワークと直接連携してユーザー・ロックアウトを管理するレルム・ワイドのユーザー・ロックアウト・マネージャを提供します。

注意:

レルム・ワイドのユーザー・ロックアウト・マネージャとWebLogic Server 6.1 PasswordPolicyMBean(レルム・アダプタ・レベル)の両方をアクティブにできます。詳細は、WebLogic Server APIリファレンスJavadocを参照してください。

レルム・ワイドのユーザー・ロックアウト・マネージャを使用する場合、それをカスタム認証プロバイダと連携させるためには、WebLogic Server管理コンソールを使用して以下のことを行います。

1. ユーザー・ロック・アウトを有効にします(デフォルトで有効)。

2. 必要に応じてユーザー・ロックアウトのパラメータを修正します。

注意:

ユーザー・ロックアウト・マネージャへの変更は、サーバーを再起動するまで有効になりません。管理コンソールを使用して前述のタスクを実行する手順は、『Oracle WebLogic Serverの保護』のユーザー・アカウントの保護に関する項で説明されています。

独自のユーザー・ロックアウト・マネージャの実装

カスタム認証プロバイダの一部として独自のユーザー・ロックアウト・マネージャを実装する場合は、次の手順を行う必要があります。

1. レルム・ワイドのユーザー・ロックアウト・マネージャを無効にして二重ロックアウトを防止します。(WebLogic Server管理コンソールを使用して新しいセキュリティ・レルムを作成すると、ユーザー・ロックアウト・マネージャが必ず作成されます。)このタスクを実行する手順は、『Oracle WebLogic Serverの保護』のユーザー・アカウントの保護に関する項で説明されています。

2. WebLogicセキュリティ・フレームワークのレルム・ワイドの実装からは何も借用できないので、以下のタスクを行うことも必要です。

1. ユーザー・ロックアウト・マネージャの実装を提供します。ユーザー・ロックアウト・マネージャに関して、セキュリティ・サービス・プロバイダ・インタフェース(SSPI)は提供されません。

2. ユーザー・ロックアウト・マネージャの管理に使用できるMBeanを変更します。

3. 管理コンソールからユーザー・ロックアウト・マネージャを管理する場合、コンソール拡張を使用して管理コンソールにユーザー・ロックアウト・マネージャを組み入れます。詳細は、『Oracle WebLogic Server管理コンソールの拡張』を参照してください。

認証プロバイダの順序の指定

「LoginModuleとマルチパート認証」で説明されているように、認証プロセスの結果は、複数の認証プロバイダ(その結果としてLoginModule)の構成順序によって影響を受けます。

認証プロバイダは任意の順序で構成できます。ただし、構成済の認証プロバイダの順序を変更する必要がある場合は、『Oracle WebLogic Serverの保護』の認証プロバイダの順序の変更に関する項で説明されている手順に従ってください。

5 IDアサーション・プロバイダ

この章では、IDアサーション・プロバイダの概念と機能、およびカスタムIDアサーション・プロバイダの開発手順について説明します。

IDアサーション・プロバイダは、ユーザーまたはシステム・プロセスがトークンを使用してそれぞれのIDを証明する特殊な形態(つまり境界認証)の認証プロバイダです。IDアサーション・プロバイダは境界認証を有効にし、シングル・サインオンをサポートします。IDアサーション・プロバイダ用のLoginModuleを作成すれば、認証プロバイダの代わりにIDアサーション・プロバイダを使用できます。また、認証プロバイダのLoginModuleを使用する場合は、認証プロバイダに加えてIDアサーション・プロバイダも使用できます。

IDアサーション・プロバイダを認証プロバイダとは別に構成できるようにするには、2つのプロバイダを作成します。IDアサーション・プロバイダと認証プロバイダが独立して機能できない場合は、1つのプロバイダを作成します。

以下の節では、IDアサーション・プロバイダの概念と機能、およびカスタムIDアサーション・プロバイダの開発手順について説明します。

- IDアサーションの概念

- IDアサーション・プロセス

- カスタムIDアサーション・プロバイダを開発する必要があるか

- カスタムIDアサーション・プロバイダの開発方法

IDアサーションの概念

IDアサーション・プロバイダを開発する前に、以下の概念を理解しておく必要があります。

- IDアサーション・プロバイダとLoginModule

- IDアサーションとトークン

- 境界認証用のトークンの渡し

- Common Secure Interoperability Version 2 (CSIv2)

IDアサーション・プロバイダとLoginModule

LoginModuleと一緒に用いると、IDアサーション・プロバイダはシングル・サインオンをサポートします。たとえば、IDアサーション・プロバイダはデジタル証明書からトークンを生成することができ、そのトークンをシステム内で回すことができるため、ユーザーは何度もサインオンを求められることはありません。

IDアサーション・プロバイダが使用するLoginModuleでは、以下のことが可能です。

- 開発したカスタム認証プロバイダの一部となります。詳細については、第4章「認証プロバイダ」を参照してください。

- Oracleが開発しWebLogic Serverと一緒にパッケージ化したWebLogic認証プロバイダの一部になります。詳細については、「カスタム認証プロバイダを開発する必要があるか」を参照してください。

- サード・パーティのセキュリティ・ベンダーの認証プロバイダの一部となります。

単純認証の場合と違って(「認証プロセス」を参照)、IDアサーション・プロバイダが使用するLoginModuleは証明情報(ユーザー名やパスワードなど)を検証しません(単にユーザーが存在することを検証するだけです)。

この構成のLoginModuleは以下の処理を行う必要があります。

- WLSGroup型などの必須のプリンシパルをサブジェクトに格納します。

- ユーザーがログインのための十分な証明を提供していると見なし、パスワードなどの証明データを要求しません。

「AuthenticationProviderV2 SSPIの実装」の説明に従って、カスタム認証プロバイダにAuthenticationProviderV2.getAssertionModuleConfigurationメソッドを実装する必要があります。このメソッドは、X.509証明書の使用時などに、IDアサーションがデプロイメント記述子のrun-asタグを処理するために呼び出されます。他のシングル・サインオン方式でも、このメソッドを使用します。

注意:

LoginModuleの詳細は、「LoginModule」を参照してください。

IDアサーションとトークン

IDアサーション・プロバイダは、ユーザーまたはシステム・プロセスのIDを断定するために使用する特定のトークン・タイプをサポートするために開発します。IDアサーション・プロバイダは複数のトークン・タイプをサポートするように開発できますが、通常はただ1つの「アクティブ」なトークン・タイプを検証するように構成されます。同じトークン・タイプを検証する機能を備えた複数のIDアサーション・プロバイダを1つのセキュリティ・レルムに組み込むことも可能ですが、実際に検証を行うのは1つのIDアサーション・プロバイダだけです。

注意:

トークン・タイプを「サポート」するということは、IDアサーション・プロバイダのランタイム・クラス(IdentityAsserter SSPI実装)がそのassertIdentityメソッドでトークン・タイプを検証できるということです。詳細は、「IdentityAsserterV2 SSPIの実装」を参照してください。

以下の節では、新しいトークン・タイプを使用するための手順について説明します。

- 新しいトークン・タイプの作成方法

- 新しいトークン・タイプをIDアサーション・プロバイダの構成で利用可能にする方法

新しいトークン・タイプの作成方法

カスタムIDアサーション・プロバイダを開発する場合には、新しいトークン・タイプも作成できます。トークン・タイプとは、文字列で表される1つのデータに過ぎません。どのようなトークン・タイプを作成して使用するかは、完全にユーザーに任されています。たとえば、現在WebLogic IDアサーション・プロバイダ用に定義されているトークンには、AuthenticatedUser、X.509、CSI.PrincipalName、CSI.ITTAnonymous、CSI.X509CertChain、CSI.DistinguishedName、wsse:PasswordDigestなど、様々なタイプがあります。

新しいトークン・タイプを作成するには、例5-1に示すとおり、新しいJavaファイルを作成し、String型の変数として新しいトークン・タイプを宣言します。PerimeterIdentityAsserterTokenTypes.javaファイルでは、Test 1、Test 2、およびTest 3というトークン・タイプの名前が文字列として定義されています。

例5-1 PerimeterIdentityAsserterTokenTypes.java

package sample.security.providers.authentication.perimeterATN;
public class PerimeterIdentityAsserterTokenTypes
{
public final static String TEST1_TYPE = 'Test 1";
public final static String TEST2_TYPE = 'Test 2";
public final static String TEST3_TYPE = 'Test 3";
}

注意:

新しいトークン・タイプを1つだけ定義する場合は、例5-4で示されているようにIDアサーション・プロバイダのランタイム・クラスで行うこともできます。

新しいトークン・タイプをIDアサーション・プロバイダの構成で利用可能にする方法

カスタムIDアサーション・プロバイダを構成する場合(「管理コンソールによるカスタムIDアサーション・プロバイダの構成」を参照)、IDアサーション・プロバイダのサポートするトークン・タイプのリストが「サポートされている種類」フィールドに表示されます。図5-1に示すとおり、サポートされているタイプの1つを「アクティブな種類」フィールドに入力します。

図5-1 サンプルIDアサーション・プロバイダの構成

「図5-1 サンプルIDアサーション・プロバイダの構成」の説明

「サポートされている種類」フィールドの内容は、カスタムIDアサーション・プロバイダのMBeanタイプを生成するために使用するMBean定義ファイル(MDF)のSupportedTypes属性から取得されます。サンプルIDアサーション・プロバイダの例を例5-2に示します。(MDFおよびMBeanタイプの詳細については、「WebLogic MBeanMakerを使用してMBeanタイプを生成する」を参照)。

例5-2 SampleIdentityAsserter MDF : SupportedTypes属性

<MBeanType>
...
<MBeanAttribute
Name = "SupportedTypes"
Type = "java.lang.String[]"
Writeable = "false"
Default = "new String[] {&quot;SamplePerimeterAtnToken&quot;}"
/>
...
</MBeanType>

同様に、「アクティブな種類」フィールドの内容はMBean定義ファイル(MDF)のActiveTypes属性から取得されます。MDFファイルのActiveTypes属性をデフォルトに設定すると、WebLogic Server管理コンソールで手動設定する必要がなくなります。サンプルIDアサーション・プロバイダの例を例5-3に示します。

例5-3 SampleIdentityAsserter MDF: Defaultを使用したActiveTypes属性

<MBeanAttribute
Name= "ActiveTypes"
Type= "java.lang.String[]"
Default = "new String[] { &quot;SamplePerimeterAtnToken&quot; }"
/>

ActiveTypes属性のデフォルト化は便利ですが、他のIDアサーション・プロバイダがそのトークン・タイプを検証することがない場合にのみ行うようにします。その場合以外は、無効なセキュリティ・レルムが構成されることになるおそれがあります(複数のIDアサーション・プロバイダが同じトークン・タイプを検証しようとします)。一番良いのは、IDアサーション・プロバイダのすべてのMDFがデフォルトでそのトークン・タイプをオフにすることです。その場合、そのトークン・タイプを検証するIDアサーション・プロバイダを構成して手作業でアクティブにすることができます。

注意:

IDアサーション・プロバイダが目的のトークン・タイプを検証して受け入れるように開発および構成されていない場合、認証プロセスは失敗します。IDアサーション・プロバイダの構成の詳細は、「管理コンソールによるカスタムIDアサーション・プロバイダの構成」を参照してください。

境界認証用のトークンの渡し

IDアサーション・プロバイダは、境界認証のためにJavaクライアントからサーブレットにトークンを渡すことができます。トークンは、HTTPヘッダー、Cookie、SSL証明書などのメカニズムを用いて渡すことができます。たとえば、HTTPヘッダーを使用すれば、Base64でコード化された文字列(バイナリ・データの送信が可能)をサーブレットに送信することができます。この文字列の値は、ユーザー名などのユーザーのIDを表す文字列です。境界認証に使用されるIDアサーション・プロバイダは、その文字列を受け取り、そこからユーザー名を抽出できます。

トークンがHTTPヘッダーまたはCookieを通じて渡される場合には、そのトークンはヘッダーまたはCookieの名前に等しく、リソース・コンテナはWebLogicセキュリティ・フレームワークの認証を処理するパートにトークンを渡します。WebLogicセキュリティ・フレームワークは、そのトークンをそのままIDアサーション・プロバイダに渡します。

WebLogic Serverは、IDアサーションのサポートを介して境界までシングル・サインオン概念を拡張できるよう設計されています。IDアサーションを使用すると、WebLogic Serverは、SAML (Security Assertion Markup Language)、SPNEGO (Simple and Protected GSS-API Negotiation)、またはCommon Secure Interoperability (CSI) v2などのプロトコルに対する拡張といった境界認証方式によって提供される認証メカニズムを使用して、この機能を実現できます。

Common Secure Interoperability Version 2 (CSIv2)

WebLogic Serverでは、IIOP (Internet Inter-ORB) (GIOPバージョン1.2)およびCORBA CSIv2 (Common Secure Interoperability version 2)仕様に基づいたEJB (Enterprise JavaBean)相互運用性プロトコルをサポートしています。WebLogic ServerでCSIv2をサポートすることにより、以下のことが可能になります。

- Java EE (Java 2 Enterprise Edition)バージョン1.4の参照実装と相互運用できます。

- WebLogic Server IIOPクライアントでT3クライアントの場合と同じようにユーザー名とパスワードを指定できるようになります。

- GSSAPI (Generic Security Services Application Programming Interface)初期コンテキスト・トークンをサポートできるようになります。今回のリリースでは、ユーザー名/パスワードとGSSUP (Generic Security Services Username Password)トークンのみがサポートされています。

注意:

WebLogic ServerにおけるCSIv2実装は、Java EE CTS (Compatibility Test Suite)適合性テストに合格しています。

CSIv2実装への外部インタフェースは、CORBAオブジェクトのユーザー名とパスワードを取得するJAAS LoginModuleです。JAAS LoginModuleは、WebLogic Javaクライアント、あるいは別のJava EEアプリケーション・サーバーに対するクライアントの役目をするWebLogic Serverインスタンスで使用することができます。CSIv2サポート用のJAAS LoginModuleはUsernamePasswordLoginModuleという名前で、weblogic.security.auth.loginパッケージに格納されています。

CSIv2は以下のように動作します。

1. IOR (Interoperable Object Reference)へのセキュリティ拡張機能の作成時に、WebLogic Serverは、CORBAオブジェクトでサポートされるセキュリティ・メカニズムを識別するタグ付きコンポーネントを追加します。このタグ付きコンポーネントには、トランスポート情報、クライアント認証情報、およびID証明トークン/認可トークン情報が入っています。

2. クライアントは、IOR内のセキュリティ・メカニズムを評価し、サーバーが必要とするオプションをサポートするメカニズムを選択します。

3. クライアントはSASプロトコルを用いて、WebLogic Serverとのセキュリティ・コンテキストを確立します。SASプロトコルはリクエストとレスポンスからなるサービス・コンテキスト内に含まれるメッセージを定義します。コンテキストはステートフルでもステートレスでもかまいません。

CSIv2の利用については、『Oracle WebLogic Serverのセキュリティの理解』のCommon Secure Interoperability Version 2に関する項を参照してください。JAAS LoginModuleの詳細は、「LoginModule」を参照してください。

IDアサーション・プロセス

境界認証では、WebLogic Serverの外部にあるシステムがトークンを通じて信頼を確立します(これは、WebLogic Serverがユーザー名とパスワードを通じて信頼を確立する、「認証プロセス」で説明されているタイプの認証とは対照的です)。IDアサーション・プロバイダは、下記の図のように機能する境界認証プロセスの一部として使用されます(図5-2を参照)。

1. WebLogic Serverの外部のトークンが、そのタイプのトークンの検証を担当し、「アクティブ」として構成されているIDアサーション・プロバイダに渡されます。

2. そのトークンの有効性が問題なく検証されれば、IDアサーション・プロバイダはそのトークンをWebLogic Serverユーザー名にマップし、そのユーザー名をWebLogic Serverに送り返します。その後WebLogic Serverでは、「認証プロセス」で説明した方法で認証プロセスを続行します。具体的には、ユーザー名がJAAS (Java Authentication and Authorization Service) CallbackHandlerを介して送信され、構成済の各認証プロバイダのLoginModuleに渡されるので、LoginModuleでは、適切なプリンシパルをサブジェクトに格納できるようになります。

図5-2 境界認証

「図5-2 境界認証」の説明

図5-2でも示されているように、境界認証では「認証プロセス」で説明されている認証プロセスと同じ構成要素が必要ですが、そこにIDアサーション・プロバイダも追加されます。

カスタムIDアサーション・プロバイダを開発する必要があるか

WebLogic IDアサーション・プロバイダでは、X509証明書を使用した証明書認証、SPNEGOトークン、SAMLアサーション・トークン、およびCSIv2 (CORBA Common Secure Interoperability Version 2) IDアサーションがサポートされています。

LDAP X509 IDアサーション・プロバイダは、X509証明書を受け取り、その証明書に関連付けられたユーザーのLDAPオブジェクトをルックアップして、LDAPオブジェクトの証明書が提示された証明書と一致することを確認し、LDAPオブジェクトから認証用にユーザーの名前を取得します。

ネゴシエーションIDアサーション・プロバイダは、SPNEGOプロトコルをサポートするMicrosoftクライアントでのSSOに使用します。ネゴシエーションIDアサーション・プロバイダは、SPNEGOトークンをデコードしてKerberosトークンを入手し、このKerberosトークンを検証してWebLogicユーザーにマップします。ネゴシエーションIDアサーション・プロバイダは、Kerberosを介したGSSのセキュリティ・コンテキストの受け入れにJava GSS (Generic Security Service) API (Application Programming Interface)を利用します。ネゴシエーションIDアサーション・プロバイダは、Windows NT統合ログイン用です。

SAML IDアサーション・プロバイダは、WebLogic ServerがSAML宛先サイトとして動作するときにSAMLアサーション・トークンを処理します。SAML IDアサーション・プロバイダは、SAMLアサーション・トークンを消費および検証し、アサーションを信頼するかどうかを決定します(SOAPメッセージの証明データ、クライアント証明書、またはその他の構成インジケータを使用)。

デフォルトのWebLogic IDアサーション・プロバイダはトークン・タイプを検証し、X509デジタル証明書とX501識別名をWebLogicユーザー名にマップします。また、CSIv2 IDアサーションに使用する信頼性のあるクライアント・プリンシパルのリストも指定します。ワイルドカード文字(*)を使用すると、すべてのプリンシパルに信頼性があると指定できます。クライアントが信頼性のあるクライアント・プリンシパルのリストにない場合は、CSIv2 IDアサーションが失敗し、呼出しが拒否されます。

注意:

X.501およびX.509証明書に対してWebLogic IDアサーション・プロバイダを使用するには、WebLogic Server製品に付属しているデフォルトのユーザー名マッパー(weblogic.security.providers.authentication.DefaultUserNameMapperImpl)を使用するか、または独自のweblogic.security.providers.authentication.UserNameMapperインタフェースの実装を用意するかのいずれかの方法があります。

このインタフェースは、必要に応じた方式に従って、X.509証明書をWebLogic Serverのユーザー名にマップします。また、このインタフェースを使用してX.501識別名をユーザー名にマップすることもできます。管理コンソールを使用してIDアサーション・プロバイダを構成するときに、このインタフェースの実装を指定します。

WebLogic IDアサーション・プロバイダでは、以下のトークン・タイプがサポートされています。

- AU_TYPE - WebLogic AuthenticatedUserがトークンとして使用される場合に使用します。

- X509_TYPE - X509クライアント証明書がトークンとして使用される場合に使用します。

- CSI_PRINCIPAL_TYPE - CSIv2プリンシパル名IDがトークンとして使用される場合に使用します。

- CSI_ANONYMOUS_TYPE - CSIv2匿名IDがトークンとして使用される場合に使用します。

- CSI_X509_CERTCHAIN_TYPE - CSIv2 X509証明書チェーンIDがトークンとして使用される場合に使用します。

- CSI_DISTINGUISHED_NAME_TYPE - CSIv2識別名IDがトークンとして使用される場合に使用します。

- AUTHORIZATION_NEGOTIATE - SPNEGO内部トークンがトークンとして使用される場合に使用します。

- SAML_ASSERTION_B64_TYPE - Base64エンコードSAML.アサーションがトークンとして使用される場合に使用します。

- SAML_ASSERTION_DOM_TYPE - SAML DOM要素がトークンとして使用される場合に使用します。

- SAML_ASSERTION_TYPE - SAML文字列XML形式がトークンとして使用される場合に使用します。

- SAML2_ASSERTION_DOM_TYPE - SAML2 DOM要素がトークンとして使用される場合に使用します。

- SAML2_ASSERTION_TYPE - SAML2文字列XML形式がトークンとして使用される場合に使用します。

- SAML_SSO_CREDENTIAL_TYPE - TARGETパラメータで構成されるSAML文字列がアサーション自体と連結され、トークンとして使用される場合に使用します。

- WSSE_PASSWORD_DIGEST_TYPE - パスワード・ダイジェストのパスワード・タイプを持つユーザー名トークンがトークンとして使用される場合に使用します。

- WWW_AUTHENTICATE_NEGOTIATE - SPNEGO内部トークンがトークンとして使用される場合に使用します。

追加的なIDアサーション・タスクを実行したい場合、または新しいトークン・タイプを作成したい場合は、カスタムIDアサーション・プロバイダを開発する必要があります。

カスタムIDアサーション・プロバイダの開発方法

WebLogic IDアサーション・プロバイダが開発者のニーズを満たさない場合、次の手順でカスタムIDアサーション・プロバイダを開発することができます。

1. 適切なSSPIによるランタイム・クラスの作成

2. WebLogic MBeanMakerを使用してMBeanタイプを生成する

3. 管理コンソールによるカスタムIDアサーション・プロバイダの構成

4. 「チャレンジIDアサーション」の説明に従って、チャレンジIDアサーションを実装する必要があるかどうかを考慮します。

適切なSSPIによるランタイム・クラスの作成

ランタイム・クラスを作成する前に、以下の作業が必要です。

- 「Provider」SSPIの目的について

- SSPI階層を理解し、ランタイム・クラスを1つ作成するか2つ作成するかを決定する

この情報を理解し、設計に関する判断を下したら、次の手順でカスタムIDアサーション・プロバイダのランタイム・クラスを作成します。

- AuthenticationProviderV2 SSPIの実装

- IdentityAsserterV2 SSPIの実装

注意:

カスタムIDアサーション・プロバイダ用に別のLoginModuleを作成する(認証プロバイダのLoginModuleを使用しない)場合は、JAAS LoginModuleインタフェースも実装する必要があります(「JAAS LoginModuleインタフェースの実装」を参照)。

カスタムIDアサーション・プロバイダのランタイム・クラスの作成例については、「例:サンプルIDアサーション・プロバイダのランタイム・クラスの作成」を参照してください。

AuthenticationProviderV2 SSPIの実装

注意:

AuthenticationProvider SSPIは、このリリースのWebLogic Serverでは非推奨になっています。AuthenticationProviderV2 SSPIをかわりに使用してください。

AuthenticationProviderV2 SSPIを実装するには、「「Provider」SSPIの目的について」で説明されているメソッドおよび次のメソッドの実装を提供する必要があります。

- getLoginModuleConfiguration

public AppConfigurationEntry getLoginModuleConfiguration()

getLoginModuleConfigurationメソッドは、認証プロバイダの関連付けられたLoginModuleに関する情報を取得します。その情報は、AppConfigurationEntryとして返されます。AppConfigurationEntryは、LoginModuleのクラス名、認証プロバイダの関連するMBeanを通じて渡されたLoginModuleの制御フラグ、および他の構成情報をLoginModuleに渡すことを可能にするLoginModuleの構成オプション・マップの格納されたJAAS (Java Authentication and Authorization Service)クラスです。

(javax.security.auth.loginパッケージ内にある)AppConfigurationEntryクラスとLoginModuleの制御フラグ・オプションの詳細は、Java SE 6.0 API仕様のAppConfigurationEntryクラス(http://download.oracle.com/javase/6/docs/api/javax/security/auth/login/AppConfigurationEntry.html)およびConfigurationクラス(http://download.oracle.com/javase/6/docs/api/javax/security/auth/login/Configuration.html)を参照してください。LoginModuleの詳細は、「LoginModule」を参照してください。セキュリティ・プロバイダとMBeanの詳細は、「MBeanタイプが必要な理由について」を参照してください。

- getAssertionModuleConfiguration

public AppConfigurationEntry
getAssertionModuleConfiguration()

getAssertionModuleConfigurationメソッドは、IDアサーション・プロバイダの関連付けられたLoginModuleに関する情報を取得します。その情報は、AppConfigurationEntryとして返されます。AppConfigurationEntryは、LoginModuleのクラス名、IDアサーション・プロバイダの関連するMBeanを通じて渡されたLoginModuleの制御フラグ、および他の構成情報をLoginModuleに渡すことを可能にするLoginModuleの構成オプション・マップの格納されたJAASクラスです。

この構成のLoginModuleは、WLSGroup型などの必須のプリンシパルをサブジェクトに格納する必要があります。また、ユーザーがログインのための十分な証明を提供していると見なし、パスワードなどの証明データを要求しません。

注意:

IDアサーション・プロバイダのassertIdentity()メソッドは、IDアサーションが発生するたびに呼び出されますが、サブジェクトがキャッシュされている場合、LoginModuleは呼び出されないことがあります。-Dweblogic.security.identityAssertionTTLフラグを使うと、この動作を変更する(たとえば、5分というデフォルトTTLを変更する、またはフラグを -1に設定してキャッシュを無効にする)ことができます。

トークンが有効なだけでなく、ユーザーも引続き有効であること(ユーザーが削除されていないことなど)を確認するのは、IDアサーション・プロバイダの役割です。

- getPrincipalValidator

public PrincipalValidator getPrincipalValidator()

getPrincipalValidatorメソッドは、プリンシパル検証プロバイダのランタイム・クラス(PrincipalValidator SSPI実装)の参照を取得します。詳細については、第6章「プリンシパル検証プロバイダ」を参照してください。

- getIdentityAsserter

public IdentityAsserterV2 getIdentityAsserter()

getIdentityAsserterメソッドは、IDアサーション・プロバイダのランタイム・クラス(IdentityAsserterV2 SSPI実装)の参照を取得します。詳細は、「IdentityAsserterV2 SSPIの実装」を参照してください。

注意:

IDアサーション・プロバイダ用のLoginModuleが既存の認証プロバイダ用のLoginModuleと同じである場合、IDアサーション・プロバイダ用のAuthenticationProviderV2 SSPI内のメソッドの実装(getIdentityAsserterメソッドを除く)はnullを戻す場合があります。この場合の例については、例5-4に示します。

AuthenticationProvider SSPIと前述のメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

IdentityAsserterV2 SSPIの実装

注意:

IdentityAsserterV2 SSPIには、追加のトークン・タイプと、IDアサーション時に必要に応じて追加情報の取得に使用できるassertIdentityメソッドに対するhandlerパラメータが含まれます。IdentityAsserter SSPIもサポートされていますが、かわりにIdentityAsserterV2 SSPIの使用を検討してください。

IdentityAsserterV2 SSPIを実装するには、次のメソッドの実装を提供する必要があります。

- assertIdentity

public CallbackHandler assertIdentity(String type, Object token, ContextHandler handler) throws IdentityAssertionException;

assertIdentityメソッドは、提供されたトークンのID情報に基づいてIDを断定します。言い換えれば、このメソッドの目的は、現時点で「信頼性のない」トークンがあれば、それを信頼性のあるクライアント・プリンシパルに照らし合わせて検証することです。typeパラメータは、IDアサーション(IDの断定)に使用するトークン・タイプを表します。IDアサーション・タイプでは、大文字/小文字は区別されません。また、tokenパラメータには実際のID情報が格納されています。handlerパラメータは、IDアサーションで使用可能な追加情報を取得する際に必要に応じて使用できるContextHandlerオブジェクトです。assertIdentityメソッドから返されるCallbackHandlerは、断定されたユーザー名を格納している必要があり、プリンシパル・マッピングを行うために構成されているすべての認証プロバイダのLoginModuleに渡されます。CallbackHandlerがnullの場合、匿名ユーザーを使用することを意味します。

CallbackHandlerは、可変個の引数を複合オブジェクトとしてメソッドに渡すことができるようにする高度に柔軟なJAAS規格です。CallbackHandlerの詳細は、Java SE 6.0 API仕様のCallbackHandlerインタフェース(http://download.oracle.com/javase/6/docs/api/javax/security/auth/callback/CallbackHandler.html)を参照してください。

注意:

IDアサーション・プロバイダのassertIdentity()メソッドは、IDアサーションが発生するたびに呼び出されますが、サブジェクトがキャッシュされている場合、LoginModuleは呼び出されないことがあります。-Dweblogic.security.identityAssertionTTLフラグを使うと、この動作を変更する(たとえば、5分というデフォルトTTLを変更する、またはフラグを -1に設定してキャッシュを無効にする)ことができます。

トークンが有効なだけでなく、ユーザーも引続き有効であること(ユーザーが削除されていないことなど)を確認するのは、IDアサーション・プロバイダの役割です。

IdentityAsserterV2 SSPIと前述のメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

例:サンプルIDアサーション・プロバイダのランタイム・クラスの作成

例5-4は、サンプルIDアサーション・プロバイダのランタイム・クラスであるSampleIdentityAsserterProviderImpl.javaクラスを示しています。このランタイム・クラスには次の実装が含まれています。

- initialize、getDescription、およびshutdownというSecurityProviderインタフェースから継承した3つのメソッド(「「Provider」SSPIの目的について」を参照)。

- getLoginModuleConfiguration、getAssertionModuleConfiguration、getPrincipalValidator、およびgetIdentityAsserterというAuthenticationProviderV2 SSPIの4つのメソッド(「AuthenticationProviderV2 SSPIの実装」を参照)。

- assertIdentityというIdentityAsserterV2 SSPIのメソッド(「IdentityAsserterV2 SSPIの実装」を参照)。

注意:

例5-4の太字のコードは、クラス宣言とメソッド・シグネチャを示しています。

例5-4 SampleIdentityAsserterProviderImpl.java

package examples.security.providers.identityassertion.simple;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.login.AppConfigurationEntry;
import weblogic.management.security.ProviderMBean;
import weblogic.security.service.ContextHandler;
import weblogic.security.spi.AuthenticationProviderV2;
import weblogic.security.spi.IdentityAsserterV2;
import weblogic.security.spi.IdentityAssertionException;
import weblogic.security.spi.PrincipalValidator;
import weblogic.security.spi.SecurityServices;
public final class SimpleSampleIdentityAsserterProviderImpl implements AuthenticationProviderV2,
IdentityAsserterV2
{
final static private String TOKEN_TYPE   = "SamplePerimeterAtnToken";
final static private String TOKEN_PREFIX = "username=";
private String description;
public void initialize(ProviderMBean mbean, SecurityServices services)
{
System.out.println("SimpleSampleIdentityAsserterProviderImpl.initialize");
SimpleSampleIdentityAsserterMBean myMBean = (SimpleSampleIdentityAsserterMBean)mbean;
description = myMBean.getDescription() + "\n" + myMBean.getVersion();
}
public String getDescription()
{
return description;
}
public void shutdown()
{
System.out.println("SimpleSampleIdentityAsserterProviderImpl.shutdown");
}
public IdentityAsserterV2 getIdentityAsserter()
{
return this;
}
public CallbackHandler assertIdentity(String type, Object token, ContextHandler context) throws
IdentityAssertionException
{
System.out.println("SimpleSampleIdentityAsserterProviderImpl.assertIdentity");
System.out.println("\tType\t\t= "  + type);
System.out.println("\tToken\t\t= " + token);
if (!(TOKEN_TYPE.equals(type))) {
String error = "SimpleSampleIdentityAsserter received unknown token type \""
+ type + "\"." + " Expected " + TOKEN_TYPE;
System.out.println("\tError: " + error);
throw new IdentityAssertionException(error);
}
if (!(token instanceof byte[])) {
String error = "SimpleSampleIdentityAsserter received unknown token class \""
+ token.getClass() + "\"." + " Expected a byte[].";
System.out.println("\tError: " + error);
throw new IdentityAssertionException(error);
}
byte[] tokenBytes = (byte[])token;
if (tokenBytes == null || tokenBytes.length < 1) {
String error = "SimpleSampleIdentityAsserter received empty token byte array";
System.out.println("\tError: " + error);
throw new IdentityAssertionException(error);
}
String tokenStr = new String(tokenBytes);
if (!(tokenStr.startsWith(TOKEN_PREFIX))) {
String error = "SimpleSampleIdentityAsserter received unknown token string \""
+ type + "\"." + " Expected " + TOKEN_PREFIX + "username";
System.out.println("\tError: " + error);
throw new IdentityAssertionException(error);
}
String userName = tokenStr.substring(TOKEN_PREFIX.length());
System.out.println("\tuserName\t= " + userName);
return new SimpleSampleCallbackHandlerImpl(userName);
}
public AppConfigurationEntry getLoginModuleConfiguration()
{
return null;
}
public AppConfigurationEntry getAssertionModuleConfiguration()
{
return null;
}
public PrincipalValidator getPrincipalValidator()
{
return null;
}
}

例5-5は、SampleIdentityAsserterProviderImpl.javaランタイム・クラスとともに使用するCallbackHandlerのサンプル実装を示しています。このCallbackHandlerの実装は、認証プロバイダのLoginModuleにユーザー名を送り返すために使用します。

例5-5 SampleCallbackHandlerImpl.java

package examples.security.providers.identityassertion.simple;
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.NameCallback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.UnsupportedCallbackException;
/*package*/ class SimpleSimpleSampleCallbackHandler implements CallbackHandler
{
private String userName;
/*package*/ SimpleSampleCallbackHandlerImpl(String user)
{
userName = user;
}
public void handle(Callback[] callbacks) throws UnsupportedCallbackException
{
for (int i = 0; i < callbacks.length; i++) {
Callback callback = callbacks[i];
if (!(callback instanceof NameCallback)) {
throw new UnsupportedCallbackException(callback, "Unrecognized
Callback");
}
NameCallback nameCallback = (NameCallback)callback;
nameCallback.setName(userName);
}
}
}

WebLogic MBeanMakerを使用してMBeanタイプを生成する

カスタム・セキュリティ・プロバイダのMBeanタイプを生成する前に、以下の作業が必要です。

- MBeanタイプが必要な理由について

- 拡張および実装するSSPI MBeanの決定

- MBean定義ファイル(MDF)の基本的な要素について

- SSPI MBeanの階層と管理コンソールに対する影響について

- WebLogic MBeanMakerによって提供されるものについて

この情報を理解し、設計に関する判断を下したら、次の手順でカスタムIDアサーション・プロバイダのMBeanタイプを作成します。

1. MBean定義ファイル(MDF)の作成

2. WebLogic MBeanMakerを使用してMBeanタイプを生成する

3. WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

4. WebLogic Server環境にMBeanタイプをインストールする

注意:

複数のセキュリティ・プロバイダのサンプルで、これらの手順の実行方法を示します。

この節で説明する手順はすべて、Windows環境での作業を想定しています。

MBean定義ファイル(MDF)の作成

MBean定義ファイル(MDF)を作成するには、次の手順に従います。

1. サンプルIDアサーション・プロバイダのMDFをテキスト・ファイルにコピーします。

注意:

サンプルのIDアサーション・プロバイダのMDFは、SampleIdentityAsserter.xmlです。

2. MDFで<MBeanType>要素と<MBeanAttribute>要素の内容をカスタムIDアサーション・プロバイダに合わせて修正します。次に、Base64DecodingRequired属性をfalseに設定する例を示します。

<MBeanAttribute
Name         = "Base64DecodingRequired"
Type         = "boolean"
Writeable    = "false"
Default      = "false"
Description  = "See MyIdentityAsserter-doc.xml."
/>

3. カスタム属性および操作(つまり、<MBeanAttribute>および<MBeanOperation>要素)をMDFに追加します。

4. ファイルを保存します。

注意:

MDF要素の構文についての詳細なリファレンスは、付録A「MBean定義ファイル(MDF)要素の構文」に収められています。

WebLogic MBeanMakerを使用してMBeanタイプを生成する

MDFを作成したら、WebLogic MBeanMakerを使用してそれを実行できます。WebLogic MBeanMakerは現在のところコマンドライン・ユーティリティで、入力としてMDFを受け取り、MBeanインタフェース、MBean実装、関連するMBean情報ファイルなどの中間Javaファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム・セキュリティ・プロバイダのMBeanタイプになります。

MBeanタイプの生成手順は、カスタムIDアサーション・プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。

- オプショナルSSPI MBeanとカスタム操作を追加しない場合

- オプショナルSSPI MBeanまたはカスタム操作を追加する場合

オプショナルSSPI MBeanとカスタム操作を追加しない場合

カスタムIDアサーション・プロバイダのMDFがオプショナルSSPI MBeanを実装せず、かつ、いかなるカスタム操作も含まない場合、次の手順に従います。

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまりIDアサーション・プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

3. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

オプショナルSSPI MBeanまたはカスタム操作を追加する場合

カスタムIDアサーション・プロバイダのMDFがオプショナルSSPI MBeanまたはカスタム操作を実装する場合、以下の質問に答えながら手順を進めてください。

MBeanタイプを作成するのは初めてですか。その場合は、次の手順に従ってください:

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまりIDアサーション・プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

3. オプショナルSSPI MBeanをMDFに実装した場合は、次の手順に従います。

1. MBean実装ファイルを見つけます。
WebLogic MBeanMakerによって生成されるMBean実装ファイルには、MBeanNameImpl.javaという名前が付けられます。たとえば、SampleIdentityAsserterという名前のMDFの場合、編集されるMBean実装ファイルはSampleIdentityAsserterImpl.javaという名前になります。

2. MDFで実装したオプショナルSSPI MBeanごとに、各メソッドを実装します。オプショナルSSPI MBeanが継承するメソッドもすべて実装してください。

4. MDFにカスタム操作を含めた場合、メソッド・スタブを使用してメソッドを実装します。

5. ファイルを保存します。

6. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

既存のMBeanタイプの更新ですか。その場合は、次の手順に従ってください:

1. WebLogic MBeanMakerによって現在のメソッドの実装が上書きされないように、既存のMBean実装ファイルを一時ディレクトリにコピーします。

2. 新しいDOSシェルを作成します。

3. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまりIDアサーション・プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

4. オプショナルSSPI MBeanをMDFに実装した場合は、次の手順に従います。

1. MBean実装ファイルを見つけて開きます。
WebLogic MBeanMakerによって生成されるMBean実装ファイルには、MBeanNameImpl.javaという名前が付けられます。たとえば、SampleIdentityAsserterという名前のMDFの場合、編集されるMBean実装ファイルはSampleIdentityAsserterImpl.javaという名前になります。

2. ステップ1で一時ディレクトリに保存した既存のMBean実装ファイルを開きます。

3. 既存のMBean実装ファイルを、WebLogic MBeanMakerによって生成されたMBean実装ファイルと同期させます。
これには、メソッドの実装を既存のMBean実装ファイルから新しく生成されたMBean実装ファイルにコピー(または、新しく生成されたMBean実装ファイルから既存のMBean実装ファイルに新しいメソッドを追加)し、いずれのMBean実装ファイルにも入っているメソッドのメソッド・シグネチャへの変更が、使用するMBean実装ファイルに反映されていることを確認するといった作業が必要です。

4. MDFを修正して元のMDFにはないオプショナルSSPI MBeanを実装した場合は、各メソッドを実装します。オプショナルSSPI MBeanが継承するメソッドもすべて実装してください。

5. MDFを変更して元のMDFにはないカスタム操作を含めた場合、メソッド・スタブを使用してメソッドを実装します。

6. 完成した、つまりすべてのメソッドを実装したMBean実装ファイルを保存します。

7. このMBean実装ファイルを、WebLogic MBeanMakerがMBeanタイプの実装ファイルを配置したディレクトリにコピーします。このディレクトリは、手順3でfilesdirとして指定したものです。(ステップ3の結果としてWebLogic MBeanMakerで生成されたMBean実装ファイルがオーバーライドされます)。

8. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

生成されるMBeanインタフェース・ファイルについて

MBeanインタフェース・ファイルとは、ランタイム・クラスまたはMBean実装が構成データを取得するために使用するMBeanのクライアント側APIです。「「Provider」SSPIの目的について」で説明されているように、これはinitializeメソッドで使用するのが一般的です。

WebLogic MBeanMakerでは、作成済のMDFからMBeanタイプを生成するので、生成されるMBeanインタフェース・ファイルの名前は、そのMDF名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMakerを使用してSampleIdentityAsserter MDFを実行すると、SampleIdentityAsserterMBean.javaという名前のMBeanインタフェース・ファイルが生成されます。

WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

WebLogic MBeanMakerでMDFを実行して中間ファイルを作成し、MBean実装ファイルを編集して適切なメソッドの実装を提供したら、カスタムIDアサーション・プロバイダのMBeanファイルとランタイム・クラスをMBean JARファイル(MJF)にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMakerによって自動化されます。

カスタムIDアサーション・プロバイダのMJFを作成するには、次の手順を行います。

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMJF=jarfile -Dfiles=filesdir weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMJFフラグはWebLogic MBeanMakerが新しいMBeanタイプを含むJARファイルを構築すべきであることを示し、jarfileはMJFの名前、filesdirはWebLogic MBeanMakerでMJFにJAR化する対象ファイルが存在する場所を示します。

この時点でコンパイルが行われるので、エラーが発生するおそれがあります。jarfileが指定されていて、エラーが発生しなかった場合には、指定された名前のMJFが作成されます。

注意:

カスタム・セキュリティ・プロバイダのJARファイルを作成する際には、一連のXMLバインディング・クラスと1つのスキーマも生成されます。そのスキーマに関連付けるネームスペースを選択できます。それにより、使用しているカスタム・クラスとOracleのカスタム・クラスとの競合を防ぐことができます。ネームスペースのデフォルトはvendorです。-targetNameSpace引数をWebLogicMBeanMakerまたは関連するWLMBeanMaker antタスクに渡すことで、このデフォルトを変更できます。

既存のMJFを更新する場合は、単純にMJFを削除して再生成します。WebLogic MBeanMakerにも -DIncludeSourceオプションがあり、それを指定すると、生成されるMJFにソース・ファイルを含めるかどうかを制御できます。ソース・ファイルには、生成されたソースとMDFそのものがあります。デフォルトはfalseです。このオプションは、-DMJFを使用しない場合には無視されます。

生成されたMJFは、自らのWebLogic Server環境にインストールすることも、顧客に配布してそれぞれのWebLogic Server環境にインストールしてもらうこともできます。

WebLogic Server環境にMBeanタイプをインストールする

MBeanタイプをWebLogic Server環境にインストールするには、MJFをWL_HOME\server\lib\mbeantypesディレクトリにコピーします。ここで、WL_HOMEはWebLogic Serverの最上位のインストール・ディレクトリです。これで、カスタムIDアサーション・プロバイダが「デプロイ」されます。つまり、カスタムIDアサーション・プロバイダがWebLogic Server管理コンソールから管理できるようになります。

注意:

MBeanタイプをインストールするデフォルトのディレクトリは、WL_HOME\server\lib\mbeantypesです。初めて使用するバージョンが9.0の場合、セキュリティ・プロバイダは...\domaindir\lib\mbeantypesからもロードできます。ただし、サーバーを起動するときに-Dweblogic.alternateTypesDirectory=<dirコマンドライン・フラグを使用すれば、WebLogic Serverが追加ディレクトリでMBeanタイプを検索します。<dirは、ディレクトリ名のカンマ区切りのリストです。このフラグを使用する場合、WebLogic Serverは常に最初にWL_HOME\server\lib\mbeantypesからMBeanタイプをロードします。その後で、追加ディレクトリにあるすべての有効なアーカイブを検索して、ロードします。このとき拡張子は考慮されません。たとえば、-Dweblogic.alternateTypesDirectory = dirX,dirYの場合、WebLogic ServerはまずWL_HOME\server\lib\mbeantypesからMBeanタイプをロードし、次にdirXおよびdirYにある有効なアーカイブをロードします。WebLogic Serverに追加ディレクトリでMBeanタイプを検索するよう指示する際に、Javaセキュリティ・マネージャを使用している場合は、weblogic.policyファイルを更新して、MBeanタイプ(その結果として、カスタム・セキュリティ・プロバイダ)に適した許可を付与することも必要になります。詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』のJavaセキュリティを使用したWebLogicリソースの保護に関する項を参照してください。

カスタムIDアサーション・プロバイダを構成することによって(「管理コンソールによるカスタムIDアサーション・プロバイダの構成」を参照)、MBeanタイプのインスタンスを作成して、GUI、他のJavaコード、またはAPIからそれらのMBeanインスタンスを使用することができます。たとえば、WebLogic Server管理コンソールを使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他のJavaオブジェクトを開発して、そのオブジェクトでMBeanをインスタンス化し、それらのMBeanから提供される情報に自動的に応答させることもできます。なお、これらのMBeanインスタンスをバックアップしておくことをお薦めします。

管理コンソールによるカスタムIDアサーション・プロバイダの構成

カスタムIDアサーション・プロバイダを構成するということは、そのカスタムIDアサーション・プロバイダをセキュリティ・レルムに追加するということです。追加されたカスタムIDアサーション・プロバイダには、ID断定サービスを必要とするアプリケーションからアクセスできます。

カスタム・セキュリティ・プロバイダの構成は管理タスクですが、カスタム・セキュリティ・プロバイダの開発者が行うこともできます。

注意:

WebLogic Server管理コンソールを使用してIDアサーション・プロバイダを構成する手順は、『Oracle WebLogic Serverの保護』のWebLogicセキュリティ・プロバイダの構成に関する項で説明されています。

チャレンジIDアサーション

チャレンジIDアサーション・インタフェースは、複数のチャレンジ、レスポンス・メッセージ、および状態を必要とするチャレンジ・レスポンス・スキームをサポートします。チャレンジIDアサーション・プロバイダ・インタフェースを使用すると、IDアサーション・プロバイダは、MicrosoftのWindows NTチャレンジ/レスポンス(NTLM)やSPNEGO (Simple and Protected GSS-API Negotiation)などのチャレンジ/レスポンス認証メカニズムを採用した認証プロトコルをサポートできます。

JavaサーブレットAPI 2.3環境におけるチャレンジ/レスポンスの制限

WebLogicセキュリティ・フレームワークを使用すると、カスタム認証プロバイダおよびカスタムIDアサーション・プロバイダを利用できます。ただし、JavaサーブレットAPI 2.3の仕様により、認証プロセス時は、認証プロバイダとクライアントまたは他のサーバーとの間の対話は制限されます。これにより、認証メカニズムは、サーブレット・コンテナが提供する認証メカニズムと互換性のある基本、フォーム、証明書の形式に制限されます。

サーブレット認証フィルタ(第13章「サーブレット認証フィルタ」を参照)には、アーキテクチャ依存の制限はほとんどありません。つまり、サーブレット認証フィルタは、サーブレット・コンテナが提供する認証メカニズムに依存していません。認証プロセスを開始するコンテナの前にフィルタを呼び出せるようにすれば、セキュリティ・レルムは、より柔軟な認証メカニズムを実装できます。たとえば、サーブレット認証フィルタを使用すると、認証用のSAMLプロバイダ・サイトにユーザーをリダイレクトできます。

サーブレット認証フィルタでは、ユーザーの環境にチャレンジ/レスポンス・プロトコルを簡単に実装できます。フィルタを使用すると、ユーザーのチャレンジ/レスポンス・メカニズムでチャレンジを完了するまで必要なだけチャレンジIDアサーション・インタフェースをループさせることができます。

weblogic.security.services.Authenticationクラスのフィルタと役割

サーブレット認証フィルタを使用すると、サーブレット・コンテナと互換性のある認証メカニズムに制限されることなくチャレンジ/レスポンス・プロトコルを実装できます。ただし、サーブレット認証フィルタは、セキュリティ・フレームワークで提供されている認証環境の外側で機能するので、セキュリティ・フレームワークを利用してプロバイダのコンテキストを判別することはできません。また、サーブレット認証フィルタでは、APIでチャレンジ回数が複数のIDアサーション・プロセスを駆動させる必要があります。

weblogic.security.services.Authenticationクラスが拡張され、サーブレット認証フィルタからの複数のチャレンジ/レスポンスIDアサーションが可能になりました。メソッドおよびインタフェースでは、ChallengeIdentityAsserterV2インタフェースとProviderChallengeContextインタフェースのラッパーが提供されるので、サーブレット認証フィルタから呼び出すことができます。

これ以外に、セキュリティ・フレームワークのコンテキスト内でサーブレット認証フィルタから複数のチャレンジ/レスポンス・ダイアログを実行する方法はドキュメント化されていません。サーブレット認証フィルタは、ChallengeIdentityAsserterV2インタフェースおよびProviderChallengeContextインタフェースを直接呼び出すことはできません。

そのため、ChallengeIdentityAsserterV2インタフェースとProviderChallengeContextインタフェースを実装し、weblogic.security.services.AuthenticationのメソッドとAppChallengeContextインタフェースを使用してサーブレット認証フィルタからそれらのインタフェースを呼び出す必要があります。

チャレンジIDアサーション・プロバイダの開発方法

チャレンジIDアサーション・プロバイダを開発するには:

- AuthenticationProviderV2 SSPIの実装

- IdentityAsserterV2 SSPIの実装

- ChallengeIdentityAsserterV2インタフェースの実装

- weblogic.security.servicesのチャレンジIDメソッドの呼出し

- weblogic.security.servicesのAppChallengeContextメソッドの呼出し

ChallengeIdentityAsserterV2インタフェースの実装

ChallengeIdentityAsserterV2インタフェースは、IdentityAsserterV2 SSPIを拡張します。IdentityAsserterV2 SSPIに加えて、ChallengeIdentityAsserterV2インタフェースを実装する必要があります。

すべてのIdentityAsserterV2メソッドおよび次のメソッドの実装を提供します。

- assertChallengeIdentity

ProviderChallengeContext assertChallengeIdentity(String tokenType, Object token, ContextHandler handler)

提供されているクライアント・トークンを使用し、場合によっては複数回のチャレンジでクライアントIDを確立します。このメソッドは、ProviderChallengeContextインタフェースの実装を返します。ProviderChallengeContextインタフェースには、チャレンジの状態を問い合せる手段があります。

- continueChallengeIdentity

void continueChallengeIdentity(ProviderChallengeContext context, String tokenType, Object token,
ContextHandler handler)

提供されているプロバイダ・コンテキストとクライアント・トークンを使用して、クライアントIDの確立を続行します。

- getChallengeToken

Object getChallengeToken(String type, ContextHandler handler)

このメソッドは、IDアサーション・プロバイダのチャレンジ・トークンを返します。

ProviderChallengeContextインタフェースの実装

ProviderChallengeContextインタフェースには、チャレンジの状態を問い合せる手段があります。ChallengeIdentityAsserterV2インタフェースのassertChallengeIdentityメソッドおよびcontinueChallengeIdentityメソッドを使用し、コールバック・ハンドラか、クライアントが応答する必要がある新しいチャレンジを返すことができます。

ProviderChallengeContextインタフェースを実装するには、以下のメソッドの実装を提供する必要があります。

- getCallbackHandler

CallbackHandler getCallbackHandler()

このメソッドは、チャレンジIDアサーションのコールバック・ハンドラを返します。hasChallengeIdentityCompletedメソッドがtrueを返した場合にのみ、このメソッドを呼び出します。

- getChallengeToken

Object getChallengeToken()

このメソッドは、チャレンジIDアサーションのチャレンジ・トークンを返します。hasChallengeIdentityCompletedメソッドがfalseを返した場合にのみ、このメソッドを呼び出します。

- hasChallengeIdentityCompleted

boolean hasChallengeIdentityCompleted

このメソッドは、チャレンジIDアサーションが完了したかどうかを返します。このメソッドは、チャレンジIDアサーションが完了した場合はtrue、完了していない場合はfalseを返します。trueの場合、呼出し側はgetCallbackHandlerメソッドを使用する必要があります。falseの場合、呼出し側はgetChallengeTokenメソッドを使用する必要があります。

weblogic.security.servicesのチャレンジIDメソッドの呼出し

ChallengeIdentityAsserterV2 SSPIを直接呼び出すのではなく、サーブレット認証フィルタからweblogic.security.services.Authenticationの次のメソッドを呼び出します。

- assertChallengeIdentity

AppChallengeContext assertChallengeIdentity(String tokenType, Object token, AppContext appContext)

提供されているクライアント・トークンを使用し、場合によっては複数回のチャレンジでクライアントIDを確立します。このメソッドは、チャレンジIDアサーションのコンテキストを戻します。この結果には、認証されたサブジェクトか、クライアントが応答する必要がある追加チャレンジが含まれる可能性があります。AppChallengeContextインタフェースには、チャレンジの状態を問い合せる手段があります。

- continueChallengeIdentity

void continueChallengeIdentity(AppChallengeContext context, String tokenType,
Object token, AppContext appContext)

提供されているプロバイダ・コンテキストとクライアント・トークンを使用して、クライアントIDの確立を続行します。

- getChallengeToken

Object getChallengeToken

このメソッドは、チャレンジIDアサーションの初期チャレンジ・トークンを返します。

weblogic.security.servicesのAppChallengeContextメソッドの呼出し

ProviderChallengeContextインタフェースを直接呼び出すのではなく、サーブレット認証フィルタからAppChallengeContextの次のメソッドを呼び出します。

- getAuthenticatedSubject

Subject getAuthenticatedSubject()

このメソッドは、チャレンジIDアサーションで認証されたサブジェクトを返します。hasChallengeIdentityCompletedメソッドがtrueを返した場合にのみ、このメソッドを呼び出します。

- getChallengeToken

Object getChallengeToken()

このメソッドは、チャレンジIDアサーションのチャレンジ・トークンを返します。hasChallengeIdentityCompletedメソッドがfalseを返した場合にのみ、このメソッドを呼び出します。

- hasChallengeIdentityCompleted

boolean hasChallengeIdentityCompleted()

このメソッドは、チャレンジIDアサーションが完了したかどうかを返します。このメソッドは、チャレンジIDアサーションが完了した場合はtrue、完了していない場合はfalseを返します。trueの場合、呼出し側はgetCallbackHandlerメソッドを使用する必要があります。falseの場合、呼出し側はgetChallengeTokenメソッドを使用する必要があります。

フィルタからのチャレンジIDアサーションの実装

以下のコード・フローでは、サーブレット認証フィルタ(第13章「サーブレット認証フィルタ」を参照)は、HTTPレベルの対話(AuthorizationおよびWWW-Authenticate)を処理するとともに、weblogic.security.services.Authenticationメソッドとインタフェースを呼び出してチャレンジIDアサーション・プロセスを駆動させる役割も果たしています。

1. ブラウザがリクエストを送信します。

2. フィルタは、リクエストを認識してAuthorizationヘッダーがないことを判別すると、weblogic.security.services.Authentication getChallengeTokenメソッドを呼び出して初期トークンを取得し、WWW-Authenticateネゴシエーション・ヘッダー付きの401レスポンスを返します。

3. ブラウザは、WWW-Authenticate付きの401を認識し、新しいリクエストと認証ネゴシエーション・トークン付きの応答を返します。

1. フィルタは、これを認識してweblogic.security.services.AuthenticationのassertChallengeIdentityメソッドを呼び出します。assertChallengeIdentityは、トークンを入力として取り、アサーション・プロセスで従う必要があるルールに従ってそれを処理し(たとえば、NTLMの場合は、トークン処理用にNTLMで要求されている処理を行います)、その処理が成功したかどうかを判別します。assertChallengeIdentityは、AppChallengeContextインタフェースの実装を戻します。

2. フィルタはappChallengeContext hasChallengeCompletedメソッドを呼び出します。AppChallengeContext hasChallengeIdentityCompletedメソッドを使用して、チャレンジが完了したかどうかを確認します。たとえば、このメソッドは、コールバック・ハンドラがnullでない(つまりユーザー名が含まれている)かどうかを判別し、trueを返すことができます。ここでは、falseが返されるので、別のチャレンジをクライアントに発行する必要があります。フィルタは、次にAppChallengeContext getChallengeTokenを呼び出し、チャレンジを再試行するためのトークンを取得します。

3. フィルタは、おそらくセッション属性などにAppChallengeContextを格納しています。

4. フィルタは、WWW-Authenticateネゴシエーションと新しいトークン付きの401レスポンスを送信します。

4. ブラウザは、新しいチャレンジを認識し、Authorizationヘッダーを付けて再び応答します。

1. フィルタは、これを認識してweblogic.security.services.Authentication continueChallengeIdentityメソッドを呼び出します。

2. フィルタはAppChallengeContext hasChallengeCompletedメソッドを呼び出します。falseが返された場合は、別のチャレンジが用意されるので、AppChallengeContext getChallengeTokenメソッドを呼び出して、チャレンジを再試行するためのトークンを取得します(以降、falseの場合は同じ処理が繰り返されます)。trueが返された場合、チャレンジは完了したことになり、フィルタは次にAppChallengeContext getAuthenticatedSubjectメソッドを呼び出し、runAs(subject, request)を実行します。

6 プリンシパル検証プロバイダ

この章では、プリンシパル検証プロバイダの概念と機能、およびカスタム・プリンシパル検証プロバイダの開発手順について説明します。

認証プロバイダは、プリンシパル検証プロバイダを利用して、サブジェクトに格納されるプリンシパル(ユーザーとグループ)に署名し、信頼性を検証します。こうした検証によって、信頼度は向上し、悪意のあるプリンシパルによる改ざんの可能性を低くすることができます。サブジェクトのプリンシパルの検証は、WebLogic Serverで各呼出しのRMIクライアント・リクエストがデマーシャリングされる際に行われます。サブジェクトのプリンシパルの信頼性も、認可判定の際に検証されます。

以下の節では、プリンシパル検証プロバイダの概念と機能、およびカスタム・プリンシパル検証プロバイダの開発手順について説明します。

- プリンシパル検証の概念

- プリンシパル検証プロセス

- カスタム・プリンシパル検証プロバイダを開発する必要があるか

- カスタム・プリンシパル検証プロバイダの開発方法

プリンシパル検証の概念

プリンシパル検証プロバイダを開発する前に、以下の概念を理解しておく必要があります。

- プリンシパル検証とプリンシパル・タイプ

- プリンシパル検証プロバイダと他のタイプのセキュリティ・プロバイダの違い

- 無効なプリンシパルが原因のセキュリティ例外

プリンシパル検証とプリンシパル・タイプ

IDアサーション・プロバイダが特定のタイプのトークンをサポートするように、プリンシパル検証プロバイダも特定のタイプのプリンシパルをサポートします。たとえば、WebLogicプリンシパル検証プロバイダ(「カスタム・プリンシパル検証プロバイダを開発する必要があるか」を参照)はWebLogic Serverプリンシパルの署名と信頼性の検証を行います。

構成済みの認証プロバイダに関連付けられているプリンシパル検証プロバイダ(「プリンシパル検証プロバイダと他のタイプのセキュリティ・プロバイダの違い」を参照)は、サブジェクトに格納されていてそのプリンシパル検証プロバイダがサポートするタイプの全プリンシパルに対して署名と検証を行います。

プリンシパル検証プロバイダと他のタイプのセキュリティ・プロバイダの違い

プリンシパル検証プロバイダは、主に認証プロバイダの「ヘルパー」として機能する特殊なセキュリティ・プロバイダです。プリンシパル検証プロバイダの主要な機能は、サブジェクトに格納されたプリンシパルが悪意のある個人によって改ざんされるのを防止することです。

AuthenticationProvider SSPI (「AuthenticationProviderV2 SSPIの実装」を参照)には、getPrincipalValidatorというメソッドが含まれています。このメソッドでは、認証プロバイダと共に使用するプリンシパル検証プロバイダのランタイム・クラスを指定します。プリンシパル検証プロバイダのランタイム・クラスとしては、Oracle提供のもの(WebLogicプリンシパル検証プロバイダ)か、独自に開発したもの(カスタム・プリンシパル検証プロバイダ)を使用できます。認証プロバイダのgetPrincipalValidatorメソッドでWebLogicプリンシパル検証プロバイダを使用する例については、「例4-0 、「ユーザー、グループ、プリンシパル、およびサブジェクト間の関係」」を参照してください。

WebLogic Server管理コンソールを使用して認証プロバイダのMBeanタイプを生成し、認証プロバイダを構成するので、プリンシパル検証プロバイダでそれらの手順を行う必要はありません。

無効なプリンシパルが原因のセキュリティ例外

認証(または認可)処理を行うときに、WebLogicセキュリティ・フレームワークはサブジェクトのプリンシパルを調べてそれが有効かどうかを確認します。プリンシパルが無効の場合、WebLogicセキュリティ・フレームワークはサブジェクトが無効であることを示すテキストを付けてセキュリティ例外をスローします。サブジェクトが無効になる原因には以下のものがあります。

- サブジェクトのプリンシパルに対応するプリンシパル検証プロバイダが構成されていません(つまりWebLogicセキュリティ・フレームワークでそのサブジェクトを検証する手段がありません)

注意:

サブジェクトには複数のプリンシパルを格納できるため(それぞれ異なる認証プロバイダのLoginModuleによって格納される)、プリンシパルは複数の異なるプリンシパル検証プロバイダを持つことができます。

- このセキュリティ・ドメインとは異なる資格証明を使用する別のWebLogic Serverセキュリティ・ドメインで署名されたプリンシパルがあり、呼出し側がそれを現在のドメインで使用しようとしている

- セキュリティを低下させる目的で作成された無効な署名を持つプリンシパルがある

- プリンシパルが署名されていないサブジェクトがある

プリンシパル検証プロセス

図6-1に示すとおり、ユーザーはユーザー名とパスワードの組み合わせを使ってシステムにログインしようとします。WebLogic Serverは、構成済みの認証プロバイダのLoginModuleを呼び出すことによって信頼を確立します。LoginModuleは、ユーザーのユーザー名とパスワードを検証し、JAAS (Java Authentication and Authorization Service)の要件に従って、プリンシパルが格納されたサブジェクトを返します。

図6-1 プリンシパル検証プロセス

「図6-1 プリンシパル検証プロセス」の説明

WebLogic Serverは、指定されたプリンシパル検証プロバイダにサブジェクトを渡します。プリンシパル検証プロバイダは、そのプリンシパルに署名して、それらをWebLogic Serverを通じてクライアント・アプリケーションに返します。他のセキュリティ操作のためにサブジェクト内のプリンシパルが必要になった場合、同じプリンシパル検証プロバイダが、そのプリンシパルが署名時から変更されていないかどうかを検証します。

カスタム・プリンシパル検証プロバイダを開発する必要があるか

WebLogic Serverのデフォルト(アクティブ)セキュリティ・レルムには、WebLogicプリンシパル検証プロバイダが含まれます。IDアサーション・プロバイダが特定のタイプのトークンをサポートするのと同じように、プリンシパル検証プロバイダは特定のタイプのプリンシパルに対する署名と信頼性の確認を行います。WebLogicプリンシパル検証プロバイダは、WebLogic Serverプリンシパルの署名と検証を行います。言い換えると、WebLogic ServerユーザーまたはWebLogic Serverグループを表すプリンシパルに対して署名と検証を行います。

注意:

WLSPrincipalsクラス(weblogic.securityパッケージ内)を使用すると、プリンシパル(ユーザーまたはグループ)がWebLogic Serverにとって特別な意味を持つものかどうかを判断できます(つまり、あらかじめ定義されたWebLogic ServerユーザーやWebLogic Serverグループかどうかを判断できます)。さらに、WebLogic Serverユーザーまたはグループを表すプリンシパルは、weblogic.security.spiパッケージのWLSUserインタフェースとWLSGroupインタフェースを実装する必要があります。

WLSPrincipalsは、セキュリティ・フレームワークではなくPrincipalValidatorImplでのみ使用されます。認証プロバイダは、独自のプリンシパル検証プロバイダを実装することも、PrincipalValidatorImplを使用することもできます。認証プロバイダでカスタム・プリンシパル検証プロバイダを構成する場合、WLSPrincipalsインタフェースは使用されません。

認証プロバイダは、PrincipalValidatorImplを使用する場合、WLSPrincipalsインタフェースを実装する必要があります。

WebLogicプリンシパル検証プロバイダには、WLSUserImplおよびWLSGroupImplという名前のWLSUserインタフェースおよびWLSGroupインタフェースの実装が含まれています。これらは、weblogic.security.principalパッケージに定義されています。また、PrincipalValidatorImplという名前のPrincipalValidator SSPIの実装も含まれています。これはweblogic.security.providerパッケージに定義されています。PrincipalValidatorImplクラスのsign()メソッドは、ランダム・シードを生成し、そのランダム・シードに基づいてダイジェストを計算します。(PrincipalValidator SSPIの詳細については、「PrincipalValidator SSPIの実装」を参照してください。)

WebLogicプリンシパル検証プロバイダの使い方

名前が付いているだけの単純なユーザーおよびグループ・プリンシパルがある状態で、WebLogicプリンシパル検証プロバイダを使用する場合には、以下の方法があります。

- weblogic.security.principal.WLSUserImplクラスとweblogic.security.principal.WLSGroupImplクラスを使用します。

- weblogic.security.provider.PrincipalValidatorImplクラスを使用します。

名前の他に追加のデータ・メンバーがあるユーザーおよびグループ・プリンシパルがある状態で、WebLogicプリンシパル検証プロバイダを使用する場合には、以下の方法があります。

- 独自のUserImplクラスとGroupImplクラスを記述します。

- weblogic.security.principal.WLSAbstractPrincipalクラスを拡張します。

- weblogic.security.spi.WLSUserインタフェースとweblogic.security.spi.WLSGroupインタフェースを実装します。

- equals()メソッドを実装して、追加のデータ・メンバーを含めます。実装では、WLSAbstractPrincipalが残りのデータを検証できるように、完了時にsuper.equals()メソッドを呼び出す必要があります。

注意:

デフォルトでは、ユーザー名とグループ名だけが検証されます。追加のデータ・メンバーも検証する場合は、続いてgetSignedData()メソッドを実装します。

- weblogic.security.provider.PrincipalValidatorImplクラスを使用します。

独自の検証スキームがあり、WebLogicプリンシパル検証プロバイダを使用しない場合や、WebLogic Serverプリンシパル以外のプリンシパルを検証する場合は、カスタム・プリンシパル検証プロバイダを開発する必要があります。

カスタム・プリンシパル検証プロバイダの開発方法

カスタム・プリンシパル検証プロバイダを開発するには、以下の方法があります。

- 以下の実装を行うことによって、独自のUserImplクラスとGroupImplクラスを記述します。

- weblogic.security.spi.WLSUserインタフェースとweblogic.security.spi.WLSGroupインタフェースを実装します。

- java.io.Serializableインタフェースを実装します。

- weblogic.security.spi.PrincipalValidator SSPIを実装することによって、独自のPrincipalValidationImplクラスを記述する(「PrincipalValidator SSPIの実装」を参照)。

PrincipalValidator SSPIの実装

PrincipalValidator SSPIを実装するには、以下のメソッドの実装を提供する必要があります。

- validate

public boolean validate(Principal principal) throws SecurityException;

validateメソッドは1つのプリンシパルを1つの引数として取り、その有効性を検証しようとします。すなわち、このメソッドは、そのプリンシパルが署名されてから変更されていないかどうかを確認します。

- sign

public boolean sign(Principal principal);

signメソッドは1つのプリンシパルを1つの引数として取り、それに署名して信頼を保証します。これにより、validateメソッドを使って、後でそのプリンシパルを検証できるようになります。

signメソッドの実装は、悪意のある個人が容易に再現することのできない機密アルゴリズムでなければなりません。そのアルゴリズムをsignメソッド自体に組み込むか、signメソッドがプリンシパルの署名に使用するトークンをサーバーに要求するようにするか、またはプリンシパルに署名する他の手段を実装できます。

- getPrincipalBaseClass

public Class getPrincipalBaseClass();

getPrincipalBaseClassメソッドは、このプリンシパル検証プロバイダが検証と署名の方法を認識しているプリンシパルのベース・クラスを返します。

PrincipalValidator SSPIと前述のメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

7 認可プロバイダ

この章では、認可プロバイダの概念と機能、およびカスタム認可プロバイダの開発手順について説明します。

認可とは、ユーザーのIDなどの情報に基づいて、ユーザーとWebLogicリソースとの対話を管理するプロセスのことです。言い換えれば、認可とは「自分は何にアクセスできますか」という質問に答えるものです。WebLogic Serverでは、認可プロバイダはユーザーとWebLogicリソースとの対話を制限して、整合性、機密性、および可用性を確保します。

以下の節では、認可プロバイダの概念と機能、およびカスタム認可プロバイダの開発手順について説明します。

- 認可の概念

- 認可プロセス

- カスタム認可プロバイダを開発する必要があるか

- カスタム認可プロバイダはスレッド・セーフか

- カスタム認可プロバイダの開発方法

認可の概念

認可プロバイダを開発する前に、以下の概念を理解しておく必要があります。

- アクセス決定

- Java Authorization Contract for Containersの使用

- セキュリティ・プロバイダとWebLogicリソース

アクセス決定

認証プロバイダのLoginModuleと同じく、アクセス決定は、「アクセスは許可されるのか」という質問に答える認可プロバイダのコンポーネントです。具体的には、指定された操作をWebLogicリソースに対して実行する権限をサブジェクトが持っているかどうかが、アプリケーション内の特定のパラメータを用いてアクセス決定に質問されます。この情報が与えられると、アクセス決定はそれに対する回答をPERMIT、DENY、またはABSTAINのいずれかで返します。

注意:

アクセス決定の詳細は、「AccessDecision SSPIの実装」を参照してください。

Java Authorization Contract for Containersの使用

Java Authorization Contract for Containers (JACC)はJava EEの一部です。JACCは、EJBおよびサーブレットに対する権限ベースのセキュリティ・モデルです。JACCはJSR-115 (http://www.jcp.org/en/jsr/detail?id=115)によって定義されます。

JACCは、WebLogic Serverドメイン内のEJBおよびサーブレット・コンテナに代替認可メカニズムを提供します。JACCが構成されている場合、WebLogicセキュリティ・フレームワークのアクセス決定、裁決、およびロール・マッピング機能は、EJBおよびサーブレットの認可判定には使用されません。

注意:

WebLogicセキュリティ・フレームワークと一緒にJACCフレームワークを使用することはできません。WebLogic Serverで使用されるJACCクラスには、決定を下すためのポリシー・オブジェクトの実装は含まれません。かわりに、JACCクラスは、java.security.Policy (http://download.oracle.com/javase/6/docs/api/java/security/Policy.html)オブジェクトに依存します。

WebLogic Serverは、JSR-115に完全に準拠しているものの、WebLogic認証プロバイダほどには最適化されていないJACCプロバイダを実装します。Java JACCクラスは、アクセス決定を下す際に使用します。JSR-115はロール・マッピングに対処する方法を定義しないので、ロールとプリンシパルの間のマッピングにはWebLogic JACCクラスが使用されます。JACCプロバイダの開発の詳細は、http://docs.oracle.com/javaee/6/api/javax/security/jacc/package-frame.htmlを参照してください。

認可プロセス

図7-1に、認可プロセスにおける認可プロバイダ(および関連する裁決プロバイダとロール・マッピング・プロバイダ)とWebLogicセキュリティ・フレームワークとの対話を示します。その後、この図について説明します。

図7-1 認可プロバイダと認可プロセス

「図7-1 認可プロバイダと認可プロセス」の説明

一般に、認可は以下のように実行されます。

1. ユーザーまたはシステム・プロセスがWebLogicリソースをリクエストし、特定の操作を実行しようとします。

2. リクエストされたWebLogicリソースのタイプを処理するリソース・コンテナがリクエストを受け取ります。たとえばEJBコンテナはEJBリソースに対するリクエストを受け取ります。

注意:

リソース・コンテナは、「セキュリティ・プロバイダとWebLogicリソース」で説明されているWebLogicリソースのいずれかを処理するコンテナです。

3. リソース・コンテナは、ContextHandlerオブジェクトを作成します。このオブジェクトは、構成済みのロール・マッピング・プロバイダおよび認可プロバイダのアクセス決定で、そのリクエストのコンテキストに関連付けられている情報を取得する際に使用できます。

注意:

ContextHandlerの詳細は、「ContextHandlerとWebLogicリソース」を参照してください。アクセス決定の詳細は、「アクセス決定」を参照してください。ロール・マッピング・プロバイダの詳細は、第9章「ロール・マッピング・プロバイダ」を参照してください。

リソース・コンテナは、サブジェクト、WebLogicリソース、そして場合によっては決定用の追加入力を提供するContextHandlerオブジェクトを渡してWebLogicセキュリティ・フレームワークを呼び出します。

4. WebLogicセキュリティ・フレームワークは、構成済みのロール・マッピング・プロバイダを呼び出します。

5. ロール・マッピング・プロバイダはContextHandlerを用いて、リクエストに関する様々な情報をリクエストします。また、ロール・マッピング・プロバイダは、リクエストする情報のタイプを表す一連のCallbackオブジェクトを作成します。そのCallbackオブジェクト群は、handleメソッドを通じて、配列としてContextHandlerに渡されます。
ロール・マッピング・プロバイダは、Callbackオブジェクトに格納されている値、サブジェクト、およびリソースを用いて、リクエスト側のサブジェクトに付与されるセキュリティ・ロールを計算し、該当するセキュリティ・ロールをWebLogicセキュリティ・フレームワークに返します。

6. WebLogicセキュリティは、リクエストされたアクションをリソースに対して実行する資格がサブジェクトにあるかどうかに関し、実際の判定を認可プロバイダに委託します。
認可プロバイダのアクセス決定ではまた、ContextHandlerを用いてリクエストに関する様々な情報をリクエストします。アクセス決定は、リクエストする情報のタイプを表す一連のCallbackオブジェクトを作成します。そのCallbackオブジェクト群は、handleメソッドを通じて、配列としてContextHandlerに渡されます。このプロセスは、ステップ5のロール・マッピング・プロバイダの場合と同じです。

7. 構成済みの各認可プロバイダのアクセス決定のisAccessAllowedメソッドが呼び出され、リクエストされたアクセスを実行する権限がサブジェクトにあるかどうかが、ContextHandler、サブジェクト、WebLogicリソース、およびセキュリティ・ロールに基づいて判定されます。各isAccessAllowedメソッドは、以下の3つの値のいずれかを返します。

- PERMIT - リクエストされたアクセスが許可されることを示します。

- DENY - リクエストされたアクセスが明示的に拒否されることを示します。

- ABSTAIN - 明示的な判定をアクセス決定が下せなかったことを示します。

このプロセスは、すべてのアクセス決定が使用されるまで続きます。

8. WebLogicセキュリティ・フレームワークは、構成済みの認可プロバイダのアクセス決定から返された判定結果に食い違いがあった場合、その調停を裁決プロバイダに委託します。裁決プロバイダでは、認可判定の最終結果を決定します。

注意:

裁決プロバイダの詳細は、第8章「裁決プロバイダ」を参照してください。

9. 裁決プロバイダはTRUEまたはFALSEの判定を返し、この判定はWebLogicセキュリティ・フレームワークを通してリソース・コンテナに転送されます。

- 判定がTRUEの場合、リソース・コンテナはリクエストを保護対象のWebLogicリソースにディスパッチします。

- 判定がFALSEの場合、リソース・コンテナはセキュリティ例外をスローします。この例外は、リクエスト側にはリクエストしたアクセスを保護されたWebLogicリソースに対して行う権限がなかったことを示します。

カスタム認可プロバイダを開発する必要があるか

WebLogic Serverのデフォルト(つまりアクティブな)セキュリティ・レルムにはWebLogic認可プロバイダが含まれています。WebLogic認可プロバイダは、このバージョンのWebLogic Serverの認可機能をデフォルトで適用するものです。WebLogic認可プロバイダは、特定のユーザーが保護対象のWebLogicリソースへのアクセスを許可されているかどうかを判定するためのポリシー・ベースの認可エンジンを使用して、アクセス決定を返します。また、WebLogic認可プロバイダは、システム内のセキュリティ・ポリシーのデプロイメントとアンデプロイメントもサポートしています。自社の既存の認可メカニズムを使用する場合は、カスタム認可プロバイダを作成してそれを既存のメカニズムに結合できます。

カスタム認可プロバイダでアプリケーションのバージョン管理をサポートする必要があるか

セキュリティ・レルムのすべての認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダは、アプリケーションのデプロイにバージョンを使用するために、アプリケーションのバージョン管理をサポートする必要があります。認可、ロール・マッピング、または資格証明マッピング用にカスタム・セキュリティ・プロバイダを開発する際に、バージョン管理されたアプリケーションをサポートする必要がある場合は、第14章「バージョン管理可能なアプリケーションのプロバイダ」の説明に従って、バージョン管理可能なアプリケーションのSSPIを実装する必要があります。

カスタム認可プロバイダはスレッド・セーフか

最高のパフォーマンスを実現するため、デフォルトでは、アプリケーションおよびモジュールのデプロイメント中にセキュリティ・ポリシーおよびロールに対して並列変更を実行できます。この理由から、セキュリティ・レルムに構成されているデプロイ可能な認可プロバイダおよびロール・マッピング・プロバイダでは、並列呼出しがサポートされている必要があります。WebLogicのデプロイ可能なXACML認可プロバイダおよびロール・マッピング・プロバイダは、この要件を満たしています。

ただし、カスタムのデプロイ可能な認可プロバイダまたはロール・マッピング・プロバイダで並列呼出しがサポートされている場合とサポートされていない場合があります。カスタムのデプロイ可能な認可プロバイダまたはロール・マッピング・プロバイダが並列呼出しをサポートしない場合、並列セキュリティ・ポリシーとロール変更を無効にして、かわりに各アプリケーションとモジュールがキューに配置され、連続してデプロイされる同期メカニズムを実行する必要があります。

注意:

同期化メカニズムを有効にした場合、定義済のWebLogic Serverプロバイダも含めて、レルム内に構成されているすべてのデプロイ可能なプロバイダが影響を受けます。同期化メカニズムを有効にすると、これらのプロバイダのパフォーマンスに悪影響を与える可能性があります。

この同期化強制メカニズムを有効にする方法については、『Oracle WebLogic Serverの保護』を参照してください。

カスタム認可プロバイダの開発方法

WebLogic認可プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム認可プロバイダを開発することができます。

1. 適切なSSPIによるランタイム・クラスの作成、または必要に応じてバルク認可プロバイダを実装

2. 必要に応じて、ポリシー・コンシューマSSPIを実装

3. 必要に応じて、PolicyStoreMBeanを実装

4. WebLogic MBeanMakerを使用してMBeanタイプを生成する

5. 管理コンソールによるカスタム認可プロバイダの構成

6. セキュリティ・ポリシーを管理するためのメカニズムの提供

適切なSSPIによるランタイム・クラスの作成

ランタイム・クラスを作成する前に、以下の作業が必要です。

- 「Provider」SSPIの目的について

- 実装する「Provider」インタフェースの決定

- SSPI階層を理解し、ランタイム・クラスを1つ作成するか2つ作成するかを決定する

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム認可プロバイダのランタイム・クラスを作成します。

- AuthorizationProvider SSPIの実装またはDeployableAuthorizationProviderV2 SSPIの実装

- AccessDecision SSPIの実装

注意:

セキュリティ・レルムでは、少なくとも1つの認可プロバイダがDeployableAuthorizationProvider SSPIを実装している必要があります。実装していない場合、WebアプリケーションやEJBをデプロイできなくなります。

カスタム認可プロバイダのランタイム・クラスの作成例については、「例:サンプル認可プロバイダのランタイム・クラスの作成」を参照してください。

AuthorizationProvider SSPIの実装

AuthorizationProvider SSPIを実装するには、「「Provider」SSPIの目的について」で説明されているメソッドおよび次のメソッドの実装を提供する必要があります。

- getAccessDecision

public AccessDecision getAccessDecision();

getAccessDecisionメソッドは、AccessDecision SSPIの実装を取得します。MyAuthorizationProviderImpl.javaという1つのランタイム・クラスの場合、getAccessDecisionメソッドの実装は次のようになります。

return this;

ランタイム・クラスが2つの場合、getAccessDecisionメソッドの実装は次のようになります。

return new MyAccessDecisionImpl;

これは、AuthorizationProvider SSPIを実装するランタイム・クラスが、AccessDecision SSPIを実装するクラスを取得する場合のファクトリとして使用されるためです。

AuthorizationProvider SSPIとgetAccessDecisionメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

DeployableAuthorizationProviderV2 SSPIの実装

DeployableAuthorizationProviderV2 SSPIを実装するには、「「Provider」SSPIの目的について」と「AuthorizationProvider SSPIの実装」で説明されているメソッド、および次のメソッドの実装を提供する必要があります。

- deleteApplicationPolicies

public void deleteApplicationPolicies(ApplicationInfo application) throws ResourceRemovalException

deleteApplicationPoliciesメソッドは、アプリケーションのポリシーをすべて削除します。deleteApplicationPoliciesメソッドは、管理サーバーでのみ呼び出されます。

- deployExcludedPolicy

public void deleteApplicationPolicies(DeployPolicyHandle handle, Resource
resource) throws ResourceCreationException

deployExcludedPolicyメソッドは、アクセスを常に拒否するポリシーをデプロイします。ポリシーがすでに存在する場合は削除され、このポリシーによって置き換えられます。

- deployPolicy

public void deployPolicy(DeployPolicyHandle handle, Resource resource,
String[] roleNames) throws ResourceCreationException

deployPolicyメソッドは、セキュリティ・ポリシーの適用対象となるWebLogicリソースと、セキュリティ・ポリシー内に記載されるセキュリティ・ロール名を基に、デプロイ済みのWebアプリケーションやEJBにかわってセキュリティ・ポリシーを作成します。

- deployUncheckedPolicy

public void deployUncheckedPolicy(DeployPolicyHandle handle, Resource
resource) throws ResourceCreationException

deployUncheckedPolicyメソッドは、アクセスを常に許可するポリシーをデプロイします。ポリシーがすでに存在する場合は削除され、このポリシーによって置き換えられます。

- endDeployPolicies

public void endDeployPolicies(DeployPolicyHandle handle) throws
ResourceCreationException

deployExcludedPolicyメソッドは、アクセスを常に拒否するポリシーをデプロイします。ポリシーがすでに存在する場合は削除され、このポリシーによって置き換えられます。

- startDeployPolicies

public deployPolicyHandle startDeployPolicies(ApplicationInfo application)
throws DeployHandleCreationException

startDeployPoliciesメソッドは、アプリケーションのポリシー・デプロイメントの開始をマークし、アプリケーションがターゲット指定されているWebLogic Serverドメイン内のすべてのサーバーで呼び出されます。

- undeployAllPolicies

public void undeployAllPolicies(DeployPolicyHandle handle) throws
ResourceRemovalException

undeployAllPoliciesメソッドは、デプロイされていないWebアプリケーションまたはEJBにかわって、ポリシー定義のセットを削除します。

DeployableAuthorizationProviderV2 SSPIとdeployPolicyおよびundeployPolicyメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

ApplicationInfoインタフェース

ApplicationInfoインタフェースは、アプリケーションのデプロイメントに関するデータをセキュリティ・プロバイダに渡します。このデータを使用すると、アプリケーションを一意に識別できます。

セキュリティ・フレームワークは、ユーザーの利便を図るためにApplicationInfoインタフェースを実装します。このインタフェースのメソッドを実装する必要はありません。

DeployableAuthorizationProviderV2インタフェースとDeployableRoleProviderV2インタフェースはApplicationInfoを使用します。たとえば、DeployableAuthorizationProviderV2のメソッドの実装を例にあげます。セキュリティ・フレームワークは、DeployableAuthorizationProviderV2のstartDeployPoliciesメソッドを呼び出し、このアプリケーションのApplicationInfoインタフェースを渡します。ApplicationInfoデータは、アプリケーションのデプロイ時に管理コンソールで提供される情報を基に決められます。

startDeployPoliciesメソッドは、DeployableAuthorizationProviderV2の他のメソッドでこの後使用できるDeployPolicyHandleを戻します。

ApplicationInfoインタフェースを使用すると、このアプリケーションのアプリケーション識別子、コンポーネント名、およびコンポーネントの種類を取得できます。コンポーネントの種類は、ApplicationInfo.ComponentTypeクラスの定義に従って、APPLICATION、CONTROL_RESOURCE、EJB、またはWEBAPPのいずれかです。

次のコードは、このタスクを実行する方法の一例です。

public DeployPolicyHandle startDeployPolicies(ApplicationInfo appInfo)
throws DeployHandleCreationException
:
// Obtain the application information...
String appId = appInfo.getApplicationIdentifier();
ComponentType compType = appInfo.getComponentType();
String compName = appInfo.getComponentName();

セキュリティ・フレームワークは、DeployableAuthorizationProviderV2 deleteApplicationPoliciesメソッドを呼び出し、このアプリケーションのApplicationInfoインタフェースを渡します。deleteApplicationPoliciesメソッドは、アプリケーションのポリシーをすべて削除します。このメソッドは、アプリケーションが削除されたときにWebLogic Serverドメイン内の管理サーバーでのみ呼び出されます。

AccessDecision SSPIの実装

AccessDecision SSPIを実装する際には、以下のメソッドの実装を用意する必要があります。

- isAccessAllowed

public Result isAccessAllowed(Subject subject, Map roles,
Resource resource, ContextHandler handler, Direction direction) throws InvalidPrincipalException

isAccessAllowedメソッドは、サブジェクトに格納されている情報を利用して、リクエスト側に保護対象リソースへのアクセスを許可すべきかどうかを決定します。isAccessAllowedメソッドはリクエストの前または後に呼び出すことができ、PERMIT、DENY、またはABSTAINのいずれかの値を返します。複数のアクセス決定が構成されていて、それらが相反する値を返す場合、最終結果を決定するには裁決プロバイダが必要になります。詳細については、第8章「裁決プロバイダ」を参照してください。

- isProtectedResource

public boolean isProtectedResource(Subject subject, Resource resource) throws InvalidPrincipalException

isProtectedResourceメソッドは、指定されたWebLogicリソースが保護対象かどうかを実際にアクセス・チェックを行わずに決定するために使用します。これは呼出し側のサブジェクトに付与できる一連のセキュリティ・ロールを計算するわけではないので、軽量のメカニズムに過ぎません。

AccessDecision SSPIとisAccessAllowedおよびisProtectedResourceメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

レルム・アダプタ認証プロバイダと互換性のあるカスタム認可プロバイダを開発する

認証プロバイダは、サブジェクト内へのユーザーおよびグループの格納を担当するセキュリティ・プロバイダです。ユーザーおよびグループはその後、認可プロバイダなど、他のタイプのセキュリティ・プロバイダによって、サブジェクトから抽出されます。セキュリティ・レルム内で構成された認証プロバイダがレルム・アダプタ認証プロバイダである場合、ユーザーおよびグループの情報は、他の認証プロバイダとは少し異なる形でサブジェクト内に格納されます。したがって、このユーザーおよびグループの情報もまた、少し異なる方法で抽出する必要があります。

例7-1は、サブジェクトへの格納にレルム・アダプタ認証プロバイダが使用された場合に、サブジェクトがユーザー名またはグループ名に一致するかどうかをチェックするために、カスタム認可プロバイダで使用できるコードです。このコードは、isAccessAllowedメソッドとisProtectedResourceメソッドの双方に属しています。

例7-1 サンプル・コード:サブジェクトがユーザー名またはグループ名に一致するかどうかのチェック

/**
* Determines if the Subject matches a user/group name.
*
* @param principalWant A String containing the name of a principal in this role
* (that is, the role definition).
*
* @param subject A Subject that contains the Principals that identify the user
* who is trying to access the resource as well as the user's groups.
*
* @return A boolean. true if the current subject matches the name of the
* principal in the role, false otherwise.
*/
private boolean subjectMatches(String principalWant, Subject subject)
{
// first, see if it's a group name match
if (SubjectUtils.isUserInGroup(subject, principalWant)) {
return true;
}
// second, see if it's a user name match
if (principalWant.equals(SubjectUtils.getUsername(subject))) {
return true;
}
// didn't match
return false;
}

例:サンプル認可プロバイダのランタイム・クラスの作成

例7-2は、サンプル認可プロバイダのランタイム・クラスであるSampleAuthorizationProviderImpl.javaクラスを示しています。このランタイム・クラスには次の実装が含まれています。

- initialize、getDescription、およびshutdownというSecurityProviderインタフェースから継承した3つのメソッド(「「Provider」SSPIの目的について」を参照)。

- AuthorizationProvider SSPIから継承したgetAccessDecisionメソッド(「AuthorizationProvider SSPIの実装」を参照)。

- deleteApplicationPolicies、deployExcludedPolicy、deployPolicy、deployUncheckedPolicy、endDeployPolicies、starteployPolicies、およびundeployAllPoliciesというDeployableAuthorizationProviderV2 SSPIの7つのメソッド(「DeployableAuthorizationProviderV2 SSPIの実装」を参照)。

- AccessDecision SSPIのisAccessAllowedおよびisProtectedResourceメソッド(「AccessDecision SSPIの実装」を参照)

注意:

例7-2の太字のコードは、クラス宣言とメソッド・シグネチャを示しています。

例7-2 SimpleSampleAuthorizationProviderImpl.java

package examples.security.providers.authorization.simple;
import java.security.Principal;
import java.util.Date;
import java.util.Enumeration;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
import javax.security.auth.Subject;
import weblogic.management.security.ProviderMBean;
import weblogic.security.SubjectUtils;
import weblogic.security.WLSPrincipals;
import weblogic.security.service.ContextHandler;
import weblogic.security.spi.AccessDecision;
import weblogic.security.spi.ApplicationInfo;
import weblogic.security.spi.ApplicationInfo.ComponentType;
import weblogic.security.spi.DeployableAuthorizationProviderV2;
import weblogic.security.spi.DeployPolicyHandle;
import weblogic.security.spi.Direction;
import weblogic.security.spi.InvalidPrincipalException;
import weblogic.security.spi.Resource;
import weblogic.security.spi.Result;
import weblogic.security.spi.SecurityServices;
import weblogic.security.spi.VersionableApplicationProvider;
public final class SimpleSampleAuthorizationProviderImpl implements
DeployableAuthorizationProviderV2, AccessDecision, VersionableApplicationProvider
{
private static String[] NO_ACCESS = new String[0];
private static String[] ALL_ACCESS = new String[] {WLSPrincipals.getEveryoneGroupname()};
private String description;
private SimpleSampleAuthorizerDatabase database;
public void initialize(ProviderMBean mbean, SecurityServices services)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.initialize");
SimpleSampleAuthorizerMBean myMBean = (SimpleSampleAuthorizerMBean)mbean;
description = myMBean.getDescription() + "\n" + myMBean.getVersion();
database = new SimpleSampleAuthorizerDatabase(myMBean);
}
public String getDescription()
{
return description;
}
public void shutdown()
{
System.out.println("SampleAuthorizationProviderImpl.shutdown");
}
public AccessDecision getAccessDecision()
{
return this;
}
public Result isAccessAllowed(Subject subject, Map roles, Resource resource,
ContextHandler handler, Direction direction)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.isAccessAllowed");
System.out.println("\tsubject\t= " + subject);
System.out.println("\troles\t= " + roles);
System.out.println("\tresource\t= " + resource);
System.out.println("\tdirection\t= " + direction);
Set principals = subject.getPrincipals();
for (Resource res = resource; res != null; res = res.getParentResource()) {
if (database.policyExists(res)) {
Result result = isAccessAllowed(res, subject, roles);
System.out.println("\tallowed\t= " + result);
return result;
}
}
Result result = Result.ABSTAIN;
System.out.println("\tallowed\t= " + result);
return result;
}
public boolean isProtectedResource(Subject subject, Resource resource) throws
InvalidPrincipalException
{
System.out.println("SimpleSampleAuthorizationProviderImpl.
isProtectedResource");
System.out.println("\tsubject\t= " + subject);
System.out.println("\tresource\t= " + resource);
for (Resource res = resource; res != null; res = res.getParentResource()) {
if (database.policyExists(res)) {
System.out.println("\tprotected\t= true");
return true;
}
}
System.out.println("\tprotected\t= false");
return false;
}
public DeployPolicyHandle startDeployPolicies(ApplicationInfo application)
{
String appId = application.getApplicationIdentifier();
String compName = application.getComponentName();
ComponentType compType = application.getComponentType();
DeployPolicyHandle handle = new    SampleDeployPolicyHandle(appId,compName,compType);
database.removePoliciesForComponent(appId, compName, compType);
return handle;
public void deployPolicy(DeployPolicyHandle handle,
Resource resource, String[] roleNamesAllowed)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.deployPolicy");
System.out.println("\thandle\t= " + ((SampleDeployPolicyHandle)handle).toString());
System.out.println("\tresource\t= " + resource);
for (int i = 0; roleNamesAllowed != null && i < roleNamesAllowed.length; i++) {
System.out.println("\troleNamesAllowed[" + i + "]\t= " + roleNamesAllowed[i]);
}
database.setPolicy(resource, roleNamesAllowed);
}
public void deployUncheckedPolicy(DeployPolicyHandle handle, Resource resource)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.deployUncheckedPolicy");
System.out.println("\thandle\t= " + ((SampleDeployPolicyHandle)handle).toString());
System.out.println("\tresource\t= " + resource);
database.setPolicy(resource, ALL_ACCESS);
}
public void deployExcludedPolicy(DeployPolicyHandle handle, Resource resource)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.deployExcludedPolicy");
System.out.println("\thandle\t= " + ((SampleDeployPolicyHandle)handle).toString());
System.out.println("\tresource\t= " + resource);
database.setPolicy(resource, NO_ACCESS);
}
public void endDeployPolicies(DeployPolicyHandle handle)
{
database.savePolicies();
}
public void undeployAllPolicies(DeployPolicyHandle handle)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.undeployAllPolicies");
SampleDeployPolicyHandle myHandle = (SampleDeployPolicyHandle)handle;
System.out.println("\thandle\t= " + myHandle.toString());

// remove policies
database.removePoliciesForComponent(myHandle.getApplication(),
myHandle.getComponent(),
myHandle.getComponentType());
}
public void deleteApplicationPolicies(ApplicationInfo application)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.deleteApplicationPolicies");
String appId = application.getApplicationIdentifier();
System.out.println("\tapplication identifier\t= " + appId);

// clear out policies for the application
database.removePoliciesForApplication(appId);
}
private boolean rolesOrSubjectContains(Map roles, Subject subject, String roleOrPrincipalWant)
{
// first, see if it's a role name match
if (roles.containsKey(roleOrPrincipalWant)) {
return true;
}

// second, see if it's a group name match
if (SubjectUtils.isUserInGroup(subject, roleOrPrincipalWant)) {
return true;
}

// third, see if it's a user name match
if (roleOrPrincipalWant.equals(SubjectUtils.getUsername(subject))) {
return true;
}

// didn't match
return false;
}

private Result isAccessAllowed(Resource resource, Subject subject, Map roles)
{
// loop over the principals and roles in our database who are allowed to access this resource
for (Enumeration e = database.getPolicy(resource); e.hasMoreElements();) {
String roleOrPrincipalAllowed = (String)e.nextElement();
if (rolesOrSubjectContains(roles, subject, roleOrPrincipalAllowed)) {
return Result.PERMIT;
}
}
// the resource was explicitly mentioned and didn't grant access
return Result.DENY;
}

public void createApplicationVersion(String appId, String sourceAppId)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.createApplicationVersion");
System.out.println("\tapplication identifier\t= " + appId);
System.out.println("\tsource app identifier\t= " + ((sourceAppId != null) ? sourceAppId : "None"));

// create new policies when existing application is specified
if (sourceAppId != null) {
database.clonePoliciesForApplication(sourceAppId,appId);
}
}
public void deleteApplicationVersion(String appId)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.deleteApplicationVersion");
System.out.println("\tapplication identifier\t= " + appId);

// clear out policies for the application
database.removePoliciesForApplication(appId);
}

public void deleteApplication(String appName)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.deleteApplication");
System.out.println("\tapplication name\t= " + appName);

// clear out policies for the application
database.removePoliciesForApplication(appName);
}

class SampleDeployPolicyHandle implements DeployPolicyHandle
{
Date date;
String application;
String component;
ComponentType componentType;

SampleDeployPolicyHandle(String app, String comp, ComponentType type)
{
this.application = app;
this.component = comp;
this.componentType = type;
this.date = new Date();
}

public String getApplication() { return application; }
public String getComponent() { return component; }
public ComponentType getComponentType() { return componentType; }

public String toString()
{
String name = component;
if (componentType == ComponentType.APPLICATION)
name = application;
return componentType +" "+ name +" ["+ date.toString() +"]";
}
}
}

ポリシー・コンシューマSSPI

WebLogic Serverには、JMX (MBean)デフォルト・ポリシーとWebサービス・アノテーション用のポリシー・コンシューマが実装されています。このリリースのWebLogic Serverには、認可プロバイダがポリシー・コレクションを取得するために使用できるSSPIがあります。

PolicyConsumer SSPIは省略可能です。ポリシー・コレクションを消費するためには、このSSPIを実装する認可プロバイダのみが呼び出されます。

このSSPIでは、初期状態のポリシー・コレクションの配信と、更新後のポリシー・コレクションの配信の両方がサポートされます。

ポリシー・コレクションの消費においては、PolicyConsumer SSPIをサポートするすべての認可プロバイダが呼び出されます。各認可プロバイダは、特定のポリシー・セットのポリシー・コレクションを取得するかしないかを選択できます。プロバイダでポリシーが永続化される場合、ポリシーを取得する必要があるのは一度のみです。一方、プロバイダでポリシーがメモリーに保持される場合、ポリシー・コレクションを再び取得することも可能です。

用意されているWebLogic Server認可プロバイダでは、ポリシーはLDAP内に永続化されます。

必要なSSPIインタフェース

カスタム認可プロバイダでポリシー・コレクションの配信をサポートするには、以下の3つのインタフェースを実装する必要があります。

- weblogic.security.spi.PolicyConsumerFactory

- weblogic.security.spi.PolicyConsumer

- weblogic.security.spi.PolicyCollectionHandler

- これらのインタフェースについては、これ以降の節で説明します。

PolicyConsumerFactory SSPIインタフェースの実装

認可プロバイダには、PolicyConsumerのインスタンスをWebLogicセキュリティ・フレームワークで使用できるように、PolicyConsumerFactoryインタフェースが実装されています。WebLogicセキュリティ・フレームワークではPolicyConsumerFactoryの実装を呼び出して、プロバイダのポリシー・コンシューマの実装を取得します。

PolicyConsumerFactory SSPIにはメソッドが1つあり、このメソッドはPolicyConsumer SSPIインタフェースの実装を返します。

public interface PolicyConsumerFactory
{
/**
* Obtain the implementation of the PolicyConsumer
* security service provider interface (SSPI).
*
* @return a PolicyConsumer SSPI implementation.
*/
public PolicyConsumer getPolicyConsumer();
}

PolicyConsumer SSPIインタフェースの実装

PolicyConsumer SSPIは、ポリシー・コレクションを消費するためのポリシー・コレクション・ハンドラを戻します。これにはgetPolicyCollectionHandler()というメソッドが1つあり、このメソッドは引数にPolicyCollectionInfoの実装を取って、PolicyCollectionHandlerインタフェースの実装を戻します。

public interface PolicyConsumer
{
/**
* Obtain a policy handler for consumption of a policy set.
*
* @param info the PolicyCollectionInfo for the policy set.
*
* @return a PolicyCollectionHandler or NULL which indicates
*     that the policy set is not needed.
*
* @exception ConsumptionException if an error occurs
*     obtaining the handler and the policy set cannot be consumed.
*/
public PolicyCollectionHandler getPolicyCollectionHandler(
PolicyCollectionInfo info)
throws ConsumptionException;
}

WebLogicセキュリティ・フレームワークではgetPolicyCollectionHandler()メソッドを呼び出して、ポリシー・コレクションに関するデータをPolicyCollectionInfoインタフェースの実装としてセキュリティ・プロバイダに渡します。(このインタフェースはあらかじめ実装されているので、ユーザーが実装する必要はありません。)

PolicyCollectionInfoのgetName()、getVersion()、getTimestamp()、およびgetResourceTypes()メソッドを使用して、このポリシー・セットに関する情報を検索します。検索後にはPolicyCollectionHandlerを返すか、ポリシー・コレクションが不要であることを示すNULLを返します。

public interface PolicyCollectionInfo
{
/**
* Get the name of the collection.
*/
public String getName();

/**
* Get the runtime version of the policy.
*/
public String getVersion();

/**
* Get the timestamp of the policy.
*/
public String getTimestamp();

/**
* Get the resource types used in the policy collection.
*/
public Resource[] getResouceTypes();
}

PolicyCollectionHandler SSPIインタフェースの実装

PolicyConsumer.getPolicyCollectionHandler()メソッドはPolicyCollectionHandlerインタフェースの実装を返します。PolicyCollectionHandlerにはsetPolicy、setUncheckedPolicy、およびdone()という3つのメソッドがあります。setPolicy()はリソースおよびロールの名前を取り、ロールに基づいてポリシーを設定します。setUncheckedPolicy()メソッドはすべてのユーザーにアクセスを許可します。

done()メソッドはポリシー・コレクションの完了を示します。done()メソッドでは、ポリシー・セットの古いポリシーをすべて削除することをお薦めします。

public interface PolicyCollectionHandler
{
/**
* Set a policy for the specified resource.
*/
public void setPolicy(Resource resource, String[] roleNames)
throws ConsumptionException;

/**
* Sets a policy which always grants access.
*/
public void setUncheckedPolicy(Resource resource)
throws ConsumptionException;

/**
* Signals the completion of the policy collection.
*/
public void done()
throws ConsumptionException;

}

更新後のポリシー・コレクションのサポート

更新後のポリシー・コレクションの配信をサポートするには、PolicyConsumer SSPIをサポートするすべての認可プロバイダでPolicyConsumer.getPolicyCollectionHandler()メソッドに渡されたPolicyCollectionInfoの内容を調べて、ポリシー・セットが変更されているかどうかを判断する必要があります。各プロバイダでは、初期状態のポリシー・コレクションとSSPIの外部から受け取ったカスタマイズ後のポリシーとの競合を解決する方法を(できれば構成によって)決定しておくことが必要です。

WebLogic Serverで提供されている認可プロバイダでは、カスタマイズ後のポリシーが更新後のポリシー・コレクションで置き換えられません。初期状態のポリシー・コレクションのポリシーはすべて削除され、カスタマイズ後のポリシーと更新後のポリシー・コレクションのみが有効になります。ポリシー・コレクションの情報に異なるタイム・スタンプやバージョンがある場合、更新後のポリシー・コレクションとして扱われます。コレクションの名前は永続キーとして使用されます。

PolicyConsumerMBean

ポリシー・コンシューマSSPIを実装する認可プロバイダには、そのプロバイダでポリシーの消費をサポートすることを示すためにweblogic.management.security.authorization.PolicyConsumerMBeanも実装する必要があります。

PolicyStoreMBean

このリリースのWebLogic Serverでは、weblogic.management.security.authorization.PolicyStoreMBeanという新しいMBeanがサポートされています。このMBeanは、管理者が生成したXACMLポリシーおよびポリシー・セットの標準的な管理操作(追加、削除、取得、リスト表示、変更、読込み)に使用できます。認可プロバイダMBeanやロール・マッピング・プロバイダMBeanには、必要に応じてこのMBeanインタフェースを実装できます。

セキュリティ管理者は、PolicyStoreMBeanのメソッドを使用して、サーバー内のポリシーをXACMLドキュメントとして管理できます。たとえば、デフォルトのXACMLプロバイダを使用するドメインを作成および管理したり、作成済のXACMLドキュメントを管理したりできます。これらのXACMLポリシーは、WebLogic ServerではWLSTを使用して管理できます。

WebLogic ServerにはこのMBeanの実装が含まれており、付属のXACMLプロバイダで使用できます。また、このMBeanの独自の実装を記述して、カスタムの認可プロバイダやロール・マッピング・プロバイダで使用することも可能です。WebLogic Serverに用意されているXACMLプロバイダでは、XACML 2.0のコア仕様(http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf)に記載されているXACMLの必須機能がサポートされています。Oracle固有の使用方法については、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。

ポリシーはXACML 2.0のポリシーまたはPolicySetドキュメントで表現されます。カスタム認可プロバイダでは、XACML 2.0のコア仕様(http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf)に記載されている標準のPolicyまたはPolicySetドキュメントを想定する必要があります。カスタム・ロール・マッピング・プロバイダでは、Core and hierarchical role based access control (RBAC) profile of XACML v2.0 (http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-rbac-profile1-spec-os.pdf)に記載されているロール割当てポリシーと整合性があるPolicyまたはPolicySetドキュメントを想定する必要があります。

具体的には、Targetに以下を含める必要があります。

- ActionAttributeDesignator (anyURI-equalで一致する、urn:oasis:names:tc:xacml:1.0:action:action-idというIDと、urn:oasis:names:tc:xacml:2.0:actions:enableRoleという値の指定されているもの)。例:

<Action>
<ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:oasis:names:tc:xacml:2.0
:actions:enableRole
</AttributeValue>

<ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#anyURI" MustBePresent="true"/>

</ActionMatch>
</Action>

- ResourceAttributeDesignator (string-equalで一致する、urn:oasis:names:tc:xacml:2.0:subject:roleというIDと、割り当てられたロールの名前である値の指定されているもの)。例:

<ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor-or-self"
DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>

XACML Policyファイルの形式の調べ

XACML 2.0のコア仕様(http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf)および『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』で説明しているOracle拡張が、提供されているXACML認可プロバイダおよびロール・マッピング・プロバイダで使用するXACMLポリシー・ファイルについての最も確実な情報です。

ただしサポートされているXACMLファイルの形式を開発プロセスの一環として確認する場合は、おそらく、管理コンソールを使用して、XACML認可またはロール・マッピング・プロバイダのデータベースからデータをXACMLファイルとしてエクスポートする方法が最も便利です。エクスポートしたXACMLファイルをコピーして別の名前で保存し、任意のツールで確認します。

注意:

エクスポートしたファイルは読取り専用としてください。変更した場合、そのファイルはWebLogic Serverにインポートし直さないでください。エクスポートしたファイルを編集すると、WebLogic Server構成が使用できなくなる可能性があります。エクスポートしたファイルの編集はサポートされていません。

WLSTを使用してPolicyStoreMBeanにポリシーの追加

例7-3に、WLSTを使用してXACMLファイルからPolicyStoreMBeanのインスタンスに1つのポリシーを追加する例を示します。

この例ではこのスクリプトで使用するプロパティを、次のantスクリプトから抜粋した行に似た方法で、あらかじめ別の場所に定義してあるものと想定しています。

<property name="xacml-docs-dir" value="${xacmldir}/xacml-docs"/>
<sysproperty key="file" value="${xacml-docs-dir}/policy-getSubject.xacml"/>

例7-3 WLSTを使用してPolicyStoreMBeanにポリシーの追加

:
try:
protocol = System.getProperty("protocol")
host = System.getProperty("host")
user = System.getProperty("authuser")
passwd = System.getProperty("authpwd")
port = System.getProperty("port")
dom = System.getProperty("domain")
rlm = System.getProperty("realm")
fil = System.getProperty("file")
prov = System.getProperty("provider")
stat = System.getProperty("status")

def configure():
try:
url = protocol + "://" + host + ":" + port
connect(user,passwd, url)
path = "/SecurityConfiguration/" + dom + "/Realms/" + rlm + "/" + prov
print("cd'ing to " + path)
cd(path)
print("calling open()")
xacmlFile = open(fil,"r")
print("calling read()")
xacmlDoc = xacmlFile.read()
print("calling cmo.addPolicy")
if stat == "none":
cmo.addPolicy(xacmlDoc)
else:
cmo.addPolicy(xacmlDoc, stat)
print("Add error handling")
:
:

『Oracle WebLogic Scripting Tool』のMBeanの移動と照会に関する項で説明しているように、WLSTが初めてWebLogic Serverインスタンスに接続すると、変数cmo(現在の管理オブジェクト)がすべての構成管理オブジェクトのルートDomainMBeanに初期化されます。MBeanタイプに移動すると、このSecurityConfigurationMBeanの場合、cmoの値はSecurityConfigurationMBeanを反映したものになります。MBeanインスタンス、つまりこの場合にはPolicyStoreMBeanを実装する認可プロバイダMBean(例では変数provで指定)に移動するときには、WLSTによってcmoの値が現在のMBeanインスタンスに変更されます。

この例ではPolicyStoreMBeanのaddPolicy()メソッドを使用して、XACMLファイルからポリシー・ストアに読み込まれるポリシーを追加しています。addPolicy()メソッドの2つのバリアント(ステータスを伴うものと伴わないもの)が示されています。

ステータスを指定しないaddPolicy()メソッドを使用する場合、デフォルトでACTIVEに設定されます。これは、ポリシーがそのターゲットで適用されるどのような決定でも評価されることを示します。ステータスは明示的にACTIVE、INACTIVE、またはBYREFERENCEに設定できます。INACTIVEステータスは、ポリシーが評価されずに格納されるだけであることを示します。BYREFERENCEステータスは、評価されるポリシー・セットによって参照された場合にだけ、ポリシーが評価されることを示します。

このタイプのWLSTスクリプトは、次のような方法でコマンドラインから呼び出せます。

java -Dhost="localhost " -Dprotocol="t3" -Dauthuser="weblogic"
-Dauthpwd="weblogic" -Dport="7001" -Ddomain="mydomain" -Drealm="myrealm"
-Dprovider="Authorizers/XACMLAuthorizer"
-Dfile="C:/XACML/xacml-docs/policy12.xml" -Dstatus="none" weblogic.WLST
XACML/scripts/XACMLaddPolicy.py

WLSTを使用してPolicySetをStringとして読み込む

例7-4に、WLSTを使用してPolicySetをStringとして読み込む例を示します。

この例ではこのスクリプトで使用するプロパティを、次のantスクリプトから抜粋した行に似た方法で、あらかじめ別の場所に定義してあるものと想定しています。

<sysproperty key="identifier"
value="urn:sample:xacml:2.0:wlssecqa:resource:type@E@Fejb@G@M@Oapplication@ENoD
DRolesOrPoliciesEar@M@Omodule@Eejb11inEarMiniAppBean.jar@M@Oejb@EMiniAppBean@
M@Omethod@EgetSubject@M@OmethodInterface@ERemote"/>
<sysproperty key="version" value="1.0"/>

例7-4 WLSTを使用してPolicySetをStringとして読み込む

:
:
try:
print("start XACMLreadPolicySet.py")
protocol = System.getProperty("protocol")
host = System.getProperty("host")
user = System.getProperty("authuser")
passwd = System.getProperty("authpwd")
port = System.getProperty("port")
dom = System.getProperty("domain")
rlm = System.getProperty("realm")
prov = System.getProperty("provider")
id = System.getProperty("identifier")
vers = System.getProperty("version")
:
:
def configure():
try:
url = protocol + "://" + host + ":" + port
connect(user,passwd, url)
path = "/SecurityConfiguration/" + dom + "/Realms/" + rlm + "/" + prov
print("cd'ing to " + path)
cd(path)
polset = cmo.readPolicySetAsString(id, vers)
print("readPolicySetAsString() returned the following policy set: " + polset)
print"Add error handling."
:
:

XACML 2.0のコア仕様(http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf)で説明されているように、<PolicySet>要素には<Policy>のセットまたは別の<PolicySet>要素、およびそれらの評価結果を結合するための指定された手順が含まれます。詳細については、XACML 2.0のコア仕様を参照してください。

バルク認可プロバイダ

WebLogic Serverのこのリリースには、以下に示すバルク・アクセス・バージョンの認可プロバイダSSPIインタフェースがあります。

- BulkAuthorizationProvider

- BulkAccessDecision

バルク・アクセスSSPIインタフェースを使用すると、認可プロバイダにおいて1回の呼出しで複数の判定リクエストを取得できます。これまでのように、たとえば「for」ループで複数の呼出しを実行する必要はありません。バルクSSPIバリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡されたResourceオブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測できるようになります。

バルク・バージョンでないSSPIインタフェースとバルク・バージョンのSSPIインタフェースの使用方法には若干の違いがあります。

BulkAccessDecision.isAccessAllowed()メソッドはロールのMapを引数に取ります。これは、第1にResourceオブジェクト、続いてロール名(Map<Resource, Map<String, SecurityRole>> roles)で索引付けされ、サブジェクトに関連付けられているもので、認可判定時に考慮に入れる必要があります。

BulkAccessDecision.isAccessAllowed()メソッドはMap (Resource、結果で索引付け)を返します。これは、リソースに定義された認可ポリシーが、リクエストされたメソッドの実行を許可するかどうかを示します。

WebLogic MBeanMakerを使用してMBeanタイプを生成する

カスタム・セキュリティ・プロバイダのMBeanタイプを生成する前に、以下の作業が必要です。

- MBeanタイプが必要な理由について

- 拡張および実装するSSPI MBeanの決定

- MBean定義ファイル(MDF)の基本的な要素について

- SSPI MBeanの階層と管理コンソールに対する影響について

- WebLogic MBeanMakerによって提供されるものについて

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム認可プロバイダのMBeanタイプを作成します。

1. MBean定義ファイル(MDF)の作成

2. WebLogic MBeanMakerを使用してMBeanタイプを生成する

3. WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

4. WebLogic Server環境にMBeanタイプをインストールする

注意:

複数のセキュリティ・プロバイダのサンプルで、これらの手順の実行方法を示します。

この節で説明する手順はすべて、Windows環境での作業を想定しています。

MBean定義ファイル(MDF)の作成

MBean定義ファイル(MDF)を作成するには、次の手順に従います。

1. サンプル認可プロバイダのMDFをテキスト・ファイルにコピーします。

注意:

サンプル認可プロバイダのMDFは、SimpleSampleAuthorizer.xmlという名前です。

2. MDFで<MBeanType>要素と<MBeanAttribute>要素の内容をカスタム認可プロバイダに合わせて修正します。

3. カスタム属性および操作(つまり、<MBeanAttribute>および<MBeanOperation>要素)をMDFに追加します。

4. ファイルを保存します。

注意:

MDF要素の構文についての詳細なリファレンスは、付録A「MBean定義ファイル(MDF)要素の構文」に収められています。

WebLogic MBeanMakerを使用してMBeanタイプを生成する

MDFを作成したら、WebLogic MBeanMakerを使用してそれを実行できます。WebLogic MBeanMakerは現在のところコマンドライン・ユーティリティで、入力としてMDFを受け取り、MBeanインタフェース、MBean実装、関連するMBean情報ファイルなどの中間Javaファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム・セキュリティ・プロバイダのMBeanタイプになります。

MBeanタイプの作成手順は、カスタム認可プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。

- オプショナルSSPI MBeanとカスタム操作を追加しない場合

- オプショナルSSPI MBeanまたはカスタム操作を追加する場合

オプショナルSSPI MBeanとカスタム操作を追加しない場合

カスタム認可プロバイダのMDFがオプショナルSSPI MBeanを実装せず、かつ、いかなるカスタム操作も含まない場合、次の手順に従います。

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり認可プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

3. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

オプショナルSSPI MBeanまたはカスタム操作を追加する場合

カスタム認可プロバイダのMDFがオプショナルSSPI MBeanまたはカスタム操作を実装する場合、以下の質問に答えながら手順を進めてください。

MBeanタイプを作成するのは初めてですか。その場合は、次の手順に従ってください:

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり認可プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

3. オプショナルSSPI MBeanをMDFに実装した場合は、次の手順に従います。

1. MBean実装ファイルを見つけます。
WebLogic MBeanMakerによって生成されるMBean実装ファイルには、MBeanNameImpl.javaという名前が付けられます。たとえば、SampleAuthorizerという名前のMDFの場合、編集されるMBean実装ファイルはSampleAuthorizerImpl.javaという名前になります。

2. MDFで実装したオプショナルSSPI MBeanごとに、各メソッドを実装します。オプショナルSSPI MBeanが継承するメソッドもすべて実装してください。

4. MDFにカスタム操作を含めた場合、メソッド・スタブを使用してメソッドを実装します。

5. ファイルを保存します。

6. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

既存のMBeanタイプの更新ですか。その場合は、次の手順に従ってください:

1. WebLogic MBeanMakerによって現在のメソッドの実装が上書きされないように、既存のMBean実装ファイルを一時ディレクトリにコピーします。

2. 新しいDOSシェルを作成します。

3. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり認可プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

4. オプショナルSSPI MBeanをMDFに実装した場合は、次の手順に従います。

1. MBean実装ファイルを見つけます。
WebLogic MBeanMakerによって生成されるMBean実装ファイルには、MBeanNameImpl.javaという名前が付けられます。たとえば、SampleAuthorizerという名前のMDFの場合、編集されるMBean実装ファイルはSampleAuthorizerImpl.javaという名前になります。

2. ステップ1で一時ディレクトリに保存した既存のMBean実装ファイルを開きます。

3. 既存のMBean実装ファイルを、WebLogic MBeanMakerによって生成されたMBean実装ファイルと同期させます。
これには、メソッドの実装を既存のMBean実装ファイルから新しく生成されたMBean実装ファイルにコピー(または、新しく生成されたMBean実装ファイルから既存のMBean実装ファイルに新しいメソッドを追加)し、いずれのMBean実装ファイルにも入っているメソッドのメソッド・シグネチャへの変更が、使用するMBean実装ファイルに反映されていることを確認するといった作業が必要です。

4. MDFを修正して元のMDFにはないオプショナルSSPI MBeanを実装した場合は、各メソッドを実装します。オプショナルSSPI MBeanが継承するメソッドもすべて実装してください。

5. MDFを変更して元のMDFにはないカスタム操作を含めた場合、メソッド・スタブを使用してメソッドを実装します。

6. 完成した、つまりすべてのメソッドを実装したMBean実装ファイルを保存します。

7. このMBean実装ファイルを、WebLogic MBeanMakerがMBeanタイプの実装ファイルを配置したディレクトリにコピーします。このディレクトリは、手順3でfilesdirとして指定したものです。(ステップ3の結果としてWebLogic MBeanMakerで生成されたMBean実装ファイルがオーバーライドされます)。

8. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

生成されるMBeanインタフェース・ファイルについて

MBeanインタフェース・ファイルとは、ランタイム・クラスまたはMBean実装が構成データを取得するために使用するMBeanのクライアント側APIです。「「Provider」SSPIの目的について」で説明されているように、これはinitializeメソッドで使用するのが一般的です。

WebLogic MBeanMakerでは、作成済のMDFからMBeanタイプを生成するので、生成されるMBeanインタフェース・ファイルの名前は、そのMDF名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMakerでSampleAuthorizer MDFを実行すると、結果としてSampleAuthorizerMBean.javaというMBeanインタフェース・ファイルが生成されます。

WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

WebLogic MBeanMakerでMDFを実行して中間ファイルを作成し、MBean実装ファイルを編集して適切なメソッドの実装を提供したら、カスタム認可プロバイダのMBeanファイルとランタイム・クラスをMBean JARファイル(MJF)にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMakerによって自動化されます。

カスタム認可プロバイダのMJFを作成するには、次の手順に従います。

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMJF=jarfile -Dfiles=filesdir weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMJFフラグはWebLogic MBeanMakerが新しいMBeanタイプを含むJARファイルを構築すべきであることを示し、jarfileはMJFの名前、filesdirはWebLogic MBeanMakerでMJFにJAR化する対象ファイルが存在する場所を示します。

この時点でコンパイルが行われるので、エラーが発生するおそれがあります。jarfileが指定されていて、エラーが発生しなかった場合には、指定された名前のMJFが作成されます。

注意:

カスタム・セキュリティ・プロバイダのJARファイルを作成する際には、一連のXMLバインディング・クラスと1つのスキーマも生成されます。そのスキーマに関連付けるネームスペースを選択できます。それにより、使用しているカスタム・クラスとOracleのカスタム・クラスとの競合を防ぐことができます。ネームスペースのデフォルトはvendorです。-targetNameSpace引数をWebLogicMBeanMakerまたは関連するWLMBeanMaker antタスクに渡すことで、このデフォルトを変更できます。

既存のMJFを更新する場合は、単純にMJFを削除して再生成します。WebLogic MBeanMakerにも -DIncludeSourceオプションがあり、それを指定すると、生成されるMJFにソース・ファイルを含めるかどうかを制御できます。ソース・ファイルには、生成されたソースとMDFそのものがあります。デフォルトはfalseです。このオプションは、-DMJFを使用しない場合には無視されます。

生成されたMJFは、自らのWebLogic Server環境にインストールすることも、顧客に配布してそれぞれのWebLogic Server環境にインストールしてもらうこともできます。

WebLogic Server環境にMBeanタイプをインストールする

MBeanタイプをWebLogic Server環境にインストールするには、MJFをWL_HOME\server\lib\mbeantypesディレクトリにコピーします。ここで、WL_HOMEはWebLogic Serverの最上位のインストール・ディレクトリです。このインストール・コマンドによって、カスタム認可プロバイダが「デプロイ」されます。つまり、カスタム認可プロバイダをWebLogic Server管理コンソールから管理できるようになります。

注意:

MBeanタイプをインストールするデフォルトのディレクトリは、WL_HOME\server\lib\mbeantypesです。初めて使用するバージョンが9.0の場合、セキュリティ・プロバイダは...\domaindir\lib\mbeantypesからもロードできます。ただし、サーバーを起動するときに-Dweblogic.alternateTypesDirectory=<dir>コマンドライン・フラグを使用すれば、WebLogic Serverが追加ディレクトリでMBeanタイプを検索します。<dir>は、ディレクトリ名のカンマ区切りのリストです。このフラグを使用する場合、WebLogic Serverは常に最初にWL_HOME\server\lib\mbeantypesからMBeanタイプをロードします。その後で、追加ディレクトリにあるすべての有効なアーカイブを検索して、ロードします。このとき拡張子は考慮されません。

たとえば、-Dweblogic.alternateTypesDirectory = dirX,dirYの場合、WebLogic ServerはまずWL_HOME\server\lib\mbeantypesからMBeanタイプをロードし、次にdirXおよびdirYにある有効なアーカイブをロードします。WebLogic Serverに追加ディレクトリでMBeanタイプを検索するよう指示する際に、Javaセキュリティ・マネージャを使用している場合は、weblogic.policyファイルを更新して、MBeanタイプ(その結果として、カスタム・セキュリティ・プロバイダ)に適した許可を付与することも必要になります。詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』のJavaセキュリティを使用したWebLogicリソースの保護に関する項を参照してください。

カスタム認可プロバイダを構成することによって(「管理コンソールによるカスタム認可プロバイダの構成」を参照)、MBeanタイプのインスタンスを作成して、GUI、他のJavaコード、またはAPIからそれらのMBeanインスタンスを使用することができます。たとえば、WebLogic Server管理コンソールを使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他のJavaオブジェクトを開発して、そのオブジェクトでMBeanをインスタンス化し、それらのMBeanから提供される情報に自動的に応答させることもできます。なお、これらのMBeanインスタンスをバックアップしておくことをお薦めします。

管理コンソールによるカスタム認可プロバイダの構成

カスタム認可プロバイダを構成するということは、認可サービスを必要とするアプリケーションがアクセス可能なセキュリティ・レルムにカスタム認可プロバイダを追加するということです。

カスタム・セキュリティ・プロバイダの構成は管理タスクですが、カスタム・セキュリティ・プロバイダの開発者が行うこともできます。この節では、カスタム認可プロバイダの構成担当者向けの重要な情報を取り上げます。

- 認可プロバイダとデプロイメント記述子の管理

- セキュリティ・ポリシー・デプロイメントの有効化

注意:

WebLogic Server管理コンソールを使用してカスタム認可プロバイダを構成する手順は、『Oracle WebLogic Serverの保護』のWebLogicセキュリティ・プロバイダの構成に関する項で説明されています。

認可プロバイダとデプロイメント記述子の管理

Enterprise JavaBeans (EJB)やWebアプリケーションなどのアプリケーションの中には、Java EEの関連デプロイメント情報とWebLogic Serverデプロイメント記述子を格納するものがあります。Webアプリケーションの場合、デプロイメント記述子ファイル(web.xmlとweblogic.xml)には、セキュリティ・ポリシーの宣言を含むJava EEセキュリティ・モデルの実装情報が記述されます。この情報は、WebLogic Server管理コンソールで認可プロバイダを初めて構成するときに格納するのが一般的です。

Java EEプラットフォームはデプロイメント記述子でWebアプリケーションおよびEJBのセキュリティを標準化しているので、WebLogic Serverではこの標準メカニズムがWebLogicセキュリティ・サービスに統合され、WebアプリケーションおよびEJBリソースを保護する方法を選択できるようになっています。デプロイメント記述子のみを使用することも管理コンソールのみを使用することもできます。また、状況によっては、この2つの方法を組み合わせることもできます。

選択した方法によって、セキュリティ・モデルを適用する必要もあります。WebLogicでは、個々のデプロイメントについて複数のセキュリティ・モデルがサポートされ、使用する方法を組み込むレルム全体の構成についてはセキュリティ・モデルがサポートされます。

デプロイメント記述子を使用するように構成すると、WebLogic Serverによりweb.xmlおよびweblogic.xmlデプロイメント記述子ファイルからセキュリティ・ポリシー情報が読み込まれます(web.xmlファイルとweblogic.xmlファイルの例については、例7-5と例7-6を参照)。この情報は、認可プロバイダのセキュリティ・プロバイダ・データベースにコピーされます。

例7-5 web.xmlファイルのサンプル

<web-app>
<welcome-file-list>
<welcome-file>welcome.jsp</welcome-file>
</welcome-file-list>
<security-constraint>
<web-resource-collection>
<web-resource-name>Success</web-resource-name>
<url-pattern>/welcome.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>developers</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>default</realm-name>
</login-config>
<security-role>
<role-name>developers</role-name>
</security-role>
</web-app>

例7-6 weblogic.xmlファイルのサンプル

<weblogic-web-app>
<security-role-assignment>
<role-name>developers</role-name>
<principal-name>myGroup</principal-name>
</security-role-assignment>
</weblogic-web-app>

セキュリティ・ポリシー・デプロイメントの有効化

カスタム認可プロバイダの開発の一環としてDeployableAuthorizationProviderV2 SSPIを実装し、カスタム認可プロバイダでデプロイ可能なセキュリティ・ポリシーをサポートする場合、カスタム認可プロバイダの構成担当者(つまり、開発者または管理者)は、WebLogic Server管理コンソールで「ポリシー・デプロイメントを有効化」チェック・ボックスがチェックされていることを確認する必要があります。チェックがはずれていると、認可プロバイダのデプロイメントは「オフ」と見なされます。このため、複数の認可プロバイダが構成されている場合、「ポリシー・デプロイメントを有効化」チェック・ボックスを使用して、セキュリティ・ポリシーのデプロイメントに使用する認可プロバイダを指定できます。

セキュリティ・ポリシーを管理するためのメカニズムの提供

WebLogic Server管理コンソールを使用してカスタム認可プロバイダを構成すると、必要な認可サービスにアプリケーションからアクセスできるようにすることはできますが、このセキュリティ・プロバイダに関連付けられたセキュリティ・ポリシーを管理する方法を管理者にも提供する必要があります。たとえばWebLogic認可プロバイダには、ポリシー・エディタ・ページが管理者向けに用意されており、様々なWebLogicリソースのセキュリティ・ポリシーを追加、変更、または削除することができます。

カスタム認可プロバイダを開発している場合、管理者はポリシー・エディタ・ページも認可サービスへのアクセスも利用できません。したがって、セキュリティ・ポリシーを管理するための独自のメカニズムを提供する必要があります。このメカニズムでは、カスタム認可プロバイダのデータベースのセキュリティ・ポリシー・データ(つまり式)を読み書きできなければなりません。

それには、以下の3通りの方法があります。

- オプション1: セキュリティ・ポリシー管理用のスタンドアロン・ツールの開発

- オプション2 :既存のセキュリティ・ポリシー管理ツールを管理コンソールに統合する

オプション1 :セキュリティ・ポリシー管理用のスタンドアロン・ツールの開発

WebLogic Server管理コンソールとまったく別のツールを開発する場合には、この方法を選択します。

この方法では、カスタム認可プロバイダ向けにコンソール拡張を作成する必要も、管理MBeanを開発する必要もありません。ただし、ツールでは以下のことを行う必要があります。

1. WebLogicリソースのIDを特定します。IDがコンソール拡張によって自動的に提供されないためです。詳細については、「WebLogicリソース識別子」を参照してください。

2. セキュリティ・ポリシーを構成する式を表す方法を決定します。この表現は完全に任意であり、文字列である必要はありません。

3. カスタム認可プロバイダのデータベースの式を読み書きします。

オプション2 : 管理コンソールに既存のセキュリティ・ポリシー管理ツールの統合

WebLogic Server管理コンソールとは別のツールを持っており、それを管理コンソールから起動する場合には、この方法を選択します。

この方法の場合、ツールでは以下のことを行う必要があります。

1. WebLogicリソースのIDを特定します。IDがコンソール拡張によって自動的に提供されないためです。詳細については、「WebLogicリソース識別子」を参照してください。

2. セキュリティ・ポリシーを構成する式を表す方法を決定します。この表現は完全に任意であり、文字列である必要はありません。

3. カスタム認可プロバイダのデータベースの式を読み書きします。

4. 『Oracle WebLogic Server管理コンソールの拡張』で説明されているように、基本的なコンソール拡張手法を使用して管理コンソールにリンクします。

8 裁決プロバイダ

この章では、裁決プロバイダの概念と機能、およびカスタム裁決プロバイダの開発手順について説明します。

裁決とは、複数の認可プロバイダが構成されている場合に発生するおそれのある認可上の競合を、それぞれの認可プロバイダのアクセス決定の結果を比較検討することで解消する手続きです。WebLogic Serverでは、裁決プロバイダを使用して、複数のアクセス決定から返される結果を調停し、PERMITかDENYの最終判定を下します。また、裁決プロバイダでは、単一の認可プロバイダのアクセス決定からABSTAINの回答が返されたときにどうすべきかを指定することもできます。

以下の節では、裁決プロバイダの概念と機能、およびカスタム裁決プロバイダの開発手順について説明します。

- 裁決プロセス

- カスタム裁決プロバイダを開発する必要があるか

- カスタム裁決プロバイダの開発方法

裁決プロセス

裁決プロバイダは認可プロセスの一部として使用されるので、使用方法は「認可プロセス」で説明されています。

カスタム裁決プロバイダを開発する必要があるか

WebLogic Serverのデフォルト(つまりアクティブな)セキュリティ・レルムにはWebLogic裁決プロバイダが含まれています。WebLogic裁決プロバイダは、複数の認可プロバイダのアクセス決定から異なる結果が返された場合に裁決を行い、WebLogicリソースへのアクセスを許可するかどうかを最終的に判定します。

WebLogic裁決プロバイダには、動作を制御する「完全一致の許可が必要」という属性があります。「完全一致の許可が必要」属性は、デフォルトではTRUEに設定されており、WebLogic裁決プロバイダはその設定に従って次のように動作します。

- すべての認可プロバイダのアクセス決定がPERMITを返した場合、最終的な判定としてTRUEを返します(つまりWebLogicリソースへのアクセスは許可されます)。

- 一部の認可プロバイダのアクセス決定がPERMITを返し、その他がABSTAINを返した場合、FALSEを返します(つまりWebLogicリソースへのアクセスは拒否されます)。

- いずれかの認可プロバイダのアクセス決定がABSTAINまたはDENYを返した場合、最終的な判定としてFALSEを返します(つまりWebLogicリソースへのアクセスは拒否されます)。

「完全一致の許可が必要」属性をFALSEに変更した場合、WebLogic裁決プロバイダは次のように動作します。

- すべての認可プロバイダのアクセス決定がPERMITを返した場合、最終的な判定としてTRUEを返します(つまりWebLogicリソースへのアクセスは許可されます)。

- 一部の認可プロバイダのアクセス決定がPERMITを返し、その他がABSTAINを返した場合、最終的な判定としてTRUEを返します(つまりWebLogicリソースへのアクセスは許可されます)。

- いずれかの認可プロバイダのアクセス決定がDENYを返した場合、最終的な判定としてFALSEを返します(つまりWebLogicリソースへのアクセスは拒否されます)。

注意:

「完全一致の許可が必要」属性は、WebLogic裁決プロバイダを構成するときに設定します。WebLogic裁決プロバイダの構成の詳細は、『Oracle WebLogic Serverの保護』のWebLogic裁決プロバイダの構成に関する項を参照してください。

上記の説明と異なる動作の裁決プロバイダが必要な場合、カスタム裁決プロバイダを開発する必要があります(裁決プロバイダでは、1つの認可プロバイダのアクセス決定がABSTAINを返した場合に、指定したセキュリティ要件に基づいてどのように対処するかを指定することもできます)。

カスタム裁決プロバイダの開発方法

WebLogic裁決プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム裁決プロバイダを開発することができます。

1. 適切なSSPIによるランタイム・クラスの作成、または必要に応じてバルク認可プロバイダを使用

2. WebLogic MBeanMakerを使用してMBeanタイプを生成する

3. 管理コンソールによるカスタム裁決プロバイダの構成

適切なSSPIによるランタイム・クラスの作成

ランタイム・クラスを作成する前に、以下の作業が必要です。

- 「Provider」SSPIの目的について

- SSPI階層を理解し、ランタイム・クラスを1つ作成するか2つ作成するかを決定する

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム裁決プロバイダのランタイム・クラスを作成します。

- AdjudicationProviderV2 SSPIの実装

- AdjudicatorV2 SSPIの実装

AdjudicationProviderV2 SSPIの実装

AdjudicationProviderV2 SSPIを実装するには、「「Provider」SSPIの目的について」で説明されているメソッドおよび次のメソッドの実装を提供する必要があります。

- getAdjudicator

public AdjudicatorV2 getAdjudicator()

getAdjudicatorメソッドは、AdjudicatorV2 SSPIの実装を取得します。MyAdjudicationProviderImpl.javaという1つのランタイム・クラスの場合、getAdjudicatorメソッドの実装は次のようになります。

return this;

ランタイム・クラスが2つの場合、getAdjudicatorメソッドの実装は次のようになります。

return new MyAdjudicatorImpl;

これは、AdjudicationProviderV2 SSPIを実装するランタイム・クラスが、AdjudicatorV2 SSPIを実装するクラスを取得する場合のファクトリとして使用されるためです。

AdjudicationProviderV2 SSPIとgetAdjudicatorメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

AdjudicatorV2 SSPIの実装

AdjudicatorV2 SSPIを実装するには、以下のメソッドの実装を提供する必要があります。

- initialize

public void initialize(AuthorizerMBean[] accessDecisionClassNames)

initializeメソッドは、「アクセスは許されるか」という質問への回答を得るために呼び出されるすべての構成済み認可プロバイダのアクセス決定の名前を初期化します。accessDecisionClassNamesパラメータは、裁決プロバイダのadjudicateメソッドで特定のアクセス決定による判定結果を支持するために使用することもできます。認可プロバイダとアクセス決定の詳細は、第7章「認可プロバイダ」を参照してください。

- adjudicate

public boolean adjudicate(Result[] results, Resource resource,
ContextHandler handler)

adjudicateメソッドは、構成済み認可プロバイダのアクセス決定から返された判定結果をすべて受け取り、「アクセスは許されるか」という質問への回答を決定します。

Adjudicator SSPIとinitializeおよびadjudicateメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

バルク裁決プロバイダ

WebLogic Serverのこのリリースには、以下に示すバルク・アクセス・バージョンの裁決プロバイダSSPIインタフェースがあります。

- BulkAdjudicationProvider

- BulkAdjudicator

バルク・アクセスSSPIインタフェースを使用すると、裁決プロバイダにおいて1回の呼出しで複数の判定リクエストを取得できます。これまでのように、たとえば「for」ループで複数の呼出しを実行する必要はありません。バルクSSPIバリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡されたResourceオブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測できるようになります。

バルク・バージョンでないSSPIインタフェースとバルク・バージョンのSSPIインタフェースの使用方法には若干の違いがあります。

BulkAdjudicator.adjudicate()メソッドはWebLogic Serverの認可マネージャによって渡されたMap (Resource, Result)インスタンス群のListを取り、これにはバルク・アクセス決定の結果が含まれます。結果の順序はBulkAdjudicator.initialize()メソッドに渡されたアクセス決定クラス名の順序と同じです。

BulkAdjudicator.adjudicate()メソッドはResourceオブジェクトのSetを返すことにも注意が必要です。このセットにResourceオブジェクトがある場合、そのオブジェクトへのアクセスが付与されていますが、そうでない場合にはアクセスは拒否されています。

WebLogic MBeanMakerを使用してMBeanタイプを生成する

カスタム・セキュリティ・プロバイダのMBeanタイプを生成する前に、以下の作業が必要です。

- MBeanタイプが必要な理由について

- 拡張および実装するSSPI MBeanの決定

- MBean定義ファイル(MDF)の基本的な要素について

- SSPI MBeanの階層と管理コンソールに対する影響について

- WebLogic MBeanMakerによって提供されるものについて

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム裁決プロバイダのMBeanタイプを作成します。

1. MBean定義ファイル(MDF)の作成

2. WebLogic MBeanMakerを使用してMBeanタイプを生成する

3. WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

4. WebLogic Server環境にMBeanタイプをインストールする

注意:

複数のセキュリティ・プロバイダのサンプルで、これらの手順の実行方法を示します。

この節で説明する手順はすべて、Windows環境での作業を想定しています。

MBean定義ファイル(MDF)の作成

MBean定義ファイル(MDF)を作成するには、次の手順に従います。

1. サンプル認証プロバイダのMDFをテキスト・ファイルにコピーします。

注意:

サンプル認証プロバイダのMDFは、SampleAuthenticator.xmlです(現在、サンプル裁決プロバイダはありません)。

2. MDFで<MBeanType>要素と<MBeanAttribute>要素の内容をカスタム裁決プロバイダに合わせて修正します。

3. カスタム属性および操作(つまり、<MBeanAttribute>および<MBeanOperation>要素)をMDFに追加します。

4. ファイルを保存します。

注意:

MDF要素の構文についての詳細なリファレンスは、付録A「MBean定義ファイル(MDF)要素の構文」に収められています。

WebLogic MBeanMakerを使用してMBeanタイプを生成する

MDFを作成したら、WebLogic MBeanMakerを使用してそれを実行できます。WebLogic MBeanMakerは現在のところコマンドライン・ユーティリティで、入力としてMDFを受け取り、MBeanインタフェース、MBean実装、関連するMBean情報ファイルなどの中間Javaファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム・セキュリティ・プロバイダのMBeanタイプになります。

MBeanタイプの生成手順は、カスタム裁決プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。

- カスタム操作を追加しない場合

- カスタム操作を追加する場合

カスタム操作を追加しない場合

カスタム裁決プロバイダのMDFにカスタム操作を含めない場合、次の手順に従います。

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true
weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

WebLogic MBeanMakerではMDFを一度に1つ処理します。そのため、MDFが複数ある(つまり裁決プロバイダが複数ある)場合には、このプロセスを繰り返す必要があります。

3. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

カスタム操作を追加する場合

カスタム裁決プロバイダのMDFにカスタム操作を含める場合、質問に答えながら手順を進めてください。

MBeanタイプを作成するのは初めてですか。その場合は、次の手順に従ってください:

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true
weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり裁決プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

3. MDFのすべてのカスタム操作に対して、メソッド・スタブを使用してメソッドを実装します。

4. ファイルを保存します。

5. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

既存のMBeanタイプの更新ですか。その場合は、次の手順に従ってください:

1. WebLogic MBeanMakerによって現在のメソッドの実装が上書きされないように、既存のMBean実装ファイルを一時ディレクトリにコピーします。

2. 新しいDOSシェルを作成します。

3. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true
weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり裁決プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

4. MDFを変更して元のMDFにはないカスタム操作を含めた場合、メソッド・スタブを使用してメソッドを実装します。

5. 完成した、つまりすべてのメソッドを実装したMBean実装ファイルを保存します。

6. このMBean実装ファイルを、WebLogic MBeanMakerがMBeanタイプの実装ファイルを配置したディレクトリにコピーします。このディレクトリは、手順3でfilesdirとして指定したものです。(ステップ3の結果としてWebLogic MBeanMakerで生成されたMBean実装ファイルがオーバーライドされます)。

7. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

生成されるMBeanインタフェース・ファイルについて

MBeanインタフェース・ファイルとは、ランタイム・クラスまたはMBean実装が構成データを取得するために使用するMBeanのクライアント側APIです。「「Provider」SSPIの目的について」で説明されているように、これはinitializeメソッドで使用するのが一般的です。

WebLogic MBeanMakerでは、作成済のMDFからMBeanタイプを生成するので、生成されるMBeanインタフェース・ファイルの名前は、そのMDF名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMakerでMyAdjudicator MDFを実行すると、MyAdjudicatorMBean.javaというMBeanインタフェース・ファイルが生成されます。

WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

WebLogic MBeanMakerでMDFを実行して中間ファイルを作成し、MBean実装ファイルを編集して適切なメソッドの実装を提供したら、カスタム裁決プロバイダのMBeanファイルとランタイム・クラスをMBean JARファイル(MJF)にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMakerによって自動化されます。

カスタム裁決プロバイダのMJFを作成するには、次の手順に従います。

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMJF=jarfile -Dfiles=filesdir weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMJFフラグはWebLogic MBeanMakerが新しいMBeanタイプを含むJARファイルを構築すべきであることを示し、jarfileはMJFの名前、filesdirはWebLogic MBeanMakerでMJFにJAR化する対象ファイルが存在する場所を示します。

この時点でコンパイルが行われるので、エラーが発生するおそれがあります。jarfileが指定されていて、エラーが発生しなかった場合には、指定された名前のMJFが作成されます。

注意:

カスタム・セキュリティ・プロバイダのJARファイルを作成する際には、一連のXMLバインディング・クラスと1つのスキーマも生成されます。そのスキーマに関連付けるネームスペースを選択できます。それにより、使用しているカスタム・クラスとOracleのカスタム・クラスとの競合を防ぐことができます。ネームスペースのデフォルトはvendorです。-targetNameSpace引数をWebLogicMBeanMakerまたは関連するWLMBeanMaker antタスクに渡すことで、このデフォルトを変更できます。

既存のMJFを更新する場合は、単純にMJFを削除して再生成します。WebLogic MBeanMakerにも -DIncludeSourceオプションがあり、それを指定すると、生成されるMJFにソース・ファイルを含めるかどうかを制御できます。ソース・ファイルには、生成されたソースとMDFそのものがあります。デフォルトはfalseです。このオプションは、-DMJFを使用しない場合には無視されます。

生成されたMJFは、自らのWebLogic Server環境にインストールすることも、顧客に配布してそれぞれのWebLogic Server環境にインストールしてもらうこともできます。

WebLogic Server環境にMBeanタイプをインストールする

MBeanタイプをWebLogic Server環境にインストールするには、MJFをWL_HOME\server\lib\mbeantypesディレクトリにコピーします。ここで、WL_HOMEはWebLogic Serverの最上位のインストール・ディレクトリです。このインストール・コマンドによって、カスタム裁決プロバイダが「デプロイ」されます。つまり、カスタム裁決プロバイダをWebLogic Server管理コンソールから管理できるようになります。

注意:

MBeanタイプをインストールするデフォルトのディレクトリは、WL_HOME\server\lib\mbeantypesです。初めて使用するバージョンが9.0の場合、セキュリティ・プロバイダは...\domaindir\lib\mbeantypesからもロードできます。ただし、サーバーを起動するときに-Dweblogic.alternateTypesDirectory=<dir>コマンドライン・フラグを使用すれば、WebLogic Serverが追加ディレクトリでMBeanタイプを検索します。<dir>は、ディレクトリ名のカンマ区切りのリストです。このフラグを使用する場合、WebLogic Serverは常に最初にWL_HOME\server\lib\mbeantypesからMBeanタイプをロードします。その後で、追加ディレクトリにあるすべての有効なアーカイブを検索して、ロードします。このとき拡張子は考慮されません。

たとえば、-Dweblogic.alternateTypesDirectory = dirX,dirYの場合、WebLogic ServerはまずWL_HOME\server\lib\mbeantypesからMBeanタイプをロードし、次にdirXおよびdirYにある有効なアーカイブをロードします。WebLogic Serverに追加ディレクトリでMBeanタイプを検索するよう指示する際に、Javaセキュリティ・マネージャを使用している場合は、weblogic.policyファイルを更新して、MBeanタイプ(その結果として、カスタム・セキュリティ・プロバイダ)に適した許可を付与することも必要になります。詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』のJavaセキュリティを使用したWebLogicリソースの保護に関する項を参照してください。

カスタム裁決プロバイダを構成することによって(「管理コンソールによるカスタム裁決プロバイダの構成」を参照) MBeanタイプのインスタンスを作成して、GUI、他のJavaコード、またはAPIからそれらのMBeanインスタンスを使用できます。たとえば、WebLogic Server管理コンソールを使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他のJavaオブジェクトを開発して、そのオブジェクトでMBeanをインスタンス化し、それらのMBeanから提供される情報に自動的に応答させることもできます。なお、これらのMBeanインスタンスをバックアップしておくことをお薦めします。

管理コンソールによるカスタム裁決プロバイダの構成

カスタム裁決プロバイダを構成するということは、裁決サービスを必要とするアプリケーションがアクセス可能なセキュリティ・レルムにカスタム裁決プロバイダを追加するということです。

カスタム・セキュリティ・プロバイダの構成は管理タスクですが、カスタム・セキュリティ・プロバイダの開発者が行うこともできます。WebLogic Server管理コンソールを使用してカスタム裁決プロバイダを構成する手順は、『Oracle WebLogic Serverの保護』のWebLogicセキュリティ・プロバイダの構成に関する項で説明されています。

9 ロール・マッピング・プロバイダ

この章では、ロール・マッピング・プロバイダの概念と機能、およびカスタム・ロール・マッピング・プロバイダの開発手順について説明します。

ロール・マッピングとは、実行時にプリンシパル(ユーザーまたはグループ)をセキュリティ・ロールに動的に割り当てるプロセスのことです。WebLogic Serverでは、ロール・マッピング・プロバイダは、WebLogicリソースを操作しようとしているサブジェクト内のプリンシパルに適用されるセキュリティ・ロールを調べます。通常、この操作ではWebLogicリソースへのアクセスを取得する必要があるので、ロール・マッピング・プロバイダは認可プロバイダと共に使用するのが一般的です。

以下の節では、ロール・マッピング・プロバイダの概念と機能、およびカスタム・ロール・マッピング・プロバイダの開発手順について説明します。

- ロール・マッピングの概念

- ロール・マッピング・プロセス

- カスタム・ロール・マッピング・プロバイダはスレッド・セーフか

- カスタム・ロール・マッピング・プロバイダを開発する必要があるか

- カスタム・ロール・マッピング・プロバイダの開発方法

ロール・マッピングの概念

ロール・マッピング・プロバイダを開発する前に、以下の概念を理解しておく必要があります。

- セキュリティ・ロール

- 動的セキュリティ・ロール計算

- セキュリティ・プロバイダとWebLogicリソース

セキュリティ・ロール

セキュリティ・ロールは、WebLogicリソースへの同じアクセス権限を持つユーザーまたはグループの集合です。グループと同様、セキュリティ・ロールを使用すると、複数のユーザーによるWebLogicリソースへのアクセスを一度に制御できます。ただし、セキュリティ・ロールはWebLogic Serverドメインの特定のリソースをスコープとしており(WebLogic Serverドメイン全体をスコープとするグループとは異なる)、動的に定義することが可能です。「動的セキュリティ・ロール計算」を参照してください。

注意:

セキュリティ・ロールの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。WebLogicリソースの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のセキュリティ・プロバイダとWebLogicリソースに関する項およびポリシーで保護できるリソースのタイプに関する項を参照してください。

weblogic.security.serviceパッケージのSecurityRoleインタフェースは、セキュリティ・ロールの抽象的な記法を表すために用いられます(詳細は、Oracle WebLogic Server APIリファレンスでSecurityRoleインタフェースを参照)。

プリンシパルをセキュリティ・ロールにマップすると、そのプリンシパルがそのセキュリティ・ロールに割り当てられているかぎり、そのプリンシパルには定義されたアクセス許可が付与されます。たとえば、アプリケーションでAppAdminというセキュリティ・ロールを定義し、これによってそのアプリケーションのリソースのごく一部に対する書込みアクセスが提供されるものとします。この場合、AppAdminセキュリティ・ロールに割り当てられたプリンシパルはすべて、それらのリソースに対して書込みアクセス権を持つことになります。詳細は、「動的セキュリティ・ロール計算」と『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

なお、多数のプリンシパルを単一のセキュリティ・ロールにマップすることができます。プリンシパルの詳細は、「ユーザー/グループ、プリンシパル、サブジェクト」を参照してください。

セキュリティ・ロールの指定は、Java EEデプロイメント記述子ファイルかWebLogic Server管理コンソール、あるいはその両方で行われます。詳細については、「ロール・マッピング・プロバイダとデプロイメント記述子の管理」を参照してください。

動的セキュリティ・ロール計算

セキュリティ・ロールは、宣言的なもの(すなわち、Java Enterprise Editionにおけるロール)とすることも、リクエストのコンテキストに基づいて動的に計算することもできます。

動的セキュリティ・ロール計算とは、このようにプリンシパル(ユーザーまたはグループ)を実行時にセキュリティ・ロールにレイト・バインドすることを意味する用語です。こうしたレイト・バインディングは、プリンシパル対セキュリティ・ロールの関連付けが静的に定義されるか動的に計算されるかによらず、保護対象WebLogicリソースについての認可判定の直前に行われます。バインディングが呼出しシーケンス内で行われるため、あらゆるプリンシパル対セキュリティ・ロール計算の結果は、リクエストに対して下される認可判定の一環として、認証用ID情報として解釈することができます。

こうしたセキュリティ・ロールの動的計算には非常に重要な利点があります。つまり、ビジネス・ルールに基づいてユーザーまたはグループをセキュリティ・ロールに関連付けることができるのです。たとえば、本来の管理者が長期の出張で不在の間のみ、ユーザーにManagerセキュリティ・ロールを割り当てることができます。このセキュリティ・ロールを動的に計算することで、そうした一時的な措置のためにアプリケーションを変更したり再デプロイしたりする必要はなくなります。さらに、本来の管理者が戻ってきたときに、その特別に付与した権限を忘れずに取り消す必要もありません。なお、ユーザーを一時的にManagersグループに追加した場合には、その必要があるでしょう。

注意:

通常はWebLogic Server管理コンソールで利用できるロール条件を使用して、ユーザーまたはグループにセキュリティ・ロールを付与します。(このリリースのWebLogic Serverでは、カスタム・ロール条件は記述できません。)詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

計算で得られたセキュリティ・ロールは、ターゲット(利用可能であれば)のID情報やリクエストのパラメータ値など、リクエストのコンテキストを構成する様々な情報にアクセスすることができます。こうしたコンテキスト情報は通常、WebLogicセキュリティ・フレームワークで評価される式に含まれるパラメータの値として使用されます。この機能は、デプロイメント記述子またはWebLogic Server管理コンソールを通じて静的に定義されたセキュリティ・ロールの計算も担当します。

注意:

認証済みユーザーに対するセキュリティ・ロールの計算は、Java EE仕様で定義されているロール・ベース・アクセス制御(RBAC)によるセキュリティ機能を拡張したものです。

動的なセキュリティ・ロール計算を作成するには、WebLogic Server管理コンソールでロール文を定義します。詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

ロール・マッピング・プロセス

WebLogicセキュリティ・フレームワークは、認可判定の一環として、セキュリティ・レルム用に構成されている各ロール・マッピング・プロバイダを呼び出します。関連情報については、「認可プロセス」を参照してください。

ロール・マッピング・プロバイダによる動的セキュリティ・ロール関連計算の結果、一連のセキュリティ・ロールが一度にサブジェクト内のプリンシパルに割り当てられます。その後、これらのセキュリティ・ロールを用いて、保護対象WebLogicリソース、リソース・コンテナ、およびアプリケーション・コードについての認可判定が行われます。たとえば、Enterprise JavaBean (EJB)であれば、アクセスを許可するかどうかを決めるビジネス・ポリシーを知らなくても、Java EEのisCallerInRole()メソッドを用いてデータベース内のレコードからフィールドを取得することができます。

動的セキュリティ・ロール計算を作成する場合のロール・マッピング・プロバイダとWebLogicセキュリティ・フレームワークとの対話を図9-1に示し、続いてそれについて説明します。

図9-1 ロール・マッピング・プロバイダとロール・マッピング・プロセス

「図9-1 ロール・マッピング・プロバイダとロール・マッピング・プロセス」の説明

一般に、ロール・マッピングは以下のように実行されます。

1. ユーザーまたはシステム・プロセスがWebLogicリソースをリクエストし、特定の操作を実行しようとします。

2. リクエストされたWebLogicリソースのタイプを処理するリソース・コンテナがリクエストを受け取ります。たとえばEJBコンテナはEJBリソースに対するリクエストを受け取ります。

注意:

リソース・コンテナは、「セキュリティ・プロバイダとWebLogicリソース」で説明されているWebLogicリソースのいずれかを処理するコンテナです。

3. リソース・コンテナは、リクエストのコンテキストに関連付けられている情報を取得するためにロール・マッピング・プロバイダで使用する場合のあるContextHandlerオブジェクトを作成します。

注意:

ContextHandlerの詳細は、「ContextHandlerとWebLogicリソース」を参照してください。

リソース・コンテナは、サブジェクト(ユーザーおよびグループ・プリンシパルを含む)、WebLogicリソースの識別子、そして場合によっては追加入力を提供するContextHandlerオブジェクトを渡してWebLogicセキュリティ・フレームワークを呼び出します。

注意:

サブジェクトの詳細は、「ユーザー/グループ、プリンシパル、サブジェクト」を参照してください。リソース識別子の詳細は、「WebLogicリソース識別子」を参照してください。

4. WebLogicセキュリティ・フレームワークは、適用するセキュリティ・ロールのリストを取得するために、構成済みの各ロール・マッピング・プロバイダを呼び出します。この仕組みは次のとおりです。

1. ロール・マッピング・プロバイダはContextHandlerを用いて、リクエストに関する様々な情報をリクエストします。また、ロール・マッピング・プロバイダは、リクエストする情報のタイプを表す一連のCallbackオブジェクトを作成します。そのCallbackオブジェクト群は、handleメソッドを通じて、配列としてContextHandlerに渡されます。
ロール・マッピング・プロバイダは、必要なコンテキスト情報を取得するのに、ContextHandlerを複数回呼び出す場合があります。ロール・マッピング・プロバイダでContextHandlerが呼び出される回数はその実装によって異なります。

2. コンテキスト情報と、セキュリティ・ポリシー、サブジェクト、およびWebLogicリソースを格納する関連セキュリティ・プロバイダ・データベースを使用することで、ロール・マッピング・プロバイダは、サブジェクト内のユーザー・プリンシパルとグループ・プリンシパルで表されるリクエスト側に特定のセキュリティ・ロールの資格があるかどうかを決定します。
セキュリティ・ポリシーは、指定されたセキュリティ・ロールを付与すべきかどうかを判定する際に評価される一連の式すなわちルールとして表されます。これらのルールを使用する際に、ロール・マッピング・プロバイダは、取得したコンテキスト情報の値を式のパラメータに代入しなければならない場合があります。さらに、ユーザー・プリンシパルまたはグループ・プリンシパルのID情報が、式のパラメータ値として必要になることもあります。

注意:

セキュリティ・ポリシーのルールは、WebLogic Server管理コンソールとJava EEデプロイメント記述子で設定します。詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のセキュリティ・ポリシーに関する項を参照してください。

3. リクエスト側に特定のセキュリティ・ロールの資格があるとセキュリティ・ポリシーに指定されている場合には、そのセキュリティ・ロールがサブジェクトに適用されるセキュリティ・ロールのリストに追加されます。

4. このプロセスは、WebLogicリソースまたはリソース・コンテナに適用されるセキュリティ・ポリシーがすべて評価されるまで続行されます。

5. セキュリティ・ロールのリストはWebLogicセキュリティ・フレームワークに返され、アクセス決定などの操作の一環として使用できるようになります。

カスタム・ロール・マッピング・プロバイダはスレッド・セーフか

最高のパフォーマンスを実現するため、デフォルトでは、アプリケーションおよびモジュールのデプロイメント中にセキュリティ・ポリシーおよびロールに対して並列変更を実行できます。この理由から、セキュリティ・レルムに構成されているデプロイ可能な認可プロバイダおよびロール・マッピング・プロバイダでは、並列呼出しがサポートされている必要があります。WebLogicのデプロイ可能なXACML認可プロバイダおよびロール・マッピング・プロバイダは、この要件を満たしています。

ただし、カスタムのデプロイ可能な認可プロバイダまたはロール・マッピング・プロバイダで並列呼出しがサポートされている場合とサポートされていない場合があります。カスタムのデプロイ可能な認可プロバイダまたはロール・マッピング・プロバイダが並列呼出しをサポートしない場合、並列セキュリティ・ポリシーとロール変更を無効にして、かわりに各アプリケーションとモジュールがキューに配置され、連続してデプロイされる同期メカニズムを実行する必要があります。

注意:

同期化メカニズムを有効にした場合、定義済のWebLogic Serverプロバイダも含めて、レルム内に構成されているすべてのデプロイ可能なプロバイダが影響を受けます。同期化メカニズムを有効にすると、これらのプロバイダのパフォーマンスに悪影響を与える可能性があります。

この同期化強制メカニズムを有効にする方法については、『Oracle WebLogic Serverの保護』を参照してください。

カスタム・ロール・マッピング・プロバイダを開発する必要があるか

WebLogic Serverのデフォルト(つまりアクティブな)セキュリティ・レルムにはWebLogicロール・マッピング・プロバイダが含まれています。WebLogicロール・マッピング・プロバイダは、デフォルト・ユーザーとWebLogicリソースのそれぞれについて、保護されている特定のリソースに関する特定のユーザー(サブジェクト)の動的セキュリティ・ロールを計算します。また、WebLogicロール・マッピング・プロバイダは、システム内のセキュリティ・ロールのデプロイメントとアンデプロイメントをサポートしています。WebLogicロール・マッピング・プロバイダは、WebLogic認可プロバイダと同じセキュリティ・ポリシー・エンジンを使用します。自社の既存のロール・マッピング・メカニズムを使用する場合は、カスタム・ロール・マッピング・プロバイダを作成してそれを既存のメカニズムに結合できます。

カスタム・ロール・マッピング・プロバイダでアプリケーションのバージョン管理をサポートする必要があるか

セキュリティ・レルムのすべての認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダは、アプリケーションのデプロイにバージョンを使用するために、アプリケーションのバージョン管理をサポートする必要があります。認可、ロール・マッピング、または資格証明マッピング用にカスタム・セキュリティ・プロバイダを開発する際に、バージョン管理されたアプリケーションをサポートする必要がある場合は、第14章「バージョン管理可能なアプリケーションのプロバイダ」の説明に従って、バージョン管理可能なアプリケーションのSSPIを実装する必要があります。

カスタム・ロール・マッピング・プロバイダの開発方法

WebLogicロール・マッピング・プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム・ロール・マッピング・プロバイダを開発することができます。

1. 適切なSSPIを使用してランタイム・クラスの作成または必要に応じてバルク認可プロバイダを実装

2. 必要に応じてロール・コンシューマSSPIを実装

3. WebLogic MBeanMakerを使用してMBeanタイプを生成する

4. 管理コンソールによるカスタム・ロール・マッピング・プロバイダの構成

5. セキュリティ・ロールを管理するためのメカニズムの提供

適切なSSPIによるランタイム・クラスの作成

ランタイム・クラスを作成する前に、以下の作業が必要です。

- 「Provider」SSPIの目的について

- 実装する「Provider」インタフェースの決定

- SSPI階層を理解し、ランタイム・クラスを1つ作成するか2つ作成するかを決定する

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム・ロール・マッピング・プロバイダのランタイム・クラスを作成します。

- RoleProvider SSPIの実装または DeployableRoleProviderV2 SSPIの実装

- RoleMapper SSPIの実装

- SecurityRoleインタフェースの実装

注意:

セキュリティ・レルムでは、少なくとも1つのロール・マッピング・プロバイダがDeployableRoleProviderV2 SSPIを実装する必要があり、実装していない場合、WebアプリケーションやEJBをデプロイできなくなります。

カスタム・ロール・マッピング・プロバイダのランタイム・クラスの作成例については、「例:サンプル・ロール・マッピング・プロバイダのランタイム・クラスの作成」を参照してください。

RoleProvider SSPIの実装

RoleProvider SSPIを実装するには、「Provider」SSPIの目的についてで説明されているメソッドおよび次のメソッドの実装を提供する必要があります。

- getRoleMapper

public RoleMapper getRoleMapper()

getRoleMapperメソッドは、RoleMapper SSPIの実装を取得します。MyRoleProviderImpl.javaという1つのランタイム・クラスの場合、getRoleMapperメソッドの実装は次のようになります。

return this;

ランタイム・クラスが2つの場合、getRoleMapperメソッドの実装は次のようになります。

return new MyRoleMapperImpl;

これは、RoleProvider SSPIを実装するランタイム・クラスが、RoleMapper SSPIを実装するクラスを取得する場合のファクトリとして使用されるためです。

RoleProvider SSPIとgetRoleMapperメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

DeployableRoleProviderV2 SSPIの実装

注意:

DeployableRoleProvider SSPIは、このリリースのWebLogic Serverでは非推奨になっています。DeployableRoleProviderV2 SSPIをかわりに使用してください。

DeployableRoleProviderV2 SSPIを実装するには、「Provider」SSPIの目的についておよび RoleProvider SSPIの実装で説明されているメソッドおよび次のメソッドの実装を提供する必要があります。

- deleteApplicationRoles

void deleteApplicationRoles(ApplicationInfo application)

アプリケーションのすべてのロールを削除し、アプリケーションが削除された時点でWebLogic Serverドメイン内の管理サーバーでのみ呼び出されます。

- deployRole

void deployRole(DeployRoleHandle handle, Resource resource, String roleName,
String[] userAndGroupNames)

デプロイされたWebアプリケーションまたはEJBにかわってロールを作成します。ロールがすでに存在する場合は削除され、このロールによって置き換えられます。

- endDeployRoles

void endDeployRoles(DeployRoleHandle handle)

アプリケーションのロール・デプロイメントの終了をマークします。

- startDeployRoles

DeployRoleHandle startDeployRoles(ApplicationInfo application)

アプリケーションのロール・デプロイメントの開始をマークし、アプリケーションがターゲット指定されているWebLogic Serverドメイン内のすべてのサーバーで呼び出されます。

- undeployAllRoles

void undeployAllRoles(DeployRoleHandle handle)

デプロイされていないWebアプリケーションまたはEJBにかわって、ロールのセットを削除します。

DeployableRoleProvider SSPIとdeployRoleおよびundeployRoleメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

ApplicationInfoインタフェース

ApplicationInfoインタフェースは、アプリケーションのデプロイメントに関するデータをセキュリティ・プロバイダに渡します。このデータを使用すると、アプリケーションを一意に識別できます。

セキュリティ・フレームワークは、ユーザーの利便を図るためにApplicationInfoインタフェースを実装します。このインタフェースのメソッドを実装する必要はありません。

DeployableAuthorizationProviderV2インタフェースとDeployableRoleProviderV2インタフェースはApplicationInfoを使用します。たとえば、DeployableRoleProviderV2のメソッドの実装を例にあげます。セキュリティ・フレームワークは、DeployableRoleProviderV2のstartDeployRolesメソッドを呼び出し、このアプリケーションのApplicationInfoインタフェースを渡します。ApplicationInfoデータは、アプリケーションのデプロイ時に管理コンソールで提供される情報を基に決められます。

startDeployRolesメソッドは、DeployableRoleProviderV2の他のメソッドでこの後使用できるDeployRoleHandleを戻します。

ApplicationInfoインタフェースを使用すると、このアプリケーションのアプリケーション識別子、コンポーネント名、およびコンポーネントの種類を取得できます。コンポーネントの種類は、ApplicationInfo.ComponentTypeクラスの定義に従って、APPLICATION、CONTROL_RESOURCE、EJB、またはWEBAPPのいずれかです。

次のコードは、このタスクを実行する方法の一例です。

public DeployRoleHandle startDeployRoles(ApplicationInfo appInfo)
throws DeployHandleCreationException
:
// Obtain the application information...
String appId = appInfo.getApplicationIdentifier();
ComponentType compType = appInfo.getComponentType();
String compName = appInfo.getComponentName();

セキュリティ・フレームワークは、DeployableRoleProviderV2のdeleteApplicationRolesメソッドを呼び出し、このアプリケーションのApplicationInfoインタフェースを渡します。deleteApplicationRolesメソッドは、アプリケーションのすべてのロールを削除し、アプリケーションが削除された時点でWebLogic Serverドメイン内の管理サーバーでのみ呼び出されます。

RoleMapper SSPIの実装

RoleMapper SSPIを実装するには、以下のメソッドの実装を提供する必要があります。

- getRoles

public Map getRoles(Subject subject, Resource  resource, ContextHandler handler)

getRolesメソッドは、場合によりContextHandlerに指定されたオプショナルな情報を使用して、特定のWebLogicリソースに関して特定のサブジェクトに関連付けられているセキュリティ・ロールを返します。ContextHandlerの詳細は、「ContextHandlerとWebLogicリソース」を参照してください。

RoleMapper SSPIとgetRolesメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

レルム・アダプタ認証プロバイダと互換性のあるカスタム・ロール・マッピング・プロバイダを開発する

認証プロバイダは、サブジェクト内へのユーザーおよびグループの格納を担当するセキュリティ・プロバイダです。ユーザーおよびグループはその後、ロール・マッピング・プロバイダなど、他のタイプのセキュリティ・プロバイダによって、サブジェクトから抽出されます。セキュリティ・レルム内で構成された認証プロバイダがレルム・アダプタ認証プロバイダである場合、ユーザーおよびグループの情報は、他の認証プロバイダとは少し異なる形でサブジェクト内に格納されます。したがって、このユーザーおよびグループの情報もまた、少し異なる方法で抽出する必要があります。

例9-1では、サブジェクトへの格納にレルム・アダプタ認証プロバイダが使用された場合に、サブジェクトがユーザー名またはグループ名に一致するかどうかをチェックするため、カスタム・ロール・マッピング・プロバイダで使用できるコードを示します。このコードは、getRolesメソッドに属しています。

例9-1 サンプル・コード:サブジェクトがユーザー名またはグループ名に一致するかどうかのチェック

/**
* Determines if the Subject matches a user/group name.
*
* @param principalWant A String containing the name of a principal in this role
* (that is, the role definition).
*
* @param subject A Subject that contains the Principals that identify the user
* who is trying to access the resource as well as the user's groups.
*
* @return A boolean. true if the current subject matches the name of the
* principal in the role, false otherwise.
*/
private boolean subjectMatches(String principalWant, Subject subject)
{
// first, see if it's a group name match
if (SubjectUtils.isUserInGroup(subject, principalWant)) {
return true;
}
// second, see if it's a user name match
if (principalWant.equals(SubjectUtils.getUsername(subject))) {
return true;
}
// didn't match
return false;
}

SecurityRoleインタフェースの実装

SecurityRoleインタフェースのメソッドを使用して、セキュリティ・ロールに関する基本的な情報を取得したり、取得した情報を別のセキュリティ・ロールと比較したりできます。これらのメソッドは、セキュリティ・プロバイダの利便性のために設計されています。

注意:

SecurityRole実装は、getRoles()メソッドによってMapとして返されます。(RoleProvider SSPIの実装を参照)。

SecurityRoleインタフェースを実装するには、以下のメソッドの実装を提供する必要があります。

- equals

public boolean equals(Object another)

equalsメソッドは、渡されたセキュリティ・ロールが、このインタフェースの実装によって表されるセキュリティ・ロールに一致する場合にTRUEを返し、それ以外の場合はFALSEを返します。

- toString

public String toString()

toStringメソッドは、このセキュリティ・ロールをStringとして返します。

- hashCode

public int hashCode()

hashCodeメソッドは、このセキュリティ・ロールのハッシュ・コードを整数で返します。

- getName

public String getName()

getNameメソッドは、このセキュリティ・ロールの名前をStringとして返します。

- getDescription

public String getDescription()

getDescriptionメソッドは、このセキュリティ・ロールの説明をStringとして返します。説明は、このセキュリティ・ロールの目的を記述したものです。

例:サンプル・ロール・マッピング・プロバイダのランタイム・クラスの作成

例9-2は、サンプル・ロール・マッピング・プロバイダのランタイム・クラスであるSimpleSampleRoleMapperProviderImpl.javaクラスを示しています。このランタイム・クラスには次の実装が含まれています。

- initialize、getDescription、およびshutdownというSecurityProviderインタフェースから継承した3つのメソッド(「「Provider」SSPIの目的について」を参照)。

- getRoleMapperというRoleProvider SSPIから継承したメソッド(「RoleProvider SSPIの実装」を参照)。

- deleteApplicationRoles、deployRole、endDeployRoles、startDeployRoles、およびundeployAllRolesというDeployableRoleProviderV2 SSPIの5つのメソッド(「DeployableRoleProviderV2 SSPIの実装」を参照)。

- getRolesというRoleMapper SSPIのメソッド(「RoleProvider SSPIの実装」を参照)。

注意:

例9-2の太字のコードは、クラス宣言とメソッド・シグネチャを示しています。

例9-2 SimpleSampleRoleMapperProviderImpl.java

package examples.security.providers.roles.simple;

import java.security.Principal;
import java.util.Collections;
import java.util.Date;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.HashSet;
import java.util.Iterator;
import java.util.Map;
import java.util.Properties;
import java.util.Set;
import javax.security.auth.Subject;
import weblogic.management.security.ProviderMBean;
import weblogic.security.SubjectUtils;
import weblogic.security.WLSPrincipals;
import weblogic.security.service.ContextHandler;
import weblogic.security.spi.ApplicationInfo;
import weblogic.security.spi.ApplicationInfo.ComponentType;
import weblogic.security.spi.DeployableRoleProviderV2;
import weblogic.security.spi.DeployRoleHandle;
import weblogic.security.spi.Resource;
import weblogic.security.spi.RoleMapper;
import weblogic.security.spi.SecurityServices;
import weblogic.security.spi.VersionableApplicationProvider;

public final class SimpleSampleRoleMapperProviderImpl
implements DeployableRoleProviderV2, RoleMapper, VersionableApplicationProvider
{
private String              description;
// a description of this provider
private SimpleSampleRoleMapperDatabase database;
// manages the role definitions for this provider
private static final Map NO_ROLES = Collections.unmodifiableMap(new HashMap(1));
// used when no roles are found

public void initialize(ProviderMBean mbean, SecurityServices services)
{
System.out.println("SimpleSampleRoleMapperProviderImpl.initialize");

// Cast the mbean from a generic ProviderMBean to a SimpleSampleRoleMapperMBean.
SimpleSampleRoleMapperMBean myMBean = (SimpleSampleRoleMapperMBean)mbean;

// Set the description to the simple sample role mapper's mbean's description and version
description = myMBean.getDescription() + "\n" + myMBean.getVersion();

// Instantiate the helper that manages this provider's role definitions
database = new SimpleSampleRoleMapperDatabase(myMBean);
}
public String getDescription()
{
return description;
}

public void shutdown()
{
System.out.println("SimpleSampleRoleMapperProviderImpl.shutdown");
}

public RoleMapper getRoleMapper()
{
// Since this class implements both the DeployableRoleProvider
// and RoleMapper interfaces, this object is the
// role mapper object so just return "this".
return this;
}

public Map getRoles(Subject subject, Resource resource, ContextHandler handler)
{
System.out.println("SimpleSampleRoleMapperProviderImpl.getRoles");
System.out.println("\tsubject\t= " + subject);
System.out.println("\tresource\t= " + resource);

// Make a list for the roles
Map roles = new HashMap();

// Make a list for the roles that have already been found and evaluated
Set rolesEvaluated = new HashSet();

// since resources scope roles, and resources are hierarchical,
// loop over the resource and all its parents, adding in any roles
// that match the current subject.
for (Resource res = resource; res != null; res = res.getParentResource()) {
getRoles(res, subject, roles, rolesEvaluated);
}

// try global resources too
getRoles(null, subject, roles, rolesEvaluated);

// special handling for no matching roles
if (roles.isEmpty()) {
return NO_ROLES;
}

// return the roles we found.
System.out.println("\troles\t= " + roles);
return roles;
}

public DeployRoleHandle startDeployRoles(ApplicationInfo application)
{
String appId = application.getApplicationIdentifier();
String compName = application.getComponentName();
ComponentType compType = application.getComponentType();
DeployRoleHandle handle = new SampleDeployRoleHandle(appId,compName,compType);

// ensure that previous roles have been removed so that
// the most up to date deployment roles are in effect
database.removeRolesForComponent(appId, compName, compType);

// A null handle may be returned if needed
return handle;

}

public void deployRole(DeployRoleHandle handle, Resource resource,
String roleName, String[] principalNames)
{
System.out.println("SimpleSampleRoleMapperProviderImpl.deployRole");
System.out.println("\thandle\t\t= " + ((SampleDeployRoleHandle)handle).toString());
System.out.println("\tresource\t\t= " + resource);
System.out.println("\troleName\t\t= " + roleName);

for (int i = 0; principalNames != null && i < principalNames.length; i++) {
System.out.println("\tprincipalNames[" + i + "]\t= " + principalNames[i]);
}
database.setRole(resource, roleName, principalNames);
}
public void endDeployRoles(DeployRoleHandle handle)
{
database.saveRoles();
}

public void undeployAllRoles(DeployRoleHandle handle)
{
System.out.println("SimpleSampleRoleMapperProviderImpl.undeployAllRoles");
SampleDeployRoleHandle myHandle = (SampleDeployRoleHandle)handle;
System.out.println("\thandle\t= " + myHandle.toString());

// remove roles
database.removeRolesForComponent(myHandle.getApplication(),
myHandle.getComponent(),
myHandle.getComponentType());
}

public void deleteApplicationRoles(ApplicationInfo application)
{
System.out.println("SimpleSampleRoleMapperProviderImpl.deleteApplicationRoles");
String appId = application.getApplicationIdentifier();
System.out.println("\tapplication identifier\t= " + appId);

// clear out roles for the application
database.removeRolesForApplication(appId);
}

private void getRoles(Resource resource, Subject subject,
Map roles, Set rolesEvaluated)
{
// loop over all the roles in our "database" for this resource
for (Enumeration e = database.getRoles(resource); e.hasMoreElements();) {
String role = (String)e.nextElement();

// Only check for roles not already evaluated
if (rolesEvaluated.contains(role)) {
continue;
}
// Add the role to the evaluated list
rolesEvaluated.add(role);

// If any of the principals is on that role, add the role to the list.
if (roleMatches(resource, role, subject)) {

// Add a simple sample role mapper role instance to the list of roles.
roles.put(role, new SimpleSampleSecurityRoleImpl(role));
}
}
}

private boolean roleMatches(Resource resource, String role, Subject subject)
{
// loop over the the principals that are in this role.
for (Enumeration e = database.getPrincipalsForRole(resource, role); e.hasMoreElements();) {

// get the next principal in this role
String principalWant = (String)e.nextElement();

// see if any of the current principals match this principal
if (subjectMatches(principalWant, subject)) {
return true;
}
}
return false;
}

private boolean subjectMatches(String principalWant, Subject subject)
{
// first, see if it's a group name match
if (SubjectUtils.isUserInGroup(subject, principalWant)) {
return true;
}
// second, see if it's a user name match
if (principalWant.equals(SubjectUtils.getUsername(subject))) {
return true;
}
// didn't match
return false;
}

public void createApplicationVersion(String appId, String sourceAppId)
{
System.out.println("SimpleSampleRoleMapperProviderImpl.createApplicationVersion");
System.out.println("\tapplication identifier\t= " + appId);
System.out.println("\tsource app identifier\t= " + ((sourceAppId != null) ? sourceAppId : "None"));

// create new roles when existing application is specified
if (sourceAppId != null) {
database.cloneRolesForApplication(sourceAppId,appId);
}
}

public void deleteApplicationVersion(String appId)
{
System.out.println("SimpleSampleRoleMapperProviderImpl.deleteApplicationVersion");
System.out.println("\tapplication identifier\t= " + appId);

// clear out roles for the application
database.removeRolesForApplication(appId);
}

public void deleteApplication(String appName)
{
System.out.println("SimpleSampleRoleMapperProviderImpl.deleteApplication");
System.out.println("\tapplication name\t= " + appName);

// clear out roles for the application
database.removeRolesForApplication(appName);
}

class SampleDeployRoleHandle implements DeployRoleHandle
{
Date date;
String application;
String component;
ComponentType componentType;

SampleDeployRoleHandle(String app, String comp, ComponentType type)
{
this.application = app;
this.component = comp;
this.componentType = type;
this.date = new Date();
}

public String getApplication() { return application; }
public String getComponent() { return component; }
public ComponentType getComponentType() { return componentType; }

public String toString()
{
String name = component;
if (componentType == ComponentType.APPLICATION)
name = application;
return componentType +" "+ name +" ["+ date.toString() +"]";
}
}
}

例9-3は、SimpleSampleRoleMapperProviderImpl.javaランタイム・クラスとともに使用するSecurityRoleの実装例を示しています。

例9-3 SimpleSampleSecurityRoleImpl.java

package examples.security.providers.roles.simple;
import weblogic.security.service.SecurityRole;
/*package*/ class SimpleSampleSecurityRoleImpl implements SecurityRole
{
private String roleName; // the role's name
private int    hashCode; // the role's hash code
/*package*/ SimpleSampleSecurityRoleImpl(String roleName)
{
this.roleName = roleName;
this.hashCode = roleName.hashCode() + 17;
}
public boolean equals(Object genericRole)
{
// if the other role is null, we're not the same
if (genericRole == null) {
return false;
}
// if we're the same java object, we're the same
if (this == genericRole) {
return true;
}

// if the other role is not a simple sample role mapper role,
// we're not the same
if (!(genericRole instanceof SimpleSampleSecurityRoleImpl)) {
return false;
}

// Cast the other role to a simple sample role mapper role.
SimpleSampleSecurityRoleImpl sampleRole =
(SimpleSampleSecurityRoleImpl)genericRole;
// if our names don't match, we're not the same
if (!roleName.equals(sampleRole.getName())) {
return false;
}
// we're the same
return true;
}
public String toString()
{
return roleName;
}

public int hashCode()
{
return hashCode;
}

public String getName()
{
return roleName;
}
public String getDescription()
{
return "";
}
}

ロール・コンシューマSSPI

WebLogic ServerにはWebサービス・アノテーション用のロール・コンシューマが実装されています。このリリースのWebLogic Serverには、ロール・マッピング・プロバイダがロール・コレクションを取得するために使用できるSSPIがあります。

RoleConsumer SSPIは省略可能です。ロール・コレクションを消費するためには、このSSPIを実装するロール・マッピング・プロバイダのみが呼び出されます。

このSSPIでは、初期状態のロール・コレクションの配信と、更新後のロール・コレクションの配信の両方がサポートされます。

ロール・コレクションの消費においては、RoleConsumer SSPIをサポートするすべてのロール・マッピング・プロバイダが呼び出されます。各ロール・マッピング・プロバイダは、特定のロール・セットのロール・コレクションを取得するかしないかを選択できます。プロバイダでロールが永続化される場合、ロールを取得する必要があるのは一度だけです。一方、プロバイダでロールがメモリーに保持される場合、ロール・コレクションを再び取得することも可能です。

用意されているWebLogic Serverロール・マッピング・プロバイダでは、ロールはLDAP内に永続化されます。

必要なSSPIインタフェース

ロール・マッピング・プロバイダをカスタマイズしてロール・コレクションの配信をサポートするには、以下の3つのインタフェースを実装する必要があります。

- weblogic.security.spi.RoleConsumerFactory

- weblogic.security.spi.RoleConsumer

- weblogic.security.spi.RoleCollectionHandler

これらのインタフェースについては、これ以降の節で説明します。

RoleConsumerFactory SSPIインタフェースの実装

ロール・マッピング・プロバイダには、RoleConsumerのインスタンスをWebLogicセキュリティ・フレームワークで使用できるように、RoleConsumerFactoryインタフェースが実装されています。WebLogicセキュリティ・フレームワークではRoleConsumerFactoryの実装を呼び出して、プロバイダのロール・コンシューマの実装を取得します。

RoleConsumerFactory SSPIにはメソッドが1つあり、このメソッドはRoleConsumer SSPIインタフェースの実装を返します。

public interface RoleConsumerFactory
{
/**
* Obtain the implementation of the RoleConsumer
* security service provider interface (SSPI).<P>
*
* @return a RoleConsumer SSPI implementation.<P>
*/
public RoleConsumer getRoleConsumer();
}

RoleConsumer SSPIインタフェースの実装

RoleConsumer SSPIは、ロール・コレクションを消費するためのロール・コレクション・ハンドラを返します。これにはgetRoleCollectionHandler()というメソッドが1つあり、このメソッドは引数にRoleCollectionInfoの実装を取って、RoleCollectionHandlerインタフェースの実装を返します。

public interface RoleConsumer
{
/**
* Obtain a role handler for consumption of a role collection.
*
* @param info the RoleCollectionInfo for the role collection.
*
* @return a RoleCollectionHandler or NULL which indicates
*         that the role collection is not needed.
*
* @exception ConsumptionException if an error occurs
*            obtaining the handler and the role collection cannot be consumed.
*/
public RoleCollectionHandler getRoleCollectionHandler(
RoleCollectionInfo info)
throws ConsumptionException;
}

WebLogicセキュリティ・フレームワークではgetRoleCollectionHandler()メソッドを呼び出して、ロール・コレクションに関するデータをRoleCollectionInfoインタフェースの実装としてセキュリティ・プロバイダに渡します(このインタフェースはあらかじめ実装されているので、ユーザーが実装する必要はありません。)

RoleCollectionInfoのgetName()、getVersion()、getTimestamp()、およびgetResourceTypes()メソッドを使用して、このロール・コレクションに関する情報を検索します。検索後にはRoleCollectionHandlerを返すか、ロール・コレクションが不要であることを示すNULLを返します。

public interface RoleCollectionInfo
{
/**
* Get the name of the collection.
*/
public String getName();

/**
* Get the runtime version of the role.
*/
public String getVersion();

/**
* Get the timestamp of the role.
*/
public String getTimestamp();

/**
* Get the resource types used in the role collection.
*/
public Resource[] getResouceTypes();
}

RoleCollectionHandler SSPIインタフェースの実装

RoleConsumer.getRoleCollectionHandler()メソッドはRoleCollectionHandlerインタフェースの実装を返します。RoleCollectionHandlerにはsetRole()とdone()という2つのメソッドがあります。setRole()メソッドは、リソース、ロール名、およびその特定のリソース用のロールに割り当てる一連のユーザー名とグループ名の配列を取ります。

done()メソッドはロール・コレクションの完了を示します。

public interface RoleCollectionHandler
{
/**
* Set a role for the specified resource.
*/
public void setRole(Resource resource, String roleName, String[] userAndGroupNames)
throws ConsumptionException;

/**
* Signals the completion of the role collection.
*/
public void done()
throws ConsumptionException;

}

更新後のロール・コレクションのサポート

更新後のロール・コレクションの配信をサポートするには、RoleConsumer SSPIをサポートするすべてのロール・マッピング・プロバイダで、RoleConsumer.getRoleCollectionHandler()メソッドに渡されたRoleCollectionInfoの内容を調べて、ロール・コレクションが変更されているかどうかを判断する必要があります。各プロバイダでは、初期状態のロール・コレクションとSSPIの外部から受け取ったカスタマイズ後のロールとの競合を解決する方法を(できれば構成によって)決定しておくことが必要です。

WebLogic Serverで提供されているロール・マッピング・プロバイダでは、カスタマイズ後のロールが更新後のロール・コレクションで置き換えられません。初期状態のロール・コレクションのロールはすべて削除され、カスタマイズ後のロールと更新後のロール・コレクションのみが有効になります。ロール・コレクションの情報に異なるタイムスタンプやバージョンがある場合、更新後のロール・コレクションとして扱われます。コレクションの名前は永続キーとして使用されます。

RoleConsumerMBean

ロール・コンシューマSSPIを実装するロール・マッピング・プロバイダには、そのプロバイダでロールの消費をサポートすることを示すためにweblogic.management.security.authorization.RoleConsumerMBeanも実装する必要があります。

PolicyStoreMBean

このリリースのWebLogic Serverでは、weblogic.management.security.authorization.PolicyStoreMBeanという新しいMBeanがサポートされています。このMBeanは、管理者が生成したXACMLポリシーおよびポリシー・セットの標準的な管理操作(追加、削除、取得、リスト表示、変更、読込み)に使用できます。認可プロバイダMBeanやロール・マッピング・プロバイダMBeanには、必要に応じてこのMBeanインタフェースを実装できます。

セキュリティ管理者は、PolicyStoreMBeanのメソッドを使用して、サーバー内のポリシーをXACMLドキュメントとして管理できます。たとえば、デフォルトのXACMLプロバイダを使用するドメインを作成および管理したり、作成済のXACMLドキュメントを管理したりできます。これらのXACMLポリシーは、WebLogic ServerではWLSTを使用して管理できます。

WebLogic ServerにはこのMBeanの実装が含まれており、付属のXACMLプロバイダで使用できます。また、このMBeanの独自の実装を記述して、カスタムの認可プロバイダやロール・マッピング・プロバイダで使用することも可能です。WebLogic Serverに用意されているXACMLプロバイダでは、XACML 2.0のコア仕様(http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf)に記載されているXACMLの必須機能がサポートされています。Oracle固有の使用方法については、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。

ポリシーはXACML 2.0のポリシーまたはPolicySetドキュメントで表現されます。カスタム認可プロバイダでは、XACML 2.0のコア仕様に記載されている標準のPolicyまたはPolicySetドキュメントを想定する必要があります。カスタム・ロール・マッピング・プロバイダでは、Core and hierarchical role based access control (RBAC) profile of XACML v2.0 (http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-rbac-profile1-spec-os.pdf)に記載されているロール割当てポリシーと整合性があるPolicyまたはPolicySetドキュメントを想定する必要があります。

具体的には、Targetに以下を含める必要があります。

- ActionAttributeDesignator (anyURI-equalで一致する、urn:oasis:names:tc:xacml:1.0:action:action-idというIDと、urn:oasis:names:tc:xacml:2.0:actions:enableRoleという値の指定されているもの)。例:

<Action>
<ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">

<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:oasis:names:tc:xacml:2.0:actions:enableRole
</AttributeValue>

<ActionAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#anyURI" MustBePresent="true"/>

</ActionMatch>
</Action>

- ResourceAttributeDesignator (string-equalで一致する、urn:oasis:names:tc:xacml:2.0:subject:roleというIDと、割り当てられたロールの名前である値の指定されているもの)。例:

<ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor-or-self"
DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>

XACML Policyファイルの形式の調べ

XACML 2.0のコア仕様(http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf)および『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』で説明しているOracle拡張が、提供されているXACML認可プロバイダおよびロール・マッピング・プロバイダで使用するXACMLポリシー・ファイルについての最も確実な情報です。

ただしサポートされているXACMLファイルの形式を開発プロセスの一環として確認する場合は、おそらく、管理コンソールを使用して、XACML認可またはロール・マッピング・プロバイダのデータベースからデータをXACMLファイルとしてエクスポートする方法が最も便利です。エクスポートしたXACMLファイルをコピーして別の名前で保存し、任意のツールで確認します。

注意:

エクスポートしたファイルは読取り専用としてください。変更した場合、そのファイルはWebLogic Serverにインポートし直さないでください。エクスポートしたファイルを編集すると、WebLogic Server構成が使用できなくなる可能性があります。エクスポートしたファイルの編集はサポートされていません。

WLSTを使用してPolicyStoreMBeanにポリシーの追加

例9-4に、WLSTを使用してXACMLファイルからPolicyStoreMBeanのインスタンスに1つのポリシーを追加する例を示します。

この例ではこのスクリプトで使用するプロパティを、次のantスクリプトから抜粋した行に似た方法で、あらかじめ別の場所に定義してあるものと想定しています。

<property name="xacml-docs-dir" value="${xacmldir}/xacml-docs"/>
<sysproperty key="file" value="${xacml-docs-dir}/policy-getSubject.xacml"/>

例9-4 WLSTを使用してPolicyStoreMBeanにポリシーの追加

:
try:
protocol = System.getProperty("protocol")
host = System.getProperty("host")
user = System.getProperty("authuser")
passwd = System.getProperty("authpwd")
port = System.getProperty("port")
dom = System.getProperty("domain")
rlm = System.getProperty("realm")
fil = System.getProperty("file")
prov = System.getProperty("provider")
stat = System.getProperty("status")

def configure():
try:
url = protocol + "://" + host + ":" + port
connect(user,passwd, url)
path = "/SecurityConfiguration/" + dom + "/Realms/" + rlm + "/" + prov
print("cd'ing to " + path)
cd(path)
print("calling open()")
xacmlFile = open(fil,"r")
print("calling read()")
xacmlDoc = xacmlFile.read()
print("calling cmo.addPolicy")
if stat == "none":
cmo.addPolicy(xacmlDoc)
else:
cmo.addPolicy(xacmlDoc, stat)
print("Add error handling")
:
:

『Oracle WebLogic Scripting Tool』のMBeanの移動と照会に関する項で説明しているように、WLSTが初めてWebLogic Serverインスタンスに接続すると、変数cmo(現在の管理オブジェクト)がすべての構成管理オブジェクトのルートDomainMBeanに初期化されます。MBeanタイプに移動すると、このSecurityConfigurationMBeanの場合、cmoの値はSecurityConfigurationMBeanを反映したものになります。MBeanインスタンス、つまりこの場合にはPolicyStoreMBeanを実装する認可プロバイダMBean(例では変数provで指定)に移動するときには、WLSTによってcmoの値が現在のMBeanインスタンスに変更されます。

この例ではPolicyStoreMBeanのaddPolicy()メソッドを使用して、XACMLファイルからポリシー・ストアに読み込まれるポリシーを追加しています。addPolicy()メソッドの2つのバリアント(ステータスを伴うものと伴わないもの)が示されています。

ステータスを指定しないaddPolicy()メソッドを使用する場合、デフォルトでACTIVEに設定されます。これは、ポリシーがそのターゲットで適用されるどのような決定でも評価されることを示します。ステータスは明示的にACTIVE、INACTIVE、またはBYREFERENCEに設定できます。INACTIVEステータスは、ポリシーが評価されずに格納されるだけであることを示します。BYREFERENCEステータスは、評価されるポリシー・セットによって参照された場合にだけ、ポリシーが評価されることを示します。

このタイプのWLSTスクリプトは、次のような方法でコマンドラインから呼び出せます。

java -Dhost="localhost " -Dprotocol="t3" -Dauthuser="weblogic"
-Dauthpwd="weblogic" -Dport="7001" -Ddomain="mydomain" -Drealm="myrealm"
-Dprovider="Authorizers/XACMLAuthorizer"
-Dfile="C:/XACML/xacml-docs/policy12.xml" -Dstatus="none" weblogic.WLST
XACML/scripts/XACMLaddPolicy.py

WLSTを使用してPolicySetをStringとして読み込む

例9-5に、WLSTを使用してPolicySetをStringとして読み込む例を示します。

この例ではこのスクリプトで使用するプロパティを、次のantスクリプトから抜粋した行に似た方法で、あらかじめ別の場所に定義してあるものと想定しています。

<sysproperty key="identifier"
value="urn:sample:xacml:2.0:wlssecqa:resource:type@E@Fejb@G@M@Oapplication@ENoD
DRolesOrPoliciesEar@M@Omodule@Eejb11inEarMiniAppBean.jar@M@Oejb@EMiniAppBean@
M@Omethod@EgetSubject@M@OmethodInterface@ERemote"/>
<sysproperty key="version" value="1.0"/>

例9-5 WLSTを使用してPolicySetをStringとして読み込む

:
:
try:
print("start XACMLreadPolicySet.py")
protocol = System.getProperty("protocol")
host = System.getProperty("host")
user = System.getProperty("authuser")
passwd = System.getProperty("authpwd")
port = System.getProperty("port")
dom = System.getProperty("domain")
rlm = System.getProperty("realm")
prov = System.getProperty("provider")
id = System.getProperty("identifier")
vers = System.getProperty("version")
:
:
def configure():
try:
url = protocol + "://" + host + ":" + port
connect(user,passwd, url)
path = "/SecurityConfiguration/" + dom + "/Realms/" + rlm + "/" + prov
print("cd'ing to " + path)
cd(path)
polset = cmo.readPolicySetAsString(id, vers)
print("readPolicySetAsString() returned the following policy set: " + polset)
print"Add error handling."
:
:

XACML 2.0のコア仕様(http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf)で説明されているように、<PolicySet>要素には<Policy>のセットまたは別の<PolicySet>要素、およびそれらの評価結果を結合するための指定された手順が含まれます。詳細については、XACML 2.0のコア仕様を参照してください。

バルク・ロール・マッピング・プロバイダ

WebLogic Serverのこのリリースには、以下に示すバルク・アクセス・バージョンのロール・マッピング・プロバイダSSPIインタフェースがあります。

- BulkRoleProvider

- BulkRoleMapper

バルク・アクセスSSPIインタフェースを使用すると、ロール・マッピング・プロバイダにおいて、1回の呼出しで複数の判定リクエストを取得できます。これまでのように、たとえば「for」ループで複数の呼出しを実行する必要はありません。バルクSSPIバリアントの目的は、プロバイダ実装において内部的なパフォーマンスの最適化を利用できるようにすることです。たとえば、渡されたResourceオブジェクトの多くが同じポリシーで保護されていることを検出することで、それらの判定結果が同じになると推測できるようになります。

バルク・バージョンでないSSPIインタフェースとバルク・バージョンのSSPIインタフェースの使用方法には若干の違いがあります。たとえば、BulkRoleMapper.getRoles()メソッドはロールのMapを返します。これは、初めにリソース、続いて名前で索引付けされ(Map<Resource, Map<String, SecurityRole>>)、サブジェクトに許可されている指定のリソースに関連付けられたセキュリティ・ロールを表します。

WebLogic MBeanMakerを使用してMBeanタイプを生成する

カスタム・セキュリティ・プロバイダのMBeanタイプを生成する前に、以下の作業が必要です。

- MBeanタイプが必要な理由について

- 拡張および実装するSSPI MBeanの決定

- MBean定義ファイル(MDF)の基本的な要素について

- SSPI MBeanの階層と管理コンソールに対する影響について

- WebLogic MBeanMakerによって提供されるものについて

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム・ロール・マッピング・プロバイダのMBeanタイプを作成します。

1. MBean定義ファイル(MDF)の作成

2. WebLogic MBeanMakerを使用してMBeanタイプを生成する

3. WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

4. WebLogic Server環境にMBeanタイプをインストールする

注意:

複数のセキュリティ・プロバイダのサンプルで、これらの手順の実行方法を示します。

この節で説明する手順はすべて、Windows環境での作業を想定しています。

MBean定義ファイル(MDF)の作成

MBean定義ファイル(MDF)を作成するには、次の手順に従います。

1. サンプル・ロール・マッピング・プロバイダのMDFをテキスト・ファイルにコピーします。

注意:

サンプル・ロール・マッピング・プロバイダのMDFは、SimpleSampleRoleMapper.xmlという名前です。

2. MDFで<MBeanType>要素と<MBeanAttribute>要素の内容をカスタム・ロール・マッピング・プロバイダに合わせて修正します。

3. カスタム属性および操作(つまり、<MBeanAttribute>および<MBeanOperation>要素)をMDFに追加します。

4. ファイルを保存します。

注意:

MDF要素の構文についての詳細なリファレンスは、付録A「MBean定義ファイル(MDF)要素の構文」に収められています。

WebLogic MBeanMakerを使用してMBeanタイプを生成する

MDFを作成したら、WebLogic MBeanMakerを使用してそれを実行できます。WebLogic MBeanMakerは現在のところコマンドライン・ユーティリティで、入力としてMDFを受け取り、MBeanインタフェース、MBean実装、関連するMBean情報ファイルなどの中間Javaファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム・セキュリティ・プロバイダのMBeanタイプになります。

MBeanタイプの生成手順は、カスタム・ロール・マッピング・プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。

- カスタム操作を追加しない場合

- カスタム操作を追加する場合

カスタム操作を追加しない場合

カスタム・ロール・マッピング・プロバイダのMDFにカスタム操作を含めない場合、次の手順に従います。

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまりロール・マッピング・プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

3. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

カスタム操作を追加する場合

カスタム・ロール・マッピング・プロバイダのMDFにカスタム操作を含める場合、質問に答えながら手順を進めてください。

MBeanタイプを作成するのは初めてですか。その場合は、次の手順に従ってください:

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまりロール・マッピング・プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

3. MDFのすべてのカスタム操作に対して、メソッド・スタブを使用してメソッドを実装します。

4. ファイルを保存します。

5. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

既存のMBeanタイプの更新ですか。その場合は、次の手順に従ってください:

1. WebLogic MBeanMakerによって現在のメソッドの実装が上書きされないように、既存のMBean実装ファイルを一時ディレクトリにコピーします。

2. 新しいDOSシェルを作成します。

3. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまりロール・マッピング・プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

4. MDFを変更して元のMDFにはないカスタム操作を含めた場合、メソッド・スタブを使用してメソッドを実装します。

5. 完成した、つまりすべてのメソッドを実装したMBean実装ファイルを保存します。

6. このMBean実装ファイルを、WebLogic MBeanMakerがMBeanタイプの実装ファイルを配置したディレクトリにコピーします。このディレクトリは、手順3でfilesdirとして指定したものです。(ステップ3の結果としてWebLogic MBeanMakerで生成されたMBean実装ファイルがオーバーライドされます)。

7. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

生成されるMBeanインタフェース・ファイルについて

MBeanインタフェース・ファイルとは、ランタイム・クラスまたはMBean実装が構成データを取得するために使用するMBeanのクライアント側APIです。「「Provider」SSPIの目的について」で説明されているように、これはinitializeメソッドで使用するのが一般的です。

WebLogic MBeanMakerでは、作成済のMDFからMBeanタイプを生成するので、生成されるMBeanインタフェース・ファイルの名前は、そのMDF名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMakerでSampleRoleMapper MDFを実行すると、SampleRoleMapperMBean.javaというMBeanインタフェース・ファイルが生成されます。

WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

WebLogic MBeanMakerでMDFを実行して中間ファイルを作成し、MBean実装ファイルを編集して適切なメソッドの実装を提供したら、カスタム・ロール・マッピング・プロバイダのMBeanファイルとランタイム・クラスをMBean JARファイル(MJF)にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMakerによって自動化されます。

カスタム・ロール・マッピング・プロバイダのMJFを作成するには、次の手順に従います。

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMJF=jarfile -Dfiles=filesdir weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMJFフラグはWebLogic MBeanMakerが新しいMBeanタイプを含むJARファイルを構築すべきであることを示し、jarfileはMJFの名前、filesdirはWebLogic MBeanMakerでMJFにJAR化する対象ファイルが存在する場所を示します。

この時点でコンパイルが行われるので、エラーが発生するおそれがあります。jarfileが指定されていて、エラーが発生しなかった場合には、指定された名前のMJFが作成されます。

注意:

カスタム・セキュリティ・プロバイダのJARファイルを作成する際には、一連のXMLバインディング・クラスと1つのスキーマも生成されます。そのスキーマに関連付けるネームスペースを選択できます。それにより、使用しているカスタム・クラスとOracleのカスタム・クラスとの競合を防ぐことができます。ネームスペースのデフォルトはvendorです。-targetNameSpace引数をWebLogicMBeanMakerまたは関連するWLMBeanMaker antタスクに渡すことで、このデフォルトを変更できます。

既存のMJFを更新する場合は、単純にMJFを削除して再生成します。WebLogic MBeanMakerにも -DIncludeSourceオプションがあり、それを指定すると、生成されるMJFにソース・ファイルを含めるかどうかを制御できます。ソース・ファイルには、生成されたソースとMDFそのものがあります。デフォルトはfalseです。このオプションは、-DMJFを使用しない場合には無視されます。

生成されたMJFは、自らのWebLogic Server環境にインストールすることも、顧客に配布してそれぞれのWebLogic Server環境にインストールしてもらうこともできます。

WebLogic Server環境にMBeanタイプをインストールする

MBeanタイプをWebLogic Server環境にインストールするには、MJFをWL_HOME\server\lib\mbeantypesディレクトリにコピーします。ここで、WL_HOMEはWebLogic Serverの最上位のインストール・ディレクトリです。このインストール・コマンドによって、カスタム・ロール・マッピング・プロバイダが「デプロイ」されます。つまり、カスタム・ロール・マッピング・プロバイダをWebLogic Server管理コンソールから管理できるようになります。

注意:

MBeanタイプをインストールするデフォルトのディレクトリは、WL_HOME\server\lib\mbeantypesです。初めて使用するバージョンが9.0の場合、セキュリティ・プロバイダは...\domaindir\lib\mbeantypesからもロードできます。ただし、サーバーを起動するときに-Dweblogic.alternateTypesDirectory=<dir>コマンドライン・フラグを使用すれば、WebLogic Serverが追加ディレクトリでMBeanタイプを検索します。<dir>は、ディレクトリ名のカンマ区切りのリストです。このフラグを使用する場合、WebLogic Serverは常に最初にWL_HOME\server\lib\mbeantypesからMBeanタイプをロードします。その後で、追加ディレクトリにあるすべての有効なアーカイブを検索して、ロードします。このとき拡張子は考慮されません。

たとえば、-Dweblogic.alternateTypesDirectory = dirX,dirYの場合、WebLogic ServerはまずWL_HOME\server\lib\mbeantypesからMBeanタイプをロードし、次にdirXおよびdirYにある有効なアーカイブをロードします。WebLogic Serverに追加ディレクトリでMBeanタイプを検索するよう指示する際に、Javaセキュリティ・マネージャを使用している場合は、weblogic.policyファイルを更新して、MBeanタイプ(その結果として、カスタム・セキュリティ・プロバイダ)に適した許可を付与することも必要になります。詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』のJavaセキュリティを使用したWebLogicリソースの保護に関する項を参照してください。

カスタム・ロール・マッピング・プロバイダを構成することによって(「管理コンソールによるカスタム・ロール・マッピング・プロバイダの構成」を参照)、MBeanタイプのインスタンスを作成して、GUI、他のJavaコード、またはAPIからそれらのMBeanインスタンスを使用することができます。たとえば、WebLogic Server管理コンソールを使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他のJavaオブジェクトを開発して、そのオブジェクトでMBeanをインスタンス化し、それらのMBeanから提供される情報に自動的に応答させることもできます。なお、これらのMBeanインスタンスをバックアップしておくことをお薦めします。

管理コンソールによるカスタム・ロール・マッピング・プロバイダの構成

カスタム・ロール・マッピング・プロバイダを構成するということは、ロール・マッピング・サービスを必要とするアプリケーションがアクセス可能なセキュリティ・レルムにカスタム・ロール・マッピング・プロバイダを追加するということです。

カスタム・セキュリティ・プロバイダの構成は管理タスクですが、カスタム・セキュリティ・プロバイダの開発者が行うこともできます。この節では、カスタム・ロール・マッピング・プロバイダの構成担当者向けの重要な情報を取り上げます。

- ロール・マッピング・プロバイダとデプロイメント記述子の管理

- セキュリティ・ロール・デプロイメントの有効化

注意:

WebLogic Server管理コンソールを使用してカスタム・ロール・マッピング・プロバイダを構成する手順は、『Oracle WebLogic Serverの保護』のWebLogicセキュリティ・プロバイダの構成に関する項で説明されています。

ロール・マッピング・プロバイダとデプロイメント記述子の管理

Enterprise JavaBeans (EJB)やWebアプリケーションなどのアプリケーションの中には、Java EEの関連デプロイメント情報とWebLogic Serverデプロイメント記述子を格納するものがあります。Webアプリケーションの場合、デプロイメント記述子ファイル(web.xmlとweblogic.xml)には、セキュリティ・ロールを含むJava EEセキュリティ・モデルの実装情報が格納されます。この情報は、WebLogic Server管理コンソールでロール・マッピング・プロバイダを初めて構成するときに格納するのが一般的です。

Java EEプラットフォームはデプロイメント記述子でWebアプリケーションおよびEJBのセキュリティを標準化しているので、WebLogic Serverではこの標準メカニズムがWebLogicセキュリティ・サービスに統合され、WebアプリケーションおよびEJBリソースを保護する方法を選択できるようになっています。デプロイメント記述子のみを使用することも管理コンソールのみを使用することもできます。また、状況によっては、この2つの方法を組み合わせることもできます。

選択した方法によって、セキュリティ・モデルを適用する必要もあります。WebLogicでは、個々のデプロイメントについて複数のセキュリティ・モデルがサポートされ、使用する方法を組み込むレルム全体の構成についてはセキュリティ・モデルがサポートされます。

詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のEJBおよびWebアプリケーション・リソースの保護のオプションに関する項を参照してください。

デプロイメント記述子を使用するように構成すると、WebLogic Serverによりweb.xmlおよびweblogic.xmlデプロイメント記述子ファイルからセキュリティ・ロール情報が読み込まれます(web.xmlファイルとweblogic.xmlファイルの例については、例9-6と例9-7を参照)。この情報は、ロール・マッピング・プロバイダのセキュリティ・プロバイダ・データベースにコピーされます。

例9-6 web.xmlファイルのサンプル

<web-app>
<welcome-file-list>
<welcome-file>welcome.jsp</welcome-file>
</welcome-file-list>
<security-constraint>
<web-resource-collection>
<web-resource-name>Success</web-resource-name>
<url-pattern>/welcome.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>developers</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>default</realm-name>
</login-config>
<security-role>
<role-name>developers</role-name>
</security-role>
</web-app>

例9-7 weblogic.xmlファイルのサンプル

<weblogic-web-app>
<security-role-assignment>
<role-name>developers</role-name>
<principal-name>myGroup</principal-name>
</security-role-assignment>
</weblogic-web-app>

セキュリティ・ロール・デプロイメントの有効化

カスタム・ロール・マッピング・プロバイダの開発の一環としてDeployableRoleProviderV2 SSPIを実装し、デプロイ可能なセキュリティ・ロールをサポートする場合、カスタム・ロール・マッピング・プロバイダの構成担当者(つまり、開発者または管理者)は、WebLogic Server管理コンソールで「ロール・デプロイメントを有効化」ボックスがチェックされていることを確認する必要があります。チェックがはずれていると、ロール・マッピング・プロバイダに対するデプロイメントは「オフ」と見なされます。このため、複数のロール・マッピング・プロバイダが構成されている場合、「ロール・デプロイメントを有効化」ボックスを使用して、セキュリティ・ロールのデプロイメントに使用するロール・マッピング・プロバイダを指定できます。

セキュリティ・ロールを管理するためのメカニズムの提供

WebLogic Server管理コンソールを使用してカスタム・ロール・マッピング・プロバイダを構成すると、必要なロール・マッピング・サービスにアプリケーションからアクセスできるようにすることはできますが、このセキュリティ・プロバイダに関連付けられたセキュリティ・ロールを管理する方法を管理者にも提供する必要があります。たとえばWebLogicロール・マッピング・プロバイダには、ロール・エディタ・ページが管理者向けに用意されており、様々なWebLogicリソースのセキュリティ・ロールを追加、変更、または削除することができます。

カスタム・ロール・マッピング・プロバイダを開発すると、管理者はロール・エディタ・ページも右クリック・メニューも利用できません。したがって、セキュリティ・ロールを管理するための独自のメカニズムを提供する必要があります。このメカニズムでは、カスタム・ロール・マッピング・プロバイダのデータベースのセキュリティ・ロール・データ(つまり式)を読み書きできなければなりません。

それには、以下の2通りの方法があります。

- オプション1: セキュリティ・ロール管理用のスタンドアロン・ツールの開発

- オプション2 : 既存のセキュリティ・ロール管理ツールを管理コンソールに統合する

オプション1 :セキュリティ・ロール管理用のスタンドアロン・ツールの開発

WebLogic Server管理コンソールとまったく別のツールを開発する場合には、この方法を選択します。

この方法では、カスタム・ロール・マッピング・プロバイダ向けにコンソール拡張を作成する必要も、管理MBeanを開発する必要もありません。ただし、ツールでは以下のことを行う必要があります。

1. WebLogicリソースのIDを特定します。IDがコンソール拡張によって自動的に提供されないためです。詳細については、「WebLogicリソース識別子」を参照してください。

2. セキュリティ・ロールを構成する式を表す方法を決定します。この表現は完全に任意であり、文字列である必要はありません。

3. カスタム・ロール・マッピング・プロバイダのデータベースの式を読み書きします。

オプション2 : 管理コンソールに既存のセキュリティ・ロール管理ツールの統合

WebLogic Server管理コンソールとは別のツールを持っており、それを管理コンソールから起動する場合には、この方法を選択します。

この方法の場合、ツールでは以下のことを行う必要があります。

1. WebLogicリソースのIDを特定します。IDがコンソール拡張によって自動的に提供されないためです。詳細については、「WebLogicリソース識別子」を参照してください。

2. セキュリティ・ロールを構成する式を表す方法を決定します。この表現は完全に任意であり、文字列である必要はありません。

3. カスタム・ロール・マッピング・プロバイダのデータベースの式を読み書きします。

4. 『Oracle WebLogic Server管理コンソールの拡張』で説明されているように、基本的なコンソール拡張手法を使用して管理コンソールにリンクします。

10 監査プロバイダ

この章では、監査プロバイダの概念と機能、およびカスタム監査プロバイダの開発手順について説明します。

監査とは、一連のリクエストの操作や結果に関する情報を、否認防止を目的として収集、格納、および配布するプロセスのことです。WebLogic Serverでは、監査はコンピュータのアクティビティの電子的な記録を提供するものです。

以下の節では、監査プロバイダの概念と機能、およびカスタム監査プロバイダの開発手順について説明します。

- 監査の概念

- 監査プロセス

- weblogic.management.security.audit.ContextHandlerImplの拡張

- カスタム監査プロバイダの開発方法

- セキュリティ・フレームワークの監査イベント

監査の概念

監査プロバイダを開発する前に、以下の概念を理解しておく必要があります。

- 監査チャネル

- カスタム・セキュリティ・プロバイダからのイベントの監査

監査チャネル

監査チャネルは監査プロバイダのコンポーネントで、セキュリティ・イベントを監査すべきかどうかを決定し、サービス品質(QoS)ポリシーに基づいて監査情報を実際に記録します。

注意:

監査チャネルの詳細は、「AuditChannel SSPIの実装」を参照してください。

カスタム・セキュリティ・プロバイダからのイベントの監査

各タイプのセキュリティ・プロバイダは、セキュリティ関連イベントの実行前または実行後に、それらのイベントに関する情報を記録するよう構成済みの監査プロバイダにリクエストできます。たとえば、あるユーザーが(アクセス権を持たない)預金口座アプリケーションのwithdrawメソッドにアクセスしようとした場合、認可プロバイダではこの操作を記録するようにリクエストできます。セキュリティ関連イベントは、監査プロバイダの構成で指定されている重大度レベルと一致するか、それを超えた場合にのみ記録されます。

カスタム・セキュリティ・プロバイダから監査イベントをポストする方法については、第12章「カスタム・セキュリティ・プロバイダからのイベントの監査」を参照してください。

監査プロセス

図10-1に、監査プロバイダがWebLogicセキュリティ・フレームワークや他のタイプのセキュリティ・プロバイダ(ここでは認証プロバイダ)と対話して、選択されたイベントを監査する仕組みを示します。図の後には、詳しい説明が続きます。

図10-1 監査プロバイダ、WebLogicセキュリティ・フレームワーク、および他のセキュリティ・プロバイダ

「図10-1 監査プロバイダ、WebLogicセキュリティ・フレームワーク、および他のセキュリティ・プロバイダ」の説明

監査プロバイダは、次のようにWebLogicセキュリティ・フレームワークと他のタイプのセキュリティ・プロバイダと対話します。

注意:

図10-1と以下の説明文では、「他のタイプのセキュリティ・プロバイダ」はWebLogic認証プロバイダとカスタム認証プロバイダです。ただし、これらは第12章「カスタム・セキュリティ・プロバイダからのイベントの監査」の説明のように、開発済みのどのようなタイプのセキュリティ・プロバイダでもかまいません。

1. リソース・コンテナは、ログイン・リクエストの一部としてユーザーの認証情報(ユーザー名とパスワードの組合せなど)をWebLogicセキュリティ・フレームワークに渡します。

2. WebLogicセキュリティ・フレームワークは、ログイン・リクエストに関連付けられている情報を構成済みの認証プロバイダに渡します。

3. 認証サーバーが認証サービスを提供するほかに監査イベントをポストする場合、各認証プロバイダは以下のことを行います。

1. AuditEventオブジェクトをインスタンス化します。AuditEventオブジェクトには、少なくとも監査対象のイベント・タイプに関する情報と監査の重大度レベルが含まれます。

注意:

AuditEventクラスを作成するには、カスタム認証プロバイダがすでに実装している必要がある他のセキュリティ・サービス・プロバイダ・インタフェース(SSPI)に加えて、認証プロバイダのランタイム・クラスにAuditEvent SSPIまたはAuditEventコンビニエンス・インタフェースを実装します。監査イベントとAuditEvent SSPI/コンビニエンス・インタフェースについては、「監査イベントの作成」を参照してください。

2. 監査サービスに対して信頼性のある呼出しを行って、AuditEventオブジェクトを渡します。

注意:

ここで信頼性のある呼出しとするのは、監査サービスがすでにセキュリティ・プロバイダのinitializeメソッドに「Provider」SSPI実装の一部として渡されているからです。詳細については、「「Provider」SSPIの目的について」を参照してください。

4. 監査サービスは、AuditEventオブジェクトを構成済みの監査プロバイダのランタイム・クラス(AuditChannel SSPI実装)に渡し、監査イベントの記録を有効にします。

注意:

認証プロバイダのAuditEventコンビニエンス・インタフェースの実装によっては、監査リクエストがイベントに対して1回発生するだけでなく、イベントの前後にも発生する場合があります。

5. 監査プロバイダのランタイム・クラスは、AuditEventオブジェクトから取得したイベント・タイプ、監査重大度、およびその他の情報(監査コンテキストなど)を利用して監査レコードの内容を管理します。一般に、構成済みの監査プロバイダの1つだけがすべての監査条件を満たします。

注意:

監査重大度レベルと監査コンテキストの詳細は、それぞれ「監査重大度」と「監査コンテキスト」を参照してください。

6. 認証プロバイダによってAuditEventオブジェクト内に指定された監査条件が満たされると、該当する監査プロバイダのランタイム・クラス(AuditChannel SSPI実装)はそれらの実装で指定された方法で監査レコードを書き出します。

注意:

監査条件が満たされた際の監査記録の書込み先は、AuditChannel SSPIの実装に応じて、ファイル、データベース、または他の永続ストレージ・メディアになります。

ContextHandler MBeanの実装

ContextHandlerMBean (weblogic.management.security.audit.ContextHandler)は、ContextHandlerがサポートする一連の属性を提供します。このインタフェースを使用すると、コンテキスト・ハンドラ・エントリを標準的な方法でサポートする監査プロバイダを管理できます。

監査プロバイダMBeanは、ContextHandlerMBeanのMBeanを必要に応じて実装できます。監査プロバイダは、このMBeanを使用して、サポートされているアクティブなContextHandlerエントリを判別します。

WebLogic Server管理コンソールは、監査プロバイダがこのMBeanを実装したことを検出して、これらの属性を使用するためのタブを自動的に提供します。

注意:

ContextHandlerMBeanに関連付けられているContextHandlerエントリは、監査プロバイダに渡されるAuditEventの内容に関連付けられることも、影響を与えることもありません。プロバイダが受信したAuditEventには、ContextElementが指定されたContextHandlerが含まれる場合も含まれない場合もあります。ContextHandlerが含まれている場合、監査プロバイダは、ContextHandlerMBean管理インタフェースを実装したかどうかに関係なくAuditEventからContextHandlerを取得できます。特に、AuditContext getContextメソッドは、ContextHandlerMBeanによって実装されたコンテキスト・ハンドラに依存しないweblogic.security.service.ContextHandlerインタフェースを返します。

AuditContext getContextメソッドを補完する形でContextHandlerMBeanコンテキスト・ハンドラを実装するように選択することもできます(サンプルのSimpleSampleAuditProviderImpl.javaでは、この方法を取っています)。ただし、これは必須ではありません。

ContextHandlerMBeanのメソッド

ContextHandlerMBeanインタフェースは、以下のメソッドを実装しています。

- getActiveContextHandlerEntries

public String[] getActiveContextHandlerEntries()

現在、監査プロバイダで処理するように構成されているContextHandlerエントリを返します。

- getSupportedContextHandlerEntries

public String[] getSupportedContextHandlerEntries()

監査プロバイダによってサポートされているすべてのContextHandlerエントリのリストを返します。

- setActiveContextHandlerEntries

public void setActiveContextHandlerEntries(String[] types) throws InvalidAttributeValueException

監査プロバイダで処理するContextHandlerエントリを設定します。指定するエントリは、監査プロバイダのSupportedContextHandlerEntries属性に列挙されているものである必要があります。

例: ContextHandlerMBeanの実装

例10-5は、サンプル監査プロバイダのランタイム・クラスであるSimpleSampleAuditProviderImpl.javaクラスを示しています。このサンプル監査プロバイダは、ContextHandlerMBeanを実装するように拡張されています。

MBean定義ファイル(MDF)は、WebLogic MBeanMakerユーティリティで、MBeanタイプを構成するJavaファイルを生成するために使用されるXMLファイルです。すべてのMDFでは、作成済のセキュリティ・プロバイダのタイプに固有の必須SSPI MBeanを拡張する必要があり、さらにオプショナルSSPI MBeanを実装することができます。

例10-1は、任意ContexthandlerMBeanを実装するサンプル監査プロバイダに関連するMDF内の主要なセクションを示しています。

例10-1 例: SimpleSampleAuditor.xml

<MBeanType
Name          = "SimpleSampleAuditor"
DisplayName   = "SimpleSampleAuditor"
Package       = "examples.security.providers.audit.simple"
Extends       = "weblogic.management.security.audit.Auditor"
Implements    = "weblogic.management.security.audit.ContextHandler"
PersistPolicy = "OnUpdate"
>
...
<MBeanAttribute
Name          = "SupportedContextHandlerEntries"
Type          = "java.lang.String[]"
Writeable     = "false"
Default       = "new String[] {
&quot;com.bea.contextelement.servlet.HttpServletRequest&quot; }"
Description   = "List of all ContextHandler entries
supported by the auditor."
/>

weblogic.management.security.audit.ContextHandlerImplの拡張

ContextHandlerMBeanにはsetActiveContextHandlerEntriesという属性があり、現在、監査プロバイダで処理するように構成されているContextHandlerエントリをsetActiveContextHandlerEntriesメソッドでこの属性に指定します。指定するエントリは、監査プロバイダのSupportedContextHandlerEntries属性に列挙されているものである必要があります。ただし実際には、MBeanではこの要件が強制されません。この属性にSupportedContextHandlerEntries属性にある値のみを設定できるように検証する処理を、別に行う必要があります。

また、weblogic.management.security.audit.ContextHandlerImplを拡張するMBeanカスタマイザのファイルを(たとえば、MyAuditorImpl.javaという名前で)作成する必要があります。weblogic.management.security.audit.ContextHandlerImplを拡張すると、プロバイダからActiveContextHandlerEntries属性の検証プロバイダへのアクセスが可能になります。この検証プロバイダによって、このエントリに確実にSupportedContextHandlerEntriesにある値のみが含まれるようになります。

ContextHandlerImplの拡張例はSimpleSampleAuditorImplで確認できます。例10-2に示します。

例10-2 SimpleSampleAuditorImpl

package examples.security.providers.audit.simple;
import javax.management.MBeanException;
import javax.management.modelmbean.RequiredModelMBean;
import weblogic.management.security.audit.ContextHandlerImpl;

/**
* The simple sample auditor's mbean implementation.
* <p>
* It is needed to inherit the ContextHandlerMBean's ActiveContextHandlerEntries
* attribute validator that ensures that the ActiveContextHandlerEntries
* attribute only contains values from the SupportedContextHandlerEntries
* attribute.
*
* @author Copyright © 1996, 2008, Oracle and/or its affiliates.
* All rights reserved.
*/
public class SimpleSampleAuditorImpl extends ContextHandlerImpl
// Note: extend ContextHandlerImpl instead of AuditorImpl to inherit
// the ActiveContextHandlerEntries attribute validator.
{
/**
* Standard mbean impl constructor.
*
* @throws MBeanException
*/
public SimpleSampleAuditorImpl(RequiredModelMBean base) throws MBeanException
{
super(base);
}
}

SimpleSampleAuditorImplのようなコードを実装したら、ActiveContextHandlerEntriesを取得するため、実行時の監査プロバイダにコードを追加します。この作業の一例を例10-3に示します。

例10-3 アクティブなコンテキスト・ハンドラ・エントリの取得

String [] activeHandlerEntries = myMBean.getActiveContextHandlerEntries();
if (activeHandlerEntries != null) {
for (int i=0; i<activeHandlerEntries.length; i++) {
if ((activeHandlerEntries[i] != null) &&
(activeHandlerEntries[i].equalsIgnoreCase(HTTP_REQUEST_ELEMENT))) {
handlerEnabled = true;
break;
}
}
}

カスタム監査プロバイダを開発する必要があるか

WebLogic Serverのデフォルト(つまりアクティブな)セキュリティ・レルムにはWebLogic監査プロバイダが含まれています。WebLogic監査プロバイダは、WebLogicセキュリティ・フレームワークで内部的に決定された、複数のセキュリティ・リクエストの情報を記録します。また、WebLogic監査プロバイダはこれらのセキュリティ・リクエストに関連付けられているイベント・データとリクエストの結果も記録します。

WebLogic監査プロバイダは、そのwriteEventメソッドで、構成済みの監査重大度レベルとそのメソッドに渡されたAuditEventオブジェクトに格納されている監査重大度に基づいて監査上の決定を行います。(AuditEventオブジェクトの詳細は、「監査イベントの作成」を参照)。

注意:

WebLogic監査プロバイダに対して構成されている監査重大度レベルは、WebLogic Server管理コンソールで変更できます。詳細は、『Oracle WebLogic Serverの保護』のWebLogic監査プロバイダの構成に関する項を参照してください。

一致するものがある場合、WebLogic監査プロバイダはWL_HOME\yourdomain\ yourserver\logsディレクトリにあるDefaultAuditRecorder.logファイルに監査情報を書き込みます。例10-4は、DefaultAuditRecorder.logファイルからの抜粋です。

例10-4 DefaultAuditRecorder.logファイル:出力例

When Authentication suceeds. [SUCCESS]
#### Audit Record Begin <Feb 23, 2005 11:42:17 AM>  <Severity=SUCCESS>
<<<Event Type = Authentication Audit Event><TestUser><AUTHENTICATE>>> Audit
Record End ####
When Authentication fails. [FAILURE]
#### Audit Record Begin <Feb 23, 2005 11:42:01 AM>  <Severity=FAILURE>
<<<Event Type = Authentication Audit Event><TestUser><AUTHENTICATE>>> Audit
Record End ####When Operations are invoked.[SUCCESS]
When a user account is unlocked. [SUCCESS]
#### Audit Record Begin <Feb 23, 2005 11:42:17 AM>  <Severity=SUCCESS>
<<<Event Type = Authentication Audit Event><TestUser><USERUNLOCKED>>> Audit
Record End ####
When an Authorization request succeeds. [SUCCESS]
#### Audit Record Begin <Feb 23, 2005 11:42:17 AM>  <Severity=SUCCESS>
<<<Event Type = Authorization Audit Event ><Subject: 1
Principal = class weblogic.security.principal.WLSUserImpl("TestUser")
><ONCE><<jndi>><type=<jndi>, application=, path={weblogic}, action=lookup>>>
Audit Record End ####

具体的にいうと例10-4には、ロール・マネージャ(セキュリティ・ロールを専門に扱うWebLogicセキュリティ・フレームワーク・コンポーネント)による監査イベントの記録が示されています。この記録から、権限のある管理者が証明書サーブレット内の保護されたメソッドにアクセスしたことがわかります。

次のJava起動オプションを使用すると、コマンドラインでDefaultAuditRecorder.log用に新しいディレクトリを指定できます。

-Dweblogic.security.audit.auditLogDir=c:\foo

新しいファイルの場所は、c:\foo\yourserver\DefaultAuditRecorder.logです。

監査情報をWebLogicセキュリティ・フレームワークで指定された以外のファイル、またはDefaultAuditRecorder.log以外の出力リポジトリ(異なる名前/場所のシンプル・ファイルまたは既存のデータベース)にも書き込む場合、カスタム監査プロバイダを開発する必要があります。

カスタム監査プロバイダの開発方法

WebLogic監査プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム監査プロバイダを開発することができます。

1. 適切なSSPIによるランタイム・クラスの作成

2. WebLogic MBeanMakerを使用してMBeanタイプを生成する

3. 管理コンソールによるカスタム監査プロバイダの構成

適切なSSPIによるランタイム・クラスの作成

ランタイム・クラスを作成する前に、以下の作業が必要です。

- 「Provider」SSPIの目的について

- SSPI階層を理解し、ランタイム・クラスを1つ作成するか2つ作成するかを決定する

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム監査プロバイダのランタイム・クラスを作成します。

- AuditProvider SSPIの実装

- AuditChannel SSPIの実装

カスタム監査プロバイダのランタイム・クラスの作成例については、「例:サンプル監査プロバイダのランタイム・クラスの作成」を参照してください。

AuditProvider SSPIの実装

AuditProvider SSPIを実装するには、「「Provider」SSPIの目的について」で説明されているメソッドおよび次のメソッドの実装を提供する必要があります。

- getAuditChannel

public AuditChannel getAuditChannel();

getAuditChannelメソッドは、AuditChannel SSPIの実装を取得します。MyAuditProviderImpl.javaという1つのランタイム・クラスの場合、getAuditChannelメソッドの実装は次のようになります。

return this;

ランタイム・クラスが2つの場合、getAuditChannelメソッドの実装は次のようになります。

return new MyAuditChannelImpl;

これは、AuditProvider SSPIを実装するランタイム・クラスが、AuditChannel SSPIを実装するクラスを取得する場合のファクトリとして使用されるためです。

AuditProvider SSPIとgetAuditChannelメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

AuditChannel SSPIの実装

AuditChannel SSPIを実装する際には、以下のメソッドの実装を提供する必要があります。

- writeEvent

public void writeEvent(AuditEvent event)

writeEventメソッドは、渡されたAuditEventオブジェクト内に指定されている情報に基づいて監査記録を書き込みます。AuditEventオブジェクトの詳細は、「監査イベントの作成」を参照してください。

AuditChannel SSPIとwriteEventメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

例:サンプル監査プロバイダのランタイム・クラスの作成

例10-5は、サンプル監査プロバイダのランタイム・クラスであるSimpleSampleAuditProviderImpl.javaクラスを示しています。このランタイム・クラスには次の実装が含まれています。

- initialize、getDescription、およびshutdownというSecurityProviderインタフェースから継承した3つのメソッド(「「Provider」SSPIの目的について」を参照)。

- getAuditChannelというAuditProvider SSPIから継承したメソッド(「AuditProvider SSPIの実装」を参照)。

- writeEventというAuditChannel SSPIのメソッド(「AuditChannel SSPIの実装」を参照)。

注意:

例10-5の太字のコードは、クラス宣言とメソッド・シグネチャを示しています。

例10-5 SimpleSampleAuditProviderImpl.java

package examples.security.providers.audit.simple;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.PrintStream;
import javax.servlet.http.HttpServletRequest;
import weblogic.management.security.ProviderMBean;
import weblogic.security.service.ContextHandler;
import weblogic.security.spi.AuditChannel;
import weblogic.security.spi.AuditContext;
import weblogic.security.spi.AuditEvent;
import weblogic.security.spi.AuditProvider;
import weblogic.security.spi.SecurityServices;

public final class SimpleSampleAuditProviderImpl implements AuditProvider, AuditChannel
{
private String      description; // a description of this provider
private PrintStream log;         // the log file that events are written to
private boolean     handlerEnabled = false;
private final static String HTTP_REQUEST_ELEMENT =
"com.bea.contextelement.servlet.HttpServletRequest";
public void initialize(ProviderMBean mbean, SecurityServices services)
{
System.out.println("SimpleSampleAuditProviderImpl.initialize");
SimpleSampleAuditorMBean myMBean = (SimpleSampleAuditorMBean)mbean;
description = myMBean.getDescription() + "\n" + myMBean.getVersion();
String [] activeHandlerEntries = myMBean.getActiveContextHandlerEntries();
if (activeHandlerEntries != null) {
for (int i=0; i<activeHandlerEntries.length; i++) {
if ((activeHandlerEntries[i] != null) &&
(activeHandlerEntries[i].equalsIgnoreCase(HTTP_REQUEST_ELEMENT))) {
handlerEnabled = true;
break;
}
}
}
File file = new File(myMBean.getLogFileName());
System.out.println("\tlogging to " + file.getAbsolutePath());
try {
log = new PrintStream(new FileOutputStream(file), true);
} catch (IOException e) {
throw new RuntimeException(e.toString());
}
}

public String getDescription()
{
return description;
}
public void shutdown()
{
System.out.println("SimpleSampleAuditProviderImpl.shutdown");
log.close();
}
public AuditChannel getAuditChannel()
{
return this;
}
public void writeEvent(AuditEvent event)
{
log.println(event);

if ((!handlerEnabled) || (!(event instanceof AuditContext)))
return;

AuditContext auditContext = (AuditContext)event;
ContextHandler handler = auditContext.getContext();

if ((handler == null) || (handler.size() == 0))
return;

Object requestValue = handler.getValue("com.bea.contextelement.servlet.HttpServletRequest");
if ((requestValue == null) || (!(requestValue instanceof HttpServletRequest)))
return;
HttpServletRequest request = (HttpServletRequest) requestValue;
log.println("    " + HTTP_REQUEST_ELEMENT + " method: " + request.getMethod());
log.println("    " + HTTP_REQUEST_ELEMENT + " URL: " + request.getRequestURL());
log.println("    " + HTTP_REQUEST_ELEMENT + " URI: " + request.getRequestURI());
return;
}
}

WebLogic MBeanMakerを使用してMBeanタイプを生成する

カスタム・セキュリティ・プロバイダのMBeanタイプを生成する前に、以下の作業が必要です。

- MBeanタイプが必要な理由について

- 拡張および実装するSSPI MBeanの決定

- MBean定義ファイル(MDF)の基本的な要素について

- SSPI MBeanの階層と管理コンソールに対する影響について

- WebLogic MBeanMakerによって提供されるものについて

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム監査プロバイダのMBeanタイプを作成します。

1. MBean定義ファイル(MDF)の作成

2. WebLogic MBeanMakerを使用してMBeanタイプを生成する

3. WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

4. WebLogic Server環境にMBeanタイプをインストールする

注意:

複数のセキュリティ・プロバイダのサンプルで、これらの手順の実行方法を示します。

この節で説明する手順はすべて、Windows環境での作業を想定しています。

MBean定義ファイル(MDF)の作成

MBean定義ファイル(MDF)を作成するには、次の手順に従います。

1. サンプル監査プロバイダのMDFをテキスト・ファイルにコピーします。

注意:

サンプル監査プロバイダのMDFは、SampleAuditor.xmlという名前です。

2. MDFで<MBeanType>要素と<MBeanAttribute>要素の内容をカスタム監査プロバイダに合わせて修正します。

3. カスタム属性および操作(つまり、<MBeanAttribute>および<MBeanOperation>要素)をMDFに追加します。

4. ファイルを保存します。

注意:

MDF要素の構文についての詳細なリファレンスは、付録A「MBean定義ファイル(MDF)要素の構文」に収められています。

WebLogic MBeanMakerを使用してMBeanタイプを生成する

MDFを作成したら、WebLogic MBeanMakerを使用してそれを実行できます。WebLogic MBeanMakerは現在のところコマンドライン・ユーティリティで、入力としてMDFを受け取り、MBeanインタフェース、MBean実装、関連するMBean情報ファイルなどの中間Javaファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム・セキュリティ・プロバイダのMBeanタイプになります。

MBeanタイプの生成手順は、カスタム監査プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。

- カスタム操作を追加しない場合

- カスタム操作を追加する場合

カスタム操作を追加しない場合

カスタム監査プロバイダのMDFにカスタム操作を含めない場合、次の手順に従います。

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり監査プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

3. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

カスタム操作を追加する場合

カスタム監査プロバイダのMDFにカスタム操作を含める場合、質問に答えながら手順を進めてください。

MBeanタイプを作成するのは初めてですか。その場合は、次の手順に従ってください:

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり監査プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

3. MDFのすべてのカスタム操作に対して、メソッド・スタブを使用してメソッドを実装します。

4. ファイルを保存します。

5. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

既存のMBeanタイプの更新ですか。その場合は、次の手順に従ってください:

1. WebLogic MBeanMakerによって現在のメソッドの実装が上書きされないように、既存のMBean実装ファイルを一時ディレクトリにコピーします。

2. 新しいDOSシェルを作成します。

3. 次のコマンドを入力します。
java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

WebLogic MBeanMakerではMDFを一度に1つ処理します。したがって、MDF (つまり監査プロバイダ)が複数ある場合には、このプロセスを繰り返す必要があります。

4. MDFを変更して元のMDFにはないカスタム操作を含めた場合、メソッド・スタブを使用してメソッドを実装します。

5. 完成した、つまりすべてのメソッドを実装したMBean実装ファイルを保存します。

6. このMBean実装ファイルを、WebLogic MBeanMakerがMBeanタイプの実装ファイルを配置したディレクトリにコピーします。このディレクトリは、手順3でfilesdirとして指定したものです。(ステップ3の結果としてWebLogic MBeanMakerで生成されたMBean実装ファイルがオーバーライドされます)。

7. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

生成されるMBeanインタフェース・ファイルについて

MBeanインタフェース・ファイルとは、ランタイム・クラスまたはMBean実装が構成データを取得するために使用するMBeanのクライアント側APIです。「「Provider」SSPIの目的について」で説明されているように、これはinitializeメソッドで使用するのが一般的です。

WebLogic MBeanMakerでは、作成済のMDFからMBeanタイプを生成するので、生成されるMBeanインタフェース・ファイルの名前は、そのMDF名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMakerでSampleAuditor MDFを実行すると、SampleAuditorMBean.javaというMBeanインタフェース・ファイルが生成されます。

WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

WebLogic MBeanMakerでMDFを実行して中間ファイルを作成し、MBean実装ファイルを編集して適切なメソッドの実装を提供したら、カスタム監査プロバイダのMBeanファイルとランタイム・クラスをMBean JARファイル(MJF)にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMakerによって自動化されます。

カスタム監査プロバイダのMJFを作成するには、次の手順に従います。

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMJF=jarfile -Dfiles=filesdir weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMJFフラグはWebLogic MBeanMakerが新しいMBeanタイプを格納するJARファイルをビルドする必要があることを示し、jarfileはMJFの名前、<filesdir>はWebLogic MBeanMakerでMJFにJAR化する対象ファイルが存在する場所です。

この時点でコンパイルが行われるので、エラーが発生するおそれがあります。jarfileが指定されていて、エラーが発生しなかった場合には、指定された名前のMJFが作成されます。

注意:

カスタム・セキュリティ・プロバイダのJARファイルを作成する際には、一連のXMLバインディング・クラスと1つのスキーマも生成されます。そのスキーマに関連付けるネームスペースを選択できます。それにより、使用しているカスタム・クラスとOracleのカスタム・クラスとの競合を防ぐことができます。ネームスペースのデフォルトはvendorです。-targetNameSpace引数をWebLogicMBeanMakerまたは関連するWLMBeanMaker antタスクに渡すことで、このデフォルトを変更できます。

既存のMJFを更新する場合は、単純にMJFを削除して再生成します。WebLogic MBeanMakerにも -DIncludeSourceオプションがあり、それを指定すると、生成されるMJFにソース・ファイルを含めるかどうかを制御できます。ソース・ファイルには、生成されたソースとMDFそのものがあります。デフォルトはfalseです。このオプションは、-DMJFを使用しない場合には無視されます。

生成されたMJFは、自らのWebLogic Server環境にインストールすることも、顧客に配布してそれぞれのWebLogic Server環境にインストールしてもらうこともできます。

WebLogic Server環境にMBeanタイプをインストールする

MBeanタイプをWebLogic Server環境にインストールするには、MJFをWL_HOME\server\lib\mbeantypesディレクトリにコピーします。ここで、WL_HOMEはWebLogic Serverの最上位のインストール・ディレクトリです。このインストール・コマンドによって、カスタム監査プロバイダが「デプロイ」されます。つまり、カスタム監査プロバイダをWebLogic Server管理コンソールから管理できるようになります。

注意:

MBeanタイプをインストールするデフォルトのディレクトリは、WL_HOME\server\lib\mbeantypesです。初めて使用するバージョンが9.0の場合、セキュリティ・プロバイダは...\domaindir\lib\mbeantypesからもロードできます。ただし、サーバーを起動するときに-Dweblogic.alternateTypesDirectory=<dir>コマンドライン・フラグを使用すれば、WebLogic Serverが追加ディレクトリでMBeanタイプを検索します。<dir>は、ディレクトリ名のカンマ区切りのリストです。このフラグを使用する場合、WebLogic Serverは常に最初にWL_HOME\server\lib\mbeantypesからMBeanタイプをロードします。その後で、追加ディレクトリにあるすべての有効なアーカイブを検索して、ロードします。このとき拡張子は考慮されません。

たとえば、-Dweblogic.alternateTypesDirectory = dirX,dirYの場合、WebLogic ServerはまずWL_HOME\server\lib\mbeantypesからMBeanタイプをロードし、次にdirXおよびdirYにある有効なアーカイブをロードします。WebLogic Serverに追加ディレクトリでMBeanタイプを検索するよう指示する際に、Javaセキュリティ・マネージャを使用している場合は、weblogic.policyファイルを更新して、MBeanタイプ(その結果として、カスタム・セキュリティ・プロバイダ)に適した許可を付与することも必要になります。詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』のJavaセキュリティを使用したWebLogicリソースの保護に関する項を参照してください。

カスタム監査プロバイダを構成することによって(「Configure the Custom Auditing Provider Using the 管理コンソール」を参照) MBeanタイプのインスタンスを作成して、GUI、他のJavaコード、またはAPIからそれらのMBeanインスタンスを使用することができます。たとえば、WebLogic Server管理コンソールを使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他のJavaオブジェクトを開発して、そのオブジェクトでMBeanをインスタンス化し、それらのMBeanから提供される情報に自動的に応答させることもできます。なお、これらのMBeanインスタンスをバックアップしておくことをお薦めします。

管理コンソールによるカスタム監査プロバイダの構成

カスタム監査プロバイダを構成するということは、監査サービスを必要とするセキュリティ・プロバイダがアクセス可能なセキュリティ・レルムにカスタム監査プロバイダを追加するということです。

カスタム・セキュリティ・プロバイダの構成は管理タスクですが、カスタム・セキュリティ・プロバイダの開発者が行うこともできます。この節では、カスタム監査プロバイダの構成担当者向けの重要な情報を取り上げます。

- 監査重大度の構成

注意:

WebLogic Server管理コンソールを使用してカスタム監査プロバイダを構成する手順は、『Oracle WebLogic Serverの保護』のWebLogicセキュリティ・プロバイダの構成に関する項で説明されています。

監査重大度の構成

構成手順では、監査プロバイダの監査重大度を下記の重大度レベルのいずれかに設定する必要があります。

- INFORMATION

- WARNING

- ERROR

- SUCCESS

- FAILURE

セキュリティ・フレームワークの監査イベント

この節では、WebLogic Serverのセキュリティ・フレームワークによってポストされる監査イベントについて説明します。カスタム監査プロバイダを記述する場合、こうした監査イベントを処理できるようにしておく必要があります。この節では、以下の内容について説明します。

- 付加的な監査情報の渡し

- 監査イベント・インタフェースと監査イベント

付加的な監査情報の渡し

WebLogicセキュリティ・プロバイダは適切なAuditEventインタフェースを実装し、イベントを監査プロバイダにポストします。AuditContextインタフェースも実装する監査イベントでは、ContextHandlerを介してより多くの情報を提供できます。

表10-1に、AuditEvent SSPIを拡張するweblogic.security.spiサブインタフェースと、どのサブインタフェースがAuditContextインタフェースを実装しているかを示します。

表10-1 監査イベント

監査イベント名

インタフェース・クラス

監査イベント

監査コンテキスト

アプリケーション・バージョン・イベント

weblogic.security.spi.AuditApplicationVersionEvent

はい

いいえ

認証監査イベント

weblogic.security.spi.AuditAtnEvent

はい

いいえ

認証監査イベントV2

weblogic.security.spi.AuditAtnEventV2

はい

はい

認可監査イベント

weblogic.security.spi.AuditAtzEvent

はい

はい

証明書パス・ビルダー監査イベント

weblogic.security.spi.AuditCertPathBuilderEvent

はい

はい

証明書パス検証監査イベント

weblogic.security.spi.AuditCertPathValidatorEvent

はい

はい

構成監査イベント

weblogic.security.spi.AuditConfigurationEvent

はい

はい

資格証明マッピング監査イベント

weblogic.security.spi.AuditCredentialMappingEvent

はい

はい

ライフ・サイクル・イベント

weblogic.security.spi.AuditLifecycleEvent

はい

いいえ

管理監査イベント

weblogic.security.spi.AuditMgmtEvent

はい

いいえ

ポリシー監査イベント

weblogic.security.spi.AuditPolicyEvent

はい

いいえ

ポリシー・コンシューマ監査イベント

weblogic.security.service.internal.PolicyConsumerAuditEvent

AuditPolicyEvent

いいえ

プロバイダ監査記録

com.bea.security.spi.ProviderAuditRecord

はい

はい

ロール・コンシューマ監査イベント

weblogic.security.service.internal.RoleConsumerAuditEvent

AuditRoleEvent

はい

ロール・デプロイメント監査イベント

weblogic.security.spi.AuditRoleDeploymentEvent

はい

いいえ

ロール・マッピング監査イベント

weblogic.security.spi.AuditRoleEvent

はい

はい

監査イベント・インタフェースと監査イベント

WebLogicセキュリティでは、weblogic.security.spiパッケージの最上位に1つの基本インタフェース(AuditEvent)が定義され、ここから派生したインタフェース群が様々なタイプの監査イベントを表します。

以降の節では、セキュリティ・フレームワークおよびセキュリティ・プロバイダが以下の監査イベントをいつポストするかについて説明します。

- AuditApplicationVersionEvent

- AuditAtnEventV2

- AuditAtzEvent

- AuditCerPathBuilderEvent、AuditCertPathValidatorEvent

- AuditConfigurationEvent (AuditCreateConfigurationEvent、AuditDeleteConfigurationEvent、AuditInvokeConfigurationEvent、AuditSetAttributeConfigurationEvent)

- AuditCredentialMappingEvent

- AuditLifecycleEvent

- AuditMgmtEvent

- AuditPolicyEvent (AuditEndPolicyDeployEvent、AuditPolicyDeleteAppEvent、AuditPolicyDeployEvent、AuditPolicyUndeployEvent、AuditResourceProtectedEvent、AuditStartPolicyDeployEvent、PolicyConsumerAuditEvent)

- AuditRoleDeploymentEvent (AuditStartRoleDeployEvent、AuditEndRoleDeployEvent、AuditRoleUndeployEvent、AuditRoleDeleteAppEvent)

- AuditRoleEvent (RoleConsumerAuditEvent)

AuditApplicationVersionEvent

アプリケーション・バージョンの監査イベントはセキュリティ・フレームワークによってポストされます。getEventTypeメソッドを使用すると監査イベントのタイプを取得できます。getEventTypeから戻される実際の監査情報の文字列はString = "Application Version Audit Event"です。

表10-2で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表10-2 アプリケーション・バージョン・イベント

コンポーネント

説明

重大度

セキュリティ・フレームワーク

このイベントはセキュリティ・フレームワークにより以下の理由でポストされます。

- 認可マネージャのアプリケーション・バージョンの作成が成功または失敗しました。

- 認可マネージャのアプリケーション・バージョンの削除が成功または失敗しました。

- 認可マネージャのバージョン管理されていないアプリケーションの削除が成功または失敗しました。

- ロール・マネージャのアプリケーション・バージョンの作成が成功または失敗しました。

- ロール・マネージャのアプリケーション・バージョンの削除が成功または失敗しました。

- ロール・マネージャのバージョン管理されていないアプリケーションの削除が成功または失敗しました。

- 資格証明マネージャのアプリケーション・バージョンの作成が成功または失敗しました。

- 資格証明マネージャのアプリケーション・バージョンの削除が成功または失敗しました。

- 資格証明マネージャのバージョン管理されていないアプリケーションの削除が成功または失敗しました。

SUCCESSまたはFAILURE

AuditAtnEventV2

認証監査イベントはセキュリティ・フレームワークによってポストされます。getEventTypeメソッドを使用すると監査イベントのタイプを取得できます。getEventTypeから戻される実際の監査情報の文字列はString eventType = "Event Type = Authentication Audit Event"です。

表10-3で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表10-3 認証監査イベント

コンポーネント

説明

重大度

セキュリティ・フレームワーク

ユーザーの認証が成功した後にポストされます。

SUCCESS

セキュリティ・フレームワーク

認証が失敗した後にポストされます(JAASログイン・メソッドからLoginExceptionがスローされます)。このLoginExceptionはJAASフレームワークによってスローされる場合と、WebLogic Server認証プロバイダのJAAS LoginModuleによってスローされる場合があります。

FAILURE

セキュリティ・フレームワーク

匿名ユーザーに対するIDアサーションの後にポストされます。

SUCCESS

セキュリティ・フレームワーク

IDアサーションが失敗した後にポストされます(IDアサーション・メソッドからIdentityAssertionExceptionがスローされます)。

FAILURE

セキュリティ・フレームワーク

IDアサーションが失敗した後にポストされます(コールバックからのユーザー名の取得時にIDアサーション・コールバック・ハンドラによってIOExceptionがスローされます)。

FAILURE

セキュリティ・フレームワーク

IDアサーションが失敗した後にポストされます(コールバックからのユーザー名の取得時にIDアサーション・コールバック・ハンドラによってUnsupportedCallbackExceptionがスローされます)。

FAILURE

セキュリティ・フレームワーク

IDアサーションが失敗した後にポストされます(IDアサーション・コールバック・ハンドラから返されたユーザー名がnullまたは長さゼロである場合)。

FAILURE

セキュリティ・フレームワーク

IDアサーションが成功した後にポストされます。

SUCCESS

セキュリティ・フレームワーク

IDアサーションが失敗した後にポストされます。

FAILURE

セキュリティ・フレームワーク

なりすましID (匿名ID)が成功した後にポストされます。

SUCCESS

セキュリティ・フレームワーク

なりすましIDが成功した後にポストされます。

SUCCESS

セキュリティ・フレームワーク

なりすましIDが失敗した後にポストされます。

FAILURE

セキュリティ・フレームワーク

プリンシパル検証が失敗した後にポストされます。

FAILURE

AuditAtzEvent

認可監査イベントはセキュリティ・フレームワークによってポストされます。getEventTypeメソッドを使用すると監査イベントのタイプを取得できます。getEventTypeから戻される実際の監査情報の文字列はString eventType = "Event Type = Authorization Audit Event V2 "です。

表10-4で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表10-4 認可監査イベント

コンポーネント

説明

重大度

セキュリティ・フレームワーク

リソースへのアクセスが許可されない場合にポストされます(認可プロバイダから例外がスローされます)。

FAILURE

セキュリティ・フレームワーク

リソースへのアクセスが許可される場合にポストされます。

SUCCESS

セキュリティ・フレームワーク

リソースへのアクセスが許可されない場合にポストされます。

FAILURE

AuditCerPathBuilderEvent、AuditCertPathValidatorEvent

証明書パス・ビルダーおよび証明書パス検証の監査イベントはセキュリティ・フレームワークによってポストされます。getEventTypeメソッドを使用すると監査イベントのタイプを取得できます。getEventTypeから戻される実際の監査情報の文字列は次のとおりです。

- String eventType = "Event Type = CertPathBuilder Audit Event "

- String eventType = "Event Type = CertPathValidator Audit Event "

表10-5で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表10-5 証明書パス・ビルダーおよび証明書パス検証のイベント

コンポーネント

説明

重大度

セキュリティ・フレームワーク

証明書パスが正常にビルドされた場合にポストされます。

SUCCESS

セキュリティ・フレームワーク

証明書パスが正常にビルドされない場合にポストされます。

FAILURE

セキュリティ・フレームワーク

証明書パスが正常に検証された場合にポストされます。

SUCCESS

セキュリティ・フレームワーク

証明書パスが正常に検証されない場合にポストされます。

FAILURE

AuditConfigurationEvent

構成監査イベントはセキュリティ・フレームワークによってポストされます。以下のイベントがポストされます。

- AuditConfigurationEvent

- AuditCreateConfigurationEvent (getEventTypeから返される実際の監査情報の文字列はString CREATE_EVENT = "Create Configuration Audit Event")

- AuditDeleteConfigurationEvent (getEventTypeから返される実際の監査情報の文字列はString DELETE_EVENT = "Delete Configuration Audit Event")

- AuditInvokeConfigurationEvent (getEventTypeから返される実際の監査情報の文字列はString INVOKE_EVENT = "Invoke Configuration Audit Event")

- AuditSetAttributeConfigurationEvent (getEventTypeから返される実際の監査情報の文字列はString SETATTRIBUTE_EVENT = "SetAttribute Configuration Audit Event")

表10-6で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表10-6 構成監査イベント

コンポーネント

説明

重大度

WebLogic管理インフラストラクチャ

WebLogic管理インフラストラクチャがこのインタフェースを実装し、以下の構成変更イベントについて構成監査イベントをポストできます。

- 新しい構成アーティファクトを作成するリクエストが許可されたか、許可されませんでした。

- 既存の構成アーティファクトを削除するリクエストが許可されたか、許可されませんでした。

- 既存の構成アーティファクトを変更するリクエストが許可されたか、許可されませんでした。

- 既存の構成アーティファクトに対する操作の呼出しが許可されたか、許可されませんでした。

SUCCESSまたはFAILURE

AuditCredentialMappingEvent

資格証明マッピング監査イベントはセキュリティ・フレームワークによってポストされます。getEventTypeメソッドを使用すると監査イベントのタイプを取得できます。getEventTypeから戻される実際の監査情報の文字列はString EVENT_TYPE = "Event Type = Credential apping Audit Event"です。

表10-7で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表10-7 資格証明マッピング監査イベント

コンポーネント

説明

重大度

セキュリティ・フレームワーク

WebLogicセキュリティ・フレームワークがこのインタフェースを実装し、以下のセキュリティ・イベントについて監査イベントをポストできます。

WebLogic Serverユーザーの資格証明がリクエストされました。

サブジェクトの資格証明がリクエストされました。

SUCCESS

AuditLifecycleEvent

AuditLifecycleEventインタフェースは監査のライフサイクルのイベントをポストするために使用されます。WebLogicセキュリティ・フレームワークがこのインタフェースを実装し、以下のセキュリティ・イベントについて監査イベントをポストできます。

- フレームワークの監査サービスの起動後。

- フレームワークの監査サービスの停止前。

getEventTypeから戻される実際の監査情報の文字列はString eventType = "Event Type = AuditLifecycle Audit Event"です。

AuditLifecycleEventTypeクラスに、サポートされる監査サービス・ライフサイクル・イベントのタイプが記述されます。有効な値はSTART_AUDITおよびSTOP_AUDITです。

監査プロバイダではこのインタフェースを使用して、監査のライフサイクルのイベントに関する付加的な情報を取得できます。AuditSeverityおよびAuditLifecycleEventType属性を使用すると、前述の監査イベントのうち、どちらがポストされたかを判断できます。

AuditMgmtEvent

管理監査イベントは、現在、セキュリティ・フレームワークおよび提供されているプロバイダのいずれでもポストされません。ただしカスタム・セキュリティ・プロバイダでは、このインタフェースを実装して、自身が実行する様々な管理操作に対し種々の監査イベントをポストできます。

監査プロバイダではこのインタフェースを使用して、管理監査イベントに関する付加的な情報を取得できます。AuditSeverity属性を使用すると、管理操作が成功したか、失敗したかを判断できます。

AuditPolicyEvent

AuditPolicyEventは、セキュリティ・フレームワークおよびWebLogic認可プロバイダによってポストされます。セキュリティ・フレームワークでは、ポリシーが認可プロバイダに対してデプロイまたはアンデプロイされたときにポリシー監査イベントをポストします。WebLogic Server認可プロバイダでは、ポリシーを作成、削除または更新したときにポリシー監査イベントをポストします。getEventTypeメソッドを使用すると監査イベントのタイプを取得できます。この監査イベント群と、getEventTypeから戻される実際の監査情報の文字列は次のとおりです。

- AuditStartPolicyDeployEvent (getEventType から返される実際の監査情報の文字列はString eventType = "Event Type = Authorization Start Policy Deploy Audit Event ")。

- AuditPolicyUndeployEvent (getEventTypeから返される実際の監査情報の文字列はString eventType = "Event Type = Authorization Policy Undeploy Audit Event ")。

- AuditPolicyDeployEvent (getEventTypeから返される実際の監査情報の文字列はString eventType = "Event Type = Authorization Policy Deploy Audit Event ")。

- AuditPolicyDeleteAppEvent (getEventTypeから返される実際の監査情報の文字列はString eventType = "Event Type = Authorization Delete Application Policies Audit Event ")。

- AuditEndPolicyDeployEvent (getEventTypeから返される実際の監査情報の文字列はString eventType = "Event Type = Authorization End Policy Deploy Audit Event ")。

AuditPolicyEventを実装するPolicyConsumerAuditEventの場合、getEventTypeから戻される実際の監査情報の文字列は次のとおりです。

- String eventType = "Event Type = Policy Consumer Get Handler"

- String eventType = "Event Type = Policy Consumer Set Policy"

- String eventType = "Event Type = Policy Consumer Set Unchecked Policy"

- String eventType = "Event Type = Policy Consumer Done"

表10-8で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表10-8 ポリシー監査イベント

コンポーネント

説明

重大度

WebLogic認可プロバイダ

- WebLogic認可プロバイダがこのインタフェースを実装し、以下のセキュリティ・イベントについて監査イベントをポストします。

- セキュリティ・ポリシーの作成が成功しました。

- セキュリティ・ポリシーの作成が失敗しました。

- セキュリティ・ポリシーの削除が成功しました。

- セキュリティ・ポリシーの削除が失敗しました。

- セキュリティ・ポリシーの更新が成功しました。

- セキュリティ・ポリシーの更新が失敗しました。

- アプリケーションのセキュリティ・ポリシーの削除が成功しました。

- アプリケーションのセキュリティ・ポリシーの削除が失敗しました。

SUCCESSまたはFAILURE

AuditRoleDeploymentEvent

セキュリティ・フレームワークでは、ロールがロール・マッピング・プロバイダに対してデプロイまたはアンデプロイされたときにロール・デプロイメント監査イベントをポストします。getEventTypeメソッドを使用すると監査イベントのタイプを取得できます。以下のイベントがポストされます。

- AuditRoleDeployEvent (getEventTypeから返される実際の監査情報の文字列はString eventType = "Event Type = RoleManager Deploy Audit Event ")。

- AuditStartRoleDeployEvent (getEventTypeから返される実際の監査情報の文字列はString eventType = "Event Type = RoleManager Start Deploy Role Audit Event ")。

- AuditEndRoleDeployEvent (getEventTypeから返される実際の監査情報の文字列はString eventType = "Event Type = RoleManager End Deploy Role Audit Event ")。

- AuditRoleUndeployEvent (getEventTypeから返される実際の監査情報の文字列はString eventType = "Event Type = RoleManager Undeploy Audit Event ")。

表10-9で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表10-9 ロール・デプロイメント監査イベント

コンポーネント

説明

重大度

セキュリティ・フレームワーク

WebLogicセキュリティ・フレームワークがこのインタフェースを実装し、以下のセキュリティ・イベントについて監査イベントをポストできます。

- ロール・マッピング・プロバイダに対するセキュリティ・ロール・デプロイメントが成功しました。

- ロール・マッピング・プロバイダに対するセキュリティ・ロール・デプロイメントが失敗しました。

- ロール・マッピング・プロバイダに対するセキュリティ・ロール・アンデプロイメントが成功しました。

- ロール・マッピング・プロバイダに対するセキュリティ・ロール・アンデプロイメントが失敗しました。

- ロール・マッピング・プロバイダに対するアプリケーションのセキュリティ・ロールの削除が成功しました。

- ロール・マッピング・プロバイダに対するアプリケーションのセキュリティ・ロールの削除が失敗しました。

SUCCESSまたはFAILURE

AuditRoleEvent

WebLogic認可プロバイダでは、ロールが作成、削除または更新されたときにロール監査イベントをポストします。getEventTypeメソッドを使用すると監査イベントのタイプを取得できます。getEventTypeから戻される実際の監査情報の文字列は次のとおりです。

- String eventType = "Event Type = RoleManager Audit Event "

- String eventType = "Event Type = RoleManager Delete Application Roles Audit Event "

AuditRoleEventを実装するRoleConsumerAuditEventの場合、getEventTypeから戻される実際の監査情報の文字列は次のとおりです。

- String eventType = "Event Type = Role Consumer Get Handler"

- String eventType = "Event Type = Role Consumer Set Role"

- String eventType = "Event Type = Role Consumer Done"

表10-10で、このイベントがポストされる条件とこのイベントの重大度レベルを説明します。

表10-10 ロール監査イベントがポストされる条件を説明します。

コンポーネント

説明

重大度

WebLogic認可プロバイダ

WebLogic認可プロバイダがこのインタフェースを実装し、以下のセキュリティ・イベントについて監査イベントをポストします。

- セキュリティ・ロールの作成が成功しました。

- セキュリティ・ロールの作成が失敗しました。

- セキュリティ・ロールの削除が成功しました。

- セキュリティ・ロールの削除が失敗しました。

- セキュリティ・ロールの更新が成功しました。

- セキュリティ・ロールの更新が失敗しました。

SUCCESS

11 資格証明マッピング・プロバイダ

この章では、資格証明マッピング・プロバイダの概念と機能、およびカスタム資格証明マッピング・プロバイダの開発手順について説明します。

資格証明マッピングとは、ターゲット・リソースにアクセスするユーザーを認証するための適切な資格証明のセットを、レガシー・システムのデータベースを用いて取得するプロセスのことです。WebLogic Serverでは、資格証明マッピング・プロバイダを使用して資格証明マッピング・サービスを提供し、新しいタイプの資格証明をWebLogic Server環境に導入します。

以下の節では、資格証明マッピング・プロバイダの概念と機能、およびカスタム資格証明マッピング・プロバイダの開発手順について説明します。

- 資格証明マッピングの概念

- 資格証明マッピング・プロセス

- カスタム資格証明マッピング・プロバイダを開発する必要があるか

- カスタム資格証明マッピング・プロバイダの開発方法

資格証明マッピングの概念

サブジェクト、つまりWebLogicリソース・リクエストの発信元は、資格証明というセキュリティ関連の属性を持っています。資格証明には、新しいサービスにアクセスするサブジェクトを認証するための情報が含まれています。こうした資格証明には、ユーザー名/パスワードの組合せ、Kerberosチケット、および公開鍵証明書などがあります。また、サブジェクトが特定のアクティビティを実行することを許可するデータも資格証明に含まれています。たとえば、暗号鍵が表す資格証明を持っていれば、サブジェクトは署名したり、データを暗号化したりすることができます。

資格証明マップは、WebLogic Serverが使用する資格証明と、レガシー・システム(または任意のリモート・システム)で使用する資格証明とのマッピングです。これにより、WebLogic Serverは、そのシステム内の特定のリソースへの接続方法を知ります。つまり、資格証明マップを使用することで、WebLogic Serverは認証済みサブジェクトに代わってリモート・システムにログインできます。資格証明マッピング・プロバイダを開発すると、資格証明をこのようにマップできます。

資格証明マッピング・プロセス

資格証明マッピング・プロセスにおける資格証明マッピング・プロバイダとWebLogicセキュリティ・フレームワークとの対話を図11-1に示し、続いてそれについて説明します。

図11-1 資格証明マッピング・プロバイダと資格証明マッピング・プロセス

「図11-1 資格証明マッピング・プロバイダと資格証明マッピング・プロセス」の説明

一般に、資格証明マッピングは以下のように実行されます。

1. JavaServer Page (JSP)、サーブレット、Enterprise JavaBeans (EJB)、リソース・アダプタなどのアプリケーション・コンポーネントは、適切なリソース・コンテナを通じてWebLogicセキュリティ・フレームワークを呼び出します。呼出しの中で、アプリケーション・コンポーネントは、サブジェクト(「誰が」リクエストしているのか)、WebLogicリソース(「何を」リクエストしているのか)、およびWebLogicリソースにアクセスするために必要な資格証明のタイプについての情報を渡します。

2. WebLogicセキュリティ・フレームワークは、資格証明に対するアプリケーション・コンポーネントのリクエストを構成済み資格証明マッピング・プロバイダに送信します。トークンをサポートするかどうかは、資格証明マッピング・プロバイダによって異なります。トークンをサポートしている場合は、その処理が行われます。

3. 資格証明マッピング・プロバイダは、レガシー・システムのデータベースを照会して、アプリケーション・コンポーネントがリクエストしているものに一致する資格証明群を取得します。

4. 資格証明マッピング・プロバイダは、資格証明をWebLogicセキュリティ・フレームワークに返します。

5. WebLogicセキュリティ・フレームワークは、リソース・コンテナを通じてリクエスト側のアプリケーション・コンポーネントに資格証明を返します。
アプリケーション・コンポーネントは、資格証明を使用して外部システムにアクセスします。外部システムには、OracleやSQL Serverなどのデータベース・リソースがあります。

カスタム資格証明マッピング・プロバイダを開発する必要があるか

WebLogic Serverのデフォルト(つまりアクティブな)セキュリティ・レルムにはWebLogic資格証明マッピング・プロバイダが含まれています。WebLogic資格証明マッピング・プロバイダは、WebLogic Serverのユーザーおよびグループを、他の外部システムが必要とする適切なユーザー名/パスワード資格証明にマップします。必要な資格証明マッピングがWebLogic Serverのユーザーおよびグループと他のシステムのユーザー名/パスワードとの間のマッピングであれば、WebLogic資格証明マッピング・プロバイダで十分です。

WebLogic Serverには、PKI資格証明マッピング・プロバイダがあります。WebLogic ServerのPKI (公開鍵インフラストラクチャ)資格証明マッピング・プロバイダは、WebLogic Serverのサブジェクト(イニシエータ)とターゲット・リソース(および必要であれば資格証明アクション)を、ターゲットとなるリソースを使用する際にアプリケーションで使用するキー・ペアまたは公開証明書にマップします。PKI資格証明マッピング・プロバイダは、サブジェクトとリソース名を使用して対応する資格証明をキーストアから検索します。PKI資格証明マッピング・プロバイダで使用可能なトークンの種類はCredentialMapperV2.PKI_KEY_PAIR_TYPEとCredentialMapperV2.PKI_TRUSTED_CERTIFICATE_TYPEです。

また、WebLogic ServerにはSAML資格証明マッピング・プロバイダが含まれています。SAML資格証明マッピング・プロバイダでは、ターゲットのサイトまたはリソースに基づく認証されたサブジェクトに対するSAML 1.1および2.0アサーションを生成します。要求されたターゲットが、構成されておらず、デフォルトが設定されていない場合、アサーションは生成されません。ユーザー情報およびグループ・メンバーシップは、(そのように構成された場合)AttributeStatement内に置かれます。

『Oracle WebLogic Serverセキュリティのプログラミング』のSAML SSO属性サポートの構成に関する項で説明されているように、WebLogic Serverでは、追加属性(グループ情報以外)を取得してSAMLアサーションに書き込んだり、着信SAMLアサーションからの属性のマップを可能にするカスタム属性マッパーの使用をサポートするために、SAML 1.1および2.0の資格証明マッピング・プロバイダとIDアサーション・プロバイダのメカニズムが強化されています。

SAML資格証明マッピング・プロバイダでは、CredentialMapperV2.SAML_ASSERTION_B64_TYPE、CredentialMapperV2.SAML_ASSERTION_DOM_TYPE、およびCredentialMapperV2.SAML_ASSERTION_TYPEの各トークン・タイプがサポートされています。

SAML 2.0資格証明マッピング・プロバイダでは、CredentialMapperV2.SAML2_ASSERTION_DOM_TYPEトークン・タイプおよびCredentialMapperV2.SAML2_ASSERTION_TYPEトークン・タイプがサポートされています。

初期状態の資格証明マッピング・プロバイダが開発者のニーズを満たさない場合は、カスタム資格証明マッピング・プロバイダを開発する必要があります。ただし、WebLogic Serverリソース・コンテナでリクエストされるのは、次のトークンの種類のみです。

- CredentialMapperV2.PASSWORD_TYPE

- CredentialMapperV2.PKI_KEY_PAIR_TYPE

- CredentialMapperV2.PKI_TRUSTED_CERTIFICATE_TYPE

- CredentialMapperV2.SAML_ASSERTION_B64_TYPE

- CredentialMapperV2.SAML_ASSERTION_DOM_TYPE

- CredentialMapperV2.SAML_ASSERTION_TYPE

- CredentialMapperV2.SAML2_ASSERTION_DOM_TYPE

- CredentialMapperV2.SAML2_ASSERTION_TYPE

- CredentialMapperV2.USER_PASSWORD_TYPE

カスタム資格証明マッピング・プロバイダでアプリケーションのバージョン管理をサポートする必要があるか

セキュリティ・レルムのすべての認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダは、アプリケーションのデプロイにバージョンを使用するために、アプリケーションのバージョン管理をサポートする必要があります。認可、ロール・マッピング、または資格証明マッピング用にカスタム・セキュリティ・プロバイダを開発する際に、バージョン管理されたアプリケーションをサポートする必要がある場合は、第14章「バージョン管理可能なアプリケーションのプロバイダ」の説明に従って、バージョン管理可能なアプリケーションのSSPIを実装する必要があります。

カスタム資格証明マッピング・プロバイダの開発方法

WebLogic資格証明マッピング・プロバイダが開発者のニーズを満たさない場合、次の手順でカスタム資格証明マッピング・プロバイダを開発することができます。

1. 適切なSSPIによるランタイム・クラスの作成

2. WebLogic MBeanMakerを使用してMBeanタイプを生成する

3. 資格証明マップを管理するためのメカニズムの提供

適切なSSPIによるランタイム・クラスの作成

ランタイム・クラスを作成する前に、以下の作業が必要です。

- 「Provider」SSPIの目的について

- 実装する「Provider」インタフェースの決定

- SSPI階層を理解し、ランタイム・クラスを1つ作成するか2つ作成するかを決定する

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム資格証明マッピング・プロバイダのランタイム・クラスを作成します。

- CredentialProviderV2 SSPIの実装またはDeployableCredentialProvider SSPIの実装

- CredentialMapperV2 SSPIの実装

CredentialProviderV2 SSPIの実装

CredentialProviderV2 SSPIを実装するには、「「Provider」SSPIの目的について」で説明されているメソッドおよび次のメソッドの実装を提供する必要があります。

- getCredentialProvider

public CredentialMapperV2 getCredentialProvider();

getCredentialProviderV2メソッドはCredentialMapperV2 SSPIの実装を取得します。(図3-3にあるような)MyCredentialMapperProviderImpl.javaという単一のランタイム・クラスの場合、getCredentialProviderメソッドの実装は次のようになります:

return this;

ランタイム・クラスが2つの場合、getCredentialProviderメソッドの実装は次のようになります。

return new MyCredentialMapperImpl;

これは、CredentialProviderV2 SSPIを実装するランタイム・クラスが、CredentialMapperV2 SSPIを実装するクラスを取得する場合のファクトリとして使用されるためです。

CredentialProviderV2 SSPIとgetCredentialProviderメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

DeployableCredentialProvider SSPIの実装

注意:

DeployableCredentialProvider SSPIは、このリリースのWebLogic Serverでは非推奨になっています。

DeployableCredentialProvider SSPIを実装するには、「「Provider」SSPIの目的について」および「CredentialProviderV2 SSPIの実装」で説明されているメソッドおよび次のメソッドの実装を提供する必要があります。

- deployCredentialMapping

public void deployCredentialMapping(Resource resource, String
initiatingPrincipal, String eisUsername, String eisPassword)throws
ResourceCreationException;

deployCredentialMappingメソッドは資格証明マップをデプロイします。マッピングがすでに存在する場合、マッピングは削除され、このマッピングによって置き換えられます。resourceパラメータは、Stringで表される開始元プリンシパルがアクセスをリクエストしているWebLogicリソースを表します。エンタープライズ情報システム(EIS)のユーザー名およびパスワードは、資格証明のマップ先のレガシー・システム(リモート・システム)における資格証明です。

- undeployCredentialMappings

public void undeployCredentialMappings(Resource resource) throws
ResourceRemovalException;

undeployCredentialMappingsメソッドは、資格証明マップをアンデプロイします(つまり、アンデプロイ済みのリソース・アダプタにかわって資格証明マッピングをデータベースから削除します)。resourceパラメータは、マッピングを削除するWebLogicリソースを表します。

注意:

deployCredentialMappingメソッド、およびundeployCredentialMappingsメソッドは、ユーザー名/パスワード資格証明のみを操作します。

DeployableCredentialProvider SSPIとdeployCredentialMapping/undeployCredentialMappingsメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

CredentialMapperV2 SSPIの実装

CredentialMapperV2インタフェースは、アプリケーション内でスコープが指定されている特定のリソースに対して適切な資格証明群の取得が可能なオブジェクトのセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を定義します。

以下の資格証明の種類のみがサポートされており、CredentialMapperV2インタフェースに渡されます。

- PASSWORD_TYPE

- PKI_KEY_PAIR_TYPE

- PKI_TRUSTED_CERTIFICATE_TYPE

- SAML_ASSERTION_B64_TYPE

- SAML_ASSERTION_DOM_TYPE

- SAML_ASSERTION_TYPE

- SAML2_ASSERTION_DOM_TYPE

- SAML2_ASSERTION_TYPE

- USER_PASSWORD_TYPE

CredentialMapperV2 SSPIを実装するには、以下のメソッドの実装を提供する必要があります。

- getCredential

public Object getCredential(Subject requestor, String initiator, Resource
resource, ContextHandler handler, String credType);

getCredentialメソッドは、指定したイニシエータに関連付けられているターゲット・リソースから、指定した種類の資格証明を返します。

- getCredentials

public Object[] getCredentials(Subject requestor, Subject initiator, Resource
resource, ContextHandler handler, String credType);

getCredentialsメソッドは、指定したイニシエータに関連付けられているターゲット・リソースから、指定した種類の資格証明を複数返します。

CredentialMapperV2 SSPIとgetCredentialおよびgetCredentialsメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

レルム・アダプタ認証プロバイダと互換性のあるカスタム資格証明マッピング・プロバイダを開発する

認証プロバイダは、サブジェクト内へのユーザーおよびグループの格納を担当するセキュリティ・プロバイダです。ユーザーおよびグループはその後、資格証明マッピング・プロバイダなど、他のタイプのセキュリティ・プロバイダによって、サブジェクトから抽出されます。セキュリティ・レルム内で構成された認証プロバイダがレルム・アダプタ認証プロバイダである場合、ユーザーおよびグループの情報は、他の認証プロバイダとは少し異なる形でサブジェクト内に格納されます。したがって、このユーザーおよびグループの情報もまた、少し異なる方法で抽出する必要があります。

例11-1では、サブジェクトへの格納にレルム・アダプタ認証プロバイダが使用された場合に、サブジェクトがユーザー名またはグループ名に一致するかどうかをチェックするため、カスタム資格証明マッピング・プロバイダで使用できるコードを示します。このコードは、実装することを選択したgetCredentialsメソッドの形式に属しています。コードでは、weblogic.security.SubjectUtilsクラスで使用可能なメソッドを利用します。

例11-1 サンプル・コード:サブジェクトがユーザー名またはグループ名に一致するかどうかのチェック

/**
* Determines if the Subject matches a user/group name.
*
* @param principalWant A String containing the name of a principal in this role
* (that is, the role definition).
*
* @param subject A Subject that contains the Principals that identify the user
* who is trying to access the resource as well as the user's groups.
*
* @return A boolean. true if the current subject matches the name of the
* principal in the role, false otherwise.
*/
private boolean subjectMatches(String principalWant, Subject subject)
{
// first, see if it's a group name match
if (SubjectUtils.isUserInGroup(subject, principalWant)) {
return true;
}
// second, see if it's a user name match
if (principalWant.equals(SubjectUtils.getUsername(subject))) {
return true;
}
// didn't match
return false;
}

WebLogic MBeanMakerを使用してMBeanタイプを生成する

カスタム・セキュリティ・プロバイダのMBeanタイプを生成する前に、以下の作業が必要です。

- MBeanタイプが必要な理由について

- 拡張および実装するSSPI MBeanの決定

- MBean定義ファイル(MDF)の基本的な要素について

- SSPI MBeanの階層と管理コンソールに対する影響について

- WebLogic MBeanMakerによって提供されるものについて

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム資格証明マッピング・プロバイダのMBeanタイプを作成します。

1. MBean定義ファイル(MDF)の作成

2. WebLogic MBeanMakerを使用してMBeanタイプを生成する

3. WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

4. WebLogic Server環境にMBeanタイプをインストールする

注意:

複数のセキュリティ・プロバイダのサンプルで、これらの手順の実行方法を示します。

この節で説明する手順はすべて、Windows環境での作業を想定しています。

MBean定義ファイル(MDF)の作成

MBean定義ファイル(MDF)を作成するには、次の手順に従います。

1. サンプル認証プロバイダのMDFをテキスト・ファイルにコピーします。

注意:

サンプル認証プロバイダのMDFは、SimpleSampleAuthenticator.xmlです。(現在、サンプル資格証明マッピング・プロバイダはありません)。

2. MDFで<MBeanType>要素と<MBeanAttribute>要素の内容をカスタム資格証明マッピング・プロバイダに合わせて修正します。

3. カスタム属性および操作(つまり、<MBeanAttribute>および<MBeanOperation>要素)をMDFに追加します。

4. ファイルを保存します。

注意:

MDF要素の構文についての詳細なリファレンスは、付録A「MBean定義ファイル(MDF)要素の構文」に収められています。

WebLogic MBeanMakerを使用してMBeanタイプを生成する

MDFを作成したら、WebLogic MBeanMakerを使用してそれを実行できます。WebLogic MBeanMakerは現在のところコマンドライン・ユーティリティで、入力としてMDFを受け取り、MBeanインタフェース、MBean実装、関連するMBean情報ファイルなどの中間Javaファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム・セキュリティ・プロバイダのMBeanタイプになります。

MBeanタイプの生成手順は、カスタム資格証明マッピング・プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。

- オプショナルSSPI MBeanとカスタム操作を追加しない場合

- オプショナルSSPI MBeanまたはカスタム操作を追加する場合

オプショナルSSPI MBeanとカスタム操作を追加しない場合

カスタム資格証明マッピング・プロバイダのMDFがオプショナルSSPI MBeanを実装せず、かつ、いかなるカスタム操作も含まない場合、次の手順に従います。

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり資格証明マッピング・プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

3. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

オプショナルSSPI MBeanまたはカスタム操作を追加する場合

カスタム資格証明マッピング・プロバイダのMDFがオプショナルSSPI MBeanまたはカスタム操作を実装する場合、以下の質問に答えながら手順を進めてください。

MBeanタイプを作成するのは初めてですか。その場合は、次の手順に従ってください:

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり資格証明マッピング・プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

3. オプショナルSSPI MBeanをMDFに実装した場合は、次の手順に従います。

1. MBean実装ファイルを見つけます。
WebLogic MBeanMakerによって生成されるMBean実装ファイルには、MBeanNameImpl.javaという名前が付けられます。たとえば、MyCredentialMapperという名前のMDFの場合、編集されるMBean実装ファイルはMyCredentialMapperImpl.javaという名前になります。

2. MDFで実装したオプショナルSSPI MBeanごとに、各メソッドを実装します。オプショナルSSPI MBeanが継承するメソッドもすべて実装してください。

4. MDFにカスタム操作を含めた場合、メソッド・スタブを使用してメソッドを実装します。

5. ファイルを保存します。

6. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

既存のMBeanタイプの更新ですか。その場合は、次の手順に従ってください:

1. WebLogic MBeanMakerによって現在のメソッドの実装が上書きされないように、既存のMBean実装ファイルを一時ディレクトリにコピーします。

2. 新しいDOSシェルを作成します。

3. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり資格証明マッピング・プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

4. オプショナルSSPI MBeanをMDFに実装した場合は、次の手順に従います。

1. MBean実装ファイルを見つけます。
WebLogic MBeanMakerによって生成されるMBean実装ファイルには、MBeanNameImpl.javaという名前が付けられます。たとえば、SampleCredentialMapperという名前のMDFの場合、編集されるMBean実装ファイルはSampleCredentialMapperImpl.javaという名前になります。

2. ステップ1で一時ディレクトリに保存した既存のMBean実装ファイルを開きます。

3. 既存のMBean実装ファイルを、WebLogic MBeanMakerによって生成されたMBean実装ファイルと同期させます。
これには、メソッドの実装を既存のMBean実装ファイルから新しく生成されたMBean実装ファイルにコピー(または、新しく生成されたMBean実装ファイルから既存のMBean実装ファイルに新しいメソッドを追加)し、いずれのMBean実装ファイルにも入っているメソッドのメソッド・シグネチャへの変更が、使用するMBean実装ファイルに反映されていることを確認するといった作業が必要です。

4. MDFを修正して元のMDFにはないオプショナルSSPI MBeanを実装した場合は、各メソッドを実装します。オプショナルSSPI MBeanが継承するメソッドもすべて実装してください。

5. MDFを変更して元のMDFにはないカスタム操作を含めた場合、メソッド・スタブを使用してメソッドを実装します。

6. 完成した、つまりすべてのメソッドを実装したMBean実装ファイルを保存します。

7. このMBean実装ファイルを、WebLogic MBeanMakerがMBeanタイプの実装ファイルを配置したディレクトリにコピーします。このディレクトリは、手順3でfilesdirとして指定したものです。(ステップ3の結果としてWebLogic MBeanMakerで生成されたMBean実装ファイルがオーバーライドされます)。

8. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

生成されるMBeanインタフェース・ファイルについて

MBeanインタフェース・ファイルとは、ランタイム・クラスまたはMBean実装が構成データを取得するために使用するMBeanのクライアント側APIです。「「Provider」SSPIの目的について」で説明されているように、これはinitializeメソッドで使用するのが一般的です。

WebLogic MBeanMakerでは、作成済のMDFからMBeanタイプを生成するので、生成されるMBeanインタフェース・ファイルの名前は、そのMDF名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMakerでMyCredentialMapper MDFを実行すると、MyCredentialMapperMBean.javaというMBeanインタフェース・ファイルが生成されます。

WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

WebLogic MBeanMakerでMDFを実行して中間ファイルを作成し、MBean実装ファイルを編集して適切なメソッドの実装を提供したら、カスタム資格証明マッピング・プロバイダのMBeanファイルとランタイム・クラスをMBean JARファイル(MJF)にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMakerによって自動化されます。

カスタム資格証明マッピング・プロバイダのMJFを作成するには、次の手順に従います。

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMJF=jarfile -Dfiles=filesdir weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMJFフラグはWebLogic MBeanMakerが新しいMBeanタイプを含むJARファイルを構築すべきであることを示し、jarfileはMJFの名前、filesdirはWebLogic MBeanMakerでMJFにJAR化する対象ファイルが存在する場所を示します。

この時点でコンパイルが行われるので、エラーが発生するおそれがあります。jarfileが指定されていて、エラーが発生しなかった場合には、指定された名前のMJFが作成されます。

注意:

カスタム・セキュリティ・プロバイダのJARファイルを作成する際には、一連のXMLバインディング・クラスと1つのスキーマも生成されます。そのスキーマに関連付けるネームスペースを選択できます。それにより、使用しているカスタム・クラスとOracleのカスタム・クラスとの競合を防ぐことができます。ネームスペースのデフォルトはvendorです。-targetNameSpace引数をWebLogicMBeanMakerまたは関連するWLMBeanMaker antタスクに渡すことで、このデフォルトを変更できます。

既存のMJFを更新する場合は、単純にMJFを削除して再生成します。WebLogic MBeanMakerにも -DIncludeSourceオプションがあり、それを指定すると、生成されるMJFにソース・ファイルを含めるかどうかを制御できます。ソース・ファイルには、生成されたソースとMDFそのものがあります。デフォルトはfalseです。このオプションは、-DMJFを使用しない場合には無視されます。

生成されたMJFは、自らのWebLogic Server環境にインストールすることも、顧客に配布してそれぞれのWebLogic Server環境にインストールしてもらうこともできます。

WebLogic Server環境にMBeanタイプをインストールする

MBeanタイプをWebLogic Server環境にインストールするには、MJFをWL_HOME\server\lib\mbeantypesディレクトリにコピーします。ここで、WL_HOMEはWebLogic Serverの最上位のインストール・ディレクトリです。このインストール・コマンドによって、カスタム資格証明マッピング・プロバイダが「デプロイ」されます。つまり、カスタム資格証明マッピング・プロバイダをWebLogic Server管理コンソールから管理できるようになります。

注意:

MBeanタイプをインストールするデフォルトのディレクトリは、WL_HOME\server\lib\mbeantypesです。初めて使用するバージョンが9.0の場合、セキュリティ・プロバイダは...\domaindir\lib\mbeantypesからもロードできます。ただし、サーバーを起動するときに-Dweblogic.alternateTypesDirectory=<dir>コマンドライン・フラグを使用すれば、WebLogic Serverが追加ディレクトリでMBeanタイプを検索します。<dir>は、ディレクトリ名のカンマ区切りのリストです。このフラグを使用する場合、WebLogic Serverは常に最初にWL_HOME\server\lib\mbeantypesからMBeanタイプをロードします。その後で、追加ディレクトリにあるすべての有効なアーカイブを検索して、ロードします。このとき拡張子は考慮されません。

たとえば、-Dweblogic.alternateTypesDirectory = dirX,dirYの場合、WebLogic ServerはまずWL_HOME\server\lib\mbeantypesからMBeanタイプをロードし、次にdirXおよびdirYにある有効なアーカイブをロードします。WebLogic Serverに追加ディレクトリでMBeanタイプを検索するよう指示する際に、Javaセキュリティ・マネージャを使用している場合は、weblogic.policyファイルを更新して、MBeanタイプ(その結果として、カスタム・セキュリティ・プロバイダ)に適した許可を付与することも必要になります。詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』のJavaセキュリティを使用したWebLogicリソースの保護に関する項を参照してください。

カスタム資格証明マッピング・プロバイダを構成することによって(「資格証明マップを管理するためのメカニズムの提供」を参照) MBeanタイプのインスタンスを作成して、GUI、他のJavaコード、またはAPIからそれらのMBeanインスタンスを使用することができます。たとえば、WebLogic Server管理コンソールを使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他のJavaオブジェクトを開発して、そのオブジェクトでMBeanをインスタンス化し、それらのMBeanから提供される情報に自動的に応答させることもできます。なお、これらのMBeanインスタンスをバックアップしておくことをお薦めします。

資格証明マップを管理するためのメカニズムの提供

WebLogic Server管理コンソールを使用してカスタム資格証明マッピング・プロバイダを構成すると、必要な資格証明マッピング・サービスにアプリケーションからアクセスできるようにすることはできますが、このセキュリティ・プロバイダに関連付けられた資格証明マップを管理する方法を管理者にも提供する必要があります。たとえばWebLogic資格証明マッピング・プロバイダには、資格証明マッピング・ページが管理者向けに用意されており、様々なコネクタ・モジュールの資格証明マッピングを追加、変更、または削除することができます。

カスタム資格証明マッピング・プロバイダを開発すると、管理者は資格証明マッピング・ページも右クリック・メニューも利用できません。したがって、資格証明マップを管理するための独自のメカニズムを提供する必要があります。このメカニズムでは、カスタム資格証明マッピング・プロバイダのデータベースの資格証明マップを読み書きできなければなりません。

それには、以下の2通りの方法があります。

- オプション1: 資格証明マップ管理用のスタンドアロン・ツールの開発

- オプション2 :既存のセキュリティ・ポリシー管理ツールを管理コンソールに統合する

オプション1 :資格証明マップ管理用のスタンドアロン・ツールの開発

WebLogic Server管理コンソールとまったく別のツールを開発する場合には、この方法を選択します。

この方法では、カスタム資格証明マッピング・プロバイダ向けにコンソール拡張を作成する必要も、管理MBeanを開発する必要もありません。ただし、ツールでは以下のことを行う必要があります。

1. WebLogicリソースのIDを特定します。IDがコンソール拡張によって自動的に提供されないためです。詳細については、「WebLogicリソース識別子」を参照してください。

2. ローカル・ユーザーとリモート・ユーザーとの関係を表す方法を特定します。この表現は完全に任意であり、文字列である必要はありません。

3. カスタム資格証明マッピング・プロバイダのデータベースの式を読み書きします。

オプション2 : 管理コンソールに既存の資格証明マップ管理ツールの統合

WebLogic Server管理コンソールとは別のツールを持っており、それを管理コンソールから起動する場合には、この方法を選択します。

この方法の場合、ツールでは以下のことを行う必要があります。

1. WebLogicリソースのIDを特定します。詳細については、「WebLogicリソース識別子」を参照してください。

2. ローカル・ユーザーとリモート・ユーザーとの関係を表す方法を特定します。この表現は完全に任意であり、文字列である必要はありません。

3. カスタム資格証明マッピング・プロバイダのデータベースの式を読み書きします。

4. 『Oracle WebLogic Server管理コンソールの拡張』で説明されているように、基本的なコンソール拡張手法を使用して管理コンソールにリンクします。

12 カスタム・セキュリティ・プロバイダからのイベントの監査

この章では、カスタム・セキュリティ・プロバイダに監査機能を追加する前に理解しておく必要がある基本情報と、カスタム・セキュリティ・プロバイダに監査機能を追加する手順について説明します。

第10章「監査プロバイダ」で説明されているように、監査とは、リクエストの操作とそれらのリクエストの結果に関する情報を、否認防止を目的として収集、格納、および配布するプロセスのことです。監査プロバイダは、コンピュータのアクティビティの電子的な記録を提供します。

各タイプのセキュリティ・プロバイダは、セキュリティ関連イベントの実行前または実行後に、それらのイベントに関する情報を記録するよう構成済みの監査プロバイダにリクエストできます。たとえば、あるユーザーが(アクセス権を持たない)預金口座アプリケーションのwithdrawメソッドにアクセスしようとした場合、認可プロバイダではこの操作を記録するようにリクエストできます。セキュリティ関連イベントは、監査プロバイダの構成で指定されている重大度レベルと一致するか、それを超えた場合にのみ記録されます。

以下の節では、カスタム・セキュリティ・プロバイダに監査機能を追加する前に理解しておく必要がある基本情報と、カスタム・セキュリティ・プロバイダに監査機能を追加する手順について説明します。

- セキュリティ・サービスと監査サービス

- カスタム・セキュリティ・プロバイダからの監査方法

セキュリティ・サービスと監査サービス

weblogic.security.spiパッケージのSecurityServicesインタフェースは、セキュリティ・サービスのリポジトリです(現在は単なる監査サービス)。SecurityServicesインタフェースは、以下のメソッドを通じて呼出し側に監査サービスの参照を提供します。

- getAuditorService

public AuditorService getAuditorService

getAuditorServiceメソッドは、監査プロバイダが構成されている場合にAuditServiceを返します。

同じくweblogic.security.spiパッケージにあるAuditorServiceインタフェースは、他のタイプのセキュリティ・プロバイダ(認証プロバイダなど)に対する限定された(書込み専用の)監査機能を提供します。つまり、監査サービスでは構成されている各監査プロバイダのwriteEventメソッドを呼び出します。このメソッドは渡されたAuditEventオブジェクトに指定されている情報に基づいて、単純に監査レコードを記述します。

writeEventメソッドの詳細は、「AuditChannel SSPIの実装」を参照してください。AuditEventオブジェクトの詳細は、「監査イベントの作成」を参照してください。AuditorServiceインタフェースには次のメソッドがあります。

- providerAuditWriteEvent

public void providerAuditWriteEvent (AuditEvent event)

providerAuditWriteEventメソッドは、セキュリティ・プロバイダに対して、構成済みの監査プロバイダを呼び出すWebLogicセキュリティ・フレームワーク内のオブジェクトへの書込みアクセスを提供します。eventパラメータは、監査するイベントのタイプや監査重大度レベルなどの監査条件を含むAuditEventオブジェクトです。監査イベントと監査重大度レベルの詳細は、それぞれ「監査イベントの作成」と「監査重大度」を参照してください。

監査サービスを呼び出すと、監査イベントの実行前または実行後にそれらのイベントを記録できますが、操作の前と後の間のコンテキストは維持されません。監査機能を持つセキュリティ・プロバイダは、「監査サービスの取得、および取得した監査サービスによる監査イベントの書込み」の説明に従って監査サービスを取得する必要があります。

注意:

監査プロバイダが構成されている場合、SecurityServicesインタフェースとAuditorServiceインタフェースの実装は起動時にWebLogicセキュリティ・フレームワークによって作成されます。(監査プロバイダの構成については、「管理コンソールによるカスタム監査プロバイダの構成」を参照してください)。

また、SecurityServicesオブジェクトは、セキュリティ・プロバイダが構成されているセキュリティ・レルムに固有のものです。カスタム・セキュリティ・プロバイダのランタイム・クラスは、そのinitializeメソッドの一部としてレルム固有のSecurityServicesオブジェクトへの参照を自動的に取得します。(詳細は、「「Provider」SSPIの目的について」を参照してください。)

これらのインタフェースとそのメソッドの詳細は、Oracle WebLogic Server APIリファレンスのSecurityServicesインタフェースおよびAuditorServiceインタフェースを参照してください。

カスタム・セキュリティ・プロバイダからの監査方法

カスタム・セキュリティ・プロバイダに監査機能を追加するには、次の手順に従います。

- 監査イベントの作成

- 監査サービスの取得、および取得した監査サービスによる監査イベントの書込み

各手順の例については、「例: AuditRoleEventインタフェースの実装」と「例:監査サービスを取得および使用してロール監査イベントの書込み」を参照してください。

注意:

カスタム・セキュリティ・プロバイダが監査イベントを記録する場合、必須のファイルに加えて、以下の手順で作成したすべてのクラスを、そのプロバイダ用のMBean JARファイル(MJF)に追加する必要があります。

監査イベントの作成

セキュリティ・プロバイダは、イベントのタイプ(認証イベントなど)や監査重大度(「エラー」など)といった、監査するイベントに関する情報を提供する必要があります。監査イベントには、この情報が格納されます。また、構成済みの監査プロバイダが理解できるコンテキスト・データも格納できます。監査イベントを作成するには、以下のいずれかを行います。

- AuditEvent SSPIの実装

- 監査イベント・コンビニエンス・インタフェースの実装

AuditEvent SSPIの実装

AuditEvent SSPIを実装するには、以下のメソッドの実装を提供する必要があります。

- getEventType

public java.lang.String getEventType()

getEventTypeメソッドは、監査するイベント・タイプの文字列表現を返します。この文字列表現は、監査チャネル(AuditChannel SSPIを実装するランタイム・クラス)によって使用されます。たとえば、Oracle提供の実装のイベント・タイプは"Authentication Audit Event"です。詳細については、「監査チャネル」および「AuditChannel SSPIの実装」を参照してください。

- getFailureException

public java.lang.Exception getFailureException()

getFailureExceptionメソッドは、Exceptionオブジェクトを返します。監査チャネルは、tostringメソッドから提供される情報に加えて、このオブジェクトから監査情報を取得します。

- getSeverity

public AuditSeverity getSeverity()

getSeverityメソッドは、監査するイベント・タイプに関連付けられている重大度レベル値を返します。この値は、監査チャネルによって使用されます。監査チャネルはこの値を使用して、監査するかどうかを判定します。詳細については、「監査重大度」を参照してください。

- toString

public java.lang.String toString()

toStringメソッドは、あらかじめフォーマットされた監査情報を監査チャネルに返します。

注意:

toStringメソッドは、任意の文字を生成できます。その際、エスケープは使用されません。監査プロバイダが、構文に文字を使用するフォーマットにtoString値を書き込む場合は、その前にtoString値をエスケープしてください。

AuditEvent SSPIとこれらのメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

監査イベント・コンビニエンス・インタフェースの実装

AuditEvent SSPIには、ユーザーの利便を図り、監査イベントの作成に役立つサブインタフェースがいくつか用意されています。

監査チャネル(AuditChannel SSPIを実装するランタイム・クラス)では、それらの各監査イベント・コンビニエンス・インタフェースを使用して、拡張イベント・タイプ・オブジェクトのインスタンス・タイプをより効果的に判断し、特定のタイプのセキュリティ・プロバイダを識別することができます。たとえば、AuditAtnEventV2コンビニエンス・インタフェースを監査チャネルで使用すると、拡張認証イベント・タイプ・オブジェクトのインスタンス・タイプを判断できます。(詳細については、「監査チャネル」および「AuditChannel SSPIの実装」を参照してください)。

監査イベント・コンビニエンス・インタフェースは以下のとおりです。

- AuditAtnEventV2インタフェース

- AuditAtzEventおよびAuditPolicyEventインタフェース

- AuditMgmtEventインタフェース

- AuditRoleEventおよびAuditRoleDeploymentEventインタフェース

注意:

上記の監査イベント・コンビニエンス・インタフェースの1つを実装することをお薦めしますが、必須ではありません。

AuditAtnEventV2インタフェース

AuditAtnEventV2は、監査チャネルが拡張認証イベント・タイプ・オブジェクトのインスタンス・タイプを判断するのに役立つコンビニエンス・インタフェースです。

注意:

AuditAtnEventインタフェースは、このリリースのWebLogic Serverで非推奨になりました。

AuditAtnEventV2インタフェースを実装するには、「AuditEvent SSPIの実装」で説明されているメソッドおよび次のメソッドの実装を提供する必要があります。

- getUsername

public String getUsername()

getUsernameメソッドは、認証イベントに関連付けられているユーザー名を返します。

- getAtnEventType

public AuditAtnEventV2.AtnEventTypeV2 getAtnEventType()

getAtnEventTypeメソッドは、認証イベントをより具体的に表すイベント・タイプを戻します。具体的な認証イベント・タイプは次のとおりです。

AUTHENTICATE - ユーザー名とパスワードを使用する単純な認証が発生しました。

ASSERTIDENTITY - トークンに基づく境界認証が発生しました。

CREATEDERIVEDKEY - 派生キーの作成を表します。

CREATEPASSWORDDIGEST - パスワード・ダイジェストの作成を表します。

IMPERSONATEIDENTITY - 指定されたクライアント・ユーザー名を使用してクライアントIDが確立されました(カーネルIDが必要です)。

USERLOCKED - 無効なログインの試行によってユーザー・アカウントがロックされました。

USERUNLOCKED - ユーザー・アカウントのロックが解除されました。

USERLOCKOUTEXPIRED - ユーザー・アカウントのロックが期限切れになりました。

VALIDATEIDENTITY - 指定されたサブジェクト内のプリンシパルの信頼性が検証されました。

- toString

public String toString()

toStringメソッドは、文字列で表された特定の認証情報を監査に返します。

注意:

toStringメソッドは、任意の文字を生成できます。その際、エスケープは使用されません。監査プロバイダが、構文に文字を使用するフォーマットにtoString値を書き込む場合は、その前にtoString値をエスケープしてください。

AuditAtnEventV2というコンビニエンス・インタフェースを使用すると、AuditEventインタフェースとAuditContextインタフェースの両方を拡張できます。AuditContextインタフェースの詳細は、「監査コンテキスト」を参照してください。

AuditAtnEventV2コンビニエンス・インタフェースとこれらのメソッドの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

AuditAtzEventおよびAuditPolicyEventインタフェース

AuditAtzEventおよびAuditPolicyEventコンビニエンス・インタフェースは、監査チャネルが拡張認可イベント・タイプ・オブジェクトのインスタンス・タイプを判断するのに役立ちます。

注意:

AuditAtzEventコンビニエンス・インタフェースとAuditPolicyEventコンビニエンス・インタフェースは、後者がAuditEventインタフェースのみを拡張する点で異なります。(後者はAuditContextインタフェースを拡張しません。)AuditContextインタフェースの詳細は、「監査コンテキスト」を参照してください。

AuditAtzEventインタフェースまたはAuditPolicyEventインタフェースを実装するには、「AuditEvent SSPIの実装」で説明されているメソッドおよび次のメソッドの実装を提供する必要があります。

- getSubject

public Subject getSubject()

getSubjectメソッドは、認可イベントに関連付けられているサブジェクト(WebLogicリソースにアクセスしようとしているサブジェクト)を返します。

- getResource

public Resource getResource()

getResourceメソッドは、認可イベントに関連付けられ、サブジェクトがアクセスしようとしているWebLogicリソースを返します。

これらのコンビニエンス・インタフェースとメソッドの詳細は、Oracle WebLogic Server APIリファレンスのAuditAtzEventインタフェースまたはAuditPolicyEventインタフェースを参照してください。

AuditMgmtEventインタフェース

AuditMgmtEventは、監査チャネルが拡張セキュリティ管理イベント・タイプ・オブジェクトのインスタンス・タイプ(セキュリティ・プロバイダのMBeanなど)を判断するのに役立つコンビニエンス・インタフェースです。このインタフェースには実装する必要があるメソッドは含まれていませんが、監査イベント実装のベスト・プラクティス構造が保持されています。

注意:

MBeanの詳細は、「セキュリティ・サービス・プロバイダ・インタフェース(SSPI) MBean」を参照してください。

AuditMgmtEventコンビニエンス・インタフェースの詳細は、Oracle WebLogic Server APIリファレンスを参照してください。

AuditRoleEventおよびAuditRoleDeploymentEventインタフェース

AuditRoleDeploymentEventおよびAuditRoleEventコンビニエンス・インタフェースは、監査チャネルが拡張ロール・マッピング・イベント・タイプ・オブジェクトのインスタンス・タイプを判断するのに役立ちます。このインタフェースには実装する必要があるメソッドは含まれていませんが、監査イベント実装のベスト・プラクティス構造が保持されています。

注意:

AuditRoleEventコンビニエンス・インタフェースとAuditRoleDeploymentEventコンビニエンス・インタフェースは、後者がAuditEventインタフェースのみを拡張する点で異なります。(後者はAuditContextインタフェースを拡張しません。)AuditContextインタフェースの詳細は、「監査コンテキスト」を参照してください。

これらのコンビニエンス・インタフェースの詳細は、Oracle WebLogic Server APIリファレンスのAuditRoleEventインタフェースまたはAuditRoleDeploymentEventインタフェースを参照してください。

監査重大度

監査重大度とは、セキュリティ・プロバイダが監査イベントを記録するレベルのことです。構成済みの監査プロバイダが監査リクエストを受け取ると、各監査プロバイダは実行されるイベントの重大度を調べます。イベントの重大度が監査プロバイダの構成に使用されたレベル以上であれば、監査プロバイダはその監査データを記録します。

注意:

監査プロバイダの構成は、WebLogic Server管理コンソールで行います。詳細については、「管理コンソールによるカスタム監査プロバイダの構成」を参照してください。

weblogic.security.spiパッケージに含まれるAuditSeverityクラスは、監査重大度レベルを数値およびテキスト値として、AuditEventオブジェクトを介して監査チャネル(AuditChannel SSPIの実装)に、提供します。重大度の数値はロジックで用いるためのもので、テキスト値は出力用監査記録の作成で用いるためのものです。AuditChannel SSPIとAuditEventオブジェクトの詳細は、「AuditChannel SSPIの実装」および「監査イベントの作成」を参照してください。

監査コンテキスト

一部の監査イベント・コンビニエンス・インタフェースは、実装にコンテキスト情報も含まれていることを示すために、AuditContextインタフェースを拡張します。コンテキスト情報は、監査チャネルによって使用されます。詳細については、「監査チャネル」および「AuditChannel SSPIの実装」を参照してください。

AuditContextインタフェースには以下のメソッドがあります。

- getContext

public ContextHandler getContext()

getContextメソッドは、ContextHandlerオブジェクトを返します。ランタイム・クラス(AuditChannel SSPIの実装)は、このオブジェクトから追加の監査情報を取得します。ContextHandlerの詳細は、「ContextHandlerとWebLogicリソース」を参照してください。

例: AuditRoleEventインタフェースの実装

例12-1に、MyAuditRoleEventImpl.javaクラスを示します。これは、監査イベント・コンビニエンス・インタフェース(ここではAuditRoleEventコンビニエンス・インタフェース)の実装例です。このクラスには以下の実装が含まれています。

- getEventType、getFailureException、getSeverity、およびtoStringというAuditEvent SSPIから継承された4つのメソッド(「AuditEvent SSPIの実装」を参照)

- ContextHandlerを介してコンテキストについての補足情報を返すgetContextという1つの追加メソッド(ContextHandlerの詳細については、「ContextHandlerとWebLogicリソース」を参照してください)。

注意:

例12-1の太字のコードは、クラス宣言とメソッド・シグネチャを示しています。

例12-1 MyAuditRoleEventImpl.java

package mypackage;
import javax.security.auth.Subject;
import weblogic.security.SubjectUtils;
import weblogic.security.service.ContextHandler;
import weblogic.security.spi.AuditRoleEvent;
import weblogic.security.spi.AuditSeverity;
import weblogic.security.spi.Resource;
/*package*/ class MyAuditRoleEventImpl implements AuditRoleEvent
{
private Subject subject;
private Resource resource;
private ContextHandler context;
private String details;
private Exception failureException;
/*package*/ MyAuditRoleEventImpl(Subject subject, Resource resource,
ContextHandler context, String details, Exception
failureException) {
this.subject = subject;
this.resource = resource;
this.context = context;
this.details = details;
this.failureException = failureException;
}
public Exception getFailureException()
{
return failureException;
}
public AuditSeverity getSeverity()
{
return (failureException == null) ? AuditSeverity.SUCCESS :
AuditSeverity.FAILURE;
}
public String getEventType()
{
return "MyAuditRoleEventType";
}
public ContextHandler getContext()
{
return context;
}
public String toString()
{
StringBuffer buf = new StringBuffer();
buf.append("EventType:" + getEventType() + "\n");
buf.append("\tSeverity: " +
getSeverity().getSeverityString());
buf.append("\tSubject: " +
SubjectUtils.displaySubject(getSubject());
buf.append("\tResource: " + resource.toString());
buf.append("\tDetails: " + details);
if (getFailureException() != null) {
buf.append("\n\tFailureException:" +
getFailureException());
}
return buf.toString();
}
}

監査サービスの取得、および取得した監査サービスによる監査イベントの書込み

カスタム・セキュリティ・プロバイダから監査サービスを取得および使用して監査イベントを書き込むには、次の手順に従います。

1. getAuditorServiceメソッドを使用して監査サービスを返します。

注意:

SecurityServicesオブジェクトはinitializeメソッドの一部としてセキュリティ・プロバイダの「Provider」SSPIの実装に渡されることに注意します。(詳細は、「Provider」SSPIの目的について」を参照してください) AuditorServiceオブジェクトは、監査プロバイダが構成されている場合にのみ返されます。

2. 「AuditEvent SSPIの実装」で作成した監査イベントをインスタンス化し、AuditService.providerAuditWriteEventメソッドを介して監査サービスに送ります。

例:監査サービスを取得および使用してロール監査イベントの書込み

例12-2に、カスタム・ロール・マッピング・プロバイダのランタイム・クラス(MyRoleMapperProviderImpl.java)が監査サービスを取得し、そのサービスを使用して監査イベントを書き込む例を示します。

注意:

MyRoleMapperProviderImpl.javaクラスは、例12-1のMyAuditRoleEventImpl.javaクラスに依存します。

例12-2 MyRoleMapperProviderImpl.java

package mypackage;
import javax.security.auth.Subject;
import weblogic.management.security.ProviderMBean;
import weblogic.security.SubjectUtils;
import weblogic.security.service.ContextHandler;
import weblogic.security.spi.AuditorService;
import weblogic.security.spi.RoleMapper;
import weblogic.security.spi.RoleProvider;
import weblogic.security.spi.Resource;
import weblogic.security.spi.SecurityServices;
public final class MyRoleMapperProviderImpl implements RoleProvider, RoleMapper
{
private AuditorService auditor;
public void initialize(ProviderMBean mbean, SecurityServices
services)
{
auditor = services.getAuditorService();
...
}
public Map getRoles(Subject subject, Resource resource,
ContextHandler handler)
{
...
if (auditor != null)
{
auditor.providerAuditWriteEvent(
new MyRoleEventImpl(subject, resource, context,
"why logging this event",
null);                // no exception occurred
}
...
}
}

プロバイダのMBeanから管理操作の監査

SecurityServicesオブジェクトはinitializeメソッドの一部としてセキュリティ・プロバイダの「Provider」SSPIの実装に渡されます。(詳細については、「Provider」SSPIの目的について」を参照してください)プロバイダは、このオブジェクトの監査プロバイダを使用して、ユーザーが正常にログインした場合などにプロバイダ固有のセキュリティ・イベントを監査できます。

セキュリティ・プロバイダのMBean実装には、SecurityServicesオブジェクトは渡されません。ただし、プロバイダは、作成中のユーザーなど、そのMBean操作を監査しなければならない場合があります。

これに対処するために、プロバイダの実行時実装でSecurityServicesオブジェクトをキャッシュし、プロバイダ固有のメカニズムを使用してそのキャッシュをプロバイダのMBean実装に渡すことができます。これにより、プロバイダでそのMBean操作を監査できます。

このタスクの実行方法の例が、Manageable Sample Authentication Providerに示されています。サンプル・プロバイダには、主に次の3つの実装クラスが含まれています。

- ManageableSampleAuthenticationProviderImplには、セキュリティ実行時実装が含まれます。

- ManageableSampleAuthenticatorImplには、MBean実装が含まれます。

- UserGroupDatabaseは、ManageableSampleAuthenticationProviderImplおよびManageableSampleAuthenticatorImplで使用するヘルパー・クラス。

次に、SecurityServicesオブジェクトをキャッシュおよび取得するコード・フローを示します。

1. ManageableSampleAuthenticationProviderImplのinitializeメソッドには、SecurityServicesオブジェクトが渡されます。

2. initializeメソッドは、UserGroupDataBaseオブジェクトを作成し、そのUserGroupDataBaseオブジェクトにSecurityServicesオブジェクトを渡します。

3. UserGroupDataBaseObjectは、SecurityServicesオブジェクトをキャッシュします。また、initializeメソッドは、レルムの名前をルックアップ・キーとして使用し、UserGroupDatabaseオブジェクトをハッシュ表に挿入します。

4. ManageableSampleAuhenticatorImplのinitメソッドは、そのMBeanからレルム名を検索します。

5. initメソッドは、レルム名を使用して、対応するUserGroupDataBaseオブジェクトをハッシュ表から検索します。

6. initメソッドは、UserGroupDatabaseオブジェクトからSecurityServicesオブジェクトを取得し、その監査プロバイダを使用して「createUser」などの管理操作を監査します。

注意:

プロバイダの実行時実装は、サーバーの起動時に、プロバイダがデフォルト・レルムの一部である場合にのみ初期化されます。したがって、サーバーの起動時にプロバイダがデフォルト・レルム内にない場合、その実行時実装は初期化されず、プロバイダのMBean実装は、SecurityServicesオブジェクトへのアクセスを取得できません。つまり、サーバーの起動時にプロバイダがデフォルト・レルム内にない場合、プロバイダは、そのMBean操作を監査できません。

例:プロバイダのMBeanから管理操作の監査

例12-3では、ManageableSampleAuhenticatorImplのinitメソッドが、MBeanからレルム名を検索する方法、レルム名を使用して対応するUserGroupDataBaseオブジェクトを(UserGroupDatabaseヘルパー・クラスを介して)ハッシュ表から検索する方法、およびUserGroupDatabaseオブジェクトからSecurityServicesオブジェクトを取得する方法を示します。

また、例12-3では、ManageableSampleAuhenticatorImplがその監査プロバイダを使用してcreateUserなどの管理操作を監査する方法も示します。

例12-3 ManageableSampleAuthenticatorImpl.java

package examples.security.providers.authentication.manageable;
import java.util.Enumeration;
import javax.management.MBeanException;
import javax.management.modelmbean.ModelMBean;
import weblogic.management.security.authentication.AuthenticatorImpl;
import weblogic.management.utils.AlreadyExistsException;
import weblogic.management.utils.InvalidCursorException;
import weblogic.management.utils.NotFoundException;
import weblogic.security.spi.AuditorService;
import weblogic.security.spi.SecurityServices;

public class ManageableSampleAuthenticatorImpl extends AuthenticatorImpl
{
// Manages the user and group definitions for this provider:
private UserGroupDatabase database;

// Manages active queries (see listUsers, listGroups, listMemberGroups):
private ListManager listManager = new ListManager();

// The name of the realm containing this provider:
private String realm;

// The name of this provider:
private String provider;

// The auditor for auditing user/group management operations.
// This is only available if this provider was configured in
// the default realm when the server was booted.
private AuditorService auditor;

public ManageableSampleAuthenticatorImpl(ModelMBean base) throws MBeanException
{
super(base);
}

private synchronized void init() throws MBeanException
{
if (database == null) {
try {
ManageableSampleAuthenticatorMBean myMBean = (ManageableSampleAuthenticatorMBean)getProxy();
database = UserGroupDatabase.getDatabase(myMBean);
realm    = myMBean.getRealm().getName();
provider = myMBean.getName();
SecurityServices services = database.getSecurityServices();
auditor = (services != null) ? services.getAuditorService() : null;
}
catch(Exception e) {
throw new MBeanException(e, "SampleAuthenticatorImpl.init failed");
}
}
}
...
public void createUser(String user, String password, String description)
throws MBeanException, AlreadyExistsException
{
init();
String details = (auditor != null) ?
"createUser(user = " + user + ", password = " + password + ",
description = " + description + ")" : null;
try {
// we don't support descriptions so just ignore it
database.checkDoesntExist(user);
database.getUser(user).create(password);
database.updatePersistentState();
auditOperationSucceeded(details);
}
catch (AlreadyExistsException   e) { auditOperationFailed(details, e); throw e; }
catch (IllegalArgumentException e) { auditOperationFailed(details, e); throw e; }
}
...
private void auditOperationSucceeded(String details)
{
if (auditor != null) {
auditor.providerAuditWriteEvent(
new ManageableSampleAuthenticatorManagementEvent(realm, provider, details, null)
);
}
}
...
private void auditOperationFailed(String details, Exception failureException)
{
if (auditor != null) {

auditor.providerAuditWriteEvent(
new ManageableSampleAuthenticatorManagementEvent(realm, provider, details, failureException)
);
}
}
}

ベスト・プラクティス:プロバイダのMBeanからの監査イベントのポスト

プロバイダの管理操作で書込み(ユーザーの作成、ユーザーの削除、データの削除など)を行うものは、操作が成功するかどうかに関係なく、監査イベントをポストする必要があります。

プロバイダがMBean操作を監査する場合は、常に以下のベスト・プラクティス・ガイドラインに留意してください。

- 書込み操作が成功した場合は、INFORMATION監査イベントをポストします。

- パラメータが不正(ユーザーがすでに存在する、インポート・フォーマット名が不正、ファイル名が存在しない、ファイル・フォーマットが不正など)という理由で書込み操作が失敗した場合は、監査イベントをポストしないようにします。

- エラー(LDAPException、RuntimeExceptionなど)のために書込み操作が失敗した場合は、FAILURE監査イベントをポストします。

- インポート操作は部分的に成功できます。たとえば、一部のユーザーがインポートされたものの、プロバイダ内にすでに名前を持つその他のユーザーがスキップされる場合などです。

- スキップしたデータがプロバイダ内のデータと同じであることが簡単に検出できる場合(たとえば、ユーザー名、説明、パスワードなどが同じ場合など)、WARNINGイベントをポストすることを考慮します。

- 一部に衝突があったためにデータをスキップする場合(たとえば、ユーザー名は同じだが、パスワードが異なっている場合など)、FAILUREイベントをポストする必要があります。

- プロバイダに格納されているデータとインポート・データを区別できない場合は、FAILUREイベントをポストします。

13 サーブレット認証フィルタ

この章では、サーブレット認証フィルタ・インタフェースの概念と機能、およびサーブレット認証フィルタの開発手順について説明します。

サーブレット認証フィルタは、IDアサーションなどの認証機能のための前処理および後処理を実行するプロバイダです。サーブレット検証フィルタは、主に認証プロバイダの「ヘルパー」として機能する特殊なセキュリティ・プロバイダです。

ServletAuthenticationFilterインタフェースは、WebLogic Serverにプラグインできる認証フィルタに対してセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を定義します。認証プロセスでサーブレット・コンテナに呼び出させる認証フィルタが認証プロバイダにあることを通知するために、ServletAuthenticationFilterインタフェースを認証プロバイダの一部として実装します。通常、このインタフェースは認証プロバイダのIDアサーション形式の一部として実装されます。

以下の節では、サーブレット認証フィルタ・インタフェースの概念と機能、およびサーブレット認証フィルタの開発手順について説明します。

- 認証フィルタの概念

- フィルタが呼び出されるしくみ

- フィルタを実装するプロバイダの例

- カスタム・サーブレット認証フィルタの開発方法

認証フィルタの概念

JavaサーブレットAPI 2.3仕様で定義されているように、フィルタは、リクエストがサーブレットに届く前のプリプロセッサ、またはサーブレットから離れたレスポンスのポストプロセッサです。フィルタを使用すると、再利用可能なユニットで反復タスクをカプセル化し、サーブレットまたはJSPページからのレスポンスを変換できます。

サーブレット認証フィルタは、コンテナ・ベースの認証をフィルタが置換または拡張できるようにするフィルタ・オブジェクトの拡張機能です。

フィルタが必要な理由

WebLogicセキュリティ・フレームワークを使用すると、カスタム認証プロバイダを利用できます。ただし、JavaサーブレットAPI 2.3の仕様により、認証プロセス時は、認証プロバイダとクライアントまたは他のサーバーとの間の対話は制限されます。これにより、認証メカニズムは、サーブレット・コンテナが提供する認証メカニズムと互換性のある基本、フォーム、証明書の形式に制限されます。

フィルタには、アーキテクチャ依存の制限はほとんどありません。つまり、サーブレット認証フィルタは、サーブレット・コンテナが提供する認証メカニズムに依存していません。認証プロセスを開始するコンテナの前にフィルタを呼び出せるようにすれば、セキュリティ・レルムは、より柔軟な認証メカニズムを実装できます。たとえば、サーブレット認証フィルタを使用すると、認証用のSAMLプロバイダ・サイトにユーザーをリダイレクトできます。

WebLogic認証プロバイダ内のJAAS LoginModuleは、ログイン・プロセスのカスタマイズに使用できます。ユーザー・データベースの場所のカスタマイズ、ログインの実行に必要な証明データの種類、サブジェクトへのグループの指定は、LoginModuleを介して実装されます。

一方、ログインを実行するためのリモート・サイトへのリダイレクト、問合せ文字列からのログイン情報の抽出、ブラウザとのログイン機能のネゴシエーションは、サーブレット認証フィルタを介して実装されます。

サーブレット認証フィルタ設計上の考慮事項

サーブレット認証フィルタを設計する際には、以下の事項を考慮する必要があります。

- 複数のフィルタを指定可能にする必要がありますか?複数のフィルタを指定可能にすると、構成時に管理上の決定を行うことができるようになります。

- 特定の実行順序に依存していますか?サーブレット認証フィルタは、フィルタの実行順序に依存しないようにしてください。

- 各フィルタが認証の前後にリクエストを処理できるようにすることを検討しましたか?その場合、フィルタで呼出しのタイミングを予測しないようにしてください。

- フィルタのdoFilterメソッドを呼び出さないことで、残りのフィルタの実行およびサーブレットの認証プロセスを停止できるようにする選択肢を各フィルタに与えることを検討します。

- フィルタでブラウザをリダイレクトできるようにする必要がありますか?

- フィルタが一方向SSL、双方向SSL、IDアサーション、フォーム認証、および基本認証で機能するようにすることを検討します。たとえば、フォーム認証は双方向のリクエスト・プロセスで、フィルタはフォーム認証用に2回呼び出されます。

フィルタが呼び出されるしくみ

サーブレット認証フィルタ・インタフェースを使用すると、認証プロバイダは0個以上のサーブレット認証フィルタ・クラスを実装できます。フィルタは以下の手順で呼び出されます。

1. 認証が発生する前に、サーブレット・コンテナがサーブレット認証フィルタを呼び出します。
サーブレット・コンテナが、サーブレット認証フィルタの構成済みチェーンをWebLogicセキュリティ・フレームワークから取得します。

セキュリティ・フレームワークは、認証プロバイダの順序に従ってサーブレット認証フィルタを返します。1つのプロバイダに複数のサーブレット認証フィルタがある場合、セキュリティ・フレームワークは、ServletAuthenticationFilterのgetAuthenticationFiltersメソッドで返されたjavax.servlet.Filterの順序付けされたリストを使用します。

場合によっては、リクエストを適切に処理するために複数回実行する必要もあるので、フィルタが重複していてもかまいません。

2. サーブレット・コンテナは、フィルタのinitメソッドをフィルタごとに呼び出し、フィルタがサービス内に適切に配置されるようにします。

3. チェーンの最後にあるリソースに対するクライアント・リクエストがあるため、リクエスト/レスポンスのペアがチェーン内を通るたびに、サーブレット・コンテナは、最初のフィルタに対してフィルタのdoFilterメソッドを呼び出します。
このメソッドに渡されるFilterChainオブジェクトを使用すると、フィルタは、リクエストとレスポンスをチェーン内の次のエンティティに渡すことができます。フィルタは、FilterChainオブジェクトを使用して、チェーン内の次のフィルタを呼び出します。または、フィルタの呼出しがチェーン内の最後のフィルタの場合、チェーンの最後のリソースを呼び出します。

4. すべてのサーブレット認証フィルタがフィルタのdoFilterメソッドを呼び出す場合、最後のサーブレット認証フィルタがdoFilterメソッドを呼び出すと、サーブレット・コンテナは、フィルタが存在しない場合と同じように認証を実行します。
ただし、サーブレット認証フィルタがdoFilterメソッドを呼び出さない場合、残りのフィルタ、サーブレット、およびサーブレット・コンテナの認証手順は呼び出されません。これにより、フィルタは、サーブレットの認証プロセスを置き換えることができます。通常、これには認証の失敗か、別の認証用URLへのリダイレクトが伴います。

認証プロバイダからサーブレット認証フィルタを呼び出さない

サーブレット認証フィルタ・インタフェースを認証プロバイダの一部として実装しても、認証プロバイダは、サーブレット認証フィルタを直接呼び出すわけではありません。サーブレット認証フィルタの実装は、フィルタを配置して呼び出す方法を認識するWebLogicセキュリティ・フレームワークの特定の機能に依存します。

カスタム・サーブレット認証フィルタを開発する場合は、カスタム認証プロバイダがWLS固有のクラス(weblogic.servlet.*など)およびJava EE固有のクラス(javax.servlet.*など)を呼び出さないようにしてください。このルールに従うと、WebLogicセキュリティのポータビリティが最大限に高まります。

図13-1にこの要件を示します。

図13-1 認証プロバイダがサーブレット認証フィルタを呼び出さない

「図13-1 認証プロバイダがサーブレット認証フィルタを呼び出さない」の説明

フィルタを実装するプロバイダの例

WebLogic Serverには、SPNEGO (Simple and Protected Negotiate)に必要なヘッダー操作を処理するサーブレット認証フィルタが含まれます。「ネゴシエーション・サーブレット認証フィルタ」と呼ばれるこのサーブレット認証フィルタは、WWW-AuthenticateヘッダーおよびAuthorization HTTPヘッダーをサポートするように構成されています。

ネゴシエーション・サーブレット認証フィルタは、ネゴシエート・プロトコルの認可されていないレスポンスに対して適切なWWW-Authenticateヘッダーを生成し、以降のリクエストに対してAuthorizationヘッダーを処理します。このフィルタは、ネゴシエーションIDアサーション・プロバイダを介して使用できます。

デフォルトでは、ネゴシエーションIDアサーション・プロバイダは使用可能ですが、WebLogicデフォルト・セキュリティ・レルムには構成されていません。ネゴシエーションIDアサーション・プロバイダは、WebLogic IDアサーション・プロバイダのかわりとして使用したり、WebLogic IDアサーション・プロバイダと併用したりできます。

カスタム・サーブレット認証フィルタの開発方法

カスタム・サーブレット認証フィルタを開発するには、以下の手順に従います。

1. 適切なSSPIによるランタイム・クラスの作成

2. WebLogic MBeanMakerを使用してMBeanタイプを生成する

3. 管理コンソールによる認証プロバイダの構成

適切なSSPIによるランタイム・クラスの作成

ランタイム・クラスを作成する前に、以下の作業が必要です。

- 「Provider」SSPIの目的について

- SSPI階層を理解し、ランタイム・クラスを1つ作成するか2つ作成するかを決定する

この情報を理解し、設計に関する判断を下したら、次の手順でサーブレット認証フィルタのランタイム・クラスを作成します。

- AuthenticationProviderV2 SSPIの実装またはIdentityAsserterV2 SSPIの実装

- サーブレット認証フィルタSSPIの実装

- フィルタ・インタフェース・メソッドの実装

カスタム・サーブレット認証フィルタ・プロバイダのランタイム・クラスの作成例については、「WebLogic MBeanMakerを使用してMBeanタイプを生成する」を参照してください。

サーブレット認証フィルタSSPIの実装

認証プロセスでサーブレット・コンテナに呼び出させる認証フィルタが認証プロバイダにあることを通知するために、ServletAuthenticationFilterインタフェースを認証プロバイダの一部として実装します。

サーブレット認証フィルタSSPIを実装する際には、以下のメソッドの実装を提供する必要があります。

- サーブレット認証フィルタの取得

public Filter[] getServletAuthenticationFilters

getServletAuthenticationFiltersメソッドは、サーブレット・コンテナの認証プロセスで実行されるjavax.servlet.Filterの順序付けられたリストを返します。コンテナは、サーブレット認証フィルタの複数のインスタンスを取得するために、このメソッドを複数回呼び出すことがあります。このメソッドは、呼出しごとに、フィルタの新しいインスタンスのリストを返す必要があります。

フィルタ・インタフェース・メソッドの実装

フィルタ・インタフェース・メソッドを実装するには、以下のメソッドの実装を提供する必要があります。通常は、init()を1回呼び出し、doFilter()を必要に応じた回数呼び出してから、destroy()を1回呼び出します。

- destroy

public void destroy()

destroyメソッドは、フィルタをサービスから取り除くよう指示するためにWebコンテナによって呼び出されます。このメソッドは、フィルタのdoFilterメソッド内のすべてのスレッドが終了した場合、またはタイムアウト期間が過ぎた場合にのみ呼び出されます。Webコンテナは、このメソッドを呼び出した後に、フィルタのこのインスタンスに対して再びdoFilterメソッドを呼び出しません。

このメソッドを使用すると、フィルタで保持されているリソース(メモリー、ファイル・ハンドル、スレッドなど)をクリーンアップし、永続的な状態をメモリー内のフィルタの現在の状態と同期させることができます。

- doFilter

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)

チェーンの最後にあるリソースに対するクライアント・リクエストがあるため、リクエスト/レスポンスのペアがチェーン内を通るたびに、フィルタのdoFilterメソッドがコンテナによって呼び出されます。このメソッドに渡されるFilterChainを使用すると、フィルタは、リクエストとレスポンスをチェーン内の次のエンティティに渡すことができます。

通常、このメソッドの実装は以下のパターンに従います。

1.リクエストを調べます。

2.必要に応じてカスタム実装でリクエスト・オブジェクトをラップし、入力フィルタ用に内容とヘッダーをフィルタ処理します。

3.必要に応じてカスタム実装でレスポンス・オブジェクトをラップし、出力フィルタ用に内容とヘッダーをフィルタ処理します。

4. FilterChainオブジェクトを使用してチェーン内の次のエンティティを呼び出すか(chain.doFilter())、フィルタ・チェーン内の次のエンティティにリクエスト/レスポンスのペアを渡さずにリクエストの処理をブロックします。

5.フィルタ・チェーン内の次のエンティティの呼出し後に、レスポンスのヘッダーを直接設定します。

- init

public void init(FilterConfig filterConfig)

initメソッドは、フィルタをサービス内に配置するよう指示するためにWebコンテナによって呼び出されます。サーブレット・コンテナは、フィルタのインスタンス化の後でinitメソッドを一度のみ呼び出します。initメソッドは、フィルタ処理をフィルタに指示する前に正常に完了している必要があります。

フィルタからのチャレンジIDアサーションの実装

第5章「IDアサーション・プロバイダ」で説明したとおり、チャレンジIDアサーション・インタフェースは、複数のチャレンジ、レスポンス・メッセージ、および状態を必要とするチャレンジ・レスポンス・スキームをサポートします。チャレンジIDアサーション・プロバイダ・インタフェースを使用すると、IDアサーション・プロバイダは、MicrosoftのWindows NTチャレンジ/レスポンス(NTLM)やSPNEGO (Simple and Protected GSS-API Negotiation)などのチャレンジ/レスポンス認証メカニズムを採用した認証プロトコルをサポートできます。

サーブレット認証フィルタを使用すると、サーブレット・コンテナと互換性のある認証メカニズムに制限されることなくチャレンジ/レスポンス・プロトコルを実装できます。ただし、サーブレット認証フィルタは、セキュリティ・フレームワークで提供されている認証環境の外側で機能するので、セキュリティ・フレームワークを利用してプロバイダのコンテキストを判別することはできません。また、サーブレット認証フィルタでは、APIでチャレンジ回数が複数のIDアサーション・プロセスを駆動させる必要があります。

weblogic.security.services.Authenticationクラスが拡張され、サーブレット認証フィルタからの複数のチャレンジ/レスポンスIDアサーションが可能になりました。メソッドおよびインタフェースでは、ChallengeIdentityAsserterV2 SSPIインタフェースとProviderChallengeContext SSPIインタフェースのラッパーが提供されるので、サーブレット認証フィルタから呼び出すことができます。

これ以外に、セキュリティ・フレームワークのコンテキスト内でサーブレット認証フィルタから複数のチャレンジ/レスポンス・ダイアログを実行する方法はドキュメント化されていません。サーブレット認証フィルタは、ChallengeIdentityAsserterV2インタフェースおよびProviderChallengeContextインタフェースを直接呼び出すことはできません。

したがって、複数のチャレンジ/レスポンスIDアサーションをフィルタから実装する場合、ChallengeIdentityAsserterV2インタフェースとProviderChallengeContextインタフェースを実装してから、weblogic.security.services.AuthenticationメソッドとAppChallengeContectインタフェースを使用して、サーブレット認証フィルタから目的のフィルタを呼び出す必要があります。

このプロセスを行う手順については、第5章「IDアサーション・プロバイダ」で説明されています。ここでは、概要を示します。

- AuthenticationProviderV2 SSPIの実装、または IdentityAsserterV2 SSPIの実装

- ChallengeIdentityAsserterV2インタフェースの実装

- ProviderChallengeContextインタフェースの実装

- weblogic.security.servicesのチャレンジIDメソッドの呼出し

- weblogic.security.servicesのAppChallengeContextメソッドの呼出し

WebLogic MBeanMakerを使用してMBeanタイプを生成する

第4章「認証プロバイダ」の説明に従ってカスタム認証プロバイダのMBeanタイプを生成する際には、使用しているサーブレット認証フィルタのMBeanも実装する必要があります。

ServletAuthenticationFilter MBeanはAuthenticationProvider MBeanを拡張します。ServletAuthenticationFilter MBeanはマーカー・インタフェースなので、メソッドはありません。

<?xml version="1.0" ?>
<!DOCTYPE MBeanType SYSTEM "commo.dtd">
<MBeanType

Name          = "ServletAuthenticationFilter"
Package       = "weblogic.management.security.authentication"
Extends       = "weblogic.management.security.authentication.AuthenticationProvider"
PersistPolicy = "OnUpdate"
Abstract      = "true"
Description   = "The SSPI MBean that all Servlet Authentication   Filter providers must extend.
This MBean is just a marker interface.  It has no methods on it."
>
</MBeanType>

WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

WebLogic MBeanMakerを使用してMDFを実行して中間ファイルを生成し、MBean実装ファイルを編集して適切なメソッドの実装を提供したら、サーブレット認証フィルタを含むカスタム認証プロバイダのMBeanファイルとランタイム・クラスをMBean JARファイル(MJF)にパッケージ化する必要があります。

カスタム認証プロバイダの場合、この手順は、「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」で説明します。

管理コンソールによる認証プロバイダの構成

サーブレット認証フィルタを実装するカスタム認証プロバイダを構成するということは、そのカスタム認証プロバイダをセキュリティ・レルムに追加するということです。追加されたカスタム認証プロバイダには、認証サービスを必要とするアプリケーションからアクセスできます。

カスタム・セキュリティ・プロバイダの構成は管理タスクですが、カスタム・セキュリティ・プロバイダの開発者が行うこともできます。

WebLogic Server管理コンソールを使用してカスタム認可プロバイダを構成する手順は、『Oracle WebLogic Serverの保護』のWebLogicセキュリティ・プロバイダの構成に関する項で説明されています。

14 バージョン管理可能なアプリケーションのプロバイダ

この章では、カスタム・セキュリティ・プロバイダにアプリケーションのバージョン管理機能を追加する前に理解しておく必要がある基本情報と、カスタム・セキュリティ・プロバイダにアプリケーションのバージョン管理機能を追加する手順について説明します。

バージョン管理可能なアプリケーションは、アプリケーション・アーカイブ(EARファイル)のマニフェスト内で指定されているアプリケーション・アーカイブのバージョンを持つアプリケーションです。バージョン管理可能なアプリケーションはサイドバイサイドでデプロイでき、同時にアクティブにすることが可能です。バージョン管理可能なアプリケーションを使用すると、アプリケーションの複数のバージョンを利用できます。各バージョンには、個別のセキュリティ制約を設定できます。

バージョン管理可能なアプリケーションのプロバイダSSPIを使用すると、バージョンが作成および削除されたときに、アプリケーションのバージョン管理をサポートするすべてのセキュリティ・プロバイダに通知できます。また、バージョンが1つしかないアプリケーションが削除された場合にも、アプリケーションのバージョン管理をサポートするすべてのセキュリティ・プロバイダに通知できます。

以下の節では、カスタム・セキュリティ・プロバイダにバージョン管理機能を追加する前に理解しておく必要がある基本情報と、カスタム・セキュリティ・プロバイダにバージョン管理機能を追加する手順について説明します。

- バージョン管理可能なアプリケーションの概念

- バージョン管理可能なアプリケーションのプロセス

- バージョン管理可能なアプリケーションのカスタム・プロバイダを開発する必要があるか

- カスタムVersionableApplicationプロバイダの開発方法

バージョン管理可能なアプリケーションの概念

バージョン管理可能なアプリケーションの再デプロイメントは、以降の再デプロイメントで同じアーカイブ・バージョンが指定されている場合を除き、必ずサイドバイサイド・バージョンを介して行われます。ただし、バージョン管理可能なアプリケーションは、複数のバージョンが競合することなく並列的に実行できるように作成する必要があります。つまり、バージョン管理可能なアプリケーションは、アプリケーション名などの固有性を想定しないようにする必要があります。たとえば、アプリケーションが、データベース表やLDAPストアなどのグローバル・データ構造の一意のキーとしてアプリケーション名を使用する場合、アプリケーションは、その代わりにアプリケーション識別子を使用するよう変更する必要があります。

本番再デプロイメントは、構成されたセキュリティ・プロバイダがアプリケーション・バージョニング・セキュリティSSPIをサポートしている場合にのみ許可されます。セキュリティ・レルムのすべての認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダは、アプリケーションのデプロイにバージョンを使用するために、アプリケーションのバージョン管理をサポートする必要があります。

アプリケーションでアプリケーション・バージョンを割り当てる方法の詳細は、『Oracle WebLogic Serverアプリケーションの開発』の本番再デプロイメント用アプリケーションの開発に関する項を参照してください。

バージョン管理可能なアプリケーションのプロセス

セキュリティ・プロバイダでアプリケーションのバージョニングをサポートするには、バージョン管理可能なアプリケーションのSSPIを実装する必要があります。WebLogicセキュリティ・フレームワークは、アプリケーションのバージョンが作成および削除されるときに、プロバイダがアプリケーションのバージョンに関連付けられたデータを作成、コピー、または削除するのに必要なアクションを実行できるように、バージョン管理可能なアプリケーションのプロバイダSSPIを呼び出します。実行するアクションは、プロバイダによって異なります。

また、バージョンが1つしかないアプリケーションが削除されたときにも、プロバイダがクリーンアップ・アクションを実行できるように、バージョン管理可能なアプリケーション・プロバイダSSPIが呼び出されます。

WebLogicセキュリティ・フレームワークは、新しいバージョンのアプリケーション識別子とアプリケーション・データのソースとして使用されるバージョンのアプリケーション識別子をバージョン管理可能なアプリケーション・プロバイダに渡します。ソース識別子が指定されなかった場合、アプリケーションの初期バージョンが作成中です。

バージョン管理可能なアプリケーションのカスタム・プロバイダを開発する必要があるか

WebLogic Serverの初期状態のセキュリティ・プロバイダ(認可、ロール・マッピング、および資格証明マッピング・プロバイダ)は、アプリケーション・バージョニングSSPIをサポートしています。新しいバージョンが作成されると、新しいアプリケーションのバージョンを表す新しいリソース識別子でカスタマイズされたすべてのロール、ポリシー、および資格証明マップのクローンが作成されます。さらに、アプリケーションのバージョンが削除されると、削除されたバージョンに関連付けられたリソースが削除されます。

認可、ロール・マッピング、または資格証明マッピング用にカスタム・セキュリティ・プロバイダを開発する際に、バージョン管理されたアプリケーションをサポートする必要がある場合は、バージョン管理可能なアプリケーションのSSPIを実装する必要があります。

カスタムVersionableApplicationプロバイダの開発方法

バージョン管理可能なアプリケーションSSPIをサポートする必要がある場合、次の手順でバージョン管理可能なアプリケーションのカスタム・プロバイダを開発できます。

- カスタム認可、ロール・マッピング、または資格証明マッピング・プロバイダの実装セキュリティ・レルムのすべての認可プロバイダ、ロール・マッピング・プロバイダ、または資格証明マッピング・プロバイダは、アプリケーションのデプロイにバージョンを使用するために、アプリケーションのバージョン管理をサポートする必要があります。

- 適切なSSPIによるランタイム・クラスの作成

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

適切なSSPIによるランタイム・クラスの作成

ランタイム・クラスを作成する前に、以下の作業が必要です。

- 「Provider」SSPIの目的について

- SSPI階層を理解し、ランタイム・クラスを1つ作成するか2つ作成するかを決定する

この情報を理解し、設計に関する判断を下したら、次の手順でバージョン管理可能なアプリケーションのカスタム・プロバイダのランタイム・クラスを作成します。

- カスタム認可、ロール・マッピング、または資格証明マッピング・プロバイダの実装

- VersionableApplication SSPIの実装

VersionableApplication SSPIの実装

VersionableApplication SSPIを実装するには、「「Provider」SSPIの目的について」で説明されているメソッドおよび次のメソッドの実装を提供する必要があります。

- createApplicationVersion

void createApplicationVersion(String appIdentifier, String sourceAppIdentifier)

新しいアプリケーションのバージョンの作成をマークします。バージョンが作成された時点で、WebLogic Serverドメイン内の1つのサーバーで(WebLogic Serverドメイン内の管理サーバーでのみ)呼び出されます。WebLogicセキュリティ・フレームワークは、新しいバージョンのアプリケーション識別子(appIdentifier)とアプリケーション・データのソースとして使用されるバージョンのアプリケーション識別子(sourceAppIdentifier)をcreateApplicationVersionメソッドに渡します。ソース識別子が指定されなかった場合、アプリケーションの初期バージョンが作成中です。

- deleteApplication

void deleteApplication(String appName)

バージョンが1つしかないアプリケーションの削除をマークします。アプリケーションが削除された時点で、WebLogic Serverドメイン内の管理サーバーでのみ呼び出されます。

- deleteApplicationVersion

void deleteApplicationVersion(String appIdentifier)

アプリケーションのバージョンの削除をマークします。バージョンが削除された時点で、WebLogic Serverドメイン内の管理サーバーでのみ呼び出されます。

例:サンプルVersionableApplicationプロバイダのランタイム・クラスの作成

例14-1では、バージョン管理可能なアプリケーションのSSPIがサンプル認可プロバイダでどのように実装されるかを示します。

例14-1 SimpleSampleAuthorizationProviderImpl

public final class SimpleSampleAuthorizationProviderImpl
implements DeployableAuthorizationProviderV2, AccessDecision, VersionableApplicationProvider
:
:
public void createApplicationVersion(String appId, String sourceAppId)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.createApplicationVersion");
System.out.println("\tapplication identifier\t= " + appId);
System.out.println("\tsource app identifier\t= " + ((sourceAppId != null) ? sourceAppId : "None"));
// create new policies when existing application is specified
if (sourceAppId != null) {
database.clonePoliciesForApplication(sourceAppId,appId);
}

public void deleteApplicationVersion(String appId)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.deleteApplicationVersion");
System.out.println("\tapplication identifier\t= " + appId);

// clear out policies for the application
database.removePoliciesForApplication(appId);
}

public void deleteApplication(String appName)
{
System.out.println("SimpleSampleAuthorizationProviderImpl.deleteApplication");
System.out.println("\tapplication name\t= " + appName);

// clear out policies for the application
database.removePoliciesForApplication(appName);
}

WebLogic MBeanMakerを使用してMBeanタイプを生成する

カスタム認可、ロール・マッピング、および資格証明マッピング・プロバイダのMBeanタイプを生成する際には、バージョン管理可能なアプリケーションのプロバイダのMBeanも実装する必要があります。ApplicationVersionerMBeanはマーカー・インタフェースなので、メソッドはありません。

例14-2では、SimpleSampleAuthorizer MBean定義ファイル(MDF)がApplicationVersionerMBean MBeanをどのように実装するかを示します。

例14-2 ApplicationVersionerMBeanを実装する

<MBeanType
Name          = "SimpleSampleAuthorizer"
DisplayName   = "SimpleSampleAuthorizer"
Package       = "examples.security.providers.authorization.simple"
Extends       = "weblogic.management.security.authorization.DeployableAuthorizer"
Implements    = "weblogic.management.security.ApplicationVersioner"
PersistPolicy = "OnUpdate"
>

WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

WebLogic MBeanMakerを使用してMDFを実行して中間ファイルを生成し、MBean実装ファイルを編集して適切なメソッドの実装を提供したら、バージョン管理可能なアプリケーションのプロバイダを含むカスタム認可プロバイダ、ロール・マッピング・プロバイダ、資格証明マッピング・プロバイダのMBeanファイルとランタイム・クラスをMBean JARファイル(MJF)にパッケージ化する必要があります。

カスタム認可プロバイダの場合、この手順は、「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」で説明します。

カスタム・ロール・マッピング・プロバイダの場合、この手順は、「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」で説明します。

カスタム資格証明マッピング・プロバイダの場合、この手順は、「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」で説明します。

管理コンソールによるバージョン管理可能なアプリケーションのカスタム・プロバイダの構成

バージョン管理可能なアプリケーションのカスタム・プロバイダを構成するということは、アプリケーション・バージョン・サービスを必要とするアプリケーションがアクセス可能なセキュリティ・レルムにバージョン管理可能なアプリケーションのカスタム・プロバイダを追加するということです。

カスタム・セキュリティ・プロバイダの構成は管理タスクですが、カスタム・セキュリティ・プロバイダの開発者が行うこともできます。

WebLogic Server管理コンソールを使用してバージョン管理可能なアプリケーションのカスタム・プロバイダを構成する手順は、『Oracle WebLogic Serverの保護』のWebLogicセキュリティ・プロバイダの構成に関する項で説明されています。

15 証明書パス・プロバイダ

この章では、カスタム・セキュリティ・プロバイダに証明書の検索および検証機能を追加する前に理解しておく必要がある基本情報と、カスタム・セキュリティ・プロバイダに証明書の検索および検証機能を追加する手順について説明します。

WebLogicセキュリティ・サービスは、着信双方向SSL、発信SSL、アプリケーション・コード、およびWebLogic Webサービスについて、X509証明書チェーンを検索および検証するフレームワークを提供します。証明書の検索と検証(CLV)フレームワークは、証明書チェーンを検索および検証する新しいセキュリティ・プラグイン・フレームワークです。このフレームワークは、JDK証明書パス機能を拡張および完了し、カスタム証明書パス・プロバイダを作成できるようにします。

以下の節では、カスタム・セキュリティ・プロバイダに証明書の検索および検証機能を追加する前に理解しておく必要がある基本情報と、カスタム・セキュリティ・プロバイダに証明書の検索および検証機能を追加する手順について説明します。

- 証明書の検索と検証の概念

- カスタム証明書パス・プロバイダを開発する必要があるか

- カスタム証明書パス・プロバイダの開発方法

証明書の検索と検証の概念

証明書パスは、メモリー内に証明書チェーンを格納するJDKクラスです。「証明書パス」という用語は、証明書チェーンを検索および検証するためのJDKアーキテクチャおよびフレームワークを指す場合にも使われます。

証明書パス・プロバイダには、証明書パス検証プロバイダと証明書パス・ビルダーの2種類があります。

- 証明書検証プロバイダは、提示された証明書チェーンが有効で信頼できるものかどうかの判別を目的とします。証明書パス検証プロバイダを作成する場合は、証明書チェーンを検証する方法を決定し、信頼性のあるCAを使用する必要があるかどうかを決めます。

- 証明書ビルダーは、証明書パスを検索するための選択基準を保持するセレクタを使用しての証明書チェーンの検索を目的とします。多くの場合、証明書ビルダーは証明書チェーンの検証も行います。証明書パス・ビルダーを作成する場合は、4種類のセレクタのうちどれをサポートするか、および証明書チェーンの検証も行うかどうかを判別します。また、証明書チェーンをどの程度指定するか、および信頼性のあるCAを使用する必要があるかどうかを決めます。

WebLogic証明書パス・プロバイダは、JDKとWebLogic証明書パスSPIの両方を使用して作成します。

証明書の検索と検証のプロセス

証明書の検索と検証のプロセスを図15-1に示します。

図15-1 証明書の検索と検証のプロセス

「図15-1 証明書の検索と検証のプロセス」の説明

証明書パス検証プロバイダと証明書パス・ビルダーを実装する必要があるか

証明書パス・プロバイダはいくつかの方法で実装できます。

- 作成と検証を行う証明書パス・ビルダーを実装できます。この場合は、以下の操作を行います。

1. 検証プロバイダSPIを実装します。

2. ビルダーSPIを実装します。

3. ビルダーSPIの一部として作成する証明書チェーンを検証する必要があります。プロバイダは一度だけ呼び出されます。検証用に改めて呼び出す必要はありません。

4. 検証アルゴリズムとして何を使用するか、どのセレクタをサポートするか、および信頼性のあるCAを使用するかどうかを指定します。

- 検証のみを行う証明書パス検証プロバイダを実装できます。この場合は、以下の操作を行います。

1. 検証プロバイダSPIを実装します。

2. 検証アルゴリズムとして何を使用するか、および信頼性のあるCAを使用するかどうかを指定します。

- 作成のみを行う証明書パス・ビルダーを実装できます。この場合は、以下の操作を行います。

1. ビルダーSPIを実装します。

2. 作成した証明書チェーンを検証するかどうかを指定します。

3. どのセレクタをサポートするか、および信頼性のあるCAを使用するかどうかを指定します。

証明書パス・プロバイダSPI MBean

WebLogic Serverには、以下の2種類の証明書パス・プロバイダSPI MBeanがあります。いずれもCertPathProviderMBeanの拡張です。

- CertPathBuilderMBeanは、プロバイダが証明書チェーンを検索できることを示します。追加の属性またはメソッドはありません。CertPathBuilderプロバイダは、このMBeanを拡張するカスタムMBeanを実装する必要があります。

- CertPathValidatorMBeanは、プロバイダが証明書チェーンを検証できることを示します。追加の属性またはメソッドはありません。CertPathValidatorプロバイダは、このMBeanを拡張するカスタムMBeanを実装する必要があります。

証明書パス・プロバイダは、その種類によって、MBeanのいずれか1つまたは両方を拡張する必要があります。作成と検証の両方をサポートするセキュリティ・プロバイダは、例15-1で示すように、両方のMBeanを拡張するMBeanを作成する必要があります。

例15-1 サンプル証明書パスMBean MDF

<?xml version="1.0" ?>
<!DOCTYPE MBeanType SYSTEM "commo.dtd">

<MBeanType
Name          = "MyCertPathProvider"
DisplayName   = "MyCertPathProvider"
Package       = "com.acme"
Extends       = "weblogic.management.security.pk.CertPathBuilder"
Implements    = "weblogic.management.security.pk.CertPathValidator"
PersistPolicy = "OnUpdate"
>
<MBeanAttribute
Name          = "ProviderClassName"
Type          = "java.lang.String"
Writeable     = "false"
Default       = "&quot;com.acme.MyCertPathProviderRuntimeImpl&quot;"
/>

<MBeanAttribute
Name          = "Description"
Type          = "java.lang.String"
Writeable     = "false"
Default       = "&quot;My CertPath Provider&quot;"
/>

<MBeanAttribute
Name          = "Version"
Type          = "java.lang.String"
Writeable     = "false"
Default       = "&quot;1.0&quot;"
/>

<!-- add custom attributes for the configuration data needed by this provider -->
<MBeanAttribute
Name          = "CustomConfigData"
Type          = "java.lang.String"
/>

WebLogic証明書パス検証プロバイダSSPI

WebLogic証明書パス検証プロバイダSSPIは、以下の4つの部分で構成されています。

- 「証明書パス・プロバイダSPI MBean」で説明されているMBean SSPI

- 「JDK CertPathBuilderSpiインタフェース、CertPathValidatorSpiインタフェースのいずれか、または両方の実装」で説明されているJDK CertPathValidatorSPIインタフェース

- 「証明書パス・プロバイダSSPIの実装」で説明されているWebLogic Server CertPathProvider SSPIインタフェース

- 「JDKセキュリティ・プロバイダSPIの実装」で説明されている、JDKにCertPathValidatorSPI実装を登録するJDKセキュリティprovider

WebLogic証明書パス・ビルダーSSPI

WebLogic証明書パス・ビルダーSSPIは、以下の4つの部分で構成されています。

- 「証明書パス・プロバイダSPI MBean」で説明されているMBean SSPI

- 「JDK CertPathBuilderSpiインタフェース、CertPathValidatorSpiインタフェースのいずれか、または両方の実装」で説明されているJDK CertPathBuilderSPIインタフェース

- 「証明書パス・プロバイダSSPIの実装」で説明されているWebLogic Server CertPathProvider SSPIインタフェース

- 「JDKセキュリティ・プロバイダSPIの実装」で説明されている、JDKにCertPathBuilderSPIを登録するJDKセキュリティprovider

WebLogic Server証明書パスSSPIとJDK SPIとの関係

WebLogicセキュリティ・フレームワーク・プロバイダとは異なり、証明書パス・プロバイダの現在の実装は、WebLogicインタフェースおよびJDKインタフェースの緊密な統合に依存します。この統合は、証明書パス・プロバイダを作成する際に最も明らかになります。

証明書パス検証プロバイダを作成する場合は、次のタスクを実行する必要があります。

1. 「WebLogic MBeanMakerを使用してMBeanタイプを生成する」の説明に従って、CertPathProviderMBeanを拡張するCertPathValidatorMBeanを作成します。

2. 「JDK CertPathBuilderSpiインタフェース、CertPathValidatorSpiインタフェースのいずれか、または両方の実装」の説明に従って、JDK java.security.cert.CertPathValidatorSpiを実装します。
JDK実装には、WebLogic CertPathValidatorParametersSpiにキャストできるJDK CertPathParametersオブジェクトが渡されます。これにより、信頼性のあるCAおよびContextHandlerを取得するWebLogicメソッドにアクセスできるようになります。また、このオブジェクトを使用すると、WebLogic証明書パス・プロバイダ・オブジェクトにもアクセスできます。

信頼性のあるCA、ContextHandler、MBeanで提供されるカスタム構成データへのアクセスを許可する証明書パス・プロバイダSSPI実装など、証明書チェーンの検証に必要なデータを指定するには、「CertPathValidatorSpi実装でCertPathValidatorParametersSpi SSPIの使用」で説明されているようにCertPathValidatorParametersSpiを使用します。

CertPathValidatorSpi実装からMBeanのカスタム構成データを直接取得する方法はないので、WebLogic証明書パス・プロバイダは重要な役割を果たします。WebLogic証明書パス・プロバイダは、カスタムMBeanデータをJDK実装で使用可能にするための固有のメカニズムを提供できます。

3. 「証明書パス・プロバイダSSPIの実装」の説明に従って、WebLogic証明書パス・プロバイダSSPIを実装します。特に、MBeanへのフックを実行し、そのカスタム構成データをCertPathValidatorSpi実装で利用できるようにするには、例15-2で示すように、証明書パス・プロバイダSSPIのinitializeメソッドを使用します。

4. 「JDKセキュリティ・プロバイダSPIの実装」の説明に従って、CertPathValidatorSpi実装を登録するJDKセキュリティproviderを実装します。このコーディングは直感的にはわかりにくいこともあるため、例15-5に実例を示しています。

証明書パス・ビルダーを作成する場合は、次のタスクを実行する必要があります。

1. 「WebLogic MBeanMakerを使用してMBeanタイプを生成する」の説明に従って、CertPathProviderMBeanを拡張するCertPathBuilderMBeanを作成します。

2. 「JDK CertPathBuilderSpiインタフェース、CertPathValidatorSpiインタフェースのいずれか、または両方の実装」の説明に従って、JDK java.security.cert.CertPathBuilderSpiを実装します。
JDK実装には、WebLogic CertPathBuilderParametersSpiにキャストできるJDK CertPathParametersオブジェクトが渡されます。これにより、信頼性のあるCA、セレクタ、およびContextHandlerを取得するWebLogicメソッドにアクセスできるようになります。また、このオブジェクトを使用すると、WebLogic証明書パス・プロバイダ・オブジェクトにもアクセスできます。

信頼性のあるCA、ContextHandler、MBeanで提供されるカスタム構成データへのアクセスを許可する証明書パス・プロバイダSSPI実装など、証明書チェーンの検証に必要なデータを指定するには、「CertPathBuilderSpi実装でCertPathBuilderParametersSpi SSPIの使用」で説明されているようにCertPathBuilderParametersSpiを使用します。

CertPathBuilderSpi実装からMBeanのカスタム構成データを直接取得する方法はないので、WebLogic証明書パス・プロバイダは重要な役割を果たします。WebLogic証明書パス・プロバイダは、カスタムMBeanデータをJDK実装で使用可能にするための固有のメカニズムを提供できます。

3. 「証明書パス・プロバイダSSPIの実装」の説明に従って、WebLogic証明書パス・プロバイダSSPIを実装します。特に、MBeanへのフックを実行し、そのカスタム構成データをCertPathBuilderSpi実装で利用できるようにするには、例15-2で示すように、証明書パス・プロバイダSSPIのinitializeメソッドを使用します。

4. 「JDKセキュリティ・プロバイダSPIの実装」の説明に従って、CertPathBuilderSpi実装を登録するJDKセキュリティproviderを実装します。このコーディングは直感的にはわかりにくいこともあるため、例15-5に実例を示しています。

カスタム証明書パス・プロバイダを開発する必要があるか

WebLogic Serverには、証明書パス・プロバイダと証明書レジストリがあります。

WebLogic Server証明書パス・プロバイダは、証明書パス・ビルダーと証明書パス検証プロバイダの両方です。証明書パス・プロバイダは、証明書のパスを完了させ、特定のWebLogic Serverインスタンスのために構成された、信頼性のあるCAを使用して、証明書を検証します。証明書パス・プロバイダは、自己署名型のチェーンまたは自己署名型の認証局によって発行されたチェーンのみを作成できます。認証局は、サーバーの信頼性のあるCAにリストされている必要があります。未完成の証明書チェーンの場合は、無効です。プロバイダは、EndCertificateSelectorセレクタのみを使用します。

また、WebLogic Server証明書パス・プロバイダは、チェーン内の署名をチェックして、チェーンが期限切れでないことを確認し、チェーン内のいずれかの証明書が、サーバー用に構成された信頼性のあるCAによって発行されたものであることを確認します。いずれかのチェックが失敗した場合、そのチェーンは有効ではありません。最後に、プロバイダは、各証明書の基本的な制約(証明書が他の証明書を発行できるかどうか)をチェックし、証明書がチェーン内の適切な場所にあることを確認します。

WebLogic Server証明書パス・プロバイダは、セキュリティ・レルム内の証明書パス・ビルダーおよび証明書パス検証プロバイダとして使用できます。

WebLogic Server証明書レジストリは、初期状態の証明書パス・プロバイダです。管理者は、信頼性のある目的の証明書のリストを管理コンソールから構成できます。証明書レジストリはビルダー/検証プロバイダです。選択条件は、EndCertificateSelector、SubjectDNSelector、IssuerDNSerialNumberSelector、SubjectKeyIdentifierのいずれかです。返される証明書チェーンには、目的の証明書のみがあります。プロバイダでは、チェーンを検証する際に目的の証明書が登録されていることのみを確認し、それ以上のチェックは行いません。

証明書パス・プロバイダと証明書レジストリの両方を構成できます。これは、信頼性のあるCAによって署名された場合にのみ証明書チェーンが有効であり、目的の証明書がレジストリにあることを確認するために行うことができます。

WebLogic Server証明書パス・プロバイダが開発者のニーズを満たさない場合、カスタム証明書パス・プロバイダを開発することができます。

カスタム証明書パス・プロバイダの開発方法

WebLogic証明書パス・プロバイダまたは証明書レジストリが開発者のニーズを満たさない場合、次の手順でカスタム証明書パス・プロバイダを開発することができます。

適切なSSPIによるランタイム・クラスの作成

ランタイム・クラスを作成する前に、以下の作業が必要です。

- 「Provider」SSPIの目的について

- SSPI階層を理解し、ランタイム・クラスを1つ作成するか2つ作成するかを決定する

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム証明書パス・プロバイダのランタイム・クラスを作成します。

- WebLogic MBeanMakerを使用してMBeanタイプを生成する

- JDK CertPathBuilderSpiインタフェース、CertPathValidatorSpiインタフェースのいずれか、または両方の実装

- 証明書パス・プロバイダSSPIの実装

- JDKセキュリティ・プロバイダSPIの実装

- CertPathBuilderSpi実装でCertPathBuilderParametersSpi SSPIの使用、またはCertPathValidatorSpi実装でCertPathValidatorParametersSpi SSPIの使用

JDK CertPathBuilderSpiインタフェース、CertPathValidatorSpiインタフェースのいずれか、または両方の実装

java.security.cert.CertPathBuilderSpiインタフェースは、CertPathBuilderクラスのサービス・プロバイダ・インタフェース(SPI)です。すべてのCertPathBuilder実装は、このインタフェース(CertPathBuilderSpi)を実装するクラスを含む必要があります。

java.security.cert.CertPathValidatorSpiインタフェースは、CertPathValidatorクラスのサービス・プロバイダ・インタフェース(SPI)です。すべてのCertPathValidator実装は、このインタフェース(CertPathValidatorSpi)を実装するクラスを含む必要があります。

例15-6では、CertPathBuilderSpiインタフェースとCertPathValidatorSpiインタフェースの実装例を示します。

証明書パス・プロバイダSSPIの実装

CertPathProvider SSPIインタフェースは、JDK CertPathValidator SPIおよびCertPathBuilder SPIによって提供されるサービスを公開し、プロバイダの操作(初期化、開始、停止など)を可能にします。

特に、MBeanへのフックを実行し、そのカスタム構成データをCertPathBuilderSpi実装またはCertPathValidatorSpi実装で利用できるようにするには、例15-2で示すように、証明書パス・プロバイダSSPIのinitializeメソッドを使用します。

より詳細な例については、例15-6に示します。

例15-2 コード(抜粋) : MBeanからのカスタム構成データの取得

public class MyCertPathProviderRuntimeImpl implements CertPathProvider
{
:
:
public void initialize(ProviderMBean mBean, SecurityServices securityServices)
{
MyCertPathProviderMBean myMBean = (MyCertPathProviderMBean)mBean;
description = myMBean.getDescription();
customConfigData = myMBean.getCustomConfigData();
:
}
:
// make my config data available to my JDK CertPathBuilderSpi and
// CertPathValidatorSpi impls
private String getCustomConfigData() { return customConfigData; }
}
:
static public class MyJDKCertPathBuilder extends CertPathBuilderSpi
{
:
//get my runtime implementation instance which holds the configuration
//data needed to build and validate the cert path
MyCertPathProviderRuntimeImpl runtime =
(MyCertPathProviderRuntimeImpl)params.getCertPathProvider();
String myCustomConfigData = runtime.getCustomConfigData();

例15-5では、使用するJDK実装をJDKに登録する方法を示します。

CertPathProvider SSPIを実装するには、「「Provider」SSPIの目的について」で説明されているメソッドおよび次のメソッドの実装を提供する必要があります。

- getCertPathBuilder

public CertPathBuilder getCertPathBuilder()

例15-3で示すように、JDK CertPathBuilderSpi実装を呼び出す証明書パス・プロバイダのJDK CertPathBuilderを取得します。CertPathBuilderは、証明書チェーンを検索し、必要に応じて検証します。

例15-3 コード(抜粋) : getCertPathBuilder

public void initialize(ProviderMBean mBean, SecurityServices securityServices)
{
:
// get my JDK cert path impls
try {
certPathBuilder = CertPathBuilder.getInstance(BUILDER_ALGORITHM);
} catch (NoSuchAlgorithmException e) { throw new AssertionError("..."); }

- getCertPathValidator

public CertPathValidator getCertPathValidator()

例15-4で示すように、JDK CertPathValidatorSpi実装を呼び出す証明書パス・プロバイダのJDK CertPathValidatorを取得します。CertPathValidatorは、証明書チェーンを検証します。

例15-4 コード(抜粋) : getCertPathValidator

public void initialize(ProviderMBean mBean, SecurityServices securityServices)
{
:
// get my JDK cert path impls
try {
certPathValidator = CertPathValidator.getInstance(VALIDATOR_ALGORITHM);
} catch (NoSuchAlgorithmException e) { throw new AssertionError("..."); }
}

JDKセキュリティ・プロバイダSPIの実装

JDKセキュリティprovider SPIを実装し、そのSPIを使用してCertPathBuilderSpi実装またはCertPathValidatorSpi実装をJDKに登録します。その実装を使用して、JDK実装をプロバイダのinitializeメソッドに登録します。

例15-6に、サンプル証明書パス・プロバイダのランタイム・クラスの作成例を示します。例15-5では、JDKセキュリティproviderを実装するサンプル・コードの一部を示します。

例15-5 JDKセキュリティ・プロバイダの実装

public class MyCertPathProviderRuntimeImpl implements CertPathProvider
{
private static final String MY_JDK_SECURITY_PROVIDER_NAME = "MyCertPathProvider";
private static final String BUILDER_ALGORITHM = MY_JDK_SECURITY_PROVIDER_NAME + "CertPathBuilder";
private static final String VALIDATOR_ALGORITHM = MY_JDK_SECURITY_PROVIDER_NAME + "CertPathValidator";
:
:
public void initialize(ProviderMBean mBean, SecurityServices securityServices)
{
MyCertPathProviderMBean myMBean = (MyCertPathProviderMBean)mBean;

description = myMBean.getDescription();

customConfigData = myMBean.getCustomConfigData();

// register my cert path impls with the JDK
// so that the CLV framework may invoke them via
// the JDK cert path apis.
if (Security.getProvider(MY_JDK_SECURITY_PROVIDER_NAME) == null) {
AccessController.doPrivileged(
new PrivilegedAction() {
public Object run() {
Security.addProvider(new MyJDKSecurityProvider());
return null;
}
}
);
}
:
// This class implements the JDK security provider that registers
// this provider's cert path builder and cert path validator implementations
// with the JDK.
private class MyJDKSecurityProvider extends Provider
{
private MyJDKSecurityProvider()
{
super(MY_JDK_SECURITY_PROVIDER_NAME, 1.0, "MyCertPathProvider JDK CertPath provider");
put("CertPathBuilder." + BUILDER_ALGORITHM,
"com.acme.MyPathProviderRuntimeImpl$MyJDKCertPathBuilder");
put("CertPathValidator." + VALIDATOR_ALGORITHM,
"com.acme.MyCertPathProviderRuntimeImpl$MyJDKCertPathValidator");
}
}
}

CertPathBuilderSpi実装でCertPathBuilderParametersSpi SSPIの使用

JDK実装には、WebLogic CertPathBuilderParametersSpiにキャストできるJDK CertPathParametersオブジェクトが渡されます。これにより、信頼性のあるCA、セレクタ、およびContextHandlerを取得するWebLogicメソッドにアクセスできるようになります。また、このオブジェクトを使用すると、WebLogic証明書パス・プロバイダ・オブジェクトにもアクセスできます。以下のメソッドを利用できます。

- getCertPathProvider

CertPathProvider getCertPathProvider()

証明書パス・プロバイダで提供されているサービスをWebLogicセキュリティ・フレームワークに公開する証明書パス・プロバイダSSPIインタフェースを取得します。特に、MBeanへのフックを実行し、そのカスタム構成データをCertPathBuilderSpi実装で利用できるようにするには、例15-2で示すように、証明書パス・プロバイダSSPIのinitializeメソッドを使用します。

- getCertPathSelector

CertPathSelector getCertPathSelector()

証明書パスを検索する際の選択条件を保持するCertPathSelectorインタフェースを取得します。

WebLogic Serverでは、サポートされている証明書チェーン検索の種類ごとに1つずつのCertPathSelectorインタフェースを実装するweblogic.security.pk内の一連のクラスを使用できます。そのため、getCertPathSelectorメソッドは、以下の派生クラスのいずれか1つを返します。

- EndCertificateSelector: 目的の証明書がある証明書チェーンを検索および検証する場合に使用します。

- IssuerDNSerialNumberSelector: 目的の証明書の発行者DNとシリアル番号から証明書チェーンを検索および検証する場合に使用します。

- SubjectDNSelector: 目的の証明書のサブジェクトDNから証明書チェーンを検索および検証する場合に使用します。

- SubjectKeyIdentifierSelector: 目的の証明書のサブジェクト・キー識別子(X509証明書のオプション・フィールド)から証明書チェーンを検索および検証する場合に使用します。
各セレクタ・クラスには、選択データおよびコンストラクタを取得するためのメソッドが1つまたは複数あります。

CertPathBuilderSpi実装は、どのセレクタをサポートするかを決めます。CertPathBuilderSpi実装は、CertPathBuilderParametersSpi SSPIのgetCertPathSelectorメソッドを使用して、証明書パスを検索する際の選択条件を保持するCertPathSelectorを取得する必要があります。その種類のセレクタをサポートしている場合、CertPathBuilderSpi実装は、そのセレクタを使用して証明書チェーンを作成および検証します。その種類のセレクタをサポートしていない場合は、呼出し側に伝播されるInvalidAlgorithmParameterExceptionをスローします。

- getContext()

ContextHandler getContext()

証明書パスの作成および検証に使用可能な追加パラメータを渡すことができるContextHandlerを取得します。

- getTrustedCAs()

X509Certificate[] getTrustedCAs()

証明書チェーンの作成に使用できる、信頼性のある認証局のリストを取得します。信頼性のあるCAでチェーンを作成する必要がある場合、CertPathBuilderSpi実装は、このリスト内のCAを使用する必要があります。

- clone

Object clone()

このインタフェースのクローンは作成できません。

CertPathValidatorSpi実装でCertPathValidatorParametersSpi SSPIの使用

JDK実装には、WebLogic CertPathValidatorParametersSpiにキャストできるJDK CertPathParametersオブジェクトが渡されます。これにより、信頼性のあるCAおよびContextHandlerを取得するWebLogicメソッドにアクセスできるようになります。また、このオブジェクトを使用すると、WebLogic証明書パス・プロバイダ・オブジェクトにもアクセスできます。CLVフレームワークは、検証プロバイダSPIに渡された証明書チェーンが適切な順序になっている(目的の証明書から開始される)こと、および各証明書が次の証明書に署名していることを確認します。以下のメソッドを利用できます。

- getCertPathProvider

CertPathProvider getCertPathProvider()

証明書パス・プロバイダで提供されているサービスをWebLogicセキュリティ・フレームワークに公開する証明書パス・プロバイダSSPIインタフェースを取得します。特に、MBeanへのフックを実行し、そのカスタム構成データをCertPathValidatorSpi実装で利用できるようにするには、例15-2で示すように、証明書パス・プロバイダSSPIのinitializeメソッドを使用します。

- getContext()

ContextHandler getContext()

証明書パスの作成および検証に使用可能な追加パラメータを渡すことができるContextHandlerを取得します。

SSLは、1つまたは複数のCertPathValidatorオブジェクトを呼び出して追加検証を実行する前に、一部の組込み検証を実行します。検証プロバイダは、実行済みの検証を検出することで、必要な検証の規模を縮小できます。

たとえば、WebLogic証明書パス・プロバイダは、SSLが実行するものと同じ検証を実行します。SSLによって呼び出された場合でも、その検証を繰り返す必要はありません。そのため、SSLは、検証プロバイダに渡すコンテキストに一部の情報を保存し、どの検証がすでに実行済みかを示します。weblogic.security.SSL.SSLValidationConstants CHAIN_PREVALIDATED_BY_SSLフィールドは、SSLが証明書チェーンを検証済みかどうかを示すブール値です。アプリケーション・コードは、このフィールドをテストできます。フィールドは、SSLが証明書チェーンを検証済みの場合はtrue、まだ検証していない場合はfalseに設定されます。

- getTrustedCAs()

X509Certificate[] getTrustedCAs()

証明書チェーンの検証に使用できる、信頼性のある認証局のリストを取得します。信頼性のあるCAでチェーンを検証する必要がある場合、CertPathBuilderSpi実装は、このリスト内のCAを使用する必要があります。

- clone

Object clone()

このインタフェースのクローンは作成できません。

ビルダーまたは検証プロバイダの結果の返し

JDK CertPathBuilder実装またはCertPathValidator実装は、java.security.cert.CertPathValidatorResultインタフェースまたはjava.security.cert.CertPathValidatorResultインタフェースを実装するオブジェクトを返す必要があります。

ユーザー独自の結果の実装を作成することも、WebLogic Serverコンビニエンス・ルーチンを使用することもできます。

WebLogic Serverには、WLSCertPathBuilderResultとWLSCertPathValidatorResultという2つの便利な結果実装クラスがあります。どちらのクラスもweblogic.security.pkにあり、java.security.cert.CertPathValidatorResultまたはjava.security.cert.CertPathValidatorResultのインスタンスを返す場合に使用できます。

注意:

返される結果は、WebLogicセキュリティ・フレームワーク内を通りません。

例:サンプル証明書パス・プロバイダの作成

例15-6では、証明書パス・ビルダー/検証プロバイダの例を示します。例には、コード・フローを説明する拡張コメントが記載されています。

例15-6で使用する証明書パスMBeanは、例15-1に示されています。

例15-6 サンプル証明書パス・プロバイダの作成

package com.acme;

import weblogic.management.security.ProviderMBean;
import weblogic.security.pk.CertPathSelector;
import weblogic.security.pk.SubjectDNSelector;
import weblogic.security.pk.WLSCertPathBuilderResult;
import weblogic.security.pk.WLSCertPathValidatorResult;
import weblogic.security.service.ContextHandler;
import weblogic.security.spi.CertPathBuilderParametersSpi;
import weblogic.security.spi.CertPathProvider;
import weblogic.security.spi.CertPathValidatorParametersSpi;
import weblogic.security.spi.SecurityServices;
import weblogic.security.SSL.SSLValidationConstants;

import java.security.InvalidAlgorithmParameterException;
import java.security.NoSuchAlgorithmException;
import java.security.AccessController;
import java.security.PrivilegedAction;
import java.security.Provider;
import java.security.Security;
import java.security.cert.CertPath;
import java.security.cert.CertPathBuilder;
import java.security.cert.CertPathBuilderResult;
import java.security.cert.CertPathBuilderSpi;
import java.security.cert.CertPathBuilderException;
import java.security.cert.CertPathParameters;
import java.security.cert.CertPathValidator;
import java.security.cert.CertPathValidatorResult;
import java.security.cert.CertPathValidatorSpi;
import java.security.cert.CertPathValidatorException;
import java.security.cert.X509Certificate;

public class MyCertPathProviderRuntimeImpl implements CertPathProvider
{
private static final String MY_JDK_SECURITY_PROVIDER_NAME = "MyCertPathProvider";
private static final String BUILDER_ALGORITHM = MY_JDK_SECURITY_PROVIDER_NAME + "CertPathBuilder";
private static final String VALIDATOR_ALGORITHM = MY_JDK_SECURITY_PROVIDER_NAME + "CertPathValidator";

// Used to invoke my JDK cert path builder / validator implementations
private CertPathBuilder   certPathBuilder;
private CertPathValidator certPathValidator;

// remember my custom configuration data from my mbean
private String customConfigData;

private String description;

public void initialize(ProviderMBean mBean, SecurityServices securityServices)
{
MyCertPathProviderMBean myMBean = (MyCertPathProviderMBean)mBean;

description = myMBean.getDescription();

customConfigData = myMBean.getCustomConfigData();

// register my cert path impls with the JDK
// so that the CLV framework may invoke them via
// the JDK cert path apis.
if (Security.getProvider(MY_JDK_SECURITY_PROVIDER_NAME) == null) {
AccessController.doPrivileged(
new PrivilegedAction() {
public Object run() {
Security.addProvider(new MyJDKSecurityProvider());
return null;
}
}
);
}

// get my JDK cert path impls
try {
certPathBuilder = CertPathBuilder.getInstance(BUILDER_ALGORITHM);
} catch (NoSuchAlgorithmException e) { throw new AssertionError("..."); }

try {
certPathValidator = CertPathValidator.getInstance(VALIDATOR_ALGORITHM);
} catch (NoSuchAlgorithmException e) { throw new AssertionError("..."); }
}

public void             shutdown          () {                     }
public String           getDescription       () { return description;    }
public CertPathBuilder  getCertPathBuilder   () { return certPathBuilder;}
public CertPathValidator getCertPathValidator () { return certPathValidator;}

// make my config data available to my JDK CertPathBuilderSpi and
// CertPathValidatorSpi impls
private String getCustomConfigData() { return customConfigData; }

/**
* This class contains JDK cert path builder implementation for this provider.
*/

static public class MyJDKCertPathBuilder extends CertPathBuilderSpi
{
public CertPathBuilderResult
engineBuild(CertPathParameters genericParams)
throws CertPathBuilderException, InvalidAlgorithmParameterException
{

// narrow the CertPathParameters to the WLS ones so we can get the
// data needed to build and validate the cert path
if (!(genericParams instanceof CertPathBuilderParametersSpi)) {
throw new InvalidAlgorithmParameterException("The CertPathParameters must be a
weblogic.security.pk.CertPathBuilderParametersSpi instance.");
}

CertPathBuilderParametersSpi params = (CertPathBuilderParametersSpi)genericParams;

// get my runtime implementation instance which holds the configuration
// data needed to build and validate the cert path
MyCertPathProviderRuntimeImpl runtime = (MyCertPathProviderRuntimeImpl)params.getCertPathProvider();
String myCustomConfigData = runtime.getCustomConfigData();

// get the selector which indicates which cert path the caller wants built.
// it can be an EndCertificateSelector, SubjectDNSelector,
// IssuerDNSerialNumberSelector
// or a SubjectKeyIdentifier.
CertPathSelector genericSelector = params.getCertPathSelector();

// decide which kinds of selectors this builder wants to support.

if (genericSelector instanceof SubjectDNSelector) {

// get the subject dn of the end certificate of the cert path the caller
// wants built
SubjectDNSelector selector = (SubjectDNSelector)genericSelector;
String subjectDN = selector.getSubjectDN();

// if your implementation requires trusted CAs, get them.
// otherwise, ignore them.  that is, it's a quality of service
// issue whether or not you require trusted CAs.
X509Certificate[] trustedCAs = params.getTrustedCAs();

// if your implementation requires looks for extra data in
// the context handler, get it.  otherwise ignore it.
ContextHandler context = params.getContext();
if (context != null) {
// ...
}

// use my custom configuration data (ie. myCustomConfigData),
// the trusted CAs (if applicable to my implementation),
// the context (if applicable to my implementation),
// and the subject DN to build and validate the cert path
CertPath certpath = ...
// or X509Certificate[] chain = ...

// if not found, throw an exception:
if (...) {
throw new CertPathBuilderException("Could not build a cert path for " + subjectDN);
}

// if not valid, throw an exception:
if (...) {
throw new CertPathBuilderException("Could not validate the cert path for " + subjectDN);
}

// if found and valid, return the cert path.
// for convenience, use the WLSCertPathBuilderResult class
return new WLSCertPathBuilderResult(certpath);
// or return new WLSCertPathBuilderResult(chain);

} else {

// the caller passed in a selector that my implementation does not support
throw new InvalidAlgorithmParameterException("MyCertPathProvider only
supports weblogoic.security.pk.SubjectDNSelector");
}
}
}

/**
* This class contains JDK cert path validator implementation for this provider.
*/

static public class MyJDKCertPathValidator extends CertPathValidatorSpi
{
public CertPathValidatorResult
engineValidate(CertPath certPath, CertPathParameters genericParams)
throws CertPathValidatorException, InvalidAlgorithmParameterException
{

// narrow the CertPathParameters to the WLS ones so we can get the
// data needed to build and validate the cert path
if (!(genericParams instanceof CertPathValidatorParametersSpi)) {
throw new InvalidAlgorithmParameterException("The CertPathParameters must be a
weblogic.security.pk.CertPathValidatorParametersSpi instance.");
}

CertPathValidatorParametersSpi params = (CertPathValidatorParametersSpi)genericParams;

// get my runtime implementation instance which holds the configuration
// data needed to build and validate the cert path
MyCertPathProviderRuntimeImpl runtime = (MyCertPathProviderRuntimeImpl)params.getCertPathProvider();
String myCustomConfigData = runtime.getCustomConfigData();

// if your implementation requires trusted CAs, get them.
// otherwise, ignore them.  that is, it's a quality of service
// issue whether or not you require trusted CAs.
X509Certificate[] trustedCAs = params.getTrustedCAs();

// if your implementation requires looks for extra data in
// the context handler, get it.  otherwise ignore it.
ContextHandler context = params.getContext();
if (context != null) {
// ...
}

// The CLV framework has already done some minimal validation
// on the cert path before sending it to your provider:
//   1) the cert path is not empty
//   2) the cert path starts with the end cert
//   3) each certificate in the cert path was issued and
//      signed by the next certificate in the chain
//      So, your validator can rely on these checks having
//      already been performed (vs your validator needing to
//      do these checks too).

// Use my custom configuration data (ie. myCustomConfigData),
// the trusted CAs (if applicable to my implementation),
// and the context (if applicable to my implementation)
// to validate the cert path

// if not valid, throw an exception:
if (...) {
throw new CertPathValidatorException("Could not validate the cerpath " + certPath);
}
// if valid, return success

// For convenience, use the WLSCertPathValidatorResult class

return new WLSCertPathValidatorResult();
}
}

// This class implements the JDK security provider that registers this    // provider's
// cert path builder and cert path validator implementations with the JDK.
private class MyJDKSecurityProvider extends Provider
{
private MyJDKSecurityProvider()
{
super(MY_JDK_SECURITY_PROVIDER_NAME, 1.0, "MyCertPathProvider JDK CertPath provider");
put("CertPathBuilder." + BUILDER_ALGORITHM, "com.acme.MyPathProviderRuntimeImpl$MyJDKCertPathBuilder");
put("CertPathValidator." + VALIDATOR_ALGORITHM, "com.acme.MyCertPathProviderRuntimeImpl$MyJDKCertPathValidator");
}
}
}

WebLogic MBeanMakerを使用してMBeanタイプを生成する

カスタム・セキュリティ・プロバイダのMBeanタイプを生成する前に、以下の作業が必要です。

- MBeanタイプが必要な理由について

- 拡張および実装するSSPI MBeanの決定

- MBean定義ファイル(MDF)の基本的な要素について

- SSPI MBeanの階層と管理コンソールに対する影響について

- WebLogic MBeanMakerによって提供されるものについて

この情報を理解し、設計に関する判断を下したら、次の手順でカスタム証明書パス・プロバイダのMBeanタイプを作成します。

MBean定義ファイル(MDF)の作成

WebLogic MBeanMakerを使用してMBeanタイプを生成する

WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

WebLogic Server環境にMBeanタイプをインストールする

注意:

複数のセキュリティ・プロバイダのサンプルで、これらの手順の実行方法を示します。

この節で説明する手順はすべて、Windows環境での作業を想定しています。

MBean定義ファイル(MDF)の作成

MBean定義ファイル(MDF)を作成するには、次の手順に従います。

1. サンプル認証プロバイダのMDFをテキスト・ファイルにコピーします。

注意:

サンプル認証プロバイダのMDFは、SimpleSampleAuthenticator.xmlです。サンプル証明書パス・プロバイダはありません。

2. MDFで<MBeanType>要素と<MBeanAttribute>要素の内容をカスタム証明書パス・プロバイダに合わせて修正します。CertPathBuilderMBeanまたはCertPathValidatorMBeanを拡張または実装する必要があります。

3. カスタム属性および操作(つまり、<MBeanAttribute>および<MBeanOperation>要素)をMDFに追加します。

4. ファイルを保存します。

注意:

MDF要素の構文についての詳細なリファレンスは、付録A「MBean定義ファイル(MDF)要素の構文」に収められています。

WebLogic MBeanMakerを使用してMBeanタイプを生成する

MDFを作成したら、WebLogic MBeanMakerを使用してそれを実行できます。WebLogic MBeanMakerは現在のところコマンドライン・ユーティリティで、入力としてMDFを受け取り、MBeanインタフェース、MBean実装、関連するMBean情報ファイルなどの中間Javaファイルをいくつか出力します。これらの中間ファイルが合わさって、カスタム・セキュリティ・プロバイダのMBeanタイプになります。

MBeanタイプの生成手順は、カスタム証明書パス・プロバイダの設計に応じて異なります。必要な設計に合わせて適切な手順を実行してください。

- オプショナルSSPI MBeanとカスタム操作を追加しない場合

- オプショナルSSPI MBeanまたはカスタム操作を追加する場合

オプショナルSSPI MBeanとカスタム操作を追加しない場合

カスタム証明書パス・プロバイダのMDFにオプショナルSSPI MBeanもカスタム操作も実装しない場合、次の手順に従います。

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり証明書パス・プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

3. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

オプショナルSSPI MBeanまたはカスタム操作を追加する場合

カスタム証明書パス・プロバイダのMDFにオプショナルSSPI MBeanまたはカスタム操作を実装する場合、以下の質問に答えながら手順を進めてください。

MBeanタイプを作成するのは初めてですか。その場合は、次の手順に従ってください:

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり証明書パス・プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

3. オプショナルSSPI MBeanをMDFに実装した場合は、次の手順に従います。

1. MBean実装ファイルを見つけます。
WebLogic MBeanMakerによって生成されるMBean実装ファイルには、MBeanNameImpl.javaという名前が付けられます。たとえば、SampleIdentityAsserterという名前のMDFの場合、編集されるMBean実装ファイルはSampleIdentityAsserterImpl.javaという名前になります。

2. MDFで実装したオプショナルSSPI MBeanごとに、各メソッドを実装します。オプショナルSSPI MBeanが継承するメソッドもすべて実装してください。

4. MDFにカスタム操作を含めた場合、メソッド・スタブを使用してメソッドを実装します。

5. ファイルを保存します。

6. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

既存のMBeanタイプの更新ですか。その場合は、次の手順に従ってください:

1. WebLogic MBeanMakerによって現在のメソッドの実装が上書きされないように、既存のMBean実装ファイルを一時ディレクトリにコピーします。

2. 新しいDOSシェルを作成します。

3. 次のコマンドを入力します。

java -DMDF=xmlfile -Dfiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMDFフラグはWebLogic MBeanMakerがMDFをコードに変換すべきであることを示し、xmlFileはMDF (XML MBeanの記述ファイル)、filesdirはWebLogic MBeanMakerで作成されたMBeanタイプの中間ファイルが格納される場所を示します。

xmlfileが入力されるたびに、新しい出力ファイル群が生成されます。

-DcreateStubs=trueフラグを使用するたびに、既存のMBean実装ファイルがすべて上書きされます。

注意:

バージョン9.0以降のWebLogic Serverでは、-DMDFDIR <MDF directory name>オプションを使用して、複数のMDFを格納するディレクトリを指定することができます。旧バージョンのWebLogic Serverでは、WebLogic MBeanMakerで一度に処理されるMDFは1つだけです。したがって、MDF (つまり証明書パス・プロバイダ)が複数ある場合には、このプロセスを繰り返す必要がありました。

4. オプショナルSSPI MBeanをMDFに実装した場合は、次の手順に従います。

1. MBean実装ファイルを見つけて開きます。
WebLogic MBeanMakerによって生成されるMBean実装ファイルには、MBeanNameImpl.javaという名前が付けられます。たとえば、SampleIdentityAsserterという名前のMDFの場合、編集されるMBean実装ファイルはSampleIdentityAsserterImpl.javaという名前になります。

2. ステップ1で一時ディレクトリに保存した既存のMBean実装ファイルを開きます。

3. 既存のMBean実装ファイルを、WebLogic MBeanMakerによって生成されたMBean実装ファイルと同期させます。
これには、メソッドの実装を既存のMBean実装ファイルから新しく生成されたMBean実装ファイルにコピー(または、新しく生成されたMBean実装ファイルから既存のMBean実装ファイルに新しいメソッドを追加)し、いずれのMBean実装ファイルにも入っているメソッドのメソッド・シグネチャへの変更が、使用するMBean実装ファイルに反映されていることを確認するといった作業が必要です。

4. MDFを修正して元のMDFにはないオプショナルSSPI MBeanを実装した場合は、各メソッドを実装します。オプショナルSSPI MBeanが継承するメソッドもすべて実装してください。

5. MDFを変更して元のMDFにはないカスタム操作を含めた場合、メソッド・スタブを使用してメソッドを実装します。

6. 完成した、つまりすべてのメソッドを実装したMBean実装ファイルを保存します。

7. このMBean実装ファイルを、WebLogic MBeanMakerがMBeanタイプの実装ファイルを配置したディレクトリにコピーします。このディレクトリは、手順3でfilesdirとして指定したものです。(ステップ3の結果としてWebLogic MBeanMakerで生成されたMBean実装ファイルがオーバーライドされます)。

8. 「WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成」に進みます。

生成されるMBeanインタフェース・ファイルについて

MBeanインタフェース・ファイルとは、ランタイム・クラスまたはMBean実装が構成データを取得するために使用するMBeanのクライアント側APIです。「「Provider」SSPIの目的について」で説明されているように、これはinitializeメソッドで使用するのが一般的です。

WebLogic MBeanMakerでは、作成済のMDFからMBeanタイプを生成するので、生成されるMBeanインタフェース・ファイルの名前は、そのMDF名の後に「MBean」というテキストが付いたものになります。たとえば、WebLogic MBeanMakerを使用してSampleIdentityAsserter MDFを実行すると、SampleIdentityAsserterMBean.javaという名前のMBeanインタフェース・ファイルが生成されます。

WebLogic MBeanMakerによるMBean JARファイル(MJF)の作成

WebLogic MBeanMakerでMDFを実行して中間ファイルを作成し、MBean実装ファイルを編集して適切なメソッドの実装を提供したら、カスタムCertPathプロバイダのMBeanファイルとランタイム・クラスをMBean JARファイル(MJF)にパッケージ化する必要があります。このプロセスも、WebLogic MBeanMakerによって自動化されます。

カスタム証明書パス・プロバイダのMJFを作成するには、次の手順に従います。

1. 新しいDOSシェルを作成します。

2. 次のコマンドを入力します。

java -DMJF=jarfile -Dfiles=filesdir weblogic.management.commo.WebLogicMBeanMaker

ここで、-DMJFフラグはWebLogic MBeanMakerが新しいMBeanタイプを含むJARファイルを構築すべきであることを示し、jarfileはMJFの名前、filesdirはWebLogic MBeanMakerでMJFにJAR化する対象ファイルが存在する場所を示します。

この時点でコンパイルが行われるので、エラーが発生するおそれがあります。jarfileが指定されていて、エラーが発生しなかった場合には、指定された名前のMJFが作成されます。

注意:

カスタム・セキュリティ・プロバイダのJARファイルを作成する際には、一連のXMLバインディング・クラスと1つのスキーマも生成されます。そのスキーマに関連付けるネームスペースを選択できます。それにより、使用しているカスタム・クラスとOracleのカスタム・クラスとの競合を防ぐことができます。ネームスペースのデフォルトはvendorです。-targetNameSpace引数をWebLogicMBeanMakerまたは関連するWLMBeanMaker antタスクに渡すことで、このデフォルトを変更できます。

既存のMJFを更新する場合は、単純にMJFを削除して再生成します。WebLogic MBeanMakerにも -DIncludeSourceオプションがあり、それを指定すると、生成されるMJFにソース・ファイルを含めるかどうかを制御できます。ソース・ファイルには、生成されたソースとMDFそのものがあります。デフォルトはfalseです。このオプションは、-DMJFを使用しない場合には無視されます。

生成されたMJFは、自らのWebLogic Server環境にインストールすることも、顧客に配布してそれぞれのWebLogic Server環境にインストールしてもらうこともできます。

WebLogic Server環境にMBeanタイプをインストールする

MBeanタイプをWebLogic Server環境にインストールするには、MJFをWL_HOME\server\lib\mbeantypesディレクトリにコピーします。ここで、WL_HOMEはWebLogic Serverの最上位のインストール・ディレクトリです。このインストール・コマンドによって、カスタム証明書パス・プロバイダが「デプロイ」されます。つまり、カスタム証明書パス・プロバイダをWebLogic Server管理コンソールから管理できるようになります。

注意:

MBeanタイプをインストールするデフォルトのディレクトリは、WL_HOME\server\lib\mbeantypesです。初めて使用するバージョンが9.0の場合、セキュリティ・プロバイダは...\domaindir\lib\mbeantypesからもロードできます。ただし、サーバーを起動するときに-Dweblogic.alternateTypesDirectory=<dir>コマンドライン・フラグを使用すれば、WebLogic Serverが追加ディレクトリでMBeanタイプを検索します。<dir>は、ディレクトリ名のカンマ区切りのリストです。このフラグを使用する場合、WebLogic Serverは常に最初にWL_HOME\server\lib\mbeantypesからMBeanタイプをロードします。その後で、追加ディレクトリにあるすべての有効なアーカイブを検索して、ロードします。このとき拡張子は考慮されません。

たとえば、-Dweblogic.alternateTypesDirectory = dirX,dirYの場合、WebLogic ServerはまずWL_HOME\server\lib\mbeantypesからMBeanタイプをロードし、次にdirXおよびdirYにある有効なアーカイブをロードします。WebLogic Serverに追加ディレクトリでMBeanタイプを検索するよう指示する際に、Javaセキュリティ・マネージャを使用している場合は、weblogic.policyファイルを更新して、MBeanタイプ(その結果として、カスタム・セキュリティ・プロバイダ)に適した許可を付与することも必要になります。詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』のJavaセキュリティを使用したWebLogicリソースの保護に関する項を参照してください。

カスタム証明書パス・プロバイダを構成することによって(「管理コンソールによるカスタム証明書パス・プロバイダの構成」を参照)、MBeanタイプのインスタンスを作成して、GUI、他のJavaコード、またはAPIからそれらのMBeanインスタンスを使用することができます。たとえば、WebLogic Server管理コンソールを使用して、属性を取得/設定したり操作を呼び出したりすることもできますし、他のJavaオブジェクトを開発して、そのオブジェクトでMBeanをインスタンス化し、それらのMBeanから提供される情報に自動的に応答させることもできます。なお、これらのMBeanインスタンスをバックアップしておくことをお薦めします。

管理コンソールによるカスタム証明書パス・プロバイダの構成

カスタム証明書パス・プロバイダを構成するということは、証明書サービスを必要とするアプリケーションがアクセス可能なセキュリティ・レルムにカスタム証明書パス・プロバイダを追加するということです。

カスタム・セキュリティ・プロバイダの構成は管理タスクですが、カスタム・セキュリティ・プロバイダの開発者が行うこともできます。

注意:

WebLogic Server管理コンソールを使用してカスタム証明書パス・プロバイダを構成する手順は、『Oracle WebLogic Serverの保護』のWebLogicセキュリティ・プロバイダの構成に関する項で説明されています。

A MBean定義ファイル(MDF)要素の構文

MBean定義ファイル(MDF) はWebLogic MBeanMakerユーティリティへの入力ファイルです。WebLogic MBeanMakerユーティリティは、このファイルを使用してカスタム・セキュリティ・プロバイダを管理するためのMBeanタイプを作成します。MDFは、単一のMBeanタイプを記述する有効な整形式XMLファイルとしてフォーマットされる必要があります。以下の節では、有効なMDFで使用可能なすべての要素と属性について説明します。

- MBeanType (ルート)要素

- MBeanAttributeサブ要素

- MBeanConstructorサブ要素

- MBeanOperationサブ要素

- 例:有効な整形式MBean定義ファイル(MDF)

MBeanType (ルート)要素

すべてのMDFにはMBeanTypeというルート要素が1つ含まれていなければなりません。この要素の構文は次のとおりです。

<MBeanType Name= string   optional_attributes>
subelements
</MBeanType>

MBeanType要素は、MBeanタイプのプログラム上の内部的な名前を指定するName属性を含む必要があります。(ユーザー・インタフェース内に表示される名前を指定するには、DisplayName属性を使用します)。他の属性は省略可能です。

以下の例は、MBeanType (ルート)要素を簡略化して示したものです。

<MBeanType Name="MyMBean" Package="com.mycompany">
<MBeanAttribute Name="MyAttr" Type="java.lang.String" Default="Hello World"/>
</MBeanType>

MBeanType (ルート)要素内に指定されている属性は、そのMBeanタイプからインスタンス化されるすべてのMBeanに適用されます。特定のMBeanインスタンスの属性をオーバーライドするには、MBeanAttributeサブ要素で属性を指定する必要があります。詳細については、「MBeanAttributeサブ要素」を参照してください。

表A-1では、MBeanType(ルート)要素で使用可能な属性について説明します。「JMX仕様/Oracle拡張機能」列は、当該属性がJMX仕様に対するOracle拡張機能なのか、それともJMXの標準属性なのかを示します。なお、Oracle拡張機能は他のJava EE Webサーバー上では動作しない場合があることに注意してください。

表A-1 MBeanType(ルート)要素の属性

属性

JMX仕様/Oracle拡張機能

指定可能な値

説明

Abstract

Oracle拡張機能

trueまたはfalse

値がtrueの場合には、当該MBeanタイプは(Java抽象クラスと同様に)インスタンス化できないことを意味します。ただし、他のMBeanタイプは当該MBeanタイプの属性と操作を継承できます。trueを指定した場合には、管理タスクを実行するための非抽象MBeanタイプを別途作成する必要があります。この属性の値を指定しない場合は、falseと見なされます。

Deprecated

Oracle拡張機能

trueまたはfalse

当該MBeanタイプが非推奨扱いになっていることを示します。この情報は生成されたJavaソースに表示されると共に、管理アプリケーションでの使用を想定してModelMBeanInfoオブジェクトにも格納されます。この属性を指定しない場合、値はfalseと見なされます。

Description

JMX仕様

String型

当該MBeanタイプに関連付けられる任意の文字列で、生成されたクラスのJavadocなど、様々な場所に現れます。デフォルト値または仮定される値はありません。

注意: ユーザー・インタフェースに表示される説明を指定するには、DisplayName属性を使用します。

DisplayName

JMX仕様

String型

ユーザー・インタフェースに表示されるMBeanタイプのインスタンス識別用の名前。タイプXのインスタンスの場合、デフォルトDisplayNameは「タイプXのインスタンス」となります。通常、この値はインスタンス作成時にオーバーライドされます。

Extends

Oracle拡張機能

パス名

このMBeanタイプが拡張する完全修飾MBeanタイプ名。

Implements

Oracle拡張機能

カンマ区切り

リスト

このMBeanタイプを実装する完全修飾MBeanタイプ名からなるカンマ区切りリスト。

「Extends」も参照してください。

Name

JMX仕様

String型

当該MBeanタイプのプログラム上の内部的な名前を指定する必須属性。

Package

Oracle拡張機能

String型

当該MBeanタイプのパッケージ名を指定し、WebLogic MBeanMakerによって作成されるクラス・ファイルの場所を決定します。この属性を指定しない場合には、MBeanタイプはJavaデフォルト・パッケージに格納されます。

注意: パッケージ名が異なっている限り、MBeanタイプ名は同じ名前でもかまいません。

PersistPolicy

JMX仕様

/OnUpdate

永続化がどのように行われるかを、以下のいずれかで指定します。

OnUpdate :属性は更新のたびに格納されます。

注意: MBeanType要素内で指定された場合、この属性値は、個々のMBeanAttributeサブ要素内のあらゆる設定をオーバーライドします。

MBeanAttributeサブ要素

MBeanタイプ内の属性ごとに、MBeanAttributeサブ要素のインスタンスを1つ記述する必要があります。MBeanAttributeサブ要素の形式は次のとおりとします。

<MBeanAttribute Name=string   optional_attributes />

MBeanAttributeサブ要素は、MBeanタイプのJava属性のプログラム上の内部的な名前を指定するName属性を含む必要があります。(ユーザー・インタフェース内に表示される名前を指定するには、DisplayName属性を使用します)。他の属性は省略可能です。

以下の例は、MBeanType要素内のMBeanAttributeサブ要素を簡略化して示したものです。

<MBeanType Name="MyMBean" Package="com.mycompany">
<MBeanAttribute Name= "WhenToCache"
Type="java.lang.String"
LegalValues="'cache-on-reference','cache-at-initialization','cache-never'"
Default= "cache-on-reference"
/>
</MBeanType>

MBeanAttributeサブ要素内に指定されている属性は、特定のMBeanインスタンスに適用されます。あるMBeanタイプからインスタンス化されるすべてのMBeanの属性を設定するには、MBeanType (ルート)要素内に属性を指定する必要があります。詳細については、「MBeanType (ルート)要素」を参照してください。

表A-2では、MBeanAttributeサブ要素で使用可能な属性について説明します。「JMX仕様/Oracle拡張機能」列は、当該属性がJMX仕様に対するOracle拡張機能なのかどうかを示します。なお、Oracle拡張機能は他のJava EE Webサーバー上では動作しない場合があることに注意してください。

表A-2 MBeanAttributeサブ要素の属性

属性

JMX仕様/Oracle拡張機能

指定可能な値

説明

Default

JMX仕様

String型

MBeanAttributeサブ要素からゲッター・メソッドまたはキャッシュ済みの値が提供されない場合に返すべき値。文字列は、この属性に指定されたデータ型と互換性を持つ型のオブジェクトに評価しなければならないJava式を表します。

この属性を指定しない場合、値はnullと見なされます。この想定値を使用し、かつLegalNull属性をfalseに設定してある場合には、WebLogic MBeanMakerとWebLogic Serverから例外がスローされます。

Deprecated

Oracle拡張機能

trueまたはfalse

当該MBean属性が非推奨扱いになっていることを示します。この情報は生成されたJavaソースに表示されると共に、管理アプリケーションでの使用を想定してModelMBeanInfoオブジェクトにも格納されます。この属性を指定しない場合、値はfalseと見なされます。

Description

JMX仕様

String型

当該MBean属性に関連付けられる任意の文字列で、生成されたクラスのJavadocなど、様々な場所に現れます。デフォルト値または仮定される値はありません。

注意: ユーザー・インタフェース内に表示される説明を指定するには、DisplayName属性を使用します。

Dynamic

Oracle拡張機能

trueまたはfalse

動的MBeanに対する変更が、サーバーを再起動しなくても有効になります。デフォルトでは、すべてのカスタム・セキュリティ・プロバイダMBean属性は動的ではありません。

8.1および7.0では、すべてのカスタム・セキュリティ・プロバイダMBean属性は動的です。

Encrypted

Oracle拡張機能

trueまたはfalse

値がtrueの場合、このMBean属性は設定されると暗号化されることを示します。この属性を指定しない場合、値はfalseと見なされます。

InterfaceType

Oracle拡張機能

String型

WebLogic MBeanMakerで生成されるMBeanインタフェースのかわりに使用すべきインタフェースのクラス名。InterfaceTypeに指定できる値は以下のとおりです。

- int

- long

- float

- double

- char

- byte

「Type」がjava.lang.String、java.lang.String[]、またはjava.lang.Propertiesの場合は指定しません。

IsIs

JMX仕様

trueまたはfalse

生成されるJavaインタフェースでMBean属性のブール値にアクセスするのに(get<AttributeName>メソッドではなく) JMX is<AttributeName>メソッドを使用するかどうかを指定します。この属性を指定しない場合、値はfalseと見なされます。

LegalNull

Oracle拡張機能

trueまたはfalse

現在のMBeanAttributeサブ要素がnullを値として取り得るかどうかを指定します。この属性を指定しない場合、値はtrueと見なされます。

LegalValues

Oracle拡張機能

カンマ区切りリスト

現在のMBeanAttributeサブ要素の取り得る値の固定集合を指定します。この属性を指定しない場合、MBean属性では、Type属性で指定されているタイプの任意の値を指定できます。

注意: このリスト内の要素は、サブ要素のType属性で指定されるデータ型に変換可能なものでなければなりません。

Max

Oracle拡張機能

Integer型

数値型のMBean属性タイプに限り、属性の最大値(その値を含む)を表す数値を指定します。この属性を指定しない場合には、値はデータ型の許容最大値まで可能です。

Min

Oracle拡張機能

Integer型

数値型のMBean属性タイプに限り、属性の最小値(その値を含む)を表す数値を指定します。この属性を指定しない場合には、値はデータ型の許容最小値まで可能です。

Name

JMX仕様

String型

当該MBean属性のプログラム上の内部的な名前を指定する必須属性。

Type

JMX仕様

Javaクラス名

この属性のデータ型の完全修飾クラス名。これに対応するクラスがクラスパスに存在していなければなりません。この属性を指定しない場合、値はjava.lang.Stringと見なされます。指定できる値は以下のとおりです。

- java.lang.Integer

- java.lang.Integer[]

- java.lang.Long

- java.lang.Long[]

- java.lang.Float

- java.lang.Float[]

- java.lang.Double

- java.lang.Double[]

- java.lang.Char

- java.lang.Char[]

- java.lang.Byte

- java.lang.Byte[]

- java.lang.String

- java.lang.String[]

- java.util.Properties

Writeable

JMX仕様

trueまたはfalse

値がtrueの場合には、MBean APIを通じてMBeanAttributeの値を設定できるようになります。MBeanTypeまたはMBeanAttributeでこの属性を指定しない場合、値はtrueと見なされます。

MBeanType要素に指定すると、この値は個々のMBeanAttributeサブ要素のデフォルトと見なされます。

MBeanConstructorサブ要素

MBeanConstructorサブ要素は現在のところ、WebLogic MBeanMakerでは使用されておらず、Java Management eXtensions 1.0仕様(http://jcp.org/aboutJava/communityprocess/final/jsr003/index.html)に準拠し、上位互換性を保つためにサポートされているだけです。したがって、ここでは、MBeanConstructorサブ要素(およびそれに関連するMBeanConstructorArgサブ要素)の属性の詳細については説明を省略します。

MBeanOperationサブ要素

MBeanタイプでサポートされている操作(メソッド)ごとに、MBeanOperationサブ要素のインスタンスを1つ記述する必要があります。MBeanOperationの形式は次のとおりとします。

<MBeanOperation Name=string    optional_attributes >
<MBeanOperationArg Name=string   optional_attributes />
</MBeanOperation>

MBeanOperationサブ要素は、その操作のプログラム上の内部的な名前を指定するName属性を含む必要があります。(ユーザー・インタフェース内に表示される名前を指定するには、DisplayName属性を使用します)。他の属性は省略可能です。

MBeanOperation要素内には、その操作(メソッド)で使用される引数ごとにMBeanOperationArgサブ要素のインスタンスを1つ記述する必要があります。MBeanOperationArgの形式は次のとおりとします。

<MBeanOperationArg Name=string optional_attributes />

Name属性には操作の名前を指定する必要があります。MBeanOperationArgのオプション属性はTypeだけで、これは、特定タイプのJava属性の動作を指定するJavaクラス名を与えるものです。この属性を指定しない場合、値はjava.lang.Stringと見なされます。

次の例は、MBeanType要素内のMBeanOperationサブ要素とMBeanOperationArgサブ要素を簡略化して示したものです。

<MBeanType Name="MyMBean" Package="com.mycompany">
<MBeanOperation
Name= "findParserSelectMBeanByKey"
ReturnType="XMLParserSelectRegistryEntryMBean"
Description="Given a public ID, system ID, or root element tag, returns the
object name of the corresponding XMLParserSelectRegistryEntryMBean."
>
<MBeanOperationArg Name="publicID" Type="java.lang.String"/>
<MBeanOperationArg Name="systemID" Type="java.lang.String"/>
<MBeanOperationArg Name="rootTag" Type="java.lang.String"/>
</MBeanOperation>
</MBeanType>

表A-3では、MBeanOperationサブ要素で使用可能な属性について説明します。「JMX仕様/Oracle拡張機能」列は、当該属性がJMX仕様に対するOracle拡張機能なのかどうかを示します。なお、Oracle拡張機能は他のJava EE Webサーバー上では動作しない場合があることに注意してください。

表A-3 MBeanOperationサブ要素の属性

属性

JMX仕様/Oracle拡張機能

指定可能な値

説明

Deprecated

Oracle拡張機能

trueまたはfalse

当該MBean操作が非推奨扱いになっていることを示します。この情報は生成されたJavaソースに表示されると共に、管理アプリケーションでの使用を想定してModelMBeanInfoオブジェクトにも格納されます。この属性を指定しない場合、値はfalseと見なされます。

Description

JMX仕様

String型

当該MBean操作に関連付けられる任意の文字列で、生成されたクラスのJavadocなど、様々な場所に現れます。デフォルト値または仮定される値はありません。

注意: ユーザー・インタフェース内に表示される説明を指定するには、DisplayName属性を使用します。

Name

JMX仕様

String型

当該MBean操作のプログラム上の内部的な名前を指定する必須属性。

ReturnType

JMX仕様

String型

当該操作から返されるJavaオブジェクトの完全修飾クラス名を表す文字列。ReturnTypeはvoidまたは以下のいずれかになります。

- int

- int[]

- long

- long[]

- float

- float[]

- double

- double[]

- char

- char[]

- byte

- byte[]

- java.lang.String

- java.lang.String[]

- java.util.Properties

表A-4では、MBeanOperationArgサブ要素で使用可能な属性について説明します。「JMX仕様/Oracle拡張機能」列は、当該属性がJMX仕様に対するOracle拡張機能なのかどうかを示します。なお、Oracle拡張機能は他のJava EE Webサーバー上では動作しない場合があることに注意してください。

表A-4 MBeanOperationArgサブ要素の属性

属性

JMX仕様/Oracle拡張機能

指定可能な値

説明

Description

JMX仕様

String型

当該MBean操作の引数に関連付けられる任意の文字列で、生成されたクラスのJavadocなど、様々な場所に現れます。デフォルト値または仮定される値はありません。

Name

JMX仕様

String型

当該引数の名前を指定する必須属性。

Type

JMX仕様

String型

当該MBean操作の引数のデータ型。この属性を指定しない場合、値はjava.lang.Stringと見なされます。Typeに指定できる値は以下のとおりです。

- int

- int[]

- long

- long[]

- float

- float[]

- double

- double[]

- char

- char[]

- byte

- byte[]

- java.lang.String

- java.lang.String[]

- java.util.Properties

MBean操作の例外

MBean定義ファイル(MDF)は、JDK例外の型またはweblogic.management.utils例外の型のみを使用する必要があります。例A-1で示したコードの一部を次に示します。MBeanOperationサブ要素内でMBeanExceptionが使用されています。

<MBeanOperation
Name = "registerPredicate"
ReturnType = "void"
Description = "Registers a new predicate with the specified class name."
>
<MBeanOperationArg
Name = "predicateClassName"
Type = "java.lang.String"
Description = "The name of the Java class that implements the predicate."
/>
<MBeanException>weblogic.management.utils.InvalidPredicateException</MBeanException>
<MBeanException>weblogic.management.utils.AlreadyExistsException</MBeanException>
</MBeanOperation>

例:有効な整形式MBean定義ファイル(MDF)

例A-1と例A-2に、この付録で説明した属性の多くを使用したMBean定義ファイル(MDF)の例を示します。例A-1には、述語を管理し、述語とそれらの引数に関するデータを読み取るMBeanタイプを生成するためのMDFを示します。例A-2には、WebLogic (デフォルト)認可プロバイダのMBeanタイプを生成するためのMDFを示します。

例A-1 PredicateEditor.xml

<?xml version="1.0" ?>
<!DOCTYPE MBeanType SYSTEM "commo.dtd">
<MBeanType
Name = "PredicateEditor"
Package = "weblogic.security.providers.authorization"
Implements = "weblogic.security.providers.authorization.PredicateReader"
PersistPolicy = "OnUpdate"
Abstract = "false"
Description = "This MBean manages predicates and reads data about predicates and their arguments.&lt;p&gt;"
>
<MBeanOperation
Name = "registerPredicate"
ReturnType = "void"
Description = "Registers a new predicate with the specified class name."
>
<MBeanOperationArg
Name = "predicateClassName"
Type = "java.lang.String"
Description = "The name of the Java class that implements the predicate."
/>
<MBeanException>weblogic.management.utils.InvalidPredicateException</MBeanException>
<MBeanException>weblogic.management.utils.AlreadyExistsException</MBeanException>
</MBeanOperation>

<MBeanOperation
Name = "unregisterPredicate"
ReturnType = "void"
Description = "Unregisters the currently registered predicate."   >

<MBeanOperationArg
Name = "predicateClassName"
Type = "java.lang.String"
Description = "The name of the Java class that implements predicate to be unregistered."
/>
<MBeanException>weblogic.management.utils.NotFoundException</MBeanException>
</MBeanOperation>
</MBeanType>

例A-2 DefaultAuthorizer.xml

<?xml version="1.0" ?>
<!DOCTYPE MBeanType SYSTEM "commo.dtd">
<MBeanType
Name = "DefaultAuthorizer"
DisplayName = "DefaultAuthorizer"
Package = "weblogic.security.providers.authorization"
Extends ="weblogic.management.security.authorization.DeployableAuthorizer"
Implements = "weblogic.management.security.authorization.PolicyEditor,
weblogic.security.providers.authorization.PredicateEditor"
PersistPolicy = "OnUpdate"
Description = "This MBean represents configuration attributes
for the WebLogic Authorization provider. &lt;p&gt;"
>
<MBeanAttribute
Name = "ProviderClassName"
Type = "java.lang.String"
Writeable = "false"
Default"&quot;weblogic.security.providers.authorization.DefaultAuthorizationProviderImpl&quot;"
Description = "The name of the Java class used to load the WebLogic
Authorization provider."
/>
<MBeanAttribute
Name = "Description"
Type = "java.lang.String"
Writeable = "false"
Default = "&quot;Weblogic Default Authorization Provider&quot;"    Description =
"A short description of the WebLogic Authorization provider."  />
<MBeanAttribute
Name = "Version"
Type = "java.lang.String"
Writeable = "false"
Default = "&quot;1.0&quot;"
Description = "The version of the WebLogic Authorization provider."
/>
</MBeanType>

Copyright © 2007, 2012, Oracle and/or its affiliates. All rights reserved.