LDAP 認証

Lightweight Directory Access Protocol (LDAP) は、ネットワーク上に分散したディレクトリー情報サービスにアクセスし、維持するためのインターネット・プロトコルです。 Web アプリケーションのユーザーの認証のために LDAP に依存する場合は、開始する前にこのトピックの内容を確認してください。

プログラミングのガイドライン

LDAP を使用して認証する場合は、次のガイドラインに従ってください。

LDAP インターフェースのみを使用 -- ユーザーは、LDAP サーバーへの接続を通じてのみ認証できます。
Active Directory -- Active Directory インターフェースの使用は禁止されていますが、Active Directory を使用した LDAP 認証はサポートされています。
管理者プロパティー -- LDAP 管理者は、すべてのユーザーの LDAP プロパティーにアクセスできなければなりません。

IBM® API Connect によって読み取られる LDAP 属性は以下のとおりです。

属性	定義
`mail`	ユーザーの SMTP E メール・アドレス。
`cn`	ユーザーの共通名を判別するために内部で使用されます。
`sn`	ユーザーの姓を判別するために内部で使用されます。
`givenname`	ユーザーの名を判別するために内部で使用されます。
`Search dn` からの接頭部	ユーザー名として使用されます。

ユーザー認証のための LDAP サーバーの使用

LDAP ディレクトリー・サーバーのすべての項目には識別名 (DN) があります。 DN は、ディレクトリー内の項目を一意に識別するための名前です。 DN は、コンマで区切られた attribute=value のペアで構成されます。例:

cn=Ben Gray,ou=editing,o=New York Times,c=US
cn=Lucille White,ou=editing,o=New York Times,c=US
cn=Tom Brown,ou=reporting,o=New York Times,c=US

ディレクトリー・スキーマに定義されたすべての属性は、DN を構成するために使用できます。コンポーネント属性値の組の順序は、大切です。 DN は、ルートを基点として、項目が存在するレベルまでの各ディレクトリー階層レベルごとに、1 つのコンポーネントを含みます。 LDAP DN は、最も具体性の高い属性 (通常はある種の名前) から始まり、徐々に意味の広い属性へと続き、たいていは国の属性で終了します。 DN の最初のコンポーネントは、相対識別名 (RDN) と呼ばれています。 RDN は項目を、同じ親を持つ他の項目と明確に区別します。上記の例では、RDN「cn=Ben Gray」によって、1 番目の項目を 2 番目の項目 (RDN「cn=Lucille White」を持つ) と区別しています。これら 2 つの DN は、それ以外は同じものです。項目に対する RDN を構成する「属性 = 値」の組も項目に存在していなければなりません。 (これは、DN のその他のコンポーネントには当てはまりません。)

例

以下の例では、基本 DN からユーザー検索が実行されます。検索は匿名で行われます。あるいは、認証バインドが使用されている場合には、認証済みユーザーが使用されます。 DN の検索では、接頭部、指定されたユーザー名、および接尾部が追加されます。使用される接頭部が「(uid=」であり、使用される接尾部が「)」である場合、uid がユーザー名属性になります。使用されるデフォルトの検索フィルターは (|(cn={filter}*)(sn={filter}*)(mail={filter}*)(givenName={filter})) であり、接頭部に使用される属性も検索フィルターに追加されます。この場合、「(uid=」が接頭部です。ユーザーを検索すると、検索フィルターは次のようになります。

  (|(cn={filter}*)(sn={filter}*)(mail={filter}*)(givenName={filter}*)(uid={filter}*))

{filter} は、実際のテキストに置き換えられます。

認証済みバインド DN は、外部 LDAP サーバー上のユーザーであり、定義された検索ベース内での基本 DN の取得と LDAP ディレクトリーの検索を許可されています。また、この DN は他のユーザー・プロパティーを読み取ることができなければならず、LDAP に匿名でアクセスして基本 DN を取得したりユーザー属性を検索してその属性にアクセスしたりすることが許可されていない場合に使用される必要があります。 Steve の検索を実行する場合、以下の例に示す LDAP 照会フィルターが使用され、UI で使用された基本 DN から検索が実行されます。ユーザーの DN が返された場合、DN およびパスワードがユーザーの認証に使用されます。

(|(cn=Steve*)(sn=Steve*)(mail=Steve*)(givenName=Steve*)(uid=Steve*)).

ログイン呼び出し中のバインドの場合、使用される検索ストリングは接頭部です。例えば、接頭部が「(uid=」である場合、ログイン時にユーザーの検索に使用される検索ストリングは、「(uid=Steve)」となります。

メール属性をユーザー名として使用する

E メール・アドレスをユーザー名として使用する場合 (例えば、 steve@company.com)、通常はメール属性を接頭部「(mail=」として使用します。この場合、以下の検索ストリングを使用して内部で検索を実行します (接頭部として「(mail=」を想定)。

(|(cn=steve@company.com*)(sn=steve@company.com*)(mail=steve@company.com*)
(givenName=steve@company.com*)(mail=steve@company.com*))

上記の例では、DN が検出された場合、パスワードは、バインドを実行するために DN と共に使用されます。最初の結果が取り込まれるため、ユーザー名には必ず固有の属性を使用してください。次に、ユーザーの LDAP プロパティー (cn、 sn、 mail、 givenName) が読み取られます。ログイン・ユーザーを使用して LDAP プロパティーを読み取ることができない場合、それらのプロパティーは、認証済みバインド資格情報を使用してユーザーの DN から読み取られます。ユーザー名属性が異なる場合は、その属性も照会されます。例えば、接頭部が「(uid=」である場合、uid 属性もユーザーの DN オブジェクトから読み取られます。

(|(cn={filter}*)(sn={filter}*)(mail={filter}*)(givenName={filter}*))

注: ユーザーの DN を直接取得するために接頭部と接尾部を使用することはできません。例えば、以下のようにしてユーザーの DN を直接取得しようとすると、失敗します。

Prefix: "uid=", Suffix: ",ou=users,dc=company,dc=com"

LDAP 参照

LDAP 参照によって、ディレクトリー・ツリーを複数の LDAP サーバー間でパーティション化および分散することができます。 LDAP 参照は、ドメイン・コントローラーが、要求されたオブジェクトのコピーを持っていないことをクライアント・アプリケーションに対して示し、そのオブジェクトを保持している可能性の高いロケーションをクライアントに知らせるための方法です。これにより、クライアントは、ドメイン・コントローラーの DNS 検索のベースとしてそのオブジェクトを使用します。

LDAP 参照の API Connect サポートには、以下が含まれます。

複数の Active Directory ツリーおよびフォレストに属するユーザーの検索。
Cloud Manager、 API Manager、 CMS Portal でのユーザー認証。

注: API Connect LDAP 参照サポートは、以下の条件に依存します。

単一の LDAP ホスト/ポートが、管理者資格情報を使用して構成され、すべてのユーザーがツリー/サーバーの基本 DN から参照されている。
LDAP 参照に従うユーザー検索の一部として、同じ管理者資格情報が下流のツリー/フォレストで使用される。
LDAP API 認証が、外部 LDAP 参照をサポートしない。内部 LDAP 参照はサポートされます。