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

12cリリース1 (12.1.1)

B65912-02(原本部品番号:E24421-02)

目次

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

はじめに

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

- 表記規則

1 概要とロードマップ

- ドキュメントの内容と対象読者

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

- 関連情報

- チュートリアルとサンプル

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

2 WebLogicリソースのセキュリティについて

- WebLogicリソースの保護の概要

- ポリシーを使用して複数のリソースの保護

- タイプ別の保護ポリシー

- リソースの階層の保護

- WebLogicリソースのロールとポリシーの設計:主な手順

- ベスト・プラクティス:ポリシーへの条件指定とロールへの条件指定

- ベスト・プラクティス: WebLogicプロバイダの使用時に資格のキャッシングを構成する

3 ポリシーで保護できるリソースのタイプ

- 管理リソース

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

- COMリソース

- EJBリソース

- エンタープライズ情報システム(EIS)リソース

- Java DataBase Connectivity (JDBC)リソース

- JDBC操作

- Java Messaging Service (JMS)リソース

- JMS操作

- Java Naming and Directory Interface (JNDI)リソース

- JNDI操作

- JMXリソース

- 一貫性のあるセキュリティ方式の維持

- サーバー・リソース

- weblogic.Serverコマンド、ノード・マネージャのパーミッション

- weblogic.Serverコマンドを使用したパーミッション

- ノード・マネージャを使用したパーミッション

- URLリソース

- Webサービス・リソース

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

4 Webアプリケーション およびEJBリソースの保護のオプション

- 不要になったデプロイメント記述子

- Webアプリケーション、EJB用のセキュリティ・モデルの比較

- 各モデルについて

- メタデータ・アノテーション

- 「デプロイメント記述子のみ」モデル

- カスタム・ロール・モデル

- カスタム・ロールおよびポリシー・モデル

- 詳細モデル

- 詳細セキュリティ・モデルについて

- 「ロールとポリシーのチェック」設定について

- 「WebアプリケーションまたはEJBのデプロイ時」設定について

- 「ロールとポリシーのチェック」と「WebアプリケーションまたはEJBのデプロイ時」の相互作用

- 「ロール・マッピングの組合せを有効化」設定について

- 使用例

- Webアプリケーション、EJBの保護

5 セキュリティ・ポリシー

- セキュリティ・ポリシーの格納および使用の前提条件

- デフォルトのルート・レベルのセキュリティ・ポリシー

- セキュリティ・ポリシー条件

- 基本的なポリシー条件

- 日付と時刻のポリシー条件

- コンテキスト要素のポリシー条件

- 保護されたパブリック・インタフェース

- 管理コンソールでのセキュリティ・ポリシーの管理

6 ユーザー、グループ、セキュリティ・ロール

- ユーザーとグループの概要

- デフォルト・グループ

- 実行時グループ

- ベスト・プラクティス: Administratorsグループにユーザーの追加

- セキュリティ・ロールの概要

- セキュリティ・ロールのタイプ:グローバル・ロールとスコープ指定ロール

- デフォルト・グローバル・ロール

- セキュリティ・ロール条件

- 基本的なロール条件

- 日付と時刻のロール条件

- コンテキスト要素のロール条件

- 管理コンソールでのユーザー、グループ、ロールの管理

7 XACMLドキュメントによるWebLogicリソースの保護

- 前提条件

- レルムへのXACMLロールまたはポリシーの追加:主な手順

- 警告:不確定な結果によってすべてのユーザーがロックアウトされる可能性がある

- 保護するリソースの決定

- 保護するリソースのIDの取得

- XACMLドキュメントの作成

- 例: ロールの割当ての定義

- 例: 認可ポリシーを定義する

- WebLogic Scripting Toolを使用してレルムにロールまたはポリシーを追加する

- ロールまたはポリシーがレルムに存在するかどうかを確認する

- カスタムMBeanのロールまたはポリシーを作成する

- カスタムMBeanのリソースIDを決定する

- XACMLドキュメントへのロールおよびポリシーのエクスポート

A WebLogic ServerにおけるXACMLのリファレンス

- WebLogic ServerとXACMLのセキュリティ・モデルの比較

- 用語の比較

- データ型について

- アクション識別子

- 例

- 環境識別子

- 例

- ポリシーおよびポリシーセット識別子

- 例

- リソース識別子

- 例

- サブジェクト識別子

- 例

- WebLogic ServerのXACML関数

- カスタム・データ型のバリアント

- 例

- その他の関数

- 例

- 日付および時刻の変換

- 算術変換および算術関数

- オブジェクト型の変換

- オブジェクトの比較

- 文字列の比較と操作

- ルールおよびポリシーの結合アルゴリズム

Oracle® Fusion Middleware

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

12cリリース1 (12.1.1)

B65912-02(原本部品番号:E24421-02)

2012年1月

セキュリティ・ロールおよびセキュリティ・ポリシーを使用してドメイン内のリソースにアクセスできるユーザーを決定する、セキュリティ・アーキテクトおよびセキュリティ管理者向けのドキュメントです。

Oracle Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護, 12cリリース1 (12.1.1)

B65912-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 America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

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

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

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

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

はじめに

「はじめに」では、このガイド『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セキュリティ・サービスでは、セキュリティ機能の複数のレイヤーを組み合せることによりWebLogic Serverドメインに対する不正なアクセスを防ぎます。このマニュアルでは、ドメイン内のリソースにアクセスできるユーザーを決定するためのロールやポリシーの使用について説明します。ロールおよびポリシー機能には、よく知られているアクセス制御リスト(Access Control List : ACL)と同様の働きがありますが、ACL以上に高度な機能も備わっています。ACLの場合、ユーザーのリソースへのアクセス権を決める条件をロールとポリシーで指定する作業は静的であり、条件の評価は実行時に行われます。

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

- ドキュメントの内容と対象読者

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

- 関連情報

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

ドキュメントの内容と対象読者

このマニュアルでは、WebLogic Serverドメイン内のリソースに対するセキュリティ方法を設計する、セキュリティ設計者やセキュリティ管理者のための情報を提供します。リソースのタイプ、WebアプリケーションやEJBを保護するためのオプション、様々なタイプのセキュリティ・ロールおよびポリシー、ロールおよびポリシーの構成要素などについて取扱います。

このマニュアルは、Java EEセキュリティやWebLogicセキュリティ・サービスの他の機能に精通している読者を対象としています。

このドキュメントは、ソフトウェア・プロジェクトの設計段階と開発段階に関する情報を説明するものです。プロダクション段階の管理に関するトピックを取り扱うものではありません。そのようなトピックに関するWebLogic Serverのマニュアルや情報源へのリンクについては、「関連情報」を参照してください。

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

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

- この章第1章「概要とロードマップ」では、このガイドの構成を紹介します。

- 第2章「WebLogicリソースのセキュリティについて」では、用語と概念を紹介し、処理の流れを概説してWebLogicリソースを保護するための主な手順について簡単に示します。

- 第3章「ポリシーで保護できるリソースのタイプ」では、WebLogic Server管理コンソールを使用して保護できる様々なWebLogicリソースのタイプについて説明します。

- 第4章「WebアプリケーションおよびEJBリソースの保護のオプション」では、デプロイメント記述子またはWebLogic Server管理コンソールを使用してEJBおよびWebアプリケーション・リソースを保護するためのオプションについて説明します。

- 第5章「セキュリティ・ポリシー」では、セキュリティ・ポリシーについて説明します。これにはWebLogic Serverのデフォルト・セキュリティ・ポリシーの説明も含まれます。さらに、セキュリティ・ポリシーの構成要素についても説明します。

- 第6章「ユーザー、グループ、セキュリティ・ロール」では、WebLogicリソースにアクセスするユーザーおよびグループについて説明します。これにはWebLogic Serverのデフォルト・グループの説明も含まれます。また、スコープ指定セキュリティ・ロールおよびグローバル・セキュリティ・ロールについても説明します。最後の節では、セキュリティ・ロールの構成要素について説明します。

- 第7章「XACMLドキュメントによるWebLogicリソースの保護」では、認可ポリシーおよびロールの割当てを記述するためのXML言語であるXACML (eXtensible Access Control Markup Language)について説明します。

- 付録A「WebLogic ServerにおけるXACMLのリファレンス」では、XACML 2.0ドキュメントを記述してWebLogic Server上のリソースを保護する場合に使用できる拡張について説明します。また、WebLogic ServerでXACMLを使用する場合の制約についても説明します。

関連情報

WebLogicリソースを保護するセキュリティ管理者にとって、この他に重要と考えられるWebLogic Serverマニュアルを以下に示します。

- 『Oracle WebLogic Serverセキュリティの理解』 - WebLogicセキュリティ・サービスの機能の概要で、このサービスのアーキテクチャと働きについて説明します。WebLogicセキュリティを理解するための基礎となるドキュメントです。

- 『Oracle WebLogic Serverの保護』 - インストール済のWebLogic Serverに対して包括的にセキュリティを構成する方法を説明しています。セキュリティ・プロバイダ、ID、信頼、SSLなどの情報が含まれます。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのロールとポリシーを使用したリソースの保護に関する項 - このドキュメントで説明するタスクをWebLogic Server管理コンソールで実行する手順について、段階を追って説明します。

以下のマニュアルに、特定のタイプのリソースに関する詳細な情報が記載されています。

- 『Oracle WebLogic Serverセキュリティのプログラミング』のWebアプリケーションのセキュリティに関する項、Enterprise JavaBean (EJB)のセキュリティ対策に関する項、およびJavaセキュリティを使用してのWebLogicリソースの保護に関する項

- 『Oracle WebLogic Server JCOMのプログラミング』(COMリソース)のアクセス制御の構成に関する項

- 『Oracle WebLogic Serverリソース・アダプタのプログラミング』(EISリソース)の「セキュリティ」

- 『Oracle WebLogic Server WebLogic Webサービスの保護』

チュートリアルとサンプル

セキュリティ関連の他のマニュアルは、『Oracle WebLogic Serverの理解』のサンプル・コードおよびサンプル・アプリケーションに関する項に示されています。

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

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

2 WebLogicリソースのセキュリティについて

この章では、用語と概念を説明し、処理の流れを概説してWebLogicリソースを保護するための主な手順について簡単に示します。

この章の内容は以下のとおりです。

- WebLogicリソースの保護の概要

- WebLogicリソースのロールとポリシーの設計:主な手順

WebLogicリソースの保護の概要

WebLogic Serverドメインのリソースを保護するには、ポリシーと(必要に応じて)ロールを作成します。リソースとは、エンティティ(Webサービスやサーバー・インスタンスなど)またはアクション(Webサービス内のメソッドや、サーバー・インスタンスを停止する操作など)です。ポリシーでは、一定の条件下でリソースにアクセスできるユーザー、グループ、またはロールを指定します。セキュリティ・グループなどのセキュリティロールによって、ユーザーにIDが付与されます。ただしグループとは違い、ロールのメンバーシップは実行時に評価される条件群に基づきます。

図2-1に、ロールとポリシーの作成方法と、セキュリティ・サービスがそれらを使用してクライアントからリソースにアクセスできるかどうかを決定する方法を示します。図の後には簡単な説明を記載します。

表2-1 ポリシーによるリソースへのアクセス付与方法

「図2-1 ポリシーによるリソースへのアクセス付与方法」の説明

1. セキュリティ・ポリシーやセキュリティ・ロールを作成する前には、管理者が組織的な境界を表すグループにユーザーを静的に割り当てます。同じユーザーが複数のグループのメンバーになれます。図2-1には、それぞれ2ユーザーが割り当てられた3つのグループが示されています。ユーザー1とユーザー3は複数のグループのメンバーです。
多数のユーザーを抱えている場合に管理者の作業効率を向上できるので、ユーザーはグループに割り当てることをお薦めします。

2. 管理者は、自社の確立されたビジネス手順に基づいてセキュリティ・ロールを作成します。セキュリティ・ロールは1つまたは複数の条件で構成され、この条件によって特定のユーザー、グループ、または他のロールにセキュリティ・ロールが付与される状況が指定されます。

3. 実行時に、セキュリティ・サービスにより1つまたは複数のロール条件とグループが比較され、そのグループのユーザーに動的にセキュリティ・ロールを付与するかどうかが決定されます。このロールとグループを比較するプロセスをロール・マッピングと呼びます。図2-1では、グループ2のみにセキュリティ・ロールが付与されています。
個々のユーザーにセキュリティ・ロールを付与することもできますが、これは一般的ではありません。

4. 管理者は、自社の確立されたビジネス手順に基づいてセキュリティ・ポリシーを作成します。セキュリティ・ポリシーは1つまたは複数のポリシー条件から構成されています。ポリシー条件には、特定のセキュリティ・ロールにWebLogicリソースへのアクセス権を付与する状況が指定されます。

5. 実行時に、WebLogicセキュリティ・サービスにより、セキュリティ・ポリシーを使用して、保護対象WebLogicリソースへのアクセス権を付与するかどうかが決定されます。セキュリティ・ロールを付与されたグループのメンバーであるユーザーのみが、WebLogicリソースにアクセスできます。図2-1のユーザー3とユーザー6はグループ2のメンバーで、グループ2に必要なセキュリティ・ロールが付与されているので、保護対象WebLogicリソースにアクセスできます。

ポリシーを使用して複数のリソースの保護

WebLogic Serverでは、1つのポリシーを使用してリソースの集合を保護する方法が2つあります。

- タイプ別の保護ポリシー

- リソースの階層の保護

タイプ別の保護ポリシー

特定のタイプのリソースをすべて保護するポリシーを作成することができます。このようなポリシーをルート・レベルのポリシーといいます。たとえば、Webサービス・タイプのルート・レベルのポリシーを作成することもできます。このルート・レベルのポリシーを定義したドメインにデプロイされるすべてのWebサービスは、ルート・レベルのポリシーによって保護されます。

特定のWebサービスのポリシーが定義されている場合は、Webサービスはそれぞれのポリシーによって保護され、ルート・レベルのポリシーは無視されます。

リソースの階層の保護

デプロイ対象のJava EEアプリケーションまたはモジュール内のすべてのリソースは階層内に存在し、階層の上位に存在するリソースのポリシーは、同じ階層の下位に存在するリソースに対してデフォルトのポリシーとして機能します。下位階層のポリシーは、常に上位階層のポリシーをオーバーライドします。

たとえば、EnterpriseApp1にはWebアプリケーションとJDBCモジュールとともに、EJB ModuleAが含まれています(図2-2を参照)。EnterpriseApp1用とEJB ModuleA内のメソッドY用にポリシーを作成します。EJBクライアントがメソッドYを呼び出す際、WebLogicセキュリティ・サービスは特定のポリシーを適用し、エンタープライズ・アプリケーション用のポリシーを無視します。

クライアントがEJBメソッドXへのアクセスを要求する際、EJBメソッドXが独自のポリシーによって保護されていない場合には、WebLogicセキュリティ・サービスから次の情報を求められます。

1. このEJBメソッドにはポリシーがあるか。ない場合は、階層の次の上位レベルに移動します。

2. このメソッドを含むEJBにはポリシーがあるか。ない場合は、階層の次の上位レベルに移動します。

3. このメソッドの親EJBを含むEJBモジュールにはポリシーがあるか。ない場合は、階層の次の上位レベルに移動します。

4. このURLパターンを含むエンタープライズ・アプリケーションにはポリシーがあるか。ある場合、このポリシーを適用します(このようなポリシーが存在しない場合は、EJBに対してデフォルトのルート・レベルのポリシーが適用されます)。

図2-2 リソースとポリシーの階層

「図2-2 リソースとポリシーの階層」の説明

管理コンソールにおいて、セキュリティ・レルムの「ロールとポリシー: ポリシー」ページで、リソースとポリシーの階層をグラフィカルに確認できます。このページへのアクセスについては、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのリソース・インスタンスのポリシーの作成に関する項を参照してください。

WebLogicリソースのロールとポリシーの設計:主な手順

ドメイン内のリソースを保護する一連のロールとポリシーは、次のような手順で設計できます。

1. ドメインに含めるリソースをすべてリストアップして、特定のユーザーやグループにアクセスを限定するリソースを決定します。
特定のドメインに含まれるリソースのタイプの一覧については、第3章「ポリシーで保護できるリソースのタイプ」を参照してください。

プランニングのためにリソースを以下のカテゴリに分類します。

- サーバー・リソース、管理リソース、およびJMXリソース。サーバー・リソースは、サーバー・インスタンスの起動と停止を誰が実行できるのかを決定します。管理リソースでは、アカウントからロックアウトされたユーザーのロック解除、ファイルのアップロード(デプロイ中に使用)、ドメインおよびサーバーのログの表示といった作業を誰が実施できるのかが決定されます。JMXリソースでは、サーバー、クラスタ、マシン、およびドメインの構成ドキュメント(config.xml)に定義されている他のコンポーネントの構成の変更を誰が実施できるのかが決定されます。
これらのタスクについては階層化された詳細なセキュリティ方式があらかじめ用意されていて、それによって8つのセキュリティ・ロール(Admin、Deployer、Operator、Monitor、Anonymous、AppTester、CrossDomainConnector、AdminChannelUser)に対し様々なタイプのアクセスが付与されます。ほとんどの環境においては、このセキュリティ方式で十分に対応できます。その場合、必要な作業は上記の8つのデフォルト・セキュリティ・ロールに適切にユーザーを割り当てることだけです(手順3を参照)。

この階層化されたセキュリティ方式は部分的に変更することもできますが、そうした変更は通常であれば必要ありません。変更する場合には、別のレイヤーとの間で一貫性を維持するために綿密な計画を立てる必要があります。「管理リソース」、「サーバー・リソース」、および「JMXリソース」を参照してください。

- Webアプリケーション・リソースとEJBリソース。ドメインにデプロイしたWebアプリケーションやEJBに誰がアクセスできるのかを決定します。
Java EEプラットフォームでは、以前からWebアプリケーションとEJBを保護するための標準モデルが提供されています。この標準モデルでは、開発者がロール・マッピングやポリシーをWebアプリケーションまたはEJBのデプロイメント記述子に定義します。

この標準モデルまたは管理コンソールを使用してポリシーとロールを定義でき、それによって統合的で動的なセキュリティ管理が可能になります。第4章「WebアプリケーションおよびEJBリソースの保護のオプション」を参照してください。

- 上記以外の全リソース。エンタープライズ・アプリケーション内のビジネス・ロジックやビジネス・コンテンツ、およびドメインにデプロイまたは構成する他のモジュールに対して、誰がアクセスできるのかを決定します。
デフォルトでは、これらのリソースはポリシーによって保護されません。ポリシーを定義して誰がアクセスできるのかを決定する必要があります。

2. 保護の対象とする各リソースのタイプについて、ルート・レベルのポリシー、スコープ指定ポリシー、またはその両方の組合せが必要がどうかを決定します。
ルート・レベルのポリシーは、あるリソース・タイプの全インスタンスに適用されます。たとえば、Webサービス・リソース・タイプにルート・レベルのポリシーを定義すると、そのポリシーはドメイン内のすべてのWebサービスに適用されます。

スコープ指定ポリシーは、特定のリソース・インスタンスに適用され、ルート・レベルのポリシーはオーバーライドされます。

第5章「セキュリティ・ポリシー」を参照してください。

3. ユーザーと、ユーザーがアクセスするリソースを分析します。ユーザーを次のようにセキュリティ・グループとロールに分類します。

- サーバーの起動と停止、または他の管理タスクに関わるユーザーを8つのデフォルト・グローバル・ロールのどれかに追加します。WebLogic Serverのセキュリティ方式では、こうしたタスクの多くについて、この8つのグローバル・ロールにのみ実行が許可されます。

- これ以外のユーザー(管理リソースやサーバー・リソースへのアクセスは付与せず、ポリシーが定義された他のリソースへのアクセスは付与するユーザー)用に、セキュリティ・グループとロールを別に作成します。ロール・メンバーシップは実行時に付与できるため、ビジネス・ルールやリクエストのコンテキストに基づいて、ユーザーやグループをロールに設定できます。
すべてのポリシーで使用できるグローバルロールや、特定のリソース・インスタンス用のポリシーでのみ使用できるスコープ指定ロールを作成できます。

第6章「ユーザー、グループ、セキュリティ・ロール」を参照してください。

4. 管理コンソールを使用して、ユーザー、グループ、ロール、およびポリシーを作成します。

1. ユーザーとグループの作成については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザーとグループの管理に関する項を参照してください。

2. セキュリティ・ロールの作成については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ロールの管理に関する項を参照してください。

3. セキュリティ・ポリシーの作成については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ポリシーの管理に関する項を参照してください。

ベスト・プラクティス:ポリシーへの条件指定とロールへの条件指定

ロールとポリシーのどちらを使用しても実行時に一連の条件を評価できます。そのため、セキュリティ・データのどの部分を静的とし、どの部分を動的とするかを検討する必要があります。たとえば、あるリソースへのアクセスを1つの特定のロールに常に許可するポリシーが複数必要な場合には、ロールの定義で条件を使用して、必要に応じてそのロールにユーザーを追加したり削除したりするようにします。一方で、静的なロールを定義して、時間に応じて様々なロールにアクセスを許可するポリシーを作成する方式が適していることもあります。

一般的なガイドラインとしては、リソースにアクセスできるエンティティ(ロール)ではなく、リソースに基づいて認可判定を行う場合には、セキュリティ・ポリシーに条件を追加します。リソースに誰がアクセスできるのかということに基づいて認可を行う場合には、セキュリティ・ロールに条件を追加します。

リソースに誰がアクセスできるのかに基づく認可の例として、管理者(manager)が休暇を取る場合を検討します。このような場合、あるユーザーを一時的にManagerセキュリティ・ロールに設定できます。このセキュリティ・ロールを動的に付与することで、そうした一時的な措置のためにアプリケーションを変更したり再デプロイしたりする必要はなくなります。一時的な管理者が特別な権限を持つ期間を指定するだけです。さらに、本来の管理者が戻ってきても、ユーザーを一時的に管理者グループに追加した場合のように、特別な特権を取り消す必要もありません。

ベスト・プラクティス: WebLogicプロバイダの使用時に資格のキャッシングを構成する

WebLogic認可プロバイダ(DefaultAuthorizer)およびWebLogicロール・マッピング・プロバイダ(DefaultRoleMapper)は、ロール、述部、およびそれらをルックアップするリソース・データをキャッシュすることでパフォーマンスが向上します。これらのWebLogicプロバイダを使用するようレルムを変更する際、キャッシュ内に格納する項目の最大数を構成できます。

注意:

