| Oracle® Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド 11g リリース1 (11.1.1) B56242-07 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド 11g リリース1 (11.1.1) B56242-07 |
|
前 |
次 |
この章では、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.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 |
第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でサポートされているレスポンス・コントロール
| オブジェクト識別子 | 名前 | 説明 |
|---|---|---|
|
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 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とコントロール値をパラメータとして含めることが必要です。これらは、第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管理者ガイド』のトラブルシューティングに関する章を参照してください。
パスワード・ベリファイアをディレクトリで動的に作成するには、アプリケーションのアイデンティティをディレクトリ管理者のVerifierServicesグループに追加する必要があります。このタスクを実行しないと、ディレクトリはLDAP_INSUFFICIENT_ACCESSエラーを戻します。
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を参照してください。
|
関連項目: 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でカタログ化されている属性である必要があります。
Oracle Internet Directory 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」。 |
ソートおよびページングを一緒に使用できます。
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)
アプリケーションに管理インタフェースがある場合はこの機能が望ましく、この機能は管理者に対して公開できます。
