Oracle® Fusion Middleware

Identity Governance Frameworkによるアプリケーションの開発

12.2.1.2

E82654-01(原本部品番号:E78161-01)

2016年10月

このガイドは、ユーザー、アプリケーションおよびサービス・プロバイダ間でのアイデンティティ関連情報の安全な受渡しを実現するIdentity Governance Framework (IGF)イニシアチブについて説明しています。ここでは、Oracleが提供する、Identity Governance Frameworkベースの開発者向けAPIを使用した開発方法について説明します。

Oracle Fusion Middleware Identity Governance Frameworkによるアプリケーションの開発、12.2.1.2

E82654-01

Copyright © 2013, 2016, Oracle and/or its affiliates.All rights reserved.

原本著者: Devanshi Mohan

原本協力者: Santhosh H M、Anandaprakash Sivasubramanian

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

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

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(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 Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

- リリース12c (12.2.1.2)の新機能

- リリース12c (12.2.1.1)の新機能

- 新しいIDSチューニング構成パラメータ

- リリース12c (12.2.1)の新機能

- 新しいIDS構成パラメータ

- 接続プールへの接続の回収のサポート

- リリース12c (12.1.3)の新機能

- 検索フィルタの論理NOT演算子

- エンティティ属性のパススルーのサポート

1 Identity Governance Frameworkの概要

- 1.1 Identity Governance Frameworkの概要

- 1.1.1 Identity Governance Frameworkが組織にもたらす利点

- 1.1.2 Identity Governance Frameworkが開発者にもたらす利点

- 1.2 Identity Governance Framework APIについて

- 1.3 Identity Governance Frameworkのシステム要件と動作要件

2 アイデンティティ・ディレクトリAPIの使用

- 2.1 アイデンティティ・ディレクトリAPIの概要

- 2.1.1 アイデンティティ・ディレクトリAPIについて

- 2.1.2 Identity Directory Serviceのアーキテクチャ

- 2.2 アイデンティティ・ディレクトリAPIの構成

- 2.2.1 Identity Directory Serviceの論理的なエンティティ構成

- 2.2.1.1 論理的なエンティティ構成のプロパティ

- 2.2.1.2 論理的なエンティティ構成の属性

- 2.2.1.3 論理的なエンティティ定義のプロパティ

- 2.2.1.4 論理的なエンティティ・リレーションシップのプロパティ

- 2.2.2 Identity Directory Serviceの物理的なアイデンティティ・ストア構成

- 2.2.3 Identity Directory Serviceのオペレーション構成

- 2.3 アイデンティティ・ディレクトリAPIの設計に関する推奨事項

- 2.3.1 defaultFetch属性の使用を最小限に抑える

- 2.3.2 アイデンティティ・ディレクトリの初期化を1回にする

- 2.4 アイデンティティ・ディレクトリAPIの使用例

- 2.4.1 アイデンティティ・ディレクトリ・ハンドルの初期化と取得

- 2.4.2 JPSコンテキストからのアイデンティティ・ディレクトリ・ハンドルの初期化と取得

- 2.4.3 メモリー内アイデンティティ・ディレクトリ・ハンドルの初期化と取得

- 2.4.4 ユーザーの追加

- 2.4.5 指定されたプリンシパルのユーザーの取得

- 2.4.6 ユーザーの変更

- 2.4.7 指定されたID値のユーザーの取得

- 2.4.8 複雑な検索フィルタを使用したユーザーの検索

- 2.4.9 ユーザー・パスワードの変更

- 2.4.10 ユーザー・パスワードのリセット

- 2.4.11 ユーザーの認証

- 2.4.12 ユーザーの削除

- 2.4.13 グループの作成

- 2.4.14 グループの検索

- 2.4.15 管理チェーンの取得

- 2.4.16 ユーザーのReporteeの取得

- 2.4.17 グループへのメンバーの追加

- 2.4.18 グループからのメンバーの削除

- 2.4.19 ユーザーがメンバーとなっているすべてのグループの取得

- 2.4.20 検索フィルタでの論理NOT演算子の使用

3 ArisID APIの使用

- 3.1 ArisID APIについて

- 3.2 ArisID APIの構成

- 3.2.1 CARMLファイルの確認

- 3.2.2 アイデンティティ・リポジトリの構成

- 3.2.3 マッピング・ファイルの構成

- 3.3 ArisID APIの設計に関する推奨事項

- 3.3.1 一意識別子の構成について

- 3.3.2 キー属性の仕様について

- 3.3.3 複数言語サポートについて

- 3.3.4 大規模な結果の処理

- 3.3.5 アプリケーションの保護

- 3.3.5.1 ドメイン・レベルの資格証明の適用

- 3.3.5.2 アプリケーション・レベルの資格証明の適用

- 3.3.6 タイムアウト間隔の構成

- 3.3.7 検索フィルタでのワイルドカード文字の指定

- 3.4 ArisID Beanの生成

- 3.5 IDXユーザーおよびロールBeanの使用例

- 3.5.1 IDXユーザーおよびロールBeanを使用したユーザーの検索: SearchUsers.jsp

- 3.5.2 IDXユーザーおよびロールBeanを使用したユーザーの検索: SearchUsers.html

- 3.6 OpenLDAPに関する考慮事項について

4 アイデンティティ・ディレクトリAPIへの移行

- 4.1 アイデンティティ・ディレクトリAPIへの移行の概要

- 4.2 アイデンティティ・ディレクトリAPIへのアプリケーションの移行

- 4.2.1 APIの初期化

- 4.2.2 UserManagerおよびGroupManagerのハンドルの取得

- 4.2.3 検索フィルタ

- 4.2.4 CRUD操作の実行

- 4.2.4.1 ユーザーを見つけるAPI

- 4.2.4.2 ユーザーを検索するAPI

- 4.2.4.3 ユーザーを作成するAPI

- 4.2.4.4 ユーザーを削除するAPI

- 4.2.4.5 ユーザーを認証するAPI

- 4.2.4.6 ユーザーを変更するAPIと関連エンティティを管理するAPI

- 4.3 ユーザーおよびロールAPIとIDS APIとの比較について

- 4.3.1 ユーザー関連APIとアイデンティティ・ディレクトリAPIとの比較

- 4.3.2 ロール関連APIとアイデンティティ・ディレクトリAPIとの比較

- 4.4 テスト環境から本番環境への移行

- 4.4.1 環境間の移行の概要

- 4.4.2 Identity Directory Service/libOVDの移動計画の変更

- 4.4.2.1 Identity Directory Service/libOVD configGroup要素の場所の特定

- 4.4.2.2 Identity Directory Service/libOVDの移動計画に関してカスタマイズするプロパティ

- 4.5 IDSの構成パラメータのチューニング

- 4.5.1 IDSの構成パラメータ

- 4.5.2 ファイルベース構成を使用してチューニング・パラメータを設定するためのWLSTコマンド

- 4.5.3 インメモリー構成を使用してチューニング・パラメータを設定するためのWLSTコマンド

- 4.5.4 ファイアウォールおよびロード・バランサのタイムアウト・エラーの処理

- 4.6 IDSでのパススルー属性の許可

はじめに

このガイドでは、Identity Governance Frameworkの概要、およびOracleが提供している関連の開発者向けAPIの使用方法について説明します。ここでは、アイデンティティ管理アプリケーションがアイデンティティ情報にアクセスして管理するための共通サービスであるアイデンティティ・ディレクトリAPIについて説明します。

対象読者

このドキュメントは、Oracle Fusion Middleware Identity Governance FrameworkベースのAPIを使用するアプリケーションを記述する開発者を対象としています。

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

Oracleのアクセシビリティへの取り組みについては、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)にアクセスしてください。

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を参照してください。

関連ドキュメント

詳細は、以下のドキュメントを参照してください。

- Identity Governance Frameworkアイデンティティ・ディレクトリJava APIリファレンス

- Identity Governance Framework IDXUserRole Java APIリファレンス

- Identity Governance Framework UserRole Java APIリファレンス

- Oracle Platform Security Servicesによるアプリケーションの保護

- Oracle® Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス

