Aggregate-realm を使用すると、認証と別のセキュリティーレルムにいずれかのセキュリティーレルムを使用したり、Elytron での承認に複数のセキュリティーレルムの集約を使用したりできます。たとえば、集約レルムを設定して、認証にプロパティーレルムを使用して、承認に JDBC リレムを使用することができます。

複数の承認レルムを集約するよう設定されたアグリゲートレルムでは、以下のようにアイデンティティーが作成されます。

以下の例は、複数の承認レルムに同じアイデンティティー属性の定義が含まれる場合にアイデンティティーがどのように作成されるかを示しています。

authentication-realm=properties-realm,
authorization-realms=[jdbc-realm,ldap-realm]

その結果、集約レルムから取得されるアイデンティティーは以下のようになります。

e-mail: user@example.com
groups: Supervisor, User
phone: 0000 0000 0000

この例では、属性 e-mail が両方の承認レルムで定義されています。集約レルムは authorization-realms=[jdbc-realm,ldap-realm] のように承認レルムを集約するよう設定されていたため、JDBC レルムで定義された値は、生成される集約レルムの属性 e-mail に使用されます。

集約レルムを使用して認証と承認を設定するには、集約レルムを作成し、セキュリティードメインとアプリケーションセキュリティードメインを集約レルムを使用するように設定します。

以下のレルムを事前に設定する必要があります。

以下のコマンドを実行して、集約レルムを作成します。

/subsystem=elytron/aggregate-realm:exampleSimpleAggregateRealm:add(authentication-realm=examplPropertiesRealm,authorization-realm=exampleJdbcRealm)

以下のレルムを事前に設定する必要があります。

以下のコマンドを実行して、集約レルムを作成します。

/subsystem=elytron/aggregate-realm:exampleSimpleAggregateRealm:add(authentication-realm=examplPropertiesRealm,authorization-realms=[exampleJdbcRealm,exampleLdapRealm])

BEARER_TOKEN 認証メカニズムを使用して、アプリケーションに送信される HTTP リクエストを承認できます。Web ブラウザーなどのクライアントが HTTP 要求をアプリケーションに送信した後、BEARER_TOKEN メカニズムは、要求の Authorization HTTP ヘッダーにベアラートークンが存在することを確認します。

Elytron は、OpenID Connect ID トークンなどの JWT 形式のベアラートークンを使用するか、OAuth2 準拠の承認サーバーによって発行された不透明なトークンを使用することで認証をサポートします。関連情報のセクションを参照してください。

次の例は、Authorization HTTP ヘッダーに mF_9.B5f-4.1JqM ベアラートークンが含まれていることを示しています。

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

BEARER_TOKEN メカニズムは、ベアラトークン文字列を抽出し、検証のために token-realm 実装に渡すことができるようになりました。実装がベアラートークンの検証に成功すると、Elytron はトークンによって表される情報に基づいてセキュリティーコンテキストを作成します。アプリケーションは、このセキュリティーコンテキストを使用して、リクエスターに関する情報を取得できます。次に、リクエスターに HTTP リソースへのアクセスを提供することにより、リクエストを実行するかどうかを決定できます。

リクエスターがベアラートークンを提供しない場合、BEARER_TOKEN メカニズムは 401 HTTP ステータスコードを返します。以下に例を示します。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

リクエスターがリソースへのアクセスを許可されていない場合、BEARER_TOKEN メカニズムは 403 HTTP ステータスコードを返します。

HTTP/1.1 403 Forbidden

elytron サブシステムで token-realm を指定することで、JWT のサポートを有効にできます。

token-realm 内で、属性と jwt トークンバリデーターを指定できます。Elytron は次のチェックを完了します。

次の例は、セキュリティーレルムとして token-realm を示し、属性として principal-claim を示しています。principal-claim 属性は、elytron がプリンシパルの名前を取得するために使用するクレームの名前を定義します。jwt 要素は、トークンを JWT として検証する必要があることを指定します。

<token-realm name="${token_realm_name}" principal-claim="${principal_claim_key}">
    <jwt issuer="${issuer_name}"
         audience="${audience_name}"
         <public-key="${public_key_in_PEM_format}"/>
 </token-realm>

token-realm のキーマップを定義できます。次に、署名の検証にさまざまなキーペアを使用して、これらのキーペアを簡単にローテーションできます。Elytron はトークンから kid の主張を取得し、検証に対応する公開鍵を使用します。

