| Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド 11g リリース1(11.1.1) B56235-03 |
|
 前 |
 次 |
この章は、アプリケーション開発者向けにJavaEEアプリケーションとOPSSのセキュリティ・コンポーネントとの統合に関する初期資料として使用できます。必要なコンポーネントの統合時に従う必要があるガイドラインを説明しています。さらに、高度なオプションのセキュリティ機能の統合に必要なガイドラインの概要も紹介しています。
この章は、ID管理テクノロジに関する包括的なガイドではありません。開発者がセキュリティ統合タスクに関する知識を得るための開始ポイントとして機能します。
ここでは、次の項目について説明します。
この章は、開発者および設計者向けにアプリケーション・セキュリティをOPSSと統合する際に必要なタスクに関する知識を提供することを目標として作成されています。
OPSSでは、アプリケーション・プログラミング・インタフェース(API)として抽象レイヤーを提供しています。これにより、開発者は、セキュリティおよびアイデンティティ管理の実装の詳細に関与する必要がなくなります。アプリケーションのセキュリティをOPSSと統合することにより、アプリケーションでセキュリティ、ID管理および監査サービスを企業全体で統一的に実装することが可能になります。
使用可能なすべてのAPIのリストおよびリンクについては、付録H「リファレンス」を参照してください。
ここでは、この章で使用されるほぼすべての頭字語の定義を紹介します。一部はこのガイドの別の場所で紹介されていますが、完全性を期すためにここでも収録されています。
Identity and Access Management (IAM)
IAMは、ユーザーIDおよびそのリソースへのアクセスを管理するツール、プロセス、およびベスト・プラクティスのセットです。
Oracle Application Development Framework (ADF)
ADFは、包括的なJ2EE開発フレームワークで、Oracle JDeveloper開発環境と統合されています。ADFは、フレームワークの一部としてアプリケーション・インフラストラクチャを提供することによって、J2EE開発を大幅に簡素化しコード作成の必要を最小限にします。
また、Oracle Fusion Middlewareセキュリティとも統合されており、ADFを利用すると開発者は宣言による方法を使用してセキュリティ概念を実装できます。
Oracle Access Manager (OAM)
OAMには、Webシングル・サインオン、ユーザー・セルフサービス、セルフ登録をはじめ、広範なWebアクセス管理機能が用意されています。
Oracle Adaptive Access Manager (OAAM)
OAAMは、強力な複数要素の認証およびリアルタイムの不正防止によってWebリソースに対するアクセスを保護します。
Oracle Authorization Policy Manager (OAPM)
OAPMは、セキュリティ・アプリケーション・アーティファクトのプロビジョニングおよび管理を実行するためのグラフィカル・インタフェース・ツールです。
Oracle Enterprise Manager (OID)
OIDは、ID、ポリシー、およびビジネス関連データの記憶域にLDAPベースのディレクトリを提供します。
Oracle Enterprise Manager (OEM)
OEMは、Oracleアプリケーションの管理のための中核的なツールです。
Oracle Identity Manager (OIM)
OIMは、ユーザーのプロビジョニングおよび管理のツールで、エンタープライズ・アプリケーションからのユーザー・アカウントの追加、更新および削除を容易にします。
Oracle Security Developer Tools (OSDT)
OSDTは、セキュア・アプリケーションの開発に必要な暗号ビルディング・ブロックを提供します。セキュア・メッセージおよびセキュア・サービス指向アーキテクチャの実装が含まれます。
OPSSサブジェクト
OPSSサブジェクトとは、プリンシパルのコレクションで、多くの場合ユーザーの資格証明(パスワード、暗号キーなど)も含まれます。Oracle WebLogicサーバー認証によってOPSSサブジェクトにプリンシパル、つまりユーザーとグループ、およびアプリケーション・ロールが移入されます。
Oracle Web Services Manager (OWSM)
OWSMは、SOAPベース・アプリケーション、つまりサービス指向アーキテクチャのセキュリティ保護、管理、デプロイのためのツールです。
Oracleウォレット(OW)
OWは、証明書、信頼できる証明書、証明書リクエスト、秘密鍵などの資格証明を格納します。
Webサービス・セキュリティ(WSS)
WSSは、SOAPベース・アプリケーション間の認証、認可、機密保護、プライバシ保護、および整合性の機能を提供します。
Webシングル・サインオン(Web-SSO)
Web-SSOを使用すると、1回認証を受けるだけで複数のWebアプリケーションへのアクセスが可能になります。
Oracle IAMスイート製品は、オペレーティング・システム、Webサーバー、アプリケーション・サーバー、データベース管理システムなどについて異種の複数ベンダーの開発および実行時環境のサポートを目的に設計されています。
次に、スイートに含まれる製品とそれぞれのアプリケーション・セキュリティにおける主要サポート領域について説明します。
OPSSとのセキュリティ統合時に必要なOPSSのセキュリティ機能の詳細は、「必要なセキュリティ機能」を参照してください。
OIDは、アプリケーションにおけるユーザーID、IDプロファイル、ロール、ポリシー、および資格証明の格納に使用されます。
ユーザーからアプリケーションにアクセスできる環境では、ユーザーIDを適切かつ安全に確認することが重要です。ユーザーIDが確認された後は、そのユーザーが他のエンタープライズ・アプリケーションにプロンプトなしでサインオンできなければなりません。
OAMは、ユーザー認証サービスとWeb SSOサービスを提供し、シングル・サインオンの実装の詳細をアプリケーションで認識できないようにします。OAMとOSSOの2つのシングル・サインオン・ソリューションが用意されています。
詳細は、第IV部「シングル・サインオンの構成」を参照してください。
ユーザー管理は継続的なアクティビティですが、通常は中央リポジトリに保存されるユーザー情報の一部を外部化する必要があります。OIMによって公開されるSPMLは、ユーザーおよびロールのプロビジョニング、ユーザー・プロファイルとロール・プロファイルの管理、ユーザー・パスワードの変更に使用されるインタフェースです。
アプリケーションでは、ユーザーおよびロールに関する書込みおよび更新操作のすべてにSPMLインタフェースを使用するように推奨されます。
OPSSでは、ユーザーおよびロールのAPIが公開されます。これは、標準のプライバシ対応インタフェースで、基礎となるデータ・リポジトリへの接続を明示的に開かずにIDおよびロール・データを読み取ります。
詳細は、第25章「ユーザーおよびロールAPIを使用した開発」を参照してください。
OPSSには、スケーラブルで拡張可能なロールベースの認可フレームワークがあります。アプリケーションではこれを使用して資格、ロール、権限などのセキュリティ・アーティファクトの指定および制御を実現できます。実行時に認可エンジンによって施行されるセキュリティ・ポリシー(ポリシー・ストアに格納)をアプリケーションで定義します。
詳細は、第24章「認可の開発」を参照してください。
OAPMは、アプリケーションのデプロイ後のセキュリティ・アーティファクトの管理に使用されます。OAPMをOPSSと連携させることによって、資格およびロールの管理、エンタープライズ・グループへのロールのマッピングなど、多数の管理タスクが容易になります。
OPSSでは、他にもアプリケーションの資格証明を格納する資格証明ストア・フレームワーク、メッセージの機密性保持のための暗号ツールキット、キー管理のツールキット、セキュリティ監査用の監査フレームワークなどのセキュリティ・サービスも提供されます。
開発者ツールAPIすべてのリストは、付録H「リファレンス」を参照してください。
この項では、アプリケーションのセキュリティ・ライフ・サイクルの各フェーズを紹介します。ここではアプリケーションがADFを使用し、Oracle JDeveloper環境を使用していることを前提として説明します。
アプリケーションのセキュリティ・ライフ・サイクルのフェーズとは、開発フェーズ、デプロイメント・フェーズ、および管理フェーズです。関係する担当者は製品マネージャ、アプリケーション設計者、アプリケーション開発者、およびアプリケーション・セキュリティ管理者です。タスクの概要については、「各フェーズの担当者別タスクの概要」を参照してください。
開発フェーズでは、開発者によってOracle Fusion Middlewareで使用可能な広範なセキュリティ・オプション機能がアプリケーションと連携するように設計されます。開発者はOracle JDeveloper、組込みのADFフレームワーク、およびOracle WebLogicサーバーで公開される豊富なセキュリティ・サービスを利用できます。これらのコンポーネントはすべてOPSSを基盤としています。OPSSによってアプリケーションの使用期間全体にわたってセキュリティ・アプローチの整合性が保持されることが保証されます。
通常、開発者はADFセキュリティ・ウィザード、認可エディタ、式言語エディタを使用します。これらはすべてOracle JDeveloperにあります。さらに、OPSS APIを使用してより複雑なセキュリティ・タスクも実現します。これによってアプリケーションの一部で宣言によるセキュリティを使用し、別の部分でプログラムによるセキュリティを使用でき、また、いずれの場合も開発および実行時環境で使用可能なセキュリティ機能を利用できます。
アプリケーション開発者も、アプリケーションのセキュリティ要件に応じてポリシー・シード・データ(アプリケーションの権限およびロール)を定義します。これらはアプリケーションのソース・コードとともにソース・コントロール・システムに格納されます。
通常、完成後のアプリケーションは本番環境にデプロイする前にステージング環境でテストされます。本番環境では、アプリケーションと実行時サービスの両方が他のセキュリティ・コンポーネントと統合されます。このコンポーネントは、ユーザー・ディレクトリ、シングル・サインオン・システム、ユーザー・プロビジョニング・システム、監査機能などです。一般にセキュリティ・サービスはフェーズとともに変化します。たとえば、開発時は開発者がファイルまたはOracleウォレットを利用してユーザーの資格証明を格納しますが、本番環境では資格証明がLDAPディレクトリに格納されます。
通常デプロイメント・フェーズでは、管理者がポリシー・シード・データを本番ポリシー・ストアに移行し、アプリケーション・ロールをエンタープライズ・グループにマッピングして、アプリケーション・セキュリティ・ポリシー施行します。
管理フェーズは、アプリケーションが本番環境にデプロイされたときに開始します。このフェーズではアプリケーション管理者またはエンタープライズ・セキュリティ管理者が日常的なセキュリティ・タスクを管理します。このタスクにはアプリケーション・リソースへのユーザー・アクセス権限の付与、監査ログの確認、セキュリティ・インシデントへの対応、セキュリティ・パッチの適用などが含まれます。
次の表はセキュリティ・ライフ・サイクルのフェーズごとに、担当者別に主要な担当任務をまとめたものです。
表20-1 アプリケーション設計者のセキュリティ・タスク
| フェーズ | タスク |
|---|---|
|
開発 |
機能のセキュリティ要件およびデータのセキュリティ要件に基づいて高度なアプリケーション・ロールを定義します。 初期のファイルベースのアプリケーション・ポリシー・ストアを移入します( |
|
デプロイメント |
QAチームのテストに使用する実際のカスタマ・シナリオを定義します。 |
|
管理 |
アプリケーション・ポリシーのカスタマイズ要件を理解し、特定します。 垂直産業向けのテンプレートの定義を検討します。 |
表20-2 アプリケーション開発者のセキュリティ・タスク
| フェーズ | タスク |
|---|---|
|
開発 |
特にOracle JDeveloperのツールおよびプロセスを使用して、アプリケーションを構築し、アプリケーション・ロールやパーミッションなどのセキュリティ・アーティファクトを作成します。 FND権限を使用して、データレベルのセキュリティを指定します。 ローカル・ポリシー・ストア使用し、サンプルのユーザーとロールでアプリケーションをテストします。 |
|
デプロイメント |
QAチームによる実行時の問題のトラブルシューティングおよび解決を支援します。 |
表20-3 アプリケーション・セキュリティ管理者のセキュリティ・タスク
| フェーズ | タスク |
|---|---|
|
デプロイメント |
デプロイメント・サービスを使用して、 アプリケーション・ロールをエンタープライズ・グループにマッピングして、セキュリティ・ポリシーの適用を可能にします。 |
|
管理 |
必要に応じてソフトウェアにパッチおよびアップグレードを適用します。 企業のユーザーおよびアプリケーション・ロールの階層は時間とともに変化するため、それに応じてユーザーとロールを管理します。 アプリケーションにパッケージ化されたポリシーを管理し、新たなポリシーを作成します。 IAMインフラストラクチャとの統合および管理を行います。 |
アプリケーション・セキュリティによって、アプリケーション・リソースへのユーザーのアクセスが定義され適用されます。リソースへのアクセスは、そのリソースに付随するリスクのレベルによって異なります。このため開発者は堅牢なセキュリティおよびIDモデルを設計および実装することによって、アプリケーション・リソースを無認可の使用から保護する必要があります。
Oracle Fusion Middlewareでは、このモデルの定義および実装のためのツールおよび手順が多数用意されています。宣言とプログラムの両アプローチの使用が可能な事前統合フレームワークを使用するため、アプリケーション開発者にはセキュリティの下位レベルの詳細が不可視になります。
OPSSには、標準のアプリケーション・プログラミングAPIの形式で抽象レイヤーがあり、開発者はセキュリティの実装詳細に関与する必要がなくなります。たとえば、OPSSを使用すると、開発者は暗号キー管理や、ユーザー・リポジトリおよびID管理インフラストラクチャとのインタフェースなどの詳細レベルに関与する必要がなくなります。
アプリケーション開発者はOracle JDeveloperのADF宣言セキュリティを使用してOPSSとの統合を行います。これにより開発フェーズではOracle JDeveloperから直接、ウィザードを使用してOPSSサービスを呼び出すことができます。その後のデプロイメント・フェーズではシステム管理者およびセキュリティ管理者がOEMまたはコマンドライン・ツールを使用してOPSSサービスを構成できます。
OPSSにはOSDTも組み込まれています。これは、XML署名、XML暗号化、XML Key Management Specification (XKMS)、SAML、WSセキュリティ、およびSecure/Multipurpose Internet Mail Extensions (S/MIME)、オンライン証明書ステータス・プロトコル(OCSP)などの、その他の非XML標準をサポートするJavaベースの暗号ライブラリのセットです。
サンプルのJ2EEアプリケーションとして、ezshareアプリケーションがあります。このアプリケーションのセキュリティはOPSSと統合され、パーミッションベースの権限を使用します。このアプリケーションはページhttp://www.oracle.com/technology/products/id_mgmt/opss/index.htmlで、Resources領域のSample Applicationをクリックすると入手できます。
ここでは、OPSSと統合するアプリケーションで実装が要求される機能について説明します。これらの機能は次のとおりです。
外部システムを資格証明ストアとして使用するアプリケーションの場合は、資格証明ストア・フレームワーク(CSF)を使用して外部システムに格納されるパスワードを保護する必要があります。これ以外の場合は、ストア内のデータへのアクセスおよびデータ管理に資格証明ストアおよびCSFにLDAPベースOIDストアを使用します。
いずれの場合も、資格証明のアクセスおよび管理には、アプリケーションでCSFを使用する必要があります。詳細は、「資格証明ストアの統合」を参照してください。
CSFの詳細は、第23.2項「CSFを使用したアプリケーション開発の概要」を参照してください。
OPSSと認証を統合するアプリケーションは、次のモデルのいずれかを使用する必要があります。
コンテナ認証(web.xml)によるサーブレットの保護
コンテナ認証(ejb-jar.xml)によるEJBの保護
プログラムによる認証の使用
J2SEとJ2EEの両コンポーネントで同じコードや認証構成を共有する場合は、これらのモデルを組み合せることを検討してください。
いずれのモデルについても、コンポーネント(サーブレット、EJB、Web)はOID IDストアを使用する必要があります。統合の詳細は、「認証の統合」を参照してください。
認証の詳細は、第22章「認証の開発」も参照してください。
OPSSと認可を統合するアプリケーションは、次のモデルのいずれかを使用する必要があります。
OID LDAPベース・ポリシー・ストアに対するポリシーベースの認可
サーブレット、EJB、およびWebコンポーネントを保護するコンテナベースの認可
統合の詳細は、「認可の統合」を参照してください。
プログラムによる認可の詳細は、第22章「認証の開発」も参照してください。
OPSSと統合するアプリケーションは、プログラムによるユーザーおよび外部ロールの管理にユーザーおよびロールAPIを使用する必要があります。このAPIによりIDサービスの使用が容易になり、ユーザー・アカウントの場所やロールの物理的実装のそれぞれなどの下位レベルの詳細を開発者が認識しておく必要をなくします。
ユーザーおよびロールAPIでサポートされる操作は次のとおりです。
ユーザー・プロファイルの属性の作成、更新、削除、変更、取得、およびパスワードの変更
ロールの属性の作成、更新、削除、変更および取得
ユーザーおよびロールAPIの詳細は、第25章「ユーザーおよびロールAPIを使用した開発」を参照してください。
ここでは、次の項目に関する重要ポイントについて説明します。
開発フェーズでユーザー認証を有効化するには、開発者がADFセキュリティ・ウィザードを実行して必要なOPSS構成を生成して、アプリケーション・デプロイメント・ディスクリプタweb.xmlで認証方式を指定します。
実行時は、Basic認証、フォームベース認証、クライアント証明書のいずれかの方法でコンテナによってアプリケーションのエンド・ユーザーの認証を行います。ほとんどの場合はフォームベース認証の選択が適しています。コンテナが認証データ(ユーザー名とパスワードなど)をユーザーから取得し、取得されたデータがOracle WebLogicサーバーによって処理され、ユーザー・セッションが確立されます。さらに保護されたリソースへのアクセスが求められた場合は、OPSSからOracle WebLogicサーバーに対して認証されたサブジェクトを問い合せます。
OPSSは、Oracle WebLogic Serverから提供される認証プロバイダを使用します。このプロバイダがユーザーの資格証明の検証を行うか、システムがユーザー名とパスワードの組合せまたはデジタル証明書に基づいて処理を行います。また、プロバイダは必要に応じてドメイン内の他のコンポーネントがユーザーID情報を利用できるようにします(サブジェクト経由)。
使用可能な認証プロバイダには、デフォルトの認証プロバイダ、外部LDAPストアなどがあります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』の認証プロバイダに関する項を参照してください。
OPSSではコンテナ管理の認証に加えて、アプリケーションによるユーザーの資格証明の認証、およびプリンシパルの確立を可能にするAPIであるLoginServiceを介したプログラムによる認証を使用できます。プリンシパルが確立されると、LoginService APIは、認証されたユーザー、認証されたロールおよびユーザーが属するアプリケーション・ロールに対応するプリンシパルでサブジェクトを作成します。このサブジェクトは、権限が付与されたアクションの実行に使用されます。さらにOPSSはIDおよびトークン・アサーションにもAPIを提供します。
通常、J2SEアプリケーションにはプログラムによる認証が必要ですが、J2EEアプリケーションはこの必要がありません。
アプリケーションをSSO環境に追加できるようにするには、SSOソリューション専用として構築されたIDアサーション・プロバイダを使用する必要があります。推奨ソリューションのOAM/OSSOには、Oracle WebLogic Serverと連携するように設計された専用のIDアサーション・プロバイダが用意されています。
OAM/OSSOソリューションを使用したSSOの管理の詳細は、第IV部「シングル・サインオンの構成」を参照してください。
認可では、ポリシーを適用することによってアプリケーション・リソースへのアクセスが保護されます。このポリシーによってユーザーがアクセスできるアクションのタイプ、タスク、サービスが決定されます。
OPSSは、次の認可モデルでJ2EEおよびADFアプリケーションに対する機能セキュリティを提供します。
これらのモデルのいずれにも、ユーザーが属するロールに従ってアプリケーションで実行可能な各タスク、J2EEで呼出し可能なメソッドなどのアプリケーション・アーティファクトへのアクセスを制御するファイングレイン認可機能が用意されています。
機能セキュリティの定義は、開発フェーズの初期段階に開始されます。製品マネージャがソース・コード・リポジトリに保管されるセキュリティ機能データ、およびアプリケーションの権限、ロール、ロール階層、ロール・カテゴリの定義を含むセキュリティ機能データを作成します。
開発者は機能セキュリティを使用する際にユーザーおよびロールに関与する必要はありません。アプリケーション・パーミッション(通常はそれぞれの製品マネージャが定義)と開発したアプリケーション・アーティファクトの関連付けに集中します。
機能セキュリティによって、ユーザーおよびエンタープライズ・ロールの外部化がサポートされ、エンタープライズ管理者はOIMを使用してこれらを管理できます。
機能セキュリティ・モデルはリソース・カタログを使用する権限を基盤とします。表20-4はこのカタログのエンティティを説明しています。
表20-4 リソース・カタログ・エンティティ
| エンティティ | 説明 | コメントおよび例 |
|---|---|---|
|
リソース・タイプ |
Javaパーミッション・クラスによって定義されるタイプで、そのタイプのインスタンスで許可されるアクションのセットが組み込まれています。 |
例: Webサービス、ADF タスクフロー、およびスケジュールされたジョブ(ESS) |
|
リソース |
リソース・タイプのインスタンス、およびリソース・タイプ別に許可されるアクションのサブセット。 |
例: 更新権限付きの発注書タスクフロー(発注書タスクフローは、ADFタスクフロー・リソース・タイプのインスタンス)。 |
|
権限(またはパーミッション・セット) |
許可されるリソースおよびアクションのセット。 |
機能ポリシーは、OPSSのコンポーネント、Oracle Authorization Policy Managerを使用して管理できます。詳細は、『Oracle Fusion Middleware Authorization Policy Manager管理者ガイド』を参照してください。
状況によっては、開発者がプログラムによってパーミッションをチェックすることが必要な場合があります。このチェックはメソッドcheckPermissionを呼び出して実行されます。checkPermisionおよびその他のメソッドを使用したポリシーのチェックの詳細は、第19.3.3.1項「メソッドcheckPermissionの使用方法」を参照してください。
通常は開発者がOracleJDeveloperのADFで提供される宣言セキュリティ・モデルを使用してアプリケーション機能セキュリティを実装します。このモデルはセキュリティ詳細のほとんどをアプリケーション固有ロジックから認識できないようにして分離するため、セキュリティ統合を大幅に簡略化します。
ADFでは、機能セキュリティ・ポリシーによってADFタスクフロー、ページ、リージョンなどの保護対象アーティファクトにパーミッションが割り当てられます。ADFには使用可能なパーミッションをリストするユーザー・インタフェースがあり、このタスクを容易にします。
ADFを使用して機能セキュリティ権限をアプリケーションに追加する手順は次のとおりです。
jazn-data.xml、adf-config.xml、weblogic.xml、jps-config.xml、cwallet.sso、およびweb.xmlをチェック・アウトします。これらのファイルはすべて書込み可能である必要があります。
ADFセキュリティ・ウィザードを実行します。
すべてのリージョンおよびタスク・フローに対する匿名アクセスを有効化します。
このタスクによって匿名ユーザーをメンバーとするロールTEST-ALLが作成されます。すべてのリージョンおよびタスク・フローへのパーミッションがロールTEST-ALLに権限付与されます。これによって非認証ユーザーもアプリケーションのADFアーティファクトにアクセスできること、およびタスク・フローおよびリージョンのセキュリティの定義前であってもアプリケーションが機能することが保証されます。
権限ロールにパーミッションを付与します。
ADFセキュリティ・ウィザードを実行すると、ステップ1に記載されたファイルが作成または更新されます。開発者は権限ポリシー・エディタを使用してタスク・フローおよびリージョンに権限ロールのパーミッションを付与します。
この時点で必要なロールが利用できない場合、開発者は、ファイルjazn-data.xmlで権限ロールを作成することを、製品マネージャにリクエストします。その後、開発者はそのファイルをチェック・アウトしなおして、新しいロールを利用可能にします。
|
注意: 開発者は、ソース・コントロールに格納されているセキュリティ・データを絶対に変更しないでください。この推奨事項には、権限、アプリケーション・ロール、アプリケーション・ロール階層、エンタープライズ・テスト・ロール、およびテスト・ユーザーを変更しないことも含まれます。 |
ADFアプリケーションにおけるセキュリティ開発の詳細については、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の第29章を参照してください。
開発者はしばしばアプリケーションの操作やアプリケーションから外部サービスへのアクセスに必要な機密データに関与する場合があります。OPSSに含まれる資格証明ストアはこのようなデータのリポジトリです。また、CSF APIによって、このデータに対するアプリケーションからのアクセスおよび操作が実行可能になります。
開発者は、アプリケーションにユーザー名とパスワードをクリア・テキストで組み込まないでください。このデータは資格証明ストアに格納し、必要に応じてCSF APIを使用してプログラムを介してアプリケーションから資格証明にアクセスします。
管理者は、Fusion Middleware ControlまたはOPSSスクリプトを使用して資格証明を管理します。
論理的に言うと、資格証明はマップまたはコンテナにグループ化され資格証明コレクションを構成します。マップ内の資格証明はキーによって一意に識別されます。このため、資格証明はマップとキーのペアによって一意に特定されます。複数のアプリケーションが同一ドメインにデプロイされ同じ資格証明ストアを使用する場合は、マップ名をアプリケーション名と同じにして名前の衝突を回避することをお薦めします。
CSF は、J2EE、J2SEおよびCのアプリケーションで使用できます。
資格証明ストアの詳細は、第23章「資格証明ストア・フレームワークを使用した開発」を参照してください。
CSFを使用する場合、開発者は次のガイドラインに従う必要があります。
CSF APIについて理解します。
CSFは、使用に適したマップおよびキー名を特定することによって実装されます。複数のアプリケーションが資格証明ストアを共有する環境ではこのことが特に重要になります。詳細は、第23.6項「APIの使用手順」を参照してください。
資格証明へのアクセスを許可するポリシーをプロビジョニングします。これらのポリシーは、ポリシー・ストアに格納されます。これはファイルベース(system-jazn-data.xml)でも、LDAPベースでもかまいません。
次の重要なガイドラインに留意してください。
資格証明へのアクセスが必要なアプリケーション・コードはできるかぎり小さいjarにパッケージ化する必要があります。
このjarには、特定のマップおよびキー名および特定のアクション・セットに対するCredentialAccessPermissionの権限を付与する必要があります。詳細は、第23.3項「Javaセキュリティ・ポリシーのパーミッションの設定」を参照してください。
権限はアプリケーションのjazn-data.xmlファイルで指定する必要があります。このファイルはアプリケーションとともにパッケージ化され、アプリケーションのデプロイ時にポリシー・ストアに移行されます。
クラスタ環境では、資格証明ストア・フレームワークAPI上で資格証明ストアMbean APIを使用して、アプリケーションの資格証明の作成、取得、更新および削除を行います。ただし、単にいずれかの資格証明を読み取るだけの場合は、いずれかのAPIを使用します。詳細は、第E.2項「MBeanを使用したOPSSサービスの構成」を参照してください。
Oracle Security Developer Toolsは、セキュアなメッセージングなどの基本タスクからサービス指向アーキテクチャの安全な実装などの複雑なタスクまでの開発に必要な暗号ビルディング・ブロックを提供します。これらのツールは、暗号、公開鍵のインフラストラクチャ、Webサービスのセキュリティおよび連合アイデンティティ管理という中核的な基礎の上に構築されており、次の特長を備えています。
認証。情報の受信者に、その情報が信頼できるソースからのものであることを保証します。一般に認証はメッセージ認証コード(MAC)、デジタル署名、またはデジタル証明書を使用することで実現されます。
機密性。対象とする受信者のみにメッセージの読取りが可能になることを保証します。一般に機密性は暗号によって実現されます。
整合性。受信されたメッセージが改ざんされていないことを保証します。一般に整合性は暗号ハッシュ機能によって実現されます。
否認防止。特定の送信者が実際に特定のメッセージを送信したことを証明します。一般に否認防止はデジタル署名の使用によって実現されます。
Oracle Security Developer Toolsの詳細は、第H.1項「OPSS APIリファレンス」、および第18.5項「Oracle Security Developer Toolsの使用」を参照してください。