- Project Aristotle - ArisID Attribute ServicesのJavadoc (http://arisid.sourceforge.net/javadocs/arisId_1.1_javadoc/)

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

このガイドで説明する新機能

Identity Governance Framework (IGF)および関連する開発者向けAPIの、新機能および製品の重要な変更について確認します。

リリース12c (12.2.1.2)の新機能

このリビジョンに新機能はありません。ガイド全体で細かい更新があります。

リリース12c (12.2.1.1)の新機能

リリース12.2.1.1で導入された新機能および大規模な変更は次のとおりです。

- 新しいIDSチューニング構成パラメータ

新しいIDSチューニング構成パラメータ

IDSデプロイメントをチューニングするための新しい構成パラメータProtocolsが追加されました。

IDSの構成パラメータを参照してください。

リリース12c (12.2.1)の新機能

リリース12.2.1.0.0で導入された新機能および大規模な変更は次のとおりです。

- 新しいIDS構成パラメータ

- 接続プールへの接続の回収のサポート

新しいIDS構成パラメータ

IDSデプロイメントをチューニングするための新しい構成パラメータMaxPoolConnectionReuseTimeおよびConnectTimeoutが追加されました。

IDSの構成パラメータを参照してください。

接続プールへの接続の回収のサポート

接続プールのプロパティを構成できるようになりました。これにより、流用された接続を一定時間使用しなかった場合に接続プールに戻すことができます。

このプロパティを設定するには、PoolConnectionReclaimTime構成パラメータを使用します。この機能は、接続再利用が最大限になるようにし、使用されていない流用された接続の維持に浪費されることになるシステム・リソースを節約します。

IDSの構成パラメータを参照してください。

リリース12c (12.1.3)の新機能

リリース12.1.3で導入された新機能および大規模な変更は次のとおりです。

- 検索フィルタの論理NOT演算子

- エンティティ属性のパススルーのサポート

検索フィルタの論理NOT演算子

論理NOT演算子を指定して、単純または複雑なフィルタ条件を無効にすることができます。

SearchFilterクラスには2つの新規メソッドがあります。negate()はNOT条件を設定するトグル・メソッドで、isNegated()メソッドはNOT条件がすでに設定されているかどうかを確認できます。

検索フィルタでの論理NOT演算子の使用を参照してください。

エンティティ属性のパススルーのサポート

アイデンティティ・ディレクトリAPIは、エンティティ属性パススルーをサポートします。

属性定義およびエンティティ定義の下の属性参照に各属性をすべて含める必要はありません。追加、変更、リクエスト済属性、または検索フィルタ操作に任意の属性を含めることができます。属性がアイデンティティ・ストア・スキーマに存在しない場合、IDS APIはアイデンティティ・ストアによってスローされたエラーを返します。

Identity Directory Serviceの論理的なエンティティ構成を参照してください。

1 Identity Governance Frameworkの概要

Identity Governance Framework (IGF)イニシアチブは、ユーザー、アプリケーションおよびサービス・プロバイダ間でのアイデンティティ関連情報の安全な受渡しを実現します。また、アプリケーションおよびサービス・インフラストラクチャにプライバシと管理のセマンティクスを提供します。

次の各トピックで、Identity Governance Frameworkの概要、およびOracleが提供している関連の開発者向けAPIについて説明します。

- Identity Governance Frameworkの概要

- Identity Governance Framework APIについて

- Identity Governance Frameworkのシステム要件と動作要件

1.1 Identity Governance Frameworkの概要

Identity Governance Frameworkでは、標準を定義してアイデンティティ情報の交換を補語することができ、社内でも社外でもアプリケーション間のコンプライアンスが規制されます。アイデンティティ情報には、個々のアイデンティティに関する名前、アドレス、番号などの情報を含めることができます。

Identity Governance Frameworkはオープン・イニシアチブです。このイニシアチブの一員として、オラクル社は主な初期の仕様を提供し、コミュニティで使用できるようにしています。

Identity Governance Frameworkは、次の目標を実現するために設計されています。

- 格納場所に関係なく、アイデンティティ情報へのアクセス方法の開発を簡易化すること。

- アプリケーションでのアイデンティティ・データ(特に、機密データ)の使用方法の管理(ガバナンスとも呼ばれる)を簡易化すること。

これらの仕様では、使用方法のポリシー、属性要件およびアイデンティティ関連の情報の使用に関する開発者APIを定義するための共通のフレームワークが提供されます。これらによって、ビジネスは、システムおよびアプリケーション全体でのアイデンティティ関連のデータの使用、格納および伝播に関係なく、ドキュメント化、制御および監査を完全に行うことができます。

この項では、次の項目について説明します。

- Identity Governance Frameworkが組織にもたらす利点

- Identity Governance Frameworkが開発者にもたらす利点

1.1.1 Identity Governance Frameworkが組織にもたらす利点

Identity Governance Frameworkは、企業のセキュリティをサポートするポリシーと標準を利用し、信頼している当事者によってアイデンティティ情報が適切に保護、管理されているという信頼感をユーザーに与えます。

組織は、顧客、従業員および取引先に関する個人の機密情報の制御と保全を保つ必要があります。社会保障番号、クレジット・カード番号、病歴などに関連するデータは、この種の情報の悪用や盗用を防ぐよう求める規制によって一層の注意が求められています。プライバシに配慮する組織が、業務の妨げとなったり、生産性、柔軟性および効率に影響するような過度に厳格な制御とプロセスを施行してこれらの要求に応えようとすることが多々あります。反対に、この情報を保護するために必要な措置をとらず、十分な監視と制御を行わずにアイデンティティ関連のデータを潜在的に危険な状態にする組織もあります。Identity Governance Frameworkによって、エンタープライズ用の標準ベースのメカニズムで、アプリケーション間で"契約"を結び、データが悪用されたり、危険にさらされたり、置き違えられたりしないという信頼性のもと、アイデンティティ関連の情報を安全に共有できます。このフレームワークを使用すると、組織は、ビジネス全体でのアイデンティティ情報の格納、使用および伝播のされ方を完全に可視化できます。これによって、組織は、アイデンティティ関連の情報の機密性を損なうことなく、ビジネス・プロセスを効率化するための制御を自動化できます。

1.1.2 Identity Governance Frameworkが開発者にもたらす利点

Identity Governance Frameworkは、アプリケーションを記述する際のアイデンティティ関連のデータの処理方法の指定について取り決められたプロセスです。そのため、開発者は標準的なアプローチでアプリケーションを作成でき、ポリシーによってアプリケーションが制御されるようにこのデータを使用できます。このことにより、プライバシを考慮したアプリケーションを短期間で開発できるようになります。

IGFによって、アイデンティティに対応するアプリケーションをデプロイ・インフラストラクチャから切り離すことができます。具体的には、IGFを使用すると、開発者は、アイデンティティ関連の情報の格納方法およびアプリケーションによるアクセス方法の決定を遅らせることができます。開発者は、SQLデータベースを使用するか、LDAPディレクトリを使用するか、あるいは他のシステムを使用するかについて悩む必要がなくなります。過去には、開発者は特異性の高いコードの記述を余儀なくされ、テクノロジとベンダーの固定化につながっていました。

たとえば、アイデンティティ・ディレクトリAPIは、ドメイン・アイデンティティ・ストアであるディレクトリ・サーバー内でアイデンティティ情報にアクセスし、管理する方法を提供します。エンティティ定義、エンティティ・リレーションシップ、およびその物理的なアイデンティティ・ストアの詳細は、アイデンティティ・ディレクトリの構成APIまたはMbeanを使用して構成できます。Identity Directory Serviceの初期化にはアイデンティティ・ディレクトリAPIを使用します。Identity Directory Serviceは、異なるアイデンティティ・ストアに格納されているユーザーおよびグループ情報にアクセスし、それらを変更するためのインタフェースを提供します。詳細は、アイデンティティ・ディレクトリAPIの使用を参照してください。

別の例として、ArisID APIがあります。アイデンティティベースの情報については、データの取得、変換およびポリシーの強制といった難しい処理がArisID APIによって行われます。Client Attribute Requirement Markup Language (CARML)ファイルと宣言を使用することで、継続的に専門的な開発者の増強を必要とせずに、様々な環境での柔軟なデプロイがアプリケーションによってサポートされます。詳細は、ArisID APIの使用を参照してください。

1.2 Identity Governance Framework APIについて

Identity Governance Frameworkは、アイデンティティ情報の交換を可能にしつつセキュリティとコンプライアンスを保証するためにひつよなデータ・モデル要件を実装するために、2種類のAPIモジュールを利用します。

Oracleでは、Identity Governance Frameworkベースの次のAPIを提供しています。

- アイデンティティ・ディレクトリAPI
アイデンティティ・ディレクトリAPIは、アイデンティティ情報にアクセスして管理するアイデンティティ管理アプリケーションのための共通サービスです。このサービスはJava EEおよびJava SEの両方のモードで使用できます。詳細は、アイデンティティ・ディレクトリAPIの使用を参照してください。

- ArisID API
ArisID APIは、エンタープライズ開発者とシステム設計者に、複数のアイデンティティ・プロトコルを使用したアイデンティティ対応のアプリケーションを作成するためのライブラリを提供します。ArisID APIでは、開発者は、Client Attribute Requirements Markup Language (CARML)を使用して、アイデンティティの属性、ロールおよび検索フィルタの要件を指定できます。詳細は、ArisID APIの使用を参照してください。

1.3 Identity Governance Frameworkのシステム要件と動作要件

システム要件のマニュアルには、ハードウェアおよびソフトウェア要件、最小ディスク領域およびメモリー要件、必要なシステム・ライブラリ、パッケージ、パッチなどの情報が記載されています。

ハードウェアとソフトウェアの要件、プラットフォーム、データベースおよびその他の情報の詳細は、システム要件と動作要件のドキュメントを参照してください。いずれのドキュメントもOracle Technology Network (OTN)から入手できます。

詳細は、Oracle Fusion Middlewareのシステム要件と仕様を参照してください。

動作保証のドキュメントには、サポートされているインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサードパーティ製品が記載されています。詳細は、Oracle Fusion Middlewareでサポートされるシステム構成を参照してください。

2 アイデンティティ・ディレクトリAPIの使用

アイデンティティ・ディレクトリAPIは、ユーザー、グループおよび組織へのアクセスと管理をサポートします。また、新しいエンティティ・タイプおよびそれらのエンティティ間で定義されたリレーションシップをサポートするように拡張することもできます。

次の各トピックで、Identity Governance Framework、アイデンティティ・ディレクトリAPIおよびIdentity Directory Serviceのアーキテクチャと主要な機能について説明します。

- アイデンティティ・ディレクトリAPIの概要

- アイデンティティ・ディレクトリAPIの構成

- アイデンティティ・ディレクトリAPIの設計に関する推奨事項

- アイデンティティ・ディレクトリAPIの使用例

2.1 アイデンティティ・ディレクトリAPIの概要

アイデンティティ・ディレクトリAPIは、アイデンティティ管理アプリケーションがアイデンティティ情報にアクセスし、管理するためのサービスを提供します。柔軟性のあるこのAPIは、クライアントによって完全に構成可能であり、標準および固有のスキーマを持つ様々なアイデンティティ・ストアをサポートします。さらに堅牢であり、高可用性およびフェイルオーバー・サポートの両方を提供します。

このAPIは、Identity Governance Frameworkを使用し、Identity Governanceによるアイデンティティ情報の規制および制御がもたらすすべての利点を提供します。このAPIはJava EEおよびJava SEの両方のモードで使用できます。Identity Governance Frameworkの詳細は、Identity Governance Frameworkの概要を参照してください。

APIでサポートされるアクションは次のとおりです。

- ユーザー、グループ、組織のエンティティおよび汎用エンティティに対する作成/読取り/更新/削除(CRUD)操作の実行

- ユーザー・アカウント状態の取得操作

- アイデンティティ・ディレクトリAPIの構成の共有

- Oracle Internet Directory、Oracle Unified Directory、Oracle Directory Server EE、Active Directoryなどのディレクトリ・サーバーのサポート

Identity Directory Serviceには次のものが含まれます。

- アイデンティティ・ディレクトリAPI
ドメイン・アイデンティティ・ストアであるディレクトリ・サーバー内でアイデンティティ情報にアクセスし、管理する方法を提供します。エンティティ定義、エンティティ・リレーションシップ、およびその物理的なアイデンティティ・ストアの詳細は、アイデンティティ・ディレクトリの構成APIまたはMbeanを使用して構成できます。ディレクトリ・サービス・インスタンスの機能は、ゲッター・メソッドを使用して問い合せることができます。

- アイデンティティ・ディレクトリAPIの構成
アイデンティティ・ディレクトリAPIの構成には、論理的なエンティティ構成と物理的なアイデンティティ・ストア構成が含まれます。

この項では、次の項目について説明します。

- アイデンティティ・ディレクトリAPIについて

- Identity Directory Serviceのアーキテクチャ

2.1.1 アイデンティティ・ディレクトリAPIについて

Identity Directory Serviceは、アイデンティティ管理製品がアイデンティティ・ディレクトリにアクセスし、管理するために使用する共通サービスです。Identity Directory Serviceの初期化にはアイデンティティ・ディレクトリAPIを使用します。

Identity Directory Serviceは、異なるアイデンティティ・ストアに格納されているユーザーおよびグループ情報にアクセスし、それらを変更するためのインタフェースを提供します。アイデンティティ・ディレクトリはIdentity Directory Serviceのインスタンスであり、次のものが含まれています。

- 一意の名前 (IDS名)

- 論理的なエンティティ構成

- 物理的なアイデンティティ・ストア構成

アイデンティティ・ストア・サービスとも呼ばれるIdentity Directory Serviceの詳細は、Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護でアイデンティティ・ストア・サービスの概要を参照してください。

2.1.2 Identity Directory Serviceのアーキテクチャ

アイデンティティ・ディレクトリ・サービスAPIを使用するには、アーキテクチャを理解し、アイデンティティの統合方法と使用方法を把握することが重要です。

図2-1は、アイデンティティ・ディレクトリ・サービスの論理的なアーキテクチャを示します。

図2-1 アイデンティティ・ディレクトリAPIのアーキテクチャ

図2-2は、アイデンティティ・ディレクトリ・サービスのコンポーネント間のリレーションシップを示します。

図2-2 アイデンティティ・ディレクトリAPIのコンポーネント

2.2 アイデンティティ・ディレクトリAPIの構成

アイデンティティ・ディレクトリAPIは、異なるアイデンティティ・ストアに格納されているユーザーおよびグループ情報にアクセスし、それらを変更するためのインタフェースを提供します。アイデンティティ・ディレクトリの構成は、論理的なエンティティ構成、物理的なアイデンティティ・ストア構成、操作構成の組合せです。

論理的なエンティティ構成およびオペレーション構成は、ids-config.xmlに格納されています。このファイルは、jps-config.xmlと同じディレクトリにあります。たとえば、Java EE環境では次の場所にあります。

DOMAIN_HOME/config/fmwconfig/ids-config.xml

物理的なアイデンティティ・ストア構成は、ovd/ids/adapters.os.xmlにあります。たとえば、ovdディレクトリは、Java EE環境では次の場所にあります。

DOMAIN_HOME/config/fmwconfig

この項では、次の項目について説明します。

- Identity Directory Serviceの論理的なエンティティ構成

- Identity Directory Serviceの物理的なアイデンティティ・ストア構成

- Identity Directory Serviceのオペレーション構成

2.2.1 Identity Directory Serviceの論理的なエンティティ構成

アイデンティティ・ディレクトリの論理エンティティ構成に関連付けられている属性とプロパティを保守管理することが重要です。

次の各トピックで、Identity Directory Serviceの論理的なエンティティ構成について説明します。

- 論理的なエンティティ構成のプロパティ

- 論理的なエンティティ構成の属性

- 論理的なエンティティ定義のプロパティ

- 論理的なエンティティ・リレーションシップのプロパティ

2.2.1.1 論理的なエンティティ構成のプロパティ

論理的なエンティティ構成のプロパティに留意する必要があります。

名前

説明

name

Identity Directory Serviceを一意に識別する名前です。

description

Identity Directory Serviceの詳細な説明です。

ovd.context

有効な値はdefaultまたはidsです。OPSSで構成されている同じアイデンティティ・ストアに接続するには、defaultを使用します。OPSSに依存せず構成された物理的なアイデンティティ・ストアに接続するには、idsを使用します。デフォルトのアイデンティティ・ディレクトリ(userroleおよびidxuserrole)のみdefault値を使用します。

app.name

Identity Directory Serviceの構成対象である特定のアプリケーションを指定するプロパティです(オプション)。

2.2.1.2 論理的なエンティティ構成の属性

次の表に、論理的なエンティティ属性を示します。

名前

説明

name

論理的な属性の名前です。

dataType

有効なデータ・タイプの値は、string、boolean、integer、double、datetime、binary、x500nameおよびrfc822nameです。

description

論理的な属性の詳細な説明です。

readOnly

デフォルトはfalseです。属性が読取り専用の場合はtrueを使用します。

pwdAttr

デフォルトはfalseです。属性がパスワード属性の場合はtrueを使用します。

注意:

12c (12.1.3)リリース以降、アイデンティティ・ディレクトリAPIは、エンティティ属性パススルーをサポートします。パススルーをサポートする場合、属性定義(論理的なエンティティ構成の属性で説明)およびエンティティ定義の下の属性参照(論理的なエンティティ定義のプロパティで説明)に各属性をすべて含める必要はありません。

IDS APIでは、追加、変更、リクエスト済属性、または検索フィルタ操作での任意の属性を許可します。エンティティ定義は、バックエンド・アイデンティティ・ストアとは異なる論理的な属性名を使用してエンティティ関係を定義するための、または属性のデフォルトのフェッチのための、属性の最小限のセットを保持できます。

入力属性がアイデンティティ・ストア・スキーマにない場合、IDS APIはアイデンティティ・ストアによってスローされたエラーを返します。

2.2.1.3 論理的なエンティティ定義のプロパティ

論理的なエンティティ定義ごとに必要なプロパティに留意する必要があります。

名前

説明

name

エンティティの名前。

type

有効なエンティティの値は、user、group、orgおよびotherです。

idAttr

エンティティを一意に識別する論理的な属性です。

create

このエンティティの作成が許可されている場合はtrueを使用します。そうでない場合はfalseを使用します。

modify

このエンティティの変更が許可されている場合はtrueを使用します。そうでない場合はfalseを使用します。

delete

このエンティティの削除が許可されている場合はtrueを使用します。そうでない場合はfalseを使用します。

search

このエンティティの検索が許可されている場合はtrueを使用します。そうでない場合はfalseを使用します。

Attribute References

次の詳細を含むエンティティ属性のリファレンスのリストです。

- name: 論理的な属性の名前。

- defaultFetch: デフォルト値はtrueです。属性がデフォルトでフェッチされる場合はtrueを使用します。たとえば、アイデンティティ・ディレクトリAPIを使用してエンティティを読み取る場合、リクエストした属性にこの属性が含まれていなくても、この属性値はアイデンティティ・ストアからフェッチされます。

- filter: 検索フィルタのタイプです。有効な値として、none、dynamic、equals、notequals、beginswith、contains、doesnotcontain、endswith、greaterequal、lessequal、greaterthanおよびlessthanのいずれかの値を持ちます。noneはフィルタのサポートがないことを意味します。

2.2.1.4 論理的なエンティティ・リレーションシップのプロパティ

論理的なエンティティ・リレーションシップ定義ごとに必要なプロパティに留意する必要があります。

名前

説明

name

エンティティ・リレーションシップの名前です。

type

有効なエンティティの値は、OneToOne、OneToMany、ManyToOneおよびManyToManyです。

fromEntity

エンティティ・リレーションシップの最初のエンティティの名前です。

fromAttr

最初のエンティティの属性です。この属性値は、リレーションシップの2番目のエンティティに関連します。

toEntity

エンティティ・リレーションシップの2番目のエンティティの名前です。

toAttr

2番目のエンティティの属性です。fromAttrプロパティの値は、2番目のエンティティのこの属性にマップされます。

recursive

エンティティ・リレーションシップが再帰的な場合はtrueを使用します。デフォルトはfalseです。

2.2.2 Identity Directory Serviceの物理的なアイデンティティ・ストア構成

必要に応じて使用できるように、アイデンティティ・ディレクトリについて構成項目の物理特性を把握し、文書化しておくことが重要です。

次の表に、物理的なアイデンティティ・ストア構成のプロパティを示します。

名前

説明

HostおよびPort

アイデンティティ・ストアのホストおよびポートの情報です。フェイルオーバー用に代替ホストおよびポートの詳細を設定することもできます。

Directory Type

ディレクトリのタイプです。有効な値は、OID、ACTIVE_DIRECTORY、IPLANET、EDIRECTORY、OPEN_LDAP、WLS_OVDおよびOUDです。

Bind DNおよびPassword

ディレクトリに接続するための資格証明です。

2.2.3 Identity Directory Serviceのオペレーション構成

Identity Directory Serviceの構成項目に関連する機能上および操作上の観点を調べ、特定する必要があります。

オペレーション構成には、主に、各エンティティのbase、name attributeおよびobjectclassの構成が含まれます。

次の表に、オペレーション構成のエンティティを示します。

名前

説明

entity.searchbase

エンティティを検索する必要のあるコンテナです。

entity.createbase

新しいエンティティが作成されるコンテナです。

entity.name.attr

エンティティのRDN属性です。

entity.filter.objclasses

このエンティティの検索時に使用されるobjectclassフィルタです。

entity.create.objclasses

この新しいエンティティの作成時に追加されるobjectclassesです。

2.3 アイデンティティ・ディレクトリAPIの設計に関する推奨事項

アイデンティティ・ディレクトリAPIを作成する際に、年頭に置いておくべき重要な設計上のガイドラインがあります。

次の各トピックで、推奨事項について説明します。

- defaultFetch属性の使用を最小限に抑える

- アイデンティティ・ディレクトリの初期化を1回にする

2.3.1 defaultFetch属性の使用を最小限に抑える

新しいアイデンティティ・ディレクトリを構成するときは、エンティティ属性の数をできるかぎり少なくする必要があります。

エンティティ属性はdefaultFetchの値によって定義されます。また、jpegphotoのように値が大きい属性は、defaultFetchの値をfalseで構成します。これは、エンティティをバックエンドから読み取るたびに、すべてのdefaultFetch属性がバックエンド・ディレクトリから取得されるためです。defaultFetch属性が多すぎるとパフォーマンスに影響を与えます。

2.3.2 アイデンティティ・ディレクトリの初期化を1回にする

アイデンティティ・ディレクトリの初期化では、ArisIdスタック全体の初期化にかなりの負荷がかかります。したがって、アイデンティティ・ディレクトリは1回のみ初期化する必要があります。

Identity Directory Serviceの初期化にはアイデンティティ・ディレクトリAPIを使用します。なんらかのオーバーヘッドがあります。そのため、アプリケーションでのアイデンティティ・ディレクトリの初期化は1回のみ、できれば起動時に実行し、全体を通して1つのハンドルのみを使用することをお薦めします。

2.4 アイデンティティ・ディレクトリAPIの使用例

アイデンティティ・ディレクトリAPIに関連する各種の操作を実行するには、次のサンプル・コードを使用します。

次の各トピックで、アイデンティティ・ディレクトリAPIに関連する操作について説明します。

- アイデンティティ・ディレクトリ・ハンドルの初期化と取得

- JPSコンテキストからのアイデンティティ・ディレクトリ・ハンドルの初期化と取得

- メモリー内アイデンティティ・ディレクトリ・ハンドルの初期化と取得

- ユーザーの追加

- 指定されたプリンシパルのユーザーの取得

- ユーザーの変更

- 指定されたID値のユーザーの取得

- 複雑な検索フィルタを使用したユーザーの検索

- ユーザー・パスワードの変更

- ユーザー・パスワードのリセット

- ユーザーの認証

- ユーザーの削除

- グループの作成

- グループの検索

- 管理チェーンの取得

- ユーザーのReporteeの取得

- グループへのメンバーの追加

- グループからのメンバーの削除

- ユーザーがメンバーとなっているすべてのグループの取得

- 検索フィルタでの論理NOT演算子の使用

2.4.1 アイデンティティ・ディレクトリ・ハンドルの初期化と取得

Identity Directory Serviceの機能を使用するには、まず初期化関数を呼び出す必要があります。アイデンティティ・ディレクトリ・ハンドルが取得され、それを利用して基本的なユーザーとグループのCRUD操作が実行されます。

import oracle.igf.ids.UserManager;
import oracle.igf.ids.GroupManager;
import oracle.igf.ids.config.OperationalConfig;
import oracle.igf.ids.IdentityDirectoryFactory;
import oracle.igf.ids.IdentityDirectory;
import oracle.igf.ids.IDSException;

public class IdsSample {

private IdentityDirectory ids;
private UserManager uMgr;
private GroupManager gMgr;

public IdsSample() throws IDSException {
// Set Operational Config
OperationalConfig opConfig = new OperationalConfig();

// Set the application credentials (optional).  This
overrides the credentials set in
// physical ID store configuration
opConfig.setApplicationUser("cn=user1,dc=us,dc=example,dc=com");
opConfig.setApplicationPassword("password".toCharArray());

// Set search/crate base, name, objclass, etc. config
(optional).  This overrides default operational configuration
in IDS
opConfig.setEntityProperty("User", opConfig.SEARCH_BASE,
"dc=us,dc=example,dc=com");
opConfig.setEntityProperty("User", opConfig.CREATE_BASE,
"dc=us,dc=example,dc=com");
opConfig.setEntityProperty("User", opConfig.FILTER
_OBJCLASSES, "person");
opConfig.setEntityProperty("User", opConfig.CREATE
_OBJCLASSES, "inetorgperson");
opConfig.setEntityProperty("Group", opConfig.SEARCH
_BASE, "cn=groups,dc=us,dc=example,dc=com");
opConfig.setEntityProperty("Group", opConfig.CREATE
_BASE, "cn=groups,dc=us,dc=example,dc=com");
opConfig.setEntityProperty("Group", opConfig.FILTER
_OBJCLASSES, "groupofuniquenames");
opConfig.setEntityProperty("Group", opConfig.CREATE
_OBJCLASSES, "groupofuniquenames");

// Get IdentityDirectory "ids1" configured in IDS config
IdentityDirectoryFactory factory = new
IdentityDirectoryFactory();
ids = factory.getIdentityDirectory("ids1", opConfig);

// Get UserManager and GroupManager handles
uMgr = ids.getUserManager();
gMgr = ids.getGroupManager();
}
}

注意:

認証プロバイダとしてTivoliを使用する場合は、認証プロバイダのタイプとしてOPEN_LDAPを選択する必要があります。これは、Oracle WebLogic ServerでTivoliがサポートされていないためです。

Tivoliのディレクトリ・ハンドルを取得するようにIdentity Governance FrameworkまたはIdentity Directory Serviceを初期化すると、生成されたadapters.os_xmlファイルに次のパラメータが含まれています。

<param name="mapAttribute" value="orclGUID=entryUUID"/>

このTivoliのシナリオでは、次のようにorclGUID属性をibm-entryUUIDにマップする必要があります。

<param name="mapAttribute" value="orclGUID=ibm-entryUUID"/>

これらの変更を反映するため、adapters.os_xmlファイルを手動で更新する必要があります。さらに、属性マッピングの更新を有効にするためにOracle WebLogic Serverを再起動する必要があります。

2.4.2 JPSコンテキストからのアイデンティティ・ディレクトリ・ハンドルの初期化と取得

JPSコンテキストから、アイデンティティ・ディレクトリ・ハンドルを初期化して取得できます。サンプル・コードを使用してタスクを実行します。

import oracle.igf.ids.UserManager;
import oracle.igf.ids.GroupManager;
import oracle.igf.ids.config.OperationalConfig;
import oracle.igf.ids.IdentityDirectoryFactory;
import oracle.igf.ids.IdentityDirectory;
import oracle.igf.ids.IDSException;

import oracle.security.jps.JpsContext;
import oracle.security.jps.JpsContextFactory;
import oracle.security.jps.service.idstore.IdentityStoreService;

public class IdsSample {

private IdentityDirectory ids;
private UserManager uMgr;
private GroupManager gMgr;

public IdsSample() throws IDSException {

// Get IdentityDirectory from JpsContext
try {
JpsContext context =
JpsContextFactory.getContextFactory().getContext();
IdentityStoreService idstore = (IdentityStoreService)
context.getServiceInstance(IdentityStoreService.class);
ids = idstore.getIdentityStore();
} catch (Exception e) {
throw new IDSException(e);
}

// Get UserManager and GroupManager handles
uMgr = ids.getUserManager();
gMgr = ids.getGroupManager();
}
}

2.4.3 メモリー内アイデンティティ・ディレクトリ・ハンドルの初期化と取得

インメモリーのアイデンティティ・ディレクトリ・ハンドルを初期化して取得できます。サンプル・コードを使用してこのタスクを実行します。

import java.util.ArrayList;
import java.util.List;

import oracle.igf.ids.UserManager;
import oracle.igf.ids.GroupManager;
import oracle.igf.ids.config.AttributeDef;
import oracle.igf.ids.config.AttributeRef;
import oracle.igf.ids.config.EntityDef;
import oracle.igf.ids.config.EntitiesConfig;
import oracle.igf.ids.config.EntityRelationship;
import oracle.igf.ids.config.IdentityStoreConfig;
import oracle.igf.ids.config.OperationalConfig;
import oracle.igf.ids.IdentityDirectoryFactory;
import oracle.igf.ids.IdentityDirectory;
import oracle.igf.ids.IDSException;

public class IdsSample {

private IdentityDirectory ids;
private UserManager uMgr;
private GroupManager gMgr;
public IdsSample() throws IDSException {

// Add Attribute definitions
List<AttributeDef> attrDefs = new ArrayList<AttributeDef>();
attrDefs.add(new AttributeDef("cn", AttributeDef.DataType.STRING));
attrDefs.add(new AttributeDef("firstname", AttributeDef.DataType.STRING));
attrDefs.add(new AttributeDef("sn", AttributeDef.DataType.STRING));
attrDefs.add(new AttributeDef("telephonenumber",
AttributeDef.DataType.STRING));
attrDefs.add(new AttributeDef("uid", AttributeDef.DataType.STRING));
attrDefs.add(new AttributeDef("uniquemember",
AttributeDef.DataType.STRING));

// Add User entity definition
List<EntityDef> entityDefs = new ArrayList<EntityDef>();
EntityDef userEntityDef = new EntityDef("User", EntityDef.EntityType.USER,
"cn");
userEntityDef.addAttribute(new AttributeRef("cn"));
userEntityDef.addAttribute(new AttributeRef("firstname"));
userEntityDef.addAttribute(new AttributeRef("sn"));
userEntityDef.addAttribute(new AttributeRef("telephonenumber"));
userEntityDef.addAttribute(new AttributeRef("uid"));
entityDefs.add(userEntityDef);

// Add Group entity definition
EntityDef groupEntityDef = new EntityDef("Group",
EntityDef.EntityType.GROUP, "cn");
groupEntityDef.addAttribute(new AttributeRef("cn"));
groupEntityDef.addAttribute(new AttributeRef("uniquemember", false,
AttributeRef.FilterType.EQUALS));
entityDefs.add(groupEntityDef);

// Add Entity relationship definition
List<EntityRelationship> entityRelations = new
ArrayList<EntityRelationship>();
entityRelations.add(new EntityRelationship("user_memberOfGroup",
EntityRelationship.RelationshipType.MANYTOMANY, "User",
"principal", "Group", "uniquemember"));
entityRelations.add(new EntityRelationship("group_memberOfGroup",
EntityRelationship.RelationshipType.MANYTOMANY, "Group",
"principal", "Group", "uniquemember", true));
EntitiesConfig entityCfg = new EntitiesConfig(attrDefs,
entityDefs, entityRelations);

// Create physical Identity Store configuration
IdentityStoreConfig idStoreCfg = new IdentityStoreConfig(
"ldap://host1:389,ldap://host2:389", "cn=orcladmin",
"password".toCharArray(), IdentityStoreConfig.IdentityStoreType.OID);

idStoreCfg.setHighAvailabilityOption(IdentityStoreConfig.HAOption.FAILOVER);
idStoreCfg.setProperty(IdentityStoreConfig.HEARTBEAT_INTERVAL, "60");
idStoreCfg.setProperty(IdentityStoreConfig.CONN_TIMEOUT, "30000");    //
milli sec
idStoreCfg.setProperty(IdentityStoreConfig.MIN_POOLSIZE, "5");
idStoreCfg.setProperty(IdentityStoreConfig.MAX_POOLSIZE, "10");
idStoreCfg.setProperty(IdentityStoreConfig.MAX_POOLWAIT, "1000");     //
milli sec
idStoreCfg.setProperty(IdentityStoreConfig.MAX_POOLCHECKS, "10");
idStoreCfg.setProperty(IdentityStoreConfig.FOLLOW_REFERRAL, "false");
idStoreCfg.setAttrMapping("firstname", "givenname");

// Set operational config
OperationalConfig opConfig = new OperationalConfig();
opConfig.setEntityProperty(opConfig.USER_ENTITY, opConfig.SEARCH_BASE,
"cn=users,dc=us,dc=example,dc=com");
opConfig.setEntityProperty(opConfig.USER_ENTITY, opConfig.CREATE_BASE,
"cn=users,dc=us,dc=example,dc=com");
opConfig.setEntityProperty(opConfig.USER_ENTITY, opConfig.NAME_ATTR,
"cn");
opConfig.setEntityProperty(opConfig.USER_ENTITY, opConfig.FILTER
_OBJCLASSES, "inetorgperson");
opConfig.setEntityProperty(opConfig.USER_ENTITY, opConfig.CREATE
_OBJCLASSES, "inetorgperson");
opConfig.setEntityProperty(opConfig.GROUP_ENTITY, opConfig.SEARCH_BASE,
"cn=groups,dc=us,dc=example,dc=com");
opConfig.setEntityProperty(opConfig.GROUP_ENTITY, opConfig.CREATE_BASE,
"cn=groups,dc=us,dc=example,dc=com");
opConfig.setEntityProperty(opConfig.GROUP_ENTITY, opConfig.NAME_ATTR,
"cn");
opConfig.setEntityProperty(opConfig.GROUP_ENTITY, opConfig.FILTER
_OBJCLASSES, "groupofuniquenames");
opConfig.setEntityProperty(opConfig.GROUP_ENTITY, opConfig.CREATE
_OBJCLASSES, "groupofuniquenames");

// Initialize Identity Store Service
IdentityDirectoryFactory factory = new IdentityDirectoryFactory();
ids = factory.getIdentityDirectory("ids1", entityCfg, idStoreCfg,
opConfig);

// Get UserManager and GroupManager handles
uMgr = ids.getUserManager();
gMgr = ids.getGroupManager();
}

}

2.4.4 ユーザーの追加

アイデンティティ・ディレクトリ・ハンドルを取得すると、ユーザーとグループに対してCRUD操作を実行できます。サンプル・コードを使用して、ユーザーをアイデンティティ・ストアに追加します。

Principal principal = null;

List<Attribute> attrs = new ArrayList<Attribute>();
attrs.add(new Attribute("commonname", "test1_user1"));
attrs.add(new Attribute("password", "mypassword".toCharArray()));
attrs.add(new Attribute("firstname", "test1"));
attrs.add(new Attribute("lastname", "user1"));
attrs.add(new Attribute("mail", "test1.user1@example.com"));
attrs.add(new Attribute("telephone", "1 650 123 0001"));
attrs.add(new Attribute("title", "Senior Director"));
attrs.add(new Attribute("uid", "tuser1"));

try {
CreateOptions createOpts = new CreateOptions();

principal = uMgr.createUser(attrs, createOpts);

System.out.println("Created user " + principal.getName());

} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}