<token-realm name="${token_realm_name}" principal-claim="${principal_claim_key}">
    <jwt issuer="${issuer_name}" audience="${audience_name}">
        <key kid="${key_ID_from_kid_claim}" public-key="${public_key_in_PEM_format}"/>
        <key kid="${another_key_ID_from_kid_claim}" public-key="${public_key_in_PEM_format}"/>
    </jwt>
</token-realm>

Elytron は、OAuth2 準拠の認証サーバーによって発行されたベアラートークンをサポートします。事前定義された oauth2-introspection エンドポイントに対してトークンを検証するようにトークンレルムを構成できます。

Open ID Connect ID トークンなどの JWT 形式のベアラートークンを使用するか、OAuth2 準拠の承認サーバーによって発行された不透明なトークンを使用して、アプリケーションの認証を構成できます。

LdapExtended (org.jboss.security.auth.spi.LdapExtLoginModule) はログインモジュール実装で、LDAP サーバー上のバインドユーザーと関連付けられたロールの特定に使用されます。ロールは再帰的にクエリーを行い、DN に従って階層的なロール構造を移動します。セキュリティードメインで LDAP を使用する場合、ほとんどの場合、特に Active Directory 以外の LDAP 実装では、LdapExtended ログインモジュールを使用する必要があります。LdapExtended ログインモジュールの設定オプションの完全リストは、JBoss EAP『ログインモジュールのリファレンス』の「LdapExtended ログインモジュール」を参照してください。

認証は以下のように行われます。

dn: uid=jduke,ou=Users,dc=jboss,dc=org
objectClass: inetOrgPerson
objectClass: person
objectClass: top
cn: Java Duke
sn: duke
uid: jduke
userPassword: theduke
# =============================
dn: uid=hnelson,ou=Users,dc=jboss,dc=org
objectClass: inetOrgPerson
objectClass: person
objectClass: top
cn: Horatio Nelson
sn: Nelson
uid: hnelson
userPassword: secret
# =============================
dn: ou=groups,dc=jboss,dc=org
objectClass: top
objectClass: organizationalUnit
ou: groups
# =============================
dn: uid=ldap,ou=Users,dc=jboss,dc=org
objectClass: inetOrgPerson
objectClass: person
objectClass: top
cn: LDAP
sn: Service
uid: ldap
userPassword: randall
# =============================
dn: ou=Users,dc=jboss,dc=org
objectClass: top
objectClass: organizationalUnit
ou: Users
# =============================
dn: dc=jboss,dc=org
objectclass: top
objectclass: domain
dc: jboss
# =============================
dn: uid=GroupTwo,ou=groups,dc=jboss,dc=org
objectClass: top
objectClass: groupOfNames
objectClass: uidObject
cn: GroupTwo
member: uid=jduke,ou=Users,dc=jboss,dc=org
uid: GroupTwo
# =============================
dn: uid=GroupThree,ou=groups,dc=jboss,dc=org
objectClass: top
objectClass: groupOfUniqueNames
objectClass: uidObject
cn: GroupThree
uid: GroupThree
uniqueMember: uid=GroupOne,ou=groups,dc=jboss,dc=org
# =============================
dn: uid=HTTP,ou=Users,dc=jboss,dc=org
objectClass: inetOrgPerson
objectClass: person
objectClass: top
cn: HTTP
sn: Service
uid: HTTP
userPassword: httppwd
# =============================
dn: uid=GroupOne,ou=groups,dc=jboss,dc=org
objectClass: top
objectClass: groupOfUniqueNames
objectClass: uidObject
cn: GroupOne
uid: GroupOne
uniqueMember: uid=jduke,ou=Users,dc=jboss,dc=org
uniqueMember: uid=hnelson,ou=Users,dc=jboss,dc=org

/subsystem=security/security-domain=testLdapExtendedExample:add(cache-type=default)

/subsystem=security/security-domain=testLdapExtendedExample/authentication=classic:add

/subsystem=security/security-domain=testLdapExtendedExample/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://localhost:10389"), ("java.naming.security.authentication"=>"simple"),     ("bindDN"=>"uid=ldap,ou=Users,dc=jboss,dc=org"), ("bindCredential"=>"randall"),     ("baseCtxDN"=>"ou=Users,dc=jboss,dc=org"), ("baseFilter"=>"(uid={0})"), ("rolesCtxDN"=>"ou=groups,dc=jboss,dc=org"),     ("roleFilter"=>"(uniqueMember={1})"), ("roleAttributeID"=>"uid")])

