2 標準的なLDAP APIを使用したアプリケーションの開発
2.1 LDAPの歴史の概要
LDAPは、X.500 Directory Access Protocolに対する軽量フロントエンドとして開発されました。LDAPの書式では、データを容易に表現できます。
LDAPはX.500 Directory Access Protocolを次のように簡素化しています。
-
TCP/IP接続を使用します。これは、X.500の実装に必要なOSI通信スタックよりも軽量です。
-
ほとんど使用されないX.500 Directory Access Protocolの冗長な機能を削減しています。
-
単純な書式を使用してデータ要素を表現します。この書式は、複雑で高度に構造化されたX.500の表現よりも処理が簡単です。
-
ネットワーク上のデータ・トランスポートに使用されるX.500エンコーディング規則の簡素化バージョンを使用します。
2.2 LDAPモデルの理解
LDAPでは、4つの基本モデルを使用して、ディレクトリ・エントリで実行される操作が定義されます。
LDAPモデルについて、次の各項で説明します。
2.2.1 ネーミング・モデルについて
LDAPネーミング・モデルによって、ディレクトリ情報を参照および編成できます。ディレクトリの各エントリは、識別名(DN)によって一意に識別されます。識別名は、ディレクトリ階層におけるそのエントリの位置を正確に伝えます。この階層は、ディレクトリ情報ツリー(DIT)を使用して表されます。
図2-1に、識別名とディレクトリ情報ツリーの関係を示します。
図2-1のDITは、Example Corporationに所属する、Anne Smithという同じ名前を持つ2人の従業員のエントリを示しています。この図のディレクトリ情報ツリーは、地理的および組織的な線で構造化されています。左の分岐で表されているAnne Smithは、米国の販売部門に勤務しています。もう一方は、英国のサーバー開発部門に勤務しています。
右の分岐で表されているAnne Smithには、Anne Smithという一般名(cn
)があります。彼女は、Exampleという組織(o
)の英国(uk
)という国(c
)のサーバー開発という組織単位(ou
)に勤務しています。このAnne Smithエントリの識別名は次のとおりです。
cn=Anne Smith,ou=Server Development,c=uk,o=example
識別名の一般的な書式では、左に最下位のDITコンポーネントを置くことに注意してください。ルートに至るまで、次の上位コンポーネントが続きます。
識別名内の最下位コンポーネントは、相対識別名(RDN)と呼ばれます。前述の識別名では、相対識別名はcn=Anne Smith
です。Anne Smithの相対識別名のすぐ上のエントリに対応する相対識別名は、ou=Server Development
です。また、ou=Server Development
のすぐ上のエントリに対応する相対識別名はc=uk
です。識別名は、このように各相対識別名をカンマで区切って順に並べたものです。
DIT全体の中で特定エントリを検索するために、クライアントは、そのエントリの相対識別名のみではなく、完全な識別名を使用することによって、エントリを一意に識別します。図2-1に示すグローバル組織の中で2人のAnne Smithを混同しないためには、それぞれの完全な識別名を使用します。同じ組織単位内に同じ名前の従業員が2人いる場合は、他のメカニズムを使用できます。たとえば、一意の識別番号でこれらの従業員を識別します。
2.2.2 情報モデルについて
LDAP情報モデルによって、ディレクトリ内の情報の形式や文字が決まります。このモデルでは、定義特性としてエントリという概念を使用します。ディレクトリのエントリとは、オブジェクトに関する情報の集合です。たとえば、電話帳には個人に関するエントリが含まれています。図書館カードの目録には、本に関するエントリが含まれています。オンライン・ディレクトリには、従業員、会議室、E-Commerceパートナ、またはプリンタなどの共有ネットワーク・リソースに関するエントリが含まれています。
一般的な電話帳の場合、個人に関するエントリには住所や電話番号などが含まれています。オンライン・ディレクトリでは、このような情報はそれぞれ属性と呼ばれます。一般的な従業員エントリには、役職名、電子メール・アドレス、電話番号などの属性が含まれています。
図2-2では、英国(uk)のAnne Smithに関するエントリにいくつかの属性があります。それぞれがAnne Smithについての固有の情報を提供します。ツリーの右側の円の中には、emailaddrs
、printername
、jpegPhoto
およびapp preferences
がリストされています。図2-2のその他の黒丸も属性を持つエントリですが、それらの属性は示していません。
各属性は、属性タイプと1つ以上の属性値で構成されます。属性の型は、その属性に含まれている情報の種類(jobTitle
など)です。属性値は実際の情報です。たとえば、jobTitle
属性に対する値にはmanager
があります。
2.2.3 機能モデルについて
LDAP機能モデルによって、ディレクトリ・エントリに行える処理が決まります。これらの操作は、主に検索、変更および認証です。
表2-1にこの機能をリストし、説明します。
表2-1 LDAPの機能
機能 | 説明 |
---|---|
検索および読取り |
読取り操作では、名前が判明しているエントリの属性を取得します。リスト操作では、指定したエントリの子を列挙します。検索操作では、検索フィルタと呼ばれる選択条件に基づいて、ツリー内に定義されている領域からエントリを選択します。一致した各エントリについて、リクエストされた属性のセットが(値の有無にかかわらず)戻されます。検索対象エントリの範囲は、単一のエントリ、エントリの子またはサブツリー全体にまで広げることができます。別名のエントリは、サーバーの境界を超えている場合でも、検索時に自動的に続行されます。中止操作を定義すると、進行中の操作を取り消すことができます。 |
変更 |
このカテゴリでは、ディレクトリを変更する4つの操作を定義します。
|
認証 |
このカテゴリでは、バインド操作を定義します。バインドによって、クライアントはセッションを開始し、そのアイデンティティをディレクトリに示すことができます。Oracle Internet Directoryは、単純なクリアテキストのパスワードから公開キーまで、様々な認証方式をサポートしています。バインド解除操作によって、ディレクトリ・セッションを終了します。 |
2.2.4 セキュリティ・モデルについて
LDAPセキュリティ・モデルによって、ディレクトリの情報を保護できます。これにより、Oracle Internet Directoryのデータのセキュリティと整合性が確保されます。
このモデルは、次の各項で説明するいくつかの部分で構成されます。
2.2.4.1 Oracle Internet Directoryでの認証タイプの理解
認証は、ディレクトリ・サーバーが、そのディレクトリに接続するユーザーのアイデンティティを確認するプロセスです。ディレクトリ認証は、LDAPバインド操作でLDAPセッションを確立するときに行われます。すべてのセッションには関連付けられているユーザー・アイデンティティがあり、認可IDとも呼ばれます。
次の各項では、Oracle Internet Directoryの認証オプションについて説明します。
2.2.4.1.1 匿名認証について
ディレクトリをすべての人が使用できる場合、ユーザーは匿名でログインできます。匿名認証では、ユーザーはユーザー名とパスワードのフィールドを空白のままにしてログインします。そうすると、匿名ユーザーに対して指定されたすべての権限を使用できます。
2.2.4.1.2 簡易認証について
簡易認証では、クライアントは暗号化されていない識別名とパスワードを使用し、サーバーに対して自己認証を行います。サーバーは、クライアントの識別名およびパスワードが、ディレクトリに格納されている識別名およびパスワードと一致していることを検証します。
2.2.4.1.3 Secure Sockets Layer (SSL)を使用した認証について
Secure Sockets Layer(SSL)は、ネットワーク接続を保護するための業界標準プロトコルです。証明書の交換によりユーザーを認証します。これらの証明書は、信頼できる認証局によって検証されます。証明書は、エンティティのアイデンティティ情報が正しいことを保証します。エンティティには、エンド・ユーザー、データベース、管理者、クライアントまたはサーバーが可能です。認証局(CA)は、すべての関係機関によって高いレベルの信頼度を与えられた公開キーの証明書を作成する機関です。
SSLは、表2-2に示す3つの認証モードで使用できます。
表2-2 SSL認証モード
SSLモード | 説明 |
---|---|
認証なし |
クライアントとサーバーのいずれも、相手に対して自己認証を行いません。証明書も送信または交換されません。この場合は、SSL暗号化および復号化のみが使用されます。 |
一方向認証 |
ディレクトリ・サーバーのみ、クライアントに対して自己認証を行います。ディレクトリ・サーバーは、そのサーバーが認証されていることを証明する証明書をクライアントに送信します。 |
双方向認証 |
クライアントとサーバーは、相互に自己認証を行い、証明書を交換します。 |
Oracle Internet Directory環境では、クライアントとディレクトリ・サーバー間のSSL認証は次の3つの基本ステップに従って行われます。
-
ユーザーは、SSLポートでSSLを使用して、ディレクトリ・サーバーへのLDAP接続を開始します。デフォルトのSSLポートは
3131
です。 -
SSLは、クライアントとディレクトリ・サーバー間のハンドシェイクを実行します。
-
ハンドシェイクが成功すると、ディレクトリ・サーバーは、そのディレクトリにアクセスするために必要な認可をユーザーが所有していることを検証します。
関連項目:
SSLの詳細は、『Oracle Advanced Security管理者ガイド』を参照してください。
2.2.4.2 Oracle Internet Directoryでのアクセス制御と認可の理解
認可プロセスにより、ユーザーが権限を持つ情報のみを読取りまたは更新することが保証されます。ディレクトリ・サーバーは、特定のディレクトリ操作の実行に必要な権限が(セッションに関連付けられた認可IDによって識別された)ユーザーに与えられていることを確認します。必要な権限がないと、操作は実行できません。
適切な認可が行われていることを保証するためにディレクトリ・サーバーが使用するメカニズムは、アクセス制御と呼ばれます。また、アクセス制御項目(ACI)は、アクセス制御に関連する管理ポリシーを記録したディレクトリ・メタデータです。
ACIは、ユーザーが変更できる操作属性として、Oracle Internet Directoryに格納されています。通常、このACI属性値のリスト全体が1つのディレクトリ・オブジェクトに関連付けられています。このリストはアクセス制御リスト(ACL)と呼ばれます。このリストにある属性値によって、そのディレクトリ・オブジェクトに対するアクセス・ポリシーが管理されます。
ACIは、ディレクトリ内にテキスト文字列として格納されています。この文字列は、明確に定義された書式に従う必要があります。ACI属性の各有効値は、個別のアクセス制御ポリシーを表します。これらの個々のポリシーのコンポーネントは、ACIディレクティブまたはACIと呼ばれ、その書式はACIディレクティブ書式と呼ばれます。
アクセス制御ポリシーは規範的です。つまり、そのセキュリティ・ディレクティブは、ディレクトリ情報ツリー(DIT)内のすべての下位エントリに適用されるように設定できます。アクセス制御ポリシーが適用される開始点は、アクセス制御ポリシー・ポイント(ACP)と呼ばれます。
2.2.4.3 Oracle Internet Directoryでのデータ整合性の理解
Oracle Internet Directoryは、SSLを使用して、送信中にデータの変更、削除または再実行が行われないことを保証します。この機能では、暗号化チェックサムを使用して、セキュアなメッセージ・ダイジェストを生成します。チェックサムは、MD5アルゴリズムまたはSecure Hash Algorithm(SHA)を使用して作成されます。メッセージ・ダイジェストは各ネットワーク・パケットに組み込まれます。
2.2.4.4 Oracle Internet Directoryでのデータ・プライバシの理解
Oracle Internet Directoryでは、SSLによる公開キー暗号化を使用して、送信中にデータが開示されないことを保証します。公開キー暗号では、メッセージの送信側が受信側の公開キーを使用してメッセージを暗号化します。メッセージが送信されると、受信側は、受信側の秘密キーを使用してメッセージを復号化します。ディレクトリは2つのレベルの暗号化をサポートしています。
表2-3 暗号化アルゴリズム
アルゴリズム | 説明 |
---|---|
DES40 |
国際的に使用可能なDES40はDESの改良型で、秘密キーを事前に処理して40ビットの有効なキーを提供します。DES40は、米国およびカナダ以外でDESベースの暗号化アルゴリズムの使用を希望する顧客を対象に設計されています。 |
RC4_40 |
Oracleは、Oracle製品が使用できる事実上すべての地域に対して、キーのサイズが40ビットのRC4データ暗号化アルゴリズムを輸出するライセンスを取得しています。この結果、国際企業は、高速暗号化を使用して事業全体を保護することが可能になります。 |
2.3 Oracle Internet Directoryでの標準的なLDAP APIの使用方法
標準的なLDAP APIは、C、PL/SQLおよびJavaで使用できます。これらにより、基本的なLDAP操作を実行できます。
LDAP操作は、「LDAPモデルの理解」を参照してください。CとPL/SQLのAPIはディレクトリSDKに含まれています。JavaはJNDIパッケージに含まれています。3つともTCP/IP接続を使用します。これらは、LDAPバージョン3に基づいており、Oracle Internet DirectoryへのSSL接続をサポートしています。
次の各項では、APIの開始方法について説明します。
2.3.1 LDAP APIを起動するために実行するステップ
通常、LDAP APIを起動するには、セッションを初期化して認証する必要があります。
アプリケーションでは、次の4つのステップに従ってAPIのファンクションを使用します。
-
ライブラリを初期化し、LDAPセッション・ハンドルを取得します。
-
必要に応じて、LDAPサーバーに対する認証を行います。
-
いくつかのLDAP操作を実行し、その結果とエラー(ある場合)を取得します。
-
セッションをクローズします。
図2-3に、これらのステップを示します。
2.3.2 C APIスタート・ガイド
C APIを使用してアプリケーションを作成する場合、$ORACLE_HOME/ldap/public
にあるヘッダー・ファイルldap.h
をインクルードする必要があります。
また、$ORACLE_HOME/lib/libclntsh.so.10.1
にあるライブラリに動的にリンクすることも必要です。
関連項目:
SSLモードおよび非SSLモードの使用方法を学習するには、「C APIの使用例」を参照してください。
2.3.3 DBMS_LDAPパッケージ・スタート・ガイド
DBMS_LDAP
パッケージを使用すると、PL/SQLアプリケーションで、エンタープライズ・ワイドのLDAPサーバー内にあるデータにアクセスできます。ファンクション・コールの名前と構文は、C APIの場合と同様です。
このファンクションは、C APIに関するInternet Engineering Task Force(IETF)の最新の推奨事項に準拠しています。ただし、PL/SQL APIに含まれるのは、C APIで使用できるファンクションの一部のみです。特に、PL/SQL APIで使用できるのは、LDAPサーバーへの同期コールのみです。
PL/SQL LDAP APIの使用を開始するには、次のコマンド・シーケンスを使用してDBMS_LDAPをデータベースにロードします。
2.3.4 Java APIスタート・ガイド
Java開発者は、Java Naming and Directory Interface(JNDI)を使用して、Oracle Internet Directoryの情報にアクセスできます。
JNDIは次のリンクで提供されています。
http://www.oracle.com/technetwork/java/jndi/index.html
この章ではJava APIについて説明しませんが、「JNDIを使用したセッションの初期化」で、JNDIに対するラッパー・メソッドを使用して基本的な接続を確立する方法を示します。
2.4 LDAPセッションの初期化
C APIに基づいたすべてのLDAP操作で、クライアントがLDAPサーバーとのLDAPセッションを確立することが求められます。PL/SQL APIに基づいたLDAP操作を実行するには、最初にデータベース・セッションを初期化してからLDAPセッションをオープンする必要があります。
ほとんどのJava操作では、Java Naming and Directory Interface(JNDI)接続が必要になります。ここで説明するoracle.ldap.util.jndi
パッケージは、この接続の確立に伴う作業を簡素化します。
LDAPセッションの初期化については、次の各トピックで説明します。
2.4.1 C APIを使用したセッションの初期化
Cファンクションldap_init()
は、LDAPサーバーとのセッションを初期化します。サーバーは、そのサーバーを必要とする操作が実行されるまで実際に接続されないため、初期化した後にオプションを設定できます。
ldap_init
の構文は、次のとおりです。
LDAP *ldap_init (
const char *hostname, int portno
);
表2-4に、このファンクションのパラメータをリストし、説明します。
表2-4 ldap_init()のパラメータ
パラメータ | 説明 |
---|---|
hostname |
ディレクトリ・ホスト名またはドット区切り文字列表記のIPアドレスを空白で区切ったリストが入ります。コロンで区切ることで各ホスト名にポート番号を組み合せることができます。 接続に成功するまで、ホストがリストの順序に従って試されます。 ノート: リテラルIPv6[10]アドレスをhostnameパラメータに格納するための適切な表現が必要ですが、現在はまだ決定および実装されていません。 |
portno |
接続先ディレクトリのTCPポート番号が入ります。デフォルトのLDAPポート |
ldap_init()
およびldap_open()
の戻り値は、そのセッションへの後続のコールに渡す必要がある不透明な構造体へのセッション・ハンドル(ポインタ)です。これらのルーチンは、セッションが初期化できない場合にNULL
を戻します。オペレーティング・システムのエラー・レポート・メカニズムをチェックすると、コールに失敗した理由を確認できます。
2.4.2 DBMS_LDAPを使用したセッションの初期化
PL/SQL APIでは、ファンクションDBMS_LDAP.init()
によりLDAPセッションを開始します。
ファンクションの構文は次のとおりです。
FUNCTION init (hostname IN VARCHAR2, portnum IN PLS_INTEGER )
RETURN SESSION;
LDAPセッションを確立するには、init
ファンクションに有効なホスト名とポート番号が必要です。このファンクションは、そのためのデータ構造を割り当て、コール元にDBMS_LDAP.SESSION
タイプのハンドルを戻します。コールで戻されたハンドルは、DBMS_LDAPでセッションに定義された後続のすべてのLDAP操作で使用する必要があります。APIは、このセッション・ハンドルを使用して、オープン接続、未処理のリクエスト、その他の情報に関する状態をメンテナンスします。
アクティブな同時接続数は64に制限されていますが、1つのデータベース・セッションで必要な数のLDAPセッションを取得できます。複数のサーバーから同時にデータを取得する必要がある場合、または複数のLDAPアイデンティティを使用するオープン・セッションが必要な場合、1つのデータペース・セッションは、通常複数のLDAPセッションを持ちます。
ノート:
DBMS_LDAP.init()
のコールで戻されるハンドルは動的な構造体です。複数のデータベース・セッション間では存続しません。ハンドルの値を永続的なフォームに格納し、後で再利用すると、予測できない結果になる場合があります。
2.4.3 JNDIを使用したセッションの初期化
oracle.ldap.util.jndi
パッケージは、JNDI実装に対するラッパー・メソッドを提供することで、基本的な接続をサポートします。
JNDIを使用して接続を確立する場合は、次のリンクを参照してください。
http://www.oracle.com/technetwork/java/jndi/index.html
次に、非SSL接続を確立するoracle.ldap.util.jndi
の実装を示します。
import oracle.ldap.util.jndi import javax.naming.*; public static void main(String args[]) { try{ InitialDirContext ctx = ConnectionUtil.getDefaultDirCtx(args[0], // host args[1], // port args[2], // DN args[3]; // password) // Do work } catch(NamingException ne) { // javax.naming.NamingException is thrown when an error occurs } }
ノート:
-
DN
とpassword
は、バインド識別名とパスワードを示します。匿名バインドの場合、これらを""
に設定します。 -
ConnectionUtil.getSSLDirCtx()
を使用すると、認証なしのSSL接続を確立できます。
2.5 LDAPセッションの認証
LDAPサーバーに対する操作を実行する個人またはアプリケーションは、最初に認証を受ける必要があります。これらのエンティティのdn
パラメータおよびpasswd
パラメータがNULLの場合、LDAPサーバーはanonymousと呼ばれる特別なアイデンティティをユーザーに割り当てます。通常、匿名ユーザーは最小限の権限を与えられたディレクトリ・ユーザーです。
バインド操作が完了すると、別のバインド操作が発生するか、LDAPセッションが終了する(unbind_s
)まで、ディレクトリ・サーバーに新規のアイデンティティが保持されます。LDAPサーバーは、このアイデンティティを使用して、デプロイ先の企業で規定されたセキュリティ・モデルを実施します。このアイデンティティは、識別されたユーザーまたはアプリケーションがディレクトリ内で検索、更新または比較を行うための十分な権限を持っているかどうかをLDAPサーバーが判断するために役立ちます。
バインド操作用のパスワードは、ネットワーク上をクリアテキストで送信されます。ネットワークがセキュアでない場合は、認証とデータ転送を伴うその他のLDAP操作でSSLを使用することを検討してください。
この項では、次の項目について説明します。
2.5.1 C APIを使用したLDAPセッションの認証
Cファンクションldap_simple_bind_s()
を使用すると、ユーザーとアプリケーションは、識別名とパスワードを使用してディレクトリ・サーバーへの認証を受けることができます。
ldap_simple_bind_s()
ファンクションの次のコードを使用すると認証できます。
int ldap_simple_bind_s ( LDAP* ld, char* dn, char* passwd );
表2-5に、このファンクションのパラメータをリストし、説明します。
表2-5 ldap_simple_bind_s()の引数
引数 | 説明 |
---|---|
ld |
有効なLDAPセッション・ハンドルです。 |
dn |
アプリケーションが認証で使用するアイデンティティ |
passwd |
認証アイデンティティに対するパスワード |
dn
パラメータおよびpasswd
パラメータがNULL
の場合、LDAPサーバーはanonymousと呼ばれる特別なアイデンティティをユーザーまたはアプリケーションに割り当てます。
2.5.2 DBMS_LDAPを使用したLDAPセッションの認証
PL/SQLファンクションsimple_bind_s
を使用すると、ユーザーとアプリケーションは、識別名とパスワードを使用してディレクトリへの認証を受けることができます。
simple_bind_s
の構文は、次のとおりです。
FUNCTION simple_bind_s ( d IN SESSION, dn IN VARCHAR2, passwd IN VARCHAR2)
RETURN PLS_INTEGER;
このファンクションには、init
で取得したLDAPセッション・ハンドルが最初のパラメータとして必要であることに注意してください。
次のPL/SQLコード・スニペットは、初期化と認証を行う前述のPL/SQLファンクションの実装方法を示しています。
DECLARE
retval PLS_INTEGER; my_session DBMS_LDAP.session;
BEGIN
retval := -1; -- Initialize the LDAP session my_session := DBMS_LDAP.init('yow.example.com',3060); --Authenticate to the directory retval :=DBMS_LDAP.simple_bind_s(my_session,'cn=orcladmin', 'welcome');
前述の例では、LDAPセッションはLDAPサーバーyow.example.com
で初期化されます。このサーバーは、TCP/IPポート番号3060
でリクエストをリスニングします。次に、アイデンティティcn=orcladmin
(パスワードはwelcome
)が認証されます。認証が完了したら、通常のLDAP操作を開始できます。
2.6 ディレクトリの検索
検索は、最も一般的なLDAP操作です。アプリケーションは、複雑な検索条件を使用し、ディレクトリからエントリを選択して取得できます。
検索フィルタとタイプについては、次の各トピックで説明します。
-
ノート:
このリリースの
DBMS_LDAP
APIに準備されているのは、同期検索機能のみです。これは、LDAPサーバーが結果セット全体を戻すまで、検索ファンクションのコール元がブロックされることを意味します。
2.6.1 検索関連の操作でのステップ
適切な属性が指定されると、一般的な検索操作で正確な情報を取得できます。
一般的な検索操作を開始して結果を取得するために必要なプログラミングは、次のステップで行います。
-
検索によって戻される属性を決定し、その属性を配列に入れます。
-
選択した有効範囲オプションとフィルタを使用して、検索を開始します。
-
結果セットからエントリを取得します。
-
ステップ3で取得したエントリから属性を取得します。
-
ステップ4で取得した属性の値を取得し、その値をローカル変数にコピーします。
-
エントリのすべての属性が処理されるまで、ステップ4を繰り返します。
-
すべてのエントリが処理されるまで、ステップ3を繰り返します。
図2-4に、フローチャートを使用してこれらのステップを示します。
2.6.2 ディレクトリ・サーバーの検索範囲のオプション
検索の有効範囲は、ディレクトリ・サーバーが検索ベースと比較して検証するエントリの数を決定します。
表2-6 search_s()またはsearch_st()ファンクションのオプション
オプション | 説明 |
---|---|
SCOPE_BASE |
ディレクトリ・サーバーは、検索ベースに対応しているエントリのみを検索します。 |
SCOPE_ONELEVEL |
ディレクトリ・サーバーは、検索対象を検索ベース・エントリの直接の子エントリに限定します。 |
SCOPE_SUBTREE |
ディレクトリ・サーバーは、検索ベース・エントリとその下のサブツリー全体を対象に検索します。 |
図2-5では、検索ベースはグレーの丸で表されています。検索対象のエントリは、薄い色の四角形で囲まれています。
2.6.3 ディレクトリ・サーバーの検索フィルタ
検索フィルタは、検索対象を特定のタイプのエントリに限定するための式です。search_s()
およびsearch_st()
ファンクションに必要な検索フィルタは、Internet Engineering Task Force(IETF)のRFC 1960で定義されている文字列フォーマットに準拠しています。
表2-6に示すように、7種類の検索フィルタがあります。これらは、attribute operator value
という書式で入力します。
表2-7 検索フィルタ
フィルタ・タイプ | 書式 | 例 | 一致 |
---|---|---|---|
等価 |
(att=value) |
(sn=Keaton) |
|
近似 |
(att~=value) |
(sn~=Ketan) |
|
部分文字列 |
(attr=[leading]*[any]*[trailing] |
(sn=*keaton*) (sn=keaton*) (sn=*keaton) (sn=ke*at*on) |
文字列
|
以上 |
attr>=value |
(sn>=Keaton) |
辞書編集順で |
以下 |
(attr<=value) |
(sn<=Keaton) |
辞書編集順で |
存在 |
(attr=*) |
(sn=*) |
|
拡張可能 |
attr[:dn]:=value |
(sn:dn:=Mary Smith) |
エントリまたはエントリのDNの姓属性がMary Smithと一致するすべてのエントリ。 |
ノート:
-
Oracle Internet Directoryでは拡張可能フィルタがサポートされますが、
ldapsearch
およびOracle LDAP APIではサポートされません。この種のフィルタを使用するには、JNDIなどの別のAPIを使用する必要があります。 -
Oracle Internet Directoryでは、フィルタで指定された一致規則を使用した拡張可能なマッチングはサポートされません。
ブール演算子や接頭辞表記法を使用してこれらのフィルタを組み合せると、より複雑なフィルタを構成できます。表2-8に例を示します。この例では、&
文字はANDを、|
文字はORを、!
文字はNOTを表します。
表2-8 ブール演算子
フィルタ・タイプ | 書式 | 例 | 一致 |
---|---|---|---|
AND |
(&(filter1)(filter2)). . .) |
(&(sn=keaton)(objectclass=inetOrgPerson)) |
姓が |
OR |
(|(filter1)(filter2)). . .) |
(|(sn~=ketan)(cn=*keaton)) |
姓が |
NOT |
(!(filter)) |
(!(mail=*)) |
メール属性を持たないエントリ。 |
表2-8の複合フィルタを組み合せて、さらに複雑なネストしたフィルタを作成できます。
関連項目:
-
LDAPフィルタの詳細は、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドのLDAPフィルタ定義に関する付録を参照してください。
-
http://www.ietf.org
のRFC 2254
2.6.4 C APIを使用したディレクトリの検索
Cファンクションldap_search_s()
は、ディレクトリの同期検索を実行します。
検索を実行するには、ldap_search_s()
ファンクションの次の構文を使用します。
int ldap_search_s ( LDAP* ld, char* base, int scope, char* filter int attrsonly, LDAPMessage** res );
表2-9に、引数の詳細な説明を示します。
表2-9 ldap_search_s()の引数
引数 | 説明 |
---|---|
ld |
有効なLDAPセッション・ハンドルです。 |
base |
検索のベースの識別名です。 |
scope |
検索対象のDITの幅と深さです。 |
filter |
検索対象のエントリを選択するためのフィルタです。 |
attrs |
検索で戻されるエントリの属性です。 |
attrso |
|
res |
この引数は検索結果を戻します。 |
ldap_search_s
は、いくつかのサポート・ファンクションと連携して、検索対象を絞り込みます。次のステップは、これらのCファンクションが検索操作のプログラム・フローにどのように対応するかを示しています。「C APIリファレンス」で、これらのファンクションの詳細を示します。
- 検索によって戻される属性を決定し、その属性を文字列の配列に入れます。配列はNULLで終了する必要があります。
ldap_search_s()
を使用して、検索を開始します。有効範囲オプションとフィルタで検索対象を絞り込みます。ldap_first_entry()
ファンクションまたはldap_next_entry()
ファンクションを使用して、結果セットからエントリを取得します。- ステップ3で取得したエントリから属性を取得します。これには、
ldap_first_attribute()
ファンクションまたはldap_next_attribute()
ファンクションを使用します。 - ステップ4で取得した属性のすべての値を取得し、その値をローカル変数にコピーします。これには、
ldap_get_values()
ファンクションまたはldap_get_values_len()
ファンクションを使用します。 - エントリのすべての属性が処理されるまで、ステップ4を繰り返します。
- すべてのエントリが処理されるまで、ステップ3を繰り返します。
2.6.5 DBMS_LDAPを使用したディレクトリの検索
PL/SQL APIを使用する場合、ファンクションDBMS_LDAP.search_s()
を使用してディレクトリ検索を実行します。
DBMS_LDAP.search_s()
の構文は、次のとおりです。
FUNCTION search_s
( ld IN SESSION, base IN VARCHAR2, scope IN PLS_INTEGER, filter IN VARCHAR2, attrs IN STRING_COLLECTION, attronly IN PLS_INTEGER, res OUT MESSAGE )
RETURN PLS_INTEGER;
このファンクションは、表2-10に示す引数を取ります。
表2-10 DBMS_LDAP.search_s()およびDBMS_LDAP.search_st()の引数
引数 | 説明 |
---|---|
ld |
有効なセッション・ハンドルです。 |
base |
検索を開始するLDAPサーバー内のベース・エントリの識別名です。 |
scope |
検索対象のDITの幅と深さです。 |
filter |
検索対象のエントリを選択するためのフィルタです。 |
attrs |
検索で戻されるエントリの属性です。 |
attronly |
|
res |
追加処理を行うための結果セットを戻す |
search_s
は、いくつかのサポート・ファンクションと連携して、検索対象を絞り込みます。次のステップは、すべてのPL/SQLファンクションが検索操作のプログラム・フローにどのように対応するかを示しています。
- 戻される属性を決定し、その属性を
DBMS_LDAP.STRING_COLLECTION
データ型に設定します。 DBMS_LDAP.search_s()
またはDBMS_LDAP.search_st()
を使用して、検索を実行します。有効範囲オプションとフィルタで検索対象を絞り込みます。DBMS_LDAP.first_entry()
またはDBMS_LDAP.next_entry()
を使用して、結果セットからエントリを取得します。- ステップ3で取得したエントリから属性を取得します。これには、
DBMS_LDAP.first_attribute()
またはDBMS_LDAP.next_attribute()
を使用します。 - ステップ4で取得した属性のすべての値を取得し、その値をローカル変数にコピーします。これには、
DBMS_LDAP.get_values()
またはDBMS_LDAP.get_values_len()
を使用します。 - エントリのすべての属性が処理されるまで、ステップ4を繰り返します。
- すべてのエントリが処理されるまで、ステップ3を繰り返します。
2.7 セッションの終了
C APIまたはDBMS_LDAP APIを使用してセッションを終了できます。
2.7.1 セッションを終了するC API
LDAPセッション・ハンドルを取得し、ディレクトリ関連の作業をすべて完了した後は、LDAPセッションを破棄する必要があります。C APIでは、そのためにldap_unbind_s()
ファンクションを使用します。
ldap_unbind_s()
の構文は、次のとおりです。
int ldap_unbind_s ( LDAP* ld );
ldap_unbind_s()
のコールが正常終了すると、ディレクトリへのTCP/IP接続がクローズします。また、LDAPセッションで使用されたシステム・リソースの割当てが解除されます。最後に、整数LDAP_SUCCESS
がコール元に戻されます。ldap_unbind_s()
を起動した後は、その他のLDAP操作は実行できません。ldap_init()
を使用して新しいセッションを開始する必要があります。
2.7.2 セッションを終了するDBMS_LDAP API
PL/SQL APIが使用されている場合、DBMS_LDAP.unbind_s()
ファンクションによりLDAPセッションが破棄されます。
unbind_s
の構文は、次のとおりです。
FUNCTION unbind_s (ld IN SESSION ) RETURN PLS_INTEGER;
unbind_s
により、ディレクトリへのTCP/IP接続がクローズします。また、LDAPセッションで使用されたシステム・リソースの割当てが解除されます。最後に、整数DBMS_LDAP.SUCCESS
がコール元に戻されます。unbind_s
を起動した後は、その他のLDAP操作は実行できません。init
ファンクションを使用して新しいセッションを開始する必要があります。