デフォルトでは、新しく作成されるドメイン内のセキュリティ・レルムにはXACML認可プロバイダとロール・マッピング・プロバイダが含まれています。XACMLプロバイダは独自のキャッシュを使用しますが、このキャッシュは構成できません。WebLogic Serverには、独自のポリシー言語を使用するWebLogic認可プロバイダ(DefaultAuthorizer)とWebLogicロール・マッピング・プロバイダ(DefaultRoleMapper)も用意されています。DefaultAuthorizerとDefaultRoleMapperは、資格データのキャッシュを構成できる唯一のWebLogic提供のセキュリティ・プロバイダです。

WebLogic認可プロバイダとロール・マッピング・プロバイダでは、各キャッシュ内に次の項目数がデフォルトで格納されます。

- 2,000項目(ロールのキャッシュ内)
このキャッシュには、ルックアップされた各ロールの名前やロールを保護するポリシーが格納されます。

- 200項目(述部のキャッシュ内)
このキャッシュには、WebLogic資格エンジンによってルックアップされた各述部が格納されます。

- 5,000項目(リソースのキャッシュ内)
このキャッシュには、ルックアップされた各リソースの名前やリソースを保護するポリシーが格納されます。

キャッシュの最大サイズを超えると、WebLogic資格エンジンは最長時間未使用(LRU)項目をキャッシュから削除します。

WebLogic Serverインスタンスのアプリケーションで2,000ロールまたは5,000リソースを超えて使用する場合は、キャッシュ・サイズを増やす必要があります(述部の場合はWebLogicプロバイダに含まれる項目数が50未満なので、このキャッシュのサイズを増やす必要はありません)。

キャッシュに格納される項目の最大数を変更するには、WebLogic Serverインスタンスのjava起動コマンドに次のシステム・プロパティのいずれかを指定します。

- -Dweblogic.entitlement.engine.cache.max_role_count=max-roles
ただし、max-rolesはキャッシュするロールの最大数です。

- -Dweblogic.entitlement.engine.cache.max_predicate_count=max-predicates
ただし、max-predicatesはキャッシュする述部の最大数です。

- -Dweblogic.entitlement.engine.cache.max_resource_count=max-resources
ただし、max_resource_countはキャッシュするリソースの最大数です。

デフォルトでは、WebLogicプロバイダは項目の使用時にその項目をキャッシュに追加します。この構成によって、資格データの最初のルックアップは、以降のルックアップよりも時間がかかります。ただし、WebLogic Serverインスタンスの起動サイクル中にキャッシュをロードするよう構成することによって、最初のルックアップにかかる時間を短縮できます。それには、サーバーのjava起動コマンドに次のシステム・プロパティを指定します。

-Dweblogic.entitlement.engine.cache.preload=true

例:

java -Dweblogic.entitlement.engine.cache.max_role_count=6001 -Dweblogic.entitlement.engine.cache.max_resource_count=3001 -Dweblogic.entitlement.engine.cache.preload=true weblogic.Server

3 ポリシーで保護できるリソースのタイプ

この章では、WebLogic Serverのポリシーを使用して保護できるリソースのタイプについて説明します。

この章の内容は以下のとおりです。

- 管理リソース

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

- COMリソース

- EJBリソース

- エンタープライズ情報システム(EIS)リソース

- Java DataBase Connectivity (JDBC)リソース

- Java Messaging Service (JMS)リソース

- Java Naming and Directory Interface (JNDI)リソース

- JMXリソース

- サーバー・リソース

- URLリソース

- Webサービス・リソース

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

管理リソース

管理リソースのポリシーでは、ファイルのアップロード(デプロイ中に使用)、ドメインおよびサーバーのログの表示、アカウントからロックアウトされたユーザーのロック解除といった作業を誰が実施できるのかが決定されます。

こうしたセキュリティに厳しいタスクでは多くの場合、はじめに別のJMXリソースのセキュリティ・ポリシーでユーザーが認可されている必要があります(図3-1を参照)。JMXリソースと、複数のリソースによって保護されるアクティビティのロールおよびポリシーの設計方法の詳細は、「JMXリソース」を参照してください。

図3-1 一部のポリシーの重なり

「図3-1 一部のポリシーの重なり」の説明

表3-1で、管理リソースによって保護される管理アクティビティについて説明します。また、これらのアクティビティの一部は別のJMXリソースによっても保護されます。複数のリソースによって保護されるアクティビティの場合、JMXリソースのデフォルトのポリシーが管理リソースの保護と重複します。

表3-1 管理リソースにおけるアクティビティとデフォルトのポリシー

管理アクティビティ

デフォルトのポリシーで許可されるロール

JMXリソースにも保護されているか

デプロイメント用のファイルのアップロード。

Admin、Deployer

いいえ

ファイル・ダウンロード・サーブレットの以下のメソッドに対する制御アクセス。

- すべてのメソッド

- wl_component_request

- wl_ear_resource_request

- ear_request

- wl_xml_entity_request

- wl_jsp_refresh_request

- file

- wl_init_replica_request

- wl_file_realm_request

- wl_managed_server_independence_request

注意: ファイル・ダウンロード・サーブレットはWebLogic Serverで内部的に使用されます。ファイル・ダウンロード・サーブレットのメソッドに対するデフォルトのポリシーは変更しないことを推奨します。ここでは、構成全体を網羅するために表示されています。

Admin、Operator

いいえ

アプリケーションでのIDアサーションの有効化。

このアクティビティのデフォルトのポリシーでは、Adminロールのユーザーが正常にAuthentication.assertIdentity() APIを呼び出すには、アプリケーションでそのユーザーにあらかじめ資格証明を提供する必要があります。

Oracle WebLogic Server APIリファレンスのweblogic.security.services.Authenticationに関する項を参照してください。

Admin

いいえ

管理コンソールでのドメイン・ログとサーバー・ログの表示。

Admin、Deployer、Operator、Monitor

はい

アカウントからロックアウトされたユーザーのロック解除。

Admin

はい

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

アプリケーション・リソースは、エンタープライズ・アプリケーション、Webアプリケーション、またはスタンドアロンのアプリケーションとしてデプロイされるその他のJava EEモジュールです(たとえば、WebサービスやJDBCモジュールをスタンドアロンのアプリケーションとしてデプロイできます)。アプリケーションを構成するすべてのリソースを保護する場合には、アプリケーション・リソースを保護します。たとえば、エンタープライズ・アプリケーションを保護することによって、そのアプリケーション内のすべてのWebLogicリソースへのアクセスが保護されます。(図3-2を参照)

図3-2 アプリケーション・リソースによるすべてのリソースの保護

「図3-2 アプリケーション・リソースによるすべてのリソースの保護」の説明

「リソースの階層の保護」を参照してください。

COMリソース

COMリソースは、1つまたは複数のjCOMクラスを含むパッケージです。jCOMは、WebLogic ServerでデプロイされるJava/Java EEオブジェクトと、Microsoft Office製品ファミリ、Visual BasicオブジェクトおよびC++オブジェクト、その他のコンポーネント・オブジェクト・モデル/分散コンポーネント・オブジェクト・モデル(COM/DCOM準拠)環境で使用できるMicrosoft ActiveXコンポーネントとの間で双方向アクセスを可能にするソフトウェア・ブリッジです。

COMリソースのポリシーによって、パッケージ内のすべてのjCOMオブジェクトへのアクセスは保護されます。

詳細は、『Oracle WebLogic Server JCOMのプログラミング』のアクセス制御の構成に関する項を参照してください。

EJBリソース

EJB (Enterprise JavaBean)リソースは、EJBデプロイメント・モジュール(JAR)、個々のEJB、またはEJBの個々のメソッドです。EJBリソースはリソースの階層内に存在し、階層の最上位がアプリケーション・リソースです。「リソースの階層の保護」を参照してください。

Java EEプラットフォームはデプロイメント記述子でEJBのセキュリティを標準化しているので、WebLogic Serverではこの標準メカニズムがWebLogicセキュリティ・サービスに統合され、EJBリソースを保護する方法を選択できるようになっています。詳細は、第4章「WebアプリケーションおよびEJBリソースの保護のオプション」を参照してください。

エンタープライズ情報システム(EIS)リソース

EISリソースは、システム・レベルのソフトウェア・ドライバであり、WebLogic Serverなどのアプリケーション・サーバーでエンタープライズ情報システム(EIS)に接続するために使用されます。Oracleでは、EISベンダーおよびサード・パーティのアプリケーション開発者によって開発されたリソース・アダプタをサポートしています。リソース・アダプタは、適切なJava EEプラットフォーム仕様をサポートしているアプリケーション・サーバーであればどのサーバーにもデプロイできます。リソース・アダプタには、Javaコードに加えて、必要な場合にはEISとの対話に必要なネイティブ・コンポーネントが含まれます。

EISへのアクセスを保護するには、グループとしてすべてのリソース・アダプタに対して、または個々のリソース・アダプタに対してセキュリティ・ポリシーとセキュリティ・ロールを作成します。これらのリソースはリソースの階層内に存在し、階層の最上位がアプリケーション・リソースです。「リソースの階層の保護」を参照してください。

詳細は、『Oracle WebLogic Serverリソース・アダプタのプログラミング』の「セキュリティ」を参照してください。

Java DataBase Connectivity (JDBC)リソース

Java DataBase Connectivity (JDBC)リソースは、JDBCシステム・リソース、アプリケーションの一部となるJDBCモジュール、JDBCデータ・リソース、またはデータ・ソース内の特定のメソッドです。JDBCモジュールをスタンドアロンのアプリケーションとしてデプロイする場合、アプリケーションはアプリケーション・リソースによって表されます(「アプリケーション・リソース」を参照)。

JDBCリソースはリソースの階層内に存在し、階層の最上位がアプリケーション・リソースです。「リソースの階層の保護」を参照してください。

JDBC操作

個々のデータ・ソースを保護する場合、以下に示す1つまたは複数の管理者用メソッドを使用してJDBC操作を保護するかどうかを選択できます。

- admin - JDBCDataSourceRuntimeMBeanのclearStatementCache、suspend、forceSuspend、resume、shutdown、forceShutdown、start、getProperties、およびpoolExistsの各メソッドはadmin操作として呼び出されます。

- reserve - アプリケーションでは、データ・ソースをルックアップしてからgetConnectionを呼び出すことにより、データ・ソース内で接続を予約します。

注意:

reserveパーミッションを与えるとユーザーはベンダー固有の操作を実行できるようになります。データベース・ベンダーによっては、こうした操作の一部がデータベースのセキュリティに影響する場合があります。

- shrink - データ・ソースの接続数を現在予約される接続の最大数または初期サイズに縮小します。

- reset - すべての物理的なデータベース接続を停止し、再確立することで、データ・ソースの接続をリセットします。また、それぞれの接続の文キャッシュをクリアします。リセットできるデータ・ソースの接続は、正常に動作しているものに限られます。

- All - 個々のデータ・ソースは、管理者用メソッドAdmin、reserve、shrink、およびresetの結合によって保護されます。

注意:

以下の点に注意します。

- セキュリティ・ポリシーでマルチ・データ・ソース内の接続へのアクセスを制御している場合は、アクセス・チェックがJDBCリソース階層の両方のレベルで行われます(まずマルチ・データ・ソース・レベルで行われ、次に個々のデータ・ソース・レベルで行われます)。すべてのタイプのWebLogicリソースと同じように、こうした二重チェックを行うことで、セキュリティ・ポリシーによる最も限定したアクセス制御を確実に行うことができます。

- Oracleデータベースを使用している場合、Oracle仮想プライベート・データベース(Oracle Virtual Private Database : VPD)を使用してもJDBCリソースへのアクセスを制御できます。詳細は、『Oracle WebLogic Server JDBCのプログラミング』のOracle仮想プライベート・データベースを使用したプログラミングに関する項を参照してください。

Java Messaging Service (JMS)リソース

Java Messaging Service (JMS)リソースは、JMSシステム・リソース、アプリケーションの一部となるJMSモジュール、JMS宛先、または宛先内の操作です。グループとしてすべての宛先(JMSキューおよびJMSトピック)に対して、またはJMSサーバー上の個々の宛先(JMSキューおよびJMSトピック)に対してセキュリティ・ポリシーとセキュリティ・ロールを作成できます。

これらのリソースはリソースの階層内に存在し、階層の最上位がアプリケーション・リソースです。「リソースの階層の保護」を参照してください。

JMS操作

JMSサーバーの特定の宛先を保護する場合、その宛先の操作を保護できます。デフォルトでは宛先は保護されていません。つまり、WebLogic Serverインスタンスの有効なユーザーであれば、誰でも宛先に対してメッセージの送受信や参照ができることになります。ポリシー条件に定義されているユーザーのみが宛先のアクセスを制御できます。有効な保護対象の操作は以下のとおりです。

- send - キューまたはトピックにメッセージを送信するために必要です。メッセージング・ブリッジだけでなく、MessageProducer.send()、QueueSender.send()、およびTopicPublisher.publish()の各メソッドの呼出しも含まれています。

- receive - キューまたはトピックでコンシューマを作成するために必要です。メッセージング・ブリッジおよびメッセージドリブンBeanに加えて、Session.createConsumer()、Session.createDurableSubscriber()、QueueSession.createReceiver()、TopicSession.createSubscriber()、TopicSession.createDurableSubscriber()、Connection.createConnectionConsumer()、Connection.createDurableConnectionConsumer()、QueueConnection.createConnectionConsumer()、TopicConnection.createConnectionConsumer()、およびTopicConnection.createDurableConnectionConsumer()の各メソッドの呼出しも含まれています。

- browse - QueueBrowserインタフェースを使用してキューのメッセージを表示するために必要です。

- All - 宛先のsend、receive、およびbrowseメソッドのために必要です。

Java Naming and Directory Interface (JNDI)リソース

Java Naming and Directory Interface (JNDI)リソースは、サーバーのJNDIツリーのノードです。JNDIリソースのポリシーでは、JNDIを通じてWebLogic Serverのエンティティおよびアクションに誰がアクセスできるのかが決定されます。ポリシーは、JNDIツリーのルート・ノードまたは個々のノードに作成できます。

JNDI操作

JNDIノードごとに、すべての操作または以下の操作のいずれかに対してポリシーを作成できます。

- modify - アプリケーションでJNDIツリーを何らかの方法で修正(つまり追加、削除、変更)するときには、現在のユーザーに必ず修正のパーミッションが必要です。bind()、rebind()、createSubContext()、destroySubContext()、およびunbind()の各メソッドが含まれています。

- lookup - アプリケーションでJNDIツリーのオブジェクトをルックアップするときには、現在のユーザーにルックアップのパーミッションが必要です。lookup()メソッドおよびlookupLink()メソッドが含まれています。

- list - アプリケーションでJNDIのコンテキストの内容をリストするときには、現在のユーザーにリスト操作を実行するパーミッションが必要です。list()メソッドおよびlistBindings()メソッドが含まれています。

JMXリソース

JMXリソースは、MBean属性またはMBean操作です。JMXリソースのポリシーでは、MBean属性の読み取りまたは書き込み、または操作の呼出しを誰が実施できるのかが決定されます。

WebLogic Serverの管理システム実装では、管理対象Bean (MBean)が使用されます。ほとんどすべての管理アクティビティで、MBeanの操作の呼出しやMBean属性の変更が必要になります。これにはJava Management Extensions (JMX)クライアントを使用します。JMXクライアントの例として管理コンソールがあります。管理コンソールを使用してサーバーのリスニング・ポートの値を変更すると、対応するMBean属性の値が管理コンソールによって変更されます。また、WebLogic Scripting ToolもJMXクライアントです。詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeanに関する項を参照してください。

WebLogic Server MBeanを保護するためのJMXリソースのデフォルト・セットが用意されています。(Oracle WebLogic Server MBeanリファレンスのMBeanのデフォルトのセキュリティ・ポリシーに関する項を参照してください。)特に重要なデータやアクションを表すMBeanの属性と操作の場合、別のリソース・タイプも使用してアクセスを保護します。たとえば、ServerLifeCycleRuntimeMBeanのshutdown()操作はJMXリソースとサーバー・リソースによって保護されます。

JMXクライアントで、JMXリソースと他のリソース・タイプで保護されている操作を呼び出したり属性を変更したりする場合、クライアントは両方のリソースに定義されているポリシーに合致している必要があります(図3-3を参照)。

図3-3 MBeanサーバーの両方のリソースによる検証

「図3-3 MBeanサーバーの両方のリソースによる検証」の説明

一貫性のあるセキュリティ方式の維持

エンティティやアクションを保護するのに使用されるすべてのリソースのグループ、グローバル・ロール、セキュリティ・ポリシーのデフォルト構成によって、一貫性のあるセキュリティ方式が作成されます。しかし、変更を行うことで、意図しないアクセス制限が発生する場合があります。デフォルトのセキュリティ設定に対する変更が、JMXリソースと別のリソースの両方のリソース・タイプによるユーザーの認可を妨げないことを確認してください。セキュリティ・ポリシーを作成または変更する際には、以下のことを検討します。

- サーバー・リソースのポリシーに、常にAdminグローバル・ロールとOperatorグローバル・ロールを含めます。
Operatorグローバル・ロール、またはこのデフォルト・グローバル・ロール内にネストされたセキュリティ・ロールが使用できない場合、WebLogicセキュリティ・サービスで矛盾した動作が発生する場合があります。

- Webアプリケーション、EJBモジュール、コネクタ・モジュール、起動/停止クラスなどのデプロイ可能リソースのセキュリティ・ポリシーでは、Deployerグローバル・ロールを使用します。

サーバー・リソース

サーバー・リソースのポリシーでは、WebLogic Serverのサーバー・インスタンスの状態を誰が制御できるのかが決定されます。

ユーザーが直接Javaコマンドでweblogic.Serverクラスを呼び出してサーバー・インスタンスを起動する場合、サーバー・リソースのポリシーによるセキュリティ・チェックのみが実施されます。WebLogic Serverインスタンスの状態を変更する他のすべてのタスクは、管理コンソール、WebLogic Scripting Tool、ノード・マネージャ、または他のJMXクライアントを使用する必要があります。したがって、ユーザーが最初に別のJMXリソースで認可されている必要があります。「JMXリソース」を参照してください。

ドメイン内のすべてのWebLogic Serverインスタンスに適用するセキュリティ・ポリシーや、個々のサーバーに適用するセキュリティ・ポリシーを作成できます。個々のサーバーに対するポリシーを定義する場合、そのサーバーのライフ・サイクル全般に渡るすべての操作を保護することも、以下の各操作に対して個別にポリシーを定義することもできます。

- boot - WebLogic Serverインスタンス(管理サーバーまたは管理対象サーバー)を起動しようとするユーザーには、そのためのパーミッションが必要です。このアクションは通常、コマンド・ラインでのjava weblogic.Serverコマンドの呼び出し、構成されている起動スクリプト(java weblogic.Serverコマンドを呼び出す)、またはノード・マネージャのWebLogic Serverをリモートで起動できる機能を通じて開始します。

- shutdown - 動作中のWebLogic Serverインスタンス(管理サーバーまたは管理対象サーバー)を停止しようとするユーザーには、そのためのパーミッションが必要です。このアクションは通常、WebLogic Server管理コンソール、またはWLST SHUTDOWNコマンドかFORCESHUTDOWNコマンドを通じて開始します。

- suspend - 動作中のWebLogic Serverインスタンス(管理サーバーまたは管理対象サーバー)への追加ログイン(特権のある管理アクション以外を目的としたログイン)を禁止しようとするユーザーには、そのためのパーミッションが必要です。このアクションは通常、管理コンソールから開始します。

- resume - 動作中のWebLogic Serverインスタンス(管理サーバーまたは管理対象サーバー)への特権のないログインを再び有効にしようとするユーザーには、そのためのパーミッションが必要です。このアクションは通常、管理コンソールから開始します。

すべてのサーバー・リソースには、グローバル・セキュリティ・ロールAdminおよびOperatorにパーミッションを付与するデフォルト・セキュリティ・ポリシーが継承されます。

注意:

ドメイン全体の管理ポートを有効にする場合、AdminロールのみがWebLogic Serverサーバー・インスタンスの状態を制御できます(Operatorでは制御できません)。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメイン全体の管理ポートの構成に関する項を参照してください。

警告:

デフォルト・セキュリティ・ポリシーからはロールを削除しないでください。既存のセキュリティ・ロールの一部を削除すると、WebLogic Serverの動作に悪影響を与えることがあります。ただし、必要に応じて、デフォルト・セキュリティ・ポリシーにより多くを含めることはできます(たとえば、新しいセキュリティ・ロールを追加するなど)。「一貫性のあるセキュリティ方式の維持」を参照してください。

weblogic.Serverコマンド、ノード・マネージャのパーミッション

WebLogic Serverインスタンス(サーバー)を起動および停止するには、weblogic.Serverコマンドを使用する方法とノード・マネージャを使用する方法があります。weblogic.Serverコマンドとノード・マネージャでは基底のコンポーネントが異なるため、これら2つのコマンドでは異なる認可方法が使用されます。

weblogic.Serverコマンドを使用したパーミッション

weblogic.Serverコマンド(管理サーバーと管理対象サーバーの両方の起動に使用可能)では、サーバー・リソースのセキュリティ・ポリシーで保護されたメソッドが呼び出されます。このコマンドを使用するには、サーバー・リソースのセキュリティ・ポリシーの要件を満たす必要があります。

weblogic.Serverの引数の中にはMBeanの属性を設定するものもあります。ただし、これらの引数ではサーバーが実行中の状態(RUNNING)になる前にMBeanを変更するので、MBeanの保護ではなく、サーバー・リソースのセキュリティ・ポリシーによって認可されます。たとえば、Operatorグローバル・ロールに属するユーザーは-Dweblogic.ListenPort引数を使用してサーバーのデフォルトのリスニング・ポートを変更できますが、WebLogic Serverインスタンスが実行中の状態になると、このユーザーはリスニング・ポートの値を変更できません。

weblogic.Serverの詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンドライン・リファレンスに関する項を参照してください。

ノード・マネージャを使用したパーミッション

ノード・マネージャを使用すると、MBeanとサーバー・リソースのセキュリティ・ポリシーの両方を使用してリモート・サーバーを起動できます。

リモートWebLogic Serverインスタンスのホスト・マシン上にノード・マネージャが構成されている場合、デフォルトでAdminグローバル・ロールまたはOperatorグローバル・ロールに属するユーザーはノード・マネージャを使用してリモート・サーバーを起動できます。