reload

/subsystem=security/security-domain=AD_Default:add(cache-type=default)

/subsystem=security/security-domain=AD_Default/authentication=classic:add

/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"=>"JBOSSsearchuser"), ("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")])

reload

/subsystem=security/security-domain=AD_Recursive:add(cache-type=default)

/subsystem=security/security-domain=AD_Recursive/authentication=classic:add

/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"=>"JBOSSsearchuser"), ("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")])

reload

Database ログインモジュールは、認証およびロールマッピングをサポートする JDBC ログインモジュールです。このログインモジュールは、ユーザー名、パスワード、およびロール情報がリレーショナルデータベースに格納される場合に使用されます。

このログインモジュールは、想定される形式のプリンシパルおよびロールが含まれる論理テーブルへの参照を提供して動作します。例を以下に示します。

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 つのテーブルがあるデータベースを検討してください。以下のステートメントは、以下のデータをテーブルに追加します。

Database ログインモジュールの設定オプションの完全リストは、JBoss EAP『ログインモジュールのリファレンス』の「Database ログインモジュール」を参照してください。

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:add

/subsystem=security/security-domain=testDB/authentication=classic:add

/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=?")])

reload

UsersRoles は、Java プロパティーファイルからロードされる複数のユーザーおよびユーザーロールをサポートする簡単なログインモジュールです。このログインモジュールの主な目的は、アプリケーションとともにデプロイされたプロパティーファイルを使用して複数のユーザーおよびロールのセキュリティー設定を簡単にテストすることです。デフォルトの username-to-password マッピングファイル名は users.properties で、デフォルトの username-to-roles マッピングファイル名は roles.propertiesです。

プロパティーファイルは、initialize メソッドスレッドコンテキストローダーを使用して初期化中にロードされます。つまり、これらのファイルは Jakarta EE デプロイメントのクラスパス (WAR アーカイブの WEB-INF/classes フォルダーなど) またはサーバークラスパスの任意のディレクトリーに配置できます。

UsersRoles ログインモジュールの設定オプションの完全リストは、JBoss EAP『Login Module Reference』の「UsersRoles ログインモジュール」を参照してください。

/subsystem=security/security-domain=sampleapp:add

/subsystem=security/security-domain=sampleapp/authentication=classic:add

/subsystem=security/security-domain=sampleapp/authentication=classic/login-module=UsersRoles:add(code=UsersRoles,flag=required,module-options=[("usersProperties"=>"sampleapp-users.properties"),("rolesProperties"=>"sampleapp-roles.properties")])

reload

証明書ベースの認証を使用するセキュリティードメインを作成するには、トラストストアと Certificate ログインモジュールまたはそのサブクラスの 1 つを指定する必要があります。

トラストストアには、認証に使用される信頼できるクライアント証明書が含まれるか、クライアントの証明書の署名に使用される認証局の証明書が含まれている必要があります。ログインモジュールは、設定されたトラストストアを使用してクライアントが提示する証明書を認証するために使用されます。セキュリティードメイン全体として、認証後にロールをプリンシパルにマップする方法も指定する必要があります。Certificate ログインモジュール自体は、ロール情報をプリンシパルにマップしませんが、別のログインモジュールと組み合わせることもできます。または、Certificate ログインモジュールの 2 つのサブクラス (CertificateRoles および DatabaseCertificate) でも、認証後にロールをプリンシパルにマップできます。以下の例は、CertificateRoles ログインモジュールを使用して、証明書ベースの認証でセキュリティードメインを設定する方法を示しています。

/subsystem=security/security-domain=cert-roles-domain:add

/subsystem=security/security-domain=cert-roles-domain/jsse=classic:add(truststore={password=secret, url="/path/to/server.truststore.jks"}, keystore={password=secret, url="/path/to/server.keystore.jks"}, client-auth=true)

/subsystem=security/security-domain=cert-roles-domain/authentication=classic:add

