ヘッダーをスキップ
Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド
11gリリース1(11.1.1)
B56235-02
  目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

13 Oracle Platform Security Servicesを使用したセキュアなアプリケーションの開発の概要

この章では、Oracle Platform Security Servicesを使用して、Oracle Fusion Middlewareと併用できるセキュアなアプリケーションを開発およびデプロイする場合の特徴と利点について説明します。

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

13.1 開発者のためのOracle Platform Security Servicesについて

この項では、Oracle Platform Security Servicesを使用してアプリケーションを保護することの利点を説明し、このツールセットの主要なコンポーネントを紹介します。この項の内容は次のとおりです。

13.1.1 開発サイクル

JavaEEソフトウェア開発は、開発、デプロイ、管理のサイクルに基づいて行われます。Oracle Platform Security Servicesのセキュリティの実装は、このサイクルのすべての段階で重要な役割を果たします。

次のリストは、JavaEEの開発サイクルをまとめたもので、セキュア・アプリケーションの開発に固有なタスクに重点を置き、OPSSによって提供されるセキュリティ拡張を強調しています。

  1. 開発者は、ビジネス要件に基づき、Webコンポーネント、エンタープライズBean、サーブレットおよびアプリケーション・クライアントを作成します。

    開発者が宣言的な手法を取ることができる間は、Oracle ADF(OPSS APIを利用)を使用すると、さらなる価値が得られます。

  2. 開発者は、JavaEEの論理ロールを定義し、セキュリティ制約を通じて論理ロールに権限を割り当てます。これらはすべて標準のJavaEEデプロイメント・ディスクリプタの構成によって実行されます。

  3. コンポーネントがアセンブルされ、組み合されてEnterprise Archive(EAR)ファイルが作成されます。

    この処理の一部として、アセンブラは環境に適したオプションを指定します。

  4. アセンブラはアプリケーションレベルのセキュリティ制約を定義し、モジュールレベルの構成間の潜在的な競合を解決します。

  5. EARファイルは、Oracle WebLogic Serverにデプロイされます。

    デプロイ・プロセスの一部として、デプロイヤがJavaEEのロールをデプロイ・ユーザーおよびロールにマップする場合もあります。

  6. システム管理者は、デプロイされたアプリケーションを維持および管理します。

    このタスクには、アプリケーション顧客からの要求に応じてデプロイ環境でロールとユーザーを作成および管理することも含まれます。

Java 2またはJAASの機能を使用して、コードベースまたはサブジェクトベースのファイングレイン・アクセス制御を可能にする場合、従来の手順には次の処理が含まれます。

  1. 開発者は、アクセスされる可能性があり、適宜保護する必要のあるすべてのリソースを特定します。

  2. 開発者は、これらのリソースを保護するためのパーミッションを定義します。

  3. 開発者は、ランタイム認可チェック用のコードを実装します。

  4. システム管理者は、目的のパーミッションを適用するために必要なすべてのポリシーの構成を管理します。ポリシーのプロビジョニングは実行時より前に完了しておく必要があります。

Oracle ADFおよびOPSSでは、次の拡張機能が提供されます。

  • 設計時: アプリケーション・ロールのモデリング、パーミッションとしてのリソースの定義、ロールに対するパーミッションの割当て。アプリケーションの資格証明管理がサポートされています。たとえば、ADF接続では、設計時、資格証明を資格証明ストア・フレームワークに格納できます。

  • デプロイ時: ポリシーおよび資格証明移行オプションが使用可能です。

  • デプロイ後、開発者は、エンタープライズ・ユーザーまたはグループに対するアプリケーション・ロールのマッピング(実行時に反映される)などの重要なタスクを実行します。

13.1.2 Javaアプリケーションを保護する際の課題