2.4.5 指定されたプリンシパルのユーザーの取得

指定されたプリンシパルのユーザーを取得できます。サンプル・コードを使用してタスクを実行します。

User user = null;

try {
ReadOptions readOpts = new ReadOptions();

user = uMgr.getUser(principal, readOpts);

} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}

2.4.6 ユーザーの変更

ユーザーを作成すると、ユーザーの既存の属性を変更することも、ユーザーを変更して属性を追加することもできます。サンプル・コードを使用してこのタスクを実行します。

try {
ModifyOptions modifyOpts = new ModifyOptions();

List<ModAttribute> attrs = new ArrayList<ModAttribute>();
attrs.add(new ModAttribute("description", "modified test user 1"));

user.modify(attrs, modifyOpts);

System.out.println("Modified user " + user.getName());
} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}

2.4.7 指定されたID値のユーザーの取得

ユーザー詳細は、ユーザーのアイデンティティ値に基づいて取得できます。そのためには、取得問合せを作成して詳細をフェッチする必要があります。サンプル・コードを使用してこのタスクを実行します。

try {
ReadOptions readOpts = new ReadOptions();

User user = uMgr.searchUser("tuser1", readOpts);

} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}

2.4.8 複雑な検索フィルタを使用したユーザーの検索

ユーザー取得の問合せで、複雑なフィルタの作成が必要になる場合もあります。これは、指定した基準を照合し、ターゲット検索操作の結果を返します。サンプル・コードを使用してこのタスクを実行します。

