Oracle® Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド 11g リリース1(11.1.1) B56242-05 |
|
前 |
次 |
この章では、Oracle Internet Directory 11gリリース1(11.1.1)で使用可能なLDAPプロトコルの拡張機能について説明します。
この章では、次の項目について説明します。
Oracle Internet Directoryでは、SASLベース認証の2つのメカニズムをサポートします。この項では、それらのメカニズムについて説明します。次の項目について説明します。
Digest-MD5メカニズムを使用したSASL認証
外部メカニズムを使用したSASL認証
SASL Digest-MD5認証は、LDAPバージョン3サーバー(RFC 2829)で必要な認証メカニズムです。LDAPバージョン2では、Digest-MD5はサポートされません。
Digest-MD5認証メカニズムを使用するには、Java APIまたはC APIのいずれかを使用して認証を設定できます。C APIでサポートされているのはauth
モードのみです。
関連項目:
|
SASL Digest-MD5メカニズムには3つのモードがあり、それぞれが異なるセキュリティ・レベルまたはQuality of Protection(QoP)を表しています。これには、次のようなものがあります。
auth
: 認証のみ。初期バインドにのみ認証が必要です。その後、情報はクリアテキストで渡されます。
auth-int
: 認証および整合性。初期バインドには認証が必要です。その後、チェックサムを使用してデータの整合性が保証されます。
auth-conf
: 認証および機密保護。初期バインドには認証が必要です。その後、暗号化を使用してデータが保護されます。次に示す5つの暗号方式を使用できます。
DES
3DES
RC4
RC4-56
RC4-40
これらはすべて対称型暗号化アルゴリズムです。
10g(10.1.4.0.1)より前のOracle Internet Directoryでは、Digest-MD5メカニズムのauth
モードのみがサポートされました。10g(10.1.4.0.1)からは、Oracle Internet Directoryで、jdk1.4 APIのJava Naming and Directory Interface(JNDI)、またはOpenLDAP Java APIで3つのモードがすべてサポートされています。Oracle LDAP SDKでサポートされているのはauth
モードのみです。
Oracle Internet DirectoryのSASL Digest-MD5認証では、特別な設定をしなくても、レルムではなくユーザーまたはパスワードに基づいた静的なSASL Digest-MD5ベリファイアの生成がサポートされています。レルムに基づいてSASL Digest-MD5を使用する場合は、新しいユーザーをプロビジョニングする前に関連するパスワード・ポリシーでorclpasswordencryptionenable
属性の値を1に変更して、どちらからもパスワードを生成できるようにしておく必要があります。値を変更するLDIFファイルは次のようになります。
dn: cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext changetype: modify replace: orclpwdencryptionenable orclpwdencryptionenable: 1
Digest-MD5メカニズムについては、Internet Engineering Task ForceのRFC 2831を参照してください。このメカニズムは、HTTP Digest認証(RFC 2617)に基づいています。
関連項目:
|
次の文は、Internet Engineering Task ForceのRFC 2222のセクション7.4を翻訳したものです。
外部認証に関連付けられたメカニズム名はEXTERNALです。クライアントは、認可アイデンティティの入った初期レスポンスを送信します。サーバーは、SASLの外部にある情報を使用して、クライアントが認可アイデンティティとして認証を行う権限を持っているかを判断します。クライアントにその権限がある場合、サーバーは認証情報の交換が正常に終了したことを示します。クそれ以外の場合、サーバーは失敗したことを示します。
IPsecやSSL/TLSなどのシステムによりこの外部情報が提供されます。
クライアントが認可アイデンティティとして空の文字列を送信した(クライアントの認証資格証明から作成された認可アイデンティティをリクエストする)場合、認可アイデンティティは外部認証を提供するシステムの認証資格証明から作成されます。
Oracle Internet Directoryは、SSL相互接続を介してSASL外部メカニズムを提供します。認可アイデンティティ(識別名)は、SSLネットワーク協定時のクライアント証明書から作成されます。
RFC 2251で定義されているように、LDAP v3プロトコルではコントロールによる拡張機能が許可されています。Oracle Internet Directoryでは複数のコントロールをサポートしています。一部は標準で、RFCで説明されています。階層検索用のCONNECT_BYコントロールなど、それ以外のコントロールはOracle固有です。コントロールは、JavaまたはCで使用できます。
コントロールは、サーバーに送信したり、LDAPメッセージとともにクライアントに戻すことができます。このようなコントロールは、サーバー・コントロールと呼ばれます。LDAP APIは、クライアント・コントロールを使用してクライアント側の拡張メカニズムもサポートします。このコントロールは、LDAP APIの動作にのみ影響し、サーバーに送信されることはありません。
CでのLDAPコントロールの使用の詳細は、第8.2.7項「コントロールの使用」を参照してください。
JavaにおけるLDAPコントロールの使用の詳細は、http://www.oracle.com/technetwork/java/jndi/index.html
のJNDIパッケージjavax.naming.ldap
に関するドキュメントを参照してください。
表3-1「Oracle Internet Directoryでサポートされているリクエスト・コントロール」と第3.2項「Oracle Internet Directoryでサポートされているレスポンス・コントロール」に、Oracle Internet Directory 11g リリース1(11.1.1)でサポートされているコントロールを示します。
表3-1 Oracle Internet Directoryでサポートされているリクエスト・コントロール
オブジェクト識別子 | 名前 | 説明 |
---|---|---|
2.16.840.1.113894.1.8.39 |
計算属性値の一意性 |
複数の属性値のエントリベースの組合せで、計算属性値の一意性を許可します。通常、属性一意性は単一属性にのみ構成されます。属性値の組合せで一意性を必要とするアプリケーションでは、このコントロールを送信すると、Oracle Internet Directoryサーバーにより、 計算値を含むエントリがすでに存在する場合は、Oracle Internet Directoryサーバーによって、LDAPエラー・コード「LDAP_ALREADY_EXISTS = 0x44」が返されます。 たとえば、マルチテナント環境では、ユーザーのUID属性は特定のテナントで一意である必要がありますが、ディレクトリ全体では必ずしも一意である必要はありません。アプリケーションでは、計算属性TenantID_UIDを持つLDAPエントリが作成されます。ここで、TenantIDはテナントの識別子、UIDは属性になります。LDAPエントリが作成されたアプリケーションでは、このコントロールが送信されます。計算属性値を含むエントリがすでに存在する場合は、Oracle Internet Directoryサーバーによって、LDAP_ALREADY_EXISTSエラー・コードが返されます。 |
2.16.840.1.113730.3.4.9 |
OID_SEARCH_VLV_REQ_CONTROL |
指定のLDAP検索で、大規模な検索結果セットの連続したサブセットを返すことをクライアントがサーバーに求めることを許可します。このコントロールを使用すると、検索結果を一度に1ページずつ表示できるため、クライアントでのより迅速な検索結果の取得が可能になると同時に、一度に多数の検索結果の格納が必要になる事態を防げます。 サーバーによって、OID_SEARCH_VLV_RES_CONTROL 2.16.840.1.113730.3.4.10が返されます。 OID_SEARCH_VLV_REQ_CONTROLは、SORTコントロール(ldapsearchの-T引数)との組合せでのみ使用できます。SORTコントロールを含めないと、リクエストによりLDAPエラー・コード53「VLVリクエスト制御を含む検索操作でSORTリクエスト制御が欠落しています。」が返されます。 SORTコントロールでは、サーバーで有効な任意のソート指定を含められます。SORTコントロールをOID_SEARCH_VLV_REQ_CONTROLと一緒に使用すると、サーバーはソートした検索結果の完全セットを返すかわりに、ターゲット・エントリを検索結果の参照ポイントとして使用して、コントロールで指定されているエントリの連続したサブセットを返します。 詳細は、「LDAP Extensions for Scrolling View Browsing of Search Results」( |
1.2.840.113556.1.4.319 |
OID_SEARCH_PAGING_CONTROL |
「ページング済のLDAP検索結果」を参照してください。 |
1.2.840.113556.1.4.473 |
OID_SEARCH_SORTING_REQUEST_CONTROL |
「ソート済のLDAP検索結果」を参照してください。 |
2.16.840.1.113730.3.4.2 |
GSL_MANAGE_DSA_CONTROL |
Oracle Internet Directoryの参照、動的グループおよび別名オブジェクトの管理に使用されます。詳細は、 |
2.16.840.1.113894.1.8.1 |
OID_RESET_PROXYCONTROL_IDENTITY |
確立されたLDAP接続でアイデンティティのプロキシ・スイッチを実行するために使用されます。たとえば、アプリケーションAがディレクトリ・サーバーに接続していて、アプリケーションBにスイッチする場合を考えます。アプリケーションBの資格証明を提供することで、リバインドは簡単に実行できます。しかし、資格証明が使用できないときでも、アプリケーションによるアイデンティティの切り替えを可能にするプロキシのメカニズムを使用できる場合があります。このコントロールを使用すると、Oracle Internet DirectoryでアプリケーションAがアプリケーションBとしてプロキシする権限を持っている場合に、アプリケーションAがアプリケーションBにスイッチすることができます。 |
2.16.840.1.113894.1.8.2 |
OID_APPLYUSEPASSWORD_POLICY |
アプリケーションにユーザーのベリファイアを送信する前に、Oracle Internet Directoryによるアカウント・ロックアウトの確認が必要なアプリケーションによって送信されます。Oracle Internet Directoryによりベリファイア検索リクエスト内にこのコントロールが検出され、ユーザー・アカウントがロックされている場合、Oracle Internet Directoryはアプリケーションにベリファイアを送信しません。適切なパスワード・ポリシー・エラーが送信されます。 |
2.16.840.1.113894.1.8.3 |
CONNECT_BY |
第3.5項「階層検索の実行」を参照してください。 |
2.16.840.1.113894.1.8.4 |
OID_CLIENT_IP_ADDRESS |
Oracle Internet DirectoryによってIPロックアウトが実行される場合に、クライアントがエンド・ユーザーIPアドレスを送信するために使用されます。 |
2.16.840.1.113894.1.8.5 |
GSL_REQDATTR_CONTROL |
動的グループとともに使用されます。ディレクトリ・サーバーに、メンバーシップ・リストではなくメンバーの特定の属性を読み取るよう指示します。 |
2.16.840.1.113894.1.8.6 |
PasswordStatusRequestControl |
このコントロールがLDAPバインド/比較操作リクエストの一部としてパッケージ化されている場合、このコントロールによってサーバーでパスワード・ポリシーのレスポンス・コントロールが生成されます。実際のレスポンス・コントロールは状況に応じて異なります。状況とは、差し迫ったパスワードの有効期限、残りの猶予期間ログインの数、パスワードの期限切れ、アカウントのロックなどです。 |
2.16.840.1.113894.1.8.14 |
OID_DYNAMIC_VERIFIER_REQUEST_CONTROL |
サーバーによる動的パスワード・ベリファイアの作成が必要な場合にクライアントが送信するリクエスト・コントロール。サーバーは、リクエスト・コントロールのパラメータを使用してベリファイアを作成します。 |
2.16.840.1.113894.1.8.16 |
AccountStatusRequestControl |
認証プロセスに関連付けられたLDAP検索操作とともにパッケージ化されている場合、Oracle Internet Directoryは、パスワード・ポリシーのレスポンス・コントロールを返し、アカウントのロックアウトやパスワードの有効期限などのアカウント状態に関連する情報をクライアント・アプリケーションに知らせます。 |
2.16.840.1.113894.1.8.23 |
GSL_CERTIFICATE_CONTROL" |
証明書検索コントロール。ユーザー証明書の検索方法を指定するためにクライアントが送信するリクエスト・コントロール。『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の付録「ユーザー証明書のディレクトリの検索」を参照してください。 |
2.16.840.1.113894.1.8.29 |
EffectivePolicyControl |
このコントロールは、LDAPベース検索の一部としてパッケージ化されます(ベースDNは、テストされているユーザー・エントリのDNです)。この時点で、ディレクトリにエントリが存在している必要はありません。検索を実行しているエンティティがパスワード・ポリシー・エントリを表示するアクセス権を持つ場合、このコントロールを渡すと、適用されるパスワード・ポリシーが記述されたLDAPエントリが返されます。オプションのtestPasswordパラメータとして望ましいパスワードを指定すると、ディレクトリ・サーバーはレスポンス・コントロール2.16.840.1.113894.1.8.32を返します。 |
2.16.840.1.113894.1.8.36 |
DelSubtreeControl |
このコントロールが削除操作とともに送信された場合、指定されたDN以下のサブツリーすべてが削除されます。この操作を実行できるのは必要な権限を持つユーザーです。 |
1.3.6.1.1.21.2 |
Transaction Specification Control |
このコントロールの値であるトランザクション識別子により操作とトランザクションの関連を示すLDAPコントロールです。このcriticalityは |
表3-2 Oracle Internet Directoryでサポートされているレスポンス・コントロール
オブジェクト識別子 | 名前 | 説明 |
---|---|---|
2.16.840.1.113730.3.4.10 |
OID_SEARCH_VLV_RES_CONTROL |
サーバーは、OID_SEARCH_VLV_REQ_CONTROL 2.16.840.1.113730.3.4.9に応答してこのコントロールを返します。 |
2.16.840.1.113894.1.8.7 |
OID_PASSWORD_EXPWARNING_CONTROL |
パスワード・ポリシー・コントロール。pwdExpireWarning属性が有効化されていて、クライアントからリクエスト・コントロールが送信された場合にサーバーが送信するレスポンス・コントロール。レスポンス・コントロール値には、パスワードの有効期限を表す秒単位の時間が含まれます。 |
2.16.840.1.113894.1.8.8 |
OID_PASSWORD_GRACELOGIN_CONTROL |
パスワード・ポリシー・コントロール。猶予期間ログインが構成されていて、クライアントからリクエスト・コントロールが送信された場合にサーバーが送信するレスポンス・コントロール。レスポンス・コントロール値には、猶予期間ログインの残数が含まれます。 |
2.16.840.1.113894.1.8.9 |
OID_PASSWORD_MUSTCHANGE_CONTROL |
パスワード・ポリシー・コントロール。強制パスワードのリセットが有効化されていて、クライアントからリクエスト・コントロールが送信された場合にサーバーが送信するレスポンス・コントロール。クライアントは、ユーザーがこのコントロールを受信する際にパスワードの変更を強制する必要があります。 |
2.16.840.1.113894.1.8.15 |
OID_DYNAMIC_VERIFIER_RESPONSE_CONTROL |
エラーが発生した場合にサーバーがクライアントに送信するレスポンス・コントロール。レスポンス・コントロールにはエラー・コードが含まれています。 |
2.16.840.1.113894.1.8.32 |
PasswordValidationControl |
必要なパスワードがオプションのtestPasswordパラメータとして指定されると、サーバーはコントロール2.16.840.1.113894.1.8.29に応答してこのコントロールを返します。クライアント・アプリケーションはvalidationResultを解析して、サーバーがパスワードを受け入れられるかどうか(成功)、またはパスワードが拒否された理由を判断できます。userpasswordに対するLDAP変更操作が失敗したときに生成されるタイプと同じエラー・メッセージが値として返されます。 |
使用しているOracle Internet Directoryインストールで使用可能なコントロールを確認するには、次のように入力します。
ldapsearch -p port -b "" -s base "objectclass=*"
supportedcontrol=
で始まるエントリを探します。
多くの場合、アプリケーションはエンド・ユーザーの代理を務めることが必要になる操作を実行する必要があります。たとえば、エンド・ユーザーのリソース・アクセス記述子を取得する場合などです。(リソース・アクセス記述子については、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の概要の章を参照してください。)
プロキシ・スイッチは、実行時にJNDIコンテキストで行われます。LDAP v3の機能であるプロキシは、InitialDirContext
のサブクラスInitialLdapContext
を使用しないと実行できません。Oracleの拡張機能oracle.ldap.util.jndi.ConnectionUtil
を使用して接続を確立する場合(後述の例)、InitialLdapContext
が常に戻されます。JNDIを使用して接続を確立する場合は、InitialLdapContext
が戻されるようにしてください。
注意: エンド・ユーザーへのプロキシ・スイッチを実行するには、ユーザーの識別名が必要です。 サブスクライバからフェッチしたUserオブジェクトがすでに存在する場合、次のコード断片で示すように、ユーザーの識別名を使用できます。 //User user = subscriber.getUser(...); user.getDn(); Userオブジェクトが存在しない場合は、次のコード断片で示すように、ユーザ名、UID、SAMアカウント名またはKerberosプリンシパルから作成できます。 User user = new User(dirCtx, idType, userIdValue, subscriber, true); // idType can be Util.IDTYPE_SIMPLE / Util.IDTYPE_GUID / Util.IDTYPE_WINDOWS / Util.IDTYPE_KERB_PRINCIPALuser.getDn(); |
次のコードは、プロキシ・スイッチがどのように行われるかを示しています。
import oracle.ldap.util.jndi.*; import javax.naming.directory.*; import javax.naming.ldap.*; import javax.naming.*; public static void main(String args[]) { try{ InitialLdapContext appCtx=ConnectionUtil.getDefaultDirCtx(args[0], // host args[1], // port args[2], // DN args[3]; // pass) // Do work as application // . . . String userDN=null; // assuming userDN has the end user DN value // Now switch to end user ctx.addToEnvironment(Context.SECURITY_PRINCIPAL, userDN); ctx.addToEnvironment("java.naming.security.credentials", ""); Control ctls[] = { new ProxyControl() }; ((LdapContext)ctx).reconnect(ctls); // Do work on behalf of end user // . . . } catch(NamingException ne) { // javax.naming.NamingException is thrown when an error occurs } }
前述のコードのProxyControl
クラスは、javax.naming.ldap.Control
を実装します。LDAPコントロールの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のLDAPコントロールに関する項を参照してください。次に、ProxyControl
クラスの例を示します。
import javax.naming.*; import javax.naming.ldap.Control; import java.lang.*; public class ProxyControl implements Control { public byte[] getEncodedValue() { return null; } public String getID() { return "2.16.840.1.113894.1.8.1"; } public boolean isCritical() { return false; } }
LDAP認証APIを変更して、アプリケーション・パスワードを動的に(ユーザーがアプリケーションにログインするときに)生成できます。この機能は、パスワード・ベリファイアのパラメータを実行時にのみ指定するアプリケーションの必要性を満たすことを目的としています。
この項の項目は次のとおりです。
パスワード・ベリファイアを動的に作成するには、LDAP認証APIのldap_search
またはldap_modify
を変更して、パスワード・ベリファイアのパラメータを含める必要があります。LDAPコントロールDynamicVerifierRequestControl
は、このパラメータを転送するためのメカニズムです。これは、パスワード・ベリファイアの静的作成に使用されるパスワード・ベリファイア・プロファイルにかわるものです。ただし、動的ベリファイアの場合にも、静的ベリファイアと同様に、ディレクトリ属性orclrevpwd
(同期)およびorclunsyncrevpwd
(非同期)が存在し、これらの属性に値が移入されていることが必要になります。
orclrevpwd
を生成する場合は、ユーザー・レルムにあるパスワード・ポリシー・エントリのorclpwdencryptionenable
属性を1
に設定する必要があることに注意してください。この属性を設定しないと、ユーザーが認証を受けようとしたときに例外がスローされます。orclunsyncrevpwd
を生成するには、暗号タイプ3DESをエントリcn=defaultSharedPINProfileEntry,cn=common,cn=products,cn=oraclecontext
に追加する必要があります。
DynamicVerifierRequestControl controlOid: 2.16.840.1.113894.1.8.14 criticality: FALSE controlValue: an OCTET STRING whose value is the BER encoding of the following type: ControlValue ::= SEQUENCE { version [0] crypto [1] CHOICE OPTIONAL { SASL/MD5 [0] LDAPString, SyncML1.0 [1] LDAPString, SyncML1.1 [2] LDAPString, CRAM-MD5 [3] LDAPString }, username [1] OPTIONAL LDAPString, realm [2] OPTIONAL LDAPString, nonce [3] OPTIONAL LDAPString, }
コントロール構造のパラメータは出現順に渡す必要があることに注意してください。表3-3に、このパラメータを定義します。
表3-3 DynamicVerifierRequestControlのパラメータ
パラメータ | 説明 |
---|---|
controlOID |
コントロール構造を一意に識別する文字列。 |
crypto |
ハッシング・アルゴリズム。コントロール構造に指定された4種類のうちいずれかを選択します。 |
username |
ユーザーの識別名(DN)。この値は常に含める必要があります。 |
realm |
ランダムに選択されたレルム。ユーザーが属するアイデンティティ管理レルムの場合があります。アプリケーション・レルムの場合もあります。SASL/MD5アルゴリズムにのみ必要です。 |
nonce |
ランダムに選択された任意の値。SYNCML1.0とSYNCML1.1に必要です。 |
表3-4に、動的パスワード・ベリファイアの作成に使用される4種類のハッシング・アルゴリズムを示します。この表には、各アルゴリズムの構成要素として使用されるパラメータも示します。ユーザー名とパスワードのパラメータはすべてのアルゴリズムで使用しますが、realm
およびnonce
パラメータを使用するかどうかはアルゴリズムによって異なることに注意してください。
パスワード・ベリファイアを動的に生成する必要のあるアプリケーションの場合、認証APIにDynamicVerifierRequestControl
を組み込む必要があります。ldap_search
またはldap_compare
にcontrolOID
とコントロール値をパラメータとして含めることが必要です。これらのAPIは、第3.4.2項「DynamicVerifierRequestControlの構文」に示したコントロール値をBERエンコードし、controlOID
とコントロール値の両方をディレクトリ・サーバーに送信する必要があります。
アプリケーションでユーザーを認証するには、ldap_search
を使用してコントロール構造を渡します。ldap_search
を使用する場合、ディレクトリは作成したパスワード・ベリファイアをクライアントに渡します。
ldap_search
には、ユーザーの識別名、controlOID
およびコントロール値を含める必要があります。ユーザーのパスワードがシングル・サインオン・パスワードの場合、渡される属性はauthpassword
です。パスワードが数値PINやその他の非同期パスワードの場合、渡される属性はorclpasswordverifier;orclcommonpin
です。
エラーが発生すると、ディレクトリはLDAPコントロールDynamicVerifierResponseControl
をクライアントに送信します。このレスポンス・コントロールにはエラー・コードが含まれています。レスポンス・コントロールが送信するエラー・コードの詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のトラブルシューティングに関する章を参照してください。
LDAP検索ファンクションに渡すことのできるサーバー・コントロールの1つはCONNECT_BY
です。これは、Oracle固有のコントロールで、階層全体を検索できます。たとえば、CONNECT_BY
コントロールを使用せずにgroup1
のすべてのユーザーを検索すると、検索ファンクションはgroup1
の直接のメンバーであるユーザーのみを返します。CONNECT_BY
コントロールを渡すと、検索ファンクションは階層全体を検索します。group2
がgroup1
のメンバーの場合には、検索でgroup2
のユーザーも返されます。group3がgroup2
のメンバーの場合には、検索でgroup3
のユーザーも返されます。
10g(10.1.4.0.1)では、CONNECT_BY
コントロールは次の2点において拡張されています。
階層をどちらの方向にも検索できるようになりました。つまり、エントリが含まれているすべてのコンテナとエントリ内に含まれているすべてのコンテナを検索できます。
検索する階層のレベル数を指定できるようになりました。
以前のリリースでは、CONNECT_BY
コントロールには値は必要ありませんでした。新機能により、次に示す値のいずれか、または両方をCONNECT_BY
に渡すことができるようになりました。
階層構成属性: 検索対象の属性を表す文字列。この値は、エントリが含まれるすべてのコンテナを検索する場合にのみ必要です。エントリ内に含まれるコンテナを検索する場合、この情報は検索フィルタによって提供されるため、この値を指定する必要はありません。
レベル数: 検索するレベル数を表す整数。値を0
にすると、すべてのレベルが検索されます。デフォルト値は0
のため、すべてのレベルを検索する場合にはこの値を渡す必要はありません。
例1: ユーザーが属するすべてのグループの検索
(member=cn=jsmith)
などのフィルタを使用した場合、階層構成属性メンバーは検索フィルタに含まれているため指定する必要はありません。デフォルトは0
であるため、レベル数の値を渡す必要はありません。
例2: ユーザーが直接属するグループのみの検索
例1と同じフィルタを使用し、整数のコントロール値1
を渡します。結果は、CONNECT_BY
コントロールを使用しなかった場合と同じになります。
例3: グループのすべてのメンバーの検索
この場合、検索フィルタには(objectclass=*)
が指定されていますが、group1
のすべてのメンバーを検索する場合、階層全体を検索するための属性はmember
です。この検索では、文字列"member"
を階層構成属性として渡す必要があります。デフォルトは0
であるため、レベル数の値を渡す必要はありません。
例4: ユーザーのすべてのマネージャの検索
ユーザーjsmith
のすべてのマネージャを検索する点を除き、例3に似ているため、階層全体を検索するための属性はmanager
です。この検索では、文字列"manager"
を渡します。デフォルトは0
であるため、レベル数の値を渡す必要はありません。
Oracle Internet Directory 10g(10.1.4.0.1)では、IETF RFC 2891で説明されているように、LDAP検索からソート済の結果を取得できるようになりました。タイプ1.2.840.113556.1.4.473のコントロールを検索ファンクションに渡すことでソート済の結果をリクエストします。サーバーにより戻されるレスポンス・コントロールは、タイプ1.2.840.113556.1.4.474です。エラー処理およびその他の詳細は、RFC 2891を参照してください。
関連項目:
|
ソートおよびページングを一緒に使用できます。
RFC 2891のOracle Internet Directory実装には、次の制限事項があります。
コントロール値でサポートされているのは、1つのattributeType
のみです。
各属性のスキーマに定義されているデフォルトの順序付けルールが使用されます。
言語ソートはサポートされていません。
デフォルトのソート順序は昇順です。
ソート・キーが複数の値を含む属性で、エントリにもその属性に対して複数の値があり、ソート順序に影響するその他のコントロールが存在しない場合、サーバーでは、その属性の順序付けルールに応じて最後の値が使用されます。
ソート属性は検索可能である必要があります。つまり、Oracle Internet Directoryでカタログ化されている属性である必要があります。
Oracle Internet Directory 10g(10.1.4.0.1)では、IETF RFC 2696で説明されているように、LDAP検索からページング済の結果を取得できるようになりました。タイプ1.2.840.113556.1.4.319のコントロールを検索ファンクションに渡すことでソート済の結果をリクエストします。詳細は、RFC 2696を参照してください。
関連項目:
|
ソートおよびページングを一緒に使用できます。
RFC 2696のOracle Internet Directory実装には、次の制限事項があります。
ACIにより検索結果から複数のエントリが部分的にブロックされた場合、ページ内のエントリ数はページ・サイズより少なくなる可能性があります。
ページングのレスポンス・コントロールには、合計のエントリ件数の見積りは含まれません。戻り値は常に0です。
Oracle Internet Directoryは、パスワードを制御する一連の豊富なポリシーをネイティブにサポートします。『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のパスワード・ポリシーの管理に関する項を参照してください。実行時にディレクトリのパスワード・ポリシーと対話するようにアプリケーションを設計し、結果として生じるイベントを正常に処理する必要があります。Oracle Internet Directoryには、クライアントがサーバーのパスワード・ポリシーと対話できる複数のメカニズムが用意されています。
この項の項目は次のとおりです。
使用するアプリケーションでディレクトリ内の独自のユーザーをプロビジョニングする場合、新しいユーザー・エントリをディレクトリにコミットする前に、パスワードがサーバーで受け入れられるかどうかをテストする必要があります。次のカスタム・コントロールを使用して、パスワードをテストできます。
EffectivePolicyControl ::= SEQUENCE { controlType 2.16.840.1.113894.1.8.29, criticality BOOLEAN DEFAULT FALSE, controlValue testPassword } testPassword ::= OCTET STRING (optional)
このコントロールをLDAPベース検索の一部としてパッケージ化します。このベースDNは、テストされているユーザー・エントリのDNです。この時点で、ディレクトリにエントリが存在している必要はありません。サーバーは検索を実行しているエンティティがパスワード・ポリシー・エントリを表示するアクセス権を持つ場合に、適用されるパスワード・ポリシーを記述するLDAPエントリを戻します。希望のパスワードをオプションのtestPasswordパラメータとして指定すると、ディレクトリ・サーバーが次のレスポンス・コントロールを戻します。
PasswordValidationControl ::= SEQUENCE { controlType 2.16.840.1.113894.1.8.32, criticality BOOLEAN DEFAULT FALSE, controlValue validationResult } validationResult ::= OCTET STRING
クライアント・アプリケーションはvalidationResult
を解析して、サーバーがパスワードを受け入れられるかどうか(成功)、またはパスワードが拒否された理由を判断できます。エラー・メッセージは、userpasswordに対するLDAP変更操作が失敗したときに生成されるものと同じです。
ユーザー認証の使用例は、大きくは次の2つの主なカテゴリに分類されます。
前者は、標準のuserpassword
属性に対して実行される認証です。認証プロセス全体はディレクトリ・サーバー内で行われ、アカウントの様々な状態を必要に応じて更新するために適切な内部イベントが生成されます。
後者は、パスワード・ベリファイアなどのその他の認証トークンに対して実行される認証で、ユーザー・エントリの一部として管理されます。トークンは、アプリケーションによって取得されます。認証プロセスはアプリケーション内で、ディレクトリ・サーバーの範囲外で行われます。そのため、LDAP検索ベース認証では、ディレクトリは、認証の結果を暗黙的に把握しません。
次の2つの項では、この2種類の認証シナリオを扱う場合のアプリケーション統合のベスト・プラクティスについて説明します。
このタイプの認証が従来使用されるのは、単純なプロトコルの場合です。アプリケーションは、サーバーに対してLDAPのバインドまたは比較操作のいずれかを実行し、成功したかどうかを確認します。それ以外の場合はすべて認証が失敗したものとして扱います。
認証が失敗すると、アプリケーションはその理由を究明し、状況を修正するアクションを実行するか、原因をエンド・ユーザーに公開してエンド・ユーザーが状況を修正する措置を取ることができるようにします。これにより、ユーザーの経験が増し、管理オーバーヘッドが軽減されます。LDAPバインド/比較操作時にこのような原因の情報を取得するには、次のLDAPコントロールを使用します。
PasswordStatusRequestControl ::= SEQUENCE { controlType 2.16.840.1.113894.1.8.6, criticality BOOLEAN DEFAULT FALSE, }
このコントロールがLDAPバインド/比較操作リクエストの一部としてパッケージ化される場合、このコントロールはサーバーで処理され、レスポンス・コントロールが生成されます。実際のレスポンス・コントロールは状況に応じて異なります。表3-2「Oracle Internet Directoryでサポートされているレスポンス・コントロール」のパスワードのレスポンス・コントロールを参照してください。状況とは、差し迫ったパスワードの有効期限、残りの猶予期間ログインの数、パスワードの期限切れ、アカウントのロックなどです。
アプリケーションがディレクトリから認証トークンを取得した後に独自で認証を行った場合、状態関連ポリシーはすべて無効となります。これらのポリシーが無効の場合、アカウント・ロックなどのシナリオを実施できず、期限切れアカウントのユーザーがアプリケーションに対して認証される可能性があります。
Oracle Internet Directoryには、このようなアプリケーションが、ディレクトリ・サーバーにすでに存在する状態に関連するポリシー・フレームワークを利用できるようにする2つのメカニズムがあります。これらについて次の項で説明します。
この機能は、次のカスタム・コントロールによって有効になります。
AccountStatusRequestControl ::= SEQUENCE { controlType 2.16.840.1.113894.1.8.16, criticality BOOLEAN DEFAULT FALSE, }
このコントロールが認証プロセスに関連付けられたLDAP検索操作とともにパッケージ化されている場合、Oracle Internet Directoryはこのコントロールを処理してレスポンス・コントロールを戻し、アカウントのロックアウトやパスワードの有効期限切れなどのアカウント状態に関連する情報をクライアント・アプリケーションに知らせます。表3-2「Oracle Internet Directoryでサポートされているレスポンス・コントロール」のパスワード・レスポンス・コントロールを参照してください。アプリケーションは結果の解析および実施が可能になります。
ポリシーがどのようにしてクライアント・アプリケーションで実施できるかという問題はこれで解決されますが、その他の基本的なアプリケーションの要件は次のようになります。
Oracle Internet Directoryでは、仮想属性orclAccountStatusEvent
によってこの機能が提供されます。
この属性は、すべてのユーザー・エントリで仮想属性として使用できます。つまり、ディスクのフットプリントがありません。ただし、これに対して変更操作を適用できます。ディレクトリには、デフォルトでこの属性に対するアクセス制限があるため、ディレクトリ管理者に、関連するユーザー群について、属性に対するアプリケーションのアイデンティティ書込み権限を付与するように依頼する必要があります。
認証の成功または失敗をディレクトリに伝えるには、UserAccountEventを保持するようにこの属性を変更します。次のLDIFでこれを示します。
dn: UserDN changetype: modify replace: orclAccountStatusEvent orclAccountStatusEvent: UserAccountEvent
Oracle Internet Directoryでは、UserAccountEventの次の値が認識されています。
UserAccountEvent = 1 (Authentication Success) UserAccountEvent = 2 (Authentication Failure)
Oracle Internet Directoryがこれらのイベントを受信すると、LDAPバインドまたは比較操作に対する認証が成功または失敗したときに起動される論理を起動するため、必要なアカウント状態を更新します。
この方法では、Oracle Internet Directoryで使用可能な、既存のアカウント状態に関連するインフラストラクチャを使用してアプリケーションを保護できます。
ユーザー・アカウントのメンテナンスと、パスワード・ポリシーとのやりとりは、定期的なパスワード変更の前後で主に行われます。アプリケーションで前述のEffectivePolicyControlを使用して有効なポリシーを取得し、そのポリシーを解析して、エンド・ユーザーをパスワード構成要件を示すメッセージを生成することをお薦めします。さらに、このコントロールにカプセル化されたテスト機能を使用して、エンド・ユーザーに変更の失敗の原因を示します。アプリケーション内でこのような状況に対処することで、管理オーバーヘッドが軽減されます。
次に、次回のログイン時にユーザーがパスワードを変更する必要がある使用例が多数あります。Oracle Internet Directoryは、pwdmustchangeパスワード・ポリシー要素が有効化されていて、userpasswordが非自己変更される場合にこの要件をネイティブにトリガーします。ただし、この要件の明示的なトリガーが必要なイベントでは、Oracle Internet Directoryは、前述のorclAccountStatusEvent属性による要件もサポートしています。関連するイベントは次のとおりです。
UserAccountEvent = 3 (Require Password Reset on next Logon) UserAccountEvent = 4 (Clear Password Reset Requirement)
アプリケーションに管理インタフェースがある場合はこの機能が望ましく、この機能は管理者に対して公開できます。