/subsystem=security/security-domain=cert-roles-domain/authentication=classic/login-module=CertificateRoles:add(code=CertificateRoles, flag=required, module-options=[ securityDomain="cert-roles-domain", rolesProperties="${jboss.server.config.dir}/cert-roles.properties",password-stacking="useFirstPass", verifier="org.jboss.security.auth.certs.AnyCertVerifier"])

user1=roleA
user2=roleB,roleC
user3=

CN\=valid-client,\ OU\=JBoss,\ O\=Red\ Hat,\ L\=Raleigh,\ ST\=NC,\ C\=US=Admin

$ keytool -printcert -file valid-client.crt
Owner: CN=valid-client, OU=JBoss, O=Red Hat, L=Raleigh, ST=NC, C=US
...

他の形式の認証でセキュリティードメインを使用するようアプリケーションを設定するのと同様に、jboss-web.xml ファイルおよび web.xml ファイルを適切に設定する必要があります。

Jboss-web.xml については、証明書ベースの認証に設定したセキュリティードメインへの参照を追加します。

<jboss-web>
  <security-domain>cert-roles-domain</security-domain>
</jboss-web>

web.xml の場合は、<login-config> の <auth-method> 属性を CLIENT-CERT に設定します。また、<security-constraint> と <security-roles> を定義する必要があります。

<web-app>
  <!-- URL for secured portion of application-->
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>secure</web-resource-name>
      <url-pattern>/secure/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>All</role-name>
    </auth-constraint>
  </security-constraint>

  <!-- Security roles referenced by this web application -->
  <security-role>
    <description>The role that is required to log in to the application</description>
    <role-name>All</role-name>
  </security-role>

  <login-config>
    <auth-method>CLIENT-CERT</auth-method>
    <realm-name>cert-roles-domain</realm-name>
  </login-config>
</web-app>

クライアントが証明書ベースの認証でセキュア化されたアプリケーションに対して認証するには、クライアントは JBoss EAP インスタンスのトラストストアに含まれるクライアント証明書へのアクセスが必要になります。たとえば、ブラウザーを使用してアプリケーションにアクセスする場合、クライアントは信頼された証明書をブラウザーのトラストストアにインポートする必要があります。

管理コンソールまたは管理 CLI を使用してセキュリティードメインのキャッシュタイプを設定できます。

/subsystem=security/security-domain=SECURITY_DOMAIN_NAME:list-cached-principals

管理コンソールまたは管理 CLI を使用してセキュリティードメインのキャッシングを無効にできます。

設定ファイルのアプローチでは、認証設定、認証コンテキスト、および一致ルールを含む XML ファイルを作成します。

<configuration>
    <authentication-client xmlns="urn:elytron:client:1.2">
        <authentication-rules>
            <rule use-configuration="monitor">
                <match-host name="127.0.0.1" />
            </rule>
            <rule use-configuration="administrator">
                <match-host name="localhost" />
            </rule>
        </authentication-rules>
        <authentication-configurations>
            <configuration name="monitor">
                <sasl-mechanism-selector selector="DIGEST-MD5" />
                <providers>
                  <use-service-loader />
                </providers>
                <set-user-name name="monitor" />
                <credentials>
                    <clear-password password="password1!" />
                </credentials>
                <set-mechanism-realm name="ManagementRealm" />
             </configuration>

             <configuration name="administrator">
                <sasl-mechanism-selector selector="DIGEST-MD5" />
                <providers>
                  <use-service-loader />
                </providers>
                <set-user-name name="administrator" />
                <credentials>
                    <clear-password password="password1!" />
                </credentials>
                <set-mechanism-realm name="ManagementRealm" />
             </configuration>
        </authentication-configurations>
    </authentication-client>
</configuration>

クライアントの実行時にシステムプロパティーを設定すると、クライアントのコードでこのファイルを参照できます。

$ java -Dwildfly.config.url=/path/to/custom-config.xml ...

ルールの作成時に、hostname、port、protocol、または user-name など、さまざまなパラメーターと一致するものを検索できます。MatchRule の完全なオプション一覧は Java ドキュメントで確認できます。ルールは、設定される順序で評価されます。

ルールに一致設定が含まれていない場合は、ルール全体が一致し、認証設定が選択されます。ルールに複数の一致設定が含まれる場合、認証設定を選択するには、すべてが一致する必要があります。

wildfly-config.xml ファイルの例は、「 Example wildfly-config.xml 」を参照してください。wildfly-config.xml ファイルを設定する方法の詳細については、wildfly-config.xml ファイルを使用したクライアント設定 を参照してください。