ノード・マネージャの詳細は、『Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャの概要に関する項を参照してください。

WebLogic Serverインスタンスの停止においてもMBeanとサーバー・リソースのセキュリティ・ポリシーの両方が関与します。ユーザーが停止コマンドを発行すると、サーバーではまず、MBeanセキュリティ・レイヤーによってそのユーザーにAdminまたはOperatorグローバル・ロールが付与されているかどうかが確認されます。続いて、MBean操作の実行後、サーバー・リソースのセキュリティ・ポリシーによって、そのユーザーがサーバーを停止する権限を持っているかどうかが判別されます。

WebLogic Serverインスタンス停止の詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止のクイック・リファレンスを参照してください。

URLリソース

URLリソースは、Webアプリケーションの特定のURLまたはURLパターンです。特定のURLまたはURLパターンのすべてのHTTPメソッドを保護するURLリソースに対して、または特定のHTTPメソッドのみを保護するURLリソースに対してポリシーを作成できます。これらのリソースはリソースの階層内に存在し、階層の最上位がアプリケーション・リソースです。「リソースの階層の保護」を参照してください。

Java EEプラットフォームはデプロイメント記述子でWebアプリケーションのセキュリティを標準化しているので、WebLogic Serverではこの標準メカニズムがWebLogicセキュリティ・サービスに統合され、Webアプリケーション・リソースを保護する方法を選択できるようになっています。詳細は、第4章「WebアプリケーションおよびEJBリソースの保護のオプション」を参照してください。

Webサービス・リソース

Webサービス・リソースは、Webサービス・モジュール(WARやJAR)、またはWebサービス・モジュールの操作です。Webサービスは以下のリソースの階層によって保護されます。

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

- Webサービス・モジュール(WARまたはJAR)のWebサービス・リソース

- 各Webサービス操作の個々のWebサービス・リソース
Webサービスが標準Javaオブジェクトを使用して実装されている場合、上記のいずれかのリソースによってJavaオブジェクトは保護されます。

WebサービスがEJBを使用して実装されている場合、上記のいずれかのリソースまたは以下のいずれかのリソースによってEJB実装は保護されます。

- EJBのEJBリソース

- EJBメソッドの個々のEJBリソース

EJBを使用してWebサービスを実装する場合、アプリケーション・レベルでポリシーを作成することをお薦めします。Webサービス・モジュールおよびWebサービス操作に対するポリシーは、Webサービス・クライアントにのみ適用されます。EJBクライアントは、RMIまたはJNDIを使用して、Webサービス・モジュールを経由せずにEJB操作を直接呼び出すことができます(図3-4を参照)。

図3-4 EJB実装を使用したWebサービス・リソースの階層

「図3-4 EJB実装を使用したWebサービス・リソースの階層」の説明

JavaアノテーションによるWebサービスの保護については、『Oracle WebLogic Server WebLogic Webサービスの保護』のメッセージ・レベルのセキュリティに関する項を参照してください。

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

Java EEの開発者はワーク・コンテキストを使用すると、プロパティをリモート呼出しに含めずに定義して渡すことが可能です。ワーク・コンテキスト・リソースは、プロパティの作成、削除、読み取り、または変更を行う操作です。特定のプロパティのすべての操作に対して1つのワーク・コンテキスト・リソースを使用できます。また、操作ごとに個々のリソースを作成することもできます。

詳細は、『Oracle WebLogic Server RMIのプログラミング』のアプリケーション設計のベスト・プラクティスに関する項を参照してください。

4 WebアプリケーションおよびEJBリソースの保護のオプション

この章では、Java EE標準モデルを含め、WebアプリケーションとEJBリソースを保護するためのWebLogic Serverのオプションについて説明します。

Java EE標準モデルでは、次のいずれかの方法でWebアプリケーションとEJBを保護できます。

- デプロイメント記述子またはメタデータ・アノテーションを使用して宣言的に行う場合。
EJB 3.xの場合、EJBセキュリティ・メタデータ・アノテーションをEJB Beanクラスで直接指定して、EJBのすべてのメソッド(またはメソッドのサブセット)を呼び出すことができるロールを指定できます。

- 「EJBでのプログラム的セキュリティの使用」に従ってプログラム的に行う場合。
WebLogic Serverは、EJBにおけるプログラムによる認可を実装するために、EJBContext.isCallerInRoleメソッドとEJBContext.getCallerPrincipalメソッドの使用、およびデプロイメント記述子でのsecurity-role-ref要素の使用をサポートしています。

環境によってはこのJava EE標準では柔軟性に欠けることもあるので、WebLogic ServerにはJava EE標準以外の選択肢としてさらに柔軟性の高いモデルも用意されています。

注意:

JACC (JSR 115で定義されているJava Authorization Contract for Containers)を使用したセキュリティを実装する場合は、Java EE標準モデルを使用する必要があります。その他のWebLogic Serverモデルは使用できず、そのWebアプリケーションおよびEJB用のセキュリティ機能は管理コンソールでは無効になります。『Oracle WebLogic Serverセキュリティのプログラミング』のJava Authorization Contract for Containersの使用に関する項を参照してください。

この章の内容は以下のとおりです。

- Webアプリケーション、EJB用のセキュリティ・モデルの比較

- 詳細セキュリティ・モデルについて

- Webアプリケーション、EJBの保護

注意:

この節で説明されているEJBリソースに対する手順は、メッセージドリブンBean (MDB)にも適用できます。

不要になったデプロイメント記述子

「EJB 3.0の新機能と変更点」で示すとおり、デプロイメント記述子ファイル(ejb-jar.xmlなど)を作成する必要がなくなりました。Beanファイル自体の中で、メタデータ・アノテーションを使用してメタデータを構成できます。アノテーションを使用すると、コンテナ内でのBeanの動作、依存関係インジェクションの要求方法などをJavaクラス自体の中で指定でき、EJBの開発プロセスを簡略化できます。アノテーションは、EJBの2.x以前のバージョンで必要だったデプロイメント記述子にかわるものです。

ただし、選択すれば、メタデータ・アノテーションに加えて(またはメタデータ・アノテーションのかわりに)XMLデプロイメント記述子を使用できます。

注意:

デプロイメント記述子要素は、対応するアノテーションを常にオーバーライドします。競合がある場合、デプロイメント記述子の値がアノテーションの値をオーバーライドします。

Webアプリケーション、EJB用のセキュリティ・モデルの比較

EJBの場合、アプリケーション開発者は、EJBメソッドを呼び出すことができるセキュリティ・ロールを指定するためにセキュリティ関連メタデータ・アノテーションを使用することで、デプロイヤのタスクを推進できます。アノテーションまたはデプロイメント記述子を使用する場合、セキュリティ・モデルはWebアプリケーションまたはEJBをデプロイするたびに選択し、選択結果はそのデプロイメントの有効期間中には変えられません。別のモデルを使用する場合は、そのWebアプリケーションまたはEJBを削除してから再デプロイする必要があります。

デプロイメント記述子ベースの各セキュリティ・モデルは、WebアプリケーションおよびEJBの保護に関する2種類の動作、すなわち、ロールとポリシーがどこで定義されているか、および、どのようなURLパターンとEJBメソッドがセキュリティ・チェックを実行するセキュリティ・サービスをトリガーするかを定義します。

表4-1で、それぞれのモデルを比較します。

表4-1 セキュリティ・モデルの動作

モデル

使用するロールとポリシーの場所

セキュリティ・チェックの実施方式

メタデータ・アノテーション

管理コンソールのデプロイメント記述子のみ(Java EE標準)としてカテゴリ化

EJB Beanファイル自体のメタデータ・アノテーションは、EJBのすべてのメソッド(またはメソッドのサブセット)を呼び出すことができるロールを指定します。

クライアントから、アノテーションで指定されたロールで保護されているEJBメソッドが要求されたときのみ。

メタデータ・アノテーションはデプロイメント記述子(および管理コンソール)ベースのメカニズムと関連して使用できます。競合がある場合、デプロイメント記述子要素は対応するアノテーションを常にオーバーライドします。

デプロイメント記述子のみ(Java EE標準)

デプロイメント記述子web.xml、weblogic.xml、ejb-jar.xml、weblogic-ejb-jar.xml。

WebアプリケーションまたはEJBを含むアプリケーションに対してロールが定義されている場合、すべてのロールが論理OR演算子で結合されます。

クライアントから、デプロイメント記述子内のポリシーで保護されているURLまたはEJBメソッドが要求されたときのみ。

デプロイメント記述子要素は、対応するアノテーションを(ある場合は)常にオーバーライドします。

カスタム・ロール

このモデルでは、セキュリティ・レルムに構成されたロール・マッピング・プロバイダによるロール・マッピングが使用されます。管理コンソールを使用してプロバイダを構成できます。デプロイメント記述子またはアノテーションのロール・マッピングはすべて無視されます。

このモデルでは、web.xmlデプロイメント記述子とejb-jar.xmlデプロイメント記述子に定義されているポリシーが使用されます。

クライアントから、デプロイメント記述子内のポリシーで保護されているURLまたはEJBメソッドが要求されたときのみ。

カスタム・ロールおよびポリシー

セキュリティ・レルムに構成したロール・マッピング・プロバイダおよび認可プロバイダ。管理コンソールを使用してプロバイダを構成できます。

デプロイメント記述子またはアノテーションのロール・マッピングやポリシーはすべて無視されます。

すべてのURLとEJBメソッドに対して。

詳細

構成可能。

このモデルでは、アノテーションまたはデプロイメント記述子からのセキュリティ・データのみを使用する、セキュリティ・プロバイダからのデータのみを使用する、または基準とするセキュリティ・データをデプロイメント記述子からセキュリティ・プロバイダのデータベースにインポートしてさらに変更を加える、といった動作に構成できます。

構成可能。

各モデルについて

以下の節では、各モデルについて説明し、それぞれに適したシナリオを提示します。

メタデータ・アノテーション