try {
// Complex search filter with nested AND and OR conditiions
SearchFilter filter = new SearchFilter(
SearchFilter.LogicalOp.OR,
new SearchFilter(SearchFilter.LogicalOp.AND,
new SearchFilter("firstname", SearchFilter.Operator.BEGINS_WITH,
"test"),
new SearchFilter("telephone", SearchFilter.Operator.CONTAINS,
"650")),
new SearchFilter(SearchFilter.LogicalOp.AND,
new SearchFilter("firstname", SearchFilter.Operator.BEGINS_WITH,
"demo"),
new SearchFilter(SearchFilter.LogicalOp.OR,
new SearchFilter("orgunit", SearchFilter.Operator.BEGINS_WITH,
"hr"),
new SearchFilter("orgunit", SearchFilter.Operator.BEGINS_WITH,
"it"),

new SearchFilter("telephone", SearchFilter.Operator.CONTAINS,
"650")));

// Requesting attributes
List<String> reqAttrs = new ArrayList<String>();
reqAttrs.add("jpegphoto");

SearchOptions searchOpts = new SearchOptions();
searchOpts.setPageSize(100);
searchOpts.setRequestedAttrs(reqAttrs);
searchOpts.setSortAttrs(new String[] {"firstname"});

ResultSet<User> sr = uMgr.searchUsers(filter, searchOpts);
while (sr.hasMore()) {
User user = sr.getNext();
System.out.println(user.getSubjectName());
}

} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}

2.4.9 ユーザー・パスワードの変更

ユーザーの作成後、ユーザーの属性を変更できます。サンプル・コードを使用して、ユーザーのパスワードを変更します。

ModifyOptions modOpts = new ModifyOptions();

try {
user.changePassword("welcome123".toCharArray(),
"welcome1".toCharArray(), modOpts);
System.out.println("Changed user password");
} catch (Exception e) {
System.out.println("Failed to change user password");
e.printStackTrace();
}

2.4.10 ユーザー・パスワードのリセット

アイデンティティ・ディレクトリに作成されたユーザーのパスワードをリセットできます。サンプル・コードを使用してこのタスクを実行します。

ModifyOptions modOpts = new ModifyOptions();

try {
user.resetPassword("welcome123".toCharArray(), modOpts);
System.out.println("Reset user password");
} catch (Exception e) {
System.out.println("Failed to reset user password");
e.printStackTrace();
}

2.4.11 ユーザーの認証

各種の操作を実行できる権限を付与する前に、ユーザーを認証する必要があります。APIを使用してユーザーを認証できます。

ReadOptions readOpts = new ReadOptions();
try {
User user = uMgr.authenticateUser("tuser1",
"mypassword".toCharArray(), readOpts);
System.out.println("authentication success");
} catch (Exception e) {
System.out.println("Authentication failed. " + e.getMessage());
e.printStackTrace();
}

2.4.12 ユーザーの削除

アイデンティティ・ディレクトリAPIを使用して、アイデンティティ・ストアに存在するユーザーを削除できます。サンプル・コードを使用してこのタスクを実行します。

try {
DeleteOptions deleteOpts = new DeleteOptions();

uMgr.deleteUser(principal, deleteOpts);

System.out.println("Deleted user " + principal.getName());

} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}

2.4.13 グループの作成

個々のユーザーに権限を付与するかわりに、ユーザーのグループ単位で権限を付与または拒否できるので、グループを作成すると便利です。アイデンティティ・ディレクトリにユーザー・グループを作成できます。

Principal principal = null;

List<Attribute> attrs = new ArrayList<Attribute>();
attrs.add(new Attribute("name", "test1_group1"));
attrs.add(new Attribute("description", "created test group 1"));
attrs.add(new Attribute("displayname", "test1 group1"));
try {
CreateOptions createOpts = new CreateOptions();

principal = gMgr.createGroup(attrs, createOpts);

System.out.println("Created group " + principal.getName());
} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}

2.4.14 グループの検索

検索フィルタを定義して、必要な基準に一致するグループを検索できます。

public void searchGroups() {

try {
SearchFilter filter = new SearchFilter("name",
SearchFilter.Operator.BEGINS_WITH, "test");

SearchOptions searchOpts = new SearchOptions();
searchOpts.setPageSize(10);

ResultSet<Group> sr = gMgr.searchGroups(filter, searchOpts);
while (sr.hasMore()) {
Group group = sr.getNext();
System.out.println(group.getSubjectName());
}

} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}

2.4.15 管理チェーンの取得

アイデンティティ・ディレクトリの任意のユーザーについて、管理階層を取得できます。サンプル・コードを使用してこのタスクを実行します。

try {
ReadOptions readOpts = new ReadOptions();
User user = uMgr.searchUser("tuser1", readOpts);

SearchOptions searchOpts = new SearchOptions();
searchOpts.setPageSize(10);
int nLevels = 0;

ResultSet<User> sr  = user.getManagementChain(nLevels, searchOpts);
while (sr.hasMore()) {
User u = sr.getNext();
System.out.println(u.getSubjectName());
}

} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}

2.4.16 ユーザーのReporteeの取得

アイデンティティ・ディレクトリでターゲット検索フィルタを定義して、ユーザーのReporteeを取得できます。

// Get Reportees with target search filter
public void getReportees() {

try {
ReadOptions readOpts = new ReadOptions();
User user = uMgr.searchUser("tuser1", readOpts);

SearchOptions searchOpts = new SearchOptions();
searchOpts.setPageSize(20);
int nLevels = 0;

// get all the direct/indirect reporting of tuser1 who are
"developers"
SearchFilter filter = new SearchFilter("title",
SearchFilter.Operator.CONTAINS, "developer");
ResultSet<User> sr  = user.getReportees(nLevels, filter, searchOpts);
while (sr.hasMore()) {
User u = sr.getNext();
System.out.println(u.getSubjectName());
}

} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}

2.4.17 グループへのメンバーの追加

特定のグループに追加して、アイデンティティ・ディレクトリの既存のユーザーを論理的にグループ化できます。サンプル・コードを使用してこのタスクを実行します。

try {
ReadOptions readOpts = new ReadOptions();
User user = uMgr.searchUser("tuser1", readOpts);
Group group = gMgr.searchGroup("test1_group1", readOpts);

ModifyOptions modOpts = new ModifyOptions();
user.addMemberOf(group, modOpts);

System.out.println("added tuser1 as a member of test1_group1");

} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}

2.4.18 グループからのメンバーの削除

アイデンティティ・ディレクトリAPIを使用して、あるグループのメンバーであるユーザーを隔離することができます。サンプル・コードを使用してこのタスクを実行します。

try {
ReadOptions readOpts = new ReadOptions();
User user = uMgr.searchUser("tuser1", readOpts);
Group group = gMgr.searchGroup("test1_group1", readOpts);

ModifyOptions modOpts = new ModifyOptions();
group.deleteMember(user, modOpts);

System.out.println("deleted tuser1 from the group test1_group1");

} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}

注意:

Identity Governance Framework/Identity Directory Serviceのグループ・メンバーシップ検索では、静的グループと動的グループの両方を評価します。ただし、メンバーシップの更新(追加/削除)は、動的グループではサポートされません。たとえば、グループからメンバーを削除する際に、そのメンバーがそのグループの動的メンバーである場合、動的グループでは削除操作がサポートされません。

2.4.19 ユーザーがメンバーとなっているすべてのグループの取得

アイデンティティ・ディレクトリAPIを使用すると、アイデンティティ・ディレクトリの既存のユーザーについて、そのユーザーが所属しているグループをすべて取得できます。サンプル・コードを使用してこのタスクを実行します。

try {
ReadOptions readOpts = new ReadOptions();
User user = uMgr.searchUser("tuser1", readOpts);

SearchOptions searchOpts = new SearchOptions();
searchOpts.setPageSize(10);
int nLevels = 0;

ResultSet<Group> sr  = user.getMemberOfGroups(nLevels, null,
searchOpts);
while (sr.hasMore()) {
Group group = sr.getNext();
System.out.println(group.getSubjectName());
}

} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}

2.4.20 検索フィルタでの論理NOT演算子の使用

アイデンティティ・ディレクトリでは、検索フィルタでNOT演算子を使用できます。検索フィルタにおけるNOT演算子は簡単に定義でき、その基準に一致する結果を取得できます。

try {
SearchFilter f1 = new SearchFilter("firstname", SearchFilter.Operator.BEGINS_WITH, "demo");
SearchFilter f2 = new SearchFilter("orgunit", SearchFilter.Operator.CONTAINS, "myorg");
f2.negate();
SearchFilter filter = new SearchFilter(SearchFilter.LogicalOp.AND, f1, f2);

ResultSet<User> sr = uMgr.searchUsers(filter, searchOpts);
}

3 ArisID APIの使用

ArisID APIは、エンタープライズ開発者とシステム設計者に、複数のアイデンティティ・プロトコルを使用したアイデンティティ対応のアプリケーションを作成するためのライブラリを提供します。ArisID APIでは、開発者は、Client Attribute Requirements Markup Language (CARML)を使用して、アイデンティティの属性、ロールおよび検索フィルタの要件を指定できます。

次の各トピックで、Identity Governance Framework ArisID APIのアーキテクチャと主要な機能について説明します。

- ArisID APIについて

- ArisID APIの構成

- ArisID APIの設計に関する推奨事項

- ArisID Beanの生成

- IDXユーザーおよびロールBeanの使用例

- OpenLDAPに関する考慮事項について

3.1 ArisID APIについて

Identity Governance Framework ArisID APIは、すべてのアイデンティティ情報交換の受渡しに使用される共通のコア・サービスを表します。正式な名称ではありませんが、ArisID APIは、開発者からアイデンティティBeanと呼ばれることが多くあります。

12c (12.2.2.0)リリースのArisID APIは、次に提案されている構成のサブセットです。

http://www.openliberty.org/wiki/index.php/ArisID_Configuration

Oracle WebLogic ServerとOracle Identity Managementをインストールしてある場合、このAPIを使用したアプリケーションの開発に必要なjarファイルはすべて、コンピュータにすでにインストールされています。

Identity Governance Frameworkオープン・ソースAPI jarファイルは次のとおりです。

- openliberty.arisId_1.1.jar: 属性のセットを含むアイデンティティ・サブジェクトの取得に使用されるライブラリ関数とプロバイダを含んだコアArisID APIを提供します。詳細は、http://arisid.sourceforge.net/javadocs/arisId_1.1_javadoc/を参照してください。

- org.openliberty.arisIdBeans_1.1.jar: ArisID APIに加えてJavaオブジェクトの抽象化を提供するArisID Beanを提供します。これらによって、ArisID APIのトランザクション型アプローチをオブジェクトまたはBean型のアプローチに変換します。詳細は、http://arisid.sourceforge.net/javadocs/arisId_1.1_javadoc/を参照してください。

ArisID API jarファイルは次のとおりです。

- idxuserrole.jar: 標準的なユーザーとロールのアイデンティティの読取り専用操作を提供します。このjarは、標準のidxuserrole.xml CARMLファイルから生成されます。詳細は、Identity Governance Framework IDXUserRole Java APIリファレンスを参照してください。

- userrole.jar: アイデンティティ情報を更新するためのユーザーとロールのアイデンティティ読取り/書込み操作を提供します。詳細は、Identity Governance Framework UserRole Java APIリファレンスを参照してください。

- arisId-stack-ovd.jar: このjarファイルはOracle Virtualizationライブラリを使用したIAttrSvcStackインタフェースの実装で、異なるバックエンドに接続し、アイデンティティ・ストア・エンティティの抽象ビューを提供します。

ArisID Beanによって、CARML対話の初期化とアクセスに必要なJava APIが提供されます。Beanジェネレータでは、Apache Velociyを使用してCARMLファイル内の各エンティティに対するjavaファイルのセットを生成します。CARMLファイルは、アプリケーションの属性使用要件を記述する宣言型のドキュメントです。ArisID Beanは、jarファイルidxuserrole.jarおよびuserrole.jar内にあります。

次の図に、ArisID APIアーキテクチャの概要を示します。

図3-1 IGF ArisID APIアーキテクチャ

3.2 ArisID APIの構成

ArisID APIは、Webサーバー環境で簡単で柔軟なデプロイを可能にする複数の構成オプションをサポートしています。