プログラムによるアプローチでは、クライアントのコードにすべての Elytron クライアント設定を設定します。

//create your authentication configuration
AuthenticationConfiguration adminConfig =
    AuthenticationConfiguration.empty()
      .useProviders(() -> new Provider[] { new WildFlyElytronProvider() })
      .setSaslMechanismSelector(SaslMechanismSelector.NONE.addMechanism("DIGEST-MD5"))
      .useRealm("ManagementRealm")
      .useName("administrator")
      .usePassword("password1!");

//create your authentication context
AuthenticationContext context = AuthenticationContext.empty();
context = context.with(MatchRule.ALL.matchHost("127.0.0.1"), adminConfig);


//create your runnable for establishing a connection
Runnable runnable =
    new Runnable() {
      public void run() {
        try {
           //Establish your connection and do some work
        } catch (Exception e) {
          e.printStackTrace();
        }
      }
    };

//use your authentication context to run your client
context.run(runnable);

設定の詳細を AuthenticationConfiguration および AuthenticationContext に追加するとき、各メソッド呼び出しはそのオブジェクトの新しいインスタンスを返します。たとえば、異なるホスト名で接続する際に別の設定が必要な場合は、以下を実行できます。

//create your authentication configuration
AuthenticationConfiguration commonConfig =
    AuthenticationConfiguration.empty()
      .useProviders(() -> new Provider[] { new WildFlyElytronProvider() })
      .setSaslMechanismSelector(SaslMechanismSelector.NONE.addMechanism("DIGEST-MD5"))
      .useRealm("ManagementRealm");

AuthenticationConfiguration administrator =
    commonConfig
      .useName("administrator")
      .usePassword("password1!");


AuthenticationConfiguration monitor =
    commonConfig
      .useName("monitor")
      .usePassword("password1!");


//create your authentication context
AuthenticationContext context = AuthenticationContext.empty();
context = context.with(MatchRule.ALL.matchHost("127.0.0.1"), administrator);
context = context.with(MatchRule.ALL.matchHost("localhost"), monitor);

また、空の認証設定を開始する代わりに、captureCurrent() を使用して現在設定されている認証を開始することもできます。

//create your authentication configuration
AuthenticationConfiguration commonConfig = AuthenticationConfiguration.captureCurrent();

captureCurrent() を使用すると、以前に確立された認証コンテキストがキャプチャーされ、新しいベース設定として使用されます。認証コンテキストは、run()を呼び出してアクティベートすると確立されます。captureCurrent() が呼び出され、コンテキストが現在アクティブでない場合、利用可能な場合はデフォルト認証を試行し、使用します。詳細は、以下のセクションを参照してください。

AuthenticationConfiguration.empty() は、上で設定を構築するベースとしてのみ使用し、それ自体では使用しないでください。JVM 全体で登録されたプロバイダーを使用し、匿名認証を有効にする設定を提供します。

AuthenticationConfiguration.empty() 設定でプロバイダーを指定する場合、カスタム一覧を指定できますが、ほとんどのユーザーは WildFlyElytronProvider() プロバイダーを使用する必要があります。

認証コンテキストを作成する場合は context.with(…​) を使用することで、現在のコンテキストのルールと認証設定を、指定のルールと認証設定とマージさせる新しいコンテキストが作成されます。指定されるルールおよび認証設定は、現在のコンテキストのルールおよび認証設定の後に表示されます。

デフォルト設定のアプローチは、Elytron Client によって提供される設定に完全に依存します。

//create your runnable for establishing a connection
Runnable runnable =
    new Runnable() {
      public void run() {
        try {
           //Establish your connection and do some work
        } catch (Exception e) {
          e.printStackTrace();
        }
      }
    };

// run runnable directly
runnable.run();

デフォルト設定を提供するために、Elytron クライアントはファイルシステム上の wildfly-config.xml ファイルの自動検出を試みます。以下の場所を探します。

以下の例は、クライアントの wildfly-config.xml ファイルの基本設定として使用できます。

<configuration>
  <authentication-client xmlns="urn:elytron:client:1.2">
    <authentication-rules>
      <rule use-configuration="default" />
    </authentication-rules>
    <authentication-configurations>
      <configuration name="default">
        <sasl-mechanism-selector selector="#ALL" />
        <set-mechanism-properties>
          <property key="wildfly.sasl.local-user.quiet-auth" value="true" />
        </set-mechanism-properties>
        <providers>
          <use-service-loader/>
        </providers>
      </configuration>
    </authentication-configurations>
  </authentication-client>
