| Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド 11g リリース1(11.1.1) B56235-03 |
|
 前 |
 次 |
この章では、OPSSを使用して開発したアプリケーションにどのような利点があり、Oracle Fusion Middlewareとどのように提携するかについて説明します。内容は次のとおりです。
この項では、Oracle Platform Security Servicesを使用してアプリケーションを保護することの利点を説明します。内容は次のとおりです。
JavaEEソフトウェア開発は、開発、デプロイ、管理のサイクルに基づいて行われます。Oracle Platform Security Servicesのセキュリティの実装は、このサイクルのすべての段階で重要な役割を果たします。
次のリストは、JavaEEの開発サイクルをまとめたもので、セキュア・アプリケーションの開発に固有なタスクに重点を置き、OPSSによって提供されるセキュリティ拡張を強調しています。
開発者は、ビジネス要件に基づき、Webコンポーネント、エンタープライズBean、サーブレットおよびアプリケーション・クライアントを作成します。
開発者が宣言的な手法を取ることができる間は、Oracle ADF(OPSS APIを利用)を使用すると、さらなる価値が得られます。
開発者は、JavaEEの論理ロールを定義し、セキュリティ制約を通じて論理ロールに権限を割り当てます。これらはすべて標準のJavaEEデプロイメント・ディスクリプタの構成によって実行されます。
コンポーネントがアセンブルされ、組み合されてEnterprise Archive (EAR)ファイルが作成されます。
この処理の一部として、アセンブラは環境に適したオプションを指定します。
アセンブラはアプリケーションレベルのセキュリティ制約を定義し、モジュールレベルの構成間の潜在的な競合を解決します。
EARファイルは、Oracle WebLogic Serverにデプロイされます。
デプロイ・プロセスの一部として、デプロイヤがJavaEEのロールをデプロイ・ユーザーおよびロールにマップする場合もあります。
システム管理者は、デプロイされたアプリケーションを維持および管理します。
このタスクには、アプリケーション顧客からの要求に応じてデプロイ環境でロールとユーザーを作成および管理することも含まれます。
Java 2またはJAASの機能を使用して、コードベースまたはサブジェクトベースのファイングレイン・アクセス制御を可能にする場合、従来の手順には次の処理が含まれます。
開発者は、アクセスされる可能性があり、適宜保護する必要のあるすべてのリソースを特定します。
開発者は、これらのリソースを保護するためのパーミッションを定義します。
開発者は、ランタイム認可チェック用のコードを実装します。
システム管理者は、目的のパーミッションを適用するために必要なすべてのポリシーの構成を管理します。ポリシーのプロビジョニングは実行時より前に完了しておく必要があります。
Oracle ADFおよびOPSSでは、次の拡張機能が提供されます。
設計時: アプリケーション・ロールのモデリング、パーミッションとしてのリソースの定義、ロールに対するパーミッションの割当て。アプリケーションの資格証明管理がサポートされています。たとえば、ADF接続では、設計時、資格証明を資格証明ストア・フレームワークに格納できます。
デプロイ時: ポリシーおよび資格証明移行オプションが使用可能です。
デプロイ後、開発者は、エンタープライズ・ユーザーまたはグループに対するアプリケーション・ロールのマッピング(実行時に反映される)などの重要なタスクを実行します。
Java開発者は、セキュア・アプリケーションの開発時、次のような課題に直面します。
ファイングレイン認可、資格証明のマッピング、ロールのマッピング、監査またはシングル・サインオンとの統合のためのAPIがJavaEE標準で定義されていません。
開発者は、セキュリティに関する深い知識を取得する必要があり、アプリケーションのビジネス・ロジックに集中することができません。
セキュリティ・エクスペリエンスがプラットフォーム間で一貫していない。たとえば、カスタムのセキュリティ・ソリューションでは独自のセキュリティ・フレームワークが開発されることが多く、そのようなフレームワークはプラットフォーム間で移植できない場合が多い。
JavaEEアプリケーションを保護するためのカスタム・ソリューションには、大規模なエンタープライズ・セキュリティ・デプロイメントのサポートが欠落している場合が多い。
カスタム・ソリューションには、管理性、可用性、スケーラビリティ、信頼性などの重要な側面が欠落している場合が多い。
Oracle Platform Security Services(OPSS)は移植可能なセキュリティ・サービスの抽象レイヤーで、強力なセキュリティ・フレームワークを提供し、開発の時間と手間を節約できます。OPSSにより、従来のJavaEE開発が様々な面で向上します。
認証、認可、監査、ロール管理、資格証明管理などの基本的なセキュリティ・サービスが提供されます。
開発者がアプリケーション・ロジックに集中できます。
Oracle Fusion Middleware製品と同じサービスが提供されます。
OPSSは、Oracle WebLogic Server、Oracle Entitlement Server、Oracle SOA Suite、Oracle WebCenterなどのOracle Fusion Middlewareコンポーネント用のセキュリティ・プラットフォームです。
標準ベースで、エンタープライズ対応です。
エンタープライズ・デプロイメントをサポートするためのストレステスト済です。
様々なLDAPサーバーおよびシングル・サインオン(SSO)システムにわたって相互運用が可能です。
Oracle WebLogic Serverで認定済です。
すべてのタイプのアプリケーション(社内、サード・パーティ、Oracle Fusion)に対して同じAPIセットが提供されます。
抽象レイヤーの使用により開発時間を最適化できます。
アプリケーション・コードに影響を与えることなくセキュリティ・ルールを変更できるので、アプリケーションの保守が容易になります。
レガシー・セキュリティ・プロバイダとサード・パーティ・セキュリティ・プロバイダの統合が可能です。
アイデンティティ管理(IdM)に対するOPSSのサポートは、次のとおりです。
小規模から中規模のアプリケーションの構築およびデプロイを顧客が実行できる軽量インフラストラクチャ
IDMシステムに対するプラグイン・インタフェース
OPSSに対して構築されたアプリケーションは、一元的にデプロイされるアイデンティティ管理システムにプラグインできます。
顧客は、アプリケーションをスケール変更して、一元的にデプロイされるアイデンティティ管理システムに切り替えることができます。
IdMシステム間で切り替える際、アプリケーション内のコード変更は不要です。
図18-1 は、OPSSアーキテクチャの基本的なコンポーネントを示しています。このマニュアルでこれまでに説明したほとんどの機能には、アプリケーション開発者が使用できる固有のAPIがあります。基礎となるSPI(サービス・プロバイダ・インタフェース)は、大部分がアプリケーション開発者や管理者に見えます。SPIについては、第1.2項「OPSSのアーキテクチャの概要」に簡単な説明があります。
Oracle Platform Securityのアーキテクチャには、次の特徴があります。
アプリケーション・レイヤーを基礎となる実装から切り離した階層型アーキテクチャ。
明示的な拡張点(SPIレイヤー経由)を可能にした拡張可能なフレームワーク。カスタマイズした実装(カスタム・ログイン・モジュールなど)をこの拡張点でフレームワークにプラグインすることで、特殊機能を提供できます。
この項では、Oracle Platform Security Servicesを使用する開発者が使用可能なAPIについて説明します。
OPSSでは、JavaSEアプリケーションがアイデンティティ・ストアにアクセスして管理できるようにする、LoginService認証APIを用意しています。
認証は、サブジェクトにプリンシパルを移入するコンポーネントであるログイン・モジュールによりサポートされます。このプロセスは、2つの異なる段階で行われます。
第一段階では、ユーザーによって提供された資格証明を使用して、ログイン・モジュールがユーザーの認証を試みます。
第2段階では、ログイン・モジュールによって、関連プリンシパルがサブジェクトに割り当てられ、最終的にそれが権限が付与されたアクションを実行するために使用されます。
詳細は、第22章「認証の開発」を参照してください。
ユーザーおよびロールAPIフレームワークを使用すると、アプリケーションは、基礎となるアイデンティティ・リポジトリの種類を問わず、統一的で移植可能な方法でアイデンティティ情報(ユーザーとロール)にアクセスすることができます。これは、基盤となるアイデンティティ・ストアのタイプがコール元に透過的であるためです。
このAPIフレームワークには、移植可能な方法でプログラム的にリポジトリにアクセスするための便利な方法が用意されているため、アプリケーション開発者は、個々のアイデンティティ・ソースに対応した複雑な処理を考慮するという煩雑な作業から解放されます。このフレームワークにより、アプリケーションは異なるリポジトリをシームレスに操作できるようになります。アプリケーションは、コードを変更しなくても、各種のアイデンティティ・リポジトリを切り替えて使用することができます。
サポートされる操作には、ユーザーとロールの作成、更新、削除のほか、ユーザーおよびロールの属性や特定の情報の検索などがあります。たとえば、特定のロールのすべてのユーザーの電子メール・アドレスを検索できます。
このAPIでは、次のものがサポートされています。
Oracle Internet DirectoryなどのLDAPディレクトリ・サーバー
フラット・ファイル
データベースなどその他のカスタム・リポジトリ(そのリポジトリのカスタム・プロバイダを実装することによる)
ユーザーおよびロールAPIを使用すると、次のことを実行できます。
移植可能な方法でプログラム的にリポジトリにアクセスします。
特定のアイデンティティ・ソースに対応した複雑な処理を考慮する必要性を除去します。
各自のアプリケーションから様々なリポジトリを操作できるようにします。
アプリケーションのコードを変更せずに様々なアイデンティティ・リポジトリ間で切替えを行います。
詳細は、第25章「ユーザーおよびロール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には、従来の認可モデルに比べて次のような利点があります。
これは、パーミッションが割り当てられるアプリケーション・ロールを使用する機能を付けてJAASモデルを拡張します。
これは、標準のJAASモデルにはないポリシー管理のサポートを提供します。例は、第19.3.2項「ポリシーの管理」を参照してください。
標準のcheckPermissionではなくJpsAuth.checkPermission OPSS APIを使用すると、デバッグ機能の強化、統合された監査サポートなどの利点も得られます。
OPSSの認可機能の詳細は、第24章「認可の開発」を参照してください。
資格証明ストアはセキュアな中央ストアで、資格証明およびその集合が格納されています。複数のアプリケーションで同一の資格証明ストアを使用することができます。
資格証明ストア・フレームワーク(CSF)APIは、アプリケーションが資格証明ストアにアクセスするためのメカニズムを提供します。
CSF APIは、ファイルベース(Oracleウォレット)およびLDAPベースの資格証明ストアをサポートします。
CSF APIによって提供される重要な機能には、特定のマップ名の資格証明を返す、特定のマップ名に資格証明を割り当てる、特定のマップ名から資格証明を削除する、資格証明のマップおよびキーに関連したその他の操作などがあります。
CredentialStoreに対する操作は、CSFで使用されるファイングレイン・アクセス制御モデルを実装するCredentialAccessPermissionによって保護されます。
このAPIの詳細は、第23章「資格証明ストア・フレームワークを使用した開発」を参照してください。
同じOPSS APIのセットを、JavaEE開発者とJavaSE開発者の両方が使用できます。この項では、OPSS APIで一般的なアプリケーションを示し、JavaEEの実装とJavaSEの実装の相違点を説明します。
図18-2は、OPSSセキュリティAPIを使用した標準のJavaEEアプリケーションを示しています。
主要な機能には、次のものがあります。
Oracle WebLogic Serverとの統合。
LDAPディレクトリまたはファイルベースの資格証明ストア内で資格証明を保護する資格証明ストア・フレームワークAPI。ここには、様々なタイプの資格証明(外部データベースの資格証明、外部Webサービスの資格証明など)が格納されます。
アイデンティティ・ストアに格納されている属性を問い合せるユーザーおよびロールAPI。
認可用のJpsAuth.checkPermission 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によって保護されます。
図18-3は、トークンまたはユーザー資格証明を使用してアイデンティティをアサートする必要があるJavaEEアプリケーションを示しています。
主要な機能には、次のものがあります。
Authenticate APIを使用したプログラム的認証のためのアプリケーションにより提供されるユーザー名とパスワード。
WebLogic認証プロバイダの使用。
トークンを使用したアイデンティティ・アサーション(パスワードを使用しない認証)。
コード・ソース・パーミッションによって保護されるアサーション。コード・ソース・パーミッション(コードベースのパーミッション付与oracle.security.jps.JpsPermission、名前IdentityAssertion、アクションexecute)が付与されているアプリケーションだけがこのAPIをアイデンティティ・アサーションに使用できます。
図18-4は、移植可能なファイングレイン認可を使用したJavaEEアプリケーションを示しています。
主要な機能には、次のものがあります。
JpsAuth.checkPermission APIコールによる認可。
認可の決定に関する監査。
図18-5は、データベースなどの外部システムの資格証明にアクセスし、これを格納する必要があるアプリケーションを示しています。
主要な機能には、次のものがあります。
資格証明ストアにセキュアに格納されている資格証明。
Oracle Fusion Middlewareの追加設定なしですぐに使用できるOracleウォレットと呼ばれるファイルベースの資格証明ストアのほか、LDAPベースの資格証明ストアのサポート。
Oracle Enterprise Manager Fusion Middleware ControlまたはWLSTスクリプトで管理できる資格証明。
監査できる資格証明ストアの操作。
図18-6は、APAC内のすべてのユーザーを検索するなど、資格証明ストアを検索してユーザーを見つけたり、あるロールの付与されたユーザーの電子メールをすべて特定することが必要な(WebLogicにデプロイされている)アプリケーションを示しています。
主要な機能には、次のものがあります。
ユーザーおよびロールAPIをコールしてユーザー属性にアクセスします。
同一のAPIが、デフォルトの認証プロバイダまたは外部LDAPストアのユーザー属性で機能します。
ユーザーおよびロールAPIは、認証プロバイダ内の構成(デフォルトまたはその他任意のLDAPベースの認証)に基づいて自動的に構成されます。
属性の格納先とは無関係に同じAPI。
図18-7は、様々なOPSS APIを使用するJavaSE Swingアプリケーションを示しています。
|
注意: LDAPベースのストアでは、図のように、ポリシーと資格証明の両方が同一のストアに保持されますが、ファイルベースのストアではそれぞれ別々のファイルに保持されます。 |
主要な機能には、次のものがあります。
認証用のLoginService API。
認可用のJpsAuth.CheckPermission。
LDAPまたはその他のバックエンドに格納されている属性を問い合せるユーザーおよびロールAPI。
資格証明ストアによる資格証明の保護。
|
重要: OPSSポリシー・プロバイダは、次の例に示すように、J2SEアプリケーションに明示的に設定する必要があります。java.security.Policy.setPolicy(new oracle.security.jps.internal.policystore.JavaProvider()) J2SEアプリケーションにポリシー・プロバイダを明示的に設定しておかないと、ランタイム・メソッド( |
Oracle ADFを使用してアプリケーションの開発およびデプロイを行う際は、OPSSのセキュリティ機能を直接使用することができます。これは、Oracle ADFがOPSSと統合されているためです。
この項では、Oracle ADFを紹介し、Oracle ADFアプリケーションにおけるOPSSセキュリティの例を示します。
Oracle Application Development Framework (Oracle ADF)は、サービス指向アプリケーションの実装を簡易化し促進するために、Javaプラットフォーム、Java Enterprise Edition (Java EE)標準およびオープンソース・テクノロジの上に構築されたエンドツーエンドのアプリケーション・フレームワークです。Web、ワイヤレス、デスクトップまたはWebサービスのインタフェースを使用してデータの検索、表示、作成、変更および検証を行うエンタープライズ・ソリューションに対して、Oracle ADFはその開発作業を簡易化することができます。
Oracle JDeveloper 11gとOracle ADFを併用すると、ドラッグ&ドロップによるデータ・バインド、視覚的なUI設計およびチーム開発機能が組み込まれた、設計からデプロイまでの開発ライフ・サイクル全体をカバーする環境が得られます。
Oracle ADFセキュリティ・フレームワークは、認証および認可サービスをFusion Webアプリケーションに提供するための推奨テクノロジです。次のような利点があります。
Oracle ADFセキュリティはOracle Platform Security Services (OPSS)アーキテクチャの上に構築されます。このアーキテクチャは、重要なセキュリティ・フレームワークを提供するだけでなく、それ自体もOracle WebLogic Serverと十分に統合されています。
Oracle JDeveloperとOracle ADFは、OPSSアプリケーションのライフ・サイクル・リスナー・フレームワークを使用し、アプリケーションのデプロイ時に資格証明データおよびポリシー・データを移行します。
OPSS機能などのセキュリティ機能に対するOracle ADFの組込みサポートにより、Oracle ADFの外部でそれらの機能を実装する際に必要な手間を一部省くことができます。実際、特定の機能は、コンテナ管理セキュリティだけでは使用することができません。
図18-8は、ファイングレイン認可とJavaEEコンテナベースの認証の両方を使用するOracle ADFアプリケーションを示しています。
主要な機能には、次のものがあります。
JDeveloperのセキュリティ・ウィザードを使用した必要なセキュリティ構成の作成。
Oracle ADFフィルタによるJpsAuth.checkPermissionへのコール。
カスタムのOracle ADFパーミッションを使用して保護されるタスク・フローとリージョン。
詳細は、次を参照してください。
『Oracle Fusion Middlewareセキュリティ概要』のADFセキュリティに関する項
『Oracle Fusion Middleware Oracle Application Development FrameworkのためのFusion開発者ガイド』
図18-9は、統合されたOracle WebLogic Server(Oracle JDeveloperに埋め込まれているOracle WebLogic Server)にアプリケーションを最初にデプロイする方法を示しています。開発者はその後、別のOracle WebLogic ServerドメインにOracle Enterprise Manager Fusion Middleware Controlを使用してデプロイされるEARファイルを作成します。権限の重複している付与に関しては、「ポリシー管理」の「注意」を参照してください。
このOracle WebLogic Serverドメインは、多くの場合、テスト領域またはステージング領域にあります。
主要な機能には、次のものがあります。
Oracle JDeveloperにより開発されるOracle ADFアプリケーション。
Oracle ADFセキュリティ・ウィザードとOracle ADF認可ポリシー・エディタ。
Oracle JDeveloperにより、アーティファクトが実行時環境に移行され、統合されたユーザー・エクスペリエンスが提供されます。
設計時に定義されたユーザーおよびグループは、デフォルトの認証プロバイダ内で使用可能です。
認可ポリシーと資格証明データは、OPSSリスナー・フレームワークを使用して移行されます。
アプリケーション開発者がポリシーおよび資格証明が含まれるEARファイルを作成します。
管理者が、Fusion Middleware ControlまたはWLSTスクリプトを使用してEARをリモートのOracle WebLogic Serverにデプロイします。
Oracle Security Developer Toolsは、セキュアなメッセージングなどの基本タスクからサービス指向アーキテクチャの安全な実装などの複雑なプロジェクトまで、強力なセキュリティ・アプリケーションの開発に必要な暗号ビルディング・ブロックを提供します。これらのツールは、暗号、公開鍵のインフラストラクチャ、Webサービスのセキュリティおよび連合アイデンティティ管理という中核的な基礎の上に構築されており、Oracle独自のセキュリティ製品の構築に広く使用されています。
これらのツールの詳細は、次のドキュメントを参照してください。
『Oracle Fusion Middlewareセキュリティ概要』のOracle Security Developer Toolkitに関する項
『Oracle Fusion Middleware Oracle Security Developer Toolsリファレンス』
Oracle JDeveloperおよびOracle ADF以外の開発IDEを使用する場合は、ユーザー・アプリケーション内でOPSS APIを使用できます。
ただし、その場合、OPSS構成ファイルおよびweb.xmlの中で手動による構成を行う必要があるので、Oracle JDeveloperの使用時に使用可能な自動構成およびセキュリティの移行という利点は得られません。
この詳細は、第21章「OPSSを使用するためのJavaEEアプリケーションの手動構成」を参照してください。