Java開発者は、セキュア・アプリケーションの開発時、次のような課題に直面します。

  • ファイングレイン認可、資格証明のマッピング、ロールのマッピング、監査またはシングル・サインオンとの統合のためのAPIがJavaEE標準で定義されていない。

  • 開発者は、セキュリティに関する深い知識を取得する必要があり、アプリケーションのビジネス・ロジックに集中することができない。

  • セキュリティ・エクスペリエンスがプラットフォーム間で一貫していない。たとえば、カスタムのセキュリティ・ソリューションでは独自のセキュリティ・フレームワークが開発されることが多く、そのようなフレームワークはプラットフォーム間で移植できない場合が多い。

  • JavaEEアプリケーションを保護するためのカスタム・ソリューションには、大規模なエンタープライズ・セキュリティ・デプロイメントのサポートが欠落している場合が多い。

    カスタム・ソリューションには、管理性、可用性、スケーラビリティ、信頼性などの重要な側面が欠落している場合が多い。

13.1.3 Oracle Platform Security Servicesによる課題の克服

Oracle Platform Security Services(OPSS)は移植可能なセキュリティ・サービスの抽象レイヤーで、強力なセキュリティ・フレームワークを提供し、開発の時間と手間を節約できます。OPSSにより、従来のJavaEE開発が様々な面で向上します。

  • 認証、認可、監査、ロール管理、資格証明管理などの基本的なセキュリティ・サービスが提供される。

  • 開発者がアプリケーション・ロジックに集中できる。

  • Oracle Fusion Middleware製品と同じサービスが提供される。

    • OPSSは、Oracle WebLogic Server、Oracle Entitlement Server、Oracle SOA Suite、Oracle WebCenterなどを含む、FusionアプリケーションおよびOracle Fusion Middlewareコンポーネント用のセキュリティ・プラットフォームです。


      注意:

      これは、OPSSに依存している製品のほんの一例です。

  • 標準ベースで、エンタープライズ対応である。

    • エンタープライズ・デプロイメントをサポートするためのストレステスト済である。

    • 様々なLDAPサーバーおよびシングル・サインオン(SSO)システムに渡って相互運用が可能である。

    • Oracle WebLogic Serverで認定済である。

  • すべてのタイプのアプリケーション(社内、サード・パーティ、Oracle Fusion)に対して同じAPIセットが提供される。

  • 抽象レイヤーの使用により開発時間を最適化できる。

  • アプリケーション・コードに影響を与えることなくセキュリティ・ルールを変更できるので、アプリケーションの保守が容易になる。

  • レガシー・セキュリティ・プロバイダとサード・パーティ・セキュリティ・プロバイダの統合が可能である。

アイデンティティ管理(IdM)に対するOPSSのサポートは、次のとおりです。

  • 小規模から中規模のアプリケーションの構築およびデプロイを顧客が実行できる軽量インフラストラクチャ

  • IdMシステムに対するプラグイン・インタフェース

    • OPSSに対して構築されたアプリケーションは、一元的にデプロイされるアイデンティティ管理システムにプラグインできる。

    • 顧客は、アプリケーションをスケール変更して、一元的にデプロイされるアイデンティティ管理システムに切り替えることができる。

    • IdMシステム間で切り替える際、アプリケーション内のコード変更は不要である。

13.1.4 OPSSのアーキテクチャ

図13-1 は、OPSSアーキテクチャの基本的なコンポーネントを示しています。このマニュアルでこれまでに説明したほとんどの機能には、アプリケーション開発者が使用できる固有のAPIがあります。基礎となるSPI(サービス・プロバイダ・インタフェース)は、大部分がアプリケーション開発者や管理者に対して透過的です。SPIについては、第1.2項「OPSSのアーキテクチャの概要」に簡単な説明があります。

図13-1 OPSSのアーキテクチャ

図13-1については周囲のテキストで説明しています。

Oracle Platform Securityのアーキテクチャには、次の特徴があります。

  • アプリケーション・レイヤーを基礎となる実装から切り離した階層型アーキテクチャ。

  • 明示的な拡張点(SPIレイヤー経由)を用意した拡張可能なアーキテクチャ。カスタマイズした実装(カスタム・ログイン・モジュールなど)をこの拡張点でフレームワークにプラグインすることで、特殊機能を提供できます。

13.2 Oracle Platform Security ServicesのAPI

この項では、Oracle Platform Security Servicesを使用する開発者が使用可能なAPIについて説明します。

13.2.1 LoginService API

OPSSでは、JavaSEアプリケーションがアイデンティティ・ストアから情報を取得したり、アイデンティティ・ストアのコンテンツを管理できるようにする、LoginService認証APIを用意しています。