</configuration>

JBoss EAP にデプロイされたクライアントは Elytron クライアントを使用することもできます。AuthenticationContext は自動的に解析され、JBoss EAP 設定の default-authentication-context 設定から作成されます。default-authentication-context が設定されていないものの、デプロイメントに wildfly-config.xml ファイルが含まれるか、wildfly.config.url システムプロパティーを使用して設定されている場合、AuthenticationContext は自動的に解析され、そのファイルから作成されます。

/subsystem=elytron/authentication-context=AUTH_CONTEXT:add
/subsystem=elytron:write-attribute(name=default-authentication-context,value=AUTH_CONTEXT)

デプロイメント外で設定ファイルを読み込むには、parseAuthenticationClientConfiguration(URI) メソッドを使用します。このメソッドは、プログラムによるアプローチを使用してクライアントコードで使用できる programmatic approach を使用してクライアントコードで使用できる AuthenticationContext を返します。

さらに、クライアントは elytron サブシステムによって提供されるクライアント設定から AuthenticationContext を自動的に解析して作成します。elytron サブシステムのクライアント設定は、クレデンシャルストアなどの elytron サブシステムに定義された他のコンポーネントも利用できます。クライアント設定がデプロイメントと elytron サブシステムの両方によって提供される場合、elytron サブシステムの設定が使用されます。

JBoss EAP 7.1 以降で、JConsole などの Jakarta Management クライアントは、wildfly-config.xml ファイルを使用して設定できます。Jakarta Management クライアントの起動時に -Dwildfly.config.url システムプロパティーを使用して、設定ファイルへのファイルパスを指定します。

-Dwildfly.config.url=path/to/wildfly-config.xml

-J-Dwildfly.config.url=path/to/wildfly-config.xml

詳細は、JBoss EAP『開発ガイド』の「wildfly-config.xml ファイルを使用したクライアント設定」を参照してください。

JBoss EAP 7.1 には ElytronAuthenticator クラスが導入されました.これは現在のセキュリティーコンテキストを使用して認証を実行します。org.wildfly.security.auth.util.ElytronAuthenticator クラスは java.net.Authenticator の実装です。

以下は、ElytronAuthenticator クラスを作成して使用し、アイデンティティーをサーバーに伝播するクライアントコードの例です。

// Create the authentication configuration
AuthenticationConfiguration httpConfig = AuthenticationConfiguration.empty().useName("bob");

// Create the authentication context
AuthenticationContext context = AuthenticationContext.captureCurrent().with(MatchRule.ALL, httpConfig.usePassword(createPassword(httpConfig, "secret")));

String response = context.run((PrivilegedExceptionAction<String>) () -> {
    Authenticator.setDefault(new ElytronAuthenticator());
    HttpURLConnection connection = HttpURLConnection.class.cast(new URL("http://localhost:" + SERVER_PORT).openConnection());
    try (InputStream inputStream = connection.getInputStream()) {
        return new BufferedReader(new InputStreamReader(inputStream)).lines().findFirst().orElse(null);
    }
});

LDAP を使用して管理インターフェースをセキュアにする場合、双方向 SSL/TLS を使用するようアウトバウンド LDAP 接続を設定できます。これを行うには、ssl-context を作成し、ldap-realm が使用する dir-context に追加します。双方向 SSL/TLS ssl-context の作成は、『サーバーセキュリティーの設定方法』の「Elytron サブシステムを使用してアプリケーションに対して双方向 SSL/TLS を有効化する手順」を参照してください。

以下の手順に従って、SSL/TLS でセキュア化されたアウトバウンド LDAP 接続を作成します。

JBoss EAP では、認証および承認をセキュリティーレルムで個別に設定できます。これにより、LDAP を認証方法として設定でき、RBAC を承認メカニズムとして設定できます。この方法で設定された場合、ユーザーが管理インターフェースへのアクセス試行すると、最初に設定された LDAP サーバーを使用して認証されます。成功すると、LDAP サーバーにあるグループ情報に関係なく、そのロールのユーザーロールおよび設定されたパーミッションは RBAC のみを使用して決定されます。