『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のメタデータ・アノテーションおよびEJB 3.0 Beanファイルの概要に関する項に示すように、EJBプログラミング・モデルでは、メタデータ・アノテーション機能(http://java.sun.com/developer/technicalArticles/releases/j2se15を参照)を使用して、アノテーション付きEJB Beanファイルを作成します。次に、WebLogicコンパイル・ツールweblogic.appc (またはこれと同等のAntタスクwlappc)を使用してBeanファイルをJavaクラス・ファイルにコンパイルし、必要となるEJBインタフェースやデプロイメント記述子など、関連するEJBアーティファクトを生成します。

使用できるセキュリティ関連アノテーションは次のとおりです。

- javax.annotation.security.DeclareRoles — EJBのセキュリティ設定に使用するセキュリティ・ロールのリストを明示的に宣言します。

- javax.annotation.security.RolesAllowed - EJBのメソッドを呼び出すことができるセキュリティ・ロールを指定します。すべてのメソッドを呼び出すことができるロールはクラス・レベルで指定し、特定のメソッドのみを呼び出すことができるロールはメソッド・レベルで指定します。

- javax.annotation.security.DenyAll — どのロールでも呼び出すことができないメソッドを指定します。

- javax.annotation.security.PermitAll — すべてのロールで呼び出すことができるメソッドを指定します。

- javax.annotation.security.RunAs — EJBを実行するロールを指定します。デフォルトでは、EJBはそれを実際に呼び出したユーザーとして実行されます。

デプロイ時にデプロイヤは、これらのセキュリティ・ロールがまだ存在しない場合は作成し、WebLogic Server管理コンソールを使用してユーザーをこれらのロールにマッピングすることで、セキュリティ・レルムを更新します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ロールの管理に関する項を参照してください。

このモデルでは、EJBでプログラムによる認可を実装しなくても、アプリケーション開発者にさらなる管理能力を付与できます。

表4-2 メタデータ・アノテーション:一般的なシナリオ

企業A、開発者

企業A、管理者/デプロイヤ

企業Aでは、開発者ロールのユーザーは次のタスクを実行します。

- セキュリティ関連メタデータ・アノテーションを1つ以上追加します。

- WebLogicコンパイル・ツールweblogic.appc (またはこれと同等のAntタスクwlappc)を使用してBeanファイルをコンパイルします。

- アプリケーションを管理者/デプロイヤに引き継ぎます。必要なロールに関する手順を提供します。

企業Aでは、管理者またはデプロイヤのロールであるユーザーは次のタスクを実行します。

- WebLogic Server管理コンソールを使用して、必ずロールが存在して適切にグループおよびユーザーにマップされているようにします。

- アノテーションのみが想定されるようにするため、アプリケーションを管理コンソールのデプロイメント記述子のみ(Java EE標準)としてデプロイします。

メタデータ・アノテーションはデプロイメント記述子(および管理コンソール)ベースのメカニズムと関連して使用できます。実行する場合は次の点に注意してください。

- 競合がある場合、デプロイメント記述子要素は対応するアノテーションを常にオーバーライドします。たとえば、アノテーションでメソッドに「すべてを拒否」を指定して、デプロイメント記述子で「開発者」ロールがそのメソッドへのアクセス権を保有すると指定した場合、「開発者」ロールにはそのメソッドへのアクセス権があります。

- 管理コンソールでカスタム・ロールを指定した場合、デプロイメント記述子またはアノテーションでのロール・マッピングはすべて無視されます。

セキュリティ関連アノテーションのすべてを使用する簡潔なステートレス・セッションEJBの例については、「EJBへのアクセスの保護」を参照してください。

「デプロイメント記述子のみ」モデル

これは標準のJava EEモデルの一部で、WebアプリケーションおよびEJBに対して宣言型セキュリティを追加するための広く知られた方法です。このモデルでは、開発者によってJava EEデプロイメント記述子(DD)およびWebLogic Server DDに定義されたロールおよびポリシーのみが使用されます。デプロイメント記述子のセキュリティ・プリンシパル(グループやユーザー)が存在し、セキュリティ・レルムに適切にマップされているかどうかについて、セキュリティ管理者による確認が必要になります。

注意:

このモデルは、EARに適用するアプリケーション・スコープのロールに影響を与えます。このモデルでは、セキュリティ・サービスはWebLogic Server DDに定義されたアプリケーション・スコープのロールのみを使用します。

開発者がデプロイメント記述子のロールやポリシーを変更すると、その変更はWebアプリケーション、EJB、またはEARを再デプロイした直後に認識されます。

このモデルを使用する場合、EJBおよびURLパターンは、よりスコープの広いロールおよびポリシー(Webアプリケーション全体をスコープとするポリシーなど)によっては保護されません。EJBまたはURLパターンがDD内のロールまたはポリシーで保護されていない場合、これらはまったく保護されず、誰でもアクセスできることになります。たとえば、EARに対してアプリケーション・スコープのポリシーを作成し、EARがEJBを含む場合、EJBはアプリケーション・スコープのポリシーによって保護されません。

このモデルは、WebアプリケーションまたはEJBの初回のデプロイ時や後の再デプロイ時に、開発者とセキュリティ管理者が作業を綿密に調整できる場合に適しています。表4-3に、一般的なシナリオを示します。

表4-3 デプロイメント記述子のみ :一般的なシナリオ

企業A、開発者

企業A、管理者/デプロイヤ

企業Aでは、開発者ロールのユーザーは次のタスクを実行します。

- Java EE DDのロールにEJBまたはWeb URLをマップします。

- WebLogic Server DDのプリンシパルにロールをマップします。

- アプリケーションを管理者/デプロイヤに引き継ぎます。

企業Aでは、管理者またはデプロイヤのロールであるユーザーは次のタスクを実行します。

- WebLogic Server管理コンソールを使用して、必ずグループが存在して適切にユーザーにマップされているようにします。

カスタム・ロール・モデル

このセキュリティ・モデルではJava EE DDに定義されたポリシーが使用され、WebLogic Server DDのプリンシパルのマッピングは無視されます。セキュリティ管理者が管理コンソールを使用してロール・マッピングを完了します。

このモデルを使用すると、開発チームのメンバーがそれぞれの専門分野に集中できます。WebアプリケーションやEJBの開発者は、どのURLパターンやEJBメソッドを保護するかを宣言するだけで済みます。セキュリティ管理者はその後で、所定のレルムに対する既存のロールとプリンシパルの階層に適したロール・マッピングを作成します。

開発者がデプロイメント記述子のポリシーを変更すると、その変更はWebアプリケーションまたはEJBを再デプロイした直後に認識されます。開発者がロール・マッピングを変更すると、その変更は再デプロイしなくても即座に有効になります。

このモデルは、開発者と管理者が作業を綿密に調整できない場合、またはロール・マッピングが頻繁に変更される場合に適しています。表4-4に、一般的なシナリオを示します。

表4-4 カスタム・ロールのみ:一般的なシナリオ

企業A、企業B、開発者

企業B、管理者/デプロイヤ

企業AからのISV開発者または企業Bからの開発者は次のタスクを実行します。

- EJB/URLをJava EEデプロイメント記述子のロールにマップします。

- アプリケーションを管理者/デプロイヤに引き継ぎます。

企業Bからの管理者またはデプロイヤは次のタスクを実行します。

- WebLogic Server管理コンソールを使用してセキュリティ・ロールを定義します。

カスタム・ロールおよびポリシー・モデル

このセキュリティ・モデルを使用すると、統合的で動的なセキュリティ管理を行えます。セキュリティ管理者が管理コンソールで作成したロールとポリシーが使用され、デプロイメント記述子に定義されているロールとポリシーは無視されます。

組織のセキュリティ要件が変化した場合に、開発者が複数のデプロイメント記述子を変更する必要はなく、管理者が一元的なグラフィカル・ユーザー・インタフェースからすべてのセキュリティ構成を変更できます。ユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーを、すべて管理コンソールを使用して定義できます。その結果、更新されたセキュリティ要件に基づく変更のプロセスがより効率的になります。

詳細な制御が必要な場合には、カスタム・ロール・モデルの使用を検討してください。そうした詳細な制御を行うには、保護するURLパターンやEJBメソッドに関する詳細な情報を、開発者から管理者に提供する必要があります。詳細な制御が必要な場合には、カスタム・ロール・モデルの使用を検討してください。(「カスタム・ロール・モデル」を参照)

またこのモデルでは、クライアントからどのURLが要求され、どのEJBメソッドが呼び出されようとしているかに関わらず、パーミッションがチェックされるので、わずかなパフォーマンスの低下が見られます。

表4-5に、一般的なシナリオを示します。

表4-5 カスタム・ロールおよびポリシー:一般的なシナリオ

企業A、開発者

企業A、管理者/デプロイヤ

- Java EE DD、WebLogic Server DDへのマッピングは行いません。

- アプリケーションを管理者/デプロイヤに引き継ぎます。

- WebLogic管理コンソールを使用して、EJBおよびWebアプリケーションのロールおよびポリシーを定義します。

詳細モデル

このモデルは、主に9.0より前のリリースとの下位互換性のために提供されています。

このモデルでは以下の動作を構成できます(「「ロール・マッピングの組合せを有効化」設定について」を参照)。

- セキュリティ・チェックをすべてのURLおよびEJBメソッドに対して実施するか、デプロイメント記述子で保護されているものに限って実施するか。

- (このモデルを、デプロイメント記述子で保護されているURLおよびEJBメソッドに対してのみセキュリティ・チェックを実施するように構成する場合、適用されません。)デプロイメント記述子に定義されているロールとポリシーのみを使用するか、レルムのセキュリティ・プロバイダで定義されているロールとポリシーのみを使用するか、またはデプロイメント記述子からレルムの認可プロバイダまたはロール・マッピング・プロバイダのデータベースにセキュリティ・データをインポートするか。
セキュリティ・データのインポート機能は以下のタスクのために用意されています。

- 管理コンソールを使用した完全なセキュリティ管理への移行手順として。このインポート機能は、WebアプリケーションやEJBの保護のみにWebLogic Server管理コンソールを使用することを計画しているが、デプロイメント記述子のセキュリティ・データを基準として使用する必要がある場合を想定して提供されています。

- WebアプリケーションおよびEJBリソースのセキュリティ構成を再初期化して、デプロイメント記述子で指定されていた元の状態に戻すため。

データをインポートした後には、管理コンソールを使用してセキュリティ・データを変更できます。

警告:

セキュリティ・データをインポートすると、セキュリティ・データの整合性にリスクが生じます。データをインポートする際には毎回セキュリティ・サービスによって、プロバイダのデータベースからのあらゆる関連データの削除と、デプロイメント記述子からのデータの再インポートが試行されます。インポートされたセキュリティ・データに変更を加えていた場合、その変更が無効になったり、削除されたりすることがあります。セキュリティ・データをインポートする場合には、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWebアプリケーションおよびEJBのセキュリティの管理にある推奨事項に従ってください。

- (このモデルを、レルムのセキュリティ・プロバイダに定義されているロールとポリシーのみを使用するように構成する場合、適用されません。)親アプリケーションのロールとWebアプリケーションまたはEJBのロールを結合するか、親アプリケーションのロールをオーバーライドするか。

このモデルの構成を変更すると、このモデルを使用するすべてのWebアプリケーションおよびEJBにその変更が適用されます。たとえば、詳細モデルを構成してすべてのURLとメソッドに対してセキュリティ・チェックを実施するようにしてから、複数のEJBをデプロイして詳細モデルを使用するように構成するとします。この場合、クライアントでどのEJBのどのメソッドを呼び出そうとした場合にも、毎回EJBコンテナによってセキュリティ・チェックが要求されます。その後、詳細モデルを変更してデプロイメント記述子で保護されているEJBメソッドにのみセキュリティ・チェックを実施するようにすると、EJBコンテナでは即座に、複数のEJBにおいて保護されているメソッドにのみセキュリティ・チェックが要求されるようになります。

詳細セキュリティ・モデルについて

注意:

この節の内容は、詳細セキュリティ・モデルを使用するWebアプリケーションおよびEJBのみに適用されるものです。

詳細モデルは、管理コンソールの「ロールとポリシーのチェック」、「WebアプリケーションまたはEJBのデプロイ時」、および「ロール・マッピングの組合せを有効化」という3つの設定で構成します。これらの設定を理解していないと、セキュリティ・データが不適切なものになったり、失われたりすることがあります。

このモデルの構成を変更すると、このモデルを使用するすべてのWebアプリケーションおよびEJBにその変更が適用されます。

以下の節では、詳細セキュリティ・モデルの設定について説明します。

- 「ロールとポリシーのチェック」設定について

- 「WebアプリケーションまたはEJBのデプロイ時」設定について

- 「ロールとポリシーのチェック」と「WebアプリケーションまたはEJBのデプロイ時」の相互作用

- 「ロール・マッピングの組合せを有効化」設定について

「ロールとポリシーのチェック」設定について

「ロールとポリシーのチェック」の設定では、セキュリティ・サービスによってすべてのURLとEJBモジュールに対してセキュリティ・チェックが実施されるのか、デプロイメント記述子およびアノテーションで保護されたものに対してのみ実施されるのかを決定します。

「ロールとポリシーのチェック」の値は以下のように設定します。

- WebアプリケーションおよびEJBリソースのうち、関連するデプロイメント記述子(DD)およびアノテーションにセキュリティの指定があるものに対してのみセキュリティ・チェックを実施するには、「デプロイメント記述子で保護されたWebアプリケーションとEJB」を選択します。

注意:

この選択は、デプロイメント記述子のみのセキュリティ・モデルと似ています。セキュリティ・サービスでは、WebアプリケーションまたはEJBのデプロイメント記述子およびアノテーションに定義されているロールおよびポリシーのみが使用されます。

- すべてのWebアプリケーションおよびEJBリソースに対してセキュリティ・チェックを実施するには、対象とするWebLogicリソースのデプロイメント記述子およびアノテーションにセキュリティ設定があるかどうかに関わらず、「すべてのWebアプリケーションとEJB」を選択します。

注意:

これを選択した場合、「WebアプリケーションまたはEJBのデプロイ時」設定も併せて構成できます。

WebアプリケーションまたはEJBのデプロイ時」設定について

「WebアプリケーションまたはEJBのデプロイ時」の設定では、セキュリティ・サービスでデプロイメント記述子およびアノテーションのロールおよびポリシーのデータを無視するか、WebアプリケーションやEJBをデプロイするたびに、ロール・マッピング・プロバイダや認可プロバイダのデータベースにデータをインポートするかを決定します。

注意:

この設定は「ロールとポリシーのチェック」で「すべてのWebアプリケーションとEJB」を設定した場合にのみ有効です。

「WebアプリケーションまたはEJBのデプロイ時」の値は以下のように設定します。

- WebLogic Server管理コンソールのみを使用してWebアプリケーションおよびEJBリソースを保護するには、「デプロイメント・ディスクリプタのロールとポリシーを無視」オプションを選択します。これを選択すると、管理コンソールを使用してリソースを保護できるようになります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのスコープ指定セキュリティ・ロールの作成に関する項およびリソース・インスタンスのポリシーの作成に関する項を参照してください。

- デプロイメント記述子およびアノテーションからセキュリティ・データをインポートするには、「デプロイメント記述子のロールとポリシーを初期化」を選択します。

警告:

セキュリティ・データをインポートすると、セキュリティ・データの整合性にリスクが生じます。データをインポートする際には毎回セキュリティ・サービスによって、プロバイダのデータベースからのあらゆる関連セキュリティ・データの削除と、デプロイメント記述子およびアノテーションからのデータの再インポートが試行されます。インポートされたセキュリティ・データに変更を加えていた場合、その変更が無効になったり、削除されたりすることがあります。セキュリティ・データをインポートする場合には、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWebアプリケーションおよびEJBのセキュリティの管理に関する項にある推奨事項に従ってください。

「ロールとポリシーのチェック」と「WebアプリケーションまたはEJBのデプロイ時」の相互作用

表4-6に、「ロールとポリシーのチェック」と「WebアプリケーションまたはEJBのデプロイ時」の設定値をさまざまに組み合せて、WebLogicセキュリティ・サービスで希望する動作を行う方法を示します。

表4-6 「ロールとポリシーのチェック」と「WebアプリケーションまたはEJBのデプロイ時」の相互作用

セキュリティを制御する対象

WebアプリケーションおよびEJBリソースに対するセキュリティの設定

「ロールとポリシーのチェック」の設定値

「WebアプリケーションまたはEJBのデプロイ時」の設定値

すべてのWebアプリケーションおよびEJBリソース

管理コンソールのみを使用する

すべてのWebアプリケーションとEJB

デプロイメント記述子のロールとポリシーを無視

すべてのWebアプリケーションおよびEJBリソース

WebアプリケーションまたはEJBリソースのデプロイ時に、セキュリティ・データをデプロイメント記述子およびアノテーションから構成済みの認可プロバイダおよびロール・マッピング・プロバイダのデータベースにコピーするか再初期化して、その後、セキュリティ・ロールとセキュリティ・ポリシーの変更をその他の方法で行います。

注意: WebアプリケーションまたはEJBリソースがデプロイされるたびに、セキュリティ・データはコピーまたは再初期化されます。

すべてのWebアプリケーションとEJB

デプロイメント記述子のロールとポリシーを初期化

デプロイメント記述子およびアノテーションで指定されているWebアプリケーションおよびEJBのメソッドのみ(デフォルト構成)

デプロイメント記述子およびアノテーションのみを使用する

デプロイメント記述子で保護されたWebアプリケーションとEJB

--

「ロール・マッピングの組合せを有効化」設定について

「ロール・マッピングの組合せを有効化」の設定では、エンタープライズ・アプリケーション、Webアプリケーション、およびEJBコンテナ内のロール・マッピングがどのように相互作用するかを決定します。

この設定は、8.xバージョンとの下位互換性のために提供されています。バージョン9.xで初めからデプロイされたすべてのアプリケーションにおいて、この設定のデフォルト値は「true」(有効)です。以前バージョン8.1でデプロイして9.xにアップグレードしたアプリケーションにおけるこの設定のデフォルト値は「false」(無効)です。以下のどちらかに当てはまる場合、「ロール・マッピングの組合せを有効化」のデフォルト値を変更することを検討してください。

- 8.xからアップグレードしたアプリケーションに対して詳細セキュリティ・モデルを選択し、バージョン9.xで利用可能な組み合せたロール・マッピングの動作を使用する必要があります。

- 9.xのアプリケーションに対して詳細セキュリティ・モデルを選択し、バージョン8.xのロール・マッピングの動作を使用する必要があります。

表4-7で、この設定がWebアプリケーションとEJBに与える影響について比較します。

表4-7 ロール・マッピングの組合せの設定がWebアプリケーションとEJBのセキュリティに与える影響

ロール・マッピングの組合せが無効

ロール・マッピングの組合せが有効

各コンテナのロール・マッピングは、<externally-defined>記述子要素で定義されていない限り、他のコンテナに対して排他的なものとなります。

アプリケーションのロール・マッピングがEJBおよびWebアプリケーションのマッピングと組み合せられることで、すべてのプリンシパル・マッピングが含まれるようになります。セキュリティ・サービスでは、ロール・マッピングが論理OR演算子と組み合せられます。

web.xmlファイル内の1つまたは複数のポリシーで、weblogic.xmlファイル内にロール・マッピングが存在しないロールが指定されている場合、Webアプリケーション・コンテナは未定義のロールがプリンシパルの名前であると想定します。そのため、想定されたプリンシパルがロール名にマップされます。たとえば、web.xmlファイルのポリシーの1つに次のスタンザがある場合:

<auth-constraint>
<role-name>PrivilegedUser</role-name>
</auth-constraint>

ただし、weblogic.xmlファイルにはPrivilegedUserに対するロール・マッピングがないとすると、Webアプリケーション・コンテナは、次のスタンザと同等のインメモリー・マッピングを作成します:

<security-role-assignment>
<role-name>PrivilegedUser</role-name>
<principal-name>PrivilegedUser </principal-name>
</security-role-assignment>

web.xmlファイル内の1つまたは複数のポリシーで、weblogic.xmlファイル内にマッピングが存在しないロールが指定されている場合、Webアプリケーション・コンテナでは未定義のロールに対して空のマップを作成します(つまり、ロールはプリンシパルを含まないものとして明示的に定義されます)。したがって、そのようなポリシーで保護されるURLパターンにはアクセスできません。

EJBメソッドのロール・マッピングは、weblogic-ejb-jar.xmlファイルで定義する必要があります。その他のコンテナで定義されたロール・マッピングは、<externally-defined>記述子要素で定義されていない限り、使用されません。

ejb-jar.xmlファイル内の1つまたは複数のポリシーで、weblogic-ejb-jar.xmlファイル内にマッピングが存在しないロールが指定されている場合、EJBコンテナは未定義のロールに対して空のマップを作成します(つまり、ロールはプリンシパルを含まないものとして明示的に定義されます)。したがって、そのようなポリシーで保護されるメソッドにはアクセスできません。

使用例

以下の例で、ロール・マッピングの組合せが有効な場合と無効な場合におけるロール・マッピングの動作の違いについて示します。

EAR、WAR、およびEJBの例

MyAppEarにMyAppWARが含まれ、MyAppWARにMyEJBが含まれます。プリンシパル・マッピングへのロール(p1およびp2)は以下のとおりです。

- EARの記述子では、myRole = p1

- WARの記述子では、myRole = p2

- EJB-JARの記述子では、myRole = empty

組み合せたロール・マッピングが有効になっている場合、ロール・マッピングは以下のようになります。

- EARコンテナでは、myRoleがp1にマップされます。

- WARコンテナでは、myRoleがp1またはp2にマップされます。

- EJBコンテナでは、myRoleがp1にマップされます。

組み合せたロール・マッピングが無効になっている場合、ロール・マッピングは以下のようになります。

- EARコンテナでは、myRoleがp1にマップされます。

- WARコンテナでは、myRoleがp2にマップされます。

- EJBコンテナでは、外部的に定義されている必要があり、定義されていない場合にはデプロイメントが失敗します。

EARおよびWARの例

MyAppEarにMyAppWARが含まれます。ロールからプリンシパルへのマッピングは以下のとおりです。

- MyAppEARの記述子では、myRole = p1

- MyAppWARの記述子では、myRole = (何も定義されません)

組み合せたロール・マッピングが有効になっている場合、ロール・マッピングは以下のようになります。

- EARコンテナでは、myRoleがp1にマップされます。

- WARコンテナでは、myRoleがp1にマップされます。
組み合せたロールの動作なので、このマッピングは同じになります。

組み合せたロール・マッピングが無効になっている場合、ロール・マッピングは以下のようになります。

- EARコンテナでは、myRoleがp1にマップされます。

- WARコンテナでは、myRoleがMyRoleにマップされます。
Webアプリケーションにマッピングが定義されていない場合、このマッピングは同じになります。EARマッピングがWARマッピングにコピーされます。

Webアプリケーション、EJBの保護

メタデータ・アノテーションの場合、EJBをコード化する際にセキュリティ関連アノテーションを追加して、すべてのメソッド(またはメソッドのサブセット)を呼び出すことができるロールを指定します。デプロイ時にデプロイヤは、これらのセキュリティ・ロールがまだ存在しない場合は作成し、WebLogic Server管理コンソールを使用してユーザーをこれらのロールにマッピングすることで、セキュリティ・レルムを更新します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ロールの管理に関する項を参照してください。

デプロイメント記述子(および管理コンソール)ベースのセキュリティの場合、セキュリティ・モデルはWebアプリケーションまたはEJBをデプロイするたびに選択し、選択結果はそのデプロイメントの有効期間中には変えられません。別のモデルを使用する場合は、そのWebアプリケーションまたはEJBを削除してから再デプロイする必要があります。

管理コンソールを使用してのアプリケーションのデプロイ、セキュリティ・モデルの選択、ロールやポリシーの変更、および他の関連タスクの実行については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWebアプリケーションおよびEJBのセキュリティの管理に関する項を参照してください。

デプロイメント記述子を使用してWebアプリケーションまたはEJBリソースを保護する場合は、『Oracle WebLogic Serverセキュリティのプログラミング』のWebアプリケーションでの宣言によるセキュリティの使用に関する項またはEJBでの宣言によるセキュリティの使用に関する項を参照してください。

5 セキュリティ・ポリシー

この章では、WebLogic Serverリソースにアクセスできるユーザーを指定するセキュリティ・ポリシーの特長と機能について説明します。「Adminロールのユーザーにアクセスを許可する」といった簡単なポリシーや、「Adminロールのユーザーに8時から5時の間だけアクセスを許可する」といった複雑なポリシーを作成することができます。

この章の内容は以下のとおりです。

- セキュリティ・ポリシーの格納および使用の前提条件

- デフォルトのルート・レベルのセキュリティ・ポリシー

- セキュリティ・ポリシー条件

- 保護されたパブリック・インタフェース

- 管理コンソールでのセキュリティ・ポリシーの管理

セキュリティ・ポリシーによる複数のリソースの保護については、「ポリシーを使用して複数のリソースの保護」を参照してください。

セキュリティ・ポリシーの格納および使用の前提条件

Webアプリケーション・リソースおよびEJBリソース以外のすべてのリソースに対するセキュリティ・ポリシーは、常にデフォルトの(アクティブな)セキュリティ・レルムに構成された認可プロバイダのセキュリティ・プロバイダ・データベースに保持されます。WebLogic Serverが提供するセキュリティ・レルムによって、ポリシーが組込みLDAPサーバーに格納されます。

Webアプリケーション・リソースおよびEJBリソースのポリシーの場所は、以下のように場合によって変わります。

- JACC (JSR 115で定義されているJava Authorization Contract for Containers)を使用したセキュリティを実装する場合、ポリシーはWebアプリケーションまたはEJBのデプロイメント記述子内に格納されます。

- DDOnlyモデルを使用してWebアプリケーションまたはEJBを保護する場合、ポリシーはデプロイメント記述子内に格納されます。

- 記述子にあるポリシーを無視するセキュリティ・モデルを使用する場合、ポリシーの格納先は認可プロバイダによって決定されます。WebLogic Serverが提供するセキュリティ・レルムによって、ポリシーが組込みLDAPサーバーに格納されます。

- 詳細セキュリティ・モデルを使用する場合、ポリシーの場所はモデルの構成方法によって異なります。

第4章「WebアプリケーションおよびEJBリソースの保護のオプション」を参照してください。

セキュリティ・ポリシーに追加する各ユーザーやグループは、アクティブなセキュリティ・レルムに構成された認証プロバイダのセキュリティ・プロバイダ・データベースに定義されている必要があります。追加する各ロールは、アクティブなセキュリティ・レルムに構成されたロール・マッピング・プロバイダのセキュリティ・プロバイダ・データベースに定義されている必要があります。WebLogic Serverのセキュリティ・レルムは、WebLogic認証プロバイダおよびWebLogic XACMLロール・マッピング・プロバイダを使用するように構成されています。これらのプロバイダでは、ユーザー、グループ、およびロールを組込みLDAPサーバーに格納します。

WebLogic認証、認可およびロール・マッピング・プロバイダの詳細は、『Oracle WebLogic Serverセキュリティの理解』のWebLogicセキュリティ・プロバイダに関する項を参照してください。

デフォルトのルート・レベルのセキュリティ・ポリシー

ルート・レベルのポリシーは、特定のリソース・タイプの全インスタンスで継承されます。表5-1で、WebLogic Serverに設定されたセキュリティ・レルムに定義されているデフォルトのルート・レベルのポリシーについて説明します。ここに示すポリシーで指定されているロールとグループについては、第6章「ユーザー、グループ、セキュリティ・ロール」を参照してください。

注意:

ルート・レベルのポリシーには管理コンソールでアクセスできます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのルート・レベルのポリシーの作成に関する項を参照してください。

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

WebLogicリソース

セキュリティ・ポリシー

管理リソース

デフォルト・グローバル・ロール: Admin

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

なし

EIS (リソース・アダプタ)リソース

デフォルト・グループ: Everyone

EJBリソース

デフォルト・グループ: Everyone

COMリソース

なし

JDBCリソース

デフォルト・グループ: Everyone

JNDIリソース

デフォルト・グループ: Everyone

JMSリソース

デフォルト・グループ: Everyone

サーバー・リソース

デフォルト・グローバル・ロール:

- Admin

- Operator

ワーク・コンテキスト

デフォルト・グループ: Everyone

URLリソース

デフォルト・グループ: Everyone

Webサービス・リソース

デフォルト・グループ: Everyone

警告:

管理リソースとサーバー・リソースのデフォルトのルート・レベルのポリシーを変更して制約をさらに厳しくすることがないようにしてください。既存のセキュリティ・ロールの一部を削除すると、WebLogic Serverの動作に悪影響を与えることがあります。ただし、必要に応じて、デフォルト・セキュリティ・ポリシーにより多くを含めることはできます(たとえば、新しいセキュリティ・ロールを追加するなど)。「一貫性のあるセキュリティ方式の維持」を参照してください。

セキュリティ・ポリシー条件

ポリシーには、あるリソースに対して誰がアクセスできるのかを決定するために1つまたは複数の条件が指定されます。もっとも基本的なポリシーには、セキュリティ・ロールまたはプリンシパルの名前が指定されています。たとえば、グローバル・ロール「Admin」のみが指定されているような形です。このポリシーは、WebLogicセキュリティ・サービスによって実行時に「Adminロールのユーザーにアクセスを許可する」と解釈されます。さらに複雑な条件を作成することも可能で、そうした条件を論理演算子ANDやOR (非排他的なOR)で組み合せることもできます。また、どの条件も否定が可能で、それによって特定の条件下におけるアクセスを禁止できます。

管理コンソールには、WebLogic Server認可プロバイダに組み込まれている以下の3種類のポリシー条件が表示されます。

注意:

以下の節では、WebLogic認可プロバイダまたはWebLogic XACML認可プロバイダを使用するレルムで利用できる条件について説明します。お使いのセキュリティ・レルムでサード・パーティ製の認可プロバイダを使用する場合は、サード・パーティのドキュメントでこの機能について参照してください。

- 基本的なポリシー条件

- 日付と時刻のポリシー条件

- コンテキスト要素のポリシー条件

基本的なポリシー条件

このリリースのWebLogic Serverで使用できる基本的なポリシー条件は以下のとおりです。

- ユーザー - 指定したユーザーにリソースへのアクセスを許可します。たとえば、ユーザーJohnだけがDeposit EJBにアクセスできるという条件を作成できます。

- グループ - 指定したグループ内のすべてのユーザーやグループにリソースへのアクセスを許可します。ただし、「ユーザー」条件や「ロール」条件と「グループ」条件が矛盾する場合を除きます。

- ロール - 指定したロールに定義されたすべてのユーザーやグループにリソースへのアクセスを許可します。ただし、「ユーザー」または「グループ」条件と「ロール」条件が矛盾する場合を除きます。たとえば、「Admin」を指定した「ロール」条件と「joe」を否定する「ユーザー」条件を作成した場合、ユーザーjoeがAdminロールに定義されていてもjoeによるアクセスが拒否されます。

- サーバーが開発モードである - リソースをホストするサーバーが開発モードで動作している場合にアクセスを許可します。『構成ウィザードによるドメインの作成』のWebLogicドメインの作成に関する項を参照してください。

- 全員に対してアクセスを許可 - すべてのユーザー、グループ、およびロールにアクセスを許可します。

- 全員に対してアクセスを拒否 - すべてのユーザー、グループ、およびロールのアクセスを禁止します。

- 要素に次のユーザーの署名が必要 - (Webサービスを保護する場合にのみ使用) Webサービス操作を呼び出すSOAPリクエスト・メッセージ内の要素を誰がデジタル署名したかに基づいてセキュリティ・ポリシー条件を作成します。たとえば、getBalance操作を、受信SOAPリクエストのAccountNumber要素がjoeという名前のユーザーによってデジタル署名された場合にのみ呼び出すことができるという条件を作成できます。
要素に次のユーザーの署名が必要条件を作成するには、次の情報を提供します。

- SOAP要素にグループまたはユーザーによる署名が必要かどうかを指定します。
たとえば、要素に対してユーザーによる署名が必要であると指定するには、userと入力します。

- 要素に署名が必要なユーザーまたはグループの名前。

- デジタル署名が必要なSOAPメッセージ要素の名前。次の形式を使用します。

{Namespace}LocalPart

LocalPartはデジタル署名が必要なSOAPメッセージの要素の名前で、「ネームスペース」はそのネームスペースです。これらの値を取得するには、WebサービスのWSDLを使用します。

例:

{http://schemas.xmlsoap.org/soap/envelope/}AccountNumber

注意:

デジタル署名されるようにWebサービスのWS-Policy内にすでに構成されている要素のみを指定できます。詳細は、『Oracle WebLogic Server WebLogic Webサービスの保護』のメッセージ・レベルのセキュリティの構成に関する項を参照してください。

日付と時刻のポリシー条件

任意の日付と時刻の条件を使用する場合、他のいずれかの条件を追加してさらにユーザーを制限しない限り、セキュリティ・ポリシーではすべてのユーザーに対して指定した日付または時刻のアクセスが許可されます。このリリースのWebLogic Serverで使用できる日付と時間のポリシー条件は以下のとおりです。

- 指定した時間帯にアクセスが発生 - 指定した時間帯のアクセスを許可します。たとえば、ユーザーに営業時間中のアクセスのみを許可する条件を作成できます。

- 次の日時より後にアクセスが発生 - 指定した時間より後のアクセスを許可します。たとえば、営業開始後など、ユーザーに特定の日時よりも後のアクセスを許可する条件を作成できます。

- 次の日時より前にアクセスが発生 - 指定した時間より前のアクセスを許可します。たとえば、営業終了前など、ユーザーに特定の日時よりも前のアクセスを許可する条件を作成できます。

- 指定した曜日にアクセスが発生 - 指定した曜日のアクセスを許可します。たとえば、ユーザーに平日のアクセスを許可する条件を作成できます。

- 指定した日にアクセスが発生 - 月の特定の日付に発生したアクセスを許可します。たとえば、ユーザーに毎月の1日にのみアクセスを許可する条件を作成できます。

- 指定した日より後にアクセスが発生 - 月の特定の日付より後に発生したアクセスを許可します。たとえば、ユーザーに毎月15日より後にアクセスを許可する条件を作成できます。

- 指定した日より前にアクセスが発生 - 月の特定の日付より前に発生したアクセスを許可します。たとえば、ユーザーに毎月15日になる前までアクセスを許可する条件を作成できます。

注意:

「指定した時間帯にアクセスが発生」などの時刻のポリシー条件に時刻を指定する形式は、ロケールによって異なります。英語版のWebLogic Serverでは、WebLogic Serverインスタンスのローカル・タイム・ゾーンを使用して、12時間形式でhh:mm:ss AM|PMのように表します。たとえば、午後8:30を指定するには、08:30:00 PMという形式を使用します。

コンテキスト要素のポリシー条件

コンテキスト要素の条件を使用すると、HTTPサーブレット・リクエスト属性、HTTPセッション属性、EJBメソッドのパラメータの値に基づいてセキュリティ・ポリシーを作成できます。この情報はWebLogic ServerによってContextHandlerオブジェクトから取得され、その値に基づいてポリシー条件を定義できます。こうした条件を使用する場合、使用しているコンテキストに属性またはパラメータと値のペアが確実に適用するようにするのはユーザーの役目です。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のContextHandlerとWebLogicリソースに関する項を参照してください。

このリリースのWebLogic Serverで使用できるコンテキスト要素のロール条件は以下のとおりです。

- コンテキスト要素が定義されている - 指定した属性またはパラメータに基づいてアクセスを許可します。

- コンテキスト要素の値が数値定数と等しい - 指定した属性またはパラメータの数値(またはdouble型の数値を表す文字列)が、指定したdouble型の数値と等しいことに基づいてアクセスを許可します。

- コンテキスト要素の値が数値定数より大きい - 指定した属性またはパラメータの数値(またはdouble型の数値を表す文字列)が、指定したdouble型の数値よりも大きいことに基づいてアクセスを許可します。

- コンテキスト要素の値が数値定数より小さい - 指定した属性またはパラメータの数値(またはdouble型の数値を表す文字列)が、指定したdouble型の数値よりも小さいことに基づいてアクセスを許可します。

- コンテキスト要素の値が文字列定数と等しい - 指定した属性またはパラメータの文字列値が、指定した文字列と等しいことに基づいてアクセスを許可します。

保護されたパブリック・インタフェース

Weblogic Server管理コンソール、Weblogic Scripting Tool (WLST)、およびMBean APIは、デフォルト・セキュリティ・ポリシーによって保護されます。デフォルト・セキュリティ・ポリシーは、表6-2で説明したデフォルト・グローバル・ロールおよびデフォルト・グループに基づきます。したがって、以下の保護されているパブリック・インタフェースとの対話では、通常、両方のセキュリティ方式を満たしている必要があります。また、MBeanとの対話が必要な管理操作は、「一貫性のあるセキュリティ方式の維持」で説明されているMBeanの保護を使用して保護されます。したがって、次の保護されているパブリック・インタフェースとの対話では、通常、両方のセキュリティ方式を満たしている必要があります。

- 「WebLogic Server管理コンソール」 - WebLogicセキュリティ・サービスでは、特定のユーザーが管理コンソールにアクセスできるかどうかをそのユーザーのログイン時に検証します。アクセスの許されていない操作をユーザーが呼び出そうとすると、アクセス拒否のエラーが表示されます。
このパブリック・インタフェースの使用方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWebLogic Server管理コンソールに関する項を参照してください。

- Weblogic Scripting Tool - Weblogic Scripting Tool (WLST)は、システム管理者やオペレータが、WebLogic Serverインスタンスおよびドメインのモニターと管理に使用する、コマンド・ライン・スクリプト・インタフェースです。WebLogicセキュリティ・サービスは、特定のユーザーにWLSTコマンド実行のパーミッションがあるかどうかをコマンドの呼出し時に検証します。アクセスの許されていない操作をユーザーが呼び出そうとすると、weblogic.management.NoAccessRuntimeExceptionが送出されます。この例外は、開発者がプログラムで明示的に捕捉できます。この例外はサーバーによってそのログ・ファイルに送信されますが、標準出力に例外を送信するよう、サーバーを構成することもできます。
このパブリック・インタフェースの使用方法については、『Oracle WebLogic Scripting Tool』を参照してください。

注意:

WLSTは、MBean API (後述)との対話を抽象化する便利なユーティリティです。したがって、WLSTを使用して実行できる管理タスクは、MBean APIを使用して実行することもできます。

- MBean API - WebLogicセキュリティ・サービスは、特定のユーザーにAPIにアクセスするパーミッションがあるかどうかを、ユーザーがMBeanの操作を実行するときに検証します。アクセスの許されていない操作をユーザーが呼び出そうとすると、weblogic.management.NoAccessRuntimeExceptionが送出されます。この例外は、開発者がプログラムで明示的に捕捉できます。この例外はサーバーによってそのログ・ファイルに送信されますが、標準出力に例外を送信するよう、サーバーを構成することもできます。
こうしたAPIの使用方法については、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeanに関する項を参照してください。

管理コンソールでのセキュリティ・ポリシーの管理

注意:

この節では、WebLogic認可プロバイダまたはWebLogic XACML認可プロバイダを使用するセキュリティ・レルムで利用可能な機能について説明します。お使いのセキュリティ・レルムでサード・パーティ製の認可プロバイダを使用する場合は、サード・パーティのドキュメントでプロバイダ・データベースへのポリシーの追加方法について参照してください。

WebLogic管理コンソールを使用して、セキュリティ・ポリシーの作成や変更のためにWebLogicリソースにアクセスできます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ポリシーの管理に関する項を参照してください。

6 ユーザー、グループ、セキュリティ・ロール

この章では、WebLogic Serverのセキュリティ・レルム内のユーザー、グループ、およびセキュリティ・ロールの特長と機能について説明します。

この章の内容は以下のとおりです。

- ユーザーとグループの概要

- デフォルト・グループ

- セキュリティ・ロールの概要

- セキュリティ・ロールのタイプ:グローバル・ロールとスコープ指定ロール

- デフォルト・グローバル・ロール

- セキュリティ・ロール条件

- 管理コンソールでのユーザー、グループ、ロールの管理

ユーザーとグループの概要

ユーザーは認証可能なエンティティです。ユーザーは、個人でもJavaクライアントなどのソフトウェア・エンティティでもかまいません。各ユーザーには、セキュリティ・レルム内でユニークなIDが与えられます。セキュリティ管理を効率化するには、ユーザーをグループに追加することをお薦めします。グループは、通常、企業の同じ部門に所属しているなどの共通点を持つユーザーの集合です。

デフォルト・グループ

表6-1に、WebLogic Serverで設定されたセキュリティ・レルムに定義されている、グループの一覧を示します。デフォルトでは、これらのグループの1つにユーザーを追加すると、デフォルト・グローバル・セキュリティ・ロールの1つにもユーザーが設定されます(「デフォルト・グローバル・ロール」を参照)。

表6-1 デフォルト・グループ

グループ名

メンバーシップ

Administrators

デフォルトでは、グループにはインストール・プロセスの一部(つまり、構成ウィザード)で入力されたユーザー情報、およびsystemユーザー(WebLogic Serverインスタンスが互換性セキュリティを実行している場合)が含まれます。Administratorsグループに割り当てられているユーザーには、デフォルトでAdminセキュリティ・ロールが付与されています。

「ベスト・プラクティス: Administratorsグループにユーザーの追加」を参照してください。

Deployers

デフォルトでは、このグループは空。Deployersグループに割り当てられたユーザーは、デフォルトではDeployerセキュリティ・ロールを与えられます。

Operators

デフォルトでは、このグループは空。Operatorsグループに割り当てられたユーザーは、デフォルトではOperatorセキュリティ・ロールを与えられます。

Monitors

デフォルトでは、このグループは空。Monitorsグループに割り当てられたユーザーは、デフォルトではMonitorセキュリティ・ロールを与えられます。

AppTesters

デフォルトでは、このグループは空。AppTestersグループに割り当てられたユーザーは、デフォルトではAppTesterセキュリティ・ロールを与えられます。

CrossDomainConnectors

デフォルトでは、このグループは空。CrossDomainConnectorsグループに割り当てられたユーザーは、デフォルトではCrossDomainConnectorセキュリティ・ロールを与えられます。

AdminChannelUsers

デフォルトでは、このグループは空。AdminChannelUsersグループに割り当てられたユーザーは、デフォルトではAdminChannelUserセキュリティ・ロールを与えられます。

OracleSystemGroup

デフォルトでは、このグループにはOracleSystemUserのユーザーが含まれ、OracleSystemRoleのロールを与えられます。

実行時グループ

実行時には、すべてのユーザーが以下のグループに入ることになります。

- Users。このグループには、認証されたすべてのユーザーが含まれます。

- Everyone。このグループにはすべての匿名ユーザーと、(usersグループも匿名ユーザーであることから)認証されたすべてのユーザーが含まれます。

表6-1のグループ(または独自に作成した他のグループ)と違い、これらのグループに対して直接ユーザーの追加または削除を行うことはできません。これらのグループは管理コンソールの「グループ」タブには表示されず、認証データベースでもエクスポートされません。

ベスト・プラクティス: Administratorsグループにユーザーの追加

Administratorsグループには、インストール時に(構成ウィザードを使用して)定義したユーザーに加えて、少なくとも1人のユーザーを追加することをお薦めします。少なくとも2人の管理者が常に存在することで、セキュリティ違反が起こった場合に1人しかいない管理ユーザーがロックアウトされるという状況を防ぐことができます。また、「system」、「admin」、「Administrator」といったありきたりなユーザー名は避けるようにします。

セキュリティ・ロールの概要

セキュリティ・ロールは、特定の条件に基いてユーザーまたはグループに付与されるIDです。複数のユーザーまたはグループに同じセキュリティ・ロールを付与することができます。また、ユーザーまたはグループは複数のセキュリティ・ロール内に存在できます。セキュリティ・ロールは、ポリシーにおいてWebLogicリソースにアクセスできるユーザーを決定するために使用されます。(第5章「セキュリティ・ポリシー」を参照してください)。

ロールでは、セキュリティ・グループと同様にユーザーにIDが付与されます。ただし、セキュリティ・ロールは以下の点でグループとは異なります。

- セキュリティ・ロールは、WebLogic Serverドメインの1つのアプリケーション内にある特定のWebLogicリソースをスコープとして指定できます。一方、グループは常にWebLogic Serverドメイン全体をスコープとします。「セキュリティ・ロールのタイプ:グローバル・ロールとスコープ指定ロール」を参照してください。

- セキュリティ・ロールは、ユーザー名、グループ・メンバーシップ、または時刻などの条件に基づいて動的に計算されてユーザーまたはグループに付与されます。一方、グループは静的です。
ロールを計算して付与するプロセスをロール・マッピングといいます。ロール・マッピングは、WebLogicセキュリティ・サービスが保護対象のWebLogicリソースに対するアクセス決定を下す直前に行われます。アクセス決定は、認可プロバイダのコンポーネントであり、WebLogicリソースに対して特定の操作を実行するパーミッションがサブジェクトにあるかどうかを判断します。(『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のアクセス決定に関する項を参照してください。)

セキュリティ・ロールのタイプ:グローバル・ロールとスコープ指定ロール

WebLogic Serverには2種類のセキュリティ・ロールがあります。

- グローバルセキュリティ・ロール。すべてのセキュリティ・ポリシーで使用できるロールです。WebLogicリソースを保護するためにそのまま使用できる複数のデフォルト・グローバル・ロールが用意されています(「デフォルト・グローバル・ロール」を参照)。

注意:

JSR 115に定義されているようにJACC (Java authorization Contract for Containers)を使用してセキュリティを実装している場合、セキュリティ・ロールは使用できません。

- スコープ指定ロール。WebLogicリソースの特定のインスタンス(EJBのメソッド、JNDIツリーのブランチなど)用に定義されたポリシーにのみ使用できるロールです。スコープ指定ロールはまず使用する必要はありません。スコープ・ロールは柔軟性を高めるためのもので、高度なユーザー向けの特別な機能です。

デフォルト・グローバル・ロール

表6-2に、WebLogic Serverで設定されたセキュリティ・レルムに定義されている、グローバル・ロールの一覧を示します。この表ではさらに、デフォルト・セキュリティ・ポリシーによって各ロールに付与されるアクセスと、各ロールにデフォルトでどのグループが含まれるかについてもまとめます。

警告:

これらのロールは削除しないでください。これらは、ほとんどの種類のWebLogicリソースを保護するデフォルト・セキュリティ・ポリシーで使用されます。また、MBeanセキュリティ・レイヤーでも使用されます。Adminロールを削除すると、実行中のドメインの構成をどのユーザーも変更できなくなります。「一貫性のあるセキュリティ方式の維持」を参照してください。

表6-2 デフォルト・グローバル・ロール、特権、および割り当てられるデフォルト・グループ

グローバル・ロール

デフォルト・ポリシーで付与されるアクセス

デフォルトの条件に含まれるグループ

Admin

- サーバー構成(一部の暗号化された属性の暗号化された値を含む)を表示します。

- サーバー構成全体を変更します。

- エンタープライズ・アプリケーション、Webアプリケーション、EJB、Java EEコネクタ、およびWebサービス・モジュールをデプロイします。

- サーバーを起動、再起動、および停止します。

Administrators

AdminChannelUser

管理チャネルAdminChannelにアクセスします。

AdminChannelUsers、Administrators、Deployers、Operators、MonitorsおよびAppTesters

Anonymous

すべてのユーザー(everyoneグループ)にこのグローバル・ロールが付与されます。

注意:このグローバル・ロールは利便性のために用意されており、weblogic.xmlおよびweblogic-ejb-jar.xmlデプロイメント記述子で指定できます。『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント記述子の要素に関する項、および『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスを参照してください。

everyone

Deployer

- サーバー構成(デプロイメント・アクティビティに関連する一部の暗号化された属性を含む)を表示します。

- 起動および停止クラス、Webアプリケーション、JDBCデータ・プール接続、EJB、Java EEコネクタ、Webサービス、およびWebLogic Tuxedo Connectorコンポーネントを変更します。必要に応じて、デプロイメント記述子を編集します。

- Java EEデプロイメントの実装(JSR-88)のデプロイメント操作にアクセスします。『Oracle WebLogic Serverへのアプリケーションのデプロイ』のWebLogic Serverデプロイメントに関する項を参照してください。

Deployers

Operator

- サーバー構成(暗号化された属性は除く)を表示します。

- サーバーを起動、再起動、および停止します。

Operators

Monitor

サーバー構成(暗号化された属性は除く)を表示します。

このセキュリティ・ロールでは、WebLogic Server管理コンソール、WLST、およびMBean APIへの読取り専用アクセスが効果的に提供されます。

Monitors

AppTester

管理モードで動作しているアプリケーションにテスト目的でアクセスします。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のプロダクション・アプリケーションを分離するための管理モードに関する項を参照してください。

AppTesters

CrossDomainConnector

外部ドメインからドメイン間呼出しを実行します。詳細は、『Oracle WebLogic Serverの保護』のWebLogic Serverドメイン間の信頼関係の有効化に関する項を参照してください。

CrossDomainConnectors

OracleSystemRole

WS-Securityトークンが認証されたユーザーのかわりのIDアサーション。

注意: このグローバル・ロールはOracle Web Services Managerで使用するために提供されています。

OracleSystemGroup

セキュリティ・ロール条件

ロールには、実行時にセキュリティ・ロールに含まれるユーザーを決定するために1つまたは複数の条件が指定されます。たとえば、基本的なロールには「Administrator」グループのみが指定されます。このロールは、WebLogicセキュリティ・サービスによって実行時に「Administratorグループをこのロールに含める」と解釈されます。さらに複雑な条件を作成することも可能で、そうした条件を論理演算子ANDやOR (非排他的なOR)で組み合せることもできます。また、どの条件も否定が可能で、それによってロールからユーザーを除外できます。ユーザーやグループにセキュリティ・ロールが与えられるには、すべての条件がtrueである必要があります。ロール文の中では、制約が厳しい式ほど後に指定します。

管理コンソールには、WebLogic Serverロール・マッピング・プロバイダに組み込まれている以下の3種類のロール条件が表示されます。

注意:

以下の節では、WebLogicロール・マッピング・プロバイダまたはWebLogic XACMLロール・マッピング・プロバイダを使用するレルムで利用できる条件について説明します。お使いのセキュリティ・レルムでサード・パーティ製のロール・マッピング・プロバイダを使用する場合は、サード・パーティのドキュメントでこの機能について参照してください。

- 基本的なロール条件

- 日付と時刻のロール条件

- コンテキスト要素のロール条件

基本的なロール条件

このリリースのWebLogic Serverで使用できる基本的なロール条件は以下のとおりです。

- ユーザー - 指定したユーザーをロールに追加します。たとえば、ユーザーJohnだけがBankTellerセキュリティ・ロールを付与されるといった条件を作成できます。

- グループ - 指定したグループをロールに追加します。たとえば、グループFullTimeBankEmployeesに属するユーザーだけがBankTellerセキュリティ・ロールを付与されるといった条件を作成できます。
セキュリティ管理がより効率的になるため、最低限の要件としてこのロール条件をお薦めします。

- サーバーが開発モードである - サーバーが開発モードで動作している場合にのみプリンシパルをロールに追加します。『構成ウィザードによるドメインの作成』のWebLogicドメインの作成に関する項を参照してください。

- 全員に対してアクセスを許可 - すべてのユーザーおよびグループをロールに追加します。

- 全員に対してアクセスを拒否 - どのユーザーやグループもロールに含まれないようにします。

日付と時刻のロール条件

任意の日付と時刻のロール条件を使用する場合、他のいずれかのロール条件を追加してさらにユーザーを制限しない限り、セキュリティ・ロールでは指定した日付または時刻のアクセスをすべてのユーザーに対して許可します。このリリースのWebLogic Serverで使用できる日付と時刻のロール条件は以下のとおりです。

- 指定した時間帯にアクセスが発生 - 指定した時間帯にのみロールにプリンシパルを追加します。たとえば、銀行の営業時間中にのみBankTellerセキュリティ・ロールをユーザーに付与するといった条件を作成できます。

- 次の日時より後にアクセスが発生 - 現在時刻が指定した時刻より後の場合にのみ、ロールにプリンシパルを追加します。たとえば、銀行の営業開始時間より後など特定の日付や時刻の後にのみBankTellerセキュリティ・ロールをユーザーに付与するといった条件を作成できます。

- 次の日時より前にアクセスが発生 - 現在時刻が指定した時刻より前の場合にのみ、ロールにプリンシパルを追加します。たとえば、銀行の営業終了時間より前など特定の日付や時刻の前にのみBankTellerセキュリティ・ロールをユーザーに付与するといった条件を作成できます。

- 指定した曜日にアクセスが発生 - 指定した曜日にのみロールにプリンシパルを追加します。たとえば、平日にのみBankTellerセキュリティ・ロールをユーザーに付与するといった条件を作成できます。

- 指定した日にアクセスが発生 - 月の特定の日付にロールにプリンシパルを追加します。たとえば、毎月1日にのみBankTellerセキュリティ・ロールをユーザーに付与するといった条件を作成できます。

- 指定した日より後にアクセスが発生 - 月の特定の日付より後の時間であることを基準としたセキュリティ・ロール条件を作成します。たとえば、毎月15日より後にBankTellerセキュリティ・ロールをユーザーに付与するといった条件を作成できます。

- 指定した日より前にアクセスが発生 - 月の特定の日付より現在の日付が前の場合にのみ、ロールにプリンシパルを追加します。たとえば、毎月15日より前にBankTellerセキュリティ・ロールをユーザーに付与するといった条件を作成できます。

コンテキスト要素のロール条件

コンテキスト要素の条件を使用すると、HTTPサーブレット・リクエスト属性、HTTPセッション属性、EJBメソッドのパラメータの値に基づいてセキュリティ・ロールを作成できます。この情報はWebLogic ServerによってContextHandlerオブジェクトから取得され、その値に基づいてロール条件を定義できます。こうした条件を使用する場合、使用しているコンテキストに属性またはパラメータと値のペアが確実に適用するようにするのはユーザーの役目です。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のContextHandlerとWebLogicリソースに関する項を参照してください。

このリリースのWebLogic Serverで使用できるコンテキスト要素のロール条件は以下のとおりです。

- コンテキスト要素が定義されている - 指定した属性またはパラメータに基づいてロールにプリンシパルを追加します。

- コンテキスト要素の値が数値定数と等しい - 指定した属性またはパラメータの数値(またはdouble型の数値を表す文字列)が、指定したdouble型の数値と等しいことに基づいて、ロールにプリンシパルを追加します。

- コンテキスト要素の値が数値定数より大きい - 指定した属性またはパラメータの数値(またはdouble型の数値を表す文字列)が、指定したdouble型の数値よりも大きいことに基づいて、ロールにプリンシパルを追加します。

- コンテキスト要素の値が数値定数より小さい - 指定した属性またはパラメータの数値(またはdouble型の数値を表す文字列)が、指定したdouble型の数値よりも小さいことに基づいて、ロールにプリンシパルを追加します。

- コンテキスト要素の値が文字列定数と等しい - 指定した属性またはパラメータの文字列値が指定した文字列と等しいことに基づいて、ロールにプリンシパルを追加します。

管理コンソールでのユーザー、グループ、ロールの管理

注意:

この節では、WebLogic認証プロバイダおよびWebLogicロール・マッピング・プロバイダまたはWebLogic XACMLロール・マッピング・プロバイダを使用するレルムで利用できる機能について説明します。お使いのセキュリティ・レルムでサード・パーティ製の認証またはロール・マッピング・プロバイダを使用する場合は、サード・パーティのドキュメントでその機能について参照してください。

セキュリティ・レルムにユーザーやグループを追加する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザーとグループの管理に関する項を参照してください。

セキュリティ・ロールの作成については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ロールの管理に関する項を参照してください。

7 XACMLドキュメントによるWebLogicリソースの保護

この章では、認可ポリシーおよびロールの割当てを記述するためのXML言語であるXACML (eXtensible Access Control Markup Language)を使用して、WebLogicリソースを保護する方法について説明します。XACMLドキュメントでロールおよびポリシーを作成し、WebLogic Scripting Tool (WLST)を使用してセキュリティ・レルムに追加できます。これは、管理コンソールで作成できるロールまたはポリシーよりも複雑なロールまたはポリシーを作成する必要がある場合、または標準言語を使用する必要がある場合に便利です。また、レルムのロールとポリシーをXACMLドキュメントにエクスポートし、そのドキュメントを他のWebLogic Serverレルムにインポートできます。

この章の内容は以下のとおりです。

- 前提条件

- レルムへのXACMLロールまたはポリシーの追加:主な手順

- カスタムMBeanのロールまたはポリシーを作成する

- XACMLドキュメントへのロールおよびポリシーのエクスポート

警告:

XACMLドキュメントをセキュリティ・レルムにロードする前に、必ずバックアップを作成してください。属性の記述に誤字などのエラーがあると、XACMLプロバイダはレルムのロールとポリシーを不確定な要素として評価し、その結果、すべてのユーザー(管理者も含む)がドメインからロックされてしまう場合があります。詳細は、「警告:不確定な結果によってすべてのユーザーがロックアウトされる可能性がある」を参照してください。

WebLogic ServerのXACML認可プロバイダおよびWebLogic Server XACMLロール・マッピング・プロバイダには、http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdfにあるXACML 2.0のコア仕様が実行されています。

前提条件

XACMLドキュメントを使用してWebLogicリソースを保護する場合、次の前提条件に留意してください。

- セキュリティ・レルムにXACML認可ポリシーを追加するには、セキュリティ・レルムでは、WebLogic Server XACML認可プロバイダまたはweblogic.management.security.authorization.PolicyStoreMBeanインタフェースを実装するサード・パーティの認可プロバイダを使用する必要があります。

- セキュリティ・レルムにXACMLロール割当てを追加するには、セキュリティ・レルムでは、WebLogic Server XACMLロール・マッピング・プロバイダまたはweblogic.management.security.authorization.PolicyStoreMBeanインタフェースを実装するサード・パーティのロール・マッピング・プロバイダを使用する必要があります。

- XACML認可ポリシーまたはXACMLロール・ポリシーでリソースを保護するには、リソース識別子(リソースID)が必要です。リソースをデプロイまたは作成すると、ユニークで不変なIDが作成されるため、リソースのポリシーを作成する前にリソースをデプロイする必要があります。

- EJBまたはWebアプリケーションを保護するには、カスタム・ロールのセキュリティ・モデル、またはカスタム・ロールおよびポリシーのセキュリティ・モデルを使用してデプロイする必要があります。XACMLドキュメントを使用して、デプロイメント記述子のみのセキュリティ・モデルを使用してデプロイしたEJBやWebアプリケーションのロールとポリシーを作成することはできません。「Webアプリケーション、EJB用のセキュリティ・モデルの比較」を参照してください。

レルムへのXACMLロールまたはポリシーの追加:主な手順

カスタムのロールおよびポリシーが記述されるXACMLドキュメントを作成し、WebLogic Scripting Toolを使用してセキュリティ・レルムにロールまたはポリシーを追加できます。

その主な手順を以下に示します。

1. 保護するリソースの決定

2. 保護するリソースのIDの取得

3. XACMLドキュメントの作成

4. WebLogic Scripting Toolを使用してレルムにロールまたはポリシーを追加する

5. ロールまたはポリシーがレルムに存在するかどうかを確認する

警告: 不確定な結果によってすべてのユーザーがロックアウトされる可能性がある

XACML仕様では、決定エンジンが決定点を処理できない場合、不確定な結果が返されます。決定点とそれに関連付けられた決定点に対して使用する結合アルゴリズムによっては、不確定な結果が決定の最上位に伝播し、プロバイダがすべての要求へのアクセスを拒否する可能性があります。

たとえば、次の属性には、MustBePresent='true'が指定され、スペルの間違い(ancesterではなくancestor)が含まれています。この場合、不確定として評価されて、セキュリティ・プロバイダはアクセスを拒否します。

<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:2.0:resource:resource-ancester"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"/>

保護するリソースの決定

WebLogic Serverでは、リソースが階層にまとめられています。管理コンソールまたはJava EEデプロイメント記述子(XACMLドキュメントではない)を使用してWebLogicリソースを保護する場合、階層の上位のリソースに作成されたポリシーは、同じ階層の下位に存在するリソースに対してデフォルトのポリシーとして機能します。下位階層のポリシーは、常に上位階層のポリシーをオーバーライドします。

XACMLドキュメントは、この階層による保護方式をエンコードできます。ただし、XACMLの階層モデルはWebLogic Serverとは少し異なります。「WebLogic ServerとXACMLのセキュリティ・モデルの比較」を参照してください。

保護するリソースのIDの取得

リソースをデプロイまたは作成すると、ユニークで不変な識別子(ID)が作成されますが、XACMLドキュメントにはWebLogic Server IDを指定するリソース識別子が含まれる必要があります。

WebLogic Serverがリソースに割り当てるIDを見つけるには、次の手順に従います。

1. 監査プロバイダを構成してレルムに対するセキュリティ監査を有効にします。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの監査プロバイダの構成に関する項を参照してください。監査プロバイダによって保存されるログ・ファイルの場所は記録しておいてください(デフォルトでは、サーバーのlogsディレクトリに保存されます)。

2. リソースをデプロイまたは作成します。

3. 外部クライアントからリソースにリクエストを送信します。
たとえば、Web Serviceクライアントを使用して、保護するWeb Serviceメソッドを呼び出します。これにより、監査プロバイダがリソースに関するメッセージを生成するイベントが引き起こされます。

注意:

Web Serviceクライアントが、XACMLドキュメントに指定されたロールとポリシーで保護されるWeblogicリソースへのアクセス権を得るには、前もって自らを認証する必要があります。

4. 監査プロバイダのログ・ファイルを開き、トリガーしたイベントのエントリを見つけます。
たとえば、WebLogic Serverデフォルト監査プロバイダを重大度レベルINFORMATION以上のメッセージを生成するように構成する場合、sayHelloメソッドをSimpleSoapPortというWebサービスから呼び出すと、監査ログには次のエントリ(ロール・マッピング・プロバイダから1つと認可プロバイダから1つ)が記録されます。

#### Audit Record Begin <Mar 30, 2006 9:24:12 AM>
<Severity =INFORMATION>
<<<Event Type = RoleManager Audit Event ><Subject: 0>
<<webservices>><type=<webservices>,
application=webservicesJwsSimpleEar, contextPath=/jws_basic_simple,
webService=SimpleSoapPort, method=sayHello,
signature={java.lang.String}><>>> Audit Record End ####
#### Audit Record Begin <Mar 30, 2006 9:24:12 AM>
<Severity =SUCCESS>
<<<Event Type = Authorization Audit Event V2 ><Subject: 0>
<ONCE><<webservices>><type=<webservices>,
application=webservicesJwsSimpleEar, contextPath=/jws_basic_simple,
webService=SimpleSoapPort, method=sayHello,
signature={java.lang.String}>>> Audit Record End ####

sayHelloメソッドのリソースIDは次のとおりです。

type=<webservices>,
application=webservicesJwsSimpleEar, contextPath=/jws_basic_simple,
webService=SimpleSoapPort, method=sayHello,
signature={java.lang.String}

5. 監査レコードのリソースIDを編集して、保護するリソースを指定します。
監査ログのIDは、WebLogic Serverリソース階層の最下位にあるリソース用です。通常は、特定の操作(WebサービスやEJBのメソッド、特定のURLのHTTPメソッドなど)に対してポリシーを作成するのではなく、階層のより上位のリソース(URLパターンやWebサービス全体など)に対してポリシーを作成します。

次のリソースIDは、前述の手順のリソースIDから得ることができます。

- sayHelloメソッドを含むWebサービスのIDは次のとおりです。

type=<webservices>,
application=webservicesJwsSimpleEar, contextPath=/jws_basic_simple,
webService=SimpleSoapPort

- Web Serviceを含むアプリケーションのIDは次のとおりです。

type=<application>,
application=webservicesJwsSimpleEar

アプリケーションのリソースIDでは、type=<application>を指定します。

- Webサービス全体に対するルート・レベルのポリシーの作成に使用するWebサービス・タイプのIDは次のとおりです。

type=<webservices>

ルート・レベルのポリシーとリソースの階層の詳細は、「ポリシーを使用して複数のリソースの保護」を参照してください。

XACMLドキュメントの作成

ロールの割当ておよび認可ポリシーを作成する場合、2つのXACMLドキュメント(ロールを記述するドキュメントとポリシーを記述するドキュメント)を作成します。一方のドキュメントをロール・マッピング・プロバイダのストアにロードし、もう一方のドキュメントを認可プロバイダのストアにロードします。

XACMLを使用してWebLogic Serverリソースを記述する方法については、付録A「WebLogic ServerにおけるXACMLのリファレンス」を参照してください。

例: ロールの割当てを定義する

XACMLドキュメントのロールの割当てを記述するための構文は、http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-rbac-profile1-spec-os.pdfにあるOASIS RBACプロファイル仕様に明記されています。(WebLogic Serverでは、この仕様のサブセットのみをサポートしています)。

この構文では以下の要素が必要です。

- Policy親要素。

- Policyの下位要素としてTarget要素。

- Targetの下位要素として、次のResourceMatch要素を含む1つ以上のResource要素。
(オプション)ロールの名前を特定する1つのResourceMatch要素。このResourceMatch要素を含めない場合は、ロール・ポリシーがレルム内のすべてのロールに適用されます。MatchId属性には関数識別子(ワイルドカードを含むロール名)を指定できます。DataType属性にはstring型を指定する必要があります。

(オプション)ロールが適用されるWebLogicリソースを特定する別のResourceMatch要素。このResourceMatch要素を含めない場合は、ロールがすべてのWebLogicリソースに適用されます。

- Targetの下位要素として、ポリシーがその他のリソース・タイプではなくロールに適用されることを示すAction要素。

- Policyの下位要素として、ロール内にユーザー、グループ、ロールを定義する1つまたは複数のRule要素。

例7-1のXACMLドキュメントでは、MyRoleというロールがSimpleSoapPort Webサービスで使用できるように指定しています。また、webServiceGroupグループがロールに存在するように指定しています。

注意:

<AttributeValue>要素に値を指定するときは、余分な空白を含めないでください。具体的には:

- 最初の値の前には空白を1つのみ入力します。

- 複数の値を指定するとき、1つのみの空白で各値を区切ります。

- 最後の値の後には空白を入力しません。

例:

<AttributeValue datatype>value1, value2, value3</AttributeValue>

例7-1 ロールに対するXACMLポリシー

<?xml version="1.0" encoding="UTF-8"?>
<Policy xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os" PolicyId="urn:bea:xacml:2.0:myRolePolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable">
<Description>Grp(group1)</Description>
<Target>
<Resources>
<Resource>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">type=&lt;webservices&gt;, application=webservicesJwsSimpleEar, contextPath=/jws_basic_simple, webService=SimpleSoapPort</AttributeValue>
<ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor-or-self" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
</ResourceMatch>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">MyRole</AttributeValue>
<ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
</ResourceMatch>
</Resource>
</Resources>
<Actions>
<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>
</Actions>
</Target>
<Rule RuleId="primary-rule" Effect="Permit">
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">webServiceGroup</AttributeValue>
<SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:group" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</Apply>
</Condition>
</Rule>
<Rule RuleId="deny-rule" Effect="Deny"/>
</Policy>

例: 認可ポリシーを定義する

例7-2のXACMLドキュメントでは、MyRoleロールのみがSimpleSoapPort Webサービスにアクセスできるように指定しています。

例7-2 Webサービスに対するXACMLポリシー

<?xml version="1.0" encoding="UTF-8"?>
<Policy xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os" PolicyId="urn:bea:xacml:2.0:myPolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable">
<Description>Rol(MyRole)</Description>
<Target>
<Resources>
<Resource>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">type=&lt;webservices&gt;, application=webservicesJwsSimpleEar, contextPath=/jws_basic_simple, webService=SimpleSoapPort</AttributeValue>
<ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor-or-self" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
</ResourceMatch>
</Resource>
</Resources>
</Target>
<Rule RuleId="primary-rule" Effect="Permit">
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">MyRole</AttributeValue>
<SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</Apply>
</Condition>
</Rule>
<Rule RuleId="deny-rule" Effect="Deny"/>
</Policy>

WebLogic Scripting Toolを使用してレルムにロールまたはポリシーを追加する

WebLogic Scripting Tool (WLST)は、XACMLドキュメントをWebLogicセキュリティ・レルムにロードするのに使用できるコマンド・ライン・スクリプト・インタフェースです。

WLSTは対話モードまたはスクリプト・モードで使用できます。WLSTはオフライン・モードでは使用できません。認証プロバイダとロール・マッピング・プロバイダは、管理サーバーの実行時のみポリシー・ストアを更新できます。

スクリプト・モードの使用の詳細は、『Oracle WebLogic Scripting Tool』のWebLogic Scripting Toolの使用に関する項を参照してください。

WLSTの対話モードを使用するための手順を以下に示します。

1. 構成するレルムを含むWebLogic Serverインスタンスを起動します。

2. コマンド・プロンプトを開き、WLSTを実行するための環境を設定します。
環境を設定する方法の1つを以下に示します。

1. ドメインのルート・ディレクトリに移動します。

2. setWLSenvスクリプトを呼び出します(このスクリプトはドメインの作成時にドメイン構成ウィザードで作成します)。

3. XACMLドキュメントを含むディレクトリに移動します。

4. WLSTを起動してlocalhost:7001でリスニングしているWebLogic Serverインスタンスに接続するために、次のコマンドを入力します。

1. java weblogic.WLST
このコマンドでWLSTプロンプトが返されます。

2. connect('username','password','localhost:7001')
ただし、usernameとpasswordは管理ユーザーの資格証明です。

5. XACMLドキュメントをJava Stringオブジェクトにロードするために、次のコマンドを入力します。

1. xacmlFile = open('myfile','r')
ただし、myfileはXACMLドキュメントの名前です。

2. xacmlDoc = xacmlFile.read()

3. (オプション)ドキュメントがStringにロードされたかどうかを確認するには、次のコマンドを入力します。

print(xacmlDoc)

標準出力にxacmlDoc変数の値が出力されます。

6. ロールの割当てをWebLogic XACMLロール・マッピング・プロバイダにロードするために、次のコマンドを入力します。

1. cd ('SecurityConfiguration/mydomain/Realms/myrealm/RoleMappers/XACMLRoleMapper')
ここで

mydomainはWebLogic Serverドメインの名前です。

myrealmはドメインのセキュリティ・レルムの名前です。

2. cmo.addPolicy(xacmlDoc) (XACMLドキュメントにPolicyが含まれている場合)、cmo.addPolicySet(xacmlDoc) (XACMLドキュメントにPolicySetが含まれている場合)。

7. 認可ポリシーをWebLogic XACML認可プロバイダにロードするために、手順5を繰り返してXACMLポリシー・ドキュメントをロードし、次のコマンドを入力します。

1. cd ('SecurityConfiguration/mydomain/Realms/myrealm/Authorizers/XACMLAuthorizer')
ここで

mydomainはWebLogic Serverドメインの名前です。

myrealmはドメインのセキュリティ・レルムの名前です。

2. cmo.addPolicy(xacmlDoc) (XACMLドキュメントにPolicyが含まれている場合)、cmo.addPolicySet(xacmlDoc) (XACMLドキュメントにPolicySetが含まれている場合)。

ポリシーの追加、変更、または削除に使用できる操作の詳細なリストは、Oracle WebLogic Server MBeanリファレンスのXACMLAuthorizerMBeanを参照してください。

ロールまたはポリシーがレルムに存在するかどうかを確認する

WebLogic Server管理コンソールでは、XACMLドキュメントから追加するロールおよびポリシーが表示されません。

そのかわり、ロールおよびポリシーがレルムに追加されたかどうかを確認するには、「XACMLドキュメントへのロールおよびポリシーのエクスポート」を参照してください。

カスタムMBeanのロールまたはポリシーを作成する

管理対象Bean (MBean)は、リソースの管理データおよび操作を公開するための標準です。アプリケーション開発者は、MBean (カスタムMBean)を作成しアプリケーションをモニターおよび管理することによって、アプリケーションの運用および管理コストを大幅に減らすことができます。『Oracle WebLogic Server JMXによる管理可能なアプリケーションの開発』を参照してください。

カスタムMBeanをWebLogic Server MBeanサーバーに登録する場合、MBeanに対して誰がアクセスできるのかを定義するXACMLドキュメントを作成できます。「前提条件」に記載した前提条件に加えて、MBeanのオブジェクト名には「Type=value」キー・プロパティが含まれている必要があります。

カスタムMBeanに対するロールおよびポリシーを作成するための主な手順は次のとおりです。

1. カスタムMBeanのリソースIDを決定する

2. XACMLドキュメントの作成

3. WebLogic Scripting Toolを使用してレルムにロールまたはポリシーを追加する

4. ロールまたはポリシーがレルムに存在するかどうかを確認する

カスタムMBeanのリソースIDを決定する

カスタムMBeanをWebLogic MBeanサーバーに登録すると、WebLogicセキュリティ・サービスによってMBeanの各属性に対して2つのリソースID (属性のゲッター・メソッドとセッター・メソッドのID)が作成されます。各MBean操作に対しては1つのリソースIDが作成されます。

IDには次のパターンが使用されます。

type=<jmx>, operation=type-of-access, application=,
mbeanType=type-name, target=attribute-or-operation

ここで

- type-of-accessはポリシーで保護するアクセスのタイプを指定します。以下の値のいずれかを使用します。

- get
誰が1つまたは複数のMBean属性を読み取ることができるかをポリシーで制御することを示します。

- set
誰が1つまたは複数のMBean属性を書き込むことができるかをポリシーで制御することを示します。

- invoke
誰が1つまたは複数のMBean操作を呼び出すことができるかをポリシーで制御することを示します。

- create
誰がMBeanサーバーのcreateメソッドを使用してMBeanのインスタンスを作成できるかをポリシーで制御することを示します。

- unregister
誰がMBeanサーバーのunregisterメソッドを使用してMBeanのインスタンスを登録解除できるかをポリシーで制御することを示します。

- type-nameはMBeanオブジェクト名のTypeキー・プロパティの値です。

- attribute-or-operationはMBean属性または操作の名前です。

たとえば、NewUserCountという1つの属性とclearNewUserCountという操作を含むMBeanを作成し、そのMBeanをmedrec:Name=AdminReportMBean,Type=CustomMBeanTypeというオブジェクト名で登録する場合、セキュリティ・サービスによって次のリソースIDが作成されます。

type=<jmx>, operation=get, application=, mbeanType=CustomMBeanType,
target=NewUserCount

type=<jmx>, operation=set, application=, mbeanType=CustomMBeanType,
target=NewUserCount

type=<jmx>, operation=clearNewUserCount, application=,
mbeanType=CustomMBeanType,target=

XACMLドキュメントへのロールおよびポリシーのエクスポート

セキュリティ・レルムに存在するすべてのロールおよびポリシーのXACML表現を確認するために、認可プロバイダとロール・マッピング・プロバイダからデータをエクスポートできます。

警告:

ロールおよびポリシーの「ラウンドトリップ」編集を行ってはいけません。つまり、ロールおよびポリシーをエクスポートして、XACMLドキュメントを変更し、変更したドキュメントをインポートしないでください。エクスポートしたファイルを編集すると、WebLogic Server構成が使用できなくなる可能性があります。エクスポートしたファイルの編集はサポートされていません。

セキュリティ・データのエクスポート方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・プロバイダからのデータのエクスポートに関する項を参照してください。

A WebLogic ServerにおけるXACMLのリファレンス

XACML (eXtensible Access Control Markup Language)は、認可ポリシーおよびロールの割当てを記述するためのXML言語です。XACMLには拡張ポイントが用意されており、Oracleのようなベンダーが独自のリソース、データ型、関数をXACMLで表現できるようになっています。

WebLogic ServerのXACML認可プロバイダおよびXACMLロール・マッピング・プロバイダ:

- http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdfにあるOASIS XACML 2.0のコア仕様 を実装および拡張します。

- http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-rbac-profile1-spec-os.pdfにあるOASIS RBAC仕様で説明されている「Core and Hierarchical Role Based Access Control (RBAC) Profile of XACML 2.0」も部分的に実装します。

以下の節では、XACML 2.0ドキュメントを記述してWebLogic Server上のリソースを保護する場合に使用できる拡張について説明します。また、WebLogic ServerでXACMLを使用する場合の制約についても説明します。

- WebLogic ServerとXACMLのセキュリティ・モデルの比較

- アクション識別子

- 環境識別子

- ポリシーおよびポリシーセット識別子

- リソース識別子

- サブジェクト識別子

- WebLogic ServerのXACML関数

- ルールおよびポリシーの結合アルゴリズム

ここでは、XACMLのWebLogic Server拡張、およびその制限事項についてのみ説明しています。XACML 2.0言語の完全なリファレンス情報については、OASIS XACML 2.0コア仕様 およびOASIS RBAC仕様を参照してください。

WebLogic ServerとXACMLのセキュリティ・モデルの比較

WebLogic Serverでリソースやポリシーを表現するためのモデルは、Java EEデプロイメント記述子のモデルに準拠しています。このJava EEモデルでは、リソースの階層を作成し、最上位のロールと認可ポリシーによって下位層のリソースを保護します。「リソースの階層の保護」を参照してください。下位層のポリシーは、常に上位層のポリシーをオーバーライドします。リソース階層の上位には、エンタープライズ・アプリケーション、Webアプリケーション、およびEJBが配置されます。リソース階層の最下位には、EJBメソッド、特定のURLパターンのHTTPメソッド、およびMBeanのゲッターとセッターが配置されます。

XACMLモデルでも、リソースの階層は認識されます。しかし、ネイティブのWebLogic Serverモデルと異なり、作成するXACMLポリシーでは、リソースをそのリソース自体のポリシーで保護するのか、リソースの親または祖先のポリシーで保護するのかを判断する方法を指定する必要があります。

また、XACMLドキュメントでは、リソースとリソースのアクションを区別するのが一般的です。たとえば、XACMLドキュメントでリソースとしてEJBを定義したら、そのEJBリソース内にEJBのメソッドを表すアクションを定義します。ネイティブのWebLogic Serverモデルでは、EJBと各EJBメソッドがリソースと見なされます。「図A-1」を参照してください。

図A-1 メソッドを含むWebLogicのリソース階層

「図A-1 メソッドを含むWebLogicのリソース階層」の説明

EJBメソッドなどのアクションをXACMLリソースとして記述することが可能ですが、XACMLでのより自然な表現方法は、EJBをリソースとして定義し、EJBメソッドをリソース内のアクションとして定義する方法です。

用語の比較

WebLogic Serverでリソースやポリシーについて説明するための用語は、Java EEデプロイメント記述子のモデルに準拠しています。このJava EEモデルでは、以下の用語を使用して主要な概念を説明しています。

- ロールには、特定の時間にどのユーザーまたはグループにそのロールを割り当てるかを示す1つまたは複数の条件が含まれています。ロール式は、条件と、その条件に従ってロールに追加するユーザーまたはグループの名前を組み合せたものです。これらの式の集合をロール文と呼びます。

- ポリシーには、特定の時間に誰がリソースにアクセスできるかを示す1つまたは複数の条件が含まれています。ポリシー式は、条件と、その条件に従ってアクセスを許可するユーザー、グループ、またはロールの名前を組み合せたものです。これらの式の集合をポリシー文と呼びます。

XACMLでは、ポリシーはルールのセットから構成されており、誰にロールを割り当て、誰がリソースにアクセスできるかは、このポリシーを使用して決定します。つまり、XACMLのポリシーは、WebLogic Serverのロール文やポリシー文に相当します。

データ型について

Oracle実装では、XACMLのコア仕様で必要とされているすべてのデータ型がサポートされます。それ以外にも、標準XMLデータ型や、様々なカスタム・データ型がサポートされています。このマニュアルでは、Oracle独自のカスタム・データ型を、bea:という接頭辞を付けて表します。

WebLogic XACMLプロバイダで認識されるすべてのデータ型の詳細は、Oracle WebLogic Server APIリファレンスのcom.bea.common.security.xacml.Typeを参照してください。

アクション識別子

XACMLでは、Action要素を使用して、リソース内での処理やリソースの階層を識別します。

WebLogic Serverでは、XACMLのコア仕様にのすべてのAction識別子がサポートされます(XACML 2.0のコア仕様を参照)。また、XACMLの環境識別子を使用できる場所ならどこでも使用できる追加の識別子1つもサポートされています。

WebLogic Serverリソース内の処理(たとえば、特定のEJBメソッド)を識別するには、表A-1の説明に従ってアクション識別子を使用します。

注意:

リソース識別子を使用して処理(EJBメソッドなど)を記述することは可能ですが、XACMLでのより自然な表現方法はアクション識別子を使用する方法です。「WebLogic ServerとXACMLのセキュリティ・モデルの比較」を参照してください。

表A-1 アクション識別子

次を識別するには...

この識別子を使用します...

操作

- 属性ID: urn:oasis:names:tc:xacml:1.0:action:action-id

- データ型: string

- 値: 処理を含むリソースの種類によって異なります。「表A-2」を参照してください。

プロバイダがセキュリティ・チェックを実行するタイミング

- 属性ID: urn:bea:xacml:2.0:action:direction

- データ型: string

- 値: ONCE、PRIOR、またはPOST

WebLogicセキュリティSPIには、プロバイダが要求されたセキュリティ・チェックを実行するタイミングを指定するためのオプション機能が含まれています。

- ONCEは、認可チェックを1回実行することを要求します。処理の前に実行するか、後に実行するかは指定しません。

- PRIORは、リクエストを処理する前に認可チェックを実行することを要求します。

- POSTは、リクエストを処理した後、その結果を返す前に認可チェックを実行することを要求します。

このdirection識別子を使用すると、ONCE、PRIOR、またはPOSTでチェックされたリクエストを識別できます。

詳細は、Oracle WebLogic Server APIリファレンスのweblogic.security.spi.Direction(セキュリティ・プロバイダにONCE、PRIOR、またはPOSTを渡すために使用するオブジェクト)に関する項を参照してください。

注意: 認可プロバイダでは、Directionオブジェクトを判定内で使用することもできます。WebLogic ServerのXACML認可プロバイダでは、ONCE値のみサポートされます。

表A-2では、action-id識別子に指定する値について説明します。

表A-2 action-id識別子の値

その処理を含むリソースの種類

指定する値

Admin

Adminリソースによって保護する管理アクティビティの名前。たとえばUserLockout。

有効な値については、Oracle WebLogic Server APIリファレンスのweblogic.security.service.AdminResourceコンストラクタのactionパラメータに関する項を参照してください。

Application

管理コンソールに表示されるアプリケーション名。

コントロール

Javaコントロール内のメソッドの名前。Javaコントロールは、再利用可能なコンポーネントで、WebLogic Platformアプリケーション内の任意の場所に作成して使用できます。

EJB

EJBメソッドの名前。たとえばmymethod。そのメソッドがオーバーロードされている場合は、指定したメソッド名を持つすべてのメソッドが一致します。

JDBC

JDBCリソースによって保護する管理アクティビティの名前。

有効な値については、Oracle WebLogic Server APIリファレンスのweblogic.security.service.JDBCResourceコンストラクタのactionパラメータに関する項を参照してください。

JMS

JMSリソースによって保護する管理アクティビティの名前。

有効な値については、Oracle WebLogic Server APIリファレンスのweblogic.security.service.JMSResourceコンストラクタのactionパラメータに関する項を参照してください。

JMX

WebLogic Server MBean内の処理の名前。たとえばshutdown。

JNDI

JNDIリソースによって保護する管理アクティビティの名前。

有効な値については、Oracle WebLogic Server APIリファレンスのweblogic.security.service.JNDIResourceコンストラクタのactionパラメータに関する項を参照してください。

サーバー

サーバー・リソースによって保護するサーバー・ライフサイクル・アクティビティの名前。たとえばboot。

有効な値については、「サーバー・リソース」を参照してください。

URL

HTTPメソッドの名前。たとえばPOST。

Webサービス

Webサービス・メソッドの名前。たとえばmymethod。

ワーク・コンテキスト

ワーク・コンテキスト・リソースによって保護する管理アクティビティの名前。

有効な値については、Oracle WebLogic Server APIリファレンスのweblogic.security.service.WorkContextResourceコンストラクタのactionパラメータに関する項を参照してください。

その他

文字列access。

例

次の例では、Action要素を使用して、SimpleSoap Webサービス内のmymethodをターゲットとして指定しています。

注意:

<AttributeValue>要素に値を指定するときは、余分な空白を含めないでください。具体的には:

- 最初の値の前には空白を1つのみ入力します。

- 複数の値を指定するとき、1つのみの空白で各値を区切ります。

- 最後の値の後には空白を入力しません。

例:

<AttributeValue datatype>value1, value2, value3</AttributeValue>

<Target>
<Resources>
<Resource>
<ResourceMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">type=&lt;webservices&gt;, application=webservicesJwsSimpleEar,contextPath=/jws_basic_simple, webService=SimpleSoapPort</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"/>
</ResourceMatch>
</Resource>
</Resources>
<ActionMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">mymethod</AttributeValue>
<ActionAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"/>
</ActionMatch>
</Target>

環境識別子

XACMLでは、必要に応じてEnvironment要素を使用して、ターゲットにアクセスを許可する前に満たされなければならない条件を運用環境内に記述できます。たとえば、Environment要素を使用して、アクセスを許可する日付と時間の範囲を指定できます。

Weblogic Serverでは、XACMLのすべてのEnvironment識別子をサポートされます(http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdfにあるOASIS XACML 2.0コア仕様を参照)。また、標準のXACMLの環境識別子を使用できる場所ならどこでも使用できる追加の識別子1つに対するサポートも追加されています。表A-3では、コンテナからプロバイダに渡す値を保持するのに使用できる識別子に対しての値のリストを提供します。

表A-3 WebLogic Serverの環境識別子

識別子

値 および 説明

属性ID:

urn:bea:xacml:2.0:environment:context:key

この識別子では、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のContextHandlerとWebLogicリソースに関する項で定義されているように、keyはContextHandler要素名を指定します。ContextHandlerは、リソース・コンテナから追加のコンテキストとコンテナ固有の情報を取得し、その情報を名前と値のペアのリストとして表すWebLogicクラス。

データ型:

bea:Object、string、またはdouble

値:

一致させたいContextHandler要素の値

例

次の例では、Environment要素を使用して、WebLogic Serverのリスニング・ポートの値を一致させています。このような要素を使用して、リクエストをリスニング・ポート9001で受け付けることを要件とするポリシーを作成できます。

<Environment>
<EnvironmentMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:double-equal">
<EnvironmentAttributeDesignator
AttributeId="urn:bea:xacml:2.0:environment:context:com.bea.cont
extelement.channel.Port"
DataType="http://www.w3.org/2001/XMLSchema#double"/>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#double">9001</AttributeValue>
</EnvironmentMatch>
</Environment>

ポリシーおよびポリシーセット識別子

XACMLでは、Policy要素を使用して1つまたは複数のルールを記述し、PolicySet要素を使用して1つまたは複数のポリシーを記述できます。各要素には、ユニークな識別子を提供するためのPolicySetId属性を含める必要があります。XACML仕様では、PolicySetId識別子を有効なURI値にすることが要件になっています。

XACMLドキュメントでは、PolicySetIdを使用して、特定のPolicyまたはPolicySet要素を別のPolicySet要素に含めることができます。WebLogic Serverでは、認可プロバイダやロール・マッピング・プロバイダのポリシー・ストアで、PolicySetIdをキーとして使用します。

WebLogic Serverでは、urn:bea:で始まるURI値は内部使用のために予約されています。urn:bea:で始まるURIを使用して独自のポリシーを作成することはできませんが、それらの値を使用してOracleのポリシーを独自のポリシー・セットに含めることはできます。

例

次に、Policy要素の有効な識別子の例を示します。

<Policy
PolicyId="urn:mycompany:myapplication:policyid:1"
...>

次に、上のPolicy要素への有効な参照の例を示します。

<PolicyIdReference>
urn:mycompany:myapplication:policyid:1
</PolicyIdReference>

リソース識別子

XACMLでは、Resource要素を使用して、データ、サービス、またはシステム・コンポーネントを表現します。

WebLogic Serverでは、XACML 2.0コア仕様の説明に従って、すべてのXACML Resource識別子がサポートされます。

Weblogic serverリソースを識別するには、リソース識別子を表A-4に説明する方法で使用します。WebLogic Serverリソースについては、第3章「ポリシーで保護できるリソースのタイプ」を参照してください。

表A-4 WebLogic Serverのリソース識別子

次を識別するには...

次の識別子を使用します...

リソース

- 属性ID: urn:oasis:names:tc:xacml:1.0:resource:resource-id

- データ型: string

- 値: WebLogic Serverリソース・タイプとWebLogic Serverリソース階層内でのリソースの位置を指定する名前と値のペアの集合。WebLogic Serverでは、これらの識別子が生成されます。
なお、この識別子を使用するポリシーでは、指定したリソースより下位にあるリソースは保護されません。たとえば、この識別子を使用したポリシーをWebサービス・モジュールに適用する場合、Webサービス内のメソッドはこのポリシーでは保護されません。

「保護するリソースのIDの取得」を参照してください。

リソースとその祖先

- 属性ID: urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor-or-self

- データ型: string

- 値: WebLogic Serverリソース・タイプを指定する名前と値のペアの集合。WebLogic Serverでは、これらの識別子が生成されます。

「保護するリソースのIDの取得」を参照してください。

リソースの親

- 属性ID: urn:oasis:names:tc:xacml:1.0:resource:resource-parent

- データ型: string

- 値: WebLogic Serverリソース・タイプを指定する名前と値のペアの集合。WebLogic Serverでは、これらの識別子が生成されます。

「保護するリソースのIDの取得」を参照してください。

リソースの祖先

- 属性ID: urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor

- データ型: string

- 値: WebLogic Serverリソース・タイプを指定する名前と値のペアの集合。WebLogic Serverでは、これらの識別子が生成されます。

「保護するリソースのIDの取得」を参照してください。

例

次の例では、Resource要素がSimpleSoapPortというWebサービスに一致し、そのWebサービス内のすべてのメソッドが返されます。

<Resource>
<ResourceMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">type=&lt;webservices&gt;, application=webservicesJwsSimpleEar, contextPath=/jws_basic_simple, webService=SimpleSoapPort</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"/>
</ResourceMatch>
</Resource>

サブジェクト識別子

XACMLでは、Subject要素を使用して、述部から参照できる属性を持つアクタを表現します。

WebLogic Serverでは、XACML 2.0のコア仕様に記載されている、XACMLサブジェクト識別子がサポートされています。

WebLogic Serverレルムに定義されているWebLogic Serverのユーザー、グループ、またはロールを識別するには、サブジェクト識別子を表A-5に説明する方法で使用します。

表A-5 WebLogicのサブジェクト識別子

次を識別するには...

次の識別子を使用します...

ユーザー・プリンシパル

- 属性ID: urn:oasis:names:tc:xacml:1.0:subject:subject-id

- データ型: string

- 値: WebLogic Serverユーザー・プリンシパルの名前。

グループ・プリンシパル

- 属性ID: urn:oasis:names:tc:xacml:2.0:subject:group

- データ型: string

- 値: WebLogic Serverグループ・プリンシパルの名前。

ロール

- 属性ID: urn:oasis:names:tc:xacml:2.0:subject:role

- データ型: string

- 値: XACMLロール・マッピング・プロバイダによって解決された1つまたは複数のロールの名前。

注意: WebLogic Serverでは、この属性を定義しているRBACプロファイル仕様の一部のみがサポートされています。

SOAPドキュメントに署名したサブジェクト

- 属性ID: urn:bea:xacml:2.0:subject:context:com.bea.contextelement.webservice.Integrity{{namespace}element}
namespaceおよびelementには、署名されたネームスペースと要素を指定します。

例:

urn:bea:xacml:2.0:subject:context:com.bea.contextelement.webservice.Integrity{{ http://schemas.xmlsoap.org/soap/envelope/}Body}

- データ型: string

- 値:要素に署名したJavaサブジェクト(ユーザーIDまたはグループID)。

例

Webサービスへのアクセスを保護するために使用できるセキュリティ・ロールを、表A-7に示した識別子を使用して定義しているXACMLドキュメントの例については、「例7-2」を参照してください。

WebLogic ServerのXACML関数

以下の節では、XACMLのコア仕様に定義されている関数以外に、WebLogic ServerのXACMLプロバイダでサポートされる関数について説明します。

- カスタム・データ型のバリアント

- その他の関数

- 日付および時刻の変換

- 算術変換および算術関数

- オブジェクト型の変換

- オブジェクトの比較

- 文字列の比較と操作

カスタム・データ型のバリアント

以下の関数識別子は、標準のXACML関数を直接移植したもので、XMLおよびWebLogic Serverのデータ型long、float、decimal、およびbea:Characterに使用できます。これらのデータ型の詳細は、Oracle WebLogic Server APIリファレンスのcom.bea.common.security.xacml.Typeを参照してください。

この一覧のtypeには、データ型の名前(long、float、decimal、またはcharacter)が入ります。

urn:bea:xacml:2.0:function:type-equal
urn:bea:xacml:2.0:function:type-greater-than
urn:bea:xacml:2.0:function:type-greater-than-or-equal
urn:bea:xacml:2.0:function:type-less-than
urn:bea:xacml:2.0:function:type-less-than-or-equal
urn:bea:xacml:2.0:function:type-one-and-only
urn:bea:xacml:2.0:function:type-bag-size urn:bea:xacml:2.0:function:type-is-in
urn:bea:xacml:2.0:function:type-bag urn:bea:xacml:2.0:function:type-intersection
urn:bea:xacml:2.0:function:type-union
urn:bea:xacml:2.0:function:type-at-least-one-member-of
urn:bea:xacml:2.0:function:type-subset
urn:bea:xacml:2.0:function:type-set-equals

bea:Objectを比較する関数については、「オブジェクトの比較」を参照してください。

例

次に、urn:bea:xacml:2.0:function:character-equalを使用して2つのbea:characterを比較するConditionの例を示します。

<Condition>
<Apply FunctionId="urn:bea:xacml:2.0:function:character-equal">
<AttributeValue DataType="urn:bea:xacml:2.0:data-type:character">Q</AttributeValue>
<AttributeValue DataType="urn:bea:xacml:2.0:data-type:character">Q</AttributeValue>
</Apply>
</Condition>

その他の関数

表A-6に、標準のXACML関数以外にWebLogic SERVERで提供されるその他の関数をまとめます。

表A-6 その他のWebLogic Server XACML関数

関数

説明

in-development-mode

- URI : urn:bea:xacml:2.0:function:in-development-mode

- 入力値の型: null

- 戻り値の型: boolean

- 説明: この関数は、引数を取らず、レルムをホストするWebLogic Serverインスタンスのモードが開発モードである場合にtrueを返します。

『構成ウィザードによるドメインの作成』のWebLogicドメインの作成に関する項を参照してください。

instance-method

- URI : urn:bea:xacml:2.0:function:instance-method

- 入力値の型: bea:Object、string、bea:Classのバッグ、[bea:Object ... ]

- 戻り値の型: bea:Object

- 説明: この関数は、コンテナが現在のコンテキスト内で使用可能にするbea:Objectでメソッドを呼び出します。

この関数は、以下の引数を取ります。

- bea:Object。このJavaオブジェクトのメソッドが呼び出されます。bea:Objectを指定するには、環境識別子urn:bea:xacml:2.0:environment:context:keyを使用します。「環境識別子」を参照してください。

- string。メソッド名。

- bea:Classのバッグ。メソッドのシグネチャ内に宣言されているJavaクラス。必要なクラスを作成するには、Oracleのstring-to-class関数を使用します。「オブジェクト型の変換」を参照してください。

- 0個以上のbea:Objects。各オブジェクトは、メソッドに渡すパラメータ値を保持します。必要なオブジェクトを作成するには、Oracleのオブジェクト変換関数を使用します。「オブジェクト型の変換」を参照してください。

呼び出されたメソッドの戻り値は、関数からはbea:Objectとして返されます。voidを返すメソッドは呼び出されないことがあります。

instance-method-match

- URI : urn:bea:xacml:2.0:function:instance-method-match

- 入力値の型: bea:Object、string、[bea:Object ...]

- 戻り値の型: bea:Object

- 説明: この関数は、コンテナが現在のコンテキスト内で使用可能にするbea:Objectでメソッドを呼び出します。

この関数は、以下の引数を取ります。

- bea:Object。このJavaオブジェクトのメソッドが呼び出されます。bea:Objectを指定するには、環境識別子urn:bea:xacml:2.0:environment:context:keyを使用します。「環境識別子」を参照してください。

- string。メソッド名。

- 0個以上のbea:Objects。各オブジェクトは、メソッドに渡すパラメータ値を保持します。必要なオブジェクトを作成するには、Oracleのオブジェクト変換関数を使用します。「オブジェクト型の変換」を参照してください。

この関数は、パラメータbea:objectのメソッド名とクラス型を使用して、ターゲットのbea:Object内の適切なメソッドを検索します。ターゲットのbea:Objectに含まれるメソッドのうち、パラメータと一致するメソッドが1つだけではない場合は結果が確定されません。

呼び出されたメソッドの戻り値は、関数からはbea:Objectとして返されます。voidを返すメソッドは呼び出されないことがあります。

instance-method-v2

- URI : urn:bea:xacml:2.0:function:instance-method-v2

- 入力値の型: bea:Class、bea:Object、string、bea:Classのバッグ、[bea:Object ... ]

- 戻り値の型: bea:Object

- 説明: この関数は、コンテナが現在のコンテキスト内で使用可能にするbea:Objectでメソッドを呼び出します。

この関数は、以下の引数を取ります。

- bea:Class。bea:Objectのクラス型。クラスを作成するには、Oracleのstring-to-class関数を使用します。「オブジェクト型の変換」を参照してください。

- bea:Object。このJavaオブジェクトのメソッドが呼び出されます。bea:Objectを指定するには、環境識別子urn:bea:xacml:2.0:environment:context:keyを使用します。「環境識別子」を参照してください。

- string。メソッド名。

- bea:Classのバッグ。メソッドのシグネチャ内に宣言されているJavaクラス。必要なクラスを作成するには、Oracleのstring-to-class関数を使用します。「オブジェクト型の変換」を参照してください。

- 0個以上のbea:Objects。各オブジェクトは、メソッドに渡すパラメータ値を保持します。必要なオブジェクトを作成するには、Oracleのオブジェクト変換関数を使用します。「オブジェクト型の変換」を参照してください。

呼び出されたメソッドの戻り値は、関数からはbea:Objectとして返されます。voidを返すメソッドは呼び出されないことがあります。

instance-method-match-v2

- URI : urn:bea:xacml:2.0:function:instance-method-match-v2

- 入力値の型: bea:Class、bea:Object、string、[bea:Object ... ]

- 戻り値の型: bea:Object

- 説明: bea:Objectのクラス名、メソッド名、およびパラメータbea:Objectsのクラス型を使用して、ターゲットのbea:Object内の適切なメソッドを検索します。ターゲットのbea:Objectに含まれるメソッドのうち、パラメータと一致するメソッドが1つだけではない場合は結果が確定されません。

この関数は、以下の引数を取ります。

- bea:Class。bea:Objectのクラス型。クラスを作成するには、Oracleのstring-to-class関数を使用します。「オブジェクト型の変換」を参照してください。

- bea:Object。このJavaオブジェクトのメソッドが呼び出されます。bea:Objectを指定するには、環境識別子urn:bea:xacml:2.0:environment:context:keyを使用します。「環境識別子」を参照してください。

- string。メソッド名。

- 0個以上のbea:Objects。各オブジェクトは、メソッドに渡すパラメータ値を保持します。必要なオブジェクトを作成するには、Oracleのオブジェクト変換関数を使用します。「オブジェクト型の変換」を参照してください。

呼び出されたメソッドの戻り値は、関数からはbea:Objectとして返されます。voidを返すメソッドは呼び出されないことがあります。

instance-method-match-v3

- URI : urn:bea:xacml:2.0:function:instance-method-match-v3

- 入力値の型: string、bea:Object、string、stringのバッグ、[bea:Object ...]

- 戻り値の型: bea:Object

- 説明: bea:Objectのクラス名、メソッド名、およびパラメータbea:Objectsのクラス型を使用して、ターゲットのbea:Object内の適切なメソッドを検索します。ターゲットのbea:Objectに含まれるメソッドのうち、パラメータと一致するメソッドが1つだけではない場合は結果が確定されません。

この関数は、Java Reflection APIを使用して、指定されたbea:Objectでメソッドを呼び出します。この関数は、以下の引数を取ります。

- String。bea:Objectのクラス型の名前。

- bea:Object。このJavaオブジェクトのメソッドが呼び出されます。bea:Object.を指定するには、環境識別子urn:bea:xacml:2.0:environment:context:keyを使用します。「環境識別子」を参照してください。

- String。メソッド名。

- stringのバッグ。メソッド・シグネチャ内のパラメータのクラス名。

- 0個以上のbea:Objects。各オブジェクトは、メソッドに渡すパラメータ値を保持します。必要なオブジェクトを作成するには、Oracleのオブジェクト変換関数を使用します。「オブジェクト型の変換」を参照してください。

- 呼び出されたメソッドの戻り値は、関数からはbea:Objectとして返されます。voidを返すメソッドは呼び出されないことがあります。

例

次のポリシーは、リクエストが特定のURLパターンに一致すると、instance-method関数を使用してHttpServletRequest.getAuthType()メソッドを呼び出します(http://download.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getAuthTypeにある「Java Platform, Enterprise Edition 6 API Specification」のjavax.servlet.http.HttpServletRequest.getAuthType()を参照)。WebLogic ServerのContextHandlerは、サーブレット・コンテナ経由で受け付けるすべてのリクエストにおいて、このHttpServletRequestオブジェクトを認可プロバイダおよびロール・マッピング・プロバイダで使用できるようにします。URLリソースのすべてのポリシーは、このメソッドまたは他のHttpServletRequestメソッドを呼び出すことができます。

例A-1 HttpServletRequest.getAuthType()を呼び出すポリシー

<Policy xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os"
PolicyId="urn:sample:xacml:2.0:function:instance-method"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:
first-applicable">
<Description>function:instance-method</Description>
<Target>
<Resources>
<Resource>
<ResourceMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">type=&lt;url&gt;, application=MedRecEAR, contextPath=,uri=/docs/*</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:2.0:resource:
resource-ancestor-or-self"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"/>
</ResourceMatch>
</Resource>
</Resources>
</Target>
<!-- Declaring the instance-method function as a variable because this policy
invokes it multiple times.
-->
<VariableDefinition VariableId="authType">
<Apply FunctionId="urn:bea:xacml:2.0:function:instance-method">
<!-- Passing the HttpServletRequest object to the function, which the
BEA ContextHandler makes available to the security framework.
-->
<Apply FunctionId="urn:bea:xacml:2.0:function:object-one-and-only">
<EnvironmentAttributeDesignator
DataType="urn:bea:xacml:2.0:data-type:object"
AttributeId="urn:bea:xacml:2.0:environment:context:com.bea.
contextelement.servlet.HttpServletRequest" />
</Apply>
<!--  Passing "getAuthType()" as the name of the HttpServletRequest
method to invoke
-->
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">getAuthType</AttributeValue>
<!-- Because the getAuthType() method signature contains no parameters,
pass an empty bag of Class.
-->
<Apply FunctionId="urn:bea:xacml:2.0:function:class-bag" />
</Apply>
</VariableDefinition>
<!-- Creating a rule that allows access to the resource only if
the getAuthType() returns a non-null value and if the non-null
value is "CLIENT_CERT"
-->
<Rule RuleId="primary-rule" Effect="Permit">
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:not">
<Apply FunctionId="urn:bea:xacml:2.0:function:object-is-null">
<VariableReference VariableId="authType" />
</Apply>
</Apply>
<Apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<!-- Because the instance-method function returns a bea:Object,
this policy wraps the function in an object-to-string function,
which enables comparison a of the function output with another
string.
-->
<Apply FunctionId="urn:bea:xacml:2.0:function:object-to-string">
<VariableReference VariableId="authType" />
</Apply>
<!--  Declaring a String object to compare to the
HttpServletRequest.getAuthType() return value.
-->
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">CLIENT_CERT</AttributeValue>
</Apply>
</Apply>
</Condition>
</Rule>
<Rule RuleId="deny-rule" Effect="Deny" />
</Policy>

日付および時刻の変換

表A-7に、XACMLの日付と時刻を別のデータ型に変換するためのOracle提供の関数をまとめます。

表A-7 WebLogic Serverの日付および時刻の変換

関数

説明

dateTime-dayOfMonth

- URI : urn:bea:xacml:2.0:function:dateTime-dayOfMonth

- 入力値の型: dateTime

- 戻り値の型: integer

- 説明: この関数は、dateTime型の引数1つを取り、入力されたdateTimeによって示唆される日(その月の何日目か)を表す整数値を返します。
月の1日目は、値1で表されます。

dateTime-dayOfMonthMaximum

- URI : urn:bea:xacml:2.0:function:dateTime-dayOfMonthMaximum

- 入力値の型: dateTime

- 戻り値の型: integer

- 説明: この関数は、datetime型の引数1つを取り、その月の最終日が何日かを表すinteger値を返します。
たとえば、dateTimeが12月の日時を表す場合は、12月の最大日数を表す31を返します。うるう年の2月の日数は自動的に調整されます。

dateTime-dayOfWeek

- URI : urn:bea:xacml:2.0:function:dateTime-dayOfWeek

- 入力値の型: dateTime

- 戻り値の型: integer

- 説明: この関数は、dateTime型の引数1つを取り、入力されたdateTime.によって示唆される曜日(その週の何日目か)を表すinteger値を返します。
日曜日を週の始まりと考え、値1で表します。

dateTime-secondsOfDay

- URI : urn:bea:xacml:2.0:function:dateTime-secondsOfDay

- 入力値の型: dateTime

- 戻り値の型: integer

- 説明: この関数は、datetime型の引数1つを取り、入力されたdatetimeによって示唆される経過時間(その日が始まってから何秒経過したか)を表すinteger値を返します。

dayTimeDuration-timeZoneOffset

- URI : urn:bea:xacml:2.0:function:dayTimeDuration-timeZoneOffset

- 入力値の型: null

- 戻り値の型: dayTimeDuration

- 説明: この関数は、引数を取らず、現地時間とグリニッジ標準時(GMT)の時差を表すdayTimeDuration値を返します。

string-to-dateTime

- URI : urn:bea:xacml:2.0:function:string-to-dateTime

- 入力値の型: string

- 戻り値の型: dateTime

- 説明: この関数は、string型の引数1つを取り、その引数をdateTimeとして返します。

string-to-date

- URI : urn:bea:xacml:2.0:function:string-to-date

- 入力値の型: string

- 戻り値の型: date

- 説明: この関数は、string型の引数1つを取り、その引数をdateとして返します。

object-to-dateTime

- URI : urn:bea:xacml:2.0:function:object-to-dateTime

- 入力値の型: bea:Object

- 戻り値の型: dateTime

- 説明: この関数は、bea:Object型の引数1つを取り、その値をdateTimeオブジェクトとして返します。bea:Objectがjava.util.Calendarのインスタンスである場合は、その値が直接返されます。bea:Objectがjava.security.Timestampまたはjava.util.Dateのインスタンスである場合は、bea:Objectがjava.util.Calendarに変換され、そのCalendar値が返されます。それ以外の場合は、bea:Objectがjava.lang.Stringに変換され、そのStringがdateTime値に解析されます。

object-to-date

- URI : urn:bea:xacml:2.0:function:object-to-date

- 入力値の型: bea:Object

- 戻り値の型: date

- 説明: この関数は、bea:Object型の引数1つを取り、その値をdateオブジェクトとして返します。bea:Objectがjava.util.Calendarのインスタンスである場合は、その値が直接返されます。bea:Objectがjava.util.Dateのインスタンスである場合は、bea:Objectがjava.util.Calendarに変換され、そのCalendar値が返されます。それ以外の場合は、bea:Objectがjava.lang.Stringに変換され、そのStringがdate値に解析されます。

算術変換および算術関数

表A-8に、算術値を別の入力型に変換するためのOracle提供の関数、およびXACMLで定義されている算術関数の基本セットを拡張するためのOracle提供の関数をまとめます。

表A-8 Weblogic Serverの算術変換および算術関数

関数

説明

float-to-double

- URI : urn:bea:xacml:2.0:function:float-to-double

- 入力値の型: float

- 戻り値の型: double

- 説明: この関数は、float型の引数1つを取り、その引数をdoubleとして返します。

long-to-double

- URI : urn:bea:xacml:2.0:function:long-to-double

- 入力値の型: long

- 戻り値の型: double

- 説明: この関数は、long型の引数1つを取り、その引数をdoubleとして返します。

long-to-float

- URI : urn:bea:xacml:2.0:function:long-to-float

- 入力値の型: long

- 戻り値の型: float

- 説明: この関数は、long型の引数1つを取り、その引数をfloatとして返します。

integer-to-float

- URI : urn:bea:xacml:2.0:function:integer-to-float

- 入力値の型: integer

- 戻り値の型: float

- 説明: この関数は、integer型の引数1つを取り、その引数をfloatとして返します。

integer-to-long

- URI : urn:bea:xacml:2.0:function:integer-to-long

- 入力値の型: integer

- 戻り値の型: long

- 説明: この関数は、integer型の引数1つを取り、その引数をlongとして返します。

string-to-double

- URI : urn:bea:xacml:2.0:function:string-to-double

- 入力値の型: string

- 戻り値の型: double

- 説明: この関数は、string型の引数1つを取り、その引数をdoubleとして返します。

string-to-long

- URI : urn:bea:xacml:2.0:function:string-to-long

- 入力値の型: string

- 戻り値の型: long

- 説明: この関数は、string型の引数1つを取り、その引数をlongとして返します。

string-to-integer

- URI : urn:bea:xacml:2.0:function:string-to-integer

- 入力値の型: string

- 戻り値の型: integer

- 説明: この関数は、string型の引数1つを取り、その引数をintegerとして返します。

string-to-float

- URI : urn:bea:xacml:2.0:function:integer-to-long

- 入力値の型: string

- 戻り値の型: float

- 説明: この関数は、string型の引数1つを取り、その引数をfloatとして返します。

to-degrees

- URI : urn:bea:xacml:2.0:function:to-degrees

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数1つを取り、その値をラジアンから度に変換して、その角度値をdoubleとして返します。

to-radians

- URI : urn:bea:xacml:2.0:function:to-radians

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数1つを取り、その値を度からラジアンに変換して、そのラジアン値をdoubleとして返します。

acos

- URI : urn:bea:xacml:2.0:function:acos

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数1つを取り、その引数の円弧のコサインをdoubleとして返します。

asin

- URI : urn:bea:xacml:2.0:function:asin

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数1つを取り、その引数の円弧のサインをdoubleとして返します。

atan

- URI : urn:bea:xacml:2.0:function:atan

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数1つを取り、その引数の円弧のタンジェントをdoubleとして返します。

atan2

- URI : urn:bea:xacml:2.0:function:atan2

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、点のx座標とy座標を表すdouble型の引数を2つ取ります。x座標に対応するr値の極座標にある点のシータ構成要素をdouble値として返します。

ceil

- URI : urn:bea:xacml:2.0:function:ceil

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数1つを取り、その引数値以上の整数のうち最小の値をdouble値として返します。

cos

- URI : urn:bea:xacml:2.0:function:cos

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数1つを取り、その引数のコサインをdoubleとして返します。

exp

- URI : urn:bea:xacml:2.0:function:exp

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数1つを取り、オイラーの数eを引数値で累乗した値をdouble値として返します。

ieee-remainder

- URI : urn:bea:xacml:2.0:function:ieee-remainder

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数2つを取り、IEEE 754標準に従って2つの引数値を剰余演算した結果をdouble値として返します。「http://grouper.ieee.org/groups/754/」を参照してください。

log

- URI : urn:bea:xacml:2.0:function:log

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数1つを取り、その自然対数をdoubleとして返します。

maximum

- URI : urn:bea:xacml:2.0:function:maximum

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数2つを取り、大きい方の値をdoubleとして返します。

minimum

- URI : urn:bea:xacml:2.0:function:minimum

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数2つを取り、小さい方の値をdoubleとして返します。

pow

- URI : urn:bea:xacml:2.0:function:pow

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数2つを取り、1番目の引数値を2番目の引数値で累乗した結果をdouble値として返します。

random-number

- URI : urn:bea:xacml:2.0:function:random-number

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数2つを取り、1番目の引数値以上かつ2番目の引数値未満の乱数をdouble値として返します。

rint

- URI : urn:bea:xacml:2.0:function:rint

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数1つを取り、その引数値にもっとも近い整数をdouble値として返します。引数値より大きい整数値との差と、引数値より小さい整数値との差が等しい場合は、偶数値の方が返されます。

sqrt

- URI : urn:bea:xacml:2.0:function:sqrt

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数1つを取り、その平方根をdoubleとして返します。

tan

- URI : uurn:bea:xacml:2.0:function:tan

- 入力値の型: double

- 戻り値の型: double

- 説明: この関数は、double型の引数1つを取り、そのタンジェントをdoubleとして返します。

オブジェクト型の変換

WebLogic Serverには、XACMLデータをJavaオブジェクトに変換するための様々な関数が用意されています。各関数のURIは、次のようになっています。

urn:bea:xacml:2.0:function:type-to-object

typeには、XACMLデータ型の名前が入ります。表A-9に、すべてのデータ型と、それらに対応する関数によって返されるJavaオブジェクトをまとめます。

たとえば、この関数では、java.lang.Stringオブジェクトとして「test」が返されます。

<Apply
FunctionId="urn:bea:xacml:2.0:function:string-to-object">test</Apply>

表A-9 データからJavaオブジェクトへの変換

型が等しい場合...

urn:bea:xacml:2.0:function:type-to-object関数は次を返します...

character

java.lang.Character

string

java.lang.String

boolean

java.lang.Boolean

integer

java.lang.Integer

double

java.lang.Double

float

java.lang.Float

long

java.lang.Long

decimal

java.lang.Double

base64Binary

java.lang.Byte[]

hexBinary

java.lang.Byte[]

date

java.util.Calendar

time

java.util.Calendar

dateTime

java.util.Calendar

dayTimeDuration

java.lang.Long

yearMonthDuration

java.lang.Integer

rfc822Name

java.lang.String

x500Name

java.lang.String

anyURI

java.net.URI

ipAddress

java.lang.String

dnsAddress

java.lang.String

表A-10には、文字列またはJavaオブジェクトを別のデータ型またはオブジェクト型に変換するためのOracle提供の関数をまとめます。コンテナが現在のコンテキストで使用可能にするオブジェクトを渡すには、環境識別子urn:bea:xacml:2.0:environment:context:keyを使用して、bea:Object.を指定します。「環境識別子」を参照してください。

表A-10 WebLogic Serverオブジェクトの変換

関数

説明

string-to-class

- URI : urn:bea:xacml:2.0:function:string-to-class

- 入力値の型: string

- 戻り値の型: bea:Class

- 説明: この関数は、string型の引数1つを取り、その引数値でjava.lang.Class.forName()を呼び出して、その結果をbea:Classとして返します。

object-to-string

- URI : urn:bea:xacml:2.0:function:object-to-string

- 入力値の型: bea:Object

- 戻り値の型: string

- 説明: この関数は、bea:Object型の引数1つを取り、その引数値でjava.lang.Object.toString()を呼び出して、その結果をstringとして返します。

object-to-double

- URI : urn:bea:xacml:2.0:function:object-to-double

- 入力値の型: bea:Object

- 戻り値の型: double

- 説明: この関数は、bea:Object型の引数1つを取り、その値をdoubleとして返します。bea:Objectがdoubleのインスタンスである場合は、その値が直接使用されます。bea:Objectがjava.lang.Numberのインスタンスである場合は、その値でNumber.doubleValue()を呼び出します。それ以外の場合は、bea:Objectがjava.lang.Stringに変換され、そのStringがdouble値に解析されます。

object-to-integer

- URI : urn:bea:xacml:2.0:function:object-to-integer

- 入力値の型: bea:Object

- 戻り値の型: integer

- 説明: この関数は、bea:Object型の引数1つを取り、その値をintegerとして返します。bea:Objectがjava.lang.Integerのインスタンスである場合は、その値が直接使用されます。bea:Objectがjava.lang.Numberのインスタンスである場合は、その値でNumber.intValue()を呼び出します。それ以外の場合は、bea:Objectがjava.lang.Stringに変換され、そのStringがintegerに解析されます。

オブジェクトの比較

表A-11に、Javaオブジェクトを比較するためのOracle提供の関数をまとめます。

表A-11 WebLogic Serverオブジェクトの比較

関数

説明

object-is-null

- URI : urn:bea:xacml:2.0:function:object-is-null

- 入力値の型: bea:Object

- 戻り値の型: boolean

- 説明: この関数は、bea:Object型の引数1つ を取り、そのオブジェクト参照がJavaキーワードnullと 等しいかどうかを示すboolean値を返します。指定したオブジェクト参照に対応するオブジェクトがない場合はtrueを返します。

object-equal

- URI : urn:bea:xacml:2.0:function:object-equal

- 入力値の型: bea:Object、bea:Object

- 戻り値の型: boolean

- 説明: この関数は、bea:Object型の引数2つを取り、java.lang.Object.equals()が呼び出され、2.つ のObjectは等しいかどうかを表示するbooleanの値を返します。
java.lang.Object.equals()メソッドの詳細は、http://download.oracle.com/javase/6/docs/api/java/lang/Object.html#equals%28java.lang.Object%29を参照してください。

object-greater-than

- URI : urn:bea:xacml:2.0:function:object-greater-than

- 入力値の型: bea:Object、bea:Object

- 戻り値の型: boolean

- 説明: この関数は、bea:Object型の引数2つを取り、1番目のbea:Objectが2番目のbea:Objectより大きいかどうかを示すboolean値を返します。2つのbea:Objectはjava.lang.Comparableを実装している必要があります。実装していない場合は評価が確定されません。

object-greater-than-or-equal

- URI : urn:bea:xacml:2.0:function:object-greater-than-or-equal

- 入力値の型: bea:Object、bea:Object

- 戻り値の型: boolean

- 説明: この関数は、bea:object型の引数2つを取り、1番目のbea:Objectが2番目のbea:object以上であるかどうかを示すboolean値を返します。2つのbea:Objectはjava.lang.Comparableを実装している必要があります。実装していない場合は評価が確定されません。

object-less-than

- URI : urn:bea:xacml:2.0:function:object-less-than

- 入力値の型: bea:Object、bea:Object

- 戻り値の型: boolean

- 説明: この関数は、bea:Object型の引数2つを取り、1番目のbea:Objectが2番目のbea:Objectより小さいかどうかを示すboolean値を返します。2つのbea:Objectはjava.lang.Comparableを実装している必要があります。実装していない場合は評価が確定されません。

object-less-than-or-equal

- URI : urn:bea:xacml:2.0:function:object-less-than-or-equal

- 入力値の型: bea:Object、bea:Object

- 戻り値の型: boolean

- 説明: この関数は、bea:Object型の引数2つを取り、1番目のbea:Objectが2番目のbea:Object以下であるかどうかを示すboolean値を返します。2つのbea:Objectはjava.lang.Comparableを実装している必要があります。実装していない場合は評価が確定されません。

object-collection-contains

- URI : urn:bea:xacml:2.0:function:object-collection-contains

- 入力値の型: bea:Object、bea:Object

- 戻り値の型: boolean

- 説明: この関数は、bea:Object型 の引数2つを取り、1番目のbea:ObjectはCollection.contains()によって決定された2番目のbea:Objectを含むかどうかを表示するbooleanを返します。1番目のbea:Objectはjava.util.Collectionを実装している必要があります。実装していない場合は評価が確定されません。
Collection.contains()メソッドの詳細は、http://download.oracle.com/javase/6/docs/api/java/util/Collection.html#contains%28java.lang.Object%29を参照してください。

object-collection-contains-all

- URI : urn:bea:xacml:2.0:function:object-collection-contains-all

- 入力値の型: bea:Object、bea:Object

- 戻り値の型: boolean

- 説明: この関数は、bea:Object型 の引数2つを取り、1番目のbea:ObjectはCollection.containsAll()によって決定された2番目のbea:Objectを含むかどうかを表示するbooleanを返します。2つのbea:Objectはjava.util.Collectionを実装している必要があります。実装していない場合は評価が確定されません。
Collection.containsAll()メソッドの詳細は、http://download.oracle.com/javase/6/docs/api/java/util/Collection.html#containsAll%28java.util.Collection%29を参照してください。

文字列の比較と操作

表A-12に、Javaオブジェクトを比較するためのOracle提供の関数をまとめます。

表A-12 Weblogic Serverでの文字列の比較と操作

関数

説明

string-char-at

- URI : urn:bea:xacml:2.0:function:string-char-at

- 入力値の型: string、integer

- 戻り値の型: bea:Character

- 説明: この関数は、string型およびinteger型の引数2つを取り、string内でIntergerによって示される位置の文字を検索して、その文字をbea:Characterとして返します。

string-compare-to-ignore-case

- URI : urn:bea:xacml:2.0:function:string-compare-to-ignore-case

- 入力値の型: string、string

- 戻り値の型: integer

この関数は、string型の引数2つを取り、2つのstring引数を比較した結果をintegerとして返します。

- 2つがまったく同じ文字列である場合は0を返します。

- 1番目の文字列が、辞書的に2番目の文字列よりも先に出現する場合は0より小さい値を返します。

- 1番目の文字列が、辞書的に2番目の文字列よりも後に出現する場合は0より大きい値を返します。

比較では、大文字小文字は区別されません。

string-contains

- URI : urn:bea:xacml:2.0:function:string-contains

- 入力値の型: string、string

- 戻り値の型: boolean

- 説明: この関数は、string型の引数2つを取り、1番目のstringに2番目のstringの値が含まれるかどうかを示すboolean値を返します。

string-starts-with

- URI : urn:bea:xacml:2.0:function:string-starts-with

- 入力値の型: string、string

- 戻り値の型: boolean

- 説明: この関数は、string型の引数2つを取り、1番目のstringの値が2番目のstringの値で始まるかどうかを示すboolean値を返します。

string-ends-with

- URI : urn:bea:xacml:2.0:function:string-ends-with

- 入力値の型: string、string

- 戻り値の型: boolean

- 説明: この関数は、string型の引数2つを取り、1番目のstringの値が2番目のstringの値で終わるかどうかを示すboolean値を返します。

string-length

- URI : urn:bea:xacml:2.0:function:string-length

- 入力値の型: string

- 戻り値の型: integer

- 説明: この関数は、string型の引数1つを取り、そのstring値の長さを表すintegerを返します。

string-replace

- URI : urn:bea:xacml:2.0:function:string-replace

- 入力値の型: string、bea:Character、bea:Character

- 戻り値の型: string

- 説明: この関数は、string型、bea:Character型、およびbea:character型の引数3つを取り、1番目のbea:character値が文字列内に含まれる場合は、それらをすべて2番目のbea:Characterの値で置き換えて、その結果をstringとして返します。

string-substring

- URI : urn:bea:xacml:2.0:function:string-substring

- 入力値の型: string、integer、integer

- 戻り値の型: string

- 説明: この関数は、string型、integer型、およびinteger型の引数3つを取り、1番目のinteger引数の索引(この索引自体を含む)から2番目のinteger引数の索引を除外して作成したstring引数のサブ文字列をstringとして返します。

string-normalize-to-upper-case

- URI : urn:bea:xacml:2.0:function:string-normalize-to-upper-case

- 入力値の型: string

- 戻り値の型: string

- 説明: この関数は、string型の引数1つを取り、その文字列を大文字に正規化した結果をstringとして返します。

ルールおよびポリシーの結合アルゴリズム

判定に複数のPolicySetを適用する場合は、それらの結果が次のアルゴリズムで結合されます。

urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:deny-overrides

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