認証は、サブジェクトにプリンシパルを移入するコンポーネントであるログイン・モジュールによりサポートされます。このプロセスは、2つの異なる段階で行われます。

  • 第一段階では、ユーザーによって提供された資格証明を使用して、ログイン・モジュールがユーザーの認証を試みます。

  • 第2段階では、ログイン・モジュールによって、関連プリンシパルがサブジェクトに割り当てられ、最終的にそれが権限が付与されたアクションを実行するために使用されます。

詳細は、第15章「認証の開発」を参照してください。

13.2.2 ユーザーおよびロールAPI

ユーザーおよびロールAPIフレームワークを使用すると、アプリケーションは、基礎となるアイデンティティ・リポジトリの種類を問わず、統一的で移植可能な方法でアイデンティティ情報(ユーザーとロール)にアクセスすることができます。基盤となるアイデンティティ・ストアは、Oracle Internet DirectoryのようなLDAPディレクトリ・サーバーでも、データベース、フラット・ファイルまたはその他のカスタム・リポジトリでもかまいません。

このAPIフレームワークには、移植可能な方法でプログラム的にリポジトリにアクセスするための便利な方法が用意されているため、アプリケーション開発者は、個々のアイデンティティ・ソースに対応した複雑な処理を考慮するという煩雑な作業から解放されます。このフレームワークにより、アプリケーションは異なるリポジトリをシームレスに操作できるようになります。アプリケーションは、コードを変更しなくても、各種のアイデンティティ・リポジトリを切り替えて使用することができます。

サポートされる操作には、ユーザーとロールの作成、更新、削除のほか、ユーザーおよびロールの属性や特定の情報の検索などがあります。たとえば、特定のロールのすべてのユーザーの電子メール・アドレスを検索できます。

このAPIでは、次のものがサポートされています。

  • Oracle Internet DirectoryなどのLDAPディレクトリ・サーバー

  • フラット・ファイル

  • データベースなどその他のカスタム・リポジトリ(そのリポジトリのカスタム・プロバイダを実装することによる)

ユーザーおよびロールAPIを使用すると、次のことを実行できます。

  • 移植可能な方法でプログラム的にリポジトリにアクセスする。

  • 特定のアイデンティティ・ソースに対応した複雑な処理を考慮する必要性を除去する。

  • 各自のアプリケーションから様々なリポジトリをシームレスに操作できるようにする。

  • アプリケーションのコードを変更せずに様々なアイデンティティ・リポジトリ間で切替えを行う。

詳細は、第18章「ユーザーおよびロールAPIを使用した開発」を参照してください。

13.2.3 JAAS認可とJpsAuth.checkPermission API

JavaEE認可モデルでは、EJBおよびURLで参照されるWebリソースへのアクセスが、ロール・メンバーシップを使用して制御されます。Java 2認可モデルでは、(ロール・メンバーシップではなく)パーミッションを使用して、アクセスの決定が制御されます。

認可ポリシーは、アプリケーション・コード内で指定できます。機密性の高いコード行の前には、サブジェクトが特定のコード・セクションの実行に適したパーミッションを持っているかどうかを確認するコールが挿入されます。サブジェクトに適切なパーミッションが与えられていない場合、コードはセキュリティ例外をスローします。

Java 2認可は、ロールではなくパーミッションに基づき、アクセス制御の決定は、SecurityManagerまたはAccessControllerへのコールによって評価されます。このモデルをJAASと併用すると、プログラム的な認可機能が使用できるため、リソースに対するファイングレイン制御が可能になります。

Oracle Fusion Middlewareでは、JavaEE DD/アノテーション・ベースの認可とJAAS/Java2パーミッション・ベースの認可を使用した認可がサポートされています。認可ポリシーを適用するための宣言的およびプログラム的なアプローチがともにサポートされています。後者はJpsAuth.checkPermission APIによって実装され、AccessController.checkPermissionも使用できます。

OPSS APIを使用すると、従来の認可モデルに比べて次のような利点があります。

  • OPSSは、パーミッションが割り当てられるアプリケーション・ロールを使用する機能を付けてJAASを拡張します。

  • OPSSでは、標準のJAASモデルにはないポリシー管理のサポートを提供します。例は、第17.2.2項「ポリシーの管理」を参照してください。

  • 標準のcheckPermission APIではなくJpsAuth.checkPermission OPSS APIを使用すると、デバッグ機能の強化、統合された監査サポートなどの利点も得られます。

