2.4. LDAP レルム
LDAP レルムは、OpenLDAP、Red Hat Directory Server、Apache Directory Server、Microsoft Active Directory などの LDAP サーバーに接続して、ユーザーを認証し、メンバーシップ情報を取得します。
LDAP サーバーは、サーバーのタイプとデプロイメントに応じて、異なるエントリーレイアウトを持つことができます。考えられるすべての設定の例を提供することは、このドキュメントでは扱っていません。
2.4.1. LDAP 接続プロパティー リンクのコピーリンクがクリップボードにコピーされました!
LDAP レルム設定で LDAP 接続プロパティーを指定します。
次のプロパティーが必要です。
| url |
LDAP サーバーの URL を指定します。TLS を使用したセキュアな接続のために、URL は |
| principal | LDAP サーバー内の有効なユーザーの識別名 (DN) を指定します。DN は、LDAP ディレクトリー構造内でユーザーを一意に識別します。 |
| credential | 前述のプリンシパルに関連するパスワードに対応します。 |
LDAP 接続のプリンシパルには、LDAP クエリーを実行し、特定の属性にアクセスするために必要な権限が必要です。
connection-pooling を有効にすると、LDAP サーバーに対する認証のパフォーマンスが大幅に向上します。接続プーリングメカニズムは JDK によって提供されます。詳細は、接続プーリングの設定 および Java チュートリアル: プーリング を参照してください。
2.4.2. LDAP レルムのユーザー認証方法 リンクのコピーリンクがクリップボードにコピーされました!
LDAP レルムでのユーザー認証方法を設定します。
LDAP レルムは、次の 2 つの方法でユーザーを認証できます。
| ハッシュ化されたパスワードの比較 |
ユーザーのパスワード属性 (通常は |
| 直接検証 | 提供された認証情報を使用して、LDAP サーバーに対して認証を行います。
Active Directory で機能する唯一の方法は直接検証です。 |
direct-verification 属性でハッシュ化を実行するエンドポイントの認証メカニズムは使用できません。この方法ではクリアテキストのパスワードが必要であるためです。そのため、Active Directory Server と統合するには、REST エンドポイントでは BASIC 認証メカニズムを、Hot Rod エンドポイントでは PLAIN を使用する必要があります。より安全な代替方法として、SPNEGO、GSSAPI、および GS2-KRB5 認証メカニズムを可能にする Kerberos を使用することができます。
LDAP レルムはディレクトリーを検索して、認証されたユーザーに対応するエントリーを探し出します。rdn-identifier 属性は、指定された識別子 (通常はユーザー名) をもとにユーザーエントリーを検索する LDAP 属性を指定します (例: uid または sAMAccountName 属性)。search-recursive="true" を設定に追加して、ディレクトリーを再帰的に検索します。デフォルトでは、ユーザーエントリーの検索は (rdn_identifier={0}) フィルターを使用します。filter-name 属性を使用して、別のフィルターを指定できます。
2.4.3. ユーザーエントリーの関連グループへのマッピング リンクのコピーリンクがクリップボードにコピーされました!
LDAP レルム設定で attribute-mapping 要素を指定して、ユーザーがメンバーであるすべてのグループを取得して関連付けます。
メンバーシップ情報は通常、次の 2 つの方法で保存されます。
-
通常
member属性にクラスgroupOfNamesまたはgroupOfUniqueNamesを持つグループエントリーの下。これは、Active Directory を除く、ほとんどの LDAP インストールにおけるデフォルトの動作です。この場合、属性フィルターを使用できます。このフィルターは、提供されたフィルターに一致するエントリーを検索します。フィルターは、ユーザーの DN と等しいmember属性を持つグループを検索します。次に、フィルターは、fromで指定されたグループエントリーの CN を抽出し、それをユーザーのRolesに追加します。 memberOf属性のユーザーエントリー内。これは通常、Active Directory の場合に当てはまります。この場合、以下のような属性参照を使用する必要があります。<attribute-reference reference="memberOf" from="cn" to="Roles" />この参照は、ユーザーのエントリーからすべての
memberOf属性を取得し、fromで指定された CN を抽出し、それらをユーザーのグループに追加します (Rolesはグループのマッピングに使用される内部名です)。
2.4.4. LDAP レルム設定リファレンス リンクのコピーリンクがクリップボードにコピーされました!
XML
JSON
YAML
2.4.4.1. LDAP レルムプリンシパルの書き換え リンクのコピーリンクがクリップボードにコピーされました!
GSSAPI、GS2-KRB5、Negotiate などの SASL 認証メカニズムによって取得されるプリンシパルには、通常、ドメイン名 (例: myuser@INFINISPAN.ORG) が含まれます。これらのプリンシパルを LDAP クエリーで使用する前に、プリンシパルを変換して互換性を確保する必要があります。このプロセスは書き換えと呼ばれます。
Data Grid には次のトランスフォーマーが含まれています。
| case-principal-transformer |
プリンシパルをすべて大文字またはすべて小文字に書き換えます。たとえば |
| common-name-principal-transformer |
プリンシパルを LDAP 識別名形式 (RFC 4514 で定義) に書き換えます。タイプ |
| regex-principal-transformer | キャプチャーグループを含む正規表現を使用してプリンシパルを書き換え、たとえば、任意の部分文字列の抽出を可能にします。 |
2.4.4.2. LDAP プリンシパル書き換え設定リファレンス リンクのコピーリンクがクリップボードにコピーされました!
ケースプリンシパルトランスフォーマー
XML
JSON
YAML
コモンネームプリンシパルトランスフォーマー
XML
JSON
YAML
Regex プリンシパルトランスフォーマー
XML
JSON
YAML
2.4.4.3. Data Grid を使用した LDAP ユーザーとグループのマッピングプロセス リンクのコピーリンクがクリップボードにコピーされました!
この例では、LDAP ユーザーとグループをロードし、Data Grid サブジェクトに内部マッピングするプロセスを示します。以下は、複数の LDAP エントリーを記述した LDIF (LDAP Data Interchange Format) ファイルです。
LDIF
root ユーザーは、admin および monitor グループのメンバーです。
エンドポイントの 1 つでパスワード strongPassword を使用してユーザー root を認証するよう要求されると、次の操作が実行されます。
- ユーザー名は、選択されたプリンシパルトランスフォーマーを使用して、必要に応じて書き換えられます。
-
レルムは、
uid属性がrootに等しいエントリーをou=People,dc=infinispan,dc=orgツリー内で検索し、DNuid=root,ou=People,dc=infinispan,dc=orgのエントリーを探し出します。このエントリーがユーザープリンシパルになります。 -
レルムは、
u=Roles,dc=infinispan,dc=orgツリー内で、member属性にuid=root,ou=People,dc=infinispan,dc=orgを含むobjectClass=groupOfNamesのエントリーを検索します。この場合、cn=admin,ou=Roles,dc=infinispan,dc=orgとcn=monitor,ou=Roles,dc=infinispan,dc=orgの 2 つのエントリーが見つかります。これらのエントリーから、グループプリンシパルとなるcn属性を抽出します。
したがって、結果として得られるサブジェクトは次のようになります。
-
NamePrincipal:
uid=root,ou=People,dc=infinispan,dc=org -
RolePrincipal:
admin -
RolePrincipal:
monitor
この時点で、グローバル承認マッパーが上記のサブジェクトに適用され、プリンシパルがロールに変換されます。その後、ロールが一連のパーミッションに展開され、パーミッションが要求されたキャッシュと操作に対して検証されます。