| Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド 11gリリース1（11.1.1） B56242-01 |
|
 戻る |
 次へ |
| Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド 11gリリース1（11.1.1） B56242-01 |
|
戻る |
次へ |
この章では、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コントロールの使用の詳細は、「コントロールの使用」を参照してください。
JavaにおけるLDAPコントロールの使用の詳細は、http://java.sun.com/products/jndiの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でサポートされているリクエスト・コントロール
| オブジェクト識別子 | 名前 | 説明 |
|---|---|---|
|
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の資格証明を指定することで単純にリバインドできますが、資格証明がなくても、アプリケーションでアイデンティティを切り替えるためのプロキシ・メカニズムを使用できる場合があります。アプリケーションAにOracle Internet Directoryでアプリケーション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 |
「階層検索の実行」を参照してください。 |
|
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を返します。 |
表3-2 Oracle Internet Directoryでサポートされているレスポンス・コントロール
| オブジェクト識別子 | 名前 | 説明 |
|---|---|---|
|
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が戻されるようにしてください。
エンド・ユーザーへのプロキシ・スイッチを実行するには、ユーザー識別名が必要です。識別名を取得する方法については、次のURLでoracle.ldap.util.Userクラスの実装例を参照してください。
http://www.oracle.com/technology/sample_code/
「Sample Applications—Fusion Middleware」の下の「Oracle Identity Management」リンクから、「Sample Application Demonstrating Proxy Switching using Oracle Internet Directory Java API」を探してください。
次のコードは、プロキシ・スイッチがどのように行われるかを示しています。
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は、「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を参照してください。
|
関連項目: 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)
アプリケーションに管理インタフェースがある場合はこの機能が望ましく、この機能は管理者に対して公開できます。