OPSSの認可機能の詳細は、第17章「認可の開発」を参照してください。

13.2.4 資格証明ストア・フレームワークAPI

資格証明ストアは、資格証明およびその集合のためのセキュアな中央ストアです。複数のアプリケーションで同一の資格証明ストアを使用することができます。

資格証明ストア・フレームワーク(CSF)APIは、アプリケーションが資格証明ストアにアクセスするためのメカニズムを提供します。

CSF APIは、ファイルベース(Oracleウォレット)およびLDAPベースの資格証明ストアをサポートします。

CSF APIによって提供される重要な機能には、特定のマップ名の資格証明を返す、特定のマップ名に資格証明を割り当てる、特定のマップ名から資格証明を削除する、資格証明のマップおよびキーに関連したその他の操作などがあります。

CredentialStoreに対する操作は、CSFで使用されるファイングレイン・アクセス制御モデルを実装するCredentialAccessPermissionによって保護されます。

このAPIの詳細は、第16章「資格証明ストア・フレームワークを使用した開発」を参照してください。

13.3 Oracle Platform Security Servicesの一般的な使用方法

同じOPSS APIのセットを、JavaEE開発者とJavaSE開発者の両方が使用できます。この項では、OPSS APIで一般的なアプリケーションを示し、JavaEEの実装とJavaSEの実装の相違点を説明します。

13.3.1 OPSS APIを使用するJavaEEアプリケーション

この例は、OPSSセキュリティAPIで機能拡張された従来のJavaEEアプリケーションを示しています。

図13-2 複数のOPSS APIを使用したJavaEEアプリケーション

図13-2については周囲のテキストで説明しています。

主要な機能には、次のものがあります。

  • Oracle WebLogic Serverとの統合。

  • LDAPディレクトリまたはファイルベースの資格証明ストア内で資格証明を保護する資格証明ストア・フレームワークAPI。ここには、様々なタイプの資格証明(外部データベースの資格証明、外部Webサービスの資格証明など)が格納されます。

  • アイデンティティ・ストアに格納されている属性を問い合せるユーザーおよびロールAPI。

  • 認可用のJpsAuth.checkPermission API。

13.3.2 OPSS APIによる認証

認証の実装に対し、開発者には次のような選択肢があります。

  • 宣言的認証。web.xml内で認証を構成します。これが標準のJavaEEセキュリティです。

  • プログラム的セキュリティ。Oracle Fusion Middlewareでは、次のようないくつかのAPIを提供しています。

    • Oracle WebLogic Serverの認証API、weblogic.security.auth.Authenticate

    • OPSSのoracle.security.jps.service.login.LoginService API(JavaSEアプリケーション用)。このAPIは、ユーザー/パスワードによる認証とユーザー名のアサーションをサポートしています。アサーション機能は、JpsPermissionと名前IdentityAssertionによって保護されます。

この例は、トークンまたはユーザー資格証明を使用してアイデンティティをアサートする必要があるJavaEEアプリケーションを示しています。

図13-3 プログラム的認証

図13-3については周囲のテキストで説明しています。

主要な機能には、次のものがあります。

  • Authenticate APIを使用したプログラム的認証のためのアプリケーションにより提供されるユーザー名とパスワード。

  • WebLogic認証プロバイダの使用。

  • トークンを使用したアイデンティティ・アサーション(パスワードを使用しない認証)。

  • コード・ソース・パーミッションによって保護されるアサーション。コード・ソース・パーミッション(コードベースのパーミッション付与oracle.security.jps.JpsPermission、名前IdentityAssertion、アクションexecute)が付与されているアプリケーションだけがこのAPIをアイデンティティ・アサーションに使用できます。


関連項目:


13.3.3 プログラム的な認可

この例では、移植可能なファイングレイン認可を使用するJavaEEアプリケーションを示します。

図13-4 ファイングレイン認可

図13-4については周囲のテキストで説明しています。

主要な機能には、次のものがあります。

  • JpsAuth.checkPermission APIコールによる認可。

  • 認可の決定に関する監査。