RBAC を管理インターフェースの承認メカニズムとして使用する方法は、JBoss EAP『サーバーセキュリティーの設定方法 』を参照してください。管理インターフェースを使用した認証に LDAP を設定する方法は、前回のセクション を参照してください。

LDAP サーバーを使用して認証したユーザーまたはプロパティーファイルを使用したユーザーは、ユーザーグループのメンバーになります。ユーザーグループは、単一のユーザーに割り当てることのできる任意のラベルです。RBAC は、このグループ情報を使用してロールをユーザーに自動的に割り当てるか、ロールからユーザーを除外するように設定できます。

LDAP ディレクトリーには、ユーザーアカウントおよびグループのエントリーが含まれ、属性によって参照されます。LDAP サーバー設定によっては、ユーザーエンティティーはユーザーが所属するグループを memberOf 属性を介してマップできます。また、グループエンティティーは、uniqueMember 属性によってユーザーが属するユーザーをマップできます。ユーザーが LDAP サーバーに正常に認証されると、グループ検索が実行され、そのユーザーのグループ情報が読み込まれます。使用中のディレクトリーサーバーによっては、グループ検索は SN を使用して実行できます。これは通常、認証で使用されるユーザー名か、ディレクトリー内のユーザーのエントリー DN を使用して実行できます。LDAP をセキュリティーレルムの承認メカニズムとして設定すると、グループ検索 (username-to-dn) およびユーザー名と識別名 (username-to-dn) 間のマッピングが設定されます。

ユーザーのグループメンバーシップ情報が LDAP サーバーから決定されると、RBAC 設定内のマッピングを使用して、ユーザーが所有するロールが決定されます。このマッピングは、グループおよび個々のユーザーを明示的に包含または除外するように設定されます。

/core-service=management/security-realm=ldap-security-realm:add

batch

/core-service=management/security-realm=ldap-security-realm/authorization=ldap:add(connection=ldap-connection)

/core-service=management/security-realm=ldap-security-realm/authorization=ldap/group-search=principal-to-group:add(group-attribute="memberOf",iterative=true,group-dn-attribute="dn", group-name="SIMPLE",group-name-attribute="cn")

run-batch

/core-service=management/security-realm=ldap-security-realm:add

batch

/core-service=management/security-realm=ldap-security-realm/authorization=ldap:add(connection=ldap-connection)

/core-service=management/security-realm=ldap-security-realm/authorization=ldap/group-search=group-to-principal:add(iterative=true, group-dn-attribute="dn", group-name="SIMPLE", group-name-attribute="uid", base-dn="ou=groups,dc=group-to-principal,dc=example,dc=org", principal-attribute="uniqueMember", search-by="DISTINGUISHED_NAME")

run-batch

/core-service=management/access=authorization:read-attribute(name=provider)

{ "outcome" => "success", "result" => "rbac" }

/core-service=management/access=authorization:read-children-names(child-type=role-mapping)

{
  "outcome" => "success",
  "result" =>
    [ "Administrator", "Deployer", "Maintainer", "Monitor", "Operator", "SuperUser" ]
}

/core-service=management/access=authorization/role-mapping=Administrator:read-resource(recursive=true)

{
  "outcome" => "success",
  "result" =>
  {
    "include-all" => false,
    "exclude" => undefined,
    "include" => {
      "user-theboss" => {
        "name" => "theboss",
        "realm" => undefined,
        "type" => "USER"
      },
      "user-harold" => {
        "name" => "harold",
        "realm" => undefined,
        "type" => "USER"
      },
      "group-SysOps" => {
        "name" => "SysOps",
        "realm" => undefined,
        "type" => "GROUP"
      }
    }
  }
}

/core-service=management/access=authorization/role-mapping=Auditor:read-resource()

{
  "outcome" => "failed",
  "failure-description" => "WFLYCTL0216: Management resource '[ (\"core-service\" => \"management\"), (\"access\" => \"authorization\"), (\"role-mapping\" => \"Auditor\") ]' not found"
}

/core-service=management/access=authorization/role-mapping=Auditor:add()

{
  "outcome" => "success"
}

/core-service=management/access=authorization/role-mapping=Auditor:read-resource()

{
  "outcome" => "success",
  "result" => {
    "include-all" => false,
    "exclude" => undefined,
    "include" => undefined
  }
}