Identity Governance Framework ArisIDでは、作成 > 変更 > テスト > デプロイといった基本的な開発プロセスがサポートされます。作成では、CARML XMLファイルをご使用の環境に応じて変更する必要があります。アプリケーションのテストは、LDAPディレクトリ・サーバーが組み込まれたOracle WebLogic Serverで行えます。

この項では、次の項目について説明します。

- CARMLファイルの確認

- アイデンティティ・リポジトリの構成

- マッピング・ファイルの構成

3.2.1 CARMLファイルの確認

CARMLは、アプリケーションについて属性使用の要件を定義するXMLベースの宣言形式です。管理者は、CARMLファイルを調べて、適切なバックエンド・リソースに接続します。

既存のArisID Beanがアプリケーションのニーズを満たすかどうかを判断するには、CARMLファイルidxuserrole.xml(読取り専用操作)およびuserrole.xml(読取り専用および読取り/書込み操作)のCARMLファイルを確認する必要があります。これらのCARMLファイルは、DOMAIN_HOME/config/fmwconfig/carmlにあります。

3.2.2 アイデンティティ・リポジトリの構成

アイデンティティ・リポジトリは、企業のユーザーとグループに関する情報が格納されるデータ・ストアです。ArisID Beanによって使用されるアイデンティティ・リポジトリを構成できます。

ArisID Beanによって使用されるアイデンティティ・リポジトリを使用可能にする必要があります。LDAPベースのディレクトリ・サーバーが組み込まれたOracle WebLogic Serverまたは11gのOracle Virtual Directoryでサポートされている任意のLDAPディレクトリを使用できます。ArisID APIは、Oracle Platform Security Servicesと統合されています。Oracle Platform Security Servicesに構成されているLDAPベースのアイデンティティ・ストアに自動的に接続します。Oracle Platform Security Servicesでサポートされているアイデンティティ・ストアの詳細は、Identity Governance Frameworkのシステム要件と動作保証情報を参照してください。

Oracle Platform Security Servicesの詳細は、Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護を参照してください。

Oracle Platform Security Servicesアイデンティティ・ストアとは異なるアイデンティティ・ストアを使用する必要がある場合、次のシステム・プロパティを設定します。

igf.ovd.config.dir=DOMAIN_HOME/config/fmwconfig/arisidprovider/conf

次に、adapters.os_xmlファイルを編集して、接続先のディレクトリのhost、portおよび資格証明を含めます。igf.ovd.config.dirプロパティは、adapaters.os_xmlおよび適切に設定された他の構成ファイルを含む任意のディレクトリに設定できます。

ディレクトリ制限

次のLDAPディレクトリ制限が適用されます。

- OpenLDAP 2.2またはNovell eDirectoryを使用する場合、ページングはサポートされていません。たとえば、searchUsersbyPage()、searchRolesbyPage()などのページングAPIは機能しません。複数言語サポート(MLS)は提供されません。

- Oracle WebLogic Serverの組込みLDAPベースのディレクトリ・サーバーを使用する場合、複数言語サポート(MLS)は提供されません。

3.2.3 マッピング・ファイルの構成

マッピング・ファイルで、CARML属性をLDAP属性、オブジェクトクラスおよび検索パラメータにマップできます。サイトのLDAPベースのディレクトリ・サーバー用にマッピング・ファイルをカスタマイズできます。

CARMLファイルが作成されている場合、対応するマッピング・ファイルは同じ場所に作成されます。デフォルトのマッピング・ファイルには、Oracle WebLogic Serverに組み込まれているディレクトリ・サーバー(Oracle Platform Security Servicesのデフォルト・アイデンティティ・ストア)に固有の属性詳細が含まれています。デフォルトのCARMLファイルとOracle Platform Security Servicesアイデンティティ・ストアを使用する場合、マッピングを構成する必要ばありません。Oracle Platform Security Servicesの構成パラメータは、マッピング・ファイルのパラメータをオーバーライドします。

3.3 ArisID APIの設計に関する推奨事項

デフォルトのCARMLファイルとマッピング・ファイルには、デプロイ・シナリオについて特定の想定がなされています。デプロイ要件によっては、これらの詳細を変更する必要がある場合があります。

次の各トピックで、変更可能な構成パラメータについて説明します。

- 一意識別子の構成について

- キー属性の仕様について

- 複数言語サポートについて

- 大規模な結果の処理

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

- タイムアウト間隔の構成

- 検索フィルタでのワイルドカード文字の指定

3.3.1 一意識別子の構成について

すべてのユーザーが一意に識別可能である必要があります。ユーザー・エントリを識別するための一意の識別子として、デフォルトの構成、emailが使用されます。

ユーザーの検索時、検索に想定されているデフォルトの属性はemailです。次に例を示します。

SearchUser( String uniqueid,  Map<String, Object>)

パフォーマンス上の理由から、一意の識別子として使用される属性は、バックエンドで検索可能な属性である必要があります。アプリケーションが選択したuniquekeyとバックエンドの属性との間のマッピングは、構成時に処理されます。これは、Oracle Virtual Directoryマッピングでの構成です。HashMapを使用して、操作の実行時に使用するオプションのコンテキスト情報を指定します。現在のリリースでは、次のオプションがサポートされます。

- 検索を実行するプリンシパル・ユーザー: (ArisIdConstants.APP_CTX_AUTHUSER, (Principal)user)

- 言語の制約(ある場合): (ArisIdConstants.APP_CTX_LOCALE, "fr")

- ページネーション・サポート(ある場合): (ArisIdConstants.APP_CTX_PAGESIZE, 10)

3.3.2 キー属性の仕様について

属性の一意性は、制約または属性を定義することによって適用されます。

アプリケーションで、アイデンティティ・リポジトリのバックエンドからアクセスされるエントリをアプリケーション固有のリポジトリに格納することがあります。このような場合、永続化する属性を慎重に検討する必要があります。たとえば、バックエンドがLDAPベースのリポジトリの場合、GUID属性がLDAPベースのバックエンドで唯一の一意のキーであるため、永続化属性としてこれを使用します。他のLDAP属性はすべて変更可能です。

バックエンドがリレーショナル・データベースの場合、一意性制約が適用される属性を一意キーとして選択します。これは、ArisIDマッピング・プロパティ・ファイルで指定できます。一意キーに基づいてユーザーを検索するメソッドは次のとおりです。

searchUserOnUniqueKey(String UniqueKey, Map<String,Object>)

HashMapを使用して、操作の実行時に使用するオプションのコンテキスト情報を指定します。現在のリリースでは、次のオプションがサポートされます。

- 検索を実行するプリンシパル・ユーザー: (ArisIdConstants.APP_CTX_AUTHUSER, (Principal)user)

- 言語の制約(ある場合): (ArisIdConstants.APP_CTX_LOCALE, "fr")

- ページネーション・サポート(ある場合): (ArisIdConstants.APP_CTX_PAGESIZE, "10")

3.3.3 複数言語サポートについて

ロケール固有の結果を必要とするアプリケーション向けに複数言語サポート(MLS)が提供されます。

属性と適切なMLSコードは、ArisIDプロパティ・ファイルのmultiLanguageAttributes要素に格納されます。

<multiLanguageAttributes>…</multiLanguageAttribute>

displaynameは、最もよく使用される複数言語属性であり、したがってデフォルトで複数言語属性として構成されています。必要に応じて他の属性をArisIDマッピング・ファイルに追加できます。

制限

引数としてロケールが指定されるAPIでは、ArisIDプロパティ・ファイルに<multiLanguageAttributes>としてリストされている、ロケール固有の値を持つすべての属性に対してロケール固有の値が返されます。他の属性についてはすべて、格納されているデフォルト値が返されます。

バックエンドのシステムでは、データはISO-3166に準拠した形式で返されます。たとえば、(英語の他に)フランス語のロケールがある場合、cn属性に対してcn,:frとして格納されます。クライアント・アプリケーションのロケールは、プロパティHashMapにArisIdConstants.APP_CTX_LOCALE, "fr"と指定し、ArisIDプロパティ・ファイルにcnをmultiLanguageAttributeとして含め、この属性をマップします。

3.3.4 大規模な結果の処理

場合によっては、大規模な結果セットを取得することがあります。その場合、パフォーマンスやリソースの問題が発生する可能性があります。大規模な結果セットを管理するには、次のサンプル・コードを使用します。

アプリケーションでアイデンティティ・データにアクセスする場合、検索の結果セットが大きすぎてアプリケーションで処理できない場合があります。そのような場合、管理可能なサイズのページに結果を分割することができます。これは、ページで返されるオブジェクトの数を定義することで行います。

次の例に、標準的な使用法を示します。

RoleManager rm = new RoleManager(env);
List<PropertyFilterValue> attrFilters = new  ArrayList<PropertyFilterValue>();
attrFilters.add(new PropertyFilterValue(Role.NAME, "admin", AttributeFilter.OP_CONTAINS));

HashMap<String,Object> map = new HashMap<String,Object>();
map.put("ArisIdConstants.APP_CTX_PAGESIZE","2");
SearchResults<Role> sr = rm.searchRolesbyPage(attrFilters, map);

while(sr.hasMore())
{
List<Role> roles = sr.getNextSet();

for (int i=0; i<roles.size(); i++)
//do the operations with roles.get(i)
}

3.3.5 アプリケーションの保護

ターゲット・システムで作成、読取り、更新および削除(CRUD)操作を実行する一般的なセキュリティ・シナリオが2つあります。これらのシナリオを確認して、十分に理解してください。

パラメータは次のとおりです。

- ドメイン・レベルの資格証明の適用

- アプリケーション・レベルの資格証明の適用

このリリースでは、プロキシ認証はサポートされていません。

3.3.5.1 ドメイン・レベルの資格証明の適用

このシナリオでは、ドメイン内のすべてのアプリケーションで共通の資格証明を使用してターゲット・システムに接続し、その資格証明で操作を実行します。アプリケーションは、ターゲット・システムにフットプリントを保持しません。

LDAPアダプタの構成ファイルadapters.os_xmlには、バックエンド・ディレクトリに接続するための資格証明およびホストとポートの詳細が含まれています。初期化時に他の資格証明を指定しない場合、アプリケーションはLDAPアダプタの構成ファイル内の資格証明を使用してターゲット・システムに接続します。

プロキシ・ユーザー(ログイン・ユーザーID)がAPIのアプリケーション・コンテキストで指定されていない場合、ArisID操作は、LDAPアダプタの構成ファイル内にある資格証明を使用して実行されます。

アプリケーションが共通の資格証明を使用して接続する場合、認可されたユーザーについてのみデータを表示したり、変更するようアプリケーション自体にセキュリティを組み込む必要があります。

LDAPアダプタの構成ファイルadapters.os_xmlがバックエンド・ディレクトリへの接続にドメイン・レベルのuseridと暗号化されたパスワードを使用するように構成されている次の例について考えます。次に示すのは、adapters.os_xmlのスニペットです。

<binddn>cn=admin</binddn>
<bindpass>{OMASK}C2QXW1Nmf+s=</bindpass>

ArisID APIの初期化時、資格証明を指定しません。

Map env = new HashMap();
// Do not set UserManager.SECURITY_PRINCIPAL & SECURITY_CREDENTIALS
UserManager uMgr  = new UserManager(env);
…
…
// Search Operation (with no proxy user in app context)
List<PropertyFilterValue> attrFilters = new ArrayList<PropertyFilterValue>();
attrFilters.add(new PropertyFilterValue("User.FIRSTNAME", "app1", AttributeFilter.OP_CONTAINS));
attrFilters.add(new PropertyFilterValue("User.LASTNAME", "user1", AttributeFilter.OP_BGNSWITH));
Map<String, Object> appCtx = null;
users = um.searchUsers(attrFilters, appCtx);

3.3.5.2 アプリケーション・レベルの資格証明の適用

このシナリオでは、各アプリケーションでアプリケーション・レベルの資格証明を使用してターゲット・システムに接続し、その資格証明でCRUD操作を実行します。

この場合、ArisID APIの初期化時にアプリケーションのユーザーIDとパスワードを指定します。そうすると、アプリケーションはそれらの資格証明を使用してターゲット・システムに接続します。

プロキシ・ユーザーがAPIのアプリケーション・コンテキストに指定されていない場合、アプリケーションの資格証明を使用してArisID操作が実行されます。

この使用例には、次の機能があります。

- 各アプリケーションは、ターゲット・システムのデータの表示および更新を行うための異なる権限を持ちます。

- ターゲット・システムで各アプリケーションによって行われる変更を監査できます。

LDAPアダプタの構成ファイルadapters.os_xmlがバックエンド・ディレクトリへの接続にドメイン・レベルのuseridと暗号化されたパスワードを使用するように構成されているシナリオについて考えます。次に示すのは、adapters.os_xmlのスニペットです。

<binddn>cn=admin</binddn>
<bindpass>{OMASK}C2QXW1Nmf+s=</bindpass>

ArisID APIの初期化時、アプリケーションのユーザー資格証明を指定します。

Map env = new HashMap();
env.put(UserManager.SECURITY_PRINCIPAL, "cn=app1_user,cn=users,dc=example,dc=com");
env.put(UserManager.SECURITY_CREDENTIALS, "mypassword");
UserManager uMgr  = new UserManager(env);
…
// Search Operation (with no proxy user in app context)
List<PropertyFilterValue> attrFilters = new ArrayList<PropertyFilterValue>();
attrFilters.add(new PropertyFilterValue("User.FIRSTNAME", "app1", AttributeFilter.OP_CONTAINS));
attrFilters.add(new PropertyFilterValue("User.LASTNAME", "user1", AttributeFilter.OP_BGNSWITH));Map<String, Object> appCtx = null;
users = um.searchUsers(attrFilters, appCtx);

3.3.6 タイムアウト間隔の構成

LDAP操作のタイムアウト間隔を構成できます。これらの間隔によって、LDAP操作がタイムアウトするまでの時間を指定できます。

デフォルトの接続/読取りタイムアウトは15秒に設定されています。たとえば、IdentityStoreのLDAP操作に15秒以上かかる場合、その操作はタイムアウトし、IGFでは次の例外が発生します。

org.openliberty.arisid.stack.ConnectionException

IdentityStoreに多数のエントリがあり、「次を含む」というフィルタを使用してページング/ソートで検索すると、これらの問合せはタイムアウトする場合があります。

タイムアウト値を0(タイムアウトなし)に設定し、プール・サイズを20まで増やすことをお薦めします。アプリケーションにタイムアウト間隔がある場合は、0より大きい値を設定します。

タイムアウト間隔を構成する手順は、次のとおりです。

