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
この時点で、グローバル承認マッパーが上記のサブジェクトに適用され、プリンシパルがロールに変換されます。その後、ロールが一連のパーミッションに展開され、パーミッションが要求されたキャッシュと操作に対して検証されます。