3 LDAPプロトコルに対する拡張機能
次の各トピックでは、LDAPプロトコルの拡張機能の詳細について説明します。
SASL認証メカニズムの使用方法
Oracle Internet Directoryは、SASL Digest-MD5認証とSASL外部認証をサポートします。
次の各項で2つの方法について説明します。
SASL Digest-MD5認証メカニズムの使用
SASL Digest-MD5認証は、LDAPバージョン3サーバー(RFC 2829)で必要な認証メカニズムです。LDAPバージョン2では、Digest-MD5はサポートされません。
Digest-MD5認証メカニズムを使用するには、Java APIまたはC APIのいずれかを使用して認証を設定できます。C APIでサポートされているのはauth
モードのみです。
関連項目:
-
「Digest-MD5を使用したSASL認証の実行」および「SASL Digest-MD5のauth-intモードおよびauth-confモードの使用方法」のJava固有の情報を参照してください。
-
C固有の情報は、「ディレクトリに対する認証」および「Oracleの拡張機能を使用したSASL認証」を参照してください
この項では、次の項目について説明します。
SASL Digest-MD5メカニズムのモード
SASL Digest-MD5メカニズムには3つのモードがあり、それぞれが異なるセキュリティ・レベルまたはQuality of Protection(QoP)を表しています。
次の表に、SASL Digest-MD5のモードの説明を示します。
表3-1 SASL Digest-MD5のモード
モード | 説明 |
---|---|
|
認証のみ。初期バインドにのみ認証が必要です。その後、情報はクリアテキストで渡されます。 |
|
認証および整合性。初期バインドには認証が必要です。その後、チェックサムを使用してデータの整合性が保証されます。 |
|
認証および機密保護。初期バインドには認証が必要です。その後、暗号化を使用してデータが保護されます。次に示す5つの暗号方式を使用できます。
|
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
モードのみです。
SASL Digest-MD5メカニズムの使用方法
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のWebサイト(
http://www.ietf.org
)。 -
OpenLDAPのクラス・ライブラリ(
http://www.openldap.org
)。
SASL Digest-MD5認証メカニズムに関連するステップ
SASL Digest-MD5認証には多くのステップが伴い、最後にディレクトリ・サーバーによってクライアントのレスポンスが検証されます。
次のステップは、SASL Digest-MD5認証の詳細を示しています。
-
ディレクトリ・サーバーは、サポートする各種認証オプションと特別なトークンを含むデータをLDAPクライアントに送信します。
-
クライアントは、選択した認証オプションを示す暗号化されたレスポンスを送信して応答します。レスポンスは、クライアントがそのパスワードを知ることがないように暗号化されます。
-
ディレクトリ・サーバーは、クライアントのレスポンスを復号化し、検証します。
SASL外部認証メカニズムの理解
Oracle Internet Directoryは、SSL相互接続を介してSASL外部メカニズムを提供します。認可アイデンティティ(識別名)は、SSLネットワーク協定時のクライアント証明書から作成されます。
次の文は、Internet Engineering Task ForceのRFC 2222のセクション7.4を翻訳したものです。
外部認証に関連付けられたメカニズム名はEXTERNALです。クライアントは、認可アイデンティティの入った初期レスポンスを送信します。サーバーは、SASLの外部にある情報を使用して、クライアントが認可アイデンティティとして認証を行う権限を持っているかを判断します。クライアントにその権限がある場合、サーバーは認証情報の交換が正常に終了したことを示します。クそれ以外の場合、サーバーは失敗したことを示します。
IPsecやSSL/TLSなどのシステムによりこの外部情報が提供されます。
クライアントが認可アイデンティティとして空の文字列を送信した(クライアントの認証資格証明から作成された認可アイデンティティをリクエストする)場合、認可アイデンティティは外部認証を提供するシステムの認証資格証明から作成されます。
Oracle Internet Directoryのコントロールの理解
RFC 2251で定義されているように、LDAPv3プロトコルではコントロールによる拡張機能が許可されています。Oracle Internet Directoryでは複数のコントロールをサポートしています。一部は標準で、RFCで説明されています。
階層検索用のCONNECT_BYコントロールなど、それ以外のコントロールはOracle固有です。コントロールは、JavaまたはCで使用できます。
この項では、次の項目について説明します。
Oracle Internet Directoryのコントロールの概要
コントロールは、サーバーに送信したり、LDAPメッセージとともにクライアントに戻すことができます。このようなコントロールは、サーバー・コントロールと呼ばれます。LDAP APIは、クライアント・コントロールを使用してクライアント側の拡張メカニズムもサポートします。このコントロールは、LDAP APIの動作にのみ影響し、サーバーに送信されることはありません。
CでのLDAPコントロールの使用の詳細は、「コントロールの使用」を参照してください
JavaにおけるLDAPコントロールの使用の詳細は、http://www.oracle.com/technetwork/java/jndi/index.html
のJNDIパッケージjavax.naming.ldap
に関するドキュメントを参照してください
Oracle Internet Directoryでサポートされるコントロール
Oracle Internet Directoryではリクエスト・コントロールとレスポンス・コントロールをサポートしています。
Oracle Internet Directoryでサポートされているリクエスト・コントロール
表3-2に、Oracle Internet Directoryでサポートされているリクエスト・コントロールをリストします
表3-2 Oracle Internet Directoryでサポートされているリクエスト・コントロール
オブジェクト識別子 | 名前 | 説明 |
---|---|---|
2.16.840.1.113730.3.4.18 |
プロキシ認可 |
LDAPクライアント・アプリケーションは、その独自のアイデンティティでOracle Internet Directoryサーバーにバインドし、他のユーザーや複数のユーザーのかわりに操作を実行できます。 このコントロールによって、特に複数のユーザーのかわりに実行されるプロキシ操作でパフォーマンスが向上します。LDAP操作では、各ユーザーのリバインドは不要です。 たとえば、次の使用例について考えてみます。
プロキシ認可コントロールの考慮事項は、次のとおりです。
|
1.3.6.1.4.1.42.2.27.8.5.1 |
パスワード・ポリシー |
LDAPクライアントは、ユーザーの現在のパスワード・ポリシー状態についてOracle Internet Directoryサーバーからの情報をリクエストできます。パスワード・ポリシーが適用可能な場合、クライアントは、次の操作でこのコントロールを送信できます。
パスワード・ポリシー・リクエスト・コントロールには パスワード・ポリシーは、通常、LDAP簡易認証メソッドまたはパスワード・ベースのSimple Authentication and Security Layer (SASL)認証の単一値属性 詳細は、次の場所にある「Password Policy for LDAP Directories」を参照してください。
|
2.16.840.1.113730.3.4.3 |
永続検索 |
LDAPクライアントは、Oracle Internet Directoryサーバーに永続検索リクエストを送信できます。 永続検索操作は、初期検索の結果がサーバーからクライアントに返された後も継続する拡張検索です。初期検索の終了後も、サーバーに対する接続は、クライアントが操作をバインド解除するか中止するまで維持されます。クライアントは、検索範囲内のエントリの変更を追跡し、エントリが変更されている場合、エントリ変更通知レスポンス・コントロールを受信できます。 このコントロールの定義は次のとおりです。 PersistentSearch ::= SEQUENCE { controlType 2.16.840.1.113730.3.4.3 changeTypes INTEGER, changesOnly BOOLEAN, returnECs BOOLEAN } これらのフィールドの説明は、次を参照してください。 |
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 |
「CONNECT_BYコントロールを使用した階層検索の実行」を参照してください。 |
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 |
これは、トランザクションIDをコントロールの値とし、これを利用して操作とトランザクションの関連付けを指定するLDAPコントロールです。この重大性は |
Oracle Internet Directoryでサポートされているレスポンス・コントロール
表3-3に、Oracle Internet Directoryでサポートされているレスポンス・コントロールをリストします
表3-3 Oracle Internet Directoryでサポートされているレスポンス・コントロール
オブジェクト識別子 | 名前 | 説明 |
---|---|---|
1.3.6.1.4.1.42.2.27.8.5.1 |
パスワード・ポリシー |
Oracle Internet Directoryサーバーがパスワード・ポリシー・リクエスト・コントロールに応答してLDAPクライアントに返すレスポンス・コントロール。レスポンス制御の値は次のようにエンコードされます: PasswordPolicyResponseValue ::= SEQUENCE { warning [0] CHOICE { timeBeforeExpiration [0] INTEGER (0 .. maxInt), graceAuthNsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL, error [1] ENUMERATED { passwordExpired (0), accountLocked (1), changeAfterReset (2), passwordModNotAllowed (3), mustSupplyOldPassword (4), /*currently not supported*/ insufficientPasswordQuality (5), passwordTooShort (6), passwordTooYoung (7), passwordInHistory (8) } OPTIONAL } Oracle Internet Directoryで サーバーは、パスワード・ポリシー・レスポンス・コントロールでエラーまたは警告のいずれかを送信します(両方ではありません)。エラー・コードの説明は、次を参照してください。
コントロールの重大性は、レスポンスでは返されません。パスワード・ポリシーの違反がない場合、サーバーは、レスポンスを送信しません。 |
2.16.840.1.113730.3.4.7 |
エントリ変更通知 |
このコントロールの定義は次のとおりです。 EntryChangeNotification ::= SEQUENCE { controlType 2.16.840.1.113730.3.4.7 changeType ENUMERATED { add (1), delete (2), modify (4), modDN (8) }, previousDN LDAPDN OPTIONAL, -- modifyDN ops. only changeNumber INTEGER OPTIONAL -- if supported } これらのフィールドの説明は、次を参照してください。 |
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.20 |
OID_PWDEXPIRED_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 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の構文
LDAPコントロールDynamicVerifierRequestControl
は、パスワード・ベリファイアのパラメータを転送するためのメカニズムです。
リクエスト・コントロールは次のようになります。
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-4に、このパラメータを定義します。
表3-4 DynamicVerifierRequestControlのパラメータ
パラメータ | 説明 |
---|---|
controlOID |
コントロール構造を一意に識別する文字列。 |
crypto |
ハッシング・アルゴリズム。コントロール構造に指定された4種類のうちいずれかを選択します。 |
username |
ユーザーの識別名(DN)。この値は常に含める必要があります。 |
realm |
ランダムに選択されたレルム。ユーザーが属するアイデンティティ管理レルムの場合があります。アプリケーション・レルムの場合もあります。SASL/MD5アルゴリズムにのみ必要です。 |
nonce |
ランダムに選択された任意の値。SYNCML1.0とSYNCML1.1に必要です。 |
ハッシング・アルゴリズムに必要なパラメータ
動的パスワード・ベリファイアの作成には、ハッシング・アルゴリズムが使用されます。
表3-5に、4つのハッシング・アルゴリズムと、各アルゴリズムの構成要素として使用されるパラメータを示します。ユーザー名とパスワードのパラメータはすべてのアルゴリズムで使用しますが、realm
およびnonce
パラメータを使用するかどうかはアルゴリズムによって異なることに注意してください。
表3-5 ハッシング・アルゴリズムに必要なパラメータ
アルゴリズム | 必要なパラメータ |
---|---|
SASL/MD5 |
|
SYNCML1.0 |
|
SYNCML1.1 |
|
CRAM-MD5 |
|
動的パスワード・ベリファイアのリクエスト・コントロールの理解
パスワード・ベリファイアを動的に生成する必要のあるアプリケーションの場合、認証APIにDynamicVerifierRequestControl
を組み込む必要があります。
ldap_search
またはldap_compare
にcontrolOID
とコントロール値をパラメータとして含めることが必要です。これらにより、「DynamicVerifierRequestControlの構文」に示したコントロール値がBERエンコードされる必要があります。その後、controlOID
とコントロール値の両方がディレクトリ・サーバーに送信される必要があります。次の各項では、パラメータの詳細について説明します。
ldap_searchが使用される場合に必要なパラメータについて
アプリケーションでユーザーを認証するには、ldap_search
を使用してコントロール構造を渡します。ldap_search
を使用する場合、ディレクトリは作成したパスワード・ベリファイアをクライアントに渡します。
ldap_search
には、ユーザーの識別名、controlOID
およびコントロール値を含める必要があります。ユーザーのパスワードがシングル・サインオン・パスワードの場合、渡される属性はauthpassword
です。パスワードが数値PINやその他の非同期パスワードの場合、渡される属性はorclpasswordverifier;orclcommonpin
です。
動的パスワード・ベリファイアのレスポンス・コントロールの理解
エラーが発生すると、ディレクトリはLDAPコントロールDynamicVerifierResponseControl
をクライアントに送信します。このレスポンス・コントロールにはエラー・コードが含まれています。
レスポンス・コントロールが送信するエラー・コードについて学習するには、Oracle Fusion Middleware Oracle Internet Directory管理者ガイドの動的パスワード・ベリファイアのトラブルシューティングに関する項を参照してください。
CONNECT_BYコントロールを使用した階層検索の実行
LDAP検索ファンクションに渡すことのできるサーバー・コントロールの1つはCONNECT_BY
です。これは、Oracle固有のコントロールで、階層全体を検索できます。
たとえば、CONNECT_BY
コントロールを使用せずにgroup1
のすべてのユーザーを検索すると、検索ファンクションはgroup1
の直接のメンバーであるユーザーのみを返します。CONNECT_BY
コントロールを渡すと、検索ファンクションは階層全体を検索します。group2
がgroup1
のメンバーの場合には、検索でgroup2
のユーザーも返されます。group3がgroup2
のメンバーの場合には、検索でgroup3
のユーザーも返されます。次の各項では、検索ファンクションの詳細について説明します。
CONNECT_BYコントロールの特性について
CONNECT_BY
コントロールは、エントリが含まれているすべてのコンテナの検索に使用されます。
10g(10.1.4.0.1)では、CONNECT_BY
コントロールは次の2点において拡張されています。
-
階層をどちらの方向にも検索できるようになりました。つまり、エントリが含まれているすべてのコンテナとエントリ内に含まれているすべてのコンテナを検索できます。
-
検索する階層のレベル数を指定できるようになりました。
CONNECT_BYコントロールの値フィールド
以前のリリースでは、CONNECT_BY
コントロールには値は必要ありませんでした。
新機能により、次に示す値のいずれか、または両方をCONNECT_BY
に渡すことができるようになりました。
表3-6 Connect_Byコントロールの値
値 | 説明 |
---|---|
階層構成属性 |
検索対象の属性を示す文字列。この値は、エントリが含まれるすべてのコンテナを検索する場合にのみ必要です。エントリ内に含まれるコンテナを検索する場合、この情報は検索フィルタによって提供されるため、この値を指定する必要はありません。 |
レベル数 |
検索するレベル数を表す整数。値を |
CONNECT_BYコントロールの使用方法
CONNECT_BYコントロールを使用すると、ユーザーおよびグループに関連するすべての情報を検索できます。
次の各トピックでは、CONNECT_BYコントロールの使用方法について説明します。
ユーザーが属するすべてのグループの検索
(member=cn=jsmith)
などのフィルタを使用した場合、階層構成属性メンバーは検索フィルタに含まれているため指定する必要はありません。デフォルトは0
であるため、レベル数の値を渡す必要はありません。
グループのすべてのメンバーの検索
この場合、検索フィルタには(objectclass=*)
が指定されていますが、group1
のすべてのメンバーを検索する場合、階層全体を検索するための属性はmember
です。この検索では、文字列"member"
を階層構成属性として渡す必要があります。デフォルトは0
であるため、レベル数の値を渡す必要はありません。
ソート済のLDAP検索結果の理解
Oracle Internet Directory g (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を参照してください。
関連項目:
http://www.ietf.org
のIETF RFC 2891「LDAP Control Extension for Server Side Sorting of Search Results」。
ソートおよびページングを一緒に使用できます。
RFC 2891のOracle Internet Directory実装には、次の制限事項があります。
-
コントロール値でサポートされているのは、1つの
attributeType
のみです。 -
各属性のスキーマに定義されているデフォルトの順序付けルールが使用されます。
-
言語ソートはサポートされていません。
-
デフォルトのソート順序は昇順です。
-
ソート・キーが複数の値を含む属性で、エントリにもその属性に対して複数の値があり、ソート順序に影響するその他のコントロールが存在しない場合、サーバーでは、その属性の順序付けルールに応じて最後の値が使用されます。
-
ソート属性は検索可能である必要があります。つまり、Oracle Internet Directoryでカタログ化されている属性である必要があります。
ページング済のLDAP検索結果の理解
Oracle Internet Directory g (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を参照してください。10g (10.1.4.0.1)では、IETF RFC 2696で説明されているように、LDAP検索からページング済の結果を取得できるようになりました。タイプ1.2.840.113556.1.4.319のコントロールを検索ファンクションに渡すことでソート済の結果をリクエストします。詳細は、RFC 2696を参照してください。
関連項目:
http://www.ietf.org
のIETF RFC 2696「LDAP Control Extension for Simple Paged Results Manipulation」。
ソートおよびページングを一緒に使用できます。
Oracle Internet Directory g (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 2696の実装には次の制限事項があります。
-
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変更操作が失敗したときに生成されるものと同じです。
ユーザー認証の処理
LDAPバインド/比較操作ベースの認証の実行
これは、標準のuserpassword
属性に対して実行される認証です。認証プロセス全体はディレクトリ・サーバー内で行われ、アカウントの様々な状態を必要に応じて更新するために適切な内部イベントが生成されます。
このタイプの認証が従来使用されるのは、単純なプロトコルの場合です。アプリケーションは、サーバーに対してLDAPのバインドまたは比較操作のいずれかを実行し、成功したかどうかを確認します。それ以外の場合はすべて認証が失敗したものとして扱います。
認証が失敗すると、アプリケーションはその理由を究明し、状況を修正するアクションを実行するか、原因をエンド・ユーザーに公開してエンド・ユーザーが状況を修正する措置を取ることができるようにします。これにより、ユーザーの経験が増し、管理オーバーヘッドが軽減されます。LDAPバインド/比較操作時にこのような原因の情報を取得するには、次のLDAPコントロールを使用します。
PasswordStatusRequestControl ::= SEQUENCE { controlType 2.16.840.1.113894.1.8.6, criticality BOOLEAN DEFAULT FALSE, }
このコントロールがLDAPバインド/比較操作リクエストの一部としてパッケージ化される場合、このコントロールはサーバーで処理され、レスポンス・コントロールが生成されます。実際のレスポンス・コントロールは状況に応じて異なります。表3-3のパスワード・レスポンス・コントロールを参照してください。状況とは、差し迫ったパスワードの有効期限、残りの猶予期間ログインの数、パスワードの期限切れ、アカウントのロックなどです。
LDAP検索操作ベースの認証の実行
これは、パスワード・ベリファイアなどのその他の認証トークンに対して実行される認証で、ユーザー・エントリの一部として管理されます。トークンは、アプリケーションによって取得されます。認証プロセスはアプリケーション内で、ディレクトリ・サーバーの範囲外で行われます。そのため、LDAP検索ベース認証では、ディレクトリは、認証の結果を暗黙的に把握しません。
アプリケーションがディレクトリから認証トークンを取得した後に独自で認証を行った場合、状態関連ポリシーはすべて無効となります。これらのポリシーが無効の場合、アカウント・ロックなどのシナリオを実施できず、期限切れアカウントのユーザーがアプリケーションに対して認証される可能性があります。
Oracle Internet Directoryには、このようなアプリケーションが、ディレクトリ・サーバーにすでに存在する状態に関連するポリシー・フレームワークを利用できるようにする2つのメカニズムがあります。これらについて次の項で説明します。
認証時の状態ポリシーの確認および実施
この機能を有効にするには、次のカスタム・コントロールを使用します。
AccountStatusRequestControl ::= SEQUENCE { controlType 2.16.840.1.113894.1.8.16, criticality BOOLEAN DEFAULT FALSE, }
このコントロールが認証プロセスに関連付けられたLDAP検索操作とともにパッケージ化されている場合、Oracle Internet Directoryはこのコントロールを処理してレスポンス・コントロールを戻し、アカウントのロックアウトやパスワードの有効期限切れなどのアカウント状態に関連する情報をクライアント・アプリケーションに知らせます。表3-3のパスワード・レスポンス・コントロールを参照してください。アプリケーションは結果の解析および実施が可能になります。
ポリシーがどのようにしてクライアント・アプリケーションで実施できるかという問題はこれで解決されますが、その他の基本的なアプリケーションの要件は次のようになります。
ディレクトリに対する認証の成功/失敗の通知
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)
アプリケーションに管理インタフェースがある場合はこの機能が望ましく、この機能は管理者に対して公開できます。