1. 次のWLSTコマンドを実行し、すべてのアダプタをリストします。

listAdapters()

2. 各アダプタに対して次のコマンドを実行し、timeoutおよびmaxpoolsizeを設定します。

a. modifyLDAPAdapter('<ADAPTER NAME>', 'OperationTimeout', 0)

b. modifyLDAPAdapter('<ADAPTER NAME>', 'MaxPoolSize', 20)

3. WebLogic Serverを再起動します。

3.3.7 検索フィルタでのワイルドカード文字の指定

Oracle Internet Directoryでは、DN属性のワイルドカード検索がサポートされます。

Oracleディレクトリ以外のディレクトリでは、ワイルドカード検索がサポートされないことがあります。そのため、バックエンドのMicrosoft Active Directoryなどとともに検索フィルタでDNを使用して、Identity Governance Framework APIを通じてseachUsers操作を実行する場合、正常にその操作を実行するには、AttributeFilter.OP_EQUALS演算子を指定する必要があります。

3.4 ArisID Beanの生成

CARMLファイルの編集が終了したら、アプリケーションで使用するArisID Beanを生成できます。ArisID Beanは、関連する様々な処理メソッドを持ち、ArisID APIの上位レイヤーとなるJava APIを提供します。

ArisID Beanを生成するには、次のコマンドを実行します:

java BeanGenerator [-genmap] <package name> <output dir> [<relationship file>] <carml file>

ここで、

- -genmapは、CARMLファイルと同じ場所にCARML-ArisIDStackマップ・ファイルを生成します。

- package nameは、生成されたBeanクラスのパッケージ名です。

- output dirは、生成されたBeanクラスの書込み先です。

- relationship fileは、エンティティ間のリレーションシップ定義を含むファイルです。

- carml fileは、CARML宣言ファイルです。

CARMLファイルからORG Beanをビルドする手順は次のとおりです。

1. ORGエンティティ用の適切な属性または相互作用を指定する、CARMLファイル名org.xmlを作成します。

2. Beanジェネレータを使用して、org Bean(OrgManager.javaおよびOrg.java)を生成します。build.xmlファイルの内容は、次のサンプルのようになります。

<path id="ArisIDBeans.classpath">
<pathelement location="MW_HOME/oracle_common/modules/velocity-dep-1.4.jar" />
<pathelement location="MW_HOME/oracle_common/modules/oracle.jrf_11.1.1/jrf.jar" />
</path>
<property name="BeanGeneratorClassPath" refid="ArisIDBeans.classpath"/>
<target name="generatebeans" description="generate arisid beans">
<java classname="org.openliberty.arisidbeans.BeanGenerator" dir="${generatedsource.dir}" fork="true">
<arg value="${generatedbean.userrole.packagename}"/>
<arg value="."/>
<arg value="${carml.dir}/org.xml"/>
<classpath>
<pathelement path="${BeanGeneratorClassPath}"/>
</classpath>
<sysproperty key="org.openliberty.arisid.policy.wspolicy.class"
value="org.openliberty.arisid.policy.neethi.PolicyImpl" />
</java>
</target>

3. 生成されたJavaファイル(Org.javaおよびOrgManager.java)をコンパイルします。

4. 生成されたマッピング・ファイル(igf-map-config-.xml)を編集して、basesearch、objectclass、OVD属性名でそれぞれの値を更新します。

5. アプリケーションでは、CARMLファイル(org.xml)に定義されている相互作用用の生成されたORG APIを使用できます。アプリケーションをアプリケーション・サーバーにデプロイした後で、次の作業を行います。

a. マッピング・ファイルをDOMAIN_HOME/config/fmwconfig/arisidprovider/confにコピーします。

b. CARMLファイルをDOMAIN_HOME/config/fmwconfig/carmlにコピーします。

3.5 IDXユーザーおよびロールBeanの使用例

IDXユーザー/ロールBeanの使用方法を理解することが重要です。IDXユーザー/ロールBeanをアプリケーションに統合する方法を理解するには、次のサンプル・アプリケーションを使用します。

次の各トピックで、IDXユーザー/ロールBeanの使用について説明します。

- IDXユーザーおよびロールBeanを使用したユーザーの検索: SearchUsers.jsp

- IDXユーザーおよびロールBeanを使用したユーザーの検索: SearchUsers.html

3.5.1 IDXユーザーおよびロールBeanを使用したユーザーの検索: SearchUsers.jsp

IDXユーザー/ロールBean Javaバージョンを使用してユーザーを検索します。

<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<%@page import="org.openliberty.arisid.*"%>
<%@page import="org.openliberty.arisidbeans.*"%>
<%@page import="oracle.igf.userrole.*"%>
<%@page import="java.util.*"%>
<%@page import="java.net.URI"%>
<%!public static UserManager uMgr = null;
{
try {
uMgr = new UserManager(null);
} catch (Exception e) {
e.printStackTrace();
}

}
%>
<html>
<head>
<title>Search Users</title>
<%

String firstname = request.getParameter("firstname");
String lastname = request.getParameter("lastname");
String telephone = request.getParameter("telephone");

List<PropertyFilterValue> attrFilters = new ArrayList<PropertyFilterValue>();
attrFilters.add(new PropertyFilterValue("firstname", firstname, AttributeFilter.OP_BGNSWITH));
attrFilters.add(new PropertyFilterValue("lastname", lastname, AttributeFilter.OP_BGNSWITH));
attrFilters.add(new PropertyFilterValue("telephone", telephone, AttributeFilter.OP_CONTAINS));

List<User> subjs = uMgr.searchUsers(attrFilters);

%>
</head>
<body>

<a href="SearchUsers.html">Home</a>
<center>List of Users with FirstName starting with "<%=firstname%>", LastName
starting with "<%=lastname%>" and TelephoneNumber containing
"<%=telephone%>"</center>

<%
Iterator<User> sIter = subjs.iterator();
while (sIter.hasNext()) {
User subj = sIter.next();

Map<String, IAttributeValue> vals = subj.getAllAttributes();
Iterator<IAttributeValue> iter = vals.values().iterator();
%>
<table border="0">
<tr>
<th>Item</th>
<th>Value</th>
</tr>
<%
while (iter.hasNext()) {
IAttributeValue val = iter.next();
String name = val.getNameIdRef();
String value = null;
if (val.size() > 0)
value = val.get(0);
if (value != null)
{
%>
<tr>
<td><%=name%></td>
<td><%=value%></td>
</tr>
<%
}
}
%>
</table>
<%
}
%>
<br>
<br>
<br>
<a href="SearchUsers.html">Home</a>
</body>
</html>

3.5.2 IDXユーザーおよびロールBeanを使用したユーザーの検索: SearchUsers.html

IDXユーザー/ロールBeanコードを使用してユーザーを検索します。

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD><TITLE>Search Users</TITLE></HEAD>
<BODY>
<FORM METHOD=POST ACTION="SearchUsers.jsp">

First Name Starting with <INPUT TYPE=TEXT NAME=firstname SIZE=30><BR><BR>
Last Name Starting with <INPUT TYPE=TEXT NAME=lastname SIZE=30><BR><BR>
Telephone Number containing <INPUT TYPE=TEXT NAME=telephone SIZE=15><BR><BR>
<P><INPUT TYPE=SUBMIT>
</FORM>
</BODY>
</HTML>

3.6 OpenLDAPに関する考慮事項について

OpenLDAPでは、APIを実装するために必須の属性をいくつか指定します。アプリケーションを実装するとき、これらの属性を考慮しておく必要があります。

OpenLDAPの場合、Role.MEMBERは次のAPIに必須の属性です。

- createRole(List<PropertyValue> attrVals, Map<String,Object> appCtxMap)

- createRole(List<PropertyValue> attrVals)

入力attrValsリストにRole.MEMBERが含まれていない場合、ロールの作成は失敗します。

4 アイデンティティ・ディレクトリAPIへの移行

ユーザーおよびロールAPIからアイデンティティ・ディレクトリAPIにアプリケーションを移行する方法を理解するには、次の各トピックを使用します。

- アイデンティティ・ディレクトリAPIへの移行の概要

- アイデンティティ・ディレクトリAPIへのアプリケーションの移行

- ユーザーおよびロールAPIとIDS APIとの比較について

- テスト環境から本番環境への移行

- IDSの構成パラメータのチューニング

- IDSでのパススルー属性の許可

4.1 アイデンティティ・ディレクトリAPIへの移行の概要

アイデンティティ・ディレクトリAPIを使用すると、アプリケーションは、統一的で移植可能な方法でアイデンティティ情報(ユーザーやその他のエンティティ)にアクセスすることができます。ユーザーおよびロールAPIを使用するアプリケーションの場合は、それを移行してアイデンティティ・ディレクトリAPIを使用できます。

アイデンティティ・ディレクトリAPIは、jps-configファイルからLDAPベースのアイデンティティ・ストアの確認を取得します。したがって、ユーザーおよびロールAPIからアイデンティティ・ディレクトリAPIにアプリケーションを移行する際、jps-configファイルの構成を変更する必要はありません。

ユーザーおよびロールAPIをプログラム的な構成で初期化するアプリケーションは、類似のメソッドを使用して、アイデンティティ・ディレクトリAPIを初期化できます。詳細は、メモリー内アイデンティティ・ディレクトリ・ハンドルの初期化と取得を参照してください。

4.2 アイデンティティ・ディレクトリAPIへのアプリケーションの移行

ユーザーおよびロールAPIからアイデンティティ・ディレクトリAPIにアプリケーションを移行するときは、一部のコード変更を実行する必要があります。

次の各トピックで、移行時に必要なコード変更について説明します。

- APIの初期化

- UserManagerおよびGroupManagerのハンドルの取得

- 検索フィルタ

- CRUD操作の実行

4.2.1 APIの初期化

アイデンティティ・ディレクトリ・ハンドルを取得するには、すべてのアプリケーションでAPIを初期化する必要があります。プログラムでは、初期化を1回だけ実行する必要があります。APIを初期化するには、次のサンプル・コードを使用します。

初期化のプロセスは、IdentityStoreService.GetIdmStore()を使用してoracle.security.idm.IdentityStoreハンドルを取得する方法に類似しています。アイデンティティ・ディレクトリ・サービスは、IdentityStoreService.getIdentityStore()を使用してIdentityDirectoryハンドルを取得します。次に例を示します。

import oracle.igf.ids.IdentityDirectory;
import oracle.igf.ids.IDSException;
import oracle.security.jps.JpsContext;
import oracle.security.jps.JpsContextFactory;
import oracle.security.jps.service.idstore.IdentityStoreService;

// Get IdentityDirectory from JpsContext
JpsContext context = JpsContextFactory.getContextFactory().getContext();
IdentityStoreService idstore = (IdentityStoreService)
context.getServiceInstance(IdentityStoreService.class);
Identity Directory ids = idstore.getIdentityStore();

4.2.2 UserManagerおよびGroupManagerのハンドルの取得

ユーザー・インスタンスに対するすべての操作はユーザー・マネージャによって処理され、グループに対するすべての操作はグループ・マネージャによって処理されます。サンプル・コードを使用して、ユーザーおよびグループの各インスタンスに対してCRUD操作を実行します。

ユーザー関連のCRUD操作はoracle.igf.ids.UserManagerを使用して、ロール関連のCRUD操作はoracle.igf.ids.GroupManagerを使用して実行できます。UserManagerおよびGroupManagerのハンドルは、IdentityDirectoryオブジェクトから取得できます。次に例を示します。

import oracle.igf.ids.UserManager;
import oracle.igf.ids.GroupManager;

// Get UserManager and GroupManager handles
UserManager uMgr = ids.getUserManager();
GroupManager gMgr = ids.getGroupManager();

4.2.3 検索フィルタ

アイデンティティ・リポジトリを検索するときは、単純な検索フィルタも複雑な検索フィルタも作成できます。サンプル・コードを使用すると、様々な検索操作を容易に実行できます。

oracle.igf.ids.SearchFilterを使用して、簡易検索フィルタまたは複雑な検索フィルタを作成できます。次に例を示します。

import oracle.igf.ids.SearchFilter;

// Simple search filter for (firstname equals "john")

SearchFilter filter1 = new SearchFilter("firstname",
SearchFilter.Operator.EQUALS, "john");

// Complex search filter for
((title contains "manager") and (org equals "amer")) or
((title contains "senior manager") and (org equals "apac"))

SearchFilter filter = new SearchFilter(
SearchFilter.LogicalOp.OR,
new SearchFilter(SearchFilter.LogicalOp.AND,
new SearchFilter("manager", SearchFilter.Operator.CONTAINS,
"manager"),
new SearchFilter("org", SearchFilter.Operator.EQUALS, "amer")),
new SearchFilter(SearchFilter.LogicalOp.AND,
new SearchFilter("manager", SearchFilter.Operator.CONTAINS,
"senior manager"),
new SearchFilter("org", SearchFilter.Operator.EQUALS, "apac")));

4.2.4 CRUD操作の実行

ユーザー、グループ、組織のエンティティおよび汎用エンティティに対する作成/読取り/更新/削除(CRUD)操作を実行できます。このため、アプリケーションで使用するCRUD APIを実装する必要があります。

次の各トピックで、これらのCRUD操作について説明します。

- ユーザーを見つけるAPI

- ユーザーを検索するAPI

- ユーザーを作成するAPI

- ユーザーを削除するAPI

- ユーザーを認証するAPI

- ユーザーを変更するAPIと関連エンティティを管理するAPI

4.2.4.1 ユーザーを見つけるAPI

ユーザーの検索に使用されるAPIを次に示します。

- 指定されたprincipal識別子のユーザーを取得します。次に例を示します。

User getUser(Principal principal, ReadOptions opts)

- ユーザーを一意に識別する、指定されたid属性値と一致するユーザーを検索します。次に例を示します。

User searchUser(String id, ReadOptions opts)

- 指定された属性の名前および値と一致するユーザーを検索します。次に例を示します。

User searchUser(String attrName, String attrVal, ReadOptions opts)

- ユーザーを一意に識別する、指定されたGUID値と一致するユーザーを検索します。次に例を示します。

searchUserByGuid(String guid, ReadOptions opts)

4.2.4.2 ユーザーを検索するAPI

ユーザーを検索するAPIの例を次に示します。

ResultSet<User> searchUsers(SearchFilter filter, SearchOptions opts)

4.2.4.3 ユーザーを作成するAPI

APIを使用してユーザーを作成できます。

ユーザーを作成するAPIの例を次に示します。