/core-service=management/access=authorization/role-mapping=Auditor/include=group-GroupToInclude:add(name=GroupToInclude, type=GROUP)

/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-GroupToExclude:add(name=GroupToExclude, type=GROUP)

/core-service=management/access=authorization/role-mapping=Auditor:read-resource(recursive=true)

{
  "outcome" => "success",
  "result" => {
    "include-all" => false,
    "exclude" => {
      "group-GroupToExclude" => {
        "name" => "GroupToExclude",
        "realm" => undefined,
        "type" => "GROUP"
      }
    },
    "include" => {
      "group-GroupToInclude" => {
        "name" => "GroupToInclude",
        "realm" => undefined,
        "type" => "GROUP"
      }
    }
  }
}

/core-service=management/access=authorization/role-mapping=Auditor/include=group-GroupToInclude:remove

/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-GroupToExclude:remove

キャッシュが相互に独立している場合でも、3 つすべてのキャッシュは同じ方法で設定されます。各キャッシュは以下の設定オプションを提供します。

"core-service" : { 
  "management" : { 
    "security-realm" : { 
      "LDAPRealm" : { 
        "authentication" : {
          "ldap" : {
            "allow-empty-passwords" : false,
            "base-dn" : "...", 
            "connection" : "MyLdapConnection", 
            "recursive" : false, 
            "user-dn" : "dn", 
            "username-attribute" : "uid", 
            "cache" : null
          }
        },
        "authorization" : {
          "ldap" : {
            "connection" : "MyLdapConnection", 
            "group-search" : {
              "group-to-principal" : { 
                "base-dn" : "...", 
                "group-dn-attribute" : "dn", 
                "group-name" : "SIMPLE", 
                "group-name-attribute" : "uid", 
                "iterative" : true, 
                "principal-attribute" : "uniqueMember", 
                "search-by" : "DISTINGUISHED_NAME", 
                "cache" : null 
              }
            }, 
            "username-to-dn" : {
              "username-filter" : { 
                "attribute" : "uid", 
                "base-dn" : "...", 
                "force" : false, 
                "recursive" : false, 
                "user-dn-attribute" : "dn", 
                "cache" : null 
                }
              } 
            }
          }, 
        } 
      } 
  }
}

"cache" : null が表示されるすべてのエリアで、キャッシュを設定できます。

/core-service=management/security-realm=LDAPRealm:read-resource(recursive=true)

{ 
  "outcome" => "success", 
  "result" => { 
    "map-groups-to-roles" => true, 
    "authentication" => {
      "ldap" => { 
        "advanced-filter" => undefined, 
        "allow-empty-passwords" => false, 
        "base-dn" => "dc=example,dc=com", 
         "connection" => "ldapConnection", 
         "recursive" => true, 
         "user-dn" => "dn", 
         "username-attribute" => "uid",
         "cache" => undefined 
        }
      }, 
      "authorization" => {
        "ldap" => { 
          "connection" => "ldapConnection", 
          "group-search" => {
            "principal-to-group" => { 
              "group-attribute" => "description", 
              "group-dn-attribute" => "dn", 
              "group-name" => "SIMPLE", 
              "group-name-attribute" => "cn", 
              "iterative" => false, 
              "prefer-original-connection" => true, 
              "skip-missing-groups" => false, 
              "cache" => undefined 
            }
          }, 
          "username-to-dn" => {
            "username-filter" => { 
              "attribute" => "uid", 
              "base-dn" => "ou=Users,dc=jboss,dc=org", 
              "force" => true, 
              "recursive" => false, 
              "user-dn-attribute" => "dn", 
              "cache" => undefined 
            }
          } 
        }
      }, 
      "plug-in" => undefined, 
      "server-identity" => undefined 
    }
  }

/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:add(eviction-time=300, cache-failures=true, max-cache-size=100)

/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-search-time:add(eviction-time=300, cache-failures=true, max-cache-size=100)

/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:read-resource(include-runtime=true)

{
  "outcome" => "success",
  "result" => {
    "cache-failures" => true,
    "cache-size" => 1,
    "eviction-time" => 300,
    "max-cache-size" => 100
  }
}

/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:contains(name=TestUserOne)

{
  "outcome" => "success",
  "result" => true
}

/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:flush-cache(name=TestUserOne)

/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:flush-cache()

/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:remove()

reload