18.3. ログインモジュール
18.3.1. モジュールの使用
JBoss EAP 6 には、ほとんどのユーザー管理ニーズに適したいくつかのバンドルされたログインモジュールが含まれています。JBoss EAP 6 は、リレーショナルデータベース、LDAP サーバー、またはフラットファイルからユーザー情報を読み取ることができます。JBoss EAP 6 はこれらのコアログインモジュールの他に、高度なカスタマイズの必要性に対応する、ユーザー情報を提供するログインモジュールも提供します。
その他のログインモジュールとそのオプションについては、付録 A.1 を参照してください。
18.3.1.1. パスワードスタッキング
スタックでは複数のログインモジュールをチェーンでき、各ログインモジュールは認証中にクレデンシャルの検証とロールの割り当ての両方を提供します。これは多くのユースケースで機能しますが、クレデンシャルの検証とロールの割り当てが複数のユーザー管理ストアに分散されることがあります。
「Ldap ログインモジュール」 LDAP とリレーショナルデータベースを組み合わせて、ユーザーがどちらのシステムでも認証できるようにする方法について説明します。ユーザーは中央の LDAP サーバーで管理されますが、アプリケーション固有のロールはアプリケーションのリレーショナルデータベースに格納される場合を考えてみましょう。password-stacking モジュールオプションはこの関係をキャプチャーします。
パスワードスタッキングを使用するには、各ログインモジュールで設定する必要があります<module-option>
使用するパスワードスタッキング 属性 FirstPass。パスワードスタッキングに設定した以前のモジュールがユーザーを認証した場合、他のすべてのスタッキングモジュールがユーザーによって認証されたこととなり、承認の手順でロールの提供のみを行います。
パスワードスタッキング オプションが useFirstPass に設定されている場合、このモジュールは最初にプロパティー名の下で共有ユーザー名とパスワードを検索しますjavax.security.auth.login.nameとjavax.security.auth.login.passwordログインモジュールの共有状態マップでそれぞれ。
これらのプロパティーが見つかった場合、プリンシパル名とパスワードとして使用されます。見つからない場合、プリンシパル名とパスワードはこのログインモジュールによって設定され、プロパティー名の下に保存されますjavax.security.auth.login.nameとjavax.security.auth.login.passwordそれぞれ。
注記
パスワードスタッキングを使用する場合は、すべてのモジュールが必要になるように設定します。これにより、すべてのモジュールが考慮され、承認プロセスにロールを公開することができるようになります。
例18.5 パスワードスタッキングサンプル
この管理 CLI の例は、パスワードスタッキングの使用方法を示しています。
/subsystem=security/security-domain=pwdStack/authentication=classic/login-module=Ldap:add( \
code=Ldap, \
flag=required, \
module-options=[ \
("password-stacking"=>"useFirstPass"), \
... Ldap login module configuration
])
/subsystem=security/security-domain=pwdStack/authentication=classic/login-module=Database:add( \
code=Database, \
flag=required, \
module-options=[ \
("password-stacking"=>"useFirstPass"), \
... Database login module configuration
])18.3.1.2. パスワードのハッシュ化
ログインモジュールのほとんどは、クライアントが提供するパスワードをユーザー管理システムに保存されたパスワードと比較する必要があります。通常、これらのモジュールはプレーンテキストのパスワードを使用しますが、プレーンテキストのパスワードがサーバー側に保存されないようにするため、ハッシュ化されたパスワードをサポートするよう設定できます。
重要
Red Hat JBoss Enterprise Application Platform Common Criteria 認定リリースは、パスワードハッシュに SHA-256 のみをサポートします。
例18.6 パスワードのハッシュ化
以下は、認証されていないユーザーにプリンシパル名
nobody を割り当て、usersb64.properties ファイルに based64 でエンコードされた SHA-256 ハッシュのパスワードを含むログインモジュール設定です。usersb64.properties ファイルは、デプロイメントクラスパスの一部です。
/subsystem=security/security-domain=testUsersRoles:add
/subsystem=security/security-domain=testUsersRoles/authentication=classic:add
/subsystem=security/security-domain=testUsersRoles/authentication=classic/login-module=UsersRoles:add( \
code=UsersRoles, \
flag=required, \
module-options=[ \
("usersProperties"=>"usersb64.properties"), \
("rolesProperties"=>"test-users-roles.properties"), \
("unauthenticatedIdentity"=>"nobody"), \
("hashAlgorithm"=>"SHA-256"), \
("hashEncoding"=>"base64") \
])
- hashAlgorithm
- パスワードをハッシュするために使用される
java.security.MessageDigestアルゴリズムの名前。デフォルトがないため、ハッシュを有効にするには、このオプションを指定する必要があります。一般的な値はSHA-256、SHA-1、およびMD5です。 - hashEncoding
base64、hex、rfc2617の 3 つのエンコーディングタイプのいずれかを指定する文字列。デフォルトはbase64です。- hashCharset
- クリアテキストのパスワードをバイト配列に変換するために使用されるエンコーディング文字セット。プラットフォームのデフォルトエンコーディングがデフォルトです。
- hashUserPassword
- ユーザーが送信するパスワードにハッシュアルゴリズムを適用する必要があることを指定します。ハッシュ化されたユーザーパスワードは、ログインモジュール内の値と比較されます. これは、パスワードのハッシュです。デフォルトは
trueです。 - hashStorePassword
- サーバー側に保存されているパスワードにハッシュアルゴリズムを適用する必要があることを指定します。これは、ユーザーパスワードのハッシュと、比較対象のサーバーからの要求固有のトークンを送信するダイジェスト認証に使用されます。ハッシュアルゴリズム (ダイジェストの場合は
rfc2617) を利用してサーバー側のハッシュを計算し、クライアントから送信されたハッシュ値と一致させる必要があります。
コードでパスワードを生成する必要がある場合、
org.jboss.security.auth.spi.Util クラスは、指定されたエンコーディングを使用してパスワードをハッシュする静的ヘルパーメソッドを提供します。次の例では、base64 でエンコードされた MD5 ハッシュパスワードを生成します。
String hashedPassword = Util.createPasswordHash("SHA-256",
Util.BASE64_ENCODING, null, null, "password");
OpenSSL は、コマンドラインでハッシュ化されたパスワードをすばやく生成するための代替方法を提供します。次の例では、base64 でエンコードされた SHA-256 ハッシュパスワードも生成されます。ここでは、プレーンテキストの
パスワード (password) が OpenSSL ダイジェスト関数にパイプされ、次に別の OpenSSL 関数にパイプされて base64 エンコード形式に変換されます。
echo -n password | openssl dgst -sha256 -binary | openssl base64
どちらの場合も、パスワードのハッシュバージョンは同じです:
XohImNooBHFR0OVvjcYpJ3NgPQ1qq73WKhHvch0VQtg=。この値は、上記の例ではセキュリティードメインで指定されたユーザーのプロパティーファイル (usersb64.properties) に保存する必要があります。
18.3.1.3. 認証されていない ID
すべての要求が認証形式で受信される訳ではありません。
unauthenticatedIdentity は、認証情報を持たない要求に特定の ID (例: guest) を割り当てるログインモジュール設定オプションです。これを使用すると、保護されていないサーブレットは特定ロールを必要としない EJB でメソッドを呼び出すことができます。このようなプリンシパルには関連したロールがなく、セキュアでない EJB や、チェックされていないパーミッション制約と関連する EJB メソッドのみにアクセスできます。
- unauthenticatedIdentity: これにより、認証情報を含まない要求に割り当てる必要があるプリンシパル名が定義されます。
18.3.1.4. Ldap ログインモジュール
Ldap ログインモジュールは、ライトウェイトディレクトリーアクセスプロトコル (LDAP) サーバーに対して認証を行う LoginModule 実装です。ユーザー名と資格情報が、Java Naming and Directory Interface (JNDI)LDAP プロバイダーを使用してアクセスできる LDAP サーバーに保管されている場合は、Ldap ログインモジュールを使用します。
AdvancedLDAP ログインモジュール
ユーザーが LDAP を SPNEGO 認証で使用する場合や、LDAP サーバーを使用中に認証フェーズの一部を省略する場合は、SPNEGO ログインモジュールとチェーンされた
AdvancedLdap ログインモジュールの使用を検討するか、AdvancedLdap ログインモジュールのみの使用を検討してください。
- 識別名 (DN)
- LDAP (Lightweight Directory Access Protocol) において、ディレクトリー内のオブジェクトを一意に特定する識別名。各識別名には、他のオブジェクトと区別するための一意名と場所が必要で、これには属性と値のペア (AVP) を使用します。AVP は、共通名、組織単位などの情報を定義します。LDAP に必要となる一意な文字列は、これらの値の組み合わせになります。
注記
このログインモジュールは、認証されていない ID とパスワードのスタッキングもサポートしています。
LDAP 接続情報は、JNDI 初期コンテキストの作成に使用される環境オブジェクトに渡される設定オプションとして提供されます。使用される標準 LDAP JNDI プロパティーには以下が含まれます。
- java.naming.factory.initial
InitialContextFactory実装クラス名。これは、デフォルトで SunLDAP プロバイダー実装com.sun.jndi.ldap.LdapCtxFactoryになります。- java.naming.provider.url
- LDAP サーバーの LDAP URL。
- java.naming.security.authentication
- 使用するセキュリティープロトコルレベル。使用可能な値には、
none、simple、strongが含まれます。プロパティーが定義されていない場合に、この動作はサービスプロバイダーによって決定されます。 - java.naming.security.protocol
- 安全なアクセスに使用するトランスポートプロトコル。この設定オプションをサービスプロバイダーのタイプ (SSL など) に設定します。プロパティーが定義されていない場合に、この動作はサービスプロバイダーによって決定されます。
- java.naming.security.principal
- サービスへの呼び出し元を認証するためのプリンシパルの ID を指定します。これは、以下で説明されているように、その他のプロパティーから構築されます。
- java.naming.security.credentials
- サービスへの呼び出し元を認証するためのプリンシパルの資格情報を指定します。資格情報は、ハッシュ化されたパスワード、クリアテキストのパスワード、キー、または証明書の形式をとることができます。プロパティーが定義されていない場合に、この動作はサービスプロバイダーによって決定されます。
Ldap ログインモジュール設定オプションの詳細については、JBoss EAP の 『セキュリティーガイド』 の 『含まれる認証モジュール』 リファレンスを参照してください。
注記
特定のディレクトリースキーマ (Microsoft Active Directory など) では、ユーザーオブジェクトのロール属性は、単純な名前ではなく、ロールオブジェクトへの DN として格納されます。このスキーマタイプを使用する実装の場合、roleAttributeIsDN
true に設定する必要があります。
ユーザー認証は、ログインモジュール設定オプションに基づいて LDAP サーバーに接続することで実行されます。LDAP サーバーへの接続は、このセクションで前述した LDAPJNDI プロパティーで設定される環境で
InitialLdapContext を作成することによって行われます。
TheContext.SECURITY_PRINCIPALは、コールバックハンドラーと組み合わせて取得したユーザーの識別名に設定されます。principalDNPrefixとprincipalDNSuffixオプション値、およびContext.SECURITY_CREDENTIALSプロパティーはそれぞれに設定されますStringパスワード。
認証が成功すると (
InitialLdapContext インスタンスが作成されると)、検索属性がに設定された rolesCtxDN の場所で検索を実行することにより、ユーザーのロールが照会されます。roleAttributeNameとuidAttributeNameオプション値。を呼び出すことによって名前が取得しているロール toString 検索結果セットのロール属性のメソッド。
例18.7 LDAP ログインモジュールセキュリティードメイン
この管理 CLI の例は、セキュリティードメイン認証設定でパラメーターを使用する方法を示しています。
/subsystem=security/security-domain=testLDAP:add(cache-type=default)
/subsystem=security/security-domain=testLDAP/authentication=classic:add
/subsystem=security/security-domain=testLDAP/authentication=classic/login-module=Ldap:add( \
code=Ldap, \
flag=required, \
module-options=[ \
("java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory"), \
("java.naming.provider.url"=>"ldap://ldaphost.jboss.org:1389/"), \
("java.naming.security.authentication"=>"simple"), \
("principalDNPrefix"=>"uid="), \
("principalDNSuffix"=>",ou=People,dc=jboss,dc=org"), \
("rolesCtxDN"=>"ou=Roles,dc=jboss,dc=org"), \
("uidAttributeID"=>"member"), \
("matchOnUserDN"=>true), \
("roleAttributeID"=>"cn"), \
("roleAttributeIsDN"=>false) \
])
の
java.naming.factory.initial、java.naming.factory.url、および java.naming.security オプションtestLDAPセキュリティードメインの設定は、次の条件を示しています。
- SunLDAPJNDI プロバイダーの実装が使用されます
- LDAP サーバーは、ポート 1389 のホスト
ldaphost.jboss.orgにあります。 - LDAP サーバーへの接続には、LDAP の単純な認証方法が使用されます。
ログインモジュールは、認証しようとしているユーザーを表す識別名 (DN) を使用して LDAP サーバーに接続しようとします。この DN は、渡されたものから構築されますprincipalDNPrefix、ユーザーのユーザー名とprincipalDNSuffix上記のように。の例18.8「LDIF ファイルの例」、ユーザー名
jsmith は uid = jsmith、ou = People、dc = jboss、dc=org に マップされます。
注記
この例では、LDAP サーバーがユーザーのエントリー (この例では
デューク) の userPassword 属性を使用してユーザーを認証することを前提としています。ほとんどの LDAP サーバーはこのように動作しますが、LDAP サーバーが認証を異なる方法で処理する場合は、LDAP が実稼働環境の要件に従って設定されていることを確認する必要があります。
認証が成功すると、
rolesCtxDN のサブツリー検索を実行して、認証の基になるロールが取得されます。uidAttributeIDユーザーと一致します。もしもmatchOnUserDNtrue の場合、検索はユーザーの完全な DN に基づいて行われます。それ以外の場合、検索は入力された実際のユーザー名に基づいて行われます。この例では、ou = Roles、dc = jboss、dc = org で、uid = jsmith、ou = People、dc = jboss、dc=org に 等しい メンバー 属性を持つエントリーを検索します。検索では、ロールエントリーの下に cn=JBossAdmin が見つかります。
検索では、で指定された属性が返されますroleAttributeIDオプション。この例では、属性は
cn です。返される値は JBossAdmin になるため、jsmith ユーザーは JBossAdmin ロールに割り当てられます。
ローカル LDAP サーバーは、多くの場合、ID および認証サービスを提供しますが、承認サービスを使用することはできません。これは、アプリケーションのロールが常に LDAP グループに適切にマッピングされるとは限らず、LDAP 管理者は、中央の LDAP サーバーで外部のアプリケーション固有のデータを許可することをためらうことが多いためです。LDAP 認証モジュールは、データベースログインモジュールなどの別のログインモジュールとペアになっていることが多く、開発中のアプリケーションにより適したロールを提供できます。
このデータが動作するディレクトリーの構造を表す LDAP データ交換フォーマット (LDIF) ファイルを以下に示します。例18.8「LDIF ファイルの例」。
- LDAP データ交換形式 (LDIF)
- LDAP ディレクトリーのコンテンツと更新要求を表すために使用されるプレーンテキストのデータ交換形式。ディレクトリーコンテンツは、オブジェクトまたは更新要求ごとに 1 つのレコードとして表されます。コンテンツは、追加、変更、削除、および名前変更のリクエストで設定されます。
例18.8 LDIF ファイルの例
dn: dc=jboss,dc=org objectclass: top objectclass: dcObject objectclass: organization dc: jboss o: JBoss dn: ou=People,dc=jboss,dc=org objectclass: top objectclass: organizationalUnit ou: People dn: uid=jsmith,ou=People,dc=jboss,dc=org objectclass: top objectclass: uidObject objectclass: person uid: jsmith cn: John sn: Smith userPassword: theduke dn: ou=Roles,dc=jboss,dc=org objectclass: top objectclass: organizationalUnit ou: Roles dn: cn=JBossAdmin,ou=Roles,dc=jboss,dc=org objectclass: top objectclass: groupOfNames cn: JBossAdmin member: uid=jsmith,ou=People,dc=jboss,dc=org description: the JBossAdmin group
18.3.1.5. LdapExtended ログインモジュール
- 識別名 (DN)
- LDAP (Lightweight Directory Access Protocol) において、ディレクトリー内のオブジェクトを一意に特定する識別名。各識別名には、他のオブジェクトと区別するための一意名と場所が必要で、これには属性と値のペア (AVP) を使用します。AVP は、共通名、組織単位などの情報を定義します。LDAP に必要となる一意な文字列は、これらの値の組み合わせになります。
LdapExtended (
org.jboss.security.auth.spi.LdapExtLoginModule) ログインモジュールは、ユーザーと認証で関連ロールを検索します。ロールは再帰的にクエリーを行い、DN に従って階層的なロール構造を移動します。
LoginModule オプションには、JNDI プロバイダーがサポートする指定の LDAP によってオプションがサポートされるかどうかが含まれます。標準プロパティー名の例
- Context.INITIAL_CONTEXT_FACTORY = "java.naming.factory.initial"
- Context.SECURITY_PROTOCOL = "java.naming.security.protocol"
- Context.PROVIDER_URL = "java.naming.provider.url"
- Context.SECURITY_AUTHENTICATION = "java.naming.security.authentication"
- Context.REFERRAL = "java.naming.referral"
ログインモジュールの実装ロジックは、次の順序に従います。
- 最初の LDAP サーバーバインドは、bindDNとbindCredentialプロパティー。ThebindDN両方を検索する権限を持つユーザーですbaseCtxDNとrolesCtxDNユーザーとロールのツリー。Theuser DN認証対象は、で指定されたフィルターを使用して照会されますbaseFilter財産。
- 結果としてuserDNを使用して LDAP サーバーにバインドすることで認証されますuserDNInitialLdapContext 環境としてContext.SECURITY_PRINCIPAL。TheContext.SECURITY_CREDENTIALSプロパティーは、コールバックハンドラーによって取得された文字列パスワードに設定されます。
- これが成功すると、rolesCtxDN、roleAttributeID、roleAttributeIsDN、roleNameAttributeID、および roleFilter オプションを使用して、関連付けられたユーザーロールが照会されます。
注記
AdvancedLdap ログインモジュールは、以下の点で LdapExtended ログインモジュールとは異なります。
- トップレベルのロールは roleAttributeID のみに対してクエリーされ、roleNameAttributeID にはクエリーされません。
- roleAttributeIsDN モジュールプロパティーが false に設定されている場合、recurseRoles モジュールオプションが true に設定されていても、再帰ロール検索は無効になります。
LdapExtended ログインモジュールオプションの詳細については、JBoss EAP の 『セキュリティーガイド』 の 『含まれる認証モジュール』 リファレンスを参照してください。
図18.1 LDAP 構造の例
[D]
例18.9 例 2LDAP 設定
version: 1 dn: o=example2,dc=jboss,dc=org objectClass: top objectClass: organization o: example2 dn: ou=People,o=example2,dc=jboss,dc=org objectClass: top objectClass: organizationalUnit ou: People dn: uid=jduke,ou=People,o=example2,dc=jboss,dc=org objectClass: top objectClass: uidObject objectClass: person objectClass: inetOrgPerson cn: Java Duke employeeNumber: judke-123 sn: Duke uid: jduke userPassword:: dGhlZHVrZQ== dn: uid=jduke2,ou=People,o=example2,dc=jboss,dc=org objectClass: top objectClass: uidObject objectClass: person objectClass: inetOrgPerson cn: Java Duke2 employeeNumber: judke2-123 sn: Duke2 uid: jduke2 userPassword:: dGhlZHVrZTI= dn: ou=Roles,o=example2,dc=jboss,dc=org objectClass: top objectClass: organizationalUnit ou: Roles dn: uid=jduke,ou=Roles,o=example2,dc=jboss,dc=org objectClass: top objectClass: groupUserEx memberOf: cn=Echo,ou=Roles,o=example2,dc=jboss,dc=org memberOf: cn=TheDuke,ou=Roles,o=example2,dc=jboss,dc=org uid: jduke dn: uid=jduke2,ou=Roles,o=example2,dc=jboss,dc=org objectClass: top objectClass: groupUserEx memberOf: cn=Echo2,ou=Roles,o=example2,dc=jboss,dc=org memberOf: cn=TheDuke2,ou=Roles,o=example2,dc=jboss,dc=org uid: jduke2 dn: cn=Echo,ou=Roles,o=example2,dc=jboss,dc=org objectClass: top objectClass: groupOfNames cn: Echo description: the echo role member: uid=jduke,ou=People,dc=jboss,dc=org dn: cn=TheDuke,ou=Roles,o=example2,dc=jboss,dc=org objectClass: groupOfNames objectClass: top cn: TheDuke description: the duke role member: uid=jduke,ou=People,o=example2,dc=jboss,dc=org dn: cn=Echo2,ou=Roles,o=example2,dc=jboss,dc=org objectClass: top objectClass: groupOfNames cn: Echo2 description: the Echo2 role member: uid=jduke2,ou=People,dc=jboss,dc=org dn: cn=TheDuke2,ou=Roles,o=example2,dc=jboss,dc=org objectClass: groupOfNames objectClass: top cn: TheDuke2 description: the duke2 role member: uid=jduke2,ou=People,o=example2,dc=jboss,dc=org dn: cn=JBossAdmin,ou=Roles,o=example2,dc=jboss,dc=org objectClass: top objectClass: groupOfNames cn: JBossAdmin description: the JBossAdmin group member: uid=jduke,ou=People,dc=jboss,dc=org
この LDAP 構造の例のモジュール設定は、次の管理 CLI コマンドで概説されています。
/subsystem=security/security-domain=testLdapExample2/authentication=classic/login-module=LdapExtended:add( \
code=LdapExtended, \
flag=required, \
module-options=[ \
("java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory"), \
("java.naming.provider.url"=>"ldap://ldaphost.jboss.org"), \
("java.naming.security.authentication"=>"simple"), \
("bindDN"=>"cn=Root,dc=jboss,dc=org"), \
("bindCredential"=>"secret1"), \
("baseCtxDN"=>"ou=People,o=example2,dc=jboss,dc=org"), \
("baseFilter"=>"(uid={0})"), \
("rolesCtxDN"=>"ou=Roles,o=example2,dc=jboss,dc=org"), \
("roleFilter"=>"(uid={0})"), \
("roleAttributeIsDN"=>"true"), \
("roleAttributeID"=>"memberOf"), \
("roleNameAttributeID"=>"cn") \
])
例18.10 例 3LDAP 設定
dn: o=example3,dc=jboss,dc=org objectclass: top objectclass: organization o: example3 dn: ou=People,o=example3,dc=jboss,dc=org objectclass: top objectclass: organizationalUnit ou: People dn: uid=jduke,ou=People,o=example3,dc=jboss,dc=org objectclass: top objectclass: uidObject objectclass: person objectClass: inetOrgPerson uid: jduke employeeNumber: judke-123 cn: Java Duke sn: Duke userPassword: theduke dn: ou=Roles,o=example3,dc=jboss,dc=org objectClass: top objectClass: organizationalUnit ou: Roles dn: uid=jduke,ou=Roles,o=example3,dc=jboss,dc=org objectClass: top objectClass: groupUserEx memberOf: cn=Echo,ou=Roles,o=example3,dc=jboss,dc=org memberOf: cn=TheDuke,ou=Roles,o=example3,dc=jboss,dc=org uid: jduke dn: cn=Echo,ou=Roles,o=example3,dc=jboss,dc=org objectClass: top objectClass: groupOfNames cn: Echo description: the JBossAdmin group member: uid=jduke,ou=People,o=example3,dc=jboss,dc=org dn: cn=TheDuke,ou=Roles,o=example3,dc=jboss,dc=org objectClass: groupOfNames objectClass: top cn: TheDuke member: uid=jduke,ou=People,o=example3,dc=jboss,dc=org
この LDAP 構造の例のモジュール設定は、次の管理 CLI コマンドで概説されています。
/subsystem=security/security-domain=testLdapExample3/authentication=classic/login-module=LdapExtended:add( \
code=LdapExtended, \
flag=required, \
module-options=[ \
("java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory"), \
("java.naming.provider.url"=>"ldap://ldaphost.jboss.org"), \
("java.naming.security.authentication"=>"simple"), \
("bindDN"=>"cn=Root,dc=jboss,dc=org"), \
("bindCredential"=>"secret1"), \
("baseCtxDN"=>"ou=People,o=example3,dc=jboss,dc=org"), \
("baseFilter"=>"(cn={0})"), \
("rolesCtxDN"=>"ou=Roles,o=example3,dc=jboss,dc=org"), \
("roleFilter"=>"(member={1})"), \
("roleAttributeID"=>"cn") \
])
例18.11 例 4LDAP 設定
dn: o=example4,dc=jboss,dc=org objectclass: top objectclass: organization o: example4 dn: ou=People,o=example4,dc=jboss,dc=org objectclass: top objectclass: organizationalUnit ou: People dn: uid=jduke,ou=People,o=example4,dc=jboss,dc=org objectClass: top objectClass: uidObject objectClass: person objectClass: inetOrgPerson cn: Java Duke employeeNumber: jduke-123 sn: Duke uid: jduke userPassword:: dGhlZHVrZQ== dn: ou=Roles,o=example4,dc=jboss,dc=org objectClass: top objectClass: organizationalUnit ou: Roles dn: cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org objectClass: groupOfNames objectClass: top cn: RG1 member: cn=empty dn: cn=RG2,cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org objectClass: groupOfNames objectClass: top cn: RG2 member: cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org member: uid=jduke,ou=People,o=example4,dc=jboss,dc=org dn: cn=RG3,cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org objectClass: groupOfNames objectClass: top cn: RG3 member: cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org dn: cn=R1,ou=Roles,o=example4,dc=jboss,dc=org objectClass: groupOfNames objectClass: top cn: R1 member: cn=RG2,cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org dn: cn=R2,ou=Roles,o=example4,dc=jboss,dc=org objectClass: groupOfNames objectClass: top cn: R2 member: cn=RG2,cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org dn: cn=R3,ou=Roles,o=example4,dc=jboss,dc=org objectClass: groupOfNames objectClass: top cn: R3 member: cn=RG2,cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org member: cn=RG3,cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org dn: cn=R4,ou=Roles,o=example4,dc=jboss,dc=org objectClass: groupOfNames objectClass: top cn: R4 member: cn=RG3,cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org dn: cn=R5,ou=Roles,o=example4,dc=jboss,dc=org objectClass: groupOfNames objectClass: top cn: R5 member: cn=RG3,cn=RG1,ou=Roles,o=example4,dc=jboss,dc=org member: uid=jduke,ou=People,o=example4,dc=jboss,dc=org
この LDAP 構造体の例のモジュール設定は、コードサンプルで概説されています。
/subsystem=security/security-domain=testLdapExample4/authentication=classic/login-module=LdapExtended:add( \
code=LdapExtended, \
flag=required, \
module-options=[ \
("java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory"), \
("java.naming.provider.url"=>"ldap://ldaphost.jboss.org"), \
("java.naming.security.authentication"=>"simple"), \
("bindDN"=>"cn=Root,dc=jboss,dc=org"), \
("bindCredential"=>"secret1"), \
("baseCtxDN"=>"ou=People,o=example4,dc=jboss,dc=org"), \
("baseFilter"=>"(cn={0})"), \
("rolesCtxDN"=>"ou=Roles,o=example4,dc=jboss,dc=org"), \
("roleFilter"=>"(member={1})"), \
("roleRecursion"=>"1"), \
("roleAttributeID"=>"memberOf") \
])
例18.12 デフォルトの Active Directory 設定
以下の例は、デフォルトの Active Directory 設定を示しています。
Active Directory の設定によっては、通常のポート 389 ではなく、ポート 3268 でグローバルカタログを検索する必要がある場合があります。これは、Active Directory フォレストに複数のドメインが含まれる場合によく見られます。
/subsystem=security/security-domain=AD_Default/authentication=classic/login-module=LdapExtended:add( \
code=LdapExtended, \
flag=required, \
module-options=[ \
("java.naming.provider.url"=>"ldap://ldaphost.jboss.org"), \
("bindDN"=>"JBOSS\searchuser"), \
("bindCredential"=>"password"), \
("baseCtxDN"=>"CN=Users,DC=jboss,DC=org"), \
("baseFilter"=>"(sAMAccountName={0})"), \
("rolesCtxDN"=>"CN=Users,DC=jboss,DC=org"), \
("roleFilter"=>"(sAMAccountName={0})"), \
("roleAttributeID"=>"memberOf"), \
("roleAttributeIsDN"=>"true"), \
("roleNameAttributeID"=>"cn"), \
("searchScope"=>"ONELEVEL_SCOPE"), \
("allowEmptyPasswords"=>"false") \
])
例18.13 再帰的なロール Active Directory の設定
以下の例では、Active Directory 内で再帰的なロール検索を実装します。この例と、デフォルトの Active Directory の例の主な違いは、ユーザーの DN を使用してメンバー属性を検索するためにロール検索が置き換えられている点です。ログインモジュールは、ロールの DN を使用して、グループがメンバーとなっているグループを検索します。
/subsystem=security/security-domain=AD_Recursive/authentication=classic/login-module=LdapExtended:add( \
code=LdapExtended, \
flag=required, \
module-options=[ \
("java.naming.provider.url"=>"ldap://ldaphost.jboss.org"), \
("java.naming.referral"=>"follow"), \
("bindDN"=>"JBOSS\searchuser"), \
("bindCredential"=>"password"), \
("baseCtxDN"=>"CN=Users,DC=jboss,DC=org"), \
("baseFilter"=>"(sAMAccountName={0})"), \
("rolesCtxDN"=>"CN=Users,DC=jboss,DC=org"), \
("roleFilter"=>"(member={1})"), \
("roleAttributeID"=>"cn"), \
("roleAttributeIsDN"=>"false"), \
("roleRecursion"=>"2"), \
("searchScope"=>"ONELEVEL_SCOPE"), \
("allowEmptyPasswords"=>"false") \
])
18.3.1.6. UsersRoles ログインモジュール
UsersRoles ログインモジュールは、Java プロパティーファイルからロードされる複数のユーザーおよびユーザーロールをサポートする簡単なログインモジュールです。デフォルトの username-to-password マッピングファイル名は users.properties で、デフォルトの username-to-roles マッピングファイル名は roles.propertiesです。
UsersRoles ログインモジュールオプションの詳細については、JBoss EAP の 『セキュリティーガイド』 の 『含まれる認証モジュール』 リファレンスを参照してください。
このログインモジュールは、パスワードスタッキング、パスワードハッシュ、および認証されていないアイデンティティーをサポートします。
プロパティーファイルは、initialize メソッドスレッドコンテキストローダーを使用して初期化中にロードされます。つまり、これらのファイルは Jakarta EE デプロイメントのクラスパス (
WAR アーカイブの WEB-INF/classes フォルダーなど) またはサーバークラスパスの任意のディレクトリーに配置できます。このログインモジュールの主な目的は、アプリケーションとともにデプロイされたプロパティーファイルを使用して複数のユーザーおよびロールのセキュリティー設定を簡単にテストすることです。
例18.14 UsersRoles ログインモジュール
/subsystem=security/security-domain=ejb3-sampleapp/authentication=classic/login-module=UsersRoles:add( \
code=UsersRoles, \
flag=required, \
module-options=[ \
("usersProperties"=>"ejb3-sampleapp-users.properties"), \
("rolesProperties"=>"ejb3-sampleapp-roles.properties") \
])
の例18.14「UsersRoles ログインモジュール」、
ejb3-sampleapp-users.properties ファイルは username = password 形式を使用し、各ユーザーエントリーは別々の行にあります。
username1=password1 username2=password2 ...
で参照され
ている ejb3-sampleapp-roles.properties ファイル例18.14「UsersRoles ログインモジュール」パターン username=role1、role2 を 使用し、オプションのグループ名の値を指定します。以下に例を示します。
username1=role1,role2,... username1.RoleGroup1=role3,role4,... username2=role1,role3,...
Theuser name.XXX
ejb3-sampleapp-roles.properties に存在するプロパティー名パターンは、プロパティー名の XXX 部分がグループ名である特定の名前付きロールグループにユーザー名ロールを割り当てるために使用されます。Theuser name=...form はの略語ですuser name.Roles=...、ここで、Roles グループ名は、JBossAuthorizationManager がユーザーの権限を定義するロールを含むことを期待する標準名です。
以下は、
jduke ユーザー名の同等の定義です。
jduke=TheDuke,AnimatedCharacter jduke.Roles=TheDuke,AnimatedCharacter
18.3.1.7. Database ログインモジュール
Database ログインモジュールは、認証とロールマッピングをサポートする JDBC (Java Database Connectivity) ベースのログインモジュールです。ユーザー名、パスワード、およびロール情報がリレーショナルデータベースに保存されている場合は、このログインモジュールを使用してください。
注記
このモジュールは、パスワードスタッキング、パスワードハッシュ、および認証されていないアイデンティティーをサポートします。
データベース ログインモジュールは、次の 2 つの論理テーブルに基づいています。
Table Principals(PrincipalID text, Password text) Table Roles(PrincipalID text, Role text, RoleGroup text)
Principals テーブルはユーザー PrincipalID を有効なパスワードに関連付けます。また、Roles テーブルはユーザー PrincipalID をそのロールセットに関連付けます。ユーザーパーミッションに使用されるロールは、Roles の RoleGroup コラムの値を持つ行に含まれる必要があります。
テーブルは論理であるため、ログインモジュールが使用する SQL クエリーを指定できます。唯一の要件として、
java.sql.ResultSet は前述の Principals および Roles と同じ論理構造を持ちます。テーブル名およびコラムの実際の名前は、コラムのインデックスに基づいてアクセスされるため、関係ありません。
この概念を明確化するために、すでに宣言されているように
Principals および Roles という 2 つのテーブルがあるデータベースを検討してください。以下のステートメントは、以下のデータをテーブルに追加します。
Principalsテーブルのechomanというパワスワードを持つPrincipalIDjavaRolesテーブルのRolesRoleGroupのEchoという名前のロールを持つPrincipalIDjavaRolesテーブルのCallerPrincipalRoleGroupにcaller_javaという名前のロールを持つPrincipalIDjava
INSERT INTO Principals VALUES('java', 'echoman')
INSERT INTO Roles VALUES('java', 'Echo', 'Roles')
INSERT INTO Roles VALUES('java', 'caller_java', 'CallerPrincipal')
データベースログインモジュールオプションの詳細については、JBoss EAP の 『セキュリティーガイド』 の 『含まれる認証モジュール』 リファレンスを参照してください。
データベースログインモジュール の設定例は、次のように設定できます。
CREATE TABLE Users(username VARCHAR(64) PRIMARY KEY, passwd VARCHAR(64)) CREATE TABLE UserRoles(username VARCHAR(64), role VARCHAR(32))
セキュリティードメインの対応するログインモジュール設定:
/subsystem=security/security-domain=testDB/authentication=classic/login-module=Database:add( \
code=Database, \
flag=required, \
module-options=[ \
("dsJndiName"=>"java:/MyDatabaseDS"), \
("principalsQuery"=>"select passwd from Users where username=?"), \
("rolesQuery"=>"select role, 'Roles' from UserRoles where username=?") \
])
18.3.1.8. Certificate ログインモジュール
Certificate ログインモジュールは、X509 証明書を基にユーザーを認証します。このログインモジュールの典型的なユースケースが、web 層の CLIENT-CERT 認証です。
証明書ログインモジュールは認証のみを実行するため、セキュアな web または EJB コンポーネントへのアクセスを完全に定義するには、承認ロールを取得できる他のログインモジュールと組み合わせる必要があります。このログインモジュールの 2 つのサブクラスである
CertRolesLoginModule および DatabaseCertLoginModule は動作を拡張し、プロパティーファイルまたはデータベースから承認ロールを取得します。
証明書 ログインモジュールオプションの詳細については、JBoss EAP の 『セキュリティーガイド』 の 『含まれる認証モジュール』 リファレンスを参照してください。
証明書 ログインモジュールには、ユーザー検証を実行するための KeyStore が必要です。これは、次の設定フラグメントに示すように、リンクされたセキュリティードメインの JSSE 設定から取得されます。
/subsystem=security/security-domain=trust-domain:add
/subsystem=security/security-domain=trust-domain/jsse=classic:add( \
truststore={ \
password=>pass1234, \
url=>/home/jbosseap/trusted-clients.jks \
})
/subsystem=security/security-domain=testCert:add
/subsystem=security/security-domain=testCert/authentication=classic:add
/subsystem=security/security-domain=testCert/authentication=classic/login-module=Certificate:add( \
code=Certificate, \
flag=required, \
module-options=[ \
("securityDomain"=>"trust-domain"), \
])
手順18.4 証明書とロールベースの承認による安全な Web アプリケーション
この手順では、クライアント証明書とロールベースの承認を使用して、
user-app.war などの Web アプリケーションを保護する方法について説明します。この例では、CertificateRoles ログインモジュールが認証と承認に使用されています。trusted-clients.keystore と app-roles.properties の両方に、クライアント証明書に関連付けられたプリンシパルにマップするエントリーが必要です。
デフォルトでは、プリンシパルは、で指定された DN などのクライアント証明書の識別名を使用して作成されます。例18.15「証明書の例」。
リソースとロールを宣言する
web.xmlを変更して、認証と承認に使用できる許可されたロールとセキュリティードメインとともに、保護するリソースを宣言します。<?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0"> <security-constraint> <web-resource-collection> <web-resource-name>Protect App</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>Admin</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>CLIENT-CERT</auth-method> <realm-name>Secured area</realm-name> </login-config> <security-role> <role-name>Admin</role-name> </security-role> </web-app>セキュリティードメインを指定する
jboss-web.xmlファイルで、必要なセキュリティードメインを指定します。<jboss-web> <security-domain>app-sec-domain</security-domain> </jboss-web>
ログインモジュールの設定
管理 CLI を使用して、指定したapp-sec-domainドメインのログインモジュール設定を定義します。[ /subsystem=security/security-domain=trust-domain:add /subsystem=security/security-domain=trust-domain/jsse=classic:add( \ truststore={ \ password=>pass1234, \ url=>/home/jbosseap/trusted-clients.jks \ }) /subsystem=security/security-domain=app-sec-domain:add /subsystem=security/security-domain=app-sec-domain/authentication=classic:add /subsystem=security/security-domain=app-sec-domain/authentication=classic/login-module=CertificateRoles:add( \ code=CertificateRoles, \ flag=required, \ module-options=[ \ ("securityDomain"=>"trust-domain"), \ ("rolesProperties"=>"app-roles.properties") \ ])
例18.15 証明書の例
[conf]$ keytool -printcert -file valid-client-cert.crt
Owner: CN=valid-client, OU=Security QE, OU=JBoss, O=Red Hat, C=CZ
Issuer: CN=EAP Certification Authority, OU=Security QE, OU=JBoss, O=Red Hat, C=CZ
Serial number: 2
Valid from: Mon Mar 24 18:21:55 CET 2014 until: Tue Mar 24 18:21:55 CET 2015
Certificate fingerprints:
MD5: 0C:54:AE:6E:29:ED:E4:EF:46:B5:14:30:F2:E0:2A:CB
SHA1: D6:FB:19:E7:11:28:6C:DE:01:F2:92:2F:22:EF:BB:5D:BF:73:25:3D
SHA256: CD:B7:B1:72:A3:02:42:55:A3:1C:30:E1:A6:F0:20:B0:2C:0F:23:4F:7A:8E:2F:2D:FA:AF:55:3E:A7:9B:2B:F4
Signature algorithm name: SHA1withRSA
Version: 3
trusted-clients.keystore には、次の証明書が必要です。例18.15「証明書の例」CN = valid-client、OU = Security QE、OU = JBoss、O = Red Hat、C=CZ のエイリアスで保存されます。app-roles.properties には同じエントリーが必要です。DN には通常区切り文字として扱われる文字が含まれているため、以下に示すように、円記号 (' \ ') を使用して問題のある文字をエスケープする必要があります。
# A sample app-roles.properties file CN\=valid-client,\ OU\=Security\ QE,\ OU\=JBoss,\ O\=Red\ Hat,\ C\=CZ
18.3.1.9. Identity ログインモジュール
Identity ログインモジュールは、ハードコードされたユーザー名をモジュールに対して認証されたサブジェクトに関連付ける簡単なログインモジュールです。このモジュールは、principal のオプションによって指定された名前を使用して SimplePrincipal インスタンスを作成します。
注記
このモジュールは、パスワードのスタッキングをサポートしています。
このログインモジュールは、サービスに固定 ID を提供する必要がある場合や、開発環境で特定のプリンシパルおよび関連付けられたロールに関連付けられたセキュリティーをテストする場合に役立ちます。
Identity ログインモジュールオプションの詳細については、JBoss EAP の 『セキュリティーガイド』 の 『含まれる認証モジュール』 リファレンスを参照してください。
セキュリティードメイン設定の例を以下に説明します。すべてのユーザーを
jduke という名前のプリンシパルとして認証し、TheDuke のロール名と AnimatedCharacter: を割り当てます。
/subsystem=security/security-domain=testIdentity:add
/subsystem=security/security-domain=testIdentity/authentication=classic:add
/subsystem=security/security-domain=testIdentity/authentication=classic/login-module=Identity:add( \
code=Identity, \
flag=required, \
module-options=[ \
("principal"=>"jduke"), \
("roles"=>"TheDuke,AnimatedCharacter") \
])
18.3.1.10. RunAs ログインモジュール
RunAS ログインモジュールは、認証のログインフェーズの間に run as ロールをスタックにプッシュするヘルパーモジュールです。ログインフェーズ後、コミットまたはアボートフェーズで run as ロールをスタックからポップします。
このログインモジュールの目的は、セキュアな EJB にアクセスするログインモジュールなど、セキュアなリソースにアクセスして認証を実行する必要のあるその他のログインモジュールにロールを提供することです。
RunAs ログインモジュールは、run as ロールの構築が必要なログインモジュールよりも先に設定する必要があります。
RunAs ログインモジュールオプションの詳細については、JBoss EAP の 『セキュリティーガイド』 の 『含まれる認証モジュール』 リファレンスを参照してください。
18.3.1.10.1. RunAsIdentity の作成
JBoss EAP 6 が EJB メソッドへのアクセスを保護するには、メソッド呼び出しが行われるときにユーザーの ID がわかっている必要があります。
サーバー内のユーザーの ID は、
javax.security.auth.Subject インスタンスまたは org.jboss.security.RunAsIdentity インスタンスのいずれかで表されます。これらのクラスは両方とも、ID を表す 1 つ以上のプリンシパルと、ID が所有するロールのリストを格納します。javax.security.auth.Subject の場合、資格情報のリストも保存されます。
の中に<assembly-descriptor>
ejb-jar.xml デプロイメント記述子のセクションでは、ユーザーがさまざまな EJB メソッドにアクセスするために必要な 1 つ以上のロールを指定します。これらのリストを比較すると、ユーザーが EJB メソッドにアクセスするために必要なロールの 1 つを持っているかどうかがわかります。
例18.16 org.jboss.security.RunAsIdentity Creation
ejb-jar.xml ファイルで、<security-identity>要素と<run-as><session> 要素の子として定義されたロール。
<session>
...
<security-identity>
<run-as>
<role-name>Admin</role-name>
</run-as>
</security-identity>
...
</session>
この宣言は、
AdminRunAsIdentity ロールを作成する必要があることを示しています。
管理者 ロールのプリンシパルに名前を付けるには、jboss-ejb3.xml ファイルで <run-as-principal> 要素を定義します。
<jboss:ejb-jar
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
xmlns:s="urn:security:1.1"
version="3.1" impl-version="2.0">
<assembly-descriptor>
<s:security>
<ejb-name>WhoAmIBean</ejb-name>
<s:run-as-principal>John</s:run-as-principal>
</s:security>
</assembly-descriptor>
</jboss:ejb-jar>
ejb-jar.xml ファイルの <security-identity> 要素と jboss-ejb3.xml ファイルの <security> 要素の両方がデプロイメント時に解析されます。<run-as> ロール名と <run-as-principal> 名は、org.jboss.metadata.ejb.spec.SecurityIdentityMetaData クラスに保存されます。
例18.17 RunAsIdentity への複数のロールの割り当て
jboss-ejb3.xml デプロイメント記述子 <assembly-descriptor> エレメントグループのプリンシパルにロールをマッピングすることにより、RunAsIdentity により多くのロールを割り当てることができます。
<jboss:ejb-jar xmlns:sr="urn:security-role"
...>
<assembly-descriptor>
...
<sr:security-role>
<sr:role-name>Support</sr:role-name>
<sr:principal-name>John</sr:principal-name>
<sr:principal-name>Jill</sr:principal-name>
<sr:principal-name>Tony</sr:principal-name>
</sr:security-role>
</assembly-descriptor>
</jboss:ejb-jar>
の例18.16「org.jboss.security.RunAsIdentity Creation」、
ジョン の <run-as-principal> が作成されました。この例の設定では、サポート ロールを追加することにより、管理者 ロールを拡張します。新しいロールには、最初に定義されたプリンシパル John を含む追加のプリンシパルが含まれます。
ejb-jar.xml ファイルと jboss-ejb3.xml ファイルの両方の <security-role> 要素は、デプロイメント時に解析されます。<role-name> および <principal-name> データは、org.jboss.metadata.ejb.spec.SecurityIdentityMetaData クラスに保存されます。
18.3.1.11. Client ログインモジュール
Client ログインモジュール (org.jboss.security.ClientLoginModule) は、呼び出し元のアイデンティティーとクレデンシャルの確立時に JBoss クライアントによって使用される LoginModule の実装です。新しい SecurityContext を作成してプリンシパルとクレデンシャルに割り当て、SecurityContext を ThreadLocal セキュリティーコンテキストに設定します。
Client ログインモジュールは、クライアントが現在のスレッドの呼び出し元を確立するために唯一サポートされるログインモジュールです。セキュリティー環境が JBoss EJB security サブシステムを使用するよう透過的に設定されていない EJB クライアントとして動作するサーバー環境とスタンドアロンクライアントアプリケーションは、Client ログインモジュールを使用する必要があります。
このログインモジュールは認証を行わない点に注意してください。サーバー上の後続の認証のために、提供されたログイン情報をサーバー EJB 呼び出しレイヤーにコピーすることもほとんどありません。ユーザーのクライアント側認証を実行する必要がある場合は、
クライアント ログインモジュールに加えて別のログインモジュールを設定する必要があります。
クライアントログインモジュールオプションの詳細については、JBoss EAP の 『セキュリティーガイド』 の 『含まれる認証モジュール』 リファレンスを参照してください。
18.3.1.12. SPNEGO ログインモジュール
SPNEGO ログインモジュール (org.jboss.security.negotiation.spnego.SPNEGOLoginModule) は、KDC で呼び出し元のアイデンティティーとクレデンシャルを確立する LoginModule の実装です。モジュールは、SPNEGO、Simple、および Protected GSSAPI Negotiation メカニズムを実装し、JBoss Negotiation プロジェクトの一部です。この認証を AdvancedLdap ログインモジュールとチェーンされた設定で使用すると、LDAP サーバーと連携できます。
SPNEGO ログインモジュールオプションの詳細については、JBoss EAP の 『セキュリティーガイド』 の 『含まれる認証モジュール』 リファレンスを参照してください。
JBoss Negotiation モジュールは、デプロイされたアプリケーションの標準の依存関係として含まれていません。を使用するには
SPNEGOまたAdvancedLdapプロジェクトのログインモジュールでは、META-INF/jboss-deployment-structure.xml デプロイメント記述子ファイルを編集して、依存関係を手動で追加する必要があります。
例18.18 JBossNegotiationModule を依存関係として追加する
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.jboss.security.negotiation" />
</dependencies>
</deployment>
</jboss-deployment-structure>
18.3.1.13. RoleMapping ログインモジュール
RoleMapping ログインモジュールは、1 つ以上の宣言的ロールへの認証プロセスの最終結果となるロールのマッピングをサポートします。たとえば、ユーザー A のロールが ldapAdmin と testAdmin で、web.xml または ejb-jar.xml ファイルで定義されたアクセスの宣言的ロールは admin であると認証プロセスによって判断された場合、このログインモジュールは admin ロールを A にマップします。
RoleMapping ログインモジュールオプションの詳細については、JBoss EAP の 『セキュリティーガイド』 の 『含まれる認証モジュール』 リファレンスを参照してください。
RoleMapping ログインモジュールは、以前マップされたロールのマッピングを変更するため、ログインモジュール設定でオプションのモジュールとして定義する必要があります。
例18.19 マップされたロールの定義
/subsystem=security/security-domain=test-domain-2/:add
/subsystem=security/security-domain=test-domain-2/authentication=classic:add
/subsystem=security/security-domain=test-domain-2/authentication=classic/login-module=test-2-lm/:add(\
flag=required,\
code=UsersRoles,\
module-options=[("usersProperties"=>"users.properties"),("rolesProperties"=>"roles.properties")]\
)
/subsystem=security/security-domain=test-domain-2/authentication=classic/login-module=test2-map/:add(\
flag=optional,\
code=RoleMapping,\
module-options=[("rolesProperties"=>"rolesMapping-roles.properties")]\
)
同じ結果を達成する別の例ですが、マッピングモジュールを使用しています。これは、ロールマッピングの推奨される方法です。
例18.20 マップされたロールを定義するための好ましい方法
/subsystem=security/security-domain=test-domain-2/:add
/subsystem=security/security-domain=test-domain-2/authentication=classic:add
/subsystem=security/security-domain=test-domain-2/authentication=classic/login-module=test-2-lm/:add(\
flag=required,\
code=UsersRoles,\
module-options=[("usersProperties"=>"users.properties"),("rolesProperties"=>"roles.properties")]\
)
/subsystem=security/security-domain=test-domain-2/mapping=classic/mapping-module=test2-map/:add(\
code=PropertiesRoles,type=role,\
module-options=[("rolesProperties"=>"rolesMapping-roles.properties")]\
)
例18.21 RoleMappingLoginModule によって使用されるプロパティーファイル
ldapAdmin=admin, testAdmin
認証されたサブジェクトにロール
ldapAdmin が含まれている場合、ロール admin および testAdmin は、認証されたサブジェクトに追加されるか、認証されたサブジェクトに置き換えられます。replaceRoleプロパティー値。
18.3.1.14. bindCredential モジュールオプション
bindCredential モジュールオプションは、DN の資格情報を保存するために使用され、複数のログインおよびマッピングモジュールで使用できます。パスワードを取得するには、いくつかの方法があります。
- 管理 CLI コマンドのプレーンテキスト。
- のパスワード
bindCredentialモジュールは、管理 CLI コマンドでプレーンテキストで提供できます。例:("bindCredential"=>"secret1").セキュリティー上の理由から、パスワードは JBoss EAP ボールトメカニズムを使用して暗号化する必要があります。 - 外部コマンドを使用します。
- 外部コマンドの出力からパスワードを取得するには、次の形式を使用します
{EXT}...どこ...外部コマンドです。コマンド出力の最初の行がパスワードとして使用されます。パフォーマンスを向上させるために、{EXTC[:expiration_in_millis]}バリアントは、指定されたミリ秒数の間パスワードをキャッシュします。デフォルトでは、キャッシュされたパスワードは期限切れになりません。値0(ゼロ) が指定されている場合、キャッシュされた資格情報は期限切れになりません。TheEXTCバリアントは、LdapExtendedログインモジュール。
例18.22 外部コマンドからパスワードを取得する
{EXT}cat /mysecretpasswordfile
例18.23 外部ファイルからパスワードを取得し、500 ミリ秒キャッシュします
{EXTC:500}cat /mysecretpasswordfile