13.3.4 資格証明ストア・フレームワーク

この例では、データベースなどの外部システムの資格証明にアクセスし、これを格納する必要があるアプリケーションを示します。

図13-5 資格証明ストア・フレームワークへの外部パスワードの格納

図13-5については周囲のテキストで説明しています。

主要な機能には、次のものがあります。

  • 資格証明ストアに安全に格納された資格証明(ユーザー名とパスワード、対称鍵など)。

  • Oracle Fusion Middlewareの追加設定なしですぐに使用できるOracleウォレットと呼ばれるファイルベースの資格証明ストアのほか、LDAPベースの資格証明ストアのサポート。

  • 資格証明を、Oracle Enterprise Manager Fusion Middleware Controlまたはコマンドライン・ツールWLSTで管理できる。

  • 資格証明ストアの操作を監査できる。

13.3.5 ユーザーおよびロール

この例では、アイデンティティ・ストア内のユーザーを検索する必要があるアプリケーションを示します。「APAC」内の全ユーザーの検索や、特定のロール内のユーザーの全電子メールの検索など、様々な問合せを実行する必要があります。

図13-6 ユーザーおよびロールAPIによるアイデンティティ・ストアの検索

図13-6については周囲のテキストで説明しています。

主要な機能には、次のものがあります。

  • ユーザーおよびロールAPIをコールしてユーザー属性にアクセスする。

  • 同一のAPIが、デフォルトの認証プロバイダまたは外部LDAPストアのユーザー属性で機能する。

    ユーザーおよびロールAPIは、認証プロバイダ内の構成(デフォルトまたはその他任意のLDAPベースの認証)に基づいて自動的に構成されます。

  • 属性の格納先とは無関係に同じAPI。

13.3.6 Oracle ADFによる認可

Oracle ADFを使用した認可の例は、第13.4.2項「Oracle ADFによるOPSSの使用方法」を参照してください。

13.3.7 JavaSEアプリケーション

この例では、様々なOPSS APIを使用するJavaSE Swingアプリケーションを示します。

図13-7 OPSS APIを使用するJavaSEアプリケーション

図13-7については周囲のテキストで説明しています。

注意:

LDAPベースのストアでは、図のように、ポリシーと資格証明の両方が同一のストアに保持されますが、ファイルベースのストアではそれぞれ別々のファイルに保持されます。

主要な機能には、次のものがあります。

  • 認証用のLoginService API。

  • 認可用のJpsAuth.CheckPermission。

  • LDAPまたはその他のバックエンドに格納されている属性を問い合せるユーザーおよびロールAPI。

  • 資格証明ストアによる資格証明の保護。

13.4 OPSSとOracle Application Development Frameworkの併用

Oracle ADFを使用してアプリケーションの開発およびデプロイを行う際は、OPSSのセキュリティ機能を直接使用することができます。これは、Oracle ADFがOPSSと統合されているためです。

この項では、Oracle ADFを紹介し、Oracle ADFアプリケーションにおけるOPSSセキュリティの例を示します。

13.4.1 Oracle ADFについて

Oracle Application Development Framework(Oracle ADF)は、サービス指向アプリケーションの実装を簡易化し促進するために、Javaプラットフォーム、Java Enterprise Edition(Java EE)標準およびオープンソース・テクノロジの上に構築されたエンドツーエンドのアプリケーション・フレームワークです。Web、ワイヤレス、デスクトップまたはWebサービスのインタフェースを使用してデータの検索、表示、作成、変更および検証を行うエンタープライズ・ソリューションに対して、Oracle ADFはその開発作業を簡易化することができます。

Oracle JDeveloper 11gとOracle ADFを併用すると、ドラッグ&ドロップによるデータ・バインド、視覚的なUI設計およびチーム開発機能が組み込まれた、設計からデプロイまでの開発ライフ・サイクル全体をカバーする環境が得られます。

13.4.2 Oracle ADFによるOPSSの使用方法