Principal createUser(List<Attribute> attrVals, CreateOptions opts)

4.2.4.4 ユーザーを削除するAPI

APIを使用してユーザーを削除できます。

ユーザーを削除するAPIの例を次に示します。

- 指定されたprincipal識別子のユーザーを削除します。

void deleteUser(Principal principal, DeleteOptions opts)

- 指定されたid属性値のユーザーを削除します。

void deleteUser(String id, DeleteOptions opts)

4.2.4.5 ユーザーを認証するAPI

APIによるユーザー認証は、一般的なメカニズムです。

ユーザーを認証するAPIの例を次に示します。

- 指定されたid属性値と一致するユーザーを認証します。

User authenticateUser(String id, char[] password, ReadOptions opts)

- 指定されたprincipal識別子のユーザーを認証します。

boolean authenticateUser(Principal principal, char[] password)

4.2.4.6 ユーザーを変更するAPIと関連エンティティを管理するAPI

ユーザー属性を変更するAPIおよびその関連エンティティを取得するAPIは、UserManagerではなくUserオブジェクトにあります。

ユーザーの変更

ユーザーを変更するAPIの例を次に示します。

- ユーザーの属性を変更します。

void User.modify(List<ModAttribute> attrVals, ModifyOptions opts)

- ユーザーの属性値を設定します。

void User.setAttributeValue(String attrName, String attrVal, ModifyOptions opts)

関連エンティティの管理

エンティティを管理するAPIの例を次に示します。

- 管理チェーンを取得します。

ResultSet<User> getManagementChain(int nLevels, SearchOptions opts)

- 指定されたユーザーがこのユーザーの管理者であるかどうかを確認します。

boolean isManager(User user, boolean direct, ReadOptions opts)

- 指定されたユーザーがこのユーザーの管理者であるかどうかを確認します。

boolean isManager(User user, boolean direct, ReadOptions opts)

- 指定されたユーザーをこのユーザーの管理者として設定します。

void setManager(User user, ModifyOptions opts)

- このユーザーのReporteeをすべて取得します。

ResultSet<User> getReportees(int nLevels,
SearchFilter targetFilter, SearchOptions opts)

- このユーザーがメンバーとして属している、指定されたフィルタ基準と一致するグループをすべて取得します。

ResultSet<Group> getMemberOfGroups(int
nLevels, SearchFilter targetFilter, SearchOptions opts)

- このユーザーが指定されたグループのメンバーであるかどうかを確認します。

boolean isMemberOf(Group group, boolean direct, ReadOptions opts)

- 指定されたグループのメンバーとしてこのユーザーを追加します。

void addMemberOf(Group group, ModifyOptions opts)

- 指定されたグループのメンバーからこのユーザーを削除します。

void deleteMemberOf(Group group, ModifyOptions opts)

4.3 ユーザーおよびロールAPIとIDS APIとの比較について

変更をアプリケーションで実装する前に、ユーザーおよびロールAPIと、アイデンティティ・ディレクトリAPIとの間の対応を理解することが不可欠です。

次の各トピックで、これらの違いについて説明します。

- ユーザー関連APIとアイデンティティ・ディレクトリAPIとの比較

- ロール関連APIとアイデンティティ・ディレクトリAPIとの比較

4.3.1 ユーザー関連APIとアイデンティティ・ディレクトリAPIとの比較

ユーザーAPIのエンドポイントと、アイデンティティ・ディレクトリAPIのエンドポイントの間の対応を理解する必要があります。

次の表に、ユーザー関連APIのメソッドと、それに対応するアイデンティティ・ディレクトリAPIのメソッドとの対応を示します。

機能

ユーザー/ロールAPIのメソッド

Identity Directory Serviceのメソッド

ユーザーの作成

User UserManager.createUser(String name, char[] password)

User UserManager.createUser(String name, char[] password, PropertySet pset)

Principal UserManager.createUser(List<Attribute> attrVals, CreateOptions opts)

ユーザーの削除

void UserManager.dropUser(UserProfile user)

void UserManager.dropUser(User user);

void UserManager.deleteUser(Principal principal, DeleteOptions opts)

void UserManager.deleteUser(String id, DeleteOptions opts)

ユーザーの認証

User UserManager.authenticateUser(String user_id, char[] passwd)

User UserManager.authenticateUser(User user, char[] passwd)

User UserManager.authenticateUser(String user_id, String authProperty, char[] passwd)

User UserManager.authenticateUser(String id, char[] password, ReadOptions opts)

boolean UserManager.authenticateUser(Principal principal, char[] password)

ユーザーの作成がサポートされているかどうかのチェック

boolean UserManager.isCreateUserSupported()

boolean UserManager.getCapabilities().isCreateCapable()

ユーザーの変更がサポートされているかどうかのチェック

boolean UserManager.isModifyUserSupported()

boolean UserManager.getCapabilities().isUpdateCapable()

ユーザーの削除がサポートされているかどうかのチェック

boolean UserManager.isDropUserSupported()

boolean UserManager.getCapabilities().isDeleteCapable()

指定された検索基準によるユーザーの検索

SearchResponse IdentityStore.searchUsers(SearchParameters params)

ResultSet<User> UserManager.searchUsers(SearchFilter filter, SearchOptions opts)

名前/一意の名前/guidによるユーザーの検索

User IdentityStore.searchUser(String name)

User UserManager.searchUser(String id, ReadOptions opts)

User UserManager.searchUser(String attrName, String attrVal, ReadOptions opts)

特定のユーザー・オブジェクトのリポジトリにユーザーが存在するかどうかのチェック

boolean IdentityStore.exists (User user)

User.getPrincipal() 次のメソッドがnullを返す場合、ユーザーは存在しません。それ以外の場合は存在します。

User getUser(Principal principal, ReadOptions opts)

単純な検索フィルタ(1つの名前、タイプおよび値に基づいた検索)

SimpleSearchFilter

SearchFilter(String propertyName, Operator op, String propertyVal)

複雑な検索フィルタ(フィルタ条件とネストしたフィルタを使用した複数の属性に基づいた検索)

ComplextSearchFilter

SearchFilter(LogicalOp op, SearchFilter... searchFilters)

指定されたプロパティ名に対するプロパティ値の取得

String User.getPropertyVal(String propName)

ユーザー・ロールAPIはキャッシュから属性値をフェッチします。キャッシュにない場合、リポジトリからフェッチします。

String User.getAttributeValue(String attrName)

制限: リポジトリからすでにフェッチされているユーザー・オブジェクトから属性値を返します。

指定されたプロパティ名に対するユーザー・プロパティの取得

Property User.getProperty(String propName)

Attribute User.getAttribute(String attrName)

指定されたプロパティ名のセットに対するユーザー・プロパティの取得

Map User.getProperties()

Map<String, Attribute> User.getAllAttributes()

ユーザーのリポジトリからユーザー・プロパティをすべて取得します。

PropertySet User.getAllUserProperties()

Map<String, Attribute> User.getAllAttributes()

すべてのユーザー・プロパティ名のスキーマからの取得

List IdentityStore.getUserPropertyNames()

スキーマ内にあるすべてのプロパティの名前を返します。

List<String> UserManager.getEntityAttributes()

ユーザーのリポジトリ内の属性値の変更

void User.setProperty(ModProperty mprop)

void User.setAttributeValue(String attrName, String attrVal, ModifyOptions opts)

ユーザーのリポジトリ内の属性値のセットの変更

void User.setProperties(ModProperty[] modPropObjs)

void User.setProperties(LdapContext ctx, ModProperty[] modPropObjs)

void User.modify(List<ModAttribute> attrVals, ModifyOptions opts)

ユーザーの直接または間接のすべてのReporteeを取得します。

SearchResponse User.getReportees(boolean direct)

ResultSet<User> User.getReportees(int nLevels, SearchFilter targetFilter, SearchOptions opts)

ユーザーの管理チェーンの取得

List User.getManagementChain(int max, String upToManagerName, String upToTitle)

ResultSet<User> User.getManagementChain(int nLevels, SearchOptions opts)

List<User> User.getManagementChain(int nLevels, String manager, String title, SearchOptions opts)

バイナリ属性の取得/設定

使用可能

ユーザー/ロールAPIのプロパティでは、バイナリ属性がサポートされます。

byte[] user.getJPEGPhoto()

void user.setJPEGPhoto(String imgpath)

Base64でエンコードした値を返します。

値を設定する際、ModAttributeを作成するには、Base64でエンコードした値またはbyte[]を使用できます。

レルムの選択

使用可能

env.put(OIDIdentityStoreFactory.RT_SUBSCRIBER_NAME, "<realm dn>");

IdentityStoreFactory.getIdentityStoreInstance(env);

これは、IDSオペレーション構成の一部です。APIレベルでは、searchbaseおよびcreatebaseは同様に指定できます。

4.3.2 ロール関連APIとアイデンティティ・ディレクトリAPIとの比較

ユーザー/ロールAPIのエンドポイントと、アイデンティティ・ディレクトリAPIのエンドポイントの間の対応を理解する必要があります。

次の表に、ロール関連APIのメソッドと、それに対応するアイデンティティ・ディレクトリAPIのメソッドとの対応を示します。

機能

ユーザー/ロールAPIのメソッド

Identity Directory Serviceのメソッド

ロールの作成

Role RoleManager.createRole(String name, int scope)

Role RoleManager.createRole(String name)

Principal GroupManager.createGroup(List<Attribute> attrVals, CreateOptions opts)

ロールの削除

void RoleManager.dropRole(RoleProfile role)

void RoleManager.dropRole(Role role)

void GroupManager.deleteGroup(Principal principal, DeleteOptions opts)

ロールの作成がサポートされているかどうかのチェック

boolean RoleManager.isCreateRoleSupported()

boolean GroupManager.getCapabilities().isCreateCapable()

ロールの変更がサポートされているかどうかのチェック

boolean RoleManager.isModifyRoleSupported()

boolean GroupManager.getCapabilities().isUpdateCapable()

ロールの削除がサポートされているかどうかのチェック

boolean RoleManager.isDropRoleSupported()

boolean GroupManager.getCapabilities().isDeleteCapable()

グループがユーザーによって所有されているか

boolean RoleManager.isGranted(Role parent, Principal principal)

boolean Group.isMember(User user, boolean direct, ReadOptions opts)

boolean User.isMemberOf(Group group, boolean direct, ReadOptions opts)

グループがユーザーによって所有されているか

boolean RoleManager.isOwnedBy(Role parent, Principal principal)

boolean User.isOwnerOf(Group group, boolean direct, ReadOptions opts)

グループがユーザーによって管理されているか

boolean RoleManager.isManagedBy(Role parent, Principal principal)

サポートされていません

ロールの直接または間接のすべてのメンバーの取得

SearchResponse Role.getGrantees(SearchFilter filter, boolean direct)

ResultSet<User> Group.getMembers(int nLevels, SearchFilter targetFilter, SearchOptions opts)

ユーザーをメンバーとしてロールに追加します。

void RoleManager.grantRole(Role parent, Principal principal)

void Group.addMember(User user, ModifyOptions opts)

ロールのメンバーからユーザーを削除

void RoleManager.revokeRole(Role parent, Principal principal)

void Group.deleteMember(User user, ModifyOptions opts)

特定のロールの直接または間接のすべての所有者の取得

SearchResponse Role.getOwners(SearchFilter filter, boolean direct)

SearchResponse Role.getOwners(SearchFilter filter)

ResultSet<User> Group.getOwners(int nLevels, SearchFilter targetFilter, SearchOptions opts)

ユーザーを所有者としてロールに追加

void Role.addOwner(Principal principal)

void Group.addOwner(User user, ModifyOptions opts)

ロールの所有者からユーザーを削除

void Role.removeOwner(Principal principal)

void Group.deleteOwner(User user, ModifyOptions opts)

ロールの直接または間接のすべての管理者の取得

SearchResponse Role.getManagers(SearchFilter filter, boolean direct)

SearchResponse Role.getManagers(SearchFilter filter)

サポートされていません

ユーザーをロールの管理者として追加します。

void Role.addManager(Principal principal)

サポートされていません

ロールの管理者からユーザーを削除します。

void Role.removeManager(Principal principal)

サポートされていません

ロールのプロパティの取得

Property Role.getProperty(String propName)

注意: ユーザー・ロールAPIはキャッシュからこれらの属性値をフェッチします。キャッシュにない場合、リポジトリからフェッチします。

Attribute Group.getAttribute(String attrName)

ロール・タイプの確認

Role.isApplicationRole

Role.isEnterpriseRole

Role.isSeeded

サポートされていません

指定された検索基準に対するロールの検索

SearchResponse IdentityStore.searchRoles(int scope, SearchParameters params)

ResultSet<Group> GroupManager.searchGroups(SearchFilter filter, SearchOptions opts)

名前/一意の名前/guidによるロールの検索

Role IdentityStore.searchRole(int searchType, String value)

Group searchGroup(String id, ReadOptions opts)

Group searchGroup(String attrName, String attrVal, ReadOptions opts)

指定されたフィルタに対するユーザーとロールの検索

SearchResponse IdentityStore.search(SearchParameters params)

次の異なるメソッドを使用できます。

UserManager.searchUsers

GroupManager.searchGroups

ユーザー/グループに割り当てられたすべてのロールを取得します。

SearchResponse getGrantedRoles(Principal principal, boolean direct)

ResultSet<Group> User.getMemberOfGroups(int nLevels, SearchFilter targetFilter, SearchOptions opts)

ResultSet<Group> Group.getMemberOfGroups(int nLevels, SearchFilter targetFilter, SearchOptions opts)

ユーザー/グループが所有しているすべてのロールを取得します。

SearchResponse getOwnedRoles(Principal principal, boolean direct)

ResultSet<Group> User.getOwnedGroups(int nLevels, SearchFilter targetFilter, SearchOptions opts)

ResultSet<Group> Group.getOwnedGroups(int nLevels, SearchFilter targetFilter, SearchOptions opts)

ユーザー/グループが管理しているすべてのロールを取得します。

SearchResponse getManagedRoles(Principal principal, boolean direct)

サポートされていません

4.4 テスト環境から本番環境への移行

ある環境から別の環境への移行、特にテスト環境から本番環境への移行では、アプリケーションをテスト環境で柔軟にテストしてから本番環境にロール・アウトできます。

次の各トピックで、テスト環境から本番環境への移行中に変更する必要があるIdentity Directory Service/libOVDのプロパティについて説明します。

- 環境間の移行の概要

- Identity Directory Service/libOVDの移動計画の変更