Oracle ADFセキュリティ・フレームワークは、認証および認可サービスをFusion Webアプリケーションに提供するための推奨テクノロジです。次のような利点があります。

  • Oracle ADFセキュリティはOracle Platform Security Services(OPSS)アーキテクチャの上に構築されます。このアーキテクチャは、重要なセキュリティ・フレームワークを提供するだけでなく、それ自体もOracle WebLogic Serverと十分に統合されています。

  • Oracle JDeveloperとOracle ADFは、OPSSアプリケーションのライフ・サイクル・リスナー・フレームワークを使用し、アプリケーションのデプロイ時に資格証明データおよびポリシー・データを移行します。

OPSS機能などのセキュリティ機能に対するOracle ADFの組込みサポートにより、Oracle ADFの外部でそれらの機能を実装する際に必要な手間を一部省くことができます。実際、特定の機能は、コンテナ管理セキュリティだけでは使用することができません。

この例では、ファイングレイン認可とJavaEEコンテナベースの認証の両方を使用する必要があるOracle ADFアプリケーションを示します。

図13-8 JpsAuth.checkPermissionを使用するOracle ADF

図13-8については周囲のテキストで説明しています。

主要な機能には、次のものがあります。

  • JDeveloperのセキュリティ・ウィザードを使用した必要なセキュリティ構成の作成。

  • Oracle ADFフィルタによるJpsAuth.checkPermissionへのコール。

  • カスタムのOracle ADFパーミッションを使用して保護されるタスク・フローとリージョン。

詳細は、次の各項を参照してください。

  • Oracle Fusion Middlewareセキュリティ概要』の「ADFセキュリティ」

  • 『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』

13.4.3 Oracle ADFの開発ライフ・サイクル

この例では、統合されたOracle WebLogic Server(Oracle JDeveloperに埋め込まれているOracle WebLogic Server)にアプリケーションを最初にデプロイする方法を示します。開発者はその後、別のOracle WebLogic ServerドメインにOracle Enterprise Manager Fusion Middleware Controlを使用してデプロイされるEARファイルを作成します。

このOracle WebLogic Serverドメインは、多くの場合、テスト領域またはステージング領域にあります。

図13-9 Oracle WebLogic ServerにデプロイされるOracle ADFアプリケーション

図13-9については周囲のテキストで説明しています。

主要な機能には、次のものがあります。

  • Oracle JDeveloperにより開発されるOracle ADFアプリケーション。

  • Oracle ADFセキュリティ・ウィザードとOracle ADF認可ポリシー・エディタの使用。

  • Oracle JDeveloperにより、アーティファクトが実行時環境に移行され、統合されたユーザー・エクスペリエンスが提供される。

    • 設計時に定義されたユーザーおよびグループは、デフォルトの認証プロバイダ内で使用可能である。

    • 認可ポリシーと資格証明データは、OPSSリスナー・フレームワークを使用して移行される。

  • アプリケーション開発者がポリシーおよび資格証明が含まれるEARファイルを作成する。

  • 管理者が、Fusion Middleware ControlまたはWLSTを使用してEARをリモートのOracle WebLogic Serverにデプロイする。


    注意:

    デプロイ・ツールとオプションの詳細は、第6章「セキュア・アプリケーションのデプロイ」を参照してください。

13.5 Oracle Security Developer Toolsの使用

Oracle Security Developer Toolsは、セキュアなメッセージングなどの基本タスクからサービス指向アーキテクチャの安全な実装などの複雑なプロジェクトまで、強力なセキュリティ・アプリケーションの開発に必要な暗号ビルディング・ブロックを提供します。これらのツールは、暗号、公開鍵のインフラストラクチャ、Webサービスのセキュリティおよび連合アイデンティティ管理という中核的な基礎の上に構築されており、Oracle独自のセキュリティ製品の構築に広く使用されています。

これらのツールの詳細は、次のドキュメントを参照してください。

13.6 Oracle JDeveloper/Oracle ADFの外部でのOPSSの使用

Oracle JDeveloperおよびOracle ADF以外の開発IDEを使用する場合は、ユーザー・アプリケーション内でOPSS APIを使用できます。

ただし、その場合、OPSS構成ファイルおよびweb.xmlの中で手動による構成を行う必要があるので、Oracle JDeveloperの使用時に使用可能な自動構成およびセキュリティの移行という利点は得られません。

この詳細は、第14章「OPSSを使用するためのJavaEEアプリケーションの手動構成」を参照してください。