4.4.1 環境間の移行の概要

Identity Directory Service/libOVDを新しい環境に、またはテストから本番環境に移動できます。Identity Directory Service/libOVDインストールを移動することによって、元の環境で行ったすべてのカスタマイズおよび構成変更を別の環境に再適用するために必要な作業量が削減されます。

テスト環境で、Identity Directory Service/libOVDのインストール、構成、カスタマイズおよび検証を実行できます。システムが安定し、必要に応じて機能するようになったら、本番環境を作成しますが、このとき、テスト環境に取り込んだすべての変更内容を再実行するかわりに、サーバーとその構成のコピーをテスト環境から移行することで本番環境を作成できます。

4.4.2 Identity Directory Service/libOVDの移動計画の変更

移動計画には、ソース環境の構成設定が含まれます。Oracle Fusion Middlewareエンティティおよびコンポーネントについて、移動計画の設定をカスタマイズできます。

環境間で移行する場合、extractMovePlanスクリプトを実行して、移動するエンティティの移動計画を作成します。extractMovePlanスクリプトは、構成情報をアーカイブから移動計画に抽出します。また、必要な構成計画もすべて抽出します。アーカイブをターゲットに適用する前に、ターゲット環境の値を反映するように、移動計画を編集する必要があります。

READ_WRITEのスコープのプロパティを変更できます。READ_ONLYのスコープのプロパティは変更しないでください。環境間の移行に関する包括的な説明および準拠する手順については、Oracle Fusion Middlewareの管理で、ターゲット環境への移動の一般手順を参照してください。

この項では、次の項目について説明します。

- Identity Directory Service/libOVD configGroup要素の場所の特定

- Identity Directory Service/libOVDの移動計画に関してカスタマイズするプロパティ

4.4.2.1 Identity Directory Service/libOVD configGroup要素の場所の特定

移動計画には、通常、複数のconfigGroup要素が含まれます。特定のconfigGroup要素に関連付けられるプロパティについて、一覧表にconfigGroup要素ごとのプロパティがまとめています。

生成された移動計画でIdentity Directory Service/libOVD ConfigGroupの場所を特定するには、<type>LIBOVD_ADAPTERS</type>を検索する必要があります。このタグによって、状況により更新する必要のあるlibOVDアダプタ・プロパティの包括的な情報が提供されます。プロパティは、特定のconfigGroup要素に関連付けられます。

各アダプタは、次の形式のconfigProperty IDタグによって表されます。

"LDAP:<context_name>:<adapter_name>"

"LDAP:ids:myOID"という例について検討します。

表4-1は、libOVDの移動計画のプロパティを示しています。

次の例は、LIBOVD_ADAPTERS configGroup要素の一部が含まれた、Identity Directory Service/libOVDの移動計画のセクションを示しています。

<configGroup>
<type>LIBOVD_ADAPTERS</type>
<configProperty id="LDAP:ids:myOID">
<configProperty>
<name>Context Name</name>
<value>ids</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_ONLY</scope>
</itemMetadata>
</configProperty>
<configProperty>
<name>Adapter Name</name>
<value>myOID</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_ONLY</scope>
</itemMetadata>
</configProperty>
<configProperty>
<name>LDAP URL</name>
<value>ldap://hostname:1389</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
<configProperty>
<name>LDAP Host Read Only</name>
<value>false</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
<configProperty>
<name>LDAP Host Percentage</name>
<value>100</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
<configProperty>
<name>DN</name>
<value>cn=orcladmin</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
<configProperty>
<name>Password File</name>
<value/>
<itemMetadata>
<dataType>STRING</dataType>
<password>true</password>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
</configProperty>
</configGroup>

4.4.2.2 Identity Directory Service/libOVDの移動計画に関してカスタマイズするプロパティ

移動計画のプロパティをカスタマイズできます。

表4-1では、Identity Directory Service/libOVDアダプタに関してカスタマイズできる移動計画のプロパティについて説明します。

表4-1 libOVDの移動計画のプロパティ

プロパティ

説明

サンプル値

コンテキスト名

アダプタに関連付けられた、使用するlibOVDコンテキスト。

これは読取り専用プロパティです。

ids

アダプタ名

アダプタの名前です。これは読取り専用プロパティです。

myOID

LDAP URL

ldap://host:portという形式のアダプタのLDAP URL値。これは読取り/書込みプロパティです。

ldap://slc05kym:1389

DN

バックエンドLDAPに接続するユーザーのDN。これは読取り/書込みプロパティです。

cn=orcladmin

パスワード・ファイル

ユーザーのパスワードが含まれるセキュア・ファイルの絶対パス。これは読取り/書込みプロパティです。

/tmp/p.txt

LDAPホスト読取り専用

特定のホストが読取り専用かどうかを示すフラグ。デフォルト値はfalseです。これは読取り/書込みプロパティです。

false

LDAPホストの割合

特定のLADAPホストの負荷割合の値を指定します。デフォルト値は100です。これは読取り/書込みプロパティです。

100

4.5 IDSの構成パラメータのチューニング

チューニングは、特定のデプロイメント要件を満たすためのパラメータの調整または変更です。デフォルトIDS構成は、デプロイメント・シナリオ用にチューニングされている必要があります。

この項に記載されている要件と推奨事項を十分に確認する必要があります。

この項では、次の項目について説明します。

- IDSの構成パラメータ

- ファイルベース構成を使用してチューニング・パラメータを設定するためのWLSTコマンド

- インメモリー構成を使用してチューニング・パラメータを設定するためのWLSTコマンド

- ファイアウォールおよびロード・バランサのタイムアウト・エラーの処理

4.5.1 IDSの構成パラメータ

構成パラメータを使用してパフォーマンスをチューニングし、リアルタイム・デプロイメントのシナリオに必要なメモリー要件のバランスをとることができます。要件に基づいてこれらのパラメータをチューニングすると、アプリケーションのスケーラビリティ特性が大きく向上します。

表4-2に、IDSの実デプロイメント・シナリオでチューニングを必要とする構成パラメータをリストします。

表4-2 IDSの構成パラメータ

パラメータ

説明

InitialPoolSize

LDAP接続プールが設定されているときに作成されるLDAP接続の初期数。

MaxPoolSize

LDAP接続プールで使用できるLDAP接続の最大数。

注意: デプロイメントが多くのコンカレント・リクエストを受信し続けている場合、接続が不足したり操作中に接続を待機したりすることを防ぐために、この値を適切に設定する必要があります。

MaxPoolWait

MaxPoolChecks

これらのパラメータは、接続プール内のすべてのLDAP接続が使用中の場合にLDAP接続が空くまでの待ち時間を決定します。IDSは、まず空き接続が使用可能になるまでMAX_POOLWAITとMAX_POOLCHECKSミリ秒待ち、次に接続プールを拡張しようとします。

PoolCleanupInterval

これは、LDAP接続プール・クリーンアップ・タイマーによって使用されるタイマー間隔(秒)です。LDAP接続プール・クリーンアップ・タイマーはこのタイマー間隔を使用して動作し、プール・クリーンアップ・タスク(必要に応じてアイドル接続に基づいた接続プールを縮小するなど)を実行します。

MaxPoolConnectionIdleTime

これは、LDAP接続の最大アイドル時間を指定します。指定された時間アイドルになっているLDAP接続では、次のLDAP接続プール・クリーンアップ・タイマーが実行されるとクローズされます。

OperationTimeout

LDAPリクエストがLDAPリモート・ホストによって承認されるのをIDSが待機する時間(ミリ秒単位)。

ConnectTimeout

これは、LDAP接続のタイムアウト期間をミリ秒数で指定します。この期間内に接続を確立できない場合は、接続の試行が中断されます。

HeartbeatInterval

これは、バックエンドLDAPが使用できるかを確認する間隔(秒)です。

SocketOptions

このパラメータは、LDAP接続で基盤になるJNDIソケットのSO_TIMEOUT (秒)、SO_REUSEADDR、TCP_NODELAY、SO_KEEPALIVEプロパティを設定します。

MaxPoolConnectionReuseTime

これは、プールが接続を閉じて削除するまでに接続を再利用できる最大回数を指定します。値は秒数で指定します。

PoolConnectionReclaimTime

これは、流用された接続が使用されない場合に自動的にプールに戻されるまでの期間(秒数)を指定します。

Protocols

これは、IDSでサポートされているプロトコル・バージョンを指定します。

4.5.2 ファイルベース構成を使用してチューニング・パラメータを設定するためのWLSTコマンド

構成情報はXMLファイルに格納されます。ファイルベース構成を使用してパラメータをチューニングするには、WebLogic Scripting Tool (WLST)を使用する必要があります。

チューニング・パラメータを構成するには、次のWLSTコマンドを使用します。

注意:

この項のすべてのWLSTコマンド例で、ADAPTER_NAMEはIDSリポジトリの名前を参照します。たとえば、libOVDアダプタ名です。

- InitialPoolSizeの場合:

modifyLDAPAdapter(adapterName='ADAPTER_NAME', attribute='InitialPoolSize', value=10, contextName='ids')

- MaxPoolSizeの場合:

modifyLDAPAdapter(adapterName='ADAPTER_NAME', attribute='MaxPoolSize', value=100, contextName='ids')

- MaxPoolWaitおよびMaxPoolCheckの場合:

modifyLDAPAdapter(adapterName='ADAPTER_NAME', attribute='MaxPoolWait', value=1000, contextName='ids')

modifyLDAPAdapter(adapterName='ADAPTER_NAME', attribute='MaxPoolChecks', value=10, contextName='ids')

- PoolCleanupIntervalの場合:

modifyLDAPAdapter(adapterName='ADAPTER_NAME', attribute='PoolCleanupInterval', value=300, contextName='ids')

- MaxPoolConnectionIdleTimeの場合:

modifyLDAPAdapter(adapterName='ADAPTER_NAME', attribute='MaxPoolConnectionIdleTime', value=3600, contextName='ids')

- OperationTimeoutの場合:

modifyLDAPAdapter(adapterName='ADAPTER_NAME', attribute='OperationTimeout', value=120000, contextName='ids')

- ConnectTimeoutの場合

modifyLDAPAdapter(adapterName='ADAPTER_NAME', attribute='ConnectTimeout', value=10000, contextName='ids')

- HeartbeatIntervalの場合:

modifyLDAPAdapter(adapterName='ADAPTER_NAME', attribute='HeartBeatInterval', value=60, contextName='ids')

- SocketOptionの場合:

modifySocketOptions(adapterName='ADAPTER_NAME', reuseAddress=false, keepAlive=false, tcpNoDelay=true, readTimeout=1800, contextName='ids')

- MaxPoolConnectionReuseTimeの場合

modifyLDAPAdapter(adapterName='ADAPTER_NAME', attribute='MaxPoolConnectionReuseTime', value=3600, contextName='ids')

- PoolConnectionReclaimTimeの場合

modifyLDAPAdapter(adapterName='ADAPTER_NAME', attribute='PoolConnectionReclaimTime', value=180, contextName='ids')

- Protocolsの場合

modifyLDAPAdapter(adapterName='ADAPTER_NAME', attribute='Protocols', value='TLSv1.2', contextName='ids')

注意:

構成変更を反映するには、activateLibOVDConfigChanges('ids') WLSTコマンドを実行するか、WebLogicサーバーを再起動する必要があります。

4.5.3 インメモリー構成を使用してチューニング・パラメータを設定するためのWLSTコマンド

インメモリー構成を使用してチューニング・パラメータを構成するには、WLSTコマンドを使用します。

構成情報はIDSコンシューマによって格納され、IdentityStoreConfigクラスを起動することで、実行時にIDSに渡されます。クラスとそのプロパティの使用に関する詳細は、Oracle Fusion Middleware Identity Governance Framework Identity Directory Java APIリファレンスを参照してください。

Java APIクラスを使用して、次の構成パラメータを変更できます。

表4-3 構成パラメータのフィールド名

パラメータ

変更するフィールド名

InitialPoolSize

IdentityStoreConfig.INITIAL_POOLSIZE

MaxPoolSize

IdentityStoreConfig.MAX_POOLSIZE

MaxPoolWait

MaxPoolChecks

IdentityStoreConfig.MAX_POOLWAIT

IdentityStoreConfig.MAX_POOLCHECK

PoolCleanupInterval

IdentityStoreConfig.POOL_CLEANUP_INTERVAL

MaxPoolConnectionIdleTime

IdentityStoreConfig.MAX_POOL_CONNECTION_IDLE_TIME

OperationTimeout

IdentityStoreConfig.CONN_TIMEOUT

ConnectTimeout

IdentityStoreConfig.CONNECT_TIMEOUT

HeartbeatInterval

IdentityStoreConfig.HEARTBEAT_INTERVAL

SocketOptions

IdentityStoreConfig.SOCKET_READTIMEOUT

IdentityStoreConfig.SOCKET_REUSEADDRESS

IdentityStoreConfig.SOCKET_KEEPALIVE

IdentityStoreConfig.SOCKET_TCPNODELAY

MaxPoolConnectionReuseTime

IdentityStoreConfig.MAX_POOL_CONNECTION_REUSE_TIME

PoolConnectionReclaimTime

IdentityStoreConfig.POOL_CONNECTION_RECLAIM_TIME

4.5.4 ファイアウォールおよびロード・バランサのタイムアウト・エラーの処理

通信プロセスを改善するには、ファイアウォールとロード・バランサに対するタイムアウトの設定が不可欠です。これは、分散システム内の問題を検出するのに役立ちます。

SocketOptions設定は、リモート・サーバー障害が原因の孤立したソケット接続を検出して安全に閉じることを助けます。TCPは、リモート・サーバーからのレスポンスを構成された時間待ってからソケットを閉じます。ただし、libOVDとバックエンドLDAPとの間にファイアウォールまたはロード・バランサがある場合、タイムアウト・エラーが発生しないようにSocketOptions内のreadTimeout値を適切に設定する必要があります。この値はファイアウォールまたはロード・バランサのタイムアウトより小さい値に設定する必要があります。

4.6 IDSでのパススルー属性の許可

IDSで検索または更新操作を実行するときは、IDS APIによって使用されるすべての属性をエンティティ定義で定義する必要があります。ただし、アイデンティティ・ディレクトリでは、実行時に動的に属性を追加できます。これらは、パススルー属性として参照されます。

シナリオによっては属性が動的に指定される場合があります。つまり、それらがエンティティ定義で定義されずに、リクエストされた属性またはフィルタで使用される可能性があります。パススルー機能により、この使用方法が実装され、例外はスローされません。