サーバーセキュリティーの設定方法

Red Hat JBoss Enterprise Application Platform 7.4

Red Hat JBoss Enterprise Application Platform と管理インターフェイスを保護するための説明

概要

本書の目的は、Red Hat JBoss Enterprise
 Application Platform (JBoss EAP) のセキュリティーを保護するための実用的なガイドを提供することです。詳細は、JBoss EAP ですべての管理インターフェイスを保護にする方法を説明します。本ガイドを読む前に、Red Hat JBoss Enterprise Application Platform のセキュリティーアーキテクチャーを読み、JBoss EAP によるセキュリティーの処理方法を理解してください。また、本書では JBoss EAP CLI インターフェイスを使用して設定の変更を行います。本書を完読することで、JBoss EAP の保護方法についてしっかりと理解することができます。

Red Hat ドキュメントへのフィードバック

弊社のドキュメントに関するご意見やご感想をお寄せください。フィードバックをお寄せいただくには、ドキュメントのテキストを強調表示し、コメントを追加できます。以下の手順に従って、Red Hat ドキュメントのフィードバックをお寄せください。

前提条件

  • Red Hat カスタマーポータルにログインする。
  • Red Hat カスタマーポータルで、Multi-page HTML 形式のドキュメントを表示する。

手順

  1. フィードバック をクリックして、既存のリーダーコメントを表示します。

    注記

    フィードバック機能は、マルチページ HTML 形式でのみ有効です。

  2. フィードバックを提供するドキュメントのセクションを強調表示します。
  3. 選択したテキストの近くに表示されるプロンプトメニューで、Add Feedback をクリックします。

    ページの右側のフィードバックセクションにテキストボックスが開きます。

  4. テキストボックスにフィードバックを入力し、Submit をクリックします。

    ドキュメントに関する問題を作成しました。

  5. 問題を表示するには、フィードバックビューで問題トラッカーリンクをクリックします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。

第1章 サーバーおよびインターフェイスの保護

1.1. ブロックの構築

1.1.1. インターフェイスおよびソケットバインディング

JBoss EAP は、ホストのインターフェー (inet-addressnic など) と、Web アプリケーションとその管理インターフェイスの両方との通信用のポートを使用します。これらのインターフェイスおよびポートは、JBoss EAP の インターフェイス および socket-binding-groups 設定により定義され、設定されます。

インターフェイス および socket-binding-groups の定義および設定方法に関する詳細は、JBoss EAP設定ガイド ソケットバインディング を参照してください。

例: インターフェイス

<interfaces>
  <interface name="management">
    <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
  </interface>
  <interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
  </interface>
</interfaces>

例: ソケットバインディンググループ

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
    <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
    <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
    <outbound-socket-binding name="mail-smtp">
        <remote-destination host="localhost" port="25"/>
    </outbound-socket-binding>
</socket-binding-group>

1.1.2. Elytron サブシステム

1.1.2.1. サーバー全体での Elytron セキュリティーの有効化

Elytron は、シンプルな方法でサーバー全体に有効にできます。JBoss EAP 7.1 では、Elytron をセキュリティープロバイダーとして有効にするサンプル設定スクリプトが導入されました。このスクリプトは、サーバーインストールの EAP_HOME/docs/examples ディレクトリーにあります。

以下のコマンドを実行して、サーバー全体で Elytron セキュリティーを有効にします。

$ EAP_HOME/bin/jboss-cli.sh --file=EAP_HOME/docs/examples/enable-elytron.cli

1.1.2.2. Elytron セキュリティードメインの作成

elytron サブシステムのセキュリティードメインはセキュリティーレルムと併せて使用されると、コア管理認証とアプリケーションによる認証の両方に使用されます。

重要

Elytron セキュリティードメインの使用は、ドメインごとに 1 つに限定されます。複数のレガシーセキュリティーが必要である場合、1 つの Elytron セキュリティードメインを使用して対応できるようになりました。

管理 CLI を使用したセキュリティードメインの追加
/subsystem=elytron/security-domain=domainName:add(realms=[{realm=realmName,role-decoder=roleDecoderName}],default-realm=realmName,permission-mapper=permissionMapperName,role-mapper=roleMapperName,...)
管理コンソールを使用したセキュリティードメインの追加
  1. 管理コンソールにアクセスします。詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。
  2. Configuration → SubsystemsSecurity (Elytron)Other Settings と選択し、表示 をクリックします。
  3. SSLセキュリティードメイン を選択し、追加 ボタンをクリックして新しいセキュリティードメインを設定します。

1.1.2.3. Elytron セキュリティーレルムの作成

elytron サブシステムのセキュリティーレルムはセキュリティードメインと併せて使用されると、コア管理認証とアプリケーションによる認証の両方に使用されます。また、セキュリティーレルムは、jdbc-realmfilesystem-realmproperties-realm など、アイデンティティーストアに基づいて具体的に入力されます。

管理 CLI を使用したセキュリティーレルムの追加
/subsystem=elytron/type-of-realm=realmName:add(....)

jdbc-realmfilesystem-realm、および properties-realm などの特定のレルムを追加する例は、前のセクションにあります。

管理コンソールを使用したセキュリティーレルムの追加
  1. 管理コンソールにアクセスします。詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。
  2. ConfigurationSubsystemsSecurity (Elytron)Security Realms と選択し、表示 をクリックします。
  3. セキュリティーレルム タブから適切なセキュリティーレルムタイプを選択し、追加 をクリックして新しいセキュリティーレルムを設定します。

1.1.2.4. Elytron ロールデコーダーの作成

ロールデコーダーは、セキュリティーレルムによって提供される ID の属性をロールに変換します。また、ロールデコーダーは、empty-role-decodersimple-role-decodercustom-role-decoder などの機能に基づいて具体的に入力されます。

管理 CLI を使用したロールデコーダーの追加
/subsystem=elytron/ROLE-DECODER-TYPE=roleDeoderName:add(....)
管理コンソールを使用したロールデコーダーの追加
  1. 管理コンソールにアクセスします。詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。
  2. ConfigurationSubsystemsSecurity (Elytron)Mappers / Decoders と選択し、表示 をクリックします。
  3. Role Decoder をクリックし、適切なロールデコーダータイプを選択し、Add をクリックして新規ロールデコーダーを設定します。

1.1.2.5. elytron サブシステムへの source-address-role-decoder の追加

管理 CLI または管理コンソールのいずれかを使用して、source-address-role-decoder ロールデコーダを elytron サブシステムに追加します。このロールデコーダを mappers 要素に設定して、クライアントの IP アドレスで権限付与に関する判断を下すことができます。

source-address-role-decoder は、クライアントの IP アドレスを抽出し、pattern 属性または source-address 属性で指定された IP アドレスと一致することを確認します。クライアントの IP アドレスがいずれかの属性で指定された IP アドレスと一致する場合、elytronroles 属性を使用してユーザーにロールを割り当てます。

注記

この手順では、管理 CLI を使用して、elytron サブシステムの mappers 要素に source-address-role-decoder を追加します。管理コンソールを使用してこのタスクを実行する場合は、関連資料セクションで提供されるリンクを参照してください。

前提条件

  • サーバーのクライアントの IP アドレスを書き留めておく。

手順

  1. elytron サブシステムでは、管理 CLI を使用して source-address-role-decoder を追加します。source-address-role-decoder の場合は、ユーザーの IP アドレスと少なくとも 1 つのロールを指定する必要があります。

    mappers 要素に source-address-role-decoder を追加した例。

    /subsystem=elytron/source-address-role-decoder=decoder1:add(source-address="10.10.10.10", roles=["Administrator"])

    この例では、 source-address-role-decoderdecoder1 と名付けて設定しています。クライアントのサーバー接続時に、elytron サブシステムは source-address-role-decoder を使用して、クライアントの IP アドレスが pattern 属性または source-address 属性のいずれかで指定された IP アドレスと一致するかどうかをチェックします。前述の例では、source-address-role-decoder は、クライアントの IP アドレスが 10.10.10.10 であるかどうかをチェックします。クライアントの IP アドレスが 10.10.10.10 の場合、elytronroles 属性を使用してユーザーに Administrator ロールを割り当てます。

    注記

    異なるネットワークからの接続を確立する必要があるユーザーに、特定のロールを割り当てるために、source-address-role-decoder を設定できます。

  2. security-domain では、role-decoder 属性で設定済みの source-address-role-decoder を参照します。これにより、Elytron セキュリティードメインが認証の判断を行う際に source-address-role-decoder が使用されます。

    設定されている source-address-role-decoder,decoder1role-decoder 属性で参照している例。

    /subsystem=elytron/security-domain=domainName:add(role-decoder=decoder1,default-realm=realmName,realms=[{realm=realmName}])

関連情報

  • 管理コンソールでロールデコーダーを追加する方法は、Elytron Subsystem を参照してください。
  • elytron サブシステムは、Security ArchitectureガイドのElytron Subsystemを参照してください。

1.1.3. elytron サブシステムへの aggregate-role-decoder の設定

aggregate-role-decoder は、2 つ以上のロールデコーダーで設定されます。aggregate-role-decoder を使用すると、各ロールデコーダから返されたロールを集約できます。

前提条件

  • elytron サブシステムに少なくとも 2 つのロールデコーダを設定する。

手順

  • aggregate-role-decoder ロールデコーダに少なくとも 2 つのロールデコーダを追加します。

    aggregate-role-decoder ロールデコーダに decoder1decoder2 を追加した例。

    /subsystem=elytron/aggregate-role-decoder=aggregateDecoder:add(role-decoders=[decoder1, decoder2])

関連情報

  • elytron サブシステムで利用可能なロールデコーダは、Security ArchitectureガイドのResources in Elytron Subsystemを参照してください。
  • ロールデコーダの作成については、Elytron Subsystem を参照してください。

1.1.3.1. Elytron ロールマッパーの作成

ロールマッパーは、ロールが他のロールにデコードされた後にロールをマッピングします。例には、ロール名の正規化、またはデコードされた後のプリンシパルへの特定のロールの追加と、このプリンシパルからの削除が含まれます。ロールマッパーは、たとえば add-prefix-role-mapperadd-suffix-role-mapperconstant-role-mapper などの機能に基づいて具体的に型が指定されます。

ロールマッパーを追加すると、一般的な形式になります
/subsystem=elytron/ROLE-MAPPER-TYPE=roleMapperName:add(...)
管理コンソースを使用したロールマッパーの追加
  1. 管理コンソールにアクセスします。詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。
  2. ConfigurationSubsystemsSecurity (Elytron)Mappers / Decoders と選択し、表示 をクリックします。
  3. Role Mapper をクリックし、適切なロールマッパータイプを選択し、Add をクリックして新規ロールマッパーを設定します。

1.1.3.2. Elytron パーミッションセットの作成

パーミッションセットを使用すると、パーミッションをアイデンティティーに割り当てることができます。

管理 CLI を使用したパーミッションセットの追加
/subsystem=elytron/permission-set=PermissionSetName:add(permissions=[{class-name="...", module="...", target-name="...", action="..."}...])

permissions パラメーターは一連のパーミッションで設定されます。各パーミッションには次の属性があります。

  • class-name は、パーミッションの完全修飾クラス名です。これは、必要な唯一のパーミッション属性です。
  • モジュール は、パーミッションのロードに使用されるオプションのモジュールです。
  • target-name は、構築されるときにパーミッションに渡される任意のターゲット名です。
  • action は、構築されたときにパーミッションに渡される任意のアクションです。

1.1.3.3. Elytron パーミッションマッパーの作成

アイデンティティーに割り当てられているロールに加え、パーミッションを割り当てることもできます。パーミッションマッパーはパーミッションをアイデンティティーに割り当てます。パーミッションマッパーは、その機能に基づいて、logical-permission-mappersimple-permission-mappercustom-permission-mapper などのように具体的に型指定されます。

管理 CLI を使用したパーミッションマッパーの追加
/subsystem=elytron/simple-permission-mapper=PermissionMapperName:add(...)
管理コンソールを使用したパーミッションマッパーの追加
  1. 管理コンソールにアクセスします。詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。
  2. ConfigurationSubsystemsSecurity (Elytron)Mappers / Decoders と選択し、表示 をクリックします。
  3. Principal Decoder をクリックし、適切なプリンシパルデコーダータイプを選択して、Add をクリックし、新しいプリンシパルデコーダーを設定します。

1.1.3.4. 認証設定の作成

認証設定には、接続を行う際に使用する認証情報が含まれます。認証設定の詳細は、JBoss EAPHow to Configure Identity ManagementElytron クライアントによるクライアント認証の設定 を参照してください。

注記

Elytron セキュリティードメインは、認証情報ストアの代わりに、アクセスしているユーザーの認証情報を使用するように設定できます。たとえば、セキュリティードメインは、アクセスしてくるユーザーの認証に Kerberos と組み合わせて使用できます。JBoss EAP のKerberos による SSO のセットアップ方法 Configure the Elytron Subsystem に従い、Kerberos セキュリティーファクトリーで obtain-kerberos-ticket=true に設定します。

管理 CLI を使用した認証設定の追加
/subsystem=elytron/authentication-configuration=AUTHENTICATION_CONFIGURATION_NAME:add(authentication-name=AUTHENTICATION_NAME, credential-reference={clear-text=PASSWORD})
管理コンソールを使用した認証設定の追加
  1. 管理コンソールにアクセスします。詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。
  2. Configuration → SubsystemsSecurity (Elytron)Other Settings と選択し、表示 をクリックします。
  3. AuthenticationAuthentication Configuration の順にクリックし、Add をクリックして新しい認証設定を設定します。

authentication-configuration 属性の完全リストは、Elytron サブシステムのコンポーネント を参照してください。

1.1.3.5. authentication-context の作成

認証コンテキストには、一連のルールと、接続の確立に使用する 認証設定 または SSL contexts が含まれます。認証コンテキストの詳細は、JBoss EAP アイデンティティー管理の設定方法Elytron クライアントによるクライアント認証の設定 を参照してください。

管理 CLI を使用した認証コンテキストの追加

認証コンテキストは、以下の管理 CLI コマンドを使用して作成できます。

/subsystem=elytron/authentication-context=AUTHENTICATION_CONTEXT_NAME:add()

通常、認証コンテキストには一連のルールと、認証設定または SSL コンテキストのいずれかが含まれます。以下の CLI コマンドは、ホスト名が localhost の場合にのみ機能する認証コンテキストの定義を示しています。

/subsystem=elytron/authentication-context=AUTHENTICATION_CONTEXT_NAME:add(match-rules=[{authentication-configuration=AUTHENTICATION_CONFIGURATION_NAME, match-host=localhost}])
管理コンソールを使用した認証コンテキストの追加
  1. 管理コンソールにアクセスします。詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。
  2. Configuration → SubsystemsSecurity (Elytron)Other Settings と選択し、表示 をクリックします。
  3. AuthenticationAuthentication Context の順にクリックし、Add をクリックして、新しい認証コンテキストを設定します。

authentication-context 属性の完全リストは、Elytron サブシステムのコンポーネント を参照してください。

1.1.3.6. Elytron 認証ファクトリーの作成

認証ファクトリーは、特定の認証メカニズムに使用される認証ポリシーです。認証ファクトリーは特に、http-authentication-factorysasl-authentication-factory および kerberos-security-factory などの認証メカニズムに基づいています。

管理 CLI を使用した認証ファクトリーの追加
/subsystem=elytron/AUTH-FACTORY-TYPE=authFactoryName:add(....)
管理コンソールを使用した認証ファクトリーの追加
  1. 管理コンソールにアクセスします。詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。
  2. Configuration → SubsystemsSecurity (Elytron)Factories / transformers の順に選択し、表示 をクリックします。
  3. HTTP FactoriesSASL Factories、または Other Factories をクリックして、適切なファクトリータイプを選択し、Add をクリックして新しいファクトリーを設定します。

1.1.3.7. Elytron キーストアの作成

key-store は、キーストアの種類、その場所、アクセスするためのクレデンシャルなどを含むキーストアまたはトラストストアの定義です。

elytron サブシステムで使用するキーストアのサンプルを生成するには、以下のコマンドを使用します。

$ keytool -genkeypair -alias localhost -keyalg RSA -keysize 1024 -validity 365 -keystore keystore.jks -dname "CN=localhost" -keypass secret -storepass secret
管理 CLI を使用したキーストアの追加

新たに作成されたキーストアを参照する Elytron で key-store を定義するには、以下の管理 CLI コマンドを実行します。このコマンドは、提供されるファイルシステムパス、キーストアのアクセスに使用される認証情報の参照、キーストアのタイプに関連したキーストアへのパスを指定します。

/subsystem=elytron/key-store=newKeyStore:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
注記

上記のコマンドは、relative-to を使用してキーストアファイルの場所を参照します。または、path のキーストアにフルパスを指定することで、relative-to を省略できます。

管理コンソールを使用したキーストアの追加
  1. 管理コンソールにアクセスします。詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。
  2. Configuration → SubsystemsSecurity (Elytron)Other Settings と選択し、表示 をクリックします。
  3. StoresKey Store の順にクリックし、Add をクリックして新しいキーストアを設定します。

1.1.3.8. Elytron キーマネージャーの作成

key-managerkey-store を参照し、SSL コンテキストとともに使用されます。

管理 CLI を使用したキーマネージャーの追加

以下のコマンドは、参照する基盤のキーストア、キーマネージャーを初期化するときに使用するアルゴリズム、基礎となるキーストアのエントリーにアクセスするための認証情報の参照を指定します。

/subsystem=elytron/key-manager=newKeyManager:add(key-store=KEY_STORE,credential-reference={clear-text=secret})
重要

Elytron サブシステムはデフォルトで KeyManagerFactory.getDefaultAlgorithm() を使用してアルゴリズムを決定するため、Red Hat は前のコマンドでアルゴリズム属性を指定しませんでした。ただし、アルゴリズム属性は指定できます。アルゴリズム属性を指定するには、使用している JDK によるキーマネージャーアルゴリズムを知る必要があります。たとえば、SunJSSE を使用する JDK は、PKIX および SunX509 アルゴリズムを提供します。

前のコマンドでは、SunX509 をキーマネージャーアルゴリズム属性として指定できます。

管理コンソールを使用したキーマネージャーの追加
  1. 管理コンソールにアクセスします。詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。
  2. Configuration → SubsystemsSecurity (Elytron)Other Settings と選択し、表示 をクリックします。
  3. SSLKey Manager をクリックし、Add をクリックして新しいキーマネージャーを設定します。

1.1.3.9. Elytron トラストストアの作成

Elytron でトラストストアを作成するには、以下の CLI コマンドを実行します。

/subsystem=elytron/key-store=default-trust-store:add(type=JKS, relative-to=jboss.server.config.dir, path=application.truststore, credential-reference={clear-text=password})

このコマンドを正常に実行するには、EAP_HOME/standalone/configuration ディレクトリー内に application.truststore ファイルを含める必要があります。エンドポイントの証明書が CA によって署名されている場合は、トラストストアに、エンドポイントや証明書チェーンに関連付けられた証明書が含まれる必要があります。

Red Hat は、自己署名証明書の使用は推奨していません。理想的には、証明書は CA によって署名され、トラストストアには、ROOT および中間 CA を示す証明書チェーンが含まれている必要があります。

1.1.3.10. Elytron トラストマネージャーの作成

Elytron でトラストマネージャーを定義するには、以下の CLI コマンドを実行します。

/subsystem=elytron/trust-manager=default-trust-manager:add(key-store=TRUST-STORE-NAME)

これにより、アプリケーションサーバーが信頼する証明書のソースとして、定義されたトラストストアが設定されます。

1.1.3.11. 初期状態の Elytron コンポーネントの使用

JBoss EAP では、elytron サブシステムで設定された一連のデフォルトの Elytron コンポーネントを利用できます。これらの事前設定されたコンポーネントの詳細は、セキュリティーアーキテクチャーガイドの 初期状態 のセクションを参照してください。

1.1.3.11.1. 管理インターフェイスのセキュア化

JBoss EAP を有効化して、管理インターフェイスの保護を行うために初期状態の Elytron コンポーネントを使用する詳細は、Elytron でのユーザー認証 を参照してください。

1.1.3.11.2. アプリケーションの保護

elytron サブシステムではデフォルトで、http-authentication-factoryapplication-http-authentication を利用できます。これは、アプリケーションの保護に使用できます。application-http-authentication の設定方法の詳細は、セキュリティーアーキテクチャーガイドの 初期設定 を参照してください。

application-http-authentication を使用するようにアプリケーションを設定するには、アイデンティティ管理ガイドの設定方法認証に Elytron またはレガシーセキュリティーを使用するよう Web アプリケーションを設定する手順 を参照してください。また、JBoss EAP アイデンティティー管理の設定方法アプリケーションの認証設定の上書き の手順に従って、すべてのアプリケーションのデフォルトの動作を上書きできます。

1.1.3.11.3. SSL/TLS の使用

JBoss EAP では、レガシーコア管理認証を使用してデフォルトの一方向 SSL/TLS 設定を利用できます。ただし、elytron サブシステムでは利用できません。以下のセクションでは、管理インターフェイスとアプリケーションの両方に elytron サブシステムを使用して SSL/TLS の設定に関する詳細を確認することができます。

1.1.3.11.4. Elytron を他のサブシステムで使用する

アプリケーションと管理インターフェイスの保護に加えて、Elytron は JBoss EAP の他のサブシステムとも統合します。

batch-jberet
batch-jberet サブシステムを設定すると、Elytron セキュリティードメインでバッチジョブを実行することができます。詳細は、設定ガイドバッチジョブのセキュリティー設定 を参照してください。
datasources
クレデンシャルストアまたは Elytron セキュリティードメインを使用することで、データソース定義に認証情報を提供できます。詳細は、設定ガイド データセキュリティー を参照してください。
ejb3
Elytron セキュリティードメインのマッピングを ejb3 サブシステムで作成し、デプロイメントによって参照されるようにすることができます。詳細は、Jakarta Enterprise Beans アプリケーションの開発EJB サブシステムと Elytron の統合 を参照してください。
iiop-openjdk
elytron サブシステムを使用することで、iiop-openjdk サブシステムを使用してクライアントとサーバーの間で SSL/TLS を設定できます。詳細は、設定ガイドElytron サブシステムで SSL/TLS を使用するよう IIOP を設定 を参照してください。
jca
elytron-enabled 属性を使用して、ワークマネージャーの Elytron セキュリティーを有効にできます。詳細は、JBoss EAP設定ガイドIO サブシステムの設定 を参照してください。
jgroups
SYM_ENCRYPT および ASYM_ENCRYPT プロトコルを設定して、elytron サブシステムで定義されたキーストアまたは認証情報リファレンスを参照できます。詳細については、設定ガイド クラスターのセキュア化 を参照してください。
mail
認証情報ストアを使用することで、mail サブシステムのサーバー定義に認証情報を指定できます。詳細は、設定ガイドパスワードに認証情報ストアを使用 を参照してください。
messaging-activemq
messaging-activemq サブシステムで使用されるリモート接続へのリモート接続を保護することができます。詳細は、メッセージングの設定Elytron Subsystem の使用 セクションを参照してください。
modcluster
Elytron クライアント ssl-context を使用することで、SSL/TLS を使用してロードバランサーと通信できます。詳細は、Elytron Integration with the ModCluster Subsystem を参照してください。
remoting
remoting サブシステムのインバウンドおよびアウトバウンド接続を設定して、elytron サブシステムに定義された認証コンテキスト、SASL 認証ファクトリー、および SSL コンテキストを参照できます。各種類の接続の設定に関する詳細は、Elytron Integration with the Remoting Subsystem を参照してください。
resource-adapters
Elytron を使用してリソースアダプターへの接続をセキュアにすることができます。作業マネージャーによって実行される作業を送信するときに、セキュリティーインフローを有効にしてセキュリティー資格情報を確立できます。詳細は、設定ガイド Elytron サブシステムを使用するようリソースアダプターを設定 を参照してください。
undertow
elytron サブシステムを使用すると、SSL/TLS とアプリケーション認証の両方を設定できます。アプリケーション認証の設定に関する詳細は、How to Configure Identity ManagementSSL/TLS の使用認証に Elytron またはレガシーセキュリティーを使用するよう Web アプリケーションを設定する手順 を参照してください。

1.1.3.12. Elytron サブシステムの有効化および無効化

elytron サブシステムは、レガシー security サブシステムとともにデフォルトの JBoss EAP プロファイルで事前設定されています。

elytron サブシステムが設定されていないプロファイルを使用している場合は、elytron エクステンションを追加し、elytron サブシステムを有効にして追加できます。

elytron サブシステムに必要な elytron 拡張機能を追加する方法:

/extension=org.wildfly.extension.elytron:add()

JBoss EAP で elytron サブシステムを有効にする方法:

/subsystem=elytron:add

reload

JBoss EAP で elytron サブシステムを無効にする方法:

/subsystem=elytron:remove

reload
重要

JBoss EAP 内の他のサブシステムには elytron サブシステムの依存関係があることがあります。これらの依存関係を無効にしても問題が解決されない場合、JBoss EAP の起動時にエラーが発生します。

1.1.4. レガシーセキュリティーサブシステム

1.1.4.1. セキュリティーサブシステムの無効化

サブシステムの remove オペレーションを実行して、JBoss EAP の security サブシステムを無効にできます。

手順

  • JBoss EAP で security サブシステムを無効にする方法:

    /subsystem=security:remove
重要

JBoss EAP 内のその他のサブシステムには、security サブシステムの依存関係があることがあります。これらの依存関係を無効にしても問題が解決されない場合、JBoss EAP の起動時にエラーが発生します。

1.1.4.2. セキュリティーサブシステムの有効化

サブシステムの add 操作を実行して、JBoss EAP の security サブシステムを有効にすることができます。

手順

  • JBoss EAP で security サブシステムを有効にする方法:

    /subsystem=security:add

1.1.5. レガシーセキュリティーレルム

JBoss EAP はセキュリティーレルムを使用して、ローカル、LDAP、プロパティーなどの認証および承認メカニズムを定義します。

例: セキュリティーレルム

<security-realms>
  <security-realm name="ManagementRealm">
    <authentication>
      <local default-user="$local" skip-group-loading="true"/>
      <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
    </authentication>
    <authorization map-groups-to-roles="false">
      <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
    </authorization>
  </security-realm>
  <security-realm name="ApplicationRealm">
    <authentication>
      <local default-user="$local" allowed-users="*" skip-group-loading="true"/>
      <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
    </authentication>
    <authorization>
      <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
    </authorization>
  </security-realm>
</security-realms>

注記

JBoss EAP では、既存のセキュリティーレルムの更新に加え、新しいセキュリティーレルムの作成も可能になります。管理コンソールで新しいセキュリティーレルムを作成したり、管理 CLI から以下のコマンドを呼び出すこともできます。

/core-service=management/security-realm=<new_realm_name>:add()

新しいセキュリティーレルムを作成し、認証または承認にプロパティーファイルを使用する場合は、新しいセキュリティードメイン専用の新しいプロパティーファイルを作成する必要があります。JBoss EAP は、他のセキュリティードメインによって使用される既存のファイルを再利用せず、設定ファイルが存在しない場合には、設定に指定された新しいファイルを自動的に作成します。

関連情報

1.1.6. 管理インターフェイスのセキュア化に認証とソケットバインディングを使用する

socket-bindinghttp-authentication-factory、および http-upgrade を組み合わせることで、elytron サブシステムを使用して管理インターフェイスを保護できます。または、security-realm とともに socket-binding を使用して、レガシーコア管理認証で管理インターフェイスをセキュア化にすることもできます。また、管理インターフェイスを無効にし、さまざまなロールとアクセス権を持つようにインターフェイスのユーザーを設定することもできます。

デフォルトでは、JBoss EAP は管理インターフェイスに接続するための http-interface を定義します。

手順

  • サーバー管理インターフェイスの設定を表示します。

    [standalone@localhost:9990 /] /core-service=management:read-resource(recursive=true)
    {
        "outcome" => "success",
        "result" => {
            "access" => {...},
            "ldap-connection" => undefined,
            "management-interface" => {"http-interface" => {
                "allowed-origins" => undefined,
                "console-enabled" => true,
                "http-authentication-factory" => "management-http-authentication",
                "http-upgrade" => {
                    "enabled" => true,
                    "sasl-authentication-factory" => "management-sasl-authentication"
                },
                "http-upgrade-enabled" => true,
                "sasl-protocol" => "remote",
                "secure-socket-binding" => undefined,
                "security-realm" => undefined,
                "server-name" => undefined,
                "socket-binding" => "management-http",
                "ssl-context" => undefined
            }},
            "security-realm" => {...},
            "service" => undefined
        }
    }

1.2. 管理インターフェイスのセキュア化の方法

ここでは、JBoss EAP 管理インターフェイスと関連サブシステムのセキュア化に関連するさまざまな操作を実行する方法を説明します。

注記

ここで使用する管理 CLI コマンドは、JBoss EAP スタンドアロンサーバーを実行していることを仮定しています。JBoss EAP 管理対象ドメインの管理 CLI を使用する場合の詳細は 管理 CLI ガイド を参照してください。

管理 CLI との Elytron の統合

管理インターフェイスは、レガシーセキュリティーレルムの場合と同様に、elytron サブシステムのリソースを使用して保護できます。

接続の SSL 設定は、以下の場所のいずれかから取得されます。

  • CLI 固有の設定内の SSL 設定。
  • サーバー証明書を受け入れるようにユーザーに自動的にプロンプトするデフォルトの SSL 設定。
  • java システムプロパティー。

クライアント設定は、wildfly-config.xml ファイルを使用して変更できます。

注記

-Dwildfly.config.url プロパティーを設定する場合は、すべてのファイルをクライアントの設定に使用できます。

1.2.1. ネットワークおよびポートの設定

ホストの設定に応じて、JBoss EAP はさまざまなネットワークインターフェイスおよびポートを使用するように設定できます。これにより、JBoss EAP はさまざまなホスト、ネットワーク、およびファイアウォール要件で使用できます。

関連情報

1.2.2. 管理コンソールの無効化

JBoss Operations Network などの他のクライアントは、JBoss EAP の管理に HTTP インターフェイスを使用して動作します。これらのサービスの使用を継続するには、Web ベースの管理コンソール自体を無効にしてください。これは、console-enabled 属性を false に設定すると実行できます。

手順

  • JBoss EAP の Web ベースの管理コンソールを無効にするには、次の手順に従います。

    /core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)

1.2.3. JMX へのリモートアクセスの無効化

jmx サブシステムへのリモートアクセスにより、JDK とアプリケーション管理操作がリモートでトリガーできます。

手順

  • JBoss EAP で JMX へのリモートアクセスを無効にするには、jmx サブシステムのリモーティングコネクターを削除します。

    /subsystem=jmx/remoting-connector=jmx/:remove

1.2.4. サイレント認証

JBoss EAP のデフォルトインストールには、ローカル管理 CLI ユーザーのサイレント認証メソッドが含まれています。これにより、ローカルユーザーは、ユーザー名またはパスワード認証なしで管理 CLI にアクセスできます。この機能を有効にすると、ローカルユーザーが認証なしに管理 CLI スクリプトを実行できるようになります。通常、ユーザーがローカル設定にアクセスできれば、独自のユーザー詳細を追加することもできるため便利な機能と見なされます。

より高度なセキュリティー管理が必要な場合は、サイレント認証を無効にできます。これは、設定ファイルの security-realm 属性内の local 要素を削除することによって実現できます。これは、スタンドアロンインスタンスと管理対象ドメインの両方が対象となります。

重要

local 要素の削除は、JBoss EAP インスタンスの影響と、その設定を完全に理解している場合にのみ行う必要があります。

手順

  1. elytron サブシステムの使用時にサイレント認証を削除するには、以下の手順に従います。

    [standalone@localhost:9990 /] /subsystem=elytron/sasl-authentication-factory=managenet-sasl-authentication:read-resource
    {
        "outcome" => "success",
        "result" => {
            "mechanism-configurations" => [
                {
                    "mechanism-name" => "JBOSS-LOCAL-USER",
                    "realm-mapper" => "local"
                },
                {
                    "mechanism-name" => "DIGEST-MD5",
                    "mechanism-realm-configurations" => [{"realm-name" => "ManagementRealm"}]
                }
            ],
            "sasl-server-factory" => "configured",
            "security-domain" => "ManagementDomain"
        }
    }
    
    [standalone@localhost:9990 /] /subsystem=elytron/sasl-authentication-factory=managenet-sasl-authentication:list-remove(name=mechanism-configurations, index=0)
    
    [standalone@localhost:9990 /] reload
  2. レガシーセキュリティーレルムの使用時にサイレント認証を削除するには、以下を行います。

    /core-service=management/security-realm=<realm_name>/authentication=local:remove

1.2.5. Elytron サブシステムを使用して管理インターフェイスに対して一方向 SSL/TLS

JBoss EAP では、JBoss EAP 管理 CLI または管理コンソールを使用して管理インターフェイスの一方向 SSL/TLS を有効にできます。

管理 CLI では、一方向の SSL/TLS を以下の方法で有効にできます。

マネージメントコンソールでは、以下の方法で一方向 SSL/TLS を有効できます。

1.2.5.1. Security コマンドを使用した一方向 SSL/TLS の有効化

security enable-ssl-management コマンドを使用すると、管理インターフェイスに一方向 SSL/TLS を有効にできます。

手順

  • CLI で security enable-ssl-management --interactive コマンドを入力します。

    security enable-ssl-management --interactive
    
    Please provide required pieces of information to enable SSL:
    Key-store file name (default management.keystore): keystore.jks
    Password (blank generated): secret
    What is your first and last name? [Unknown]: localhost
    What is the name of your organizational unit? [Unknown]:
    What is the name of your organization? [Unknown]:
    What is the name of your City or Locality? [Unknown]:
    What is the name of your State or Province? [Unknown]:
    What is the two-letter country code for this unit? [Unknown]:
    Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct y/n [y]?
    Validity (in days, blank default): 365
    Alias (blank generated): localhost
    Enable SSL Mutual Authentication y/n (blank n): n
    
    SSL options:
    key store file: keystore.jks
    distinguished name: CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
    password: secret
    validity: 365
    alias: localhost
    Server keystore file keystore.jks, certificate file keystore.pem and keystore.csr file
    will be generated in server configuration directory.
    Do you confirm y/n :y

注記
  • コマンドを実行すると、管理 CLI がサーバーを再読み込みし、そのサーバーに再接続します。
  • disable-ssl-management コマンドを使用して、管理インターフェイスの一方向 SSL/TLS を無効にできます。

    security disable-ssl-management

    このコマンドでは、Elytron リソースは削除されません。SSL 設定に ApplicationRealm レガシーセキュリティーレルムを使用するようにシステムを設定します。

1.2.5.2. Elytron サブシステムのコマンドを使用した一方向 SSL/TLS の有効化

Elytron サブシステムでの管理インターフェイスに対する一方向 SSL/TLS の有効化

手順

  1. key-store を設定します。

    /subsystem=elytron/key-store=httpsKS:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
    注記

    上記のコマンドは、relative-to を使用してキーストアファイルの場所を参照します。または、path のキーストアにフルパスを指定することで、relative-to を省略できます。

    キーストアファイルが存在しない場合は、以下のコマンドを使用してサンプルキーペアを生成できます。

    /subsystem=elytron/key-store=httpsKS:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
    
    /subsystem=elytron/key-store=httpsKS:store()
  2. key-manager および server-ssl-context を作成します。

    /subsystem=elytron/key-manager=httpsKM:add(key-store=httpsKS,credential-reference={clear-text=secret})
    
    /subsystem=elytron/server-ssl-context=httpsSSC:add(key-manager=httpsKM,protocols=["TLSv1.2"])
    重要

    Elytron サブシステムはデフォルトで KeyManagerFactory.getDefaultAlgorithm() を使用してアルゴリズムを決定するため、Red Hat は前のコマンドでアルゴリズム属性を指定しませんでした。ただし、アルゴリズム属性は指定できます。アルゴリズム属性を指定するには、使用している JDK によるキーマネージャーアルゴリズムを知る必要があります。たとえば、SunJSSE を使用する JDK は、PKIX および SunX509 アルゴリズムを提供します。

    前のコマンドでは、SunX509 をキーマネージャーアルゴリズム属性として指定できます。

    また、使用する HTTPS プロトコルを決定する必要もあります。上記のコマンド例は TLSv1.2 を使用します。

    cipher-suite-filter を使用して暗号スイートを指定し、use-cipher-suites-order 引数を使用してサーバーの暗号スイートの順序を優先できます。use-cipher-suites-order 属性はデフォルトで true に設定されます。これは、レガシー security サブシステムの動作とは異なります。その動作は、デフォルトで、クライアント暗号スイートの順序を許可します。

  3. 管理インターフェイスで HTTPS を有効にします。

    /core-service=management/management-interface=http-interface:write-attribute(name=ssl-context, value=httpsSSC)
    
    /core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
  4. JBoss EAP インスタンスをリロードします。

    reload

一方向 SSL/TLS が管理インターフェイスに対して有効化されるようになりました。

重要

security-realmssl-context両方 が定義されている場合、JBoss EAP は ssl-context によって提供される SSL / TLS 設定を使用します。

1.2.5.3. 管理コンソールを使った一方向 SSL/TLS の有効化

管理コンソールで使用する管理インターフェイスに対して SSL を有効にするには、管理コンソールの SSL ウィザードを使用します。

手順

  1. 管理コンソールにアクセスします。詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。
  2. Runtime に移動して、該当するサーバー名をクリックします。
  3. サーバー名の横にある 表示 をクリックします。
  4. HTTP Manageme…​ をクリックし、HTTP Management Interface 設定ページを開きます。
  5. Enable SSL をクリックしてウィザードを起動します。

    このウィザードでは、以下のシナリオで、SSL を有効にする方法を順を追ってガイドします。

    • 証明書ストアを作成し、自己署名証明書を生成する。
    • Let's Encrypt 認証局から証明書を取得したい。
    • 証明書ストアはすでにファイルシステムにあるが、キーストアの設定がない。
    • 有効な証明書ストアを使用するキーストアの設定が存在する。

ウィザードを使用すると、任意で相互認証のトラストストアを作成できます。

1.2.6. Elytron サブシステムを使用した管理インターフェイスに対する双方向 SSL/TLS の有効化

JBoss EAP では、管理インターフェイスの双方向 SSL/TLS は、security コマンドまたは elytron サブシステムコマンドのいずれかを使用して有効にできます。

双方向 SSL/TLS を有効にするには、クライアント証明書を取得または生成する必要があります。クライアント証明書を生成するには、以下の手順で行います。

その後、以下のいずれかの方法で管理インターフェイスの双方向 SSL/TLS を有効にします。

1.2.6.1. クライアント証明書の生成

クライアント証明書は、CLI の keytool コマンドを使って生成できます。

手順

  1. クライアント証明書を作成します。

    $ keytool -genkeypair -alias client -keyalg RSA -keysize 1024 -validity 365 -keystore client.keystore.jks -dname "CN=client" -keypass secret -storepass secret
  2. クライアント証明書をエクスポートします。

    $ keytool -exportcert  -keystore client.keystore.jks -alias client -keypass secret -storepass secret -file /path/to/client.cer

1.2.6.2. セキュリティーコマンドによる双方向 SSL/TLS の有効化

security enable-ssl-management コマンドを使用すると、管理インターフェイスに双方向 SSL/TLS を有効にできます。

注記

以下の例では、信頼チェーンが存在しないので、証明書は検証されません。信頼された証明書を使用している場合、クライアントの証明書は問題なく検証できます。

前提条件

  • クライアントのキーストアを設定している。
  • サーバーのトラストストア用の証明書をエクスポートしている。

    詳しくは、クライアント証明書の生成 をご覧ください。

手順

  • CLI で security enable-ssl-management --interactive コマンドを入力します。

    security enable-ssl-management --interactive
    
    Please provide required pieces of information to enable SSL:
    Key-store file name (default management.keystore): server.keystore.jks
    Password (blank generated): secret
    What is your first and last name? [Unknown]: localhost
    What is the name of your organizational unit? [Unknown]:
    What is the name of your organization? [Unknown]:
    What is the name of your City or Locality? [Unknown]:
    What is the name of your State or Province? [Unknown]:
    What is the two-letter country code for this unit? [Unknown]:
    Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct y/n [y]?
    Validity (in days, blank default): 365
    Alias (blank generated): localhost
    Enable SSL Mutual Authentication y/n (blank n): y
    Client certificate (path to pem file): /path/to/client.cer
    Validate certificate y/n (blank y): n
    Trust-store file name (management.truststore): server.truststore.jks
    Password (blank generated): secret
    
    SSL options:
    key store file: server.keystore.jks
    distinguished name: CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
    password: secret
    validity: 365
    alias: localhost
    client certificate: /path/to/client.cer
    trust store file: server.trustore.jks
    trust store password: secret
    Server keystore file server.keystore.jks, certificate file server.pem and server.csr file will be generated in server configuration directory.
    Server truststore file server.trustore.jks will be generated in server configuration directory.
    Do you confirm y/n: y

    注記
    • コマンドを実行すると、管理 CLI がサーバーを再読み込みし、そのサーバーへの再接続を試みます。

      双方向 SSL/TLS 認証を完了するには、サーバーの証明書をクライアントトラストストアにインポートし、クライアント証明書を表示するようにクライアントを設定する必要があります。

    • disable-ssl-management コマンドを使用して、管理インターフェイスの双方向 SSL/TLS を無効にできます。

      security disable-ssl-management

      このコマンドでは、Elytron リソースは削除されません。SSL 設定に ApplicationRealm レガシーセキュリティーレルムを使用するようにシステムを設定します。

1.2.6.3. Elytron サブシステムのコマンドを使用した双方向 SSL/TLS の有効化

elytron サブシステムのコマンドを使用して、管理インターフェイスの双方向 SSL/TLS を有効にすることができます。

前提条件

手順

  1. キーストアを取得または生成します。

    JBoss EAP で一方向 SSL/TLS を有効にするには、使用する予定のキーストア、トラストストア、および証明書を取得または生成する必要があります。キーストア、トラストストア、および証明書の一連のサンプルを生成するには、以下のコマンドを使用します。

    1. key-store を設定します。

      /subsystem=elytron/key-store=twoWayKS:add(path=server.keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
      
      /subsystem=elytron/key-store=twoWayKS:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
      
      /subsystem=elytron/key-store=twoWayKS:store()
      注記

      上記のコマンドは、relative-to を使用してキーストアファイルの場所を参照します。または、path のキーストアにフルパスを指定することで、relative-to を省略できます。

    2. サーバー証明書をエクスポートします。

      /subsystem=elytron/key-store=twoWayKS:export-certificate(alias=localhost,path=/path/to/server.cer,pem=true)
    3. サーバートラストストアの key-store を作成し、クライアント証明書をサーバートラストストアにインポートします。

      注記

      以下の例では、信頼チェーンが存在しないので、証明書は検証されません。信頼された証明書を使用している場合、クライアントの証明書は問題なく検証できます。

      /subsystem=elytron/key-store=twoWayTS:add(path=server.truststore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
      
      /subsystem=elytron/key-store=twoWayTS:import-certificate(alias=client,path=/path/to/client.cer,credential-reference={clear-text=secret},trust-cacerts=true,validate=false)
      
      /subsystem=elytron/key-store=twoWayTS:store()
  2. サーバーキーストアおよびトラストストアの key-managertrust-manager、および server-ssl-context を設定します。

    /subsystem=elytron/key-manager=twoWayKM:add(key-store=twoWayKS,credential-reference={clear-text=secret})
    
    /subsystem=elytron/trust-manager=twoWayTM:add(key-store=twoWayTS)
    
    /subsystem=elytron/server-ssl-context=twoWaySSC:add(key-manager=twoWayKM,protocols=["TLSv1.2"],trust-manager=twoWayTM,want-client-auth=true,need-client-auth=true)
    重要

    Elytron サブシステムはデフォルトで KeyManagerFactory.getDefaultAlgorithm() および TrustManagerFactory.getDefaultAlgorithm() を使用してアルゴリズムを決定するため、Red Hat は前のコマンドでアルゴリズム属性を指定しませんでした。ただし、アルゴリズム属性は指定できます。アルゴリズム属性を指定するには、使用している JDK によるキーマネージャーアルゴリズムを知る必要があります。たとえば、SunJSSE を使用する JDK は、PKIX および SunX509 アルゴリズムを提供します。

    前のコマンドでは、SunX509 をキーマネージャーアルゴリズム属性として指定し、PKIX をトラストマネージャーアルゴリズム属性として指定できます。

    また、使用する HTTPS プロトコルを決定する必要もあります。上記のコマンド例は TLSv1.2 を使用します。

    cipher-suite-filter を使用して暗号スイートを指定し、use-cipher-suites-order 引数を使用してサーバーの暗号スイートの順序を優先できます。use-cipher-suites-order 属性はデフォルトで true に設定されます。これは、レガシー security サブシステムの動作とは異なります。その動作は、デフォルトで、クライアント暗号スイートの順序を許可します。

  3. 管理インターフェイスで HTTPS を有効にします。

    /core-service=management/management-interface=http-interface:write-attribute(name=ssl-context, value=twoWaySSC)
    
    /core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
  4. JBoss EAP インスタンスをリロードします。

    reload
    注記

    双方向 SSL/TLS 認証を完了するには、サーバーの証明書をクライアントトラストストアにインポートし、クライアント証明書を表示するようにクライアントを設定する必要があります。

  5. クライアント証明書を使用するようにクライアントを設定します。

    双方向 SSL / TLS 認証を完了するには、信頼されたクライアント証明書をサーバーに提示するようにクライアントを設定する必要があります。たとえば、ブラウザーを使用している場合は、信頼された証明書をブラウザーの信頼ストアにインポートする必要があります。

    これにより、サーバー管理への元の認証を変更せずに、双方向 SSL/TLS 認証を強制できます。

    元の認証方法を変更する場合は、JBoss EAP アイデンティティー管理の設定方法証明書による認証設定 を参照してください。

これで、双方向 SSL/TLS が管理インターフェイスに対して有効化されるようになります。

重要

security-realmssl-context両方 が定義されている場合、JBoss EAP は ssl-context によって提供される SSL / TLS 設定を使用します。

1.2.7. CLI セキュリティーコマンドを使用した管理インターフェイスの SASL 認証

CLI の security コマンドを使用して、管理インターフェイスの SASL 認証を有効または無効にすることができます。このコマンドを使用して、SASL メカニズムを並べ替えることもできます。

SASL 認証の有効化

JBoss EAP では、elytron SASL 認証ファクトリーを使用した SASL 認証は security enable-sasl-management コマンドで管理インターフェイスに対して有効にできます。このコマンドは、認証の設定に必要で存在しないリソースをすべて作成します。このコマンドはデフォルトで、含まれる SASL ファクトリーと http-interface を関連付けます。

例: SASL 認証の有効化

security enable-sasl-management

Server reloaded.
Command success.
Authentication configured for management http-interface
sasl authentication-factory=management-sasl-authentication
security-domain=ManagementDomain

注記

コマンドを実行すると、管理 CLI がサーバーを再読み込みし、そのサーバーに再接続します。

SASL ファクトリーがすでに存在する場合、ファクトリーは --mechanism 引数によって定義されたメカニズムを使用するように更新されます。

引数の一覧は、Authorization Security Arguments を参照してください。

SASL 認証の無効化

アクティブな SASL 認証ファクトリーを削除するには、以下のコマンドを使用します。

security disable-sasl-management

または、以下のコマンドを使用して、アクティブな SASL 認証ファクトリーから特定のメカニズムを削除できます。

security disable-sasl-management --mechanism=MECHANISM
SASL メカニズムの順序変更

定義された SASL メカニズムの順序により、サーバーがリクエストを認証する方法が決まり、最初に一致したメカニズムがクライアントに送信されます。

この順序を変更するには、以下のように、security reorder-sasl-management コマンドにコンマで区切ったものを渡します。

security reorder-sasl-management --mechanisms-order=MECHANISM1,MECHANISM2,...

1.2.8. CLI セキュリティーコマンドを使用した管理インターフェイスの HTTP 認証の有効化

CLI の security コマンドを使用して、管理インターフェイスの HTTP 認証を有効または無効にすることができます。

HTTP 認証の有効化

JBoss EAP では、elytron HTTP 認証ファクトリーを使用した HTTP 認証は security enable-http-auth-management コマンドで管理インターフェイスに対して有効にできます。このコマンドは、http-interface のみを対象とすることができます。追加の引数なしでは、含まれる HTTP 認証ファクトリーをがこのインターフェイスに関連付けられます。

例: HTTP 認証の有効化

security enable-http-auth-management

Server reloaded.
Command success.
Authentication configured for management http-interface
http authentication-factory=management-http-authentication
security-domain=ManagementDomain

注記

コマンドを実行すると、管理 CLI がサーバーを再読み込みし、そのサーバーに再接続します。

HTTP ファクトリーがすでに存在する場合、ファクトリーは --mechanism 引数によって定義されたメカニズムを使用するように更新されます。

引数の一覧は、Authorization Security Arguments を参照してください。

HTTP 認証の無効化

アクティブな HTTP 認証ファクトリーを削除するには、以下のコマンドを使用します。

security disable-http-auth-management

または、以下のコマンドを使用して、アクティブ HTTP 認証ファクトリーから特定のメカニズムを削除できます。

security disable-http-auth-management --mechanism=MECHANISM

1.2.9. レガシーのコア管理認証を使用した一方向 SSL/TLS の管理インターフェイスの設定

一方向 SSL/TLS のみを使用して通信を行うよう JBoss EAP 管理んたーフェースを設定すると、セキュリティーが強化されます。クライアントと管理インターフェイス間のネットワークトラフィックはすべて暗号化されるため、仲介者攻撃などのセキュリティー攻撃のリスクが軽減されます。

この手順では、JBoss EAP インスタンスとの暗号化されていない通信を無効にします。この手順は、スタンドアロンサーバーと管理対象ドメイン設定の両方に該当します。管理対象ドメインの場合は、管理 CLI コマンドにホスト名 (例: /host=master) を付けます。

重要

管理インターフェイスで一方向 SSL/TLS を有効にする手順を実行すると、明示的に指示しない限り、設定は再読み込みされません。これを実行すると、管理インターフェイスがロックされる可能性があります。

  1. キーストアを作成して、管理インターフェイスをセキュア化。

    詳細は、管理インターフェイスを保護するための鍵ストアの作成 を参照してください。

  2. 管理インターフェイスが HTTPS にバインドされようにする

    詳しくは、管理インターフェイスの HTTPS へのバインド を参照してください。

  3. オプション: カスタムの socket-binding-group を実装します。

    詳しくは カスタム socket-binding-group をご覧ください。

  4. 新しいセキュリティーレルムを作成します。

    詳しくは、新しいセキュリティーレルムの作成 をご覧ください。

  5. 新しいセキュリティーレルムを使用するように管理インターフェイスを設定します。

    詳細は、セキュリティーレルムを使用する管理インターフェイスの設定 を参照してください。

  6. キーストアを使用するように管理インターフェイスを設定します。

    詳しくは、キーストアを使用する管理インターフェイスの設定 をご覧ください。

  7. jboss-cli.xml を更新します。

    詳細は、jboss-cli.xml ファイル の更新を参照してください。

1.2.9.1. キーストアを作成してた管理インターフェイスのセキュア化

キーストアを作成して、管理インターフェイスのセキュリティーを確保します。

このキーストアは、管理インターフェイスが JCEKS 形式のキーストアと互換性がないため、JKS 形式である必要があります。

手順

  • 以下の CLI コマンドでキーストアを作成します。

    パラメーター (aliaskeypasskeystorestorepassdname など) の値の例を、環境に合わせて正しい値に置き換えてください。

    $ keytool -genkeypair -alias appserver -storetype jks -keyalg RSA -keysize 2048 -keypass password1 -keystore EAP_HOME/standalone/configuration/identity.jks -storepass password1 -dname "CN=appserver,OU=Sales,O=Systems Inc,L=Raleigh,ST=NC,C=US" -validity 730 -v
注記

パラメーターの validity は、キーが有効な日数を指定します。730 の値は 2 年と等しくなります。

1.2.9.2. 管理インターフェイスが HTTPS にバインドされようにする

管理インターフェイスが HTTPS にバインドするように JBoss EAP を設定します。

手順

  • スタンドアロンサーバーを運用する場合の設定

    管理インターフェイスが HTTPS にバインドされるようにするには、management-https 設定を追加し、management-http 設定を削除する必要があります。

    以下の CLI コマンドを使用して管理インターフェイスを HTTPS にバインドします。

    /core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
    
    /core-service=management/management-interface=http-interface:undefine-attribute(name=socket-binding)
  • 管理ドメイン実行時の設定

    secure-port を追加し、ポート設定を削除して、management-interface 属性内のソケット要素を変更します。

    以下のコマンドを使用して管理インターフェイスを HTTPS にバインドします。

    /host=master/core-service=management/management-interface=http-interface:write-attribute(name=secure-port,value=9993)
    
    /host=master/core-service=management/management-interface=http-interface:undefine-attribute(name=port)

1.2.9.3. カスタムの socket-binding-group

カスタムの socket-binding-group を使用する場合は、management-https バインディングが定義されていることを確認する必要があります。デフォルトではポート 9993 にバインドされます。これは、サーバーの設定ファイルの socket-binding-group 属性から確認したり、管理 CLI を使用して確認できます。

/socket-binding-group=standard-sockets/socket-binding=management-https:read-resource(recursive=true)

{
    "outcome" => "success",
    "result" => {
        "client-mappings" => undefined,
        "fixed-port" => false,
        "interface" => "management",
        "multicast-address" => undefined,
        "multicast-port" => undefined,
        "name" => "management-https",
        "port" => expression "${jboss.management.https.port:9993}"
    }
}

1.2.9.4. 新しいセキュリティーレルムの作成

新しいセキュリティーレルムを作成します。

この手順では、HTTPS の ManagementRealmHTTPS を使用する新しいセキュリティーレリムは、EAP_HOME/standalone/configuration/ ディレクトリーに位置する https-mgmt-users.properties というプロパティーファイルを使用します。

手順

  1. ユーザー名とパスワードを格納するプロパティーファイルを作成します。

    ユーザー名とパスワードは後でファイルに追加できます。ただし、現在は、https-mgmt-users.properties という名前で空のファイルを作成し、その場所に保存する必要があります。以下の例は、touch コマンドの使用を示しています。しかし、テキストエディターなどの他のメカニズムを使用することもできます。

    例: touch コマンドを使用した空のファイルの作成

    $ touch EAP_HOME/standalone/configuration/https-mgmt-users.properties

  2. 次に、以下の管理 CLI コマンドを使用して ManagementRealmHTTPS という名前の新規セキュリティーレルムを作成します。

    /core-service=management/security-realm=ManagementRealmHTTPS:add
    
    /core-service=management/security-realm=ManagementRealmHTTPS/authentication=properties:add(path=https-mgmt-users.properties,relative-to=jboss.server.config.dir)
  3. プロパティーファイルにユーザーを追加します。

    これで、新しいセキュリティーレルムを作成し、認証用にプロパティーファイルを使用するよう設定しました。EAP_HOME/bin/ ディレクトリーの add-user スクリプトを使用して、このプロパティーファイルにユーザーを追加する必要があります。add-user スクリプトを実行する際には、-up-r オプションをそれぞれ使用してプロパティーファイルとセキュリティーレルムの両方を指定する必要があります。そこから、add-user スクリプトは、https-mgmt-users.properties ファイルに保存するためのユーザー名とパスワードの情報を対話的に要求します。

    $ EAP_HOME/bin/add-user.sh -up EAP_HOME/standalone/configuration/https-mgmt-users.properties -r ManagementRealmHTTPS
    ...
    Enter the details of the new user to add.
    Using realm 'ManagementRealmHTTPS' as specified on the command line.
    ...
    Username : httpUser
    Password requirements are listed below. To modify these restrictions edit the add-user.properties configuration file.
     - The password must not be one of the following restricted values {root, admin, administrator}
     - The password must contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
     - The password must be different from the username
    ...
    Password :
    Re-enter Password :
    About to add user 'httpUser' for realm 'ManagementRealmHTTPS'
    ...
    Is this correct yes/no? yes
    ..
    Added user 'httpUser' to file 'EAP_HOME/configuration/https-mgmt-users.properties'
    ...
    Is this new user going to be used for one AS process to connect to another AS process?
    e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
    yes/no? no
    重要

    プロパティーファイルを使用してユーザー名とパスワードを保存するようにセキュリティーレルムを設定する場合、各レリムは別のレルムと共有されていない個別のプロパティーを使用することが推奨されます。

1.2.9.5. セキュリティーレルムを使用する管理インターフェイスの設定

管理インターフェイスがセキュリティーレルムを使用するように設定するには、管理 CLI コマンドを使用します。

手順

  • 次の管理 CLI コマンドを実行します。

    /core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=ManagementRealmHTTPS)

1.2.9.6. キーストアを使用する管理インターフェイスの設定

管理用 CLI コマンドを使用して、キーストアを使用するように管理インターフェイスを設定します。

手順

  1. 以下の管理 CLI コマンドを使用して、キーストアを使用するように管理インターフェイスを設定します。

    パラメーターファイルでは、パスワードとエイリアスの値を、管理インターフェイスをセキュア化するためのキーストアの作成 手順からコピーする必要があります。

    /core-service=management/security-realm=ManagementRealmHTTPS/server-identity=ssl:add(keystore-path=identity.jks,keystore-relative-to=jboss.server.config.dir,keystore-password=password1, alias=appserver)
    注記

    キーストアのパスワードを更新するには、以下の CLI コマンドを使用します。

    /core-service=management/security-realm=ManagementRealmHTTPS/server-identity=ssl:write-attribute(name=keystore-password,value=newpassword)
  2. サーバーの設定を再読み込みします。

    reload

    サーバー設定のリロード後には、起動したサービスの数を示すテキストの直前に以下の内容がログに含まれるはずです。

    13:50:54,160 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0061: Http management interface listening on https://127.0.0.1:9993/management
    13:50:54,162 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0052: Admin console listening on https://127.0.0.1:9993

これで、管理インターフェイスはポート 9993 をリッスンするようになります。これにより、手順が成功したことを確認できました。

重要

このとき、CLI は接続を切断し、ポートバインディングが変更されたため再接続できなくなります。

次のステップ に進み、jboss-cli.xml ファイルを更新して、管理 CLI が再接続できるようにします。

1.2.9.7. jboss-cli.xml ファイルの更新

管理 CLI を使用して管理アクションを実行する場合は、EAP_HOME/bin/jboss-cli.xml ファイルを更新する必要があります。

手順

  • EAP_HOME/bin/jboss-cli.xml ファイルを以下のように更新します。

    • <default-protocol> の値を https-remoting に更新します。
    • <default-controller> において、<protocol> の値を https-remoting に更新します。
    • <default-controller> で、<port> の値を 9993 に更新します。

    例: jboss-cli.xml

    <jboss-cli xmlns="urn:jboss:cli:2.0">
        <default-protocol use-legacy-override="true">https-remoting</default-protocol>
        <!-- The default controller to connect to when 'connect' command is executed w/o arguments -->
        <default-controller>
            <protocol>https-remoting</protocol>
            <host>localhost</host>
            <port>9993</port>
        </default-controller>
    ...

次回、管理 CLI を使用して管理インターフェイスに接続する場合は、サーバー証明書を受け入れ、ManagementRealmHTTPS セキュリティーレルムに対して認証を行う必要があります。

例: サーバー証明書の許可および認証

$ ./jboss-cli.sh -c
Unable to connect due to unrecognised server certificate
Subject    - CN=appserver,OU=Sales,O=Systems Inc,L=Raleigh,ST=NC,C=US
Issuer     - CN=appserver, OU=Sales, O=Systems Inc, L=Raleigh, ST=NC, C=US
Valid From - Tue Jun 28 13:38:48 CDT 2016
Valid To   - Thu Jun 28 13:38:48 CDT 2018
MD5 : 76:f4:81:8b:7e:c3:be:6d:ee:63:c1:7a:b7:b8:f0:fb
SHA1 : ea:e3:f1:eb:53:90:69:d0:c9:69:4a:5a:a3:20:8f:76:c1:e6:66:b6

Accept certificate? [N]o, [T]emporarily, [P]ermenantly : p
Authenticating against security realm: ManagementRealmHTTPS
Username: httpUser
Password:
[standalone@localhost:9993 /]

重要

security-realmssl-context両方 が定義されている場合、JBoss EAP は ssl-context によって提供される SSL / TLS 設定を使用します。

1.2.10. レガシーコア管理認証のある管理インターフェイスに双方向 SSL/TLS を設定する

クライアント認証 とも呼ばれる双方向 SSL/TLS 認証は、SSL/TLS 証明書を使用してクライアントとサーバーの両方を認証します。これは、クライアントとサーバーの両方に証明書があるという点で、一方向 SSL / TLS の管理インターフェイスの設定 とは異なります。そのため、サーバーの伝えるアイデンティティーだけでなく、クライアントの伝えるアイデンティティーも信頼できます。

本セクションでは、以下の規則を使用します。

HOST1
JBoss サーバーのホスト名。例: jboss.redhat.com.
HOST2
クライアントに適した名前。例: myclientこれは必ずしも実際のホスト名ではないことに注意してください。
CA_HOST1
HOST1 証明書に使用する DN (識別名) です。たとえば、cn=jboss,dc=redhat,dc=com となります。
CA_HOST2
HOST2 証明書に使用する DN (識別名) です。例: cn=myclient,dc=redhat,dc=com
注記

キーストアおよびトラストストアパスワードの保存にパスワード vault が使用された場合 (推奨)、パスワード vault はすでに作成されるはずです。パスワード vault の詳細は、Red Hat JBoss Enterprise Application Platform 7セキュリティーアーキテクチャーパスワード Vaultパスワード Vault システム を参照してください。

警告

Red Hat では、影響するすべてのパッケージで TLSv1.1 または TLSv1.2 を利用するために SSLv2、SSLv3、および TLSv1.0 を明示的に無効化することを推奨しています。

手順

  1. キーストアを生成します。

    $ keytool -genkeypair -alias HOST1_alias -keyalg RSA -keysize 1024 -validity 365 -keystore HOST1.keystore.jks -dname "CA_HOST1" -keypass secret -storepass secret
    
    $ keytool -genkeypair -alias HOST2_alias -keyalg RSA -keysize 1024 -validity 365 -keystore HOST2.keystore.jks -dname "CA_HOST2" -keypass secret -storepass secret
  2. 証明書をエクスポートします。

    $ keytool -exportcert  -keystore HOST1.keystore.jks -alias HOST1_alias -keypass secret -storepass secret -file HOST1.cer
    
    $ keytool -exportcert  -keystore HOST2.keystore.jks -alias HOST2_alias -keypass secret -storepass secret -file HOST2.cer
  3. 対立するトラストストアにインポートします。

    $ keytool -importcert -keystore HOST1.truststore.jks -storepass secret -alias HOST2_alias -trustcacerts -file HOST2.cer
    
    $ keytool -importcert -keystore HOST2.truststore.jks -storepass secret -alias HOST1_alias -trustcacerts -file HOST1.cer
  4. CertificateRealm を定義します。

    サーバー (host.xml または standalone.xml) の設定で CertificateRealm を定義し、その先となるインターフェイスを指定します。これは、以下のコマンドで実行できます。

    /core-service=management/security-realm=CertificateRealm:add()
    
    /core-service=management/security-realm=CertificateRealm/server-identity=ssl:add(keystore-path=/path/to/HOST1.keystore.jks, keystore-password=secret,alias=HOST1_alias)
    
    /core-service=management/security-realm=CertificateRealm/authentication=truststore:add(keystore-path=/path/to/HOST1.truststore.jks,keystore-password=secret)
  5. http-interfacesecurity-realm を新しい CertificateRealm に変更します。

    /core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=CertificateRealm)
  6. CLI の SSL/TLS 設定を追加します。

    重要

    双方向 SSL/TLS の追加に加え、管理インターフェイスも HTTPS にバインドされるように設定してください。詳細は、レガシーのコア管理認証を使用した一方向 SSL/TLS の管理インターフェイスの設定 管理インターフェイスが HTTPS にバインドされようにする を参照してください。

    EAP_HOME/bin/jboss-cli.xml を設定ファイルとして使用する CLI の SSL/TLS 設定を追加します。

    キーストアとトラストストアパスワードをプレーンテキストに保存するには、EAP_HOME/bin/jboss-cli.xml を編集し、変数に適切な値を使用して SSL/TLS 設定を追加します。

    例: プレーンテキストの jboss-cli.xml キーストアおよびトラストストアのパスワード

    <ssl>
      <alias>HOST2_alias</alias>
      <key-store>/path/to/HOST2.keystore.jks</key-store>
      <key-store-password>secret</key-store-password>
      <trust-store>/path/to/HOST2.truststore.jks</trust-store>
      <trust-store-password>secret</trust-store-password>
      <modify-trust-store>true</modify-trust-store>
    </ssl>

    パスワード vault に保存されているキーストアおよびトラストストアパスワードを使用するには、vault 設定および適切な vault の値を EAP_HOME/bin/jboss-cli.xml に追加する必要があります。

    例: パスワード vault の jboss-cli.xml キーストアおよびトラストストアのパスワード

    <ssl>
      <vault>
        <vault-option name="KEYSTORE_URL" value="path-to/vault/vault.keystore"/>
        <vault-option name="KEYSTORE_PASSWORD" value="MASK-5WNXs8oEbrs"/>
        <vault-option name="KEYSTORE_ALIAS" value="vault"/>
        <vault-option name="SALT" value="12345678"/>
        <vault-option name="ITERATION_COUNT" value="50"/>
        <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/>
      </vault>
      <alias>HOST2_alias</alias>
      <key-store>/path/to/HOST2.keystore.jks</key-store>
      <key-store-password>VAULT::VB::cli_pass::1</key-store-password>
      <key-password>VAULT::VB::cli_pass::1</key-password>
      <trust-store>/path/to/HOST2.truststore.jks</trust-store>
      <trust-store-password>VAULT::VB::cli_pass::1</trust-store-password>
      <modify-trust-store>true</modify-trust-store>
    </ssl>

重要

security-realmssl-context両方 が定義されている場合、JBoss EAP は ssl-context によって提供される SSL / TLS 設定を使用します。

1.2.11. HTTPS リスナーのリファレンス

HTTPS リスナーで使用できる属性の完全リストは、JBoss EAP設定ガイドUndertow Subsystem Attributes を参照してください。

1.2.11.1. 暗号化スイートについて

許可される一連の暗号を設定できます。JSSE 構文については、コンマ区切りのリストが必要です。OpenSSL 構文については、コロン区切のリストが必要です。1 つのみの構文を使うようにしてください。デフォルトは JVM のデフォルトです。

重要

強度の低い暗号を使用すると、セキュリティーが重大なリスクにさらされることになります。暗号スイートの NIST 推奨は NIST ガイドライン を参照してください。

利用可能な OpenSSL 暗号の一覧 は、OpenSSL ドキュメントを参照してください。以下はサポート対象外であることに注意してください。

  • @SECLEVEL
  • SUITEB128
  • SUITEB128ONLY
  • SUITEB192

標準 JSSE 暗号のリスト は、Java のドキュメントを参照してください。

有効な暗号スイートのリストを更新するには、undertow サブシステムの HTTPS リスナーの enabled-cipher-suites 属性を使用します。

例: 有効化された暗号化スイート一覧を更新する管理 CLI コマンド

/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enabled-cipher-suites,value="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA")

注記

この例では、2 つの暗号だけが一覧表示されますが、実際の例はより多くの暗号が使用されます。

1.2.12. Open SSL プロバイダーで TLS 1.3 プロトコルのサポートを可能にする

ssl-context 設定で cipher-suite-names 属性を設定して、TLS の OpenSSL プロバイダーで TLS 1.3 プロトコルのサポートを有効にできます。JBoss EAP が Open SSL TLS プロバイダーを使用するように設定するには、次のいずれかの方法を選択します。

  • Elytron サブシステムがデフォルトで Open SSL TLS プロバイダーを使用するように設定します。
  • server-ssl-context コンポーネントまたは client-ssl-context コンポーネントの providers 属性を設定して、Open SSL TLS プロバイダーを使用します。
重要

TLS 1.3 を JDK 11 で実行時のパフォーマンスは、TLS 1.2 と比較すると、低下する可能性があります。これは、クライアントがサーバーに対して非常に多くの TLS 1.3 要求を行った場合に発生する可能性があります。新しい JDK バージョンにアップグレードさせることで、パフォーマンスを向上できます。実稼働環境で有効にする前に、TLS 1.3 を使用する設定で、パフォーマンス低下がないかをテストします。

前提条件

  • アプリケーションに対して、一方向の SSL/TLS または双方向の SSL/TLS を有効にしておく。

手順

  1. 次のいずれかの方法を選択して、JBoss EAP 7.4 インスタンスが Open SSL TLS プロバイダーを使用するように設定します。

    1. elytron サブシステムがデフォルトで Open SSL TLS プロバイダーを使用するように設定します。これには、デフォルトの final-providers 設定 (この設定ではグローバルにプロバイダーをすべて登録し終えてから Open SSL TLS プロバイダーが登録される) を削除します。

      /subsystem=elytron:undefine-attribute(name=final-providers)
      reload

      次に、グローバルに登録する全プロバイダーの前に、Open SSL TLS プロバイダーを優先的に登録します。

      /subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers)
    2. server-ssl-context または client-ssl-contextproviders 属性を設定して、Open SSL TLS プロバイダーを使用します。

      server SSC という既存の server-ssl-contextprovider 属性を設定する例です。

      /subsystem=elytron/server-ssl-context=serverSSC:write-attribute(name=providers,value=openssl)
      reload

  2. オプション: TLS 1.3 プロトコル以外のプロトコルを使用するように ssl-context を設定した場合は、ssl-contextprotocols 属性に TLS 1.3 プロトコルを含めるように設定する必要があります。

    /subsystem=elytron/server-ssl-context=serverSSC:write-attribute(name=protocols,value=[TLSv1.3])
  3. ssl-context 設定で cipher-suite-names 属性を設定して、OpenSSL プロバイダーで TLS 1.3 プロトコルのサポートを有効にできます。次の例では、cipher-suit-names 属性の値として、TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 を設定しています。

    /subsystem=elytron/server-ssl-context=serverSSC:write-attribute(name=cipher-suite-names,value=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256)
  4. JBoss EAP インスタンスをリロードします。

    reload
  5. オプション: TLS 1.3 プロトコルと TLS 1.3 サイファースイートを使用して、サーバーとの SSL 暗号化接続を正常に確立できるかどうかをテストします。curl などのツールを使って、設定の出力を確認します。

    curl -v https://<ip_address>:<ssl_port>

    TLS_AES_256_GCM_SHA384 が TLS 1.3 プロトコルで SSL 接続を保護していることを示す出力例です。

    SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
    * ALPN, server accepted to use h2
    * Server certificate:
    *  subject: C=Unknown; ST=Unknown; L=Unknown; O=Unknown; OU=Unknown; CN=localhost
    *  start date: Oct  6 14:58:16 2020 GMT
    *  expire date: Nov  5 15:58:16 2020 GMT
    *  issuer: C=Unknown; ST=Unknown; L=Unknown; O=Unknown; OU=Unknown; CN=localhost
    *  SSL certificate verify result: self signed certificate (18), continuing anyway.

関連情報

1.2.13. FIPS 140-2 準拠暗号化

以下の方法のいずれかを使用することで、Red Hat Enterprise Linux で FIPS 140-2 に準拠する暗号を設定できます。

1.2.13.1. Red Hat Enterprise Linux 7 以降での SSL/TLS の FIPS 140-2 暗号化の有効化。

Undertow は、SSL/TLS に FIPS 140-2 準拠の暗号を使用するように設定できます。この設定例の範囲は、FIPS モードで Mozilla NSS ライブラリーを使用する Red Hat Enterprise Linux 7 以降に限定されます。

重要

インストール済みの Red Hat Enterprise Linux は、FIPS 140-2 に準拠するように既に設定されています。詳細は、Red Hat カスタマーポータルにある How can I make RHEL 6 or RHEL 7 FIPS 140-2 compliant? を参照してください。

警告

FIPS モードで JBoss EAP を実行するとき TLS 1.2 プロトコルを使用すると、NoSuchAlgorithmException が発生する可能性があります。この問題の詳細は、Red Hat カスタマーポータルにある NoSuchAlgorithmException: no such algorithm: SunTls12MasterSecret のソリューションを参照してください。

そのため、HTTP/2 には TLS 1.2 プロトコルが必要なため、HTTP/2 を FIPS モードで設定することはできません。FIPS モード (PKCS11) は TLS 1 および TLS 1.1 プロトコルをサポートしているため、以下を使用できます。

  • Oracle/OpenJDK の TLS 1.1
  • IBM java の TLS 1

SSL/TLS に FIPS 140-2 に準拠する暗号を使用するように Undertow を設定するには、以下を行う必要があります。

注記

OpenSSL プロバイダーにはプライベートキーが必要ですが、PKCS11 ストアから秘密鍵を取得することはできません。FIPS は、FIPS 準拠の暗号化モジュールからの暗号化されていない鍵のエクスポートを許可しません。そのため、elytron サブシステムとレガシーのセキュリティーの両方では、FIPS モードで TLS の OpenSSL プロバイダーを使用することはできません。

NSS データベースの設定
  1. NSS データベースを格納するために、適切なユーザーが所有するディレクトリーを作成します。

    NSS データベースディレクトリーを作成するコマンドの例

    $ mkdir -p /usr/share/jboss-as/nssdb
    $ chown jboss /usr/share/jboss-as/nssdb
    $ modutil -create -dbdir /usr/share/jboss-as/nssdb

    注記
    • RHEL7 以前のデフォルトのデータベース形式である DBM ファイル形式は廃止されました。NSS は、デフォルトで SQL を使用するようになりました
    • jboss ユーザーはあくまで例です。これは、オペレーティングシステムで、JBoss EAP を実行できる、アクティブなユーザーに置き換えてください。
  2. NSS 設定ファイル (/usr/share/jboss-as/nss_pkcsll_fips.cfg) を作成します。

    以下を指定する必要があります。

    • 名前
    • NSS ライブラリーが置かれているディレクトリー
    • 以前のステップで NSS データベースが作成されたディレクトリー

      例: nss_pkcsll_fips.cfg

      name = nss-fips
      nssLibraryDirectory=/usr/lib64
      nssSecmodDirectory=/usr/share/jboss-as/nssdb
      nssDbMode = readOnly
      nssModule = fips

      注記

      64 ビットバージョンの Red Hat Enterprise Linux 6 使っていない場合は、nssLibraryDirectory/usr/lib64 ではなく、/usr/lib に置き換えます。

  3. Java セキュリティー設定ファイルを編集します。この設定ファイルは JVM 全体に影響しますが、以下のいずれかの手段で定義できます。

    • デフォルトの設定ファイル java.security は JDK で入手できます。このファイルは、他のセキュリティー設定ファイルが指定されていない場合に使用されます。このファイルの場所は、JDK ベンダーのドキュメントを参照してください。
    • カスタムの Java セキュリティー設定ファイルを定義し、-Djava.security.properties=/path/to/java.security.properties を使用して参照します。この方法で参照されると、デフォルトのセキュリティーファイルの設定が上書きされます。このオプションは、異なるセキュリティー設定を必要とする同じホストで複数の JVM を実行している場合に便利です。

      以下の行を Java セキュリティー設定ファイルに追加します。

      例: java.security

      security.provider.1=sun.security.pkcs11.SunPKCS11 /usr/share/jboss-as/nss_pkcsll_fips.cfg

      注記

      上記の行で指定されている nss_pkcsll_fips.cfg 設定ファイルは、前のステップで作成したファイルです。

      以下のリンクを設定ファイルから更新する必要があります。

      security.provider.5=com.sun.net.ssl.internal.ssl.Provider

      上記を以下に変更します。

      security.provider.5=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-nss-fips
      重要

      このファイルの他の security.provider.X 行 (例: security.provider.2) には、このプロバイダーに優先順位が指定されるように X の値を増やす必要があります。

  4. 前の手順で作成した NSS データベースディレクトリーで modutil コマンドを実行して、FIPS モードを有効化します。

    modutil -fips true -dbdir /usr/share/jboss-as/nssdb
    注記

    この時点では、NSS 共有オブジェクトの一部に対するライブラリー署名の再生成を求めるセキュリティーライブラリーエラーが発生することがあります。

  5. FIPS トークンにパスワードを設定します。

    トークンの名前は、NSS FIPS 140-2 Certificate DB である 必要があります

    modutil -changepw "NSS FIPS 140-2 Certificate DB" -dbdir /usr/share/jboss-as/nssdb
    重要

    FIPS トークンに使用されるパスワードは、FIPS に準拠したパスワードである必要があります。パスワードの強度が不十分な場合は、以下のようなエラーが発生することがあります。ERROR: Unable to change password on token "NSS FIPS 140-2 Certificate DB"

  6. NSS ツールを使用して証明書を作成します。

    コマンド例

    $ certutil -S -k rsa -n undertow -t "u,u,u" -x -s "CN=localhost, OU=MYOU, O=MYORG, L=MYCITY, ST=MYSTATE, C=MY" -d /usr/share/jboss-as/nssdb

  7. 以下のコマンドを実行することで、JVM が PKCS11 キーストアから秘密鍵を読み取りできることを確認します。

    $ keytool -list -storetype pkcs11
重要

FIPS を有効にすると、JBoss EAP の起動時に以下のエラーが発生することがあります。

10:16:13,993 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.server.controller.management.security_realm.ApplicationRealm.key-manager: org.jboss.msc.service.StartException in service jboss.server.controller.management.security_realm.ApplicationRealm.key-manager: WFLYDM0018: Unable to start service
	at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:85)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.security.KeyStoreException: FIPS mode: KeyStore must be from provider SunPKCS11-nss-fips
	at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:67)
	at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
	at org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(AbstractKeyManagerService.java:130)
	at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:83)
	... 5 more

FIPS 140-2 準拠の暗号を使用しないレガシーコア管理認証にデフォルトのキーマネージャーなどの既存のキーマネージャーが設定されている場合は、このメッセジーが表示されます。

SSL/TLS への FIPS 140-2 対応暗号の管理 CLI の設定

SSL/TLS 対応の FIPS 140-2 準拠暗号化が有効な環境で動作するように、JBoss EAP 管理 CLI を設定する必要があります。デフォルトでは、このような環境で管理 CLI を使用しようとすると、次の例外が表示されます。org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used

  • 従来の security サブシステムを使用している場合:

    以下のように、jboss-cli.sh ファイルの javax.net.ssl.keyStore および javax.net.ssl.trustStore システムプロパティーを更新します。

    JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11"
    JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=P@ssword123"
  • elytron サブシステムを使用している場合は、以下の手順に従います。

    1. 以下の内容を含む管理 CLI の XML 設定ファイルを作成します。

      例: cli-wildfly-config.xml

      <configuration>
        <authentication-client xmlns="urn:elytron:client:1.2">
          <key-stores>
            <key-store name="truststore" type="PKCS11">
              <key-store-clear-password password="P@ssword123"/>
            </key-store>
          </key-stores>
          <ssl-contexts>
            <ssl-context name="client-cli-context">
              <trust-store key-store-name="truststore"/>
              <cipher-suite selector="${cipher.suite.filter}"/>
              <protocol names="TLSv1.1"/>
            </ssl-context>
          </ssl-contexts>
          <ssl-context-rules>
            <rule use-ssl-context="client-cli-context"/>
          </ssl-context-rules>
        </authentication-client>
      </configuration>

      注記

      IBM JDK を使用している場合は、必要な設定を行うための IBM 管理 CLI 設定の例 を参照してください。

    2. 管理 CLI の起動時に、-Dwildfly.config.url プロパティーを使用して管理 CLI スクリプトに設定ファイルを渡します。以下に例を示します。

      $ jboss-cli.sh -Dwildfly.config.url=cli-wildfly-config.xml
Elytron および Undertow サブシステムの設定
  1. FIPS 140-2 準拠暗号化 key-storekey-managerssl-context を追加します。

    /subsystem=elytron/key-store=fipsKS:add(type=PKCS11,provider-name="SunPKCS11-nss-fips",credential-reference={clear-text="P@ssword123"})
    
    /subsystem=elytron/key-manager=fipsKM:add(key-store=fipsKS,algorithm="SunX509",provider-name=SunPKCS11-nss-fips,credential-reference={clear-text="P@ssword123"})
    
    /subsystem=elytron/server-ssl-context=fipsSSC:add(key-manager=fipsKM,protocols=["TLSv1.1"])
  2. undertow サブシステムを更新して、新しい ssl-context を使用します。

    注記

    https-listener には、常に security-realm または ssl-context が設定されている必要があります。2 つの設定間で変更する場合は、以下に示すように、コマンドを単一のバッチで実行する必要があります。

    batch
    /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
    /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=fipsSSC)
    run-batch
    
    reload

FIPS モードの elytron サブシステムでは、FIPS モードの OpenJDK および Oracle JDK により、カスタム KeyManager または TrustManager 実装に基づいた高度な機能の使用が制限されます。以下の設定属性はサーバー上では機能しません。

  • server-ssl-context.security-domain
  • trust-manager.certificate-revocation-list
従来のコア管理認証を使用した Undertow の設定

必要に応じて、elytron サブシステムの代わりに従来のコア管理認証を使用して、SSL/TLS の FIPS 140-2 準拠暗号化の設定を完了できます。

  1. SSL/TLS を使用するように Undertow を設定します。

    注記

    以下のコマンドはバッチモードで実行する必要があります。あるいは、ssl サーバーアイデンティティーを追加した後にサーバーをリロードする必要があります。以下の例はバッチモードを使用しています。

    batch
    
    /core-service=management/security-realm=HTTPSRealm:add
    
    /core-service=management/security-realm=HTTPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="strongP@ssword1")
    
    /subsystem=undertow/server=default-server/https-listener=https:add(socket-binding=https, security-realm=HTTPSRealm, enabled-protocols="TLSv1.1")
    
    run-batch

    Undertow を SSL / TLS に設定する基本的な詳細は、Setting up an SSL/TLS for Applications で説明されています。

  2. Undertow によって使用される暗号スイートを設定します。

    SSL/TLS を設定した後は、特定のセットの暗号スイートを有効にするために https リスナーとセキュリティーレルムを設定する必要があります。

    必要な暗号スイート

    SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_AES_256_CBC_SHA

    https リスナーに暗号スイートを有効にする基本的な方法は、暗号スイートについて で説明されています。https リスナーで暗号化スイートを有効にするには、以下を行います。

    HTTPS リスナーでの暗号スイートを有効にするコマンドの例

    /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enabled-cipher-suites,value="SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_anon_WITH_AES_128_CBC_SHA,TLS_ECDH_anon_WITH_AES_256_CBC_SHA")

  3. セキュリティーレルムで暗号スイートを有効にします。

    セキュリティーレルムで暗号スイートを有効化するコマンドの例

    /core-service=management/security-realm=HTTPSRealm/server-identity=ssl:write-attribute(name=enabled-cipher-suites, value=[SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_AES_256_CBC_SHA])

1.2.13.2. Bouncy Castle を使用した SSL/TLS の FIPS 140-2 暗号化の有効化

Undertow は、SSL/TLS に FIPS 140-2 準拠の暗号を使用するように設定できます。この設定例の範囲は、Red Hat Enterprise Linux 7 以降に限定されます。Bouncy Castle JAR は Red Hat によって提供されていないため、Bouncy Castle から直接取得する必要があります。

前提条件
SSL/TLS への FIPS 140-2 対応暗号の管理 CLI の設定

SSL/TLS 対応の FIPS 140-2 準拠暗号化が有効な環境で動作するように、JBoss EAP 管理 CLI を設定する必要があります。

  1. 以下の内容を含む管理 CLI の XML 設定ファイルを作成します。

    例: cli-wildfly-config.xml

    <configuration>
      <authentication-client xmlns="urn:elytron:client:1.2">
        <key-stores>
          <key-store name="truststore" type="BCFKS">
            <file name="${truststore.location}" />
            <key-store-clear-password password="${password}" />
          </key-store>
          <key-store name="keystore" type="BCFKS">
            <file name="${keystore.location}" />
            <key-store-clear-password password="${password}" />
          </key-store>
        </key-stores>
        <ssl-contexts>
          <ssl-context name="client-cli-context">
            <key-store-ssl-certificate algorithm="PKIX" key-store-name="keystore">
              <key-store-clear-password password="${password"} />
            </key-store-ssl-certificate>
            <trust-store key-store-name="truststore"/>
            <trust-manager algorithm="PKIX">
            </trust-manager>
            <cipher-suite selector="TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CCM,TLS_RSA_WITH_AES_128_CCM"/>
            <protocol names="TLSv1.2"/>
          </ssl-context>
        </ssl-contexts>
        <ssl-context-rules>
          <rule use-ssl-context="client-cli-context"/>
        </ssl-context-rules>
      </authentication-client>
    </configuration>

  2. 管理 CLI の起動時に、-Dwildfly.config.url プロパティーを使用して管理 CLI スクリプトに設定ファイルを渡します。以下に例を示します。

    $ jboss-cli.sh -Dwildfly.config.url=cli-wildfly-config.xml
Elytron および Undertow サブシステムの設定
  1. FIPS 140-2 準拠暗号化 key-storekey-managerssl-context を追加します。キーストアを定義した場合は、そのタイプは BCFKS である必要があります。

    /subsystem=elytron/key-store=fipsKS:add(path=KEYSTORE,relative-to=jboss.server.config.dir,credential-reference={clear-text=STORE_PASSWORD},type="BCFKS")
    
    /subsystem=elytron/key-manager=fipsKM:add(key-store=fipsKS,algorithm="PKIX",credential-reference={clear-text=PASSWORD})
    
    /subsystem=elytron/server-ssl-context=fipsSSC:add(key-manager=fipsKM,protocols=["TLSv1.2"],cipher-suite-filter="TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CCM,TLS_RSA_WITH_AES_128_CCM")
  2. undertow サブシステムを更新して、新しい ssl-context を使用します。

    注記

    https-listener には、常に security-realm または ssl-context が設定されている必要があります。2 つの設定間で変更する場合は、以下に示すように、コマンドを単一のバッチで実行する必要があります。

    batch
    /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
    /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=fipsSSC)
    run-batch
    
    reload

1.2.14. IBM JDK における FIPS 140-2 準拠暗号化

IBM JDK では、マルチプラットフォーム用の IBM Java Cryptographic Extension (JCE) IBMJCEFIPS プロバイダーと IBM Java Secure Sockets Extension (JSSE) FIPS 140-2 Cryptographic Module (IBMJSSE2) は、FIPS 140-2 準拠暗号化を提供します。

IBMJCEFIPS プロバイダーの詳細は、IBM Documentation for IBM JCEFIPS および NIST IBMJCEFIPS – Security Policy を参照してください。IBMJSSE2 の詳細は、Running IBMJSSE2 in FIPS mode を参照します。

1.2.14.1. キーストレージ

IBM JCE はキーストアを提供しません。このキーはコンピューターに保存され、その物理境界は残しません。このキーがコンピューター間で移動している場合は暗号化する必要があります。

FIPS 準拠のモードで keytool を実行するには、以下のような各コマンドで -providerClass を使用します。

keytool -list -storetype JCEKS -keystore mystore.jck -storepass mystorepass -providerClass com.ibm.crypto.fips.provider.IBMJCEFIPS

1.2.14.2. 管理 CLI の設定

IBM JDK で FIPS 140-2 準拠の暗号の管理 CLI を設定 するには、以下のように、IBM JDK に固有の管理 CLI 設定ファイルを使用する必要があります。

例: cli-wildfly-config-ibm.xml

<configuration>
  <authentication-client xmlns="urn:elytron:client:1.2">
    <key-stores>
      <key-store name="truststore" type="JKS">
        <file name="/path/to/truststore"/>
        <key-store-clear-password password="P@ssword123"/>
      </key-store>
    </key-stores>
    <ssl-contexts>
      <ssl-context name="client-cli-context">
        <trust-store key-store-name="truststore"/>
        <cipher-suite selector="${cipher.suite.filter}"/>
        <protocol names="TLSv1"/>
      </ssl-context>
    </ssl-contexts>
    <ssl-context-rules>
      <rule use-ssl-context="client-cli-context"/>
    </ssl-context-rules>
  </authentication-client>
</configuration>

1.2.14.3. FIPS プロバイダー情報の確認

サーバーが使用する IBMJCEFIPS に関する情報を確認するには、-Djavax.net.debug=truestandalone.conf または domain.conf ファイルに追加することでデバッグレベルのロギングを有効にします。FIPS プロバイダーの情報は、server.log ファイルに記録されます。以下に例を示します。

04:22:45,685 INFO  [stdout] (http-/127.0.0.1:8443-1) JsseJCE:  Using MessageDigest SHA from provider IBMJCEFIPS version 1.7
04:22:45,689 INFO  [stdout] (http-/127.0.0.1:8443-1) DHCrypt:  DH KeyPairGenerator  from provider from init IBMJCEFIPS version 1.7
04:22:45,754 INFO  [stdout] (http-/127.0.0.1:8443-1) JsseJCE:  Using KeyFactory DiffieHellman from provider IBMJCEFIPS version 1.7
04:22:45,754 INFO  [stdout] (http-/127.0.0.1:8443-1) JsseJCE:  Using KeyAgreement DiffieHellman from provider IBMJCEFIPS version 1.7
04:22:45,754 INFO  [stdout] (http-/127.0.0.1:8443-1) DHCrypt:  DH KeyAgreement  from provider IBMJCEFIPS version 1.7
04:22:45,754 INFO  [stdout] (http-/127.0.0.1:8443-1) DHCrypt:  DH KeyAgreement  from provider from initIBMJCEFIPS version 1.7

1.2.15. JVM が FIPS モードで実行されているときに管理対象ドメインを起動する

各ホストコントローラーとマスタードメインコントローラーを更新して、通信に SSL/TLS を使用します。

前提条件

開始する前に、以下の前提条件を完了していることを確認してください。

  • 管理対象ドメインを実装している。

    管理対象ドメインの設定の詳細は、JBoss EAP設定ガイド ドメイン管理 セクションを参照してください。

  • FIPS を設定している。

    FIPS の設定の詳細は、Red Hat Enterprise Linux 7 以降での SSL/TLS の FIPS 140-2 暗号化の有効化 を参照してください。

  • 必要な証明書をすべて作成し、ドメインコントローラーの証明書を各コントローラーのトラストストアにインポートしている。
警告

Red Hat では、影響するすべてのパッケージで TLSv1.1 を利用するために SSLv2、SSLv3、および TLSv1.0 を明示的に無効化することを推奨しています。

  1. マスタードメインコントローラーで、NSS データベースを PKCS11 プロバイダーとして使用するように設定された SSL/TLS セキュリティーレルムを作成します。

    例: マスタードメインコントローラーのセキュリティーレルム

    <security-realm name="HTTPSRealm">
        <server-identities>
            <ssl>
                <engine enabled-protocols="TLSv1.1"/>
                <keystore provider="PKCS11" keystore-password="strongP@ssword1"/>
            </ssl>
        </server-identities>
        <authentication>
            <local default-user="\$local"/>
            <properties path="https-users.properties" relative-to="jboss.domain.config.dir"/>
        </authentication>
    </security-realm>

  2. 各ホストコントローラーで、認証に SSL/TLS トラストストアを使用してセキュリティーレルムを作成します。

    例: 各ホストコントローラーのセキュリティーレルム

    <security-realm name="HTTPSRealm">
      <authentication>
        <truststore provider="PKCS11" keystore-password="strongP@ssword1"/>
      </authentication>
    </security-realm>

    注記

    各ホストでこのプロセスを繰り返します。

  3. 作成したセキュリティーレルムを使用して、マスタードメインコントローラーの HTTP インターフェイスを保護します。

    例: HTTP インターフェイス

    <management-interfaces>
        <http-interface security-realm="HTTPSRealm">
            <http-upgrade enabled="true"/>
            <socket interface="management" port="${jboss.management.http.port:9990}"/>
        </http-interface>
    </management-interfaces>

  4. 各ホストコントローラーで SSL/TLS レルムを使用して、マスタードメインコントローラーに接続します。

    マスタードメインコントローラーへの接続に使用されるセキュリティーレルムを更新します。サーバーが動作していない場合に、ホストコントローラーの設定ファイル (host.xmlhost-slave.xml など) を変更します。

    例: ホストコントローラー設定ファイル

    <domain-controller>
      <remote security-realm="HTTPSRealm">
        <discovery-options>
          <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9990}"/>
        </discovery-options>
      </remote>
    </domain-controller>

  5. 各サーバーがホストコントローラーに接続する方法を更新します。

    例: サーバー設定

    <server name="my-server" group="my-server-group">
      <ssl ssl-protocol="TLS" trust-manager-algorithm="PKIX" truststore-type="PKCS11" truststore-password="strongP@ssword1"/>
    </server>

  6. 管理対象ドメインで双方向 SSL/TLS を設定します。

    双方向 SSL/TLS を有効にするには、マスタードメインコントローラーの SSL/TLS セキュリティーレルムにトラストストア認証メソッドを追加します。以下の管理 CLI コマンドを実行します。

    /host=master/core-service=management/security-realm=HTTPSRealm/authentication=truststore:add(keystore-provider="PKCS11",keystore-password="strongP@ssword1")
    
    reload --host=master

    SSL サーバーアイデンティティーを持つように各ホストコントローラーのセキュリティーレルムを更新する必要もあります。以下の管理 CLI コマンドを実行します。

    /host=host1/core-service=management/security-realm=HTTPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="strongP@ssword1",enabled-protocols=["TLSv1.1"])
    
    reload --host=host1
    重要

    また、各ホストの証明書がドメインコントローラーのトラストストアにインポートされることを確認する必要があります。

1.2.16. Red Hat Single Sign-On での管理コンソールのセキュア化

elytron サブシステムを使用すると、Red Hat シングルサインオンで JBoss EAP 管理コンソールをセキュア化できます。

注記

この機能はスタンドアロンサーバーを実行する場合のみ利用でき、管理対象ドメイン実行時にはサポートされません。管理 CLI をセキュアにする Red Hat Single Sign-On の使用はサポートされません。

以下の手順に従い、Red Hat Single Sign-On を設定し、JBoss EAP 管理コンソールのユーザーを認証します。

JBoss EAP 管理用の Red Hat Single Sign-On サーバーの設定
  1. Red Hat Single Sign-On サーバーをダウンロードしてインストールします。基本的な手順については、Red Hat Single Sign-On Getting Started Guide を参照してください。
  2. Red Hat Single Sign-On サーバーを起動します。

    この手順では、ポートオフセット 100 でサーバーを起動したことを前提とします。

    $ RHSSO_HOME/bin/standalone.sh -Djboss.socket.binding.port-offset=100
  3. http://localhost:8180/auth/ で Red Hat Single Sign-On 管理コンソールにログインします。

    Red Hat Single Sign-On 管理コンソールに初めてアクセスすると、初期管理ユーザーを作成するように求められます。

  4. wildfly-infra という名前の新規レルムを作成します。

    1. レルム名の横にあるドロップダウンメニューで、Add realm をクリックし、Name フィールドに wildfly-infra を入力し、Create をクリックします。
  5. wildfly-console というクライアントアプリケーションを作成します。

    重要

    このクライアントアプリケーションの名前は wildfly-consoleする必要があります

    1. Clients を選択し、Create をクリックします。
    2. Client ID フィールドに wildfly-console を入力し、Save をクリックします。
    3. 表示される Settings 画面で Access Typepublic に設定し、Valid Redirect URIshttp://localhost:9990/console/* に、Web Originshttp://localhost:9990 に設定し、Save をクリックします。
  6. wildfly-management というクライアントアプリケーションを作成します。

    1. Clients を選択し、Create をクリックします。
    2. Client ID フィールドに wildfly-management を入力し、Save をクリックします。
    3. 表示される Settings 画面で、Access Typebearer-only に設定し、Save をクリックします。
  7. JBoss EAP 管理コンソールへのアクセスを付与するためのロールを作成します。

    1. Roles を選択して Add Role をクリックします。
    2. Role Name フィールドに大文字で ADMINISTRATOR を入力し、Save をクリックします。

      以下の手順では、ADMINISTRATOR ロールを使用しますが、その他のロールもサポートされています。詳細は、JBoss EAP のセキュリティーアーキテクチャーロールベースのアクセス制御 を参照してください。

  8. ユーザーを作成し、ADMINISTRATOR ロールを割り当てます。

    1. Users を選択して Add user をクリックします。
    2. Username フィールドに jboss を入力して Save をクリックします。
    3. Credentials タブを選択し、このユーザーのパスワードを設定します。
    4. Role Mappings タブを選択し、ADMINISTRATOR を選択して Add selected をクリックし、このユーザーにロールを追加します。
JBoss EAP に Red Hat Single Sign-On クライアントアダプターをインストールする
  1. Download the Red Hat Single Sign-On client adapter for JBoss EAP 7 from the ソフトウェアダウンロードページ から JBoss EAP 7 の Red Hat Single Sign-On クライアントアダプターをダウンロードします。
  2. このファイルを JBoss EAP インストールのルートディレクトリーに展開します。
  3. adapter-elytron-install-offline.cli スクリプトを実行し、JBoss EAP のインストールを設定します。

    $ EAP_HOME/bin/jboss-cli.sh --file=adapter-elytron-install-offline.cli
    重要

    このスクリプトにより、keycloak サブシステムと、elytron および undertow サブシステムのその他の必要なリソースが standalone.xml に追加されます。別の設定ファイルを使用する必要がある場合は、必要に応じてスクリプトを変更してください。

Red Hat Single Sign-On を使用するように JBoss EAP を設定する
  1. EAP_HOME/bin/ ディレクトリーで、以下の内容を含む protect-eap-mgmt-services.cli という名前のファイルを作成します。

    # Create a realm for both JBoss EAP console and mgmt interface
    /subsystem=keycloak/realm=wildfly-infra:add(auth-server-url=http://localhost:8180/auth,realm-public-key=REALM_PUBLIC_KEY)
    
    # Create a secure-deployment in order to protect mgmt interface
    /subsystem=keycloak/secure-deployment=wildfly-management:add(realm=wildfly-infra,resource=wildfly-management,principal-attribute=preferred_username,bearer-only=true,ssl-required=EXTERNAL)
    
    # Protect HTTP mgmt interface with Keycloak adapter
    /core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm)
    /subsystem=elytron/http-authentication-factory=keycloak-mgmt-http-authentication:add(security-domain=KeycloakDomain,http-server-mechanism-factory=wildfly-management,mechanism-configurations=[{mechanism-name=KEYCLOAK,mechanism-realm-configurations=[{realm-name=KeycloakOIDCRealm,realm-mapper=keycloak-oidc-realm-mapper}]}])
    /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory,value=keycloak-mgmt-http-authentication)
    /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade, value={enabled=true, sasl-authentication-factory=management-sasl-authentication})
    
    # Enable RBAC where roles are obtained from the identity
    /core-service=management/access=authorization:write-attribute(name=provider,value=rbac)
    /core-service=management/access=authorization:write-attribute(name=use-identity-roles,value=true)
    
    # Create a secure-server in order to publish the JBoss EAP console configuration via mgmt interface
    /subsystem=keycloak/secure-server=wildfly-console:add(realm=wildfly-infra,resource=wildfly-console,public-client=true)
    
    # reload
    reload
  2. このファイルでの REALM_PUBLIC_KEY を公開鍵の値に置き換えます。この値を取得するには、Red Hat Single Sign-On 管理コンソールにログインし、wildfly-infra レルムを選択して Realm SettingsKeys の順に選択し、Public key をクリックします。
  3. JBoss EAP を起動します。

    $ EAP_HOME/bin/standalone.sh
    重要

    Red Hat Single Sign-On クライアントアダプターを取り付けるとき adapter-elytron-install-offline.cli スクリプトを変更して、standalone.xml 以外の設定ファイルを使用する場合は、その設定を使用して JBoss EAP を起動するようにしてください。

  4. protect-eap-mgmt-services.cli スクリプトを実行します。

    $ EAP_HOME/bin/jboss-cli.sh --connect --file=protect-eap-mgmt-services.cli

http://localhost:9990/console/ で JBoss EAP 管理コンソールにアクセスすると、ログインのために Red Hat Single Sign-On にリダイレクトされ、認証に成功したときに JBoss EAP 管理コンソールにリダイレクトされます。

1.3. レガシーセキュリティードメインへのセキュリティー監査の設定

監査モジュールを使って、セキュリティー サブシステムのイベントを監視できます。監査では、プロバイダーモジュール、カスタム実装、またはその両方を使用してイベントを監視します。

イベントの監視後に、監査モジュールは、ログファイルへの書き込み、電子メール通知の読み取りをはじめ、他の測定可能な監査メカニズムを使用します。

管理コンソールを使用して、セキュリティードメインのセキュリティー監査設定を行います。

手順

  1. Configuration タブをクリックします。
  2. SubsystemsSecurity (Legacy) に移動します。
  3. 編集可能なセキュリティードメインを選択し、表示をクリックします。
  4. Audit タブを選択し、Add を押して、新しい監査モジュールを追加します。
  5. モジュールの名前を設定し、Code フィールドにプロバイダーモジュールのクラス名を入力します。
  6. オプション: モジュールオプションを編集し、モジュールオプションフィールドにキーと値のペアを追加することでモジュールオプションを追加します。Enter を押して新しい値を追加し、Backspace を押して既存の値を削除します。

1.4. Elytron によるセキュリティー監査

Elytron を使用し、トリガーとなるイベントのセキュリティー監査を完了することができます。セキュリティー監査とは、承認または認証の試行に応答して、ログへの書き込みなどのイベントをトリガーすることを指します。

イベントに対して行われるセキュリティー監査の種類は、セキュリティーレルムの設定によって異なります。

1.4.1. Elytron 監査ロギング

elytron サブシステムで監査ログを有効にすると、アプリケーションサーバー内で Elytron の認証および承認イベントをログに記録できます。Elytron は監査ログエントリーを、個々のイベントを保存する JSON、または人間が読めるテキスト形式の SIMPLE のいずれかで保存します。

Elytron の監査ロギングは、JBoss EAP 管理インターフェイスの監査ロギングなど、他のタイプの監査ロギングとは異なります。

Elytron はデフォルトでは、監査ログが無効です。Elytron に以下のログハンドラーを設定して、監査ログを有効化できます。セキュリティードメインにログハンドラーを追加できます。

  • ファイル監査ログ
  • 定期的なローテーションファイル監査ロギング
  • サイズローテーションファイル監査ロギング
  • syslog 監査ロギング
  • カスタム監査ログ

aggregate-security-event-listener リソース を使用すると、ロガーなどのより多くの宛先にセキュリティーイベントを送信することができます。aggregate-security-event-listener リソース は、全イベントをアグリゲートリスナー定義で指定されたリスナーすべてに配信します。

監査モジュールを使って、レガシーセキュリティードメインのイベントを監視することができます。管理コンソールを使用して、レガシーセキュリティードメインのセキュリティー監査設定を設定できます。

関連情報

1.4.2. ファイル監査ログの有効化

elytron サブシステムを使用して、スタンドアロンサーバーまたは管理ドメイン内のサーバーにあるファイルの監査ログを有効化できます。

ファイル監査ロギングは、監査ログメッセージをファイルシステムにあるファイル 1 つに保存します。デフォルトでは、Elytron はファイル監査ロガーとして local-audit を指定します。local-audit を有効にして、スタンドアロンサーバーでは EAP_HOME/standalone/log/audit.log に、管理ドメインでは EAP_HOME/domain/log/audit.log に、Elytron 監査ログを書き込めるようにする必要があります。

手順

  1. ファイルの監査ログを作成します。

    elytron サブシステムを使用して、ファイル監査ログを作成する例:

    /subsystem=elytron/file-audit-log=<audit_log_name>:add(path="<path_to_log_file>", relative-to="<base_for_path_to_log_file>", format=<format_type>, synchronized=<whether_to_log_immediately>)

  2. ファイル監査ログをセキュリティードメインに追加します。

    セキュリティードメインにファイル監査ログを追加するコマンド例

    /subsystem=elytron/security-domain=<security_domain_name>:write-attribute(name=security-event-listener , value=<audit_log_name>)

関連情報

1.4.3. 定期的なローテーションファイル監査ロギングの有効化

elytron サブシステムを使用して、スタンドアロンサーバーまたはドメインにあるサーバーのファイル監査ログを有効にできます。

ファイル監査ログを定期的にローテーションすると、設定されたスケジュールに基づいて監査ログファイルが自動的にローテーションされます。定期的なローテーションファイル監査ロガーは、デフォルトのファイル監査ロガーと似ていますが、定期的なローテーションファイル監査ロガーには、suffix という追加の属性が含まれています。

suffix 属性の値は、java.time.format.Date Time Formatter 形式で指定された日付 (.yyyy-MM-dd など) です。Elytron は、その接尾辞で指定された値から自動的にローテーションの周期を計算します。elytron サブシステムは、ログファイル名の最後に接尾辞を付加します。

手順

  1. 定期的なローテーションファイル監査ログを作成します。

    elytron サブシステムでの定期的なローテーションファイル監査ログの作成例

    /subsystem=elytron/periodic-rotating-file-audit-log=<periodic_audit_log_name>:add(path="<periodic_audit_log_filename>", relative-to="<path_to_audit_log_directory>", format=<record_format>, synchronized=<whether_to_log_immediately>,suffix="<suffix_in_DateTimeFormatter_format>")

  2. 定期的なローテーションファイル監査ロガーをセキュリティードメインに追加します。

    セキュリティードメインに定期的なローテーションファイル監査ロガーを追加する例

    /subsystem=elytron/security-domain=<security_domain_name>:write-attribute(name=security-event-listener, value=<periodic_audit_log_name>)

関連情報

1.4.4. サイズローテーションファイルの監査ログの有効化

elytron サブシステムを使用して、スタンドアロンサーバーまたはドメイン管理されたサーバーのサイズサブシステムファイル監査ログを有効にできます。

ログファイルが設定されたファイルサイズに達すると、サイズローテーションファイル監査ログにより自動的に監査ログのローテーションが行われます。サイズサブシステムファイル監査ロガーは、デフォルトのファイル監査ロガーと類似していますが、サイズサブシステムファイル監査ロガーには追加の属性が含まれています。

ログファイルのサイズが rotate-size 属性で定義された制限を超えた場合には、Elytron は接尾辞 .1 を現在のファイルに末尾に追加して、Elytron は新しいログファイルを作成します。Elytron は、既存のログファイルの接尾辞に 1 つ足します。たとえば、Elytron は audit_log.1 の名前を audit_log.2 に変更します。Elytron は、ログファイルの量が max-backup-index で定義されたログファイルの最大数に達するまでそのまま増分していきます。ログファイルが max-backup-index の値を超えると、Elytron は、audit_log.99 のように制限を超えたファイルを削除します。

手順

  1. サイズローテーションファイルの監査ログを作成します。

    elytron サブシステムを使用して、サイズローテーションファイルの監査ログを作成する例

    /subsystem=elytron/size-rotating-file-audit-log=<audit_log_name>:add(path="<path_to_log_file>",relative-to="<base_for_path_to_log_file>",format=<record_format>,synchronized=<whether_to_log_immediately>,rotate-size="<max_file_size_before_rotation>",max-backup-index=<max_number_of_backup_files>)

  2. サイズローテーション監査ロガーをセキュリティードメインに追加します。

    elytron サブシステムを使用して、サイズローテーションファイルの監査ログを有効にした例

    /subsystem=elytron/security-domain=<domain_size_logger>:write-attribute(name=security-event-listener, value=<audit_log_name>)

関連情報

1.4.5. syslog の監査ログの有効化

elytron サブシステムを使って、スタンドアロンのサーバーやドメイン管理されているサーバーの syslog 監査ログを有効にできます。syslog 監査ロギングを使用すると、ロギング結果を syslog サーバーに送信するため、ローカルファイルへのロギングよりもセキュリティーオプションが多くなります。

syslog ハンドラーは、syslog サーバーのホスト名や、syslog サーバーをリッスンするポートなど、syslog サーバーへの接続に使用するパラメーターを指定します。複数の Syslog ハンドラーを定義して同時に有効化できます。

対応するログ形式は、RFC5424RFC3164 です。伝送プロトコルは、UDP、TCP、TCP with SSL に対応しています。

最初のインスタンスに syslog を定義すると、ロガーは、以下の例で示すようなメッセージを含む INFORMATIONAL 優先度イベントを syslog サーバーに送信します。

"Elytron audit logging enabled with RFC format: <format>"

&lt;format&gt; は、監査ログハンドラーに設定されている RFC 形式を指し、デフォルトでは RFC5424 の値が設定されています。

手順

  1. syslog ハンドラーを追加します。

    elytron サブシステムを使って syslog ハンドラーを追加した例

    /subsystem=elytron/syslog-audit-log=<syslog_audit_log_name>:add(host-name=<record_host_name>, port=<syslog_server_port_number>, server-address=<syslog_server_address>, format=<record_format>, transport=<transport_layer_protocol>)

    また、TLS 経由で syslog サーバーにログを送信することもできます。

    TLS でログを送信するための syslog の設定例

    /subsystem=elytron/syslog-audit-log=<syslog_audit_log_name>:add(transport=SSL_TCP,server-address=<syslog_server_address>,port=<syslog_server_port_number>,host-name=<record_host_name>,ssl-context=<client_ssl_context>)

  2. セキュリティードメインに syslog 監査ロガーを追加します。

    セキュリティードメインに syslog 監査ロガーを追加する例

    /subsystem=elytron/security-domain=<security_domain_name>:write-attribute(name=security-event-listener, value=<syslog_audit_log_name>)

関連情報

1.4.6. Elytron でのカスタムセキュリティーイベントリスナーの使用

Elytron を使って、カスタムイベントリスナーを定義できます。カスタムイベントリスナーは、受信したセキュリティーイベントの処理を管理します。イベントリスナーは、カスタムの監査ログ目的で使用したり、内部の ID ストレージに対するユーザー認証に使したり用できます。

重要

module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビュー機能としてのみ提供されます。module コマンドは、管理ドメイン内での使用や、リモート管理 CLI での接続には適していません。実稼働環境では、手動でモジュールを追加削除する必要があります。

テクノロジープレビュー機能は、Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

テクノロジープレビュー機能のサポート範囲は、Red Hat カスタマーポータルの テクノロジープレビュー機能のサポート範囲 を参照してください。

手順

  1. java.util.function.Consumer<org.wildfly.security.auth.server.event.SecurityEvent> インターフェイスを実装するクラスを作成します。たとえば、以下は、ユーザーの認証が成功または失敗したときに常にメッセージを出力します。

    指定のインターフェイスを使用する Java クラスの作成例

    public class MySecurityEventListener implements Consumer<SecurityEvent> {
        public void accept(SecurityEvent securityEvent) {
            if (securityEvent instanceof SecurityAuthenticationSuccessfulEvent) {
                System.err.printf("Authenticated user \"%s\"\n", securityEvent.getSecurityIdentity().getPrincipal());
            } else if (securityEvent instanceof SecurityAuthenticationFailedEvent) {
                System.err.printf("Failed authentication as user \"%s\"\n", ((SecurityAuthenticationFailedEvent)securityEvent).getPrincipal());
            }
        }
    }

    この例の Java クラスは、ユーザー認証に成功または失敗するたびに、メッセージを表示します。

  2. カスタムイベントリスナーをモジュールとして提供する JAR を JBoss EAP に追加します。

    以下に、カスタムイベントリスナーをモジュールとして Elytron に追加する管理 CLI コマンドの例を示します。

    module コマンドを使用して、カスタムイベントリスナーを Elytron にモジュールとして追加した例

    /subsystem=elytron/custom-security-event-listener=<listener_name>:add(module=<module_name>, class-name=<class_name>)

  3. セキュリティードメインのカスタムイベントリスナーを参照します。

    Application Domain でカスタムイベントリスナーを参照する例

    /subsystem=elytron/security-domain=<domain_name>:write-attribute(name=security-event-listener, value=<listener_name>)

  4. サービスを再起動します。

    $ reload

    イベントリスナーは、指定されたセキュリティードメインからセキュリティーイベントを受信します。

関連情報

1.5. 一方向と双方向 SSL/TLS をアプリケーションに設定

1.5.1. アプリケーション用の自己署名証明書の自動作成

レガシーセキュリティーレルムを使用している場合は、JBoss EAP では開発の目的で自己署名証明書が自動的に生成されます。

例: 自己署名証明書の作成を示すサーバー−ログ

15:26:09,031 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-7) WFLYDM0111: Keystore /path/to/jboss/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
...
15:26:10,076 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0113: Generated self signed certificate at /path/to/jboss/configuration/application.keystore. Please note that self signed certificates are not secure, and should only be used for testing purposes. Do not use this self signed certificate in production.
SHA-1 fingerprint of the generated key is 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:00:11:22:33
SHA-256 fingerprint of the generated key is 00:11:22:33:44:55:66:77:88:99:00:aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee
...

この証明書はテスト目的で作成され、アプリケーションが使用する HTTPS インターフェイスに割り当てられます。ファイルが HTTPS インターフェイスの初回アクセス時に存在しない場合は、証明書を含むキーストアが生成されます。

例: 自己署名証明書を使用したデフォルトの ApplicationRealm

<security-realm name="ApplicationRealm">
  <server-identities>
    <ssl>
      <keystore path="application.keystore" relative-to="jboss.server.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/>
    </ssl>
  </server-identities>
  ...
</security-realm>

例: HTTPS インターフェイスのデフォルト設定

<subsystem xmlns="urn:jboss:domain:undertow:10.0">
    ...
    <server name="default-server">
        ...
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
        <host name="default-host" alias="localhost">
        ...

注記

自己署名証明書の作成を無効にする場合は、サーバーキーストア設定から generate-self-signed-certificate-host="localhost" を削除する必要があります。generate-self-signed-certificate-host 属性は、自己署名証明書を生成するホスト名を保持します。

警告

この自己署名証明書はテスト目的のみを目的とし、実稼働環境での使用を目的としていません。Elytron を使用したアプリケーションに SSL/TLS を設定する方法は、Elytron サブシステムを使用してアプリケーションに対して一方向 SSL/TLS を有効化する および Elytron サブシステムを使用してアプリケーションに対して双方向 SSL/TLS を有効化する セクションを参照してください。レガシーのセキュリティーを使用したアプリケーション向けに SSL/TLS を設定する方法は、レガシーセキュリティーレルムを使用してアプリケーションに対して一方向 SSL/TLS を有効化する および レガシーセキュリティーレルムを使用してアプリケーションに対して双方向 SSL/TLS を有効化する セクションを参照してください。

1.5.2. Elytron の使用

1.5.2.1. Elytron サブシステムを使用したアプリケーション用の一方向 SSL/TLS の有効化

JBoss EAP では、JBoss EAP 管理 CLI または管理コンソールを使用してデプロイされたアプリケーションの一方向 SSL/TLS を有効にできます。

管理 CLI では、一方向の SSL/TLS を以下の方法で有効にできます。

セキュリティーコマンドの使用

security enable-ssl-http-server コマンドを使用すると、デプロイされたアプリケーションに一方向 SSL/TLS を有効にできます。

例: ウィザードの使用

security enable-ssl-http-server --interactive

Please provide required pieces of information to enable SSL:
Key-store file name (default default-server.keystore): keystore.jks
Password (blank generated): secret
What is your first and last name? [Unknown]: localhost
What is the name of your organizational unit? [Unknown]:
What is the name of your organization? [Unknown]:
What is the name of your City or Locality? [Unknown]:
What is the name of your State or Province? [Unknown]:
What is the two-letter country code for this unit? [Unknown]:
Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct y/n [y]?
Validity (in days, blank default): 365
Alias (blank generated): localhost
Enable SSL Mutual Authentication y/n (blank n): n

SSL options:
key store file: keystore.jks
distinguished name: CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
password: secret
validity: 365
alias: localhost
Server keystore file keystore.jks, certificate file keystore.pem and keystore.csr file
will be generated in server configuration directory.
Do you confirm y/n: y

注記

コマンドを実行すると、管理 CLI がサーバーをリロードします。

一方向 SSL/TLS がアプリケーション用に有効化されました。

Elytron サブシステムコマンドの使用

JBoss EAP では、undertow サブシステムとともに elytron サブシステムを使用すると、デプロイされたアプリケーションに一方向 SSL/TLS を有効にすることができます。

  1. JBoss EAP で key-store を設定します。

    /subsystem=elytron/key-store=httpsKS:add(path=/path/to/keystore.jks, credential-reference={clear-text=secret}, type=JKS)

    キーストアファイルが存在しない場合は、以下のコマンドを使用してサンプルキーペアを生成できます。

    /subsystem=elytron/key-store=httpsKS:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
    
    /subsystem=elytron/key-store=httpsKS:store()
  2. key- store を参照する key-manager を設定します。

    /subsystem=elytron/key-manager=httpsKM:add(key-store=httpsKS,credential-reference={clear-text=secret})
    重要

    Elytron サブシステムはデフォルトで KeyManagerFactory.getDefaultAlgorithm() を使用してアルゴリズムを決定するため、Red Hat は前のコマンドでアルゴリズム属性を指定しませんでした。ただし、アルゴリズム属性は指定できます。アルゴリズム属性を指定するには、使用している JDK によるキーマネージャーアルゴリズムを知る必要があります。たとえば、SunJSSE を使用する JDK は、PKIX および SunX509 アルゴリズムを提供します。

    前のコマンドでは、SunX509 をキーマネージャーアルゴリズム属性として指定できます。

  3. key-manager を参照する server-ssl-context を設定します。

    /subsystem=elytron/server-ssl-context=httpsSSC:add(key-manager=httpsKM, protocols=["TLSv1.2"])
    重要

    利用できるようにする必要のある SSL/TLS プロトコルを決定する必要があります。上記のコマンド例は TLSv1.2 を使用します。cipher-suite-filter 引数を使用して、許可される暗号スイートを指定でき、use-cipher-suites-order 引用して、サーバーの暗号スイートの順序を許可します。use-cipher-suites-order 属性はデフォルトで true に設定されます。これは、レガシー security サブシステムの動作とは異なります。その動作は、デフォルトで、クライアント暗号スイートの順序を許可します。

    警告

    Red Hat では、影響するすべてのパッケージで TLSv1.1 または TLSv1.2 を利用するために SSLv2、SSLv3、および TLSv1.0 を明示的に無効化することを推奨しています。

  4. https-listener が SSL 設定でレガシーセキュリティーレルムを使用するように設定されているかどうかを確認します。

    /subsystem=undertow/server=default-server/https-listener=https:read-attribute(name=security-realm)
    {
        "outcome" => "success",
        "result" => "ApplicationRealm"
    }

    上記のコマンドは、https-listener が SSL 設定の ApplicationRealm レガシーセキュリティーレルムを使用するように設定されていることを示しています。undertow は、レガシーセキュリティーレルムと Elytron の ssl-context を同時に参照できないため、レガシーセキュリティーレルムへの参照を削除する必要があります。

    注記

    結果が undefined である場合は、次の手順でセキュリティーレルムへの参照を削除する必要はありません。

  5. レガシーセキュリティーレルムへの参照を削除し、https-listener を Elytron の ssl-context を使用するように更新します。

    注記

    https-listener には、常に security-realm または ssl-context が設定されている必要があります。2 つの設定間で変更する場合は、以下に示すように、コマンドを単一のバッチで実行する必要があります。

    batch
    /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
    /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value=httpsSSC)
    run-batch
  6. サーバーをリロードします。

    reload

    一方向 SSL/TLS がアプリケーション用に有効化されました。

注記

disable-ssl-http-server コマンドを使用すると、デプロイされたアプリケーションの一方向 SSL/TLS を無効にできます。

security disable-ssl-http-server

このコマンドでは、Elytron リソースは削除されません。SSL 設定に ApplicationRealm レガシーセキュリティーレルムを使用するようにシステムを設定します。

管理コンソールの使用

管理コンソールで SSL ウィザードを使用すると、undertow サブシステムを設定することでアプリケーションに SSL を有効にできます。

ウィザードにアクセスするには、以下の手順に従います。

  1. 管理コンソールにアクセスします。詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。
  2. ConfigurationSubsystemsWeb (Undertow)Server と選択します。
  3. 設定するサーバー名をクリックします。
  4. 表示 をクリックします。
  5. ListenerHTTPS Listener に移動します。
  6. SSL を有効にするリスナーを選択し、SSL の有効化 をクリックしてウィザードを起動します。

    このウィザードでは、以下のシナリオで、SSL を有効にする方法を順を追ってガイドします。

    • 証明書ストアを作成し、自己署名証明書を生成する。
    • Let's Encrypt 認証局から証明書を取得したい。
    • 証明書ストアはすでにファイルシステムにあるが、キーストアの設定がない。
    • 有効な証明書ストアを使用するキーストアの設定が存在する。

ウィザードを使用すると、任意で相互認証のトラストストアを作成できます。

1.5.2.2. Elytron サブシステムを使用してアプリケーションに対して双方向 SSL/TLS を有効化する

  1. クライアントキーストアを取得または生成します。

    $ keytool -genkeypair -alias client -keyalg RSA -keysize 1024 -validity 365 -keystore client.keystore.jks -dname "CN=client" -keypass secret -storepass secret
  2. クライアント証明書をエクスポートします。

    keytool -exportcert  -keystore client.keystore.jks -alias client -keypass secret -storepass secret -file /path/to/client.cer
  3. デプロイしたアプリケーションに対して双方向 SSL/TLS を有効にします。

    JBoss EAP では、デプロイされたアプリケーション用の双方向 SSL/TLS は、security コマンドまたは elytron サブシステムコマンドを使用して有効にできます。

    1. セキュリティーコマンドの使用

      security enable-ssl-http-server コマンドを使用すると、デプロイされたアプリケーションに双方向 SSL/TLS を有効にできます。

      注記

      以下の例では、信頼チェーンが存在しないので、証明書は検証されません。信頼された証明書を使用している場合、クライアントの証明書は問題なく検証できます。

      例: ウィザードの使用

      security enable-ssl-http-server --interactive
      
      Please provide required pieces of information to enable SSL:
      Key-store file name (default default-server.keystore): server.keystore.jks
      Password (blank generated): secret
      What is your first and last name? [Unknown]: localhost
      What is the name of your organizational unit? [Unknown]:
      What is the name of your organization? [Unknown]:
      What is the name of your City or Locality? [Unknown]:
      What is the name of your State or Province? [Unknown]:
      What is the two-letter country code for this unit? [Unknown]:
      Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct y/n [y]?
      Validity (in days, blank default): 365
      Alias (blank generated): localhost
      Enable SSL Mutual Authentication y/n (blank n): y
      Client certificate (path to pem file): /path/to/client.cer
      Validate certificate y/n (blank y): n
      Trust-store file name (management.truststore): server.truststore.jks
      Password (blank generated): secret
      
      SSL options:
      key store file: server.keystore.jks
      distinguished name: CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
      password: secret
      validity: 365
      alias: localhost
      client certificate: /path/to/client.cer
      trust store file: server.trustore.jks
      trust store password: secret
      Server keystore file server.keystore.jks, certificate file server.pem and server.csr file will be generated in server configuration directory.
      Server truststore file server.trustore.jks will be generated in server configuration directory.
      Do you confirm y/n: y

      注記

      コマンドを実行すると、管理 CLI がサーバーをリロードします。

      双方向 SSL/TLS 認証を完了するには、サーバーの証明書をクライアントトラストストアにインポートし、クライアント証明書を表示するようにクライアントを設定する必要があります。

    2. elytron サブシステムコマンドの使用

      JBoss EAP では、undertow サブシステムとともに elytron サブシステムを使用してデプロイされたアプリケーションで双方向 SSL/TLS を有効にすることもできます。

      1. キーストアを取得または生成します。

        JBoss EAP で双方向 SSL/TLS を有効化する前に、使用する予定のキーストア、トラストストア、および証明書を取得または生成する必要があります。

        1. サーバーキーストアを作成します。

          /subsystem=elytron/key-store=twoWayKS:add(path=/PATH/TO/server.keystore.jks,credential-reference={clear-text=secret},type=JKS)
          
          /subsystem=elytron/key-store=twoWayKS:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
          
          /subsystem=elytron/key-store=twoWayKS:store()
          注記

          上記のコマンドはキーストアへの絶対パスを使用します。または、relative-to 属性を使用してベースディレクトリー変数を指定し、path は相対パスを指定します。

          /subsystem=elytron/key-store=twoWayKS:add(path=server.keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
        2. サーバー証明書をエクスポートします。

          /subsystem=elytron/key-store=twoWayKS:export-certificate(alias=localhost,path=/path/to/server.cer,pem=true)
      2. サーバートラストストアのキーストアを作成し、クライアント証明書をサーバートラストストアにインポートします。

        注記

        以下の例では、信頼チェーンが存在しないので、証明書は検証されません。信頼された証明書を使用している場合、クライアントの証明書は問題なく検証できます。

        /subsystem=elytron/key-store=twoWayTS:add(path=/path/to/server.truststore.jks,credential-reference={clear-text=secret},type=JKS)
        
        /subsystem=elytron/key-store=twoWayTS:import-certificate(alias=client,path=/path/to/client.cer,credential-reference={clear-text=secret},trust-cacerts=true,validate=false)
        
        /subsystem=elytron/key-store=twoWayTS:store()
      3. キーストア key-store を参照する key-manager を設定します。

        /subsystem=elytron/key-manager=twoWayKM:add(key-store=twoWayKS, credential-reference={clear-text=secret})
        重要

        Elytron サブシステムはデフォルトで KeyManagerFactory.getDefaultAlgorithm() を使用してアルゴリズムを決定するため、Red Hat は前のコマンドでアルゴリズム属性を指定しませんでした。ただし、アルゴリズム属性は指定できます。アルゴリズム属性を指定するには、使用している JDK によるキーマネージャーアルゴリズムを知る必要があります。

        たとえば、Sun valueFrom を使用する JDK では PKIX アルゴリズムおよび SunX 509 アルゴリズムを利用できます。

        前のコマンドでは、SunX509 をキーマネージャーアルゴリズム属性として指定できます。

      4. トラストストア key-store を参照する trust-manager を設定します。

        /subsystem=elytron/trust-manager=twoWayTM:add(key-store=twoWayTS)
        重要

        Elytron サブシステムはデフォルトで TrustManagerFactory.getDefaultAlgorithm() を使用してアルゴリズムを決定するため、Red Hat は前のコマンドでアルゴリズム属性を指定しませんでした。ただし、アルゴリズム属性は指定できます。アルゴリズム属性を指定するには、使用している JDK によるトラストマネージャーアルゴリズムを知る必要があります。たとえば、Sun valueFrom を使用する JDK では PKIX アルゴリズムおよび SunX 509 アルゴリズムを利用できます。

        前のコマンドでは、PKIX をトラストマネージャーのアルゴリズム属性として指定できます。

      5. key-managertrust-manager、を参照する server-ssl-context を設定し、クライアント認証を有効化します。

        /subsystem=elytron/server-ssl-context=twoWaySSC:add(key-manager=twoWayKM, protocols=["TLSv1.2"], trust-manager=twoWayTM, need-client-auth=true)
        重要

        利用できるようにする必要のある SSL/TLS プロトコルを決定する必要があります。上記のコマンド例は TLSv1.2 を使用します。cipher-suite-filter 引数を使用して、許可される暗号スイートを指定でき、use-cipher-suites-order 引用して、サーバーの暗号スイートの順序を許可します。use-cipher-suites-order 属性はデフォルトで true に設定されます。これは、レガシー security サブシステムの動作とは異なります。その動作は、デフォルトで、クライアント暗号スイートの順序を許可します。

        警告

        Red Hat では、影響するすべてのパッケージで TLSv1.1 または TLSv1.2 を利用するために SSLv2、SSLv3、および TLSv1.0 を明示的に無効化することを推奨しています。

      6. https-listener が SSL 設定でレガシーセキュリティーレルムを使用するように設定されているかどうかを確認します。

        /subsystem=undertow/server=default-server/https-listener=https:read-attribute(name=security-realm)
        {
            "outcome" => "success",
            "result" => "ApplicationRealm"
        }

        上記のコマンドは、https-listener が SSL 設定の ApplicationRealm レガシーセキュリティーレルムを使用するように設定されていることを示しています。Undertow は、elytron サブシステムではレガシーセキュリティーレルムと ssl-context を同時に参照できません。したがって、レガシーセキュリティーレルムへの参照を削除する必要があります。

        注記

        結果が undefined である場合は、次の手順でセキュリティーレルムへの参照を削除する必要はありません。

      7. レガシーセキュリティーレルムへの参照を削除し、https-listener を Elytron の ssl-context を使用するように更新します。

        注記

        https-listener には、常に security-realm または ssl-context が設定されている必要があります。2 つの設定間で変更する場合は、以下に示すように、コマンドを単一のバッチで実行する必要があります。

        batch
        /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
        /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value=twoWaySSC)
        run-batch
      8. サーバーをリロードします。

        reload
        注記

        双方向 SSL/TLS 認証を完了するには、サーバーの証明書をクライアントトラストストアにインポートし、クライアント証明書を表示するようにクライアントを設定する必要があります。

        $ keytool -importcert -keystore client.truststore.jks -storepass secret -alias localhost -trustcacerts -file /path/to/server.cer
      9. クライアント証明書を使用するようにクライアントを設定します。

        双方向 SSL / TLS 認証を完了するには、信頼されたクライアント証明書をサーバーに提示するようにクライアントを設定する必要があります。たとえば、ブラウザーを使用している場合は、信頼された証明書をブラウザーの信頼ストアにインポートする必要があります。

        この手順では、双方向 SSL/TLS を強制しますが、アプリケーションの元の認証方法は変更されません。

        元の認証方法を変更する場合は、JBoss EAP アイデンティティー管理の設定方法証明書による認証設定 を参照してください。

双方向 SSL/TLS がアプリケーション用に有効化されました。

注記

disable-ssl-http-server コマンドを使用すると、デプロイされたアプリケーションの双方向 SSL/TLS を無効にできます。

security disable-ssl-http-server

このコマンドでは、Elytron リソースは削除されません。SSL 設定に ApplicationRealm レガシーセキュリティーレルムを使用するようにシステムを設定します。

1.5.3. Elytron で CRL を使用した証明書失効リストの設定

Elytron で証明書失効に証明書失効リスト (CRL) を使用するように、双方向 SSL/TLS の有効化に使用されるトラストマネージャーを設定します。

前提条件

  • トラストマネージャーは双方向 SSL/TLS を使用するよう設定されます。
  • トラストマネージャーには、失効するためにチェックされる証明書チェーンが含まれます。

手順

  1. トラストマネージャーが、証明書で参照されるディストリビューションポイントから取得した CRL を使用するように設定します。

    /subsystem=elytron/trust-manager=twoWayTM:write-attribute(name=certificate-revocation-list,value={})
  2. 証明書で参照されているディストリビューションポイントから取得した CRL を上書きします。

    /subsystem=elytron/trust-manager=twoWayTM:write-attribute(name=certificate-revocation-list.path, value=intermediate.crl.pem)
  3. 証明書失効に CRL を使用するように trust-manager を設定します。

    • OCSP レスポンダーが証明書失効リストに対しても設定されている場合、証明書失効に CRL を使用するようトラストマネージャーに、値が trueocsp.prefer- CRL 属性も追加します。

      /subsystem=elytron/trust-manager=twoWayTM:write-attribute(name=ocsp.prefer-crls,value="true")
    • OCSP レスポンダーが証明書失効リストに対して設定されていない場合、設定は完了します。

追加情報

1.5.4. Elyton で OCSP を使用した認証失効の設定

双方向 SSL/TLS が、証明書失効リストに Online Certificate Status Protocol (OCSP) レスポンダーを使用するようにするのに使用されるトラストマネージャーを設定します。OCSP は RFC6960 で定義されてい ます。

OCSP レスポンダーと CRL が証明書失効に対して設定されている場合、OCSP レスポンダーはデフォルトで呼び出されます。

前提条件

  • トラストマネージャーは双方向 SSL/TLS を使用するよう設定されます。

手順

  1. 証明書失効に、証明書に定義された OCSP レスポンダーを使用するようにトラストマネージャーを設定します。

    /subsystem=elytron/trust-manager=twoWayTM:write-attribute(name=ocsp,value={})
  2. 証明書で定義された OCSP レスポンダーを上書きします。

    /subsystem=elytron/trust-manager=twoWayTM:write-attribute(name=ocsp.responder,value="http://example.com/ocsp-responder")

追加情報

1.5.5. レガシーセキュリティーレルムの使用

重要

前提条件として、SSL/TLS 暗号化キーと証明書を作成し、アクセス可能なディレクトリーに配置する必要があります。さらに、キーストアエイリアスやパスワード、必要な暗号スイートなどの関連情報もアクセスできる必要があります。SSL/TLS キーおよび証明書の生成例は、方向 SSL/TLS の設定 セクションにある最初の手順を参照してください。暗号化スイートを含む HTTPS リスナーの詳細は、HTTPS リスナーの参照 を参照してください。

1.5.5.1. レガシーセキュリティーレルムを使用したアプリケーション用の一方向 SSL/TLS の有効化

この例では、キーストアの identity.jks がサーバー設定ディレクトリーにコピーされ、指定のプロパティーで設定されたことを仮定します。管理者は、example の独自の値を置き換えてください。

注記

ここで使用する管理 CLI コマンドは、JBoss EAP スタンドアロンサーバーを実行していることを仮定しています。JBoss EAP 管理対象ドメインの管理 CLI を使用する場合の詳細は 管理 CLI ガイド を参照してください。

  1. 最初に HTTPS セキュリティーレルムを追加し、設定します。HTTPS セキュリティーレルムが設定されたら、セキュリティーレルムを参照する undertow サブシステムで https-listener を設定します。

    batch
    
    /core-service=management/security-realm=HTTPSRealm:add
    
    /core-service=management/security-realm=HTTPSRealm/server-identity=ssl:add(keystore-path=identity.jks, keystore-relative-to=jboss.server.config.dir, keystore-password=password1, alias=appserver)
    
    /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=security-realm, value=HTTPSRealm)
    
    run-batch
    警告

    Red Hat では、影響するすべてのパッケージで TLSv1.1 または TLSv1.2 を利用するために SSLv2、SSLv3、および TLSv1.0 を明示的に無効化することを推奨しています。

  2. JBoss EAP サーバーを再起動し、変更を反映します。

1.5.5.2. レガシーセキュリティーレルムを使用したアプリケーションの双方向 SSL/TLS の有効化

アプリケーションに双方向 SSL/TLS を設定する場合は、Setting up Two-way SSL/TLS for the Management Interfaces で説明されている手順の多くに従います。アプリケーションに双方向 SSL/TLS を設定するには、以下を行う必要があります。

  1. クライアントとサーバー両方のストアを生成します。
  2. クライアントとサーバー両方の証明書をエクスポートします。
  3. opposing トラストストアに証明書をインポートします。
  4. サーバーのキーストアおよびトラストストアを使用するサーバーで、CertificateRealm などのセキュリティーレルムを定義します。
  5. セキュリティーレルムを使用し、クライアント検証が必須となるように undertow サブシステムを更新します。

最初の 4 つの手順は、Setting up Two-way SSL/TLS for the Management Interfaces で説明されています。

重要

新しいセキュリティーレルムが追加されても、サーバーがリロードされていない場合は、サーバーをリロードしてから次の手順を実行する必要があります。

Undertow サブシステムの調整

キーストア、証明書、トラストストア、およびセキュリティーレルムが作成され、設定されると、undertow サブシステムに HTTPS リスナーを追加し、作成したセキュリティーレルムを使用する必要があり、クライアントの検証が必須になります。

/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=security-realm, value=CertificateRealm)

/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=verify-client, value=REQUIRED)
重要

変更を反映するには、サーバーをリロードする必要があります。

重要

アプリケーションに双方向 SSL/TLS を有効化した JBoss EAP インスタンスに接続するクライアントは、クライアント証明書またはキーストアにアクセスできなければなりません。つまり、クライアントのキーストアに証明書が含まれるクライアントキーストアが必要になります。クライアントがブラウザーを使用して JBoss EAP インスタンスに接続している場合は、その証明書またはキーストアをブラウザーの証明書マネージャーにインポートする必要があります。

注記

アプリケーションでの双方向 SSL/TLS に加えて、アプリケーションで証明書ベースの認証を使用する方法の詳細は、JBoss EAP アイデンティティー管理の設定方法証明書ベースの認証を使用するためのセキュリティドメインの設定 セクションを参照してください。

1.6. CLI セキュリティーコマンドを使用したアプリケーションの HTTP 認証の有効化

JBoss EAP では、elytron HTTP 認証ファクトリーを使用した HTTP 認証は、security enable-http-auth-http-server コマンドで undertow セキュリティードメインに対して有効化できます。デフォルトでは、このコマンドにより、アプリケーション HTTP ファクトリーが指定のセキュリティードメインに関連付けられます。

例: Undertow セキュリティードメインでの HTTP 認証の有効化

security enable-http-auth-http-server --security-domain=SECURITY_DOMAIN

Server reloaded.
Command success.
Authentication configured for security domain SECURITY_DOMAIN
http authentication-factory=application-http-authentication
security-domain=SECURITY_DOMAIN

注記

コマンドを実行すると、管理 CLI がサーバーを再読み込みし、そのサーバーに再接続します。

HTTP ファクトリーがすでに存在する場合、ファクトリーは --mechanism 引数によって定義されたメカニズムを使用するように更新されます。

1.6.1. 管理インターフェイスの HTTP 認証の無効化

この手順では、管理インターフェイスの HTTP 認証を無効にする方法を説明します。

手順

  • アクティブな HTTP 認証ファクトリーを削除するには、以下のコマンドを使用します。

    security disable-http-auth-http-server --security-domain=SECURITY_DOMAIN
  • または、以下のコマンドを使用して、アクティブな SASL 認証ファクトリーから特定のメカニズムを削除できます。

    security disable-http-auth-http-server --mechanism=MECHANISM --security-domain=SECURITY_DOMAIN

1.7. SASL の認証メカニズム

Simple Authentication and Security Layer (SASL) 認証メカニズムは、elytron サブシステムを使用して JBoss EAP サーバーへの接続を認証するメカニズムと、サーバーに接続するクライアントを定義するために使用されます。クライアントとは、他の JBoss EAP インスタンスまたは Elytron クライアントが考えられます。JBoss EAP の SASL 認証メカニズムは、remoting サブシステムとの Elytron 統合 でも大幅に使用されます。

1.7.1. SASL 認証メカニズムの選択

注記

JBoss EAP および Elytron クライアントは、さまざまな SASL 認証メカニズムと連携しますが、使用するメカニズムをサポートする必要があります。SASL 認証メカニズムのサポートレベルのリスト 参照してください。

使用する認証メカニズムは、お使いの環境と認証方法によって異なります。以下の一覧は、対応している SASL 認証メカニズム の一部の使用をまとめています。

ANONYMOUS
認証されていないゲストアクセス。
DIGEST-MD5
HTTP ダイジェスト認証を SASL メカニズムとして使用します。
EXTERNAL
要求のコンテキストで暗示される認証クレデンシャルを使用します。たとえば、IPsec または TLS 認証などです。
GS で始まるメカニズム
Kerberos を使用した認証。
JBOSS-LOCAL-USER
JBoss EAP サーバーを実行しているローカルユーザーと同じファイルアクセスがあることをクライアントがテストして認証を提供します。これは、同じマシンで実行されている他の JBoss EAP インスタンスで便利です。
OAUTHBEARER
OAuth が提供する認証を SASL メカニズムとして使用します。
PLAIN
プレーンテキストのユーザー名およびパスワード認証。
SCRAM で始まるメカニズム
指定されたハッシュ関数を使用する SCRAM (Salted Challenge Response Authentication Mechanism)
-PLUS で終わるメカニズム
特定の認証メカニズムのチャネルバインディングのバリアントを示します。基礎となる接続が SSL/TLS を使用する場合は、これらのバリアントを使用する必要があります。

個別の SASL 認証メカニズムの詳細は、IANA SASL mechanism list and individual mechanism memos を参照してください。

1.7.2. サーバー側での SASL 認証メカニズムの設定

サーバー側での SASL 認証メカニズムの設定は、SASL 認証ファクトリーを使用して行われます。

必要な設定には、以下の 2 つのレベルがあります。

  • 認証メカニズムを指定する sasl-authentication-factory
  • 1 つ異常の sasl-authentication-factory を集約し、メカニズムプロパティーを設定してオプションでフィルターを適用し、特定の認証メカニズムの有効化または無効化を行う configurable-sasl-server-factory

以下の例は、新しい configurable-sasl-server-factory の作成、アプリケーションクライアントの SASL 認証メカニズムとして DIGEST-MD5 を使用する sasl-authentication-factory の作成のデモンストレーションを行っています。

/subsystem=elytron/configurable-sasl-server-factory=mySASLServerFactory:add(sasl-server-factory=elytron)

/subsystem=elytron/sasl-authentication-factory=mySASLAuthFactory:add(sasl-server-factory=mySASLServerFactory,security-domain=ApplicationDomain,mechanism-configurations=[{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=ApplicationRealm}]}])

1.7.3. クライアント側での SASL 認証メカニズムの指定

クライアントで使用される sasl 認証メカニズムは sasl-mechanism-selector で指定されます。クライアントが接続しているサーバーによって公開される、対応の SASL 認証メカニズムをすべて指定できます。

sasl-mechanism-selector は、認証が設定されている Elytron 設定で定義されます。

  • elytron サブシステムでは、これは authentication-configuration の属性です。以下に例を示します。

    /subsystem=elytron/authentication-configuration=myAuthConfig:write-attribute(name=sasl-mechanism-selector,value="DIGEST-MD5")

    sasl-mechanism-selectorauthentication-configuration を使用する例は、Configuring SSL or TLS with elytronに記載されています。

  • Elytron Client の場合、通常 wildfly-config.xml という名前のクライアント設定ファイルの authentication-configurationsconfiguration 要素の下に指定されます。以下に例を示します。

    <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" />
          ...
          </configuration>
        </authentication-configurations>
      </authentication-client>
    </configuration>

Elytron クライアントを使用したクライアント認証の設定 に関する詳細は、アイデンティティー管理の設定方法 を参照してください。

sasl-mechanism-selector Grammar

sasl-mechanism-selector のセレクター文字列には特定の文法があります。

単純な形式では、個別のメカニズムを指定する場合は、その名前をスペースで区切って指定します。たとえば、DIGEST-MD5、SCRAM-SHA-1、および SCRAM-SHA-256 を許可された認証として指定する場合は、文字列 DIGEST-MD5 SCRAM-SHA-1 SCRAM-SHA-256 を使用します。

文法の高度な使用方法は、以下の特別なトークンを使用できます。

  • #ALL: すべてのメカニズム。
  • #FAMILY(NAME): 指定したメカニズムファミリーに属するメカニズム。たとえば、ファミリーは DIGEST、EAP、GS2、SCRAM、または IEC-ISO-9798 のいずれかになります。
  • #PLUS: チャネルバインディングを使用するメカニズム。たとえば、SCRAM-SHA-XXX-PLUS または GS2- を-PLUS とします。
  • #MUTUAL: サーバーを認証するメカニズム。たとえば、サーバーがパスワードを認識していることを証明します。#MUTUAL には、#FAMILY(SCRAM)#FAMILY(GS2) といったファミリーが含まれます。
  • #HASH(ALGORITHM): 指定されたハッシュアルゴリズムを使用するメカニズム。たとえば、アルゴリズムは MD5、SHA-1、SHA-256、SHA-384、SHA-512 などにすることができます。

上記のトークンと名前は、以下の操作および述語でも使用できます。

  • -: 禁止
  • !: 反転
  • &&: および
  • ||: または
  • ==: 等号
  • ?: If
  • #TLS: は、TLS がアクティブであれば true となり、それ以外では false となります。

以下は、sasl-mechanism-selector 文字列およびその意味の例です。

  • #TLS && !#MUTUAL: TLS がアクティブは、相互認証なしのすべてのメカニズム。
  • #ALL -ANONYMOUS: ANONYMOUS を除くすべてのメカニズム
  • SCRAM-SHA-1 SCRAM-SHA-256: 2 つのメカニズムをその順序で追加。
  • (SCRAM-SHA-1 &verbar;&verbar; SCRAM-SHA-256): プロバイダーまたはサーバーが提示する順序でメカニズムを 2 つ追加します。
  • !#HASH(MD5): MD5 ハッシュアルゴリズムを使用しないメカニズム。
  • #FAMILY(DIGEST): 任意のダイジェストメカニズム。

1.7.4. SASL 認証メカニズムプロパティーの設定

サーバーおよびクライアント側の両方で認証方法のプロパティーを設定できます。

  • サーバー側では、configurable-sasl-server-factory で認証方法プロパティーを定義します。以下の例は、com.sun.security.sasl.digest.utf8 プロパティーの値を false で定義します。

    /subsystem=elytron/configurable-sasl-server-factory=mySASLServerFactory:map-put(name=properties,key=com.sun.security.sasl.digest.utf8,value=false)
  • クライアント側では、クライアントの認証設定で認証メカニズムプロパティーを定義します。

    • elytron サブシステムでは、認証メカニズムプロパティーを authentication-configuration に定義します。以下の例は、true の値で wildfly.sasl.local-user. valueFrom-auth プロパティーを定義します。

      /subsystem=elytron/authentication-configuration=myAuthConfig:map-put(name=mechanism-properties,key=wildfly.sasl.local-user.quiet-auth,value=true)
    • Elytron Client の場合、認証メカニズムプロパティーは通常、wildfly-config.xml という名前のクライアント設定ファイルの authentication-configurationsconfiguration 要素で指定されます。以下に例を示します。

      ...
      <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>
          ...
        </configuration>
      </authentication-configurations>
      ...

Java ドキュメンテーションの標準 Java SASL 認証メカニズムプロパティー のリストを表示できます。その他の JBoss EAP 固有の SASL 認証メカニズムプロパティーは、認証メカニズムリファンレンス に一覧表示されています。

1.8. Elytron の ModCluster サブシステムとの統合

elytron サブシステムによって公開されるセキュリティー機能は、SSL/TLS を使用してロードバランサーと通信するように modcluster サブシステムを設定するのに使用できるクライアント ssl-context です。

アプリケーションサーバーとロードバランサー間の通信を保護する場合は、以下を行うためにクライアント ssl-context を定義する必要があります。

  • ロードバランサーの証明書の検証に使用される証明書チェーンを保持するトラストストアを定義する。
  • ロードバランサーの証明書に対して検証を実行するためのトラストマネージャーを定義する。

1.8.1. クライアント SSL コンテキストの定義と ModCluster サブシステムの設定

以下の手順では、トラストストアとトラストマネージャーを設定する必要があります。これらの作成の詳細は、Elytron トラストストアの作成 および Elytron トラストマネージャーの作成 を参照してください。

  1. クライアント SSL コンテキストを作成します。

    この SSL コンテキストは、SSL/TLS を使用してロードバランサーに接続する際に modcluster サブシステムによって使用されます。

    /subsystem=elytron/client-ssl-context=modcluster-client-ssl-context:add(trust-manager=default-trust-manager)
  2. 以下のオプションのいずれかを使用して、新しく作成されたクライアント SSL コンテキストを参照します。

    • ssl-context を設定して modcluster サブシステムを設定します。

      /subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=ssl-context, value=modcluster-client-ssl-context)
    • mod-cluster フィルターの ssl-context 属性を定義して undertow サブシステムを設定します。

      /subsystem=undertow/configuration=filter/mod-cluster=modcluster:write-attribute(name=ssl-context,value=modcluster-client-ssl-context)
  3. サーバーをリロードします。

    reload

modcluster サブシステムを設定し、トラストマネージャーとともに 双方向認証 を使用する場合は、キーマネージャーも設定する必要があります。

  1. キーストアを作成します。

    /subsystem=elytron/key-store=twoWayKS:add(path=/path/to/client.keystore.jks, credential-reference={clear-text=secret},type=JKS)
  2. キーマネージャーを設定します。

    /subsystem=elytron/key-manager=twoWayKM:add(key-store=twoWayKS, algorithm="SunX509", credential-reference={clear-text=secret})
  3. クライアント SSL コンテキストを作成します。

    /subsystem=elytron/client-ssl-context=modcluster-client-ssl-context:add(trust-manager=default-trust-manager, key-manager=twoWayKM)
    注記

    既存のクライアント SSL コンテキストがある場合には、以下のように key-manager を追加できます。

    /subsystem=elytron/client-ssl-context=modcluster-client-ssl-context:write-attribute(name=key-manager, value=twoWayKM)
  4. サーバーをリロードします。

    reload

1.9. Elytron の JGroups サブシステムとの統合

jgroups サブシステムで承認プロトコルまたは暗号化プロトコルを定義するときに elytron サブシステムのコンポーネントが参照されることがあります。これらのプロトコルの設定方法は設定ガイドクラスターのセキュア化 を参照してください。

1.10. Remoting サブシステムとの Elytron の等号

1.10.1. Elytron とリモーティングコネクターの統合

リモーティングコネクターは SASL 認証ファクトリー、ソケットバインディング、およびオプションの SSL コンテキストによって指定されます。特にコネクターの属性は以下のようになります。

sasl-authentication-factory
このコネクターに対する要求の認証に使用する SASL 認証ファクトリーへの参照。このファクトリーの作成に関する詳細は、Elytron 認証ファクトリーの作成を参照してください
socket-binding
コネクターが受信リクエストをリッスンするインターフェイスおよびポートを詳細化しているソケットバインディングへの参照。
ssl-context
このコネクターに使用するサーバー側の SSL コンテキストのオプションの参照。SSL コンテキストには、使用されるサーバーキーマネージャーとトラストマネージャーが含まれます。また、SSL コンテキストは、SSL が必要なインスタンスで定義する必要があります。

たとえば、以下のようにコネクターを追加できます。ここでは、SASL_FACTORY_NAME はすでに定義された認証ファクトリーで、SOCKET_BINDING_NAME は既存のソケットバインディングです。

/subsystem=remoting/connector=CONNECTOR_NAME:add(sasl-authentication-factory=SASL_FACTORY_NAME,socket-binding=SOCKET_BINDING_NAME)

SSL が必要な場合は、以下のように ssl-context 属性を使用して、事前設定された server-ssl-context が参照されることがあります。

/subsystem=remoting/connector=CONNECTOR_NAME:add(sasl-authentication-factory=SASL_FACTORY_NAME,socket-binding=SOCKET_BINDING_NAME,ssl-context=SSL_CONTEXT_NAME)

1.10.1.1. Elytron サブシステムを使用したリモーティングコネクターでの一方向 SSL/TLS の有効化

以下の SASL メカニズムは、SSL/TLS などの外部のセキュアなチャネルへのチャネルバインディングに対応しています。

  • GS2-KRB5-PLUS
  • SCRAM-SHA-1-PLUS
  • SCRAM-SHA-256-PLUS
  • SCRAM-SHA-384-PLUS
  • SCRAM-SHA-512-PLUS

これらのメカニズムを使用するには、カスタム SASL ファクトリー を設定するか、定義済みの SASL 認証ファクトリーのいずれかを変更する必要があります。SASL メカニズムセレクター は、クライアントで使用することで、適切な SASL メカニズムを指定できます。

前提条件

  • キーストア が設定されている。
  • キーマネージャー が設定されている。
  • 定義された キーマネージャー を参照する server-ssl-context が設定されている。

手順

  1. コネクターの socket-binding を作成します。以下のコマンドは、ポート 11199 でリッスンする oneWayBinding バインディングを定義します。

    /socket-binding-group=standard-sockets/socket-binding=oneWayBinding:add(port=11199)
  2. SASL 認証ファクトリー、以前に作成したソケットバインディング、および SSL コンテキストを参照するコネクターを作成します。

    /subsystem=remoting/connector=oneWayConnector:add(sasl-authentication-factory=SASL_FACTORY,socket-binding=oneWayBinding,ssl-context=SSL_CONTEXT)
    重要

    security-realmssl-context両方 が定義されている場合、JBoss EAP は ssl-context によって提供される SSL / TLS 設定を使用します。

  3. サーバー証明書を信頼するようにクライアントを設定します。汎用クライアントの例は、Elytron Client Side One Way Example を参照してください。この例では、クライアントの trust-store を使用して ssl-context を設定します。

1.10.1.2. Elytron サブシステムを使用したリモーティングコネクターの双方向 SSL/TLS の有効化

以下の SASL メカニズムは、SSL/TLS などの外部のセキュアなチャネルへのチャネルバインディングに対応しています。

  • GS2-KRB5-PLUS
  • SCRAM-SHA-1-PLUS
  • SCRAM-SHA-256-PLUS
  • SCRAM-SHA-384-PLUS
  • SCRAM-SHA-512-PLUS

これらのメカニズムを使用するには、カスタム SASL ファクトリー を設定するか、定義済みの SASL 認証ファクトリーのいずれかを変更して、これらのメカニズムを提供できます。SASL メカニズムセレクターは、クライアントで使用することで、適切な SASL メカニズムを指定できます。

前提条件

  • クライアント証明書とサーバー証明書向けにそれぞれ別の キーストアコンポーネント が設定されている。
  • サーバーの key-storekey-manager を設定している。
  • サーバーの trust-storetrust-manager が設定されている。
  • 定義された key-managertrust-manager を参照する server-ssl-context が設定されている。

手順

  1. コネクターの socket-binding を作成します。以下のコマンドは、ポート 11199 でリッスンする twoWayBinding バインディングを定義します。

    /socket-binding-group=standard-sockets/socket-binding=twoWayBinding:add(port=11199)
  2. SASL 認証ファクトリー、以前に作成したソケットバインディング、および SSL コンテキストを参照するコネクターを作成します。

    /subsystem=remoting/connector=twoWayConnector:add(sasl-authentication-factory=SASL_FACTORY,socket-binding=twoWayBinding,ssl-context=SSL_CONTEXT)
    重要

    security-realmssl-context両方 が定義されている場合、JBoss EAP は ssl-context によって提供される SSL / TLS 設定を使用します。

  3. サーバー証明書を信頼するようクライアントを設定し、その証明書をサーバーへ提示します。

    双方向 SSL / TLS 認証を完了するには、信頼されたクライアント証明書をサーバーに提示するようにクライアントを設定する必要があります。たとえば、ブラウザーを使用している場合は、信頼される証明書をブラウザーのトラストストアにインポートする必要があります。汎用クライアントの例は、Elytron Client Side Two Way Example を参照してください。この例では、クライアントの trust-storekey-store を使用して ssl-context を設定します。

双方向 SSL/TLS がリモーティングコネクターで有効化されるようになりました。

1.10.2. リモーティング HTTP コネクターとの Elytron の統合

リモート HTTP 接続は、undertow サブシステムのコネクターと、elytron サブシステムで定義された SASL 認証ファクトリーを参照して指定されます。HTTP コネクターは HTTP アップグレードベースのリモーティングコネクターの設定を利用できるようにします。また、connector-ref 属性によって指定された HTTP リスナーに接続します。

connector の属性は次のとおりです。

connector-ref
事前定義された undertow リスナーへの参照。
sasl-authentication-factory
このコネクターに対する要求の認証に使用する SASL 認証ファクトリーへの参照。このファクトリーの作成に関する詳細は、Elytron 認証ファクトリーの作成を参照してください

たとえば、http-connector は以下のように追加できます。ここでは、CONNECTOR_NAMEundertow リスナーを参照します。また、SASL_FACTORY_NAMEelytron サブシステムにすでに定義された認証ファクトリーです。

/subsystem=remoting/http-connector=HTTP_CONNECTOR_NAME:add(connector-ref=CONNECTOR_NAME,sasl-authentication-factory=SASL_FACTORY_NAME)

1.10.2.1. リモーティング HTTP コネクターでの一方向 SSL の有効化

以下の SASL メカニズムは、SSL/TLS などの外部のセキュアなチャネルへのチャネルバインディングに対応しています。

  • GS2-KRB5-PLUS
  • SCRAM-SHA-1-PLUS
  • SCRAM-SHA-256-PLUS
  • SCRAM-SHA-384-PLUS
  • SCRAM-SHA-512-PLUS

上記のメカニズムのいずれかを使用するには、カスタム SASL ファクトリーを設定してください。または、事前定義された SASL 認証ファクトリーのいずれかを編集することで、これらのメカニズムを提供できます。SASL メカニズムセレクター は、クライアントで使用することで、適切な SASL メカニズムを指定できます。

前提条件

手順

  1. https-listener が SSL 設定でレガシーセキュリティーレルムを使用するように設定されているかどうかを確認します。

    /subsystem=undertow/server=default-server/https-listener=https:read-attribute(name=security-realm)
    {
        "outcome" => "success",
        "result" => "ApplicationRealm"
    }

    上記のコマンドは、https-listener が SSL 設定の ApplicationRealm レガシーセキュリティーレルムを使用するように設定されていることを示しています。undertow は、レガシーセキュリティーレルムと Elytron の ssl-context を同時に参照できないため、レガシーセキュリティーレルムへの参照を削除する必要があります。

    注記

    結果が undefined である場合は、次の手順でセキュリティーレルムへの参照を削除する必要はありません。

  2. レガシーセキュリティーレルムへの参照を削除し、https-listener を Elytron の ssl-context を使用するように更新します。

    注記

    https-listener には、常に security-realm または ssl-context が設定されている必要があります。2 つの設定間で変更する場合は、以下に示すように、コマンドを単一のバッチで実行する必要があります。

    batch
    /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
    /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value=SERVER_SSL_CONTEXT)
    run-batch
  3. HTTPS リスナーおよび SASL 認証ファクトリーを参照する HTTP コネクターを作成します。

    /subsystem=remoting/http-connector=ssl-http-connector:add(connector-ref=https,sasl-authentication-factory=SASL_FACTORY)
  4. サーバーをリロードします。

    reload
  5. サーバー証明書を信頼するようにクライアントを設定します。たとえば、ブラウザーを使用している場合は、信頼される証明書をブラウザーのトラストストアにインポートする必要があります。

1.10.2.2. リモーティング HTTP コネクターでの双方向 SSL/TLS の有効化

以下の SASL メカニズムは、SSL/TLS などの外部のセキュアなチャネルへのチャネルバインディングに対応しています。

  • GS2-KRB5-PLUS
  • SCRAM-SHA-1-PLUS
  • SCRAM-SHA-256-PLUS
  • SCRAM-SHA-384-PLUS
  • SCRAM-SHA-512-PLUS

上記のメカニズムのいずれかを使用するには、カスタム SASL ファクトリーを設定してください。または、事前定義された SASL 認証ファクトリーのいずれかを編集することで、これらのメカニズムを提供できます。SASL メカニズムセレクター は、クライアントで使用することで、適切な SASL メカニズムを指定できます。

前提条件

手順

  1. https-listener が SSL 設定でレガシーセキュリティーレルムを使用するように設定されているかどうかを確認します。

    /subsystem=undertow/server=default-server/https-listener=https:read-attribute(name=security-realm)
    {
        "outcome" => "success",
        "result" => "ApplicationRealm"
    }

    上記のコマンドは、https-listener が SSL 設定の ApplicationRealm レガシーセキュリティーレルムを使用するように設定されていることを示しています。undertow は、レガシーセキュリティーレルムと Elytron の ssl-context を同時に参照できないため、レガシーセキュリティーレルムへの参照を削除する必要があります。

    注記

    結果が undefined である場合は、次の手順でセキュリティーレルムへの参照を削除する必要はありません。

  2. レガシーセキュリティーレルムへの参照を削除し、https-listener を Elytron の ssl-context を使用するように更新します。

    注記

    https-listener には、常に security-realm または ssl-context が設定されている必要があります。2 つの設定間で変更する場合は、以下に示すように、コマンドを単一のバッチで実行する必要があります。

    batch
    /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
    /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value=SERVER_SSL_CONTEXT)
    run-batch
  3. HTTPS リスナーおよび SASL 認証ファクトリーを参照する HTTP コネクターを作成します。

    /subsystem=remoting/http-connector=ssl-http-connector:add(connector-ref=https,sasl-authentication-factory=SASL_FACTORY)
  4. サーバーをリロードします。

    reload
  5. サーバー証明書を信頼するようクライアントを設定し、その証明書をサーバーへ提示します。

    双方向 SSL / TLS 認証を完了するには、信頼されたクライアント証明書をサーバーに提示するようにクライアントを設定する必要があります。たとえば、ブラウザーを使用している場合は、信頼される証明書をブラウザーのトラストストアにインポートする必要があります。

双方向 SSL/TLS がリモーティング HTTP コネクターで有効化されるようになりました。

重要

security-realmssl-context両方 が定義されている場合、JBoss EAP は ssl-context によって提供される SSL / TLS 設定を使用します。

1.10.3. リモーティングアウトバウンドコネクターとの Elytron の統合

リモートアウトバウンド接続は、アウトバウンドソケットバインディングと認証コンテキストによって指定されます。認証コンテキストは、接続に必要なすべてのセキュリティー情報を提供します。特に remote-outbound-connection の属性は以下のようになります。

  • outbound-socket-binding-ref - 接続の宛先アドレスとポートの判断に使用されるアウトバウンドソケットバインディングの名前。
  • authentication-context - 認証設定および定義した SSL コンテキストが含まれる認証コンテキストの参照。これが存在する場合は、接続に必要となります。認証コンテキストの定義の情報は、認証コンテキストの作成 を参照してください。

たとえば、remote-outbound-connection は以下のように追加できます。OUTBOUND_SOCKET_BINDING_NAME は既に定義されている outbound-socket-binding で、AUTHENTICATION_CONTEXT_NAME は、elytron サブシステム設定で既に定義されている authentication-context です。

/subsystem=remoting/remote-outbound-connection=OUTBOUND_CONNECTION_NAME:add(authentication-context=AUTHENTICATION_CONTEXT_NAME, outbound-socket-binding-ref=OUTBOUND_SOCKET_BINDING_NAME)

1.11. SSL/TLS の追加の Elytron コンポーネント

一方向 SSL/TLS および双方向 SSL/TLS の設定に関する基本概念は以下のとおりです。

Elytron は SSL/TLS を設定するための追加のコンポーネントも提供します。

1.11.1. Ldap-key-store の使用

Ldap-key-store を使用すると、LDAP サーバーに保存されているキーストアを使用できます。ldap-key-storekey-store と同じように使用できます。

注記

Jakarta Management ObjectName を使用して LDAP 認証情報を復号化することはできません。代わりに、認証情報は認証情報ストアを使用してセキュア化できます。クレデンシャルストアの詳細は、Elytron のクレデンシャルストア を参照してください。

ldap-key-store を作成して使用するには以下の手順に従います。

  1. dir-context を設定します。

    JBoss EAP から LDAP サーバーに接続するには、URL を指定する dir-context と、サーバーへの接続に使用するプリンシパルを設定する必要があります。

    例: dir-context

    /subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389", principal="uid=admin,ou=system", credential-reference={clear-text="secret"})

  2. ldap-key-store を設定します。

    ldap-key-store を設定する場合は、LDAP サーバーへの接続に使用する dir-context と、LDAP サーバーに保存されているキーストアの検索方法の両方を指定する必要があります。少なくとも、search-path を指定する必要があります。

    例: ldap-key-store

    /subsystem=elytron/ldap-key-store=ldapKS:add(dir-context=exampleDC, search-path="ou=Keystores,dc=wildfly,dc=org")

  3. ldap-key-store を使用します。

    ldap-key-store を定義したら、key-store を使用できるのと同じ場所で使用できます。たとえば、アプリケーションに 1 方向 SSL/TLS および 双方向 SSL/TLS を設定する際には ldap-key-store を使用できます。

ldap-key-store および他の Elytron コンポーネントの属性の完全リストは、Elytron サブシステムのコンポーネント を参照してください。

1.11.2. filtering-key-store の使用

Filtering-key-store を使用すると、既存の key-store からエイリアスのサブセットを公開し、key-store を使用できる場所と同じ場所で使用できます。たとえば、キーストアに alias1alias2、および alias3 が含まれ、alias1 および alias3 のみを公開する必要がある場合は、filtering-key-store を使用することで複数の方法を利用できます。

filtering-key-store を作成するには、以下の手順に従います。

  1. key-store を設定します。

    /subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
  2. filtering-key-store を設定します。

    filtering-key-store を設定するとき、フィルター処理を行う key-store と、key-store からエイリアスをフィルター処理するための alias-filter を指定します。フィルターは、以下のいずれかの形式で指定できます。

    • alias1,alias3: 公開するエイリアスのコンマ区切りの一覧。
    • all:-alias2: 一覧表示されているものを除いた、キーストアのすべてのエイリアスを公開。
    • none:+alias1:+alias3: 一覧表示されるもの以外のエイリアスをキーストアに公開しない。

      この例では、コンマ区切りリストで alias1alias3 を公開します。

      /subsystem=elytron/filtering-key-store=filterKS:add(key-store=myKS, alias-filter="alias1,alias3")
      注記

      alias-filter 属性は、大文字と小文字を区別します。elytronAppServer などの大文字・小文字を合わせたエイリアスまたは大文字のエイリアスの使用は一部のキーストアプロバイダーで認識されない可能性があるため、elytronappserver などの小文字のエイリアスを使用することが推奨されます。

  3. filtering-key-store を使用します。

    filtering-key-store を定義したら、key-store を使用する場所と同じ場所で使用できます。たとえば、アプリケーションに 一方向 SSL/TLS および 双方向 SSL/TLS を設定する際に filtering-key-store を使用できます。

filtering-key-store および他の Elytron コンポーネントの属性の完全リストは、Elytron サブシステムのコンポーネント を参照してください。

1.11.3. キーストアの再読み込み

JBoss EAP に設定されたキーストアは、管理 CLI からリロードできます。これは、キーストアが参照する証明書に変更を加えた場合に便利です。

キーストアをリロードするには、以下を実行します。

/subsystem=elytron/key-store=httpsKS:load

1.11.4. キーマネージャーの再初期化

JBoss EAP で設定された key-manager は管理 CLI から再初期化できます。これは、キーストアリソースによって提供される証明書に変更を加え、サーバーを再起動せずにこの変更を新しい SSL 接続に適用する場合に役に立ちます。

注記

key-store がファイルベースの場合は、最初に読み込む必要があります。

/subsystem=elytron/key-store=httpsKS:load()

key-manager を初期化するには、以下を実行します。

/subsystem=elytron/key-manager=httpsKM:init()

1.11.5. トラストマネージャーの再初期化

管理 CLI または管理コンソールから JBoss EAP で設定された trust-manager を再初期化できます。これは、キーストアリソースによって提供される証明書に変更を加え、サーバーを再起動せずに新しい SSL 接続に変更を適用する必要がある場合に役立ちます。

管理 CLI からの信頼マネージャーの再初期化
注記

key-store がファイルベースの場合は、最初に読み込む必要があります。

/subsystem=elytron/key-store=httpsKS:load()

trust-manager を再初期化するには、以下を実行します。

/subsystem=elytron/trust-manager=httpsTM:init()
管理コンソールからのトラストマネージャーの再初期化
  1. 管理コンソールに移動し、Runtime タブをクリックします。
  2. Monitor 列の Security (Elytron) をクリックします。
  3. Security の列で、SSLView の順にクリックします。
  4. ナビゲーションペインで、Trust Manager をクリックします。
  5. 画面右上の Initialize をクリックして、trust-manager を再初期化します。

1.11.6. キーストアエイリアス

alias は、ストアに保存されているシークレットまたは認証情報を示します。key-store コンポーネントを使用してキーストアを elytron サブシステムに追加する場合は、alias 関連の key-store 操作を使用してキーストアの内容を確認できます。

エイリアスの各種操作は次のとおりです。

  • read-alias - キーストアからエイリアスを読み取ります。
  • read-aliases - キーストアからエイリアスを読み取ります。
  • remove-alias - キーストアからエイリアスを削除します。

たとえば、エイリアスを読み取るには、次を実行します。

/subsystem=elytron/key-store=httpsKS/:read-alias(alias=localhost)

1.11.7. client-ssl-context の使用

client-ssl-context は、JBoss EAP インスタンスが SSL 接続をクライアントとして作成する際に SSL コンテキストを提供するために使用されます (リモーティングで SSL を使用するなど)。

client-ssl-context を作成するには、以下の手順に従います。

  1. 必要に応じて、key-storekey-manager、および trust-manager コンポーネントを作成します。

    双方向 SSL/TLS 接続を確立する場合は、クライアント証明書とサーバー証明書用の別の key-store コンポーネント、クライアント key-store 用の key-manager、およびサーバー key-store 用の trust-manager を作成する必要があります。または、一方向 SSL/TLS 接続を行う場合は、サーバー証明書の key-store と、それを参照する trust-manager を作成する必要があります。キーストアおよびトラストストアの作成例は、Elytron サブシステムを使用してアプリケーションに対して双方向 SSL/TLS を有効化する セクションで参照できます。

  2. client-ssl-context を作成します。

    キーストア、トラストストア、およびその他の必要な設定オプションを参照する client-ssl-context を作成します。

    例: client-ssl-context

    /subsystem=elytron/client-ssl-context=exampleCSC:add(key-manager=clientKM, trust-manager=clientTM, protocols=["TLSv1.2"])

  3. client-ssl-context を参照します。

client-ssl-context および他の Elytron コンポーネントの属性の完全リストは、Elytron サブシステムのコンポーネント を参照してください。

1.11.8. server-ssl-context の使用

server-ssl-context は、サーバー側の SSL コンテキストを提供するために使用されます。SSL コンテキストの通常の設定の他に、暗号化スイートやプロトコルなどの追加項目を設定することが可能です。SSL コンテキストは、設定された追加項目をラップします。

  1. 必要に応じて、key-storekey-manager、および trust-manager コンポーネントを作成します。

    双方向 SSL/TLS 接続を確立する場合は、クライアント証明書とサーバー証明書用の別の key-store コンポーネント、サーバー key-store 用の key-manager、およびサーバー trust-store 用の trust-manager を作成する必要があります。または、一方向 SSL/TLS 接続を行う場合は、サーバー証明書の key-store と、それを参照する key-manager を作成する必要があります。キーストアおよびトラストストアの作成例は、Elytron サブシステムを使用してアプリケーションに対して双方向 SSL/TLS を有効化する セクションで参照できます。

  2. server-ssl-context を作成します。

    キーマネージャー、トラストマネージャー、またはその他の必要な設定オプションを参照する server-ssl-context を以下のオプションのいずれかを使用して作成します。

管理 CLI を使用したサーバー SSL コンテキストの追加
/subsystem=elytron/server-ssl-context=newServerSSLContext:add(key-manager=KEY_MANAGER,protocols=["TLSv1.2"])
重要

対応する HTTPS プロトコルを決定する必要があります。上記のコマンド例は TLSv1.2 を使用します。cipher-suite-filter 引数を使用して、許可される暗号スイートを指定でき、use-cipher-suites-order 引用して、サーバーの暗号スイートの順序を許可します。use-cipher-suites-order 属性はデフォルトで true に設定されます。これは、レガシー security サブシステムの動作とは異なります。その動作は、デフォルトで、クライアント暗号スイートの順序を許可します。

管理コンソールを使用したサーバー SSL コンテキストの追加
  1. 管理コンソールにアクセスします。詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。
  2. Configuration → SubsystemsSecurity (Elytron)Other Settings と選択し、表示 をクリックします。
  3. SSLServer SSL Context の順にクリックし、Add をクリックして新しいサーバー SSL コンテキストを設定します。

server-ssl-context および他の Elytron コンポーネントの属性の完全リストは、Elytron サブシステムのコンポーネント を参照してください。

1.11.9. server-ssl-sni-context の使用

server-ssl-sni-context は、サーバー側の SNI 一致を提供するために使用されます。与えられたホスト名がいずれも一致しない場合のデフォルトとともに、ホスト名を SSL コンテキストに関連付けるためのマッチングルールを利用できます。SSL SNI コンテキストは、undertow サブシステムでコンテキストを定義する場合など、標準のサーバー SSL コンテキストの代わりに使用できます。

  1. 必要に応じて key-storekey-managertrust-manager、および server-ssl-context コンポーネントを作成します。server-ssl-sni-context を作成するには、サーバー SSL コンテキストが定義されている必要があります。
  2. server-ssl-context 要素に一致する情報を提供する server-ssl-sni-context を作成します。デフォルトの SSL コンテキストは、default-ssl-context 属性を使用して指定する必要があります。これは、一致しないホスト名が見つかった場合に使用されます。host-context-map は、さまざまな SSL コンテキストの一致に、コンマ区切りのホスト名一覧を受け入れます。

    /subsystem=elytron/server-ssl-sni-context=SERVER_SSL_SNI_CONTEXT:add(default-ssl-context=DEFAULT_SERVER_SSL_CONTEXT,host-context-map={HOSTNAME=SERVER_SSL_CONTEXT,...})

    以下を使用して server-ssl-sni-context を定義します。これは serverssl SSL コンテキストにデフォルト設定され、www.example.com の着信リクエストを exampleSSL コンテキストに一致させます。

    /subsystem=elytron/server-ssl-sni-context=exampleSNIContext:add(default-ssl-context=serverSSL,host-context-map={www\\.example\\.com=exampleSSL})
注記

ホストのマッチングの属性値は正規表現として機能します。そのため、ドメイン名の区切りに使用されるピリオド (.) をエスケープしてください。

管理コンソールを使用した server-ssl-sni-context の設定
  1. 管理コンソールにアクセスします。詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。
  2. Configuration → SubsystemsSecurity (Elytron)Other Settings と選択し、表示 をクリックします。
  3. SSL → Server SSL SNI Context の順にクリックして、必要な ssl-sni-context を設定します。

Elytron コンポーネントの属性の完全リストは、Elytron サブシステムのコンポーネント を参照してください。

1.11.10. カスタム SSL コンポーネント

elytron サブシステムで SSL/TLS を設定する場合は、以下のコンポーネントのカスタム実装を提供および使用できます。

  • key-store
  • key-manager
  • trust-manager
  • client-ssl-context
  • server-ssl-context
警告

Java Secure Socket Extension (JSSE) の詳しい知識がない場合は、trust-manager 以外のコンポーネントのカスタム実装を提供することは推奨されません。

重要

FIPS を使用する場合は、カスタムトラストマネージャーまたはキーマネージャーを使用できません。これは、FIPS では、セキュリティー上の理由から、これらのマネージャーを JDK に組み込む必要があるためです。同様に、X509 エビデンスを検証する SecurityRealm を実装して、同様の動作を実現できます。

Elytron コンポーネントのカスタム実装を作成する場合、それらは適切な機能と要件を提供する必要があります。機能と要件の詳細は、JBoss EAPセキュリティーアーキテクチャーガイドの 性能および要件 セクションを参照してください。各コンポーネントの実装の詳細は、JDK ベンダーによって提供されます。

1.11.10.1. カスタムコンポーネントの Elytron への追加

以下の手順では、Elytron 内でカスタムコンポーネントを追加する方法について説明します。

  1. カスタムコンポーネントのプロバイダーが含まれる JAR をモジュールとして JBoss EAP に追加し、javax.api などの必要な依存関係を宣言します。

    module add --name=MODULE_NAME --resources=FACTORY_JAR --dependencies=javax.api,DEPENDENCY_LIST
    重要

    module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境では、モジュールを手作業で追加および削除する必要があります。詳細は、JBoss EAP設定ガイドカスタムモジュールの手動作成 および 手作業によるカスタムモジュールの削除 を参照してください。

    テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

    テクノロジープレビュー機能のサポート範囲は、Red Hat カスタマーポータルの テクノロジープレビュー機能のサポート範囲 を参照してください。

  2. コンポーネントが elytron サブシステムに追加されると、java.util.ServiceLoader がプロバイダー検出に使用されます。または、provider-loader を定義してプロバイダーへの参照を指定することもできます。ローダーを作成する方法は 2 つあります。各コンポーネントには、1 つずつのみ実装する必要があります。

    • provider-loader を定義する際にプロバイダーを直接参照します。

      /subsystem=elytron/provider-loader=LOADER_NAME:add(class-names=[CLASS_NAME],module=MODULE_NAME)
    • META-INF/services/java.security.Provider にプロバイダーへの参照を含めます。この参照は、org.kohsuke.metainf-services@MetaInfServices アノテーションを使用する際に自動的に作成されます。この方法を使用する場合は、以下のように provider-loader からモジュールのみを参照する必要があります。

      /subsystem=elytron/provider-loader=LOADER_NAME:add(module=MODULE_NAME)
  3. 定義したプロバイダーを追加および参照するタイプに適切な要素を使用して、カスタムコンポーネントを Elytron の設定に追加します。

    /subsystem=elytron/COMPONENT_NAME=NEW_COMPONENT:add(providers=LOADER_NAME,...)

    たとえば、トラストマネージャーを定義するには、以下のコマンドにあるように trust-manager 要素が使用されます。

    例: カスタム信頼マネージャーの追加

    /subsystem=elytron/trust-manager=newTrustManager:add(algorithm=MyX509,providers=customProvider,key-store=sampleKeystore)

  4. 定義が完了すると、コンポーネントは他の要素から参照できるようになります。

関連情報

1.11.10.2. カスタム Elytron コンポーネントに引数を含める

以下に示すように、クラスが initialize メソッドを実装している場合は、カスタムコンポーネントに引数を含めることができます。

void initialize(final Map<String, String> configuration);

このメソッドにより、定義時にカスタムクラスが設定文字列のセットを受け取ることができます。これらは、コンポーネントを定義する際に configuration 属性を使用して渡されます。たとえば、以下の例では、myValue の値を持つ myAttribute という名前の属性を定義します。

/subsystem=elytron/COMPONENT_NAME=NEW_COMPONENT:add(class-name=CLASS_NAME,module=MODULE_NAME,configuration={myAttribute="myValue"}

1.11.10.3. Elytron でのカスタムトラストマネージャーの使用

カスタムトラストマネージャーを実装することで、Undertow で HTTPS、dir-context で LDAPS を使用する際、または Elytron が SSL 接続に使用される場所において、証明書の検証を拡張できます。このコンポーネントは、サーバーの信頼決定を行います。また、カスタムトラストマネージャーが使用される場合は、これらを実装することが強く推奨されます。

重要

FIPS を使用する場合、カスタムトラストマネージャーは利用できません。これは、FIPS では、セキュリティー上の理由から、これらのマネージャーを JDK に組み込む必要があるためです。同様に、X509 エビデンスを検証する SecurityRealm を実装して、同様の動作を実現できます。

カスタムストラストマネージャーの実装要件

カスタムトラストマネージャーを使用する場合は、以下を実装する必要があります。

  • X509ExtendedTrustManager インターフェイスを実装するトラストマネージャー。
  • TrustManagerFactorySpi を拡張するトラストマネージャーファクトリー。
  • トラストマネージャーファクトリーのプロバイダー。

JBoss EAP に追加するには、プロバイダーを JAR ファイルに含める必要があります。実装されたクラスはモジュールとして JBoss EAP に組み込む必要があります。 クラスはモジュールに置く必要はなく、モジュールの依存関係から読み込むことができます。

実装例

以下の例は、カスタムトラストマネージャーファクトリーをサービスとして登録するプロバイダーを示しています。

例: プロバイダー

import org.kohsuke.MetaInfServices;
import javax.net.ssl.TrustManagerFactory;
import java.security.Provider;
import java.util.Collections;
import java.util.List;
import java.util.Map;

@MetaInfServices(Provider.class)
public class CustomProvider extends Provider {

    public CustomProvider() {
        super("CustomProvider", 1.0, "Demo provider");

        System.out.println("CustomProvider initialization.");

        final List<String> emptyList = Collections.emptyList();
        final Map<String, String> emptyMap = Collections.emptyMap();

        putService(new Service(this, TrustManagerFactory.class.getSimpleName(),"CustomAlgorithm", CustomTrustManagerFactorySpi.class.getName(), emptyList, emptyMap));
    }

}

以下の例は、カスタムトラストマネージャーを示しています。このトラストマネージャーには、クライアントまたはサーバーが信頼できるかどうかを確認するためのオーバーロードメソッドが含まれています。

例: TrustManager

import javax.net.ssl.SSLEngine;
import javax.net.ssl.X509ExtendedTrustManager;
import java.net.Socket;
import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;

public class CustomTrustManager extends X509ExtendedTrustManager {

    public void checkClientTrusted(X509Certificate[] x509Certificates, String s, Socket socket) throws CertificateException {
        // Insert your code here
    }

    public void checkServerTrusted(X509Certificate[] x509Certificates, String s, Socket socket) throws CertificateException {
        // Insert your code here
    }

    public void checkClientTrusted(X509Certificate[] x509Certificates, String s, SSLEngine sslEngine) throws CertificateException {
        // Insert your code here
    }

    public void checkServerTrusted(X509Certificate[] x509Certificates, String s, SSLEngine sslEngine) throws CertificateException {
        // Insert your code here
    }

    public void checkClientTrusted(X509Certificate[] x509Certificates, String s) throws CertificateException {
        // Insert your code here
    }

    public void checkServerTrusted(X509Certificate[] x509Certificates, String s) throws CertificateException {
        // Insert your code here
    }

    public X509Certificate[] getAcceptedIssuers() {
        // Insert your code here
    }

}

以下の例は、トラストマネージャーのインスタンスを返すために使用されるファクトリーです。

例: TrustManagerFactorySpi

import javax.net.ssl.ManagerFactoryParameters;
import javax.net.ssl.TrustManager;
import javax.net.ssl.TrustManagerFactorySpi;
import java.security.InvalidAlgorithmParameterException;
import java.security.KeyStore;
import java.security.KeyStoreException;

public class CustomTrustManagerFactorySpi extends TrustManagerFactorySpi {

    protected void engineInit(KeyStore keyStore) throws KeyStoreException {
        // Insert your code here
    }

    protected void engineInit(ManagerFactoryParameters managerFactoryParameters) throws InvalidAlgorithmParameterException {
        // Insert your code here
    }

    protected CustomTrustManager[] engineGetTrustManagers() {
        // Insert your code here
    }

}

カスタムトラストマネージャーの追加

プロバイダーおよびトラストマネージャーを作成したら、カスタムコンポーネントの Elytron への追加 の手順を使用して elytron サブシステムに追加します。

1.11.11. デフォルトの SSLContext

デプロイメント内で使用されるライブラリーの多くは、確立する接続に SSL 設定が必要になる場合があります。これらのライブラリーは呼び出し元によって設定可能な傾向があります。設定が指定されていない場合、それらはデフォルトの SSLContext をプロセスに使用します。

デフォルトの SSLContext は以下のメソッド呼び出しを使用して利用できます。

javax.net.ssl.SSLContext.getDefault();

デフォルトでは、この SSLContext はシステムプロパティーを使用して設定されます。ただし、elytron サブシステム内では、設定したコンテキストのいずれかを割り当て、デフォルトとして使用するように指定できます。

この機能を使用するには、通常通りに SSLContext を設定します。以下のコマンドを使用することで、デフォルトとして使用する SSLContext を指定できます。

/subsystem=elytron:write-attribute(name=default-ssl-context, value=client-context)

既存のサービスおよびデプロイメントは、これを設定する前にデフォルトの SSLContext をキャッシュする可能性があります。そのため、デプロイメントをアクティベートする前にデフォルトが設定されるようリロードが必要となります。

:reload

default-ssl-context 属性が続いて undefined である場合、標準 API はデフォルトを元に戻すメカニズムを提供しません。この場合、Java プロセスを再起動する必要があります。

/subsystem=elytron:undefine-attribute(name=default-ssl-context)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-restart" => true,
        "process-state" => "restart-required"
    }
}

1.11.12. 証明書失効リストの使用

証明書失効リスト (CRL) に対して証明書を検証する場合は、elytron サブシステムのトラストマネージャーに certificate-revocation-list 属性を使用してこれを設定できます。以下に例を示します。

/subsystem=elytron/trust-manager=TRUST_MANAGER:write-attribute(name=certificate-revocation-list,value={path=/path/to/CRL_FILE.crl.pem}

トラストマネージャーで使用できる属性の詳細は、trust-manager 属性表 を参照してください。

注記

証明書失効リストと証明書の両方の有効性を確認するには、トラストストアに証明書チェーンが含まれている必要があります。トラストストアには、認証局および中間証明書のみを含むエンドエンティティー証明書を含めることができません。

reload-certificate-revocation-list 操作を使用すると、トラストマネージャーに証明書失効リストを再読み込みするよう指示できます。

/subsystem=elytron/trust-manager=TRUST_MANAGER:reload-certificate-revocation-list

1.11.13. 認証局を使用した署名証明書の管理

JBoss EAP 管理 CLI と管理コンソールを使用すると、署名済み証明書を取得および管理できます。これにより、CLI またはコンソールから直接署名済み証明書を作成し、必要なキーストアにインポートできます。

注記

このセクションのコマンドの多くには、認証局のステージング URL を使用するかどうかを示すオプションの staging パラメーターがあります。デフォルト値は false で、テストを支援するように設計されています。このパラメーターは、実稼働環境では有効にしないでください。

Let's Encrypt アカウントの設定

JBoss EAP 7.4 より、Let's Encrypt が唯一対応している認証局となりました。署名付き証明書を管理するには、認証局でアカウントを作成し、以下の情報を指定する必要があります。

  • 認証局アカウントキーのエイリアスを含むキーストア。
  • 認証局のエイリアス。指定されたエイリアスが指定のキーストアに存在しない場合は、エイリアスが作成され、プライベートキーエントリーとして保存されます。
  • 問題が起きた場合に認証局が連絡できる、メールアドレスなどの URL オプションの一覧です。
/subsystem=elytron/certificate-authority-account=CERTIFICATE_ACCOUNT:add(key-store=KEYSTORE,alias=ALIAS,contact-urls=[mailto:EMAIL_ADDRESS])
認証局でアカウントを作成します。

アカウントが設定されたら、サービスの条件に同意して認証局で作成できます。

/subsystem=elytron/certificate-authority-account=CERTIFICATE_ACCOUNT:create-account(agree-to-terms-of-service=true)
認証局でアカウントを作成します。

認証局アカウントオプションは、update-account コマンドを使用して更新できます。

/subsystem=elytron/certificate-authority-account=CERTIFICATE_ACCOUNT:update-account(agree-to-terms-of-service=true)
認証局に関連付けられたアカウントキーの変更

認証局アカウントに関連付けられたキーは、change-account-key コマンドを使用して変更できます。

/subsystem=elytron/certificate-authority-account=CERTIFICATE_ACCOUNT:change-account-key()
認証局を使用したアカウントの非アクティブ化

このアカウントが不要になった場合は、deactivate-account コマンドを使用して非アクティブ化できます。

/subsystem=elytron/certificate-authority-account=CERTIFICATE_ACCOUNT:deactivate-account()
認証局に関連付けられたメタデータを取得します。

アカウントのメタデータは、get-metadata コマンドでクエリーできます。これにより、以下の情報が表示されます。

  • サービス用語への URL。
  • 認証局の Web サイトへの URL。
  • 認証局アカウントの一覧。
  • 外部アカウントが必要であるかどうか。
/subsystem=elytron/certificate-authority-account=CERTIFICATE_ACCOUNT:get-metadata()
管理コンソールを使用した Let's Encrypt アカウントの設定

管理コンソールを使用して Let's Encrypt アカウントを設定するには、以下の手順に従います。

  1. 管理コンソールにアクセスします。

    詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。

  2. Runtime → Host → Security (Elytron)SSL の順に選択し、View をクリックします。
  3. Certificate Auth… をクリックして、Certificate Authority Account ページを開きます。
  4. ラベルの付いたボタンをクリックすると、選択したエイリアスに対して以下の設定を実行できます。

    • Create

      認証局でアカウントを作成します。

    • Deactivate

      選択した認証局アカウントを無効化します。

    • Update

      選択したアカウントを認証局で更新します。

    • Get Metadata

      認証局アカウントについての以下の情報を表示します。

      • 関連するエイリアス
      • 認証局の名前
      • 連絡先の詳細
      • キーストア名
      • 認証局の詳細
    • Change Account Key

      • 認証局で関連する鍵を変更します。

1.11.14. キーストアの操作

管理 CLI および管理コンソールを使用すると、Elytron key-store リソースでさまざまなキーストア操作を実行できます。

管理 CLI を使用したキーストア操作

管理 CLI を使用すると、以下のキーストア操作を実行できます。

  • キーペアを生成します。

    generate-key-pair コマンドは、キーペアを生成し、生成された公開鍵を自己署名の X.509 証明書にラップします。生成された秘密鍵と自己署名証明書がキーストアに追加されます。

    /subsystem=elytron/key-store=httpsKS:add(path=/path/to/server.keystore.jks,credential-reference={clear-text=secret},type=JKS)
    
    /subsystem=elytron/key-store=httpsKS:generate-key-pair(alias=example,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=www.example.com")
  • 証明書の署名要求を生成します。

    generate-certificate-signing-request コマンドは、キーストアから PrivateKeyEntry を使用して PKCS #10 証明書署名要求を生成します。生成される証明書署名要求はファイルに書き込まれます。

    /subsystem=elytron/key-store=httpsKS:generate-certificate-signing-request(alias=example,path=server.csr,relative-to=jboss.server.config.dir,distinguished-name="CN=www.example.com",extensions=[{critical=false,name=KeyUsage,value=digitalSignature}],credential-reference={clear-text=secret})
  • 証明書または証明書チェーンをインポートします。

    Import-certificate コマンドは、ファイルからキーストアのエントリーに、証明書チェーンまたは証明書チェーンをインポートします。

    /subsystem=elytron/key-store=httpsKS:import-certificate(alias=example,path=/path/to/certificate_or_chain/file,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},trust-cacerts=true)
  • 証明書をエクスポートします。

    export-certificate コマンドは、キーストアのエントリーからファイルに証明書をエクスポートします。

    /subsystem=elytron/key-store=httpsKS:export-certificate(alias=example,path=serverCert.cer,relative-to=jboss.server.config.dir,pem=true)
  • エイリアスを変更します。

    change-alias コマンドは、既存のキーストアエントリーを新しいエイリアスに移動します。

    /subsystem=elytron/key-store=httpsKS:change-alias(alias=example,new-alias=newExample,credential-reference={clear-text=secret})
  • キーストアに加えられた変更を保存します。

    store コマンドは、キーストアをサポートするファイルに加えられた変更をすべて保持します。

    /subsystem=elytron/key-store=httpsKS:store()
管理コンソールを使用したキーストア操作

管理コンソールを使用して操作を実行するには、以下を実行します。

  1. 管理コンソールにアクセスします。

    詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。

  2. RuntimeSecurity (Elytron)Stores の順に選択し、View をクリックします。
  3. Key Store をクリックし、キーストア定義ページを開きます。
  4. 必要なキーストア名をクリックします。

    ラベルの付いたボタンをクリックすると、選択したキーストアに対して以下の操作を実行できます。

    • Load

      キーストアをロードまたは再読み込みします。

    • Store

      キーストアをサポートするファイルに加えられた変更が永続化されます。

    • Generate Key Pair

      キーペアを生成し、公開鍵を自己署名の X.509 証明書でラップし、秘密鍵と証明書をキーストアに追加します。

    • Import Certificate

      ファイルからキーストアに証明書チェーンをインポートします。

    • Obtain

      認証局から署名済み証明書を取得し、キーストアに保存します。

1.11.14.1. キーストア認証局の操作

Let's Encrypt アカウントの設定 を行うことで、キーストアで以下の操作を行うことができます。

注記

このセクションのコマンドの多くには、認証局のステージング URL を使用するかどうかを示すオプションの staging パラメーターがあります。デフォルト値は false で、テストを支援するように設計されています。このパラメーターは、実稼働環境では有効にしないでください。

管理 CLI を使用したキーストア認証局の操作

管理 CLI を使用することで、以下のキーストアの認証局操作を実行できます。

  • 署名済み証明書を取得します。

    キーストアに認証局アカウントを定義したら、obtain-certificate コマンドを使用して署名済み証明書を取得し、キーストアに保存できます。認証局のアカウントが存在しない場合は、自動的に作成されます。

    /subsystem=elytron/key-store=KEYSTORE:obtain-certificate(alias=ALIAS,domain-names=[DOMAIN_NAME],certificate-authority-account=CERTIFICATE_ACCOUNT,agree-to-terms-of-service=true,algorithm=RSA,credential-reference={clear-text=secret})
  • 署名付きの証明書を取り消します。

    revoke-certificate コマンドは、認証局が発行した証明書を取り消します。

    /subsystem=elytron/key-store=KEYSTORE:revoke-certificate(alias=ALIAS,certificate-authority-account=CERTIFICATE_ACCOUNT)
  • 署名付き証明書が更新時かどうかを確認します。

    should-renew-certificate コマンドは、証明書が更新時かどうかを確認します。このコマンドは、証明書の期限切れ日数が指定日数を下回る場合に true を返し、それ以外の場合は false を返します。

    以下のコマンドは、次の 7 日間で証明書の有効期限が切れるかどうかを判断します。

    /subsystem=elytron/key-store=KEYSTORE:should-renew-certificate(alias=ALIAS,expiration=7)
管理コンソールを使用したキーストア認証局の操作

管理コンソールを使用して操作を実行するには、以下を実行します。

  1. 管理コンソールにアクセスします。

    詳細は、JBoss EAP設定ガイド 管理コンソール を参照してください。

  2. RuntimeSecurity (Elytron)Stores の順に選択し、View をクリックします。
  3. Key Store をクリックし、キーストア定義ページを開きます。
  4. 必要なキーストア名の隣の Aliases をクリックします。
  5. 必要なエイリアス名をクリックします。

    ラベルの付いたボタンをクリックすると、選択したエイリアスに対して以下の操作を実行できます。

    • Change Alias

      エントリーのエイリアスを変更します。

    • Export Certificate

      キーストアのエントリーからファイルに証明書をエクスポートします。

    • Generate CSR

      証明書の署名要求を生成します。

    • Remove Alias

      選択したエイリアスをキーストアから削除します。

    • Details

      エイリアスに関連付けられた証明書の詳細を表示します。

    • Revoke

      エイリアスに関連付けられた証明書を取り消します。

    • Verify Renew

      関連付けられた証明書の更新時かどうかを判断します。

1.11.15. サブジェクトの別名拡張を使用した X.509 証明書の Evidence Decoder の設定

デフォルトでは、Elytron の X.509 証明書に関連するプリンシパルは証明書のサブジェクト名です。また、X.509 証明書チェーンに関連付けられたプリンシパルは証明書チェーンの最初の証明書のサブジェクト名になります。X.509 証明書のサブジェクトの別名エクステンションをプリンシパルとして使用するように X509-subject-alt-name-evidence-decoder を設定できます。

X.509 証明書および X.509 証明書チェーンのサブジェクトの別名拡張仕様は、RFC 5280 で定義されています。

前提条件

  • クライアント証明書の想定形式が分かっているか、ローカルで利用可能なクライアント証明書がある。

手順

  1. 使用するサブジェクトの別名エクステンションを特定します。

    クライアント証明書がローカルにある場合は、keytool コマンドを使用してサブジェクトの別名の拡張子を表示できます。

    keytool -printcert -file /path/to/certificate/certificate.cert

    サブジェクトの別名の拡張子は、以下のように一覧表示されています。

    SubjectAlternativeName [
       DNS:one.example.org
       IP Address:127.0.0.1
    ]
  2. 識別されたサブジェクトの代替名を使用するために、x509-subject-alt-name-evidence-decoder を作成します。

    /subsystem=elytron/x509-subject-alt-name-evidence-decoder=exampleDnsDecoder:add(alt-name-type=__EXTENSION_TO_USE__)
    • エビデンスデコーダーを使用するには、security-domain で参照します。

      /subsystem=elytron/security-domain=__Security_Domain_Name__:write-attribute(name="evidence-decoder",value="exampleDnsDecoder")

1.11.16. 集約エビデンスデコーダーの設定

2 つ以上のエビデンスデコーダーを組み合わせるように集約エビデンスデコーダーを設定できます。エビデンスデコーダーが null 以外のプリンシパルを返すまで、もしくは試行するエビデンスデコーダーがなくなるまで、設定された順序でエビデンスデコーダーが適用されます。

前提条件

手順

  1. 既存のエビデンスデコーダーから集約エビデンスデコーダーを作成します。

    /subsystem=elytron/aggregate-evidence-decoder=aggregateDecoder:add(evidence-decoders=[__DECODER_1__,__DECODER_2__,...,__DECODER_N__])
    • エビデンスデコーダーを使用するには、セキュリティードメインで参照します。

      /subsystem=elytron/security-domain=__SECURITY_DOMAIN__:write-attribute(name="evidence-decoder",value="aggregateDecoder")

1.11.17. X.500 サブジェクトエビデンスデコーダーの設定

x500-subject-evidence-decoder を設定して、証明書チェーンの最初の証明書からサブジェクトを抽出します。

手順

  • x.500 サブジェクトエビデンスデコーダーを作成します。

    /subsystem=elytron/x500-subject-evidence-decoder=exampleSubjectDecoder:add()

1.11.18. カスタムエビデンスデコーダー実装の使用

Elytron でカスタム org.wildfly.security.auth.server.EvidenceDecoder 実装を使用するには、JBoss EAP にモジュールとして追加します。

手順

  1. カスタム実装クラスを Java Archive (JAR) としてパッケージ化します。
  2. JAR を含む JBoss EAP にモジュールを追加します。

    JBoss EAP にモジュールを追加する方法は、設定ガイドカスタムモジュールの作成 を参照してください。

  3. カスタムエビデンスデコーダーを Elytron に追加します。

    /subsystem=elytron/custom-evidence-decoder=myCustomEvidenceDecoder:add(module=__MODULE_NAME__, class-name=__FULLY_QUALIFIED_CLASS_NAME__)

第2章 管理対象ドメインのセキュア化

管理対象ドメインコントローラーとそのホストコントローラー間の通信のセキュリティーを保護できます。

2.1. ドメインコントローラーのパスワード認証の elytron での設定

マスタードメインコントローラーにユーザーを追加して、スレーブコントローラーがそのユーザーとして認証できるようにする必要があります。スレーブコントローラーは、マスタードメインコントローラーの HTTP インターフェイスで認証を試行します。

手順

  1. マスタードメインコントローラーでユーザーを追加します。ユーザー名、パスワード、その他の設定を追加するには、add-user ユーティリティーを使用します。HTTP インターフェイスが Management RealmElytron セキュリティーレルムで保護されている場合には、Management Realm にユーザーを追加する必要があります。

    注記

    デフォルトのファイルベースのユーザーおよびグループ認証メカニズムを使用している場合は、EAP_HOME/bin/add-user.sh スクリプトを実行してください。

    注記

    add-user ユーティリティーを使ってユーザー情報を追加した後に、サーバーはプロパティーファイルの内容をメモリーにキャッシュします。ただし、サーバーは認証リクエストごとにプロパティーファイルの変更時間を確認し、時間が更新された場合にリロードします。つまり、add-user ユーティリティーによるすべての変更が稼働中のサーバーに即座に適用されることになります。

    注記

    管理ユーザーのレルムのデフォルト名は ManagementRealm です。Add-user ユーティリティーでレルム名の入力を求められた場合には、別のレルムに切り替えていない限り、デフォルトのレルム名を使用する必要があります。

  2. authentication-configuration をスレーブコントローラーに追加します。次の例では、ユーザーが slave、パスワードが password1!slave という名前の authentication-configuration を新たに追加します。

    /host=slave/subsystem=elytron/authentication-configuration=slave:add(authentication-name=slave, credential-reference={clear-text=password1!})
  3. 次の例のように、スレーブコントローラーに authentication-context を追加します。

    /host=slave/subsystem=elytron/authentication-context=slave-context:add(match-rules=[{authentication-configuration=slave}])
  4. 次の例のように、スレーブコントローラーにドメインコントローラーの場所と authentication-context を指定します。

    <domain-controller>
      <remote protocol="remote" host="localhost" port="9990" authentication-context="slave-context"/>
    </domain-controller>

関連情報

  • 管理対象ドメイン操作モードの概念および一般的な設定の詳細は、JBoss EAP設定ガイド ドメイン管理 セクションを参照してください。
  • ユーザーの管理については、JBoss EAPConfiguration GuideManagement Users セクションを参照してください。

2.2. レガシーコアマネジメント認証を用いたドメインコントローラーのパスワード認証の設定

デフォルトでは、Red Hat JBoss Enterprise Application Platform は、マスタードメインコントローラーに接続する各スレーブコントローラーから認証を要求するようにマスタードメインコントローラーを設定します。

スレーブコントローラーを適切な認証情報で設定するための手順です。

手順

  1. マスタードメインコントローラーにユーザーを追加するには、add-user スクリプトを使用します。

    1. マスターが管理インターフェイスをセキュア化するために使用する同じレルムにユーザーが追加されていることを確認します (デフォルトでは ManagementRealm)。
    2. 次の例のように、スレーブユーザーを追加します。また、Is this new user going to be used for one AS process to connect to another AS process? (この新しいユーザーは、ある AS プロセスが別の AS プロセスに接続するために使用されますか ?) という質問に必ず yes を選択します。

      $ EAP_HOME/bin/add-user.sh
      
      What type of user do you wish to add?
       a) Management User (mgmt-users.properties)
       b) Application User (application-users.properties)
      (a): a
      
      Enter the details of the new user to add.
      Using realm 'ManagementRealm' as discovered from the existing property files.
      Username : slave-user
      Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
       - The password should be different from the username
       - The password should not be one of the following restricted values {root, admin, administrator}
       - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
      Password :
      Re-enter Password :
      What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[  ]:
      About to add user 'slave-user' for realm 'ManagementRealm'
      Is this correct yes/no? yes
      Added user 'slave-user' to file '/home/user/EAP-7.4.0/standalone/configuration/mgmt-users.properties'
      Added user 'slave-user' to file '/home/user/EAP-7.4.0/domain/configuration/mgmt-users.properties'
      Added user 'slave-user' with groups  to file '/home/user/EAP-7.4.0/standalone/configuration/mgmt-groups.properties'
      Added user 'slave-user' with groups  to file '/home/user/EAP-7.4.0/domain/configuration/mgmt-groups.properties'
      Is this new user going to be used for one AS process to connect to another AS process?
      e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
      yes/no? yes
      To represent the user add the following to the server-identities definition <secret value="ABCzc3dv11Qx" />
      重要

      ユーザーを追加した後、スクリプトは &lt;secret&gt; 要素を出力します。この要素は次のステップで使用する必要があります。

  2. クレデンシャルを使用するようにスレーブコントローラーを設定します。マスタードメインコントローラーでユーザーを作成した後に、ホスト設定ファイルでそのクレデンシャルを使用するように各スレーブコントローラーを更新する必要があります。たとえば、host.xmlhost-slave.xml などです。

    次の例では、ドメインコントローラーの設定で &lt;remote&gt; 要素にユーザー名を追加しています。さらにこの例では、&lt;remote&gt; 要素のセキュリティー保護に使用するレルムの server-identities&lt;secret&gt; を追加しています。

    注記

    直前の手順でユーザーをマスタードメインコントローラーに追加する時に、ユーザー名と <secret> の両方が取得されていました。

    ...
    <security-realm name="ManagementRealm">
        <server-identities>
            <!-- Replace this with either a base64 password of your own, or use a vault with a vault expression -->
            <secret value="ABCzc3dv11Qx"/>
        </server-identities>
    ...
    <domain-controller>
      <remote security-realm="ManagementRealm" username="slave-user">
          <discovery-options>
              <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9990}"/>
          </discovery-options>
      </remote>
    </domain-controller>

関連情報

  • 管理対象ドメイン操作モードの概念および一般的な設定の詳細は、JBoss EAP設定ガイド ドメイン管理 セクションを参照してください。
  • ユーザーの管理については、JBoss EAPConfiguration GuideManagement Users の項を参照してください。

2.3. Elytron でのドメインコントローラーへの SSL または TLS の設定

マスタードメインコントローラーとホストコントローラー間で相互に通信する際に Secure Sockets Layer (SSL) または Transport Layer Security (TLS) を使用するように管理対象ドメインの JBoss EAP インスタンスを設定できます。

重要

管理対象ドメインの JBoss EAP インスタンス間で使用する SSL または TLS を設定する場合は、対話に応じて各インスタンスにクライアントまたはサーバーのロールを設定できます。これには、すべてのホストコントローラーとドメインコントローラーが含まれます。最適な結果を得るには、エンドポイント間で双方向の SSL または TLS を設定してください。

前提条件

  • 必要なすべての証明書とキーストアを生成して設定しておく。管理インターフェイスで双方向 SSL/TLS を有効にするには、セキュリティーコマンドを使用した双方向 SSL/TLS の有効化 または Elytron サブシステムコマンドを使用した双方向 SSL/TLS の有効化 のいずれかを参照してください。

    注記

    エンドポイント間で双方向 SSL または TLS を設定するには、マスタードメインコントローラーおよび各ホストコントローラーの証明書およびキーストアを生成し、設定する必要があります。

    さらに、マスタードメインコントローラーの証明書を各ホストコントローラーのキーストアにインポートする必要があります。さらに、各ホストコントローラーの証明書をマスタードメインコントローラーの鍵ストアにインポートしてください。

手順

  1. マスタードメインコントローラーでユーザーを追加します。デフォルトのファイルベースのユーザーおよびグループ認証メカニズムを使用している場合は、EAP_HOME/bin/add-user.sh スクリプトを実行してください。プロンプトが表示されたら、ユーザー名、パスワード、およびその他の設定を追加します。

    注記

    管理ユーザーのレルムのデフォルト名は ManagementRealm です。Add-user ユーティリティーでレルム名の入力を求められた場合には、別のレルムに切り替えていない限り、デフォルトのレルム名を使用する必要があります。

    注記

    スレーブコントローラーがユーザーを認証するためには、マスタードメインコントローラーにユーザーを追加する必要があります。

    注記

    サーバーは、メモリー内のプロパティーファイルの内容をキャッシュします。ただし、サーバーは認証リクエストごとにプロパティーファイルの変更時間を確認し、時間が更新された場合にリロードします。このように、add-user ユーティリティーによる変更は、実行中のサーバーに直ちに適用されます。

  2. マスタードメインコントローラーを、SSL または TLS を使用するように設定します。以下の例では、サーバーキーストアとトラストストア向けのドメインコントローラーの key-storekey-managertrust-manager、および server-ssl-context を設定するコマンドを紹介します。

    /host=master/subsystem=elytron/key-store=twoWayKS:add(path=/path/to/server.keystore.jks,credential-reference={clear-text=secret},type=JKS)
    
    /host=master/subsystem=elytron/key-store=twoWayTS:add(path=/path/to/server.truststore.jks,credential-reference={clear-text=secret},type=JKS)
    
    /host=master/subsystem=elytron/key-manager=twoWayKM:add(key-store=twoWayKS,credential-reference={clear-text=secret})
    
    /host=master/subsystem=elytron/trust-manager=twoWayTM:add(key-store=twoWayTS)
    
    /host=master/subsystem=elytron/server-ssl-context=twoWaySSC:add(key-manager=twoWayKM,protocols=["TLSv1.2"],trust-manager=twoWayTM,want-client-auth=true,need-client-auth=true)
    
    /host=master/core-service=management/management-interface=http-interface:write-attribute(name=ssl-context, value=twoWaySSC)
    重要

    Elytron サブシステムはデフォルトで KeyManagerFactory.getDefaultAlgorithm() および TrustManagerFactory.getDefaultAlgorithm() を使用してアルゴリズムを決定するため、Red Hat は前のコマンドでアルゴリズム属性を指定しませんでした。ただし、アルゴリズム属性は指定できます。アルゴリズム属性を指定するには、使用している JDK によるキーマネージャーアルゴリズムを知る必要があります。たとえば、SunJSSE を使用する JDK は、PKIX および SunX509 アルゴリズムを提供します。

    前のコマンドでは、SunX509 をキーマネージャーアルゴリズム属性として指定し、PKIX をトラストマネージャーアルゴリズム属性として指定できます。

    また、使用する HTTPS プロトコルを決定する必要もあります。この手順の例では、TLSv1.2 を使用しています。

    cipher-suite-filter を使用して暗号スイートを指定し、use-cipher-suites-order 引数を使用してサーバーの暗号スイートの順序を優先できます。use-cipher-suites-order 属性はデフォルトで true に設定されます。これは、レガシー security サブシステムの動作とは異なります。その動作は、デフォルトで、クライアント暗号スイートの順序を許可します。

  3. 各スレーブホストコントローラーに認証コンテキストとドメインコントローラーの場所を設定します。以下の設定例では、localhost に存在するドメインコントローラーを示しています。

    注記

    ご利用の環境で正しい管理ユーザー、パスワード、およびドメインコントローラーの場所を指定するようにしてください。

    /host=slave1/subsystem=elytron/authentication-context=slaveHostSSLContext:add()
    
    /host=slave1/subsystem=elytron/authentication-configuration=slaveHostSSLConfiguration:add()
    
    /host=slave1/subsystem=elytron/authentication-configuration=slaveHostSSLConfiguration:write-attribute(name=sasl-mechanism-selector,value=DIGEST-MD5)
    
    /host=slave1/subsystem=elytron/authentication-configuration=slaveHostSSLConfiguration:write-attribute(name=authentication-name,value=slave)
    
    /host=slave1/subsystem=elytron/authentication-configuration=slaveHostSSLConfiguration:write-attribute(name=realm,value=ManagementRealm)
    
    /host=slave1/subsystem=elytron/authentication-configuration=slaveHostSSLConfiguration:write-attribute(name=credential-reference,value={clear-text=password1!})
    
    /host=slave1/subsystem=elytron/authentication-context=slaveHostSSLContext:write-attribute(name=match-rules,value=[{match-host=localhost,authentication-configuration=slaveHostSSLConfiguration}]
    
    /host=slave1:write-remote-domain-controller(host=localhost,port=9990,protocol=remote,authentication-context=slaveHostSSLContext)
  4. 各スレーブホストコントローラーが SSL/TLS を使用するように設定します。以下のコマンドでは、サーバーのキーストアとトラストストアに対して、スレーブホストコントローラーの key-storekey-managertrust-managerclient-ssl-context および authentication-context を設定します。さらに、この例では、localhost に存在するドメインコントローラーを示しています。

    注記

    環境に適したドメインコントローラーの場所を指定するようにしてください。

    /host=slave1/subsystem=elytron/key-store=twoWayKS:add(path=/path/to/client.keystore.jks,credential-reference={clear-text=secret},type=JKS)
    
    /host=slave1/subsystem=elytron/key-store=twoWayTS:add(path=/path/to/client.truststore.jks,credential-reference={clear-text=secret},type=JKS)
    
    /host=slave1/subsystem=elytron/key-manager=twoWayKM:add(key-store=twoWayKS,credential-reference={clear-text=secret})
    
    /host=slave1/subsystem=elytron/trust-manager=twoWayTM:add(key-store=twoWayTS)
    
    /host=slave1/subsystem=elytron/client-ssl-context=twoWayCSC:add(key-manager=twoWayKM,protocols=["TLSv1.2"],trust-manager=twoWayTM)
    
    /host=slave1/subsystem=elytron/authentication-context=slaveHostSSLContext:write-attribute(name=match-rules,value=[{match-host=localhost,authentication-configuration=slaveHostSSLConfiguration,ssl-context=twoWayCSC}])
    重要

    Elytron サブシステムはデフォルトで KeyManagerFactory.getDefaultAlgorithm() および TrustManagerFactory.getDefaultAlgorithm() を使用してアルゴリズムを決定するため、Red Hat は前のコマンドでアルゴリズム属性を指定しませんでした。ただし、アルゴリズム属性は指定できます。アルゴリズム属性を指定するには、使用している JDK によるキーマネージャーアルゴリズムを知る必要があります。たとえば、SunJSSE を使用する JDK は、PKIX および SunX509 アルゴリズムを提供します。

    前のコマンドでは、SunX509 をキーマネージャーアルゴリズム属性として指定し、PKIX をトラストマネージャーアルゴリズム属性として指定できます。

    また、使用する HTTPS プロトコルを決定する必要もあります。この手順の例では、TLSv1.2 を使用しています。

    cipher-suite-filter を使用して暗号スイートを指定し、use-cipher-suites-order 引数を使用してサーバーの暗号スイートの順序を優先できます。use-cipher-suites-order 属性はデフォルトで true に設定されます。これは、レガシー security サブシステムの動作とは異なります。その動作は、デフォルトで、クライアント暗号スイートの順序を許可します。

  5. 管理対象ドメインのすべての JBoss EAP ホストをリロードします。

関連情報

  • 管理対象ドメイン操作モードの概念および一般的な設定の詳細は、JBoss EAP設定ガイド ドメイン管理 セクションを参照してください。
  • ユーザーの管理については、JBoss EAPConfiguration GuideManagement Users の項を参照してください。

2.4. Elytron を使用してドメインモードで SSL を設定する

JBoss EAP 7.1 以降のバージョンでは、Elytron を使用してドメインモードで SSL を設定できます。

前提条件

  • JBoss EAP 7.1 以降
  • Elytron

手順

  1. SSL を有効にする自己署名証明書を作成します。

    keytool -genkey -alias jboss -keysize 2048 -validity 365 -keyalg RSA -sigalg SHA256withRSA -keystore jboss.jks -storepass jboss@123 -keypass jboss@123 -dname "CN=example.com, OU=JavaEE, O=Red Hat, C=IN"
  2. 管理 CLI を使用して keystore、key-manager、および ssl-context を作成します。

    #Configure a keystore
    /profile=<profile-name>/subsystem=elytron/key-store=httpsKS:add(path="${jboss.home.dir}/ssl/jboss.jks", credential-reference={clear-text=jboss@123}, type=JKS)
    
    #Create a new key-manager
    /profile=<profile-name>/subsystem=elytron/key-manager=httpsKM:add(key-store=httpsKS,algorithm="SunX509",credential-reference={clear-text=jboss@123})
    
    #Configure new server-ssl-context reference with protocol and ciphers
    /profile=<profile-name>/subsystem=elytron/server-ssl-context=httpsSSC:add(key-manager=httpsKM,protocols=["TLSv1.2"])
  3. Elytron ssl-context をマップするように undertow サブシステムを設定します。

    batch
    /profile=<profile-name>/subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
    /profile=<profile-name>/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=httpsSSC)
    run-batch
  4. オプション: management-interface を保護して、同じ ssl-context を使用します。

    host-*.xml ファイルは、管理インターフェイスを保持するドメインコントローラーとホストコントローラーの設定を定義します。SSL が正常に設定されていることを確認するには、ホストで ssl-context を再度定義する必要があります。

    #Configure a keystore on the master DC host
    /host=<host-name>/subsystem=elytron/key-store=httpsKS:add(path="${jboss.home.dir}/ssl/jboss.jks", credential-reference={clear-text=jboss@123}, type=JKS)
    
    #Create a new key-manager on the master DC host
    /host=<host-name>/subsystem=elytron/key-manager=httpsKM:add(key-store=httpsKS,algorithm="SunX509",credential-reference={clear-text=jboss@123})
    
    #Configure new server-ssl-context reference with protocol and ciphers on the master DC host
    /host=<host-name>/subsystem=elytron/server-ssl-context=httpsSSC:add(key-manager=httpsKM,protocols=["TLSv1.2"])
    
    #Configure the secure-port and ssl-context for management-http interface  on the master DC host
    /host=<host-name>/core-service=management/management-interface=http-interface:write-attribute(name=ssl-context,value=httpsSSC)
    
    /host=<host-name>/core-service=management/management-interface=http-interface:write-attribute(name=secure-port,value=9993)
  5. リモートホストコントローラーが SSL 経由でドメインコントローラーに接続できるように、トラストストアが適切に設定されていることを確認します。詳細は、Elytron を使用したドメインコントローラーとホストコントローラー間の SSL/TLS の設定 を参照してください。
  6. サーバーをリロードして、変更が有効であることを確認します。

    reload --host=<host-name>

検証

  • Red Hat Enterprise Linux コマンドラインでブラウザーまたは openSSL を使用して、TLS 接続を確認します。

    openssl s_client -connect host:8443

    出力には、使用されている証明書と TLS バージョンに関する情報が表示されます。

    SSL-Session:
    Protocol: TLSv1.2

2.5. レガシーコアマネジメントの認証機構の SSL または TLS 設定

マスタードメインコントローラーとホストコントローラー間で相互に通信する際に Secure Sockets Layer (SSL) または Transport Layer Security (TLS) を使用するように管理対象ドメインの JBoss EAP インスタンスを設定できます。

重要

管理対象ドメインの JBoss EAP インスタンス間で使用する SSL または TLS を設定する場合は、対話に応じて各インスタンスにクライアントまたはサーバーのロールを設定できます。これには、すべてのホストコントローラーとドメインコントローラーが含まれます。最適な結果を得るには、エンドポイント間で双方向の SSL または TLS を設定してください。

前提条件

  • 必要なすべての証明書とキーストアを生成して設定しておく。管理インターフェイスで双方向 SSL/TLS を有効にするには、レガシーコアの管理認証での管理インターフェイスへの双方向 SSL/TLS 設定 を参照してください。

    注記

    エンドポイント間で双方向 SSL または TLS を設定するには、マスタードメインコントローラーおよび各ホストコントローラーの証明書およびキーストアを生成し、設定する必要があります。

    さらに、マスタードメインコントローラーの証明書を各ホストコントローラーのキーストアにインポートする必要があります。さらに、各ホストコントローラーの証明書をマスタードメインコントローラーの鍵ストアにインポートしてください。

手順

  1. 以下の例のように、マスタードメインコントローラーが SSL または TLS を使用するように設定します。すべての証明書とキーストアを設定したら、双方向 SSL/TLS を使用するようにセキュリティーレルムを設定する必要があります。これには、SSL/TLS を使用するようにセキュリティーレルムを設定します。設定されたセキュリティーレルムは、ホストコントローラーとマスタードメインコントローラー間の接続に使用する管理インターフェイスのセキュリティーを確保します。

    注記

    以下のコマンドを、バッチモードまたはサーバー上で実行します。sslサーバーの ID を追加した後は、サーバーをリロードする必要があります。この手順の例では、バッチモードで実行しています。

    batch
    
    /host=master/core-service=management/security-realm=CertificateRealm:add()
    
    /host=master/core-service=management/security-realm=CertificateRealm/server-identity=ssl:add(alias=domaincontroller,keystore-relative-to=jboss.domain.config.dir,keystore-path=domaincontroller.jks,keystore-password=secret)
    
    /host=master/core-service=management/security-realm=CertificateRealm/authentication=truststore:add(keystore-relative-to=jboss.domain.config.dir,keystore-path=domaincontroller.jks,keystore-password=secret)
    
    /host=master/core-service=management/security-realm=CertificateRealm/authentication=local:add(default-user=\$local)
    
    /host=master/core-service=management/security-realm=CertificateRealm/authentication=properties:add(relative-to=jboss.domain.config.dir,path=mgmt-users.properties)
    
    /host=master/core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=CertificateRealm)
    
    run-batch
  2. すべてのホストコントローラーで SSL または TLS を使用するように設定します。

    batch
    
    /host=instance1/core-service=management/security-realm=CertificateRealm:add()
    
    /host=instance1/core-service=management/security-realm=CertificateRealm/server-identity=ssl:add(alias=instance1,keystore-relative-to=jboss.domain.config.dir,keystore-path=instance1.jks,keystore-password=secret)
    
    /host=instance1/core-service=management/security-realm=CertificateRealm/authentication=truststore:add(keystore-relative-to=jboss.domain.config.dir,keystore-path=instance1.jks,keystore-password=secret)
    
    /host=instance1/core-service=management/security-realm=CertificateRealm/authentication=local:add(default-user="\$local")
    
    /host=instance1/core-service=management/security-realm=CertificateRealm/authentication=properties:add(relative-to=jboss.domain.config.dir,path=mgmt-users.properties)
    
    /host=instance1/core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=CertificateRealm)
    
    run-batch
  3. マスタードメインコントローラーの接続に使用するセキュリティーレルムを更新します。ホストコントローラーの設定ファイルの更新は、サーバーが起動していない状態で行う必要があります。たとえば、host.xmlhost-slave.xml などです。

    <domain-controller>
      <remote security-realm="CertificateRealm" username="slave-user">
        <discovery-options>
          <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9990}"/>
        </discovery-options>
      </remote>
    </domain-controller>

関連情報

第3章 サーバーのユーザーと管理インターフェイスのセキュア化

3.1. Elytron でのユーザー認証

3.1.1. デフォルト設定

デフォルトでは、JBoss EAP 管理インターフェイスはレガシーコア管理認証によってセキュア化されます。

例: デフォルト設定

/core-service=management/management-interface=http-interface:read-resource()
{
    "outcome" => "success",
    "result" => {
        "allowed-origins" => undefined,
        "console-enabled" => true,
        "http-authentication-factory" => undefined,
        "http-upgrade" => {"enabled" => true},
        "http-upgrade-enabled" => true,
        "sasl-protocol" => "remote",
        "secure-socket-binding" => undefined,
        "security-realm" => "ManagementRealm",
        "server-name" => undefined,
        "socket-binding" => "management-http",
        "ssl-context" => undefined
    }

JBoss EAP では、管理インターフェイスをセキュアにするために、elytron サブシステムで management-http-authentication および management-sasl-authentication を利用できます。

JBoss EAP をデフォルトの Elytron コンポーネントを使用するように更新するには、以下の手順に従います。

  1. management-http-authentication を使用するように、http-authentication-factory を設定します。

    /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=management-http-authentication)
  2. management-sasl-authentication を使用するように sasl-authentication-factory を設定します。

    /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=management-sasl-authentication)
  3. security-realm の定義を解除します。

    /core-service=management/management-interface=http-interface:undefine-attribute(name=security-realm)
  4. 変更を有効にするには、JBoss EAP をリロードします。
reload

管理インターフェイスのセキュリティーは、elytron サブシステムによって提供されるデフォルトのコンポーネントを使用して保護されるようになりました。

3.1.1.1. Elytron HTTP 認証のデフォルト設定

http で管理インターフェイスにアクセスする場合 (Web ベースの管理コンソールを使用する場合など)、JBoss EAP は management-http-authentication http-authentication-factory を使用します。

/subsystem=elytron/http-authentication-factory=management-http-authentication:read-resource()
{
    "outcome" => "success",
    "result" => {
        "http-server-mechanism-factory" => "global",
        "mechanism-configurations" => [{
            "mechanism-name" => "DIGEST",
            "mechanism-realm-configurations" => [{"realm-name" => "ManagementRealm"}]
        }],
        "security-domain" => "ManagementDomain"
    }
}

management-http-authentication http-authentication-factory は ManagementDomain セキュリティードメインを使用するよう設定されます。

/subsystem=elytron/security-domain=ManagementDomain:read-resource()
{
    "outcome" => "success",
    "result" => {
        "default-realm" => "ManagementRealm",
        "permission-mapper" => "default-permission-mapper",
        "post-realm-principal-transformer" => undefined,
        "pre-realm-principal-transformer" => undefined,
        "principal-decoder" => undefined,
        "realm-mapper" => undefined,
        "realms" => [
            {
                "realm" => "ManagementRealm",
                "role-decoder" => "groups-to-roles"
            },
            {
                "realm" => "local",
                "role-mapper" => "super-user-mapper"
            }
        ],
        "role-mapper" => undefined,
        "trusted-security-domains" => undefined
    }
}

ManagementDomain セキュリティードメインは、プロパティーベースのレルムである ManagementRealm Elytron セキュリティーレルムによってサポートされます。

重要

プロパティーベースのレルムは、サーバーの起動時にのみ読み取られます。サーバーの起動後に、手動または add-user スクリプトを使用して追加したユーザーは、サーバーをリロードする必要があります。このリロードは、管理 CLI から reload コマンドを実行すると実行できます。

reload
/subsystem=elytron/properties-realm=ManagementRealm:read-resource()
{
    "outcome" => "success",
    "result" => {
        "groups-attribute" => "groups",
        "groups-properties" => {
            "path" => "mgmt-groups.properties",
            "relative-to" => "jboss.server.config.dir"
        },
        "plain-text" => false,
        "users-properties" => {
            "path" => "mgmt-users.properties",
            "relative-to" => "jboss.server.config.dir"
        }
    }
}

3.1.1.2. デフォルトの Elytron 管理 CLI 認証

デフォルトでは、管理 CLI (jboss-cli.sh) は remote+http で接続するように設定されます。

例: デフォルトの jboss-cli.xml

<jboss-cli xmlns="urn:jboss:cli:3.1">

    <default-protocol use-legacy-override="true">remote+http</default-protocol>

    <!-- The default controller to connect to when 'connect' command is executed w/o arguments -->
    <default-controller>
        <protocol>remote+http</protocol>
        <host>localhost</host>
        <port>9990</port>
    </default-controller>

これにより、HTTP 経由で接続が確立され、HTTP アップグレードを使用して通信プロトコルが Remoting に変更されます。HTTP アップグレード接続は、sasl-authentication-factory を使用して http-interfacehttp-upgrade セクションでセキュア化されます。

例: デフォルトコンポーネントの設定

/core-service=management/management-interface=http-interface:read-resource()
{
    "outcome" => "success",
    "result" => {
        "allowed-origins" => undefined,
        "console-enabled" => true,
        "http-authentication-factory" => "management-http-authentication",
        "http-upgrade" => {
            "enabled" => true,
            "sasl-authentication-factory" => "management-sasl-authentication"
        },
        "http-upgrade-enabled" => true,
        "sasl-protocol" => "remote",
        "secure-socket-binding" => undefined,
        "security-realm" => undefined,
        "server-name" => undefined,
        "socket-binding" => "management-http",
        "ssl-context" => undefined
    }
}

デフォルトの sasl-authentication-factory は management-sasl-authentication です。

/subsystem=elytron/sasl-authentication-factory=management-sasl-authentication:read-resource()
{
    "outcome" => "success",
    "result" => {
        "mechanism-configurations" => [
            {
                "mechanism-name" => "JBOSS-LOCAL-USER",
                "realm-mapper" => "local"
            },
            {
                "mechanism-name" => "DIGEST-MD5",
                "mechanism-realm-configurations" => [{"realm-name" => "ManagementRealm"}]
            }
        ],
        "sasl-server-factory" => "configured",
        "security-domain" => "ManagementDomain"
    }
}

management-sasl-authentication sasl-authentication-factory は、JBOSS-LOCAL-USERDIGEST-MD5 メカニズムを指定します。

DIGEST-MD5 で使用される ManagementRealm Elytron セキュリティーレルムは management-http-authentication http-authentication-factory で使用されるレルムと同じです。

例: JBOSS-LOCAL-USER レルム

/subsystem=elytron/identity-realm=local:read-resource()
{
    "outcome" => "success",
    "result" => {
        "attribute-name" => undefined,
        "attribute-values" => undefined,
        "identity" => "$local"
    }
}

local Elytron セキュリティーレリムは、ローカルユーザーに対するサイレント認証を処理します。

3.1.2. 新規アイデンティティーストアでの管理インターフェイスのセキュア化

  1. アイデンティティーストアのセキュリティードメインおよびサポートするセキュリティーレルム、デコーダー、またはマッパーを作成します。

    このプロセスについては、JBoss EAP アイデンティティー管理の設定方法Elytron サブシステム を参照してください。たとえば、ファイルシステムベースのアイデンティティーストアを使用して管理インターフェイスのセキュリティーを保護する場合は、ファイルシステムベースのアイデンティティーストアでの認証設定 の手順に従います。

  2. http-authentication-factory または masasl-authentication-factory を作成します。

    例: http-authentication-factory

    /subsystem=elytron/http-authentication-factory=example-http-auth:add(http-server-mechanism-factory=global, security-domain=exampleSD, mechanism-configurations=[{mechanism-name=DIGEST, mechanism-realm-configurations=[{realm-name=exampleManagementRealm}]}])

    例: sasl-authentication-factory

    /subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured, security-domain=exampleSD, mechanism-configurations=[{mechanism-name=DIGEST-MD5, mechanism-realm-configurations=[{realm-name=exampleManagementRealm}]}])

  3. Pattern-filter を configured configurable-sasl-server-factory に追加します。

    例: GSSAPI の Configured configurable-sasl-server-factory への追加

    /subsystem=elytron/configurable-sasl-server-factory=configured:list-add(name=filters, value={pattern-filter=GSSAPI})

    これは任意の手順です。クライアントが HTTP 管理インターフェイスへの接続を試みると、JBoss EAP は HTTP 応答とともに状態コード 401 Unauthorized と、ダイジェストや GSSAPI などのサポートされる認証をリストする一連のヘッダーを返信します。詳細は、JBoss EAPセキュリティーアーキテクチャーHTTP インターフェイスによるローカルおよびリモートクライアント認証 を参照してください。

  4. 管理インターフェイスを更新して、http-authentication-factory または sasl-authentication-factory を使用します。

    例: http-authentication-factory の更新

    /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=example-http-auth)
    
    reload

    例: sasl-authentication-factory の更新

    /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=example-sasl-auth)
    
    reload

    注記

    レガシーのコア管理認証を使用する場合は、http 管理インターフェイスのみを単一のレガシーセキュリティーレルムでセキュアにすることができます。これにより、HTTP および SASL 設定が単一のレガシーセキュリティーレルムに強制的に表示されます。elytron サブシステムを使用する場合は、http-authentication-factorysasl-authentication-factory を別々に設定し、http 管理インターフェイスの HTTP および SASL メカニズムをセキュアにするために個別のセキュリティードメインを使用できます。

注記

レガシーセキュリティーと Elytron で同等の実装を持つ複数の異なる属性が管理インターフェイスで設定されている場合は、Elytron 関連設定のみが使用されます。たとえば、レガシーセキュリティーに security-realm、Elytron に http-authentication-factory が設定されている場合、認証は http-authentication-factory 設定で処理されます。

注記

管理インターフェイスに http-authentication-factory または HTTP インターフェイスの sasl-authentication-factorysecurity-realm の両方が含まれていて、ssl-context が使用されていない場合、認証は Elytron によって処理され、SSL はレガシーセキュリティーレルムによって処理されます。

管理インターフェイスに security-realmssl-context の両方が含まれ、HTTP インターフェイスの http-authentication-factory または sasl-authentication-factory が使用されていない場合、認証はレガシーセキュリティーレルムによって処理され、SSL は Elytron によって処理されます。

3.1.3. サイレント認証の追加

デフォルトでは、JBoss EAP は local セキュリティーレルム経由でのサイレント認証として知られるローカルユーザーの認証メカニズムを提供します。詳細は サイレント認証 の項を参照してください。

サイレント認証は sasl-authentication-factory に追加する必要があります。

サイレント認証を既存の sasl-authentication-factory に追加するには、以下を実行します。

/subsystem=elytron/sasl-authentication-factory=example-sasl-auth:list-add(name=mechanism-configurations, value={mechanism-name=JBOSS-LOCAL-USER, realm-mapper=local})

reload

サイレント認証で sasl-server-factory を新たに作成するには、以下を実行します。

/subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured,security-domain=ManagementDomain,mechanism-configurations=[{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=exampleManagementRealm}]},{mechanism-name=JBOSS-LOCAL-USER, realm-mapper=local}])

reload
注記

上記の例では、既存の ManagementDomain セキュリティードメインを使用していますが、他のセキュリティードメインを作成して使用することも可能です。セキュリティードメインの作成例は、JBoss EAP アイデンティティー管理の設定方法Elytron サブシステム を参照してください。

重要

Elytron セキュリティーが使用され、実際のアイデンティティーに対応しない認証名で JBOSS-LOCAL-USER SASL メカニズムを使用して認証試行を行うと、認証は失敗します。

レガシー security サブシステムを使用すると、JBOSS-LOCAL-USER のカスタムユーザー名を選択できます。ユーザー名を特殊アイデンティティーにマッピングすることで、認証が続行されます。

3.1.4. 認証済み管理ユーザーのアイデンティティーマッピング

elytron サブシステムを使用して管理インターフェイスをセキュアにする場合は、認証されたユーザーのアイデンティティーマッピング用の管理インターフェイスにセキュリティードメインを提供できます。これにより、認証されたユーザーは、管理インターフェイスにログインする際に適切なアイデンティティーとともに表示されます。

アプリケーションサーバーは、複数の種類の管理インターフェイスを公開します。各タイプのインターフェイスは、独立した authentication-factory に関連付けて、そのインターフェイスの認証要件を処理できます。

承認の決定を行うために、現在のセキュリティーアイデンティティーがセキュリティードメインから取得されます。返されたセキュリティーアイデンティティーには、そのセキュリティードメイン内で定義されたルールに基づいたロールマッピングおよびパーミッション割り当てが設定されます。

注記

多くの場合、共通のセキュリティードメインはすべての管理に使用されます。管理インターフェイスの認証および承認決定に使用されるセキュリティーアイデンティティーの取得に使用されます。このような場合、セキュリティードメインは管理インターフェイスの認証ファクトリーと関連付けられ、特別な access=identity を定義する必要はありません。

場合によっては、承認決定のアイデンティティーを取得するために異なるセキュリティードメインが使用されることがあります。ここでは、access=identity リソースが定義されます。これには、承認のためにアイデンティティーを取得するためのセキュリティードメインへの参照が含まれます。

以下の例では、管理インターフェイスを exampleSD Elytron セキュリティードメインでセキュリティー保護し、exampleManagementRealm として公開していることを前提としています。

アイデンティティーマッピングを定義するには、identity リソースを管理インターフェイスに追加します。

例: identity リソースの追加

/core-service=management/access=identity:add(security-domain=exampleSD)

identity リソースを追加すると、管理インターフェイスにアクセスするときに認証済みユーザーのアイデンティティーが表示されます。identity リソースが追加されない場合は、認証に使用されるセキュリティードメインのアイデンティティーが使用されます。

たとえば、user1 として管理 CLI にログインすると、アイデンティティーが適切に表示されます。

例: 管理 CLI から認証されたユーザーの ID の表示

:whoami
{
    "outcome" => "success",
    "result" => {"identity" => {"username" => "user1"}}
}

重要

identity リソースが追加され、レガシーセキュリティーレルムを使用して管理インターフェイスをセキュアにする場合、認証されたユーザーは常に anonymous のアイデンティティーを持ちます。identity リソースが削除されると、レガシーセキュリティーレルムから認証されたユーザーが適切なアイデンティティーとともに表示されます。

管理操作の承認は、access=identity に指定されたドメインであるセキュリティードメインを常に使用します。指定されていない場合は、認証に使用されるドメインになります。ロールマッピングは常にセキュリティードメインのコンテキストで使用されます。

現在のリクエストの identity リソースは、Elytron 設定を使用してマップされたロールのセットを返します。RBAC ベースのロールマッピング定義が使用されている場合、identity リソースのロールはグループとして取得され、管理 RoleMapping にフィードされて現在のリクエストの管理ロールを取得します。

表3.1 各種シナリオで使用する ID

シナリオNo access=identity definitionElytron security-domain を参照する access=identity

レガシーの security-realm を使用する HTTP 管理インターフェイス

接続からのアイデンティティー

サポートされないか、匿名のアイデンティティー

security-domain が関係する elytron HTTP 認証ファクトリーを使用した HTTP 管理インターフェイス

接続からのアイデンティティー

正常にインフローされた場合は、参照される security-domain からのアイデンティティー

レガシー security-realm を使用した HTTP アップグレードを含むネイティブ管理インターフェイス

接続からのアイデンティティー

サポートされないか、匿名のアイデンティティー

security-domain が関係する elytron SASL 認証ファクトリーを使用した、ネイティブ管理 (HTTP アップグレードを含む) インターフェイス

接続からのアイデンティティー

正常にインフローされた場合は、参照される security-domain からのアイデンティティー

注記

identity リソースで使用されるセキュリティードメインが認証からセキュリティードメインを信頼しない場合は、匿名のアイデンティティーが使用されます。

両方が同一のセキュリティーレルムを使用している場合は、identity リソースで使用されるセキュリティードメインは認証からセキュリティードメインを信頼する必要はありません。

信頼されるセキュリティードメインは推移的ではありません。

access=identity リソースが定義されていない場合は、管理インターフェイスに対して認証している際に確立されるアイデンティティーが使用されます。この場合、remoting サブシステム経由の接続またはアプリケーションの使用して確立されたアイデンティティーは使用できなくなります。

access=identity リソースが定義されていても、管理インターフェイスが使用するセキュリティードメインが異なり、インフロー元のドメイン一覧に記載さレテいない場合、アイデンティティーは確立されません。インフローは、認証中に確立されたアイデンティティーを使用して試行されます。この場合、remoting サブシステム経由の接続またはアプリケーションの使用して確立されたアイデンティティーは、この方法でインフローできなくなります。

重要

管理インターフェイスがレガシーセキュリティーレルムを使用してセキュア化された場合、アイデンティティーは複数の異なるセキュリティードメイン間で共有できなくなります。この場合、access=identity リソースを定義することはできません。そのため、認証中に確立されたアイデンティティーを直接使用できます。したがって、PicketBox を使用してセキュア化されたアプリケーションは identity リソースではサポートされていません。

3.1.5. 管理 CLI での Elytron クライアントの使用

管理 CLI は、JBoss EAP に接続する際にセキュリティー情報を提供するために Elytron Client を使用するように設定できます。

  1. Elytron で管理インターフェイスを保護します。

    管理 CLI とともに Elytron クライアントを使用するには、管理インターフェイスを Elytron でセキュアにする必要があります。Elytron で管理インターフェイスをセキュア化する方法の詳細は、Elytron でのユーザー認証 を参照してください。

  2. Elytron クライアント設定ファイルを作成します。

    認証設定が含まれる Elytron クライアント設定ファイルと、その設定を使用するためのルールを作成する必要があります。認証設定の作成の詳細は、JBoss EAP アイデンティティー管理の設定方法設定ファイルのアプローチ を参照してください。

    例: custom-config.xml

    <configuration>
        <authentication-client xmlns="urn:elytron:client:1.2">
            <authentication-rules>
                <rule use-configuration="configuration1">
                    <match-host name="localhost" />
                </rule>
            </authentication-rules>
            <authentication-configurations>
                <configuration name="configuration1">
                    <sasl-mechanism-selector selector="DIGEST-MD5" />
                    <providers>
                      <use-service-loader />
                    </providers>
                    <set-user-name name="user1" />
                    <credentials>
                        <clear-password password="password123" />
                    </credentials>
                    <set-mechanism-realm name="exampleManagementRealm" />
                 </configuration>
            </authentication-configurations>
        </authentication-client>
    </configuration>

  3. 管理 CLI スクリプトで Elytron クライアント設定ファイルを使用します。

    $ ./jboss-cli.sh -c  -Dwildfly.config.url=/path/to/custom-config.xml

3.2. Elytron でのアイデンティティー伝搬および転送

3.2.1. リモート呼び出しのセキュリティーアイデンティティーの伝搬

JBoss EAP 7.1 では、リモーティング呼び出しのためにクライアントからサーバーにセキュリティーアイデンティティーを伝搬するためのサーバーとアプリケーションを簡単に設定できる機能が導入されました。指定のユーザーのセキュリティーアイデンティティー内で実行するようにサーバーコンポーネントを設定することも可能です。

本セクションの例では、セキュリティーアイデンティティーの認証情報を転送する方法を説明します。クライアントとジャカルタエンタープライズビーンズのセキュリティーアイデンティティを、リモートのジャカルタエンタープライズビーンズに伝播します。これは、ユーザーの承認されたロール情報とともにリモート Jakarta Enterprise Beans を呼び出した Principal の名前が含まれる文字列を返します。この例では、以下のコンポーネントで設定されています。

  • 呼び出し元に関する承認情報を返す、すべてのユーザーがアクセスできる単一のメソッドを含むセキュアな Jakarta Enterprise Beans。
  • 1 つのメソッドを含む中間的な Jakarta Enterprise Beans です。リモート接続を利用して、セキュアな Jakarta Enterprise Beans 上でメソッドを呼び出します。
  • 中間的な Jakarta Enterprise Beans を呼び出すリモートのスタンドアロンクライアントアプリケーションです。
  • 認証に使用されるアイデンティティー情報が含まれる META-INF/wildfly-config.xml ファイル。

最初に、サーバーを設定して セキュリティーアイデンティティー伝搬を有効化する 必要があります。次に、リモート Jakarta Enterprise Beans を検索して呼び出すために WildFlyInitialContextFactory を使用する レンプルアプリケーションコードを確認します

セキュリティーの伝搬のためのサーバーの設定
  1. ApplicationDomain を使用するように ejb3 サブシステムを設定します。

    /subsystem=ejb3/application-security-domain=quickstart-domain:add(security-domain=ApplicationDomain)

    これにより、以下の application-security-domain 設定が ejb3 サブシステムに追加されます。

    <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
        ....
        <application-security-domains>
            <application-security-domain name="quickstart-domain" security-domain="ApplicationDomain"/>
        </application-security-domains>
    </subsystem>
  2. PLAIN 認証設定を追加して、プレーンテキストのユーザー名とパスワードと、アウトバウンド接続に使用される認証コンテキストを送信します。アイデンティティー伝搬に対応しているメカニズムのリストは、Mechanisms That Support Security Identity Propagation を参照してください。

    /subsystem=elytron/authentication-configuration=ejb-outbound-configuration:add(security-domain=ApplicationDomain,sasl-mechanism-selector="PLAIN")
    /subsystem=elytron/authentication-context=ejb-outbound-context:add(match-rules=[{authentication-configuration=ejb-outbound-configuration}])

    これにより、以下の authentication-client 設定が elytron サブシステムに追加されます。

    <subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
        <authentication-client>
            <authentication-configuration name="ejb-outbound-configuration" security-domain="ApplicationDomain" sasl-mechanism-selector="PLAIN"/>
            <authentication-context name="ejb-outbound-context">
                <match-rule authentication-configuration="ejb-outbound-configuration"/>
            </authentication-context>
        </authentication-client>
        ....
    </subsystem>
  3. リモート宛先アウトバウンドソケットバインディングを standard-sockets ソケットバインディンググループに追加します。

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=ejb-outbound:add(host=localhost,port=8080)

    これにより、以下の ejb-outbound アウトバウンドソケットバインディングが standard-sockets ソケットバインディンググループに追加されます。

    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        ....
        <outbound-socket-binding name="ejb-outbound">
            <remote-destination host="localhost" port="8080"/>
        </outbound-socket-binding>
    </socket-binding-group>
  4. リモートアウトバウンド接続を追加し、HTTP コネクターに SASL 認証ファクトリーを設定します。

    /subsystem=remoting/remote-outbound-connection=ejb-outbound-connection:add(outbound-socket-binding-ref=ejb-outbound, authentication-context=ejb-outbound-context)
    /subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=sasl-authentication-factory,value=application-sasl-authentication)

    これにより、http-remoting-connector および ejb-outbound-connection 設定が remoting サブシステムに追加されます。

    <subsystem xmlns="urn:jboss:domain:remoting:4.0">
        ....
        <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm" sasl-authentication-factory="application-sasl-authentication"/>
        <outbound-connections>
            <remote-outbound-connection name="ejb-outbound-connection" outbound-socket-binding-ref="ejb-outbound" authentication-context="ejb-outbound-context"/>
        </outbound-connections>
    </subsystem>
  5. Elytron SASL 認証が PLAIN メカニズムを使用するように設定します。

    /subsystem=elytron/sasl-authentication-factory=application-sasl-authentication:write-attribute(name=mechanism-configurations,value=[{mechanism-name=PLAIN},{mechanism-name=JBOSS-LOCAL-USER,realm-mapper=local},{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=ApplicationRealm}]}])

    これにより、以下の application-sasl-authentication 設定が elytron サブシステムに追加されます。

    <subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
        ....
        <sasl>
          ....
          <sasl-authentication-factory name="application-sasl-authentication" sasl-server-factory="configured" security-domain="ApplicationDomain">
              <mechanism-configuration>
                  <mechanism mechanism-name="PLAIN"/>
                  <mechanism mechanism-name="JBOSS-LOCAL-USER" realm-mapper="local"/>
                  <mechanism mechanism-name="DIGEST-MD5">
                      <mechanism-realm realm-name="ApplicationRealm"/>
                  </mechanism>
              </mechanism-configuration>
          </sasl-authentication-factory>
      </sasl>
      ....
    </subsystem>

上記の例のアプリケーションでは、サーバーがセキュリティー伝搬を有効にするために設定されました。

セキュリティーアイデンティティーを伝搬するアプリケーションサンプルコードの確認

サーバー設定でセキュリティーアイデンティティーの伝搬が有効になっていると、Jakarta Enterprise Beans クライアントアプリケーションは WildFlyInitialContextFactory を使用して Jakarta Enterprise Beans プロキシーを検索し、呼び出すことができます。Jakarta Enterprise Beans は、以下で示されているように、クライアント例で認証されたユーザーとして呼び出されます。以下の簡単なコード例は、JBoss EAP 7.4 に同梱される ejb-security-context-propagation クイックスタートから取得されます。セキュリティーアイデンティティーの伝搬の完全な作業例は、クイックスタートを参照してください。

Jakarta Enterprise Beans を別のユーザーとして呼び出すには、コンテキストプロパティーに Context.SECURITY_PRINCIPAL および Context.SECURITY_CREDENTIALS を設定します。

例: リモートクライアント

public class RemoteClient {

    public static void main(String[] args) throws Exception {
        // invoke the intermediate bean using the identity configured in wildfly-config.xml
        invokeIntermediateBean();

        // now lets programmatically setup an authentication context to switch users before invoking the intermediate bean
        AuthenticationConfiguration superUser = AuthenticationConfiguration.empty().setSaslMechanismSelector(SaslMechanismSelector.NONE.addMechanism("PLAIN")).
                useName("superUser").usePassword("superPwd1!");
        final AuthenticationContext authCtx = AuthenticationContext.empty().
                with(MatchRule.ALL, superUser);

        AuthenticationContext.getContextManager().setThreadDefault(authCtx);
        invokeIntermediateBean();
    }

    private static void invokeIntermediateBean() throws Exception {
        final Hashtable<String, String> jndiProperties = new Hashtable<>();
        jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
        jndiProperties.put(Context.PROVIDER_URL, "remote+http://localhost:8080");
        final Context context = new InitialContext(jndiProperties);
        IntermediateEJBRemote intermediate = (IntermediateEJBRemote) context.lookup("ejb:/ejb-security-context-propagation/IntermediateEJB!"
                + IntermediateEJBRemote.class.getName());
        // Call the intermediate EJB
        System.out.println(intermediate.makeRemoteCalls());
    }
}

例: 中間の Jakarta Enterprise Beans

@Stateless
@Remote(IntermediateEJBRemote.class)
@SecurityDomain("quickstart-domain")
@PermitAll
public class IntermediateEJB implements IntermediateEJBRemote {

    @EJB(lookup="ejb:/ejb-security-context-propagation/SecuredEJB!org.jboss.as.quickstarts.ejb_security_context_propagation.SecuredEJBRemote")
    private SecuredEJBRemote remote;

    @Resource
    private EJBContext context;

    public String makeRemoteCalls() {
        try {
            StringBuilder sb = new StringBuilder("** ").
                    append(context.getCallerPrincipal()).
                    append(" * * \n\n");
            sb.append("Remote Security Information: ").
                    append(remote.getSecurityInformation()).
                    append("\n");

            return sb.toString();
        } catch (Exception e) {
            if (e instanceof RuntimeException) {
                throw (RuntimeException) e;
            }
            throw new RuntimeException("Teasting failed.", e);
        }
    }
}

例: セキュアな Jakarta Enterprise Beans

@Stateless
@Remote(SecuredEJBRemote.class)
@SecurityDomain("quickstart-domain")
public class SecuredEJB implements SecuredEJBRemote {

    @Resource
    private SessionContext context;

    @PermitAll
    public String getSecurityInformation() {
        StringBuilder sb = new StringBuilder("[");
        sb.append("Principal=[").
                append(context.getCallerPrincipal().getName()).
                append("], ");
        userInRole("guest", sb).append(", ");
        userInRole("user", sb).append(", ");
        userInRole("admin", sb).append("]");
        return sb.toString();
    }
}

例: wildfly-config.xml ファイル

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <authentication-client xmlns="urn:elytron:client:1.2">
        <authentication-rules>
            <rule use-configuration="default"/>
        </authentication-rules>
        <authentication-configurations>
            <configuration name="default">
                <set-user-name name="quickstartUser"/>
                <credentials>
                    <clear-password password="quickstartPwd1!"/>
                </credentials>
                <sasl-mechanism-selector selector="PLAIN"/>
                <providers>
                    <use-service-loader />
                </providers>
            </configuration>
        </authentication-configurations>
    </authentication-client>
</configuration>

3.2.2. 承認転送モードの使用

Elytron は、認証情報転送の他に、ピア間での信頼できるアイデンティティーの使用をサポートします。これは、以下の場合に役に立ちます。

  • 要件は、ネットワークを介してパスワードを送信できないことです。
  • 認証タイプは、認証情報転送に対応していない ものです。
  • この環境には、伝搬されたリクエストを受信できるシステムを制限する必要があります。

承認転送を使用するには、まず 転送サーバーで認証クライアントを設定し てから、受信サーバーが承認を許可および処理するように設定 します。

転送サーバーでの認証クライアントの設定

承認転送を有効にするには、転送サーバー設定で認証クライアント設定を行う必要があります。

以下の管理 CLI コマンドは、デフォルトの認証クライアント設定を作成し、認証転送を有効にします。必要に応じて、さらに高度なルールベースの選択を設定できます。

例: 認証クライアント設定を作成するための管理 CLI コマンド

/subsystem=elytron/authentication-configuration=forwardit:add(authentication-name=theserver1,security-domain=ApplicationDomain,realm=ApplicationRealm,forwarding-mode=authorization,credential-reference={clear-text=thereallysecretpassword})
/subsystem=elytron/authentication-context=forwardctx:add(match-rules=[{authentication-configuration=forwardit,match-no-user=true}])

以下のコマンドは、以下の authentication-configuration および authentication-context 設定を elytron サブシステムに追加します。

例: 認証クライアント設定

<authentication-client>
    <authentication-configuration name="forwardit" authentication-name="theserver1" security-domain="ApplicationDomain" forwarding-mode="authorization" realm="ApplicationRealm">
        <credential-reference clear-text="thereallysecretpassword"/>
    </authentication-configuration>
    <authentication-context name="forwardctx">
        <match-rule match-no-user="true" authentication-configuration="forwardit"/>
    </authentication-context>
</authentication-client>

転送サーバーがデフォルトの認証ベースのユーザー名と認証情報をを使用する代わりに受信サーバーに接続すると、事前に定義されたサーバーログイン名である theserver1 を使用して信頼関係が確立されます。

受信サーバーでの承認転送の設定

転送を正常に完了するには、受信側のサーバー設定を、転送サーバーによって渡されたアイデンティティーに一致するアイデンティティーで設定する必要があります。この場合、正しい認証情報を使用して、受信側サーバーに server1 という名前のユーザーを設定する必要があります。

また、転送サーバーから渡される theserver1 アイデンティティーのアイデンティティー切り替えを許可するために、elytron サブシステムの RunAs パーミッションマッピングも設定する必要があります。パーミッションマッピングの詳細は、JBoss EAPHow to Configure Server SecurityElytron パーミッションマッパーの作成 を参照してください。

以下のコマンドは、以下の設定を含む auth-forwarding-permission-mapper という名前の simple-permission-mapper を追加します。

  • anonymous ユーザーのパーミッションマッピングこのユーザーにパーミッションがなく、匿名ユーザーがログインできなくなります。
  • theserver1 ユーザーのパーミッションマッピング。このユーザーには、* という RunAsPrincipalPermission パーミッションが割り当てられ、このユーザーに任意のアイデンティティーとして実行するグローバルパーミッションが付与されます。必要に応じて、特定のアイデンティティーにパーミッションを制限できます。
  • その他のすべてのユーザーのパーミッションマッピング。

例: 簡単なパーミッションマッパーを作成する管理 CLI コマンド

/subsystem=elytron/permission-set=run-as-principal-permission:add(permissions=[{class-name="org.wildfly.security.auth.permission.RunAsPrincipalPermission",target-name="*"}])

/subsystem=elytron/simple-permission-mapper=auth-forwarding-permission-mapper:add(permission-mappings=[{principals=["anonymous"]},{principals=["theserver1"],permission-sets=[{permission-set=login-permission},{permission-set=default-permissions},{permission-set=run-as-principal-permission}]},{match-all=true,permission-sets=[{permission-set=login-permission},{permission-set=default-permissions}]}]

このコマンドは、以下の simple-permission-mapper 設定を elytron サブシステムに追加します。

例: 簡単なパーミッションマッパー設定

<mappers>
    <simple-permission-mapper name="auth-forwarding-permission-mapper">
        <permission-mapping>
            <principal name="anonymous"/>
            <!-- No permissions: Deny any permission to anonymous! -->
        </permission-mapping>
        <permission-mapping>
            <principal name="theserver1"/>
            <permission-set name="login-permission"/>
            <permission-set name="default-permissions"/>
            <permission-set name="run-as-principal-permission"/>
        </permission-mapping>
        <permission-mapping match-all="true">
            <permission-set name="login-permission"/>
            <permission-set name="default-permissions"/>
        </permission-mapping>
    </simple-permission-mapper>
</mappers>
<permission-sets>
    <permission-set name="login-permission">
        <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/>
    </permission-set>
    <permission-set name="default-permissions">
        <permission class-name="org.wildfly.extension.batch.jberet.deployment.BatchPermission" module="org.wildfly.extension.batch.jberet" target-name="*"/>
        <permission class-name="org.wildfly.transaction.client.RemoteTransactionPermission" module="org.wildfly.transaction.client"/>
        <permission class-name="org.jboss.ejb.client.RemoteEJBPermission" module="org.jboss.ejb-client"/>
    </permission-set>
    <permission-set name="run-as-principal-permission">
        <permission class-name="org.wildfly.security.auth.permission.RunAsPrincipalPermission" target-name="*"/>
    </permission-set>
</permission-sets>

注記

Login-permission および default-permissions パーミッションセットはすでにデフォルト設定に存在します。

承認の転送後にプリンシパルトランスフォーマーが使用される場合、これらのトランスフォーマーは認証と承認プリンシパルの両方に適用されます。

3.2.3. プリンシパルユーザー名の大文字小文字を変更する ケースプリンシパルトランスフォーマー の作成

elytron サブシステムには、case-principal-transformer のプリンシパルトランスフォーマーがあります。case-principal-transformer を使用して、プリンシパルのユーザー名を大文字または小文字のいずれかに変更できます。

case-principal-transformer 主なトランスフォーマーには、デフォルトで true に設定されている upper-case 属性が含まれています。

case-principal-transformer の使用例として、認証メカニズムを使ってプリンシパルをセキュリティーレルムにマッピングしている場合を見ていきます。レルムマッパーは、マッピングされたプリンシパルを操作して、セキュリティーレルムを特定し、そのアイデンティティの 1 つをロードします。認証メカニズムは、アイデンティティをポストレルムマッピングステージと最終的なプリンシパル変換ステージに渡します。その後、認証メカニズムは、認証目的で ID を検証します。case-principal-transformer プリンシパルトランスフォーマーを使って、マッピングされたプリンシパルの文字の大文字/小文字の形式を変換できます。

手順の例では、セキュリティードメインのコンテキストで case-principal-transformer を使用しています。プリンシパルトランスフォーマーは、以下の認証ポリシーとインラインで使用することもできます。

  • http-authentication-factory
  • sasl-authentication-factory
  • ssl-context
  • aggregate-realm

手順

  1. elytron サブシステムに case-principal-transformer を追加し、ユーザー名に大文字または小文字のどちらを使用するか選択します。

    1. トランスフォーマーのユーザー名を大文字に変更するには、デフォルトの upper-case 属性値を変更しないでください。

      elytron サブシステムに、デフォルトの upper-case 属性設定を定義して、<transformer_name> を追加する例

      /subsystem=elytron/case-principal-transformer=<transformer_name>:add(upper-case="true")

      また、コマンド構文を短縮して、デフォルトの upper-case 属性値を使用することもできます。

      /subsystem=elytron/case-principal-transformer=<transformer_name>:add()
    2. トランスフォーマーのユーザー名を小文字に変更するには、upper-case 属性を false に設定します。

      upper-case 属性を false に設定して elytron サブシステムに追加した &lt;transformer_name&gt; の例。

      /subsystem=elytron/case-principal-transformer=<transformer_name>:add(upper-case="false")

  2. オプション: elytron サブシステムを使用して、プリンシパルトランスフォーマーを設定します。次の例では、elytron サブシステムが提供するデフォルトの Application Domain 設定にプリンシパルトランスフォーマーを設定しています。Elytron は、デフォルトの Application Domain 設定を pre-realm-principal-transformer に適用します。

    /subsystem=elytron/security-domain=ApplicationDomain:write-attribute(name=pre-realm-principal-transformer,value=<transformer_name>)
    注記

    レルムマッパーでのセキュリティーレルムの特定後に、Application Domain 設定を使用する post-realm-principal-transformer を設定できます。

関連情報

3.2.4. セキュリティーアイデンティティーの認証情報の取得

HTTP クライアントなど、発信呼び出しで使用するアイデンティティー認証情報の取得が必要となる場合があります。以下の例は、セキュリティー認証情報をプログラムで取得する方法を示しています。

import org.wildfly.security.auth.server.IdentityCredentials;
import org.wildfly.security.auth.server.SecurityDomain;
import org.wildfly.security.auth.server.SecurityIdentity;
import org.wildfly.security.credential.PasswordCredential;
import org.wildfly.security.password.interfaces.ClearPassword;

SecurityIdentity securityIdentity = null;
ClearPassword password = null;

// Obtain the SecurityDomain for the current deployment.
// The calling code requires the
//     org.wildfly.security.permission.ElytronPermission("getSecurityDomain") permission
//     if running with a security manager.
SecurityDomain securityDomain = SecurityDomain.getCurrent();
if (securityDomain != null) {
    // Obtain the current security identity from the security domain.
    // This always returns an identity, but it could be the representation
    //     of the anonymous identity if no authenticated identity is available.
    securityIdentity = securityDomain.getCurrentSecurityIdentity();
    // The private credentials can be accessed to obtain any credentials delegated to the identity.
    // The calling code requires the
    //     org.wildfly.security.permission.ElytronPermission("getPrivateCredentials")
    //     permission if running with a security manager.
    IdentityCredentials credentials = securityIdentity.getPrivateCredentials();
    if (credentials.contains(PasswordCredential.class)) {
        password = credentials.getCredential(PasswordCredential.class).getPassword(ClearPassword.class);
    }
}

3.2.5. セキュリティー アイデンティティーの伝搬をサポートするメカニズム

以下の SASL メカニズムは、セキュリティー アイデンティティーの伝搬に対応しています。

  • PLAIN
  • OAUTHBEARER
  • GSSAPI
  • GS2-KRB5

以下の HTTP メカニズムは、セキュリティーアイデンティティーの伝搬に対応しています。

  • FORM 1
  • BASIC
  • BEARER_TOKEN
  • SPNEGO

1 FORM 認証は、Web ブラウザーでは自動的に処理されません。このため、HA クラスターで実行するときに FORM 認証を使用する Web アプリケーションでアイデンティティー伝搬を使用することはできません。BASICSPNEGO などの他のメカニズムは、HA クラスター環境でのアイデンティティー伝搬に対応しています。

3.3. Elytron でのアイデンティティーの切り替え

3.3.1. サーバー間の Jakarta Enterprise Beans コールでのアイデンティティの切り替え

デフォルトでは、アプリケーションサーバーにデプロイされた Jakarta Enterprise Beans にリモート呼び出しを行う場合、リモートサーバーの認証に使用されるアイデンティティーはソースサーバーで使用されていたものと同じになります。場合によっては、異なるアイデンティティーのセキュリティーコンテキスト内でリモートセキュアな Jakarta Enterprise Beans を実行することがあります。

Elytron API を使用して、サーバー間の Jakarta Enterprise Beans 呼び出しのアイデンティティーを切り換えることができます。これを実行すると、API 呼び出しでプログラムに従って指定されたアイデンティティーを使用して、接続上で受信されるリクエストは新しいリクエストとして実行されます。

以下のコード例は、リモート Jakarta Enterprise Beans の認証に使用されるアイデンティティーを切り替える方法を示しています。securityDomain.authenticate() メソッドで渡される remoteUsername および remotePassword 引数は、ターゲットサーバーで認証に使用されるアイデンティティーのクレデンシャルです。

例: サーバー間の Jakarta Enterprise Beans コールでのアイデンティティの切り替え

SecurityDomain securityDomain = SecurityDomain.getCurrent();
Callable<T> forwardIdentityCallable = () -> {
    return AuthenticationContext.empty()
            .with(MatchRule.ALL,
                    AuthenticationConfiguration.empty()
                    .setSaslMechanismSelector(SaslMechanismSelector.ALL)
                    .useForwardedIdentity(securityDomain))
            .runCallable(callable);
};

securityDomain.authenticate(remoteUsername, new PasswordGuessEvidence(remotePassword.toCharArray())).runAs(forwardIdentityCallable);

3.4. レガシーのコア管理認証によるユーザー認証

3.4.1. デフォルトのユーザー設定

JBoss EAP のすべての管理インターフェイスはデフォルトでセキュアになります。また、ユーザーはローカルインターフェイスとリモートインターフェイスという 2 つの方法で管理インターフェイスにアクセスできます。これらの認証メカニズムの基本は、JBoss EAPSecurity ArchitectureDefault SecurityJBoss EAP Out of the Box のセクションで説明しています。デフォルトでは、これらのインターフェイスへのアクセスは管理レルムセキュリティーレルムで設定されます。最初に、ローカルインターフェイスが有効になり、JBoss EAP インスタンスを実行するホストマシンへのアクセスになります。リモートアクセスも有効化され、ファイルベースのアイデンティティーストアを使用するように設定されます。デフォルトでは、mgmt-users.properties ファイルを使用してユーザー名とパスワードを保存し、mgmt-groups.properties を使用してユーザーグループ情報を保存します。

ユーザー情報は、EAP_HOME/bin/ ディレクトリーに格納されている adduser スクリプトを使用してこれらのファイルに追加されます。

adduser スクリプトでユーザーを追加するには、以下を実行します。

  1. add-user.sh または add-user.bat コマンドを実行します。
  2. 管理ユーザーまたはアプリケーションユーザーを追加するかどうかを選択します。
  3. ユーザーを追加するレルムを選択します。デフォルトでは、利用可能なレルムは ManagementRealmApplicationRealm のみです。カスタムレルムが追加されると、代わりに手動で名前を入力することができます。
  4. プロンプトが表示されたら、ユーザー名、パスワード、および任意のロールを入力します。変更は、セキュリティーレルムの各プロパティーファイルに書き込まれます。

3.4.2. LDAP での認証の追加

JBoss EAP は、LDAP 認証を使用した管理インターフェイスのセキュア化にも対応しています。LDAP の基本と JBoss EAP での使用は、Red Hat JBoss Enterprise Application Platform 7セキュリティーアーキテクチャーガイドの LDAPLDAP と管理インターフェイスの使用LDAP と ManagementRealm の使用 で説明されています。LDAP 認証を使用して管理インターフェイスをセキュアにする方法の詳細は、JBoss EAP アイデンティティー管理の設定方法LDAP での管理インターフェイスのセキュリティー保護 セクションを参照してください。

3.4.3. 管理インターフェイスのセキュア化での JAAS の使用

JAAS は、JBoss EAP がセキュリティーを管理するために使用する宣言型セキュリティー API です。JAAS と宣言型セキュリティーの詳細は、Red Hat JBoss Enterprise Application Platform Security Architectureガイドの 宣言型セキュリティーと JAAS を参照します。

注記

JBoss EAP インスタンスが ADMIN_ONLY モードで実行されるように設定されていると、JAAS を使用した管理インターフェイスのセキュア化はサポートされません。ADMIN_ONLY モードの詳細は、JBoss EAP設定ガイド JBoss EAP の ADMIN_ONLY モードでの実行 を参照してください。

JAAS を使用して管理インターフェイスに認証するには、以下の手順を実行する必要があります。

  1. セキュリティードメインを作成します。

    この例では、セキュリティードメインが UserRoles ログインモジュールで作成されますが、その他のログインモジュールも使用できます。

    /subsystem=security/security-domain=UsersLMDomain:add(cache-type=default)
    
    /subsystem=security/security-domain=UsersLMDomain/authentication=classic:add
    
    /subsystem=security/security-domain=UsersLMDomain/authentication=classic/login-module=UsersRoles:add(code=UsersRoles, flag=required,module-options=[("usersProperties"=>"users.properties"),("rolesProperties"=>"roles.properties")])
  2. JAAS 認証でセキュリティーレルムを作成します。

    /core-service=management/security-realm=SecurityDomainAuthnRealm:add
    
    /core-service=management/security-realm=SecurityDomainAuthnRealm/authentication=jaas:add(name=UsersLMDomain)
  3. 新しいセキュリティーレルムを使用するように http-interface 管理インターフェイスを更新します。

    /core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=SecurityDomainAuthnRealm)
  4. オプション: グループメンバーシップを割り当てます。

    属性 assign-groups は、セキュリティーレルム内のグループ割り当てに、セキュリティードメインからロードされたユーザーメンバーシップ情報を使用するかどうかを決定します。true に設定すると、グループ割り当ては、RBAC (Role-Based Access Control) に使用されます。

    /core-service=management/security-realm=SecurityDomainAuthnRealm/authentication=jaas:write-attribute(name=assign-groups,value=true)

3.5. ロールベースのアクセス制御

ロールベースのアクセス制御の基本は、JBoss EAPSecurity Architectureガイドの ロールベースのアクセス制御管理インターフェイスへの RBAC の追加 で説明されています。

3.5.1. ロールベースのアクセス制御の有効化

デフォルトでは、Role-Based Access Control (RBAC) システムが無効になっています。有効にするには、provider 属性を simple から rbac に変更します。provider は、management 要素の access-control 要素の属性です。これは、管理 CLI を使用するか、サーバーがオフラインの場合にはサーバー設定 XML ファイルを編集して実行できます。稼働中のサーバーで RBAC を無効化または有効化した場合、サーバー設定をリロードして変更を反映する必要があります。

警告

プロバイダーを rbac に変更する前に、RBAC ロールのいずれかにマッピングされるユーザーを含めるようにしてください (Administrator または SuperUser ロールのいずれかが望ましい)。シャットダウンして XML 設定を編集する以外に、インストールを管理する方法はありません。JBoss EAP に同梱される標準 XML 設定のいずれかで開始した場合、$local ユーザーは SuperUser ロールにマッピングされ、local 認証スキームが有効になります。これにより、JBoss EAP プロセスと同じシステムで CLI を実行するユーザーに、完全な管理パーミッションを付与できます。リモート CLI ユーザーと Web ベースの管理コンソールユーザーには、パーミッションが与えられません。

プロバイダーを rbac に切り替える前に、$local 以外のユーザーをマッピングすることが推奨されます。プロバイダーが simple に設定されている場合でも、rbac プロバイダーに関連付けられたすべての設定を実行できます。

一度有効にすると、無効化できるのは Administrator または SuperUser ロールのユーザーのみとなります。デフォルトでは、サーバーと同じマシンで実行される場合、管理 CLI は SuperUser ロールとして実行されます。

RBAC を有効化する CLI

管理 CLI で RBAC を有効にするには、アクセス承認リソースの write-attribute 操作で provider 属性を rbac に設定します。

/core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

reload

管理対象ドメインでは、アクセス制御設定はドメイン全体の設定の一部です。そのため、リソースアドレスは上記のリソースアドレスと同じですが、管理 CLI はマスタードメインコントローラーに接続されます。

/core-service=management/access=authorization:write-attribute(name=provider,value=rbac)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    },
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {
            "outcome" => "success",
            "response-headers" => {
                "operation-requires-reload" => true,
                "process-state" => "reload-required"
            }
        }},
        "server-two" => {"response" => {
            "outcome" => "success",
            "response-headers" => {
                "operation-requires-reload" => true,
                "process-state" => "reload-required"
            }
        }}
    }}}}
}

reload --host=master
注記

スタンドアロンサーバーと同様に、変更を有効にするには、リロードまたは再起動が必要です。管理対象ドメインでは、ドメインのすべてのホストおよびサーバーは、マスタードメインコントローラーから、リロードまたは再起動する必要があります。

RBAC を無効にする管理 CLI コマンド

管理 CLI で RBAC を無効化にするには、アクセス承認リソースの write-attribute 操作で provider 属性を simple に設定します。

/core-service=management/access=authorization:write-attribute(name=provider, value=simple)
RBAC を有効または無効にする XML 設定

サーバーがオフラインの場合、XML 設定を編集して RBAC を有効または無効にすることができます。これを行うには、管理要素の access-control 要素の provider 属性を編集します。この値を rbac に設定して有効にし、simple で無効にします。

例: RBAC を有効または無効にする XML 設定

<management>
  <access-control provider="rbac">
    <role-mapping>
      <role name="SuperUser">
        <include>
          <user name="$local"/>
        </include>
      </role>
    </role-mapping>
  </access-control>
</management>

3.5.2. Permission Combination Policy の変更

Permission Combination Policy は、ユーザーが複数のロールが割り当てられているかどうかの判断方法を決定します。permissive または reject に設定できます。デフォルトは permissive です。

permissive に設定すると、アクションを許可するユーザーにロールが割り当てられていると、そのアクションが許可されます。

rejecting に設定すると、複数のロールがユーザーに割り当てられている場合、アクションは許可されません。つまり、このポリシーが rejecting に設定されていると、各ユーザーには単一のロールのみを割り当てる必要があります。ポリシーが rejecting に設定されている場合、複数のロールを持つユーザーは管理コンソールまたは管理 CLI を使用できません。

Permission Combination Policy は、permission-combination-policy 属性を permissive または rejecting のいずれかに設定して設定します。これは、管理 CLI を使用するか、サーバーがオフラインの場合にはサーバー設定 XML ファイルを編集して実行できます。Permission-combination-policy 属性は access-control 要素の一部で、access-control 要素は management 要素にあります。

Permission Combination Policy の設定

アクセス承認リソースの write-attribute 操作を使用して、permission-combination-policy 属性を必要なポリシー名に設定します。

/core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=POLICYNAME)

有効なポリシー名は rejecting および permissive になります。

例: Permission Combination Policy を拒否する管理 CLI コマンド

/core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=rejecting)

サーバーがオフラインの場合、XML 設定を編集してパーミッションの組み合わせポリシー (permission combination policy) 値を変更できます。これを行うには、access-control 要素の permission-combination-policy 属性を編集します。

例: Permission Combination Policy を拒否する XML 設定

<access-control provider="rbac" permission-combination-policy="rejecting">
  <role-mapping>
    <role name="SuperUser">
      <include>
        <user name="$local"/>
      </include>
    </role>
  </role-mapping>
</access-control>

3.5.3. ロールの管理

RBAC (Role-Based Access Control) を有効にすると、管理ユーザーが許可されている内容は、ユーザーが割り当てられているロールによって決まります。JBoss EAP 7 は、ユーザーおよびグループメンバーシップの両方に基づた包含と除外のシステムを使用して、ユーザーが所属するロールを決定します。

ユーザーは、以下の場合にロールに割り当てられると見なされます。

  • ロールに含めるユーザーとして一覧表示される、または
  • ロールに含まれるように一覧表示されるグループのメンバー。

また、ユーザーが以下を実行しない場合、ユーザーはロールに割り当てられると見なされます。

  • ロールから除外するユーザーとして一覧、または
  • ロールから除外される一覧のグループのメンバーです。

除外は包含よりも優先されます。

ユーザーおよびグループのロール包含および除外の設定は、管理コンソールと管理 CLI の両方を使用して設定できます。

この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。

3.5.3.1. 管理 CLI を使用したユーザーロール割り当ての設定

ユーザーおよびグループのロールへのマッピングの設定は、role-mapping 要素として /core-service=management/access=authorization に位置します。

この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。

ロール割り当て設定の表示

read-children-names 操作を使用して、設定されたロールの完全なリストを取得します。

/core-service=management/access=authorization:read-children-names(child-type=role-mapping)
{
    "outcome" => "success",
    "result" => [
        "Administrator",
        "Deployer",
        "Maintainer",
        "Monitor",
        "Operator",
        "SuperUser"
    ]
}

指定した role-mapping の read-resource 操作を使用して、特定のロールの完全な詳細を取得します。

/core-service=management/access=authorization/role-mapping=ROLENAME: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"
            }
        }
    }
}
新規ロールの追加

この手順では、ロールの role-mapping エントリーを追加する方法を説明します。これは、ロールを設定する前に行う必要があります。

add 操作で、新しいロール設定を追加します。

/core-service=management/access=authorization/role-mapping=ROLENAME:add

ROLENAME は、Auditor などの新規マッピングに使用されるロールの名前です。

例: 新規ロール設定の管理 CLI コマンド

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

ロールに含まれるユーザーの追加

この手順では、ロールの、含まれる一覧にユーザーを追加する方法を説明します。

ロールの設定が行われていない場合は、そのロールの role-mapping エントリーを最初に実行する必要があります。

add 操作を使用して、ロール、追加一覧にユーザーエントリーを追加します。

/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)
  • ROLENAME は、Auditor などの、設定されるているロールの名前です。
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、user-USERNAME (例: user-max) などのエイリアスの命名規則を使用することを推奨します。
  • username は、max などの包含リストに追加されるユーザーの名前です。

例: ロールに含まれるユーザーの管理 CLI コマンド

/core-service=management/access=authorization/role-mapping=Auditor/include=user-max:add(name=max, type=USER)

ユーザーをロールで除外したものとして追加

この手順では、ロールの除外リストにユーザーを追加する方法を説明します。

ロールの設定が行われていない場合は、そのロールの role-mapping エントリーを最初に実行する必要があります。

add 操作を使用して、ロールの除外リストにユーザーエントリーを追加します。

/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=USERNAME, type=USER)
  • ROLENAME は、Auditor などの、設定されるているロールの名前です。
  • USERNAME は、max などの除外リストに追加されているユーザーの名前です。
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、user-USERNAME (例: user-max) などのエイリアスの命名規則を使用することを推奨します。

例: ロールで除外される管理 CLI コマンドユーザー

/core-service=management/access=authorization/role-mapping=Auditor/exclude=user-max:add(name=max, type=USER)

ユーザーロール包含設定の削除

この手順では、ロールマッピングからユーザー包含エントリーを削除する方法を説明します。

remove 操作を使用してエントリーを削除します。

/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
  • ROLENAME は、Auditor などの、設定されるているロールの名前です。
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、user-USERNAME (例: user-max) などのエイリアスの命名規則を使用することを推奨します。

例: ユーザーロールの包含設定を削除する管理 CLI コマンド

/core-service=management/access=authorization/role-mapping=Auditor/include=user-max:remove

注記

包含の一覧からユーザーを削除しても、ユーザーはシステムから削除されません。また、ロールがそのユーザーに割り当てられないようにします。ロールはグループメンバーシップに基づいて依然として割り当てられる可能性があります。

ユーザーロール除外の設定の削除

この手順では、ロールマッピングからユーザー除外エントリーを削除する方法を説明します。

削除操作でエントリーを削除します。

/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
  • ROLENAME は、Auditor などの、設定されるているロールの名前です。
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、user-USERNAME (例: user-max) などのエイリアスの命名規則を使用することを推奨します。
/core-service=management/access=authorization/role-mapping=Auditor/exclude=user-max:remove
注記

除外の一覧からユーザーを削除しても、ユーザーはシステムから削除されません。また、そのロールが必ずそのユーザーに割り当てられるようになるわけではありません。依然としてロールはグループメンバーシップに基づいて除外される可能性があります。

3.5.4. Elytron サブシステムを使用したユーザーロール割り当ての設定

ロールの管理セクションで説明しているように、ユーザーのロールマッピングを直接追加することに加え、elytron サブシステムによって提供されるアイデンティティーから直接取得されるように RBAC ロールを設定することもできます。

RBAC システムを設定して elytron サブシステムによって提供されるロールを使用するには、以下を実行します。

/core-service=management/access=authorization:write-attribute(name=use-identity-roles,value=true)
重要

この機能を使用するには RBAC が有効にされており、プリンシパルには RBAC ロールがなければなりません。

3.5.5. ロールおよびユーザーグループ

ユーザーグループは、1 人以上のユーザーに割り当てることのできる任意のラベルです。管理インターフェイスを使用して認証を行う場合、管理インターフェイスのセキュア化方法に応じて、ユーザーには elytron サブシステムまたはコア管理認証のいずれかからグループが割り当てられます。RBAC システムは、所属するユーザーグループに応じて、自動的にロールをユーザーに割り当てるように設定できます。また、グループメンバーシップに基づいてロールからユーザーを除外することもできます。

3.5.6. 管理 CLI を使用したグループロール割り当ての設定

ロールに含まれる、またはロールから除外されるグループは、管理コンソールおよび管理 CLI で設定できます。このトピックでは、管理 CLI の使用についてのみ説明します。

ユーザーおよびグループのロールへのマッピングの設定は、role-mapping 要素として /core-service=management/access=authorization の管理 API に位置します。

この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。

グループロール割り当て設定の表示

read-children-names 操作を使用して、設定されたロールの完全なリストを取得します。

/core-service=management/access=authorization:read-children-names(child-type=role-mapping)
{
    "outcome" => "success",
    "result" => [
        "Administrator",
        "Deployer",
        "Maintainer",
        "Monitor",
        "Operator",
        "SuperUser"
    ]
}

指定した role-mapping の read-resource 操作を使用して、特定のロールの完全な詳細を取得します。

/core-service=management/access=authorization/role-mapping=ROLENAME: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"
            }
        }
    }
}
新規ロールの追加

この手順では、ロールの role-mapping エントリーを追加する方法を説明します。これは、ロールを設定する前に行う必要があります。

add 操作で、新しいロール設定を追加します。

/core-service=management/access=authorization/role-mapping=ROLENAME:add
ロールに含まれるグループの追加

この手順では、ロールの包含リストにグループを追加する方法を説明します。

ロールの設定が行われていない場合は、そのロールの role-mapping エントリーを最初に実行する必要があります。

add 操作を使用して、ロール、追加一覧にグループエントリーを追加します。

/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=GROUPNAME, type=GROUP)
  • ROLENAME は、Auditor などの、設定されるているロールの名前です。
  • GROUPNAME は、investigators など、包含リストに追加されるグループの名前です。
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、group-GROUPNAME (例: group-investigators) などのエイリアスの命名規則を使用することを推奨します。

例: ロールに含まれるグループを追加する管理 CLI コマンド

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

ロールの除外としてグループを追加

この手順では、ロールの除外リストにグループを追加する方法を説明します。

ロールの設定が行われていない場合は、そのロールの role-mapping エントリーを最初に作成する必要があります。

add 操作を使用して、ロールの除外一覧にグループエントリーを追加します。

/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=GROUPNAME, type=GROUP)
  • ROLENAME は、Auditor などの、設定されるているロールの名前です。
  • GROUPNAME は、supervisors など、包含リストに追加されるグループの名前です。
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、group-GROUPNAME (例: group-supervisors) などのエイリアスの命名規則を使用することを推奨します。

例: ロールの除外としてグループを追加する管理 CLI コマンド

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

グループロール包含設定の削除

この手順では、ロールマッピングからグループ包含エントリーを削除する方法を説明します。

remove 操作を使用してエントリーを削除します。

/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
  • ROLENAME は、Auditor などの、設定されるているロールの名前です。
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、group-GROUPNAME (例: group-investigators) などのエイリアスの命名規則を使用することを推奨します。

例: グループロールの包含設定を削除する管理 CLI コマンド

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

注記

包含の一覧からグループを削除しても、グループはシステムから削除されません。また、ロールがこのグループのユーザーに割り当てられないようにします。このロールは、引き続きグループのユーザーに割り当てられます。

ユーザーグループ除外エントリーの削除

この手順では、ロールマッピングからグループ除外エントリーを削除する方法を説明します。

remove 操作を使用してエントリーを削除します。

/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
  • ROLENAME は、Auditor などの、設定されるているロールの名前です。
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、group-GROUPNAME (例: group-supervisors) などのエイリアスの命名規則を使用することを推奨します。
/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-supervisors:remove
注記

除外の一覧からグループを削除しても、システムからそのグループは削除されません。また、ロールがグループのメンバーに割り当てられることを保証する訳ではありません。依然としてロールはグループメンバーシップに基づいて除外される可能性があります。

3.5.7. LDAP での RBAC の使用

LDAP で RBAC を使用する基本と、JBoss EAP が LDAP で RBAC を使用するよう設定する方法は、JBoss EAP アイデンティティー管理の設定方法LDAP および RBAC セクションを参照してください。

3.5.8. スコープ指定されたロール

スコープ指定されたロールは、標準的なロールのパーミッションを付与するユーザー定義のロールです。ただし、JBoss EAP 管理対象ドメインの 1 つ以上のサーバーグループまたはホストに対してのみ適用されます。スコープ指定されたロールでは、管理ユーザーに、必要なサーバーグループまたはホストのみに制限されるパーミッションを付与することができます。

重要

スコープ指定されたロールは、Administrator または SuperUser ロールが割り当てられているユーザーが作成できます。

これらは、以下の 5 つの特性によって定義されます。

  • 一意な名前。
  • ベースとなる標準ロール。
  • サーバーグループまたはホストに適用される場合。
  • 制限されたサーバーグループまたはホストの一覧。
  • すべてのユーザーが自動的に組み込まれるかどうか。デフォルトは false です。

作成すると、スコープ指定されたロールは標準ロールと同じ方法でユーザーおよびグループに割り当てることができます。

スコープ指定されたロールを作成しても、新しいパーミッションを定義することはできません。スコープ指定されたロールは、制限されたスコープ内で既存のロールのパーミッションを適用する場合にのみ使用できます。たとえば、スコープ指定されたロールは、単一のサーバーグループに制限されている Deployer ロールに基づいて作成できます。

ロールには、以下の 2 つのスコープのみを使用できます。

ホストスコープ指定ロール
ホストスコープ指定ロールは、そのロールのパーミッションは単一または複数のホストに制限されます。つまり、アクセスは関連する /host=*/ リソースツリーに提供されますが、他のホストに固有のリソースは非表示になります。
サーバーグループスコープ指定ロール
サーバーグループスコープ指定ロールは、そのロールのパーミッションを 1 つ以上のサーバーグループに制限します。また、ロールのパーミッションは、指定した server-groups に関連付けられたプロファイル、ソケットバインディンググループ、サーバー設定、およびサーバーリソースにも適用されます。サーバーグループに論理的に関連していないものの内部のサブリソースは、ユーザーには認識できません。
重要

ユーザービリティーを強化する管理モデルのシンプルなビューを提供するために、server-group および host のスコープ指定されたロールに一部のリソースがアドレス指定できなくなります。これは、機密データを保護するためにアドレス指定できないリソースとは異なります。

host スコープ指定されたロールの場合は、ロールに指定されたサーバーグループに関連していなければ、管理モデルの /host=* 部分のリソースが表示されないことを意味します。

server-group のスコープ指定ロールの場合は、ロールに指定されたサーバーグループに関連しない場合、管理モデルの profilesocket-binding-groupdeploymentdeployment-overlayserver-groupserver-configserver の部分のリソースが表示されないことを意味します。

3.5.8.1. 管理 CLI からのスコープ指定されたロールの設定

重要

この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。

新しいスコープ指定されたロールの追加

スコープ設定されたロールを新たに追加するには、以下の操作を行う必要があります。

/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:add
/core-service=management/access=authorization/server-group-scoped-role=NEW-SCOPED-ROLE:add(base-role=BASE-ROLE, server-groups=[SERVER-GROUP-NAME])

NEW-SCOPED-ROLEBASE-ROLE、および SERVER-GROUP-NAME を適切な情報に置き換えます。

スコープ指定ロールマッピングの表示および編集

スコープ設定ロールの詳細 (メンバーを含む) は、以下のコマンドを使用して表示できます。

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

NEW-SCOPED-ROLE を適切な情報に置き換えます。

スコープ指定ロールの詳細を編集するには、write-attribute コマンドを使用できます。以下に例を示します。

/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:write-attribute(name=include-all, value=true)

NEW-SCOPED-ROLE を適切な情報に置き換えます。

スコープ指定ロールの削除
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:remove
/core-service=management/access=authorization/server-group-scoped-role=NEW-SCOPED-ROLE:remove

NEW-SCOPED-ROLE を適切な情報に置き換えます。

重要

ユーザーまたはグループが割り当てられている場合、スコープ指定ロールは削除できません。最初にロールの割り当てを削除してから、スコープ指定ロールを削除します。

ユーザーの追加および削除

スコープ指定ロールへのユーザーの追加および削除は 標準ロールの追加と削除 と同じプロセスに従います。

3.5.8.2. 管理コンソールからのスコープ指定ロールの設定

重要

この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。

管理コンソールのスコープ指定ロール設定は、以下の手順で確認できます。

  1. 管理コンソールにログインします。
  2. Access Control タブをクリックします。
  3. Roles をクリックして、スコープ指定されたロールを含め、すべてのロールを表示します。

以下の手順では、スコープ指定ロールの設定タスクを実行する方法について説明します。

新しいスコープ指定されたロールの追加
  1. 管理コンソールにログインします。
  2. Access Control タブをクリックします。
  3. Roles を選択し、Add (+) ボタンをクリックします。
  4. Host Scoped Role または Server Group Scoped Role を選択します。
  5. 以下の詳細を指定します。

    • Name: スコープ指定の新しいロールの一意の名前。
    • Base Role: このロールがパーミッションを元にするロール。
    • Hosts または Server Groups。ロールが制限されているホストまたはサーバーグループのリスト。追加中のスコープ指定ロールの種類による。複数のエントリーを選択できます。
    • Include All: このロールがすべてのユーザーを自動的に含めるかどうか。デフォルトは OFF です。
  6. Add をクリックして新規ロールを作成します。
スコープ指定されたロールの編集
  1. 管理コンソールにログインします。
  2. Access Control タブをクリックします。
  3. 左側の Roles メニューをクリックします。
  4. 編集するスコープ指定ロールをクリックし、Edit をクリックします。
  5. 変更する詳細を更新して、Save ボタンをクリックします。
スコープ指定されたロールメンバーの表示
  1. 管理コンソールにログインします。
  2. Access Control タブをクリックします。
  3. 左側の Roles メニューをクリックします。
  4. 対象のスコープ指定ロールをクリックして、包含メンバーおよび除外メンバーを表示します。
スコープ指定ロールの削除
  1. 管理コンソールにログインします。
  2. Access Control タブをクリックします。
  3. 左側の Roles メニューをクリックします。
  4. 対象のスコープ対象のロールをクリックし、ドロップダウンから Remove をクリックします。
  5. Yes をクリックし、その割り当てをすべて削除します。
ユーザーの追加および削除

スコープ指定ロールへのユーザーの追加および削除は標準ロールの追加と削除と同じプロセスに従います。ユーザーのスコープ指定ロールを更新するには、以下を実行します。

  1. 管理コンソールにログインします。
  2. Access Control タブをクリックします。
  3. 左側の Roles メニューをクリックし、対象のスコープ指定ロールをクリックします。
  4. メンバーを含めるにはプラス (+) ボタンを選択し、メンバーを除外するにはマイナス (-) ボタンを選択します。

3.5.9. 制約の設定

3.5.9.1. 機密性制約の設定

各機密性制約は、機密であるとみなされるリソースのセットを定義します。通常、機密リソースとは、パスワードなどの秘密のリソースや、ネットワーキング、JVM 設定、システムプロパティーなどのサーバーに重大な影響を与えるリソースのことです。アクセス制御システム自体も機密であると見なされます。リソースの機密性は、どのロールが特定のリソースの読み取り、書き込み、またはアドレス指定できるかを制限します。

機密性制約設定は /core-service=management/access=authorization/constraint=sensitivity-classification にあります。

管理モデル内で、それぞれの機密性制約は分類として識別されます。分類はタイプにグループ化されます。各分類には apply-to 要素があります。これは分類設定が適用されるパスパターンの一覧です。

機密性制約を設定するには、write-attribute 操作を使用して configured-requires-readconfigured-requires-writeconfigured-requires-addressable 属性を設定します。操作のタイプを機密に設定するには、属性の値を true に設定します。機密にしない場合は値を false に設定します。デフォルトでは、これらの属性は設定されず、default-requires-readdefault-requires-writedefault-requires-addressable の値が使用されます。設定した属性が適用されると、デフォルトではなく、その値が使用されます。デフォルト値は変更できません。

例: 読み取りシステムプロパティーを機密操作にする

/core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property:write-attribute(name=configured-requires-read,value=true)

例: 結果

/core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property:read-resource

{
    "outcome" => "success",
    "result" => {
        "configured-requires-addressable" => undefined,
        "configured-requires-read" => true,
        "configured-requires-write" => undefined,
        "default-requires-addressable" => false,
        "default-requires-read" => false,
        "default-requires-write" => true,
        "applies-to" => {
            "/core-service=platform-mbean/type=runtime" => undefined,
            "/system-property=*" => undefined,
            "/" => undefined
        }
    }
}

ロールと、実行できる各操作は、属性の設定によって異なります。これは、以下の表で説明されています。

表3.2 機密性制約設定の結果

requires-readrequires-writerequires-addressable

true

読み取りは機密です。AuditorAdministratorSuperUser のみを読み取ることができます。

書き込みは機密です。Administrator および SuperUser のみが書き込み可能です。

アドレス指定は機密です。AuditorAdministratorSuperUser のみがアドレス指定できます。

false

読み取りは機密ではありません。すべての管理ユーザーが読み取り可能です。

書き込みは機密ではありません。Maintainer、 Administrator、および SuperUser のみが書き込み可能です。また、Deployer はリソースをアプリケーションリソースとして記述することもできます。

アドレス指定は機密ではありません。すべての管理ユーザーがアドレス指定できます。

3.5.9.2. 機密性制約の一覧

以下の管理 CLI コマンドを使用すると、利用可能な機密性制約のリストを JBoss EAP 管理モデルから直接確認できます。

/core-service=management/access=authorization/constraint=sensitivity-classification:read-resource(include-runtime=true,recursive=true)

3.5.9.3. アプリケーションリソース制約の設定

各アプリケーションリソース制約は、通常はアプリケーションとサービスのデプロイメントに関連するリソース、属性、および操作のセットを定義します。アプリケーションリソース制約が有効化されると、Deployer ロールの管理ユーザーに、適用されるリソースへのアクセスが付与されます。

アプリケーション制約設定は /core-service=management/access=authorization/constraint=application-classification/ にあります。

各アプリケーションリソース制約は分類として識別されます。分類はタイプにグループ化されます。各分類には apply-to 要素があります。これは分類設定が適用されるパスパターンの一覧です。

デフォルトでは、有効になっている唯一のアプリケーションリソースの分類はコアです。コアには、デプロイメント、デプロイメントオーバーレイ、およびデプロイメント操作が含まれます。

アプリケーションリソースを有効にするには、write-attribute 操作を使用して、分類の configured-application 属性を true に設定します。アプリケーションリソースを無効にするには、この属性を false に設定します。デフォルトでは、これらの属性は設定されず、default-application 属性の値が使用されます。デフォルト値は変更できません。

例: logger-profile アプリケーションリソースの分類の有効化

/core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile:write-attribute(name=configured-application,value=true)

例: 結果

/core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile:read-resource

{
    "outcome" => "success",
    "result" => {
        "configured-application" => true,
        "default-application" => false,
        "applies-to" => {"/subsystem=logging/logging-profile=*" => undefined}
    }
}
重要

アプリケーションリソース制約は、その設定に一致するすべてのリソースに適用されます。たとえば、Deployer ユーザーに、あるデータソースリソースへのアクセスを許可して、同じデータベースの別のリソースへのアクセスを拒否することはできません。このレベルの分離が必要な場合は、異なるサーバーグループでリソースを設定し、グループごとに異なるスコープ指定の Deployer ロールを作成することが推奨されます。

3.5.9.4. アプリケーションリソース制約の一覧表示

以下の管理 CLI コマンドを使用すると、利用可能なアプリケーションリソースのリストを JBoss EAP 管理モデルから直接確認できます。

/core-service=management/access=authorization/constraint=application-classification:read-resource(include-runtime=true,recursive=true)

3.5.9.5. Vault 式制約の設定

デフォルトでは、vault 式の読み書きは機密操作です。Vault 式制約を設定すると、これらの操作のいずれかまたは両方を非機密に設定できます。この制約を変更すると、より多くのロールで vault 式の読み書きが可能になります。

Vault 式制約は /core-service=management/access=authorization/constraint=vault-expression にあります。

Vault 式制約を設定するには、write-attribute 操作を使用して configured-requires-writeconfigured-requires-read の値を true または false に設定します。デフォルトではそれらは設定されず、default-requires-readdefault-requires-write の値が使用されます。デフォルト値は変更できません。

例: Vault 式への書き込みのを非機密操作にする

/core-service=management/access=authorization/constraint=vault-expression:write-attribute(name=configured-requires-write,value=false)

例: 結果

/core-service=management/access=authorization/constraint=vault-expression:read-resource

{
    "outcome" => "success",
    "result" => {
        "configured-requires-read" => undefined,
        "configured-requires-write" => false,
        "default-requires-read" => true,
        "default-requires-write" => true
    }
}

ロールと、読み書きが可能な関連の vault 式は、属性の設定に依存します。これは、以下の表で説明されています。

表3.3 Vault 式制約設定の結果

requires-readrequires-write

true

読み取り操作は機密です。AuditorAdministrator、および SuperUser のみを読み取ることができます。

書き込み操作は機密です。Administrator および SuperUser のみが書き込み可能です。

false

読み取り操作は機密ではありません。すべての管理ユーザーは読み取りが可能です。

書き込み操作は機密ではありません。MonitorAdministrator、および SuperUser は書き込み可能です。Deployer は、vault 式がアプリケーションリソースにある場合にも書き込み可能です。

第4章 クレデンシャルをセキュアに保存する方法

JBoss EAP では、設定ファイル外で機密文字列を暗号化できます。これらの文字列はキーストアに格納でき、その後アプリケーションおよび検証システムに対して復号化されます。機密文字列は以下のいずれかに格納できます。

  • クレデンシャルストア: JBoss EAP 7.1 で導入されるクレデンシャルストアは、ストレージファイルで暗号化することで、機密およびプレーンテキストの文字列を安全に保護できます。各 JBoss EAP サーバーに複数のクレデンシャルストアを含めることができます。
  • パスワード vault: レガシー設定で使用されると、パスワード vault は Java キーストアを使用して、設定ファイル外に機密文字列を保存します。各 JBoss EAP サーバーには単一のパスワード vault のみを含めることができます。

EAP_HOME/standalone/configuration/EAP_HOME/domain/configuration/ の設定ファイルは、すべてデフォルトでは読み取り可能です。プレーンテキストパスワードを設定ファイルに保存せず、クレデンシャルストア または password vault のいずれかに認証情報を配置することを強く推奨します。

設定ファイルにプレーンテキストのパスワードを配置する場合、これらのファイルは、限られたユーザーのみがアクセスできるようにする必要があります。JBoss EAP 7 を実行しているユーザーアカウントには少なくとも読み書き込みアクセスが必要です。

4.1. Elytron のクレデンシャルストア

4.1.1. Elytron が提供するクレデンシャルストア

Elytron には、クレデンシャルの保存に使用できるデフォルトのクレデンシャルストアタイプが 2 つ ( KeyStoreCredentialStore と PropertiesCredentialStore) 用意されています。JBoss EAP 管理 CLI でクレデンシャルストアを管理することも、Wild Fly Elytron ツールを使用してオフラインで管理することもできます。2 つのデフォルトストアタイプに加えて、独自のカスタムクレデンシャルストアを作成、使用、管理することができます。

4.1.1.1. KeyStoreCredentialStore/credential-store

Elytron のすべてのクレデンシャルタイプを Key Store Credential Store に格納できます。elytron サブシステムの Key Store Credential Store のリソース名は credential-store です。Key Store Credential Store は、Java Development Kit (JDK) の Key Store 実装が提供するメカニズムを使用して、認証情報を保護します。

管理用 CLI で Key Store Credential Store に次のようにアクセスします。

/subsystem=elytron/credential-store

4.1.1.2. PropertiesCredentialStore/secret-key-credential-store

JBoss EAP を正しく起動するには、特定のセキュアリソースのロックを解除する初期キーが必要です。secret-key-credential-store を使用して、このマスターシークレットキーを指定し、これらの必要なサーバーリソースのロックを解除します。また、Properties Credential Store を使って、AES(Advanced Encryption Standard) の秘密鍵の保存をサポートする SecretKeyCredential を保存することもできます。ファイルシステムのパーミッションを使用して、クレデンシャルストアへのアクセスを制限します。アプリケーションサーバーのみにアクセス権を付与して、このクレデンシャルストアへのアクセスを制限するのが理想的です。PropertiesCredentialStore の elytron サブシステムでのリソース名は secret-key-credential-store で、管理 CLI で以下のようにアクセスできます。

/subsystem=elytron/secret-key-credential-store

初期キーの作成および提供の詳細は、セキュリティーで保護されたリソースをロック解除するための JBoss EAP への初期キーの提供 を参照してください。また、外部のソースからマスターキーやパスワードを入手することもできます。外部ソースからパスワードを取得する方法は、外部ソースからクレデンシャルストアのパスワードの取得 を参照してください。

4.1.2. Elytron のクレデンシャルタイプ

Elytron では、さまざまなセキュリティーの用途に合わせて以下の 3 種類のクレデンシャルがあり、これらのクレデンシャルを Elytron のクレデンシャルストアの 1 つに保存できます。

PasswordCredential

このクレデンシャルタイプでは、プレーンテキスト (暗号化されていない) パスワードを安全に保存できます。パスワードを必要とする JBoss EAP リソースでは、パスワードの機密性を維持するために、プレーンテキストのパスワードの代わりに PasswordCredential への参照を使用します。

データベースへの接続の例

data-source add ... --user-name=db_user --password=StrongPassword

このデータベース接続コマンドの例では、StrongPassword とパスワードが表示されます。つまり、他の人もサーバー設定ファイルでパスワードを確認できるということです。

PasswordCredential を使用したデータベースへの接続例

data-source add ... --user-name=db_user --credential-reference={store=exampleKeyStoreCredentialStore, alias=passwordCredentialAlias}

データベースへの接続にパスワードではなくクレデンシャルリファレンスを使用した場合に、他の人が確認できるのは設定ファイル内のクレデンシャルリファレンスのみで、パスワードは表示されません。

KeyPairCredential

KeyPairCredential には、Secure Shell (SSH) と Public-Key Cryptography Standards (PKCS) の両方のキーペアを使用できます。キーペアには、共有される公開鍵と、特定のユーザーだけが知っている秘密鍵の両方が含まれています。

KeyPairCredential の管理は、Wild Fly Elytron ツールのみで行うことができます。

SecretKeyCredential
SecretKeyCredential は Elytron で暗号化式の作成に使用できる Advanced Encryption Standard (AES) キーです。暗号化式については、Elytron の暗号化式 を参照してください。

4.1.3. Elytron のクレデンシャルストアでサポートされる認証情報タイプ

次の表は、どのクレデンシャルストアがどの認証情報のタイプをサポートしているかを示しています。

認証情報のタイプKeyStoreCredentialStore/credential-storePropertiesCredentialStore/secret-key-credential-store

PasswordCredential

はい

いいえ

KeyPairCredential

はい

いいえ

SecretKeyCredential

はい

はい

4.1.4. JBoss EAP 管理 CLI を使用したクレデンシャルストアの操作

実行中の JBoss EAP サーバーで JBoss EAP クレデンシャルを管理するには、提供されている管理 CLI 操作を使用します。PasswordCredential および SecretKeyCredential は、JBoss EAP 管理 CLI を使用して管理できます。

注記

これらの操作は、変更可能なクレデンシャルストアに対してのみ行うことができます。デフォルトでは、クレデンシャルストアタイプはすべて変更可能です。

4.1.4.1. スタンドアロンサーバー用の KeyStoreCredentialStore/credential-Store の作成

ファイルシステムの任意のディレクトリーに、スタンドアロンサーバーとして動作する JBoss EAP 用の Key StoreCredentialStore を作成します。セキュリティーの理由から、このストアを含むディレクトリーは、一部のユーザーのみがアクセスできるようにする必要があります。

前提条件

  • 最低でも、JBoss EAP が実行されているユーザーアカウントの KeyStoreCredentialStore を含むディレクトリーへの読み取り/書き込みアクセスが割り当てられている。
注記

credential-storesecret-key-credential-store は同じ Elytron 機能 (org.wildfly.security.credential-store) を実装しているため、同じ名前を指定できません。

手順

  • 以下の管理用 CLI コマンドで KeyStoreCredentialStore を作成します。

    構文

    /subsystem=elytron/credential-store=<name_of_credential_store>:add(path="<path_to_store_file>", relative-to=<base_path_to_store_file>, credential-reference={clear-text=<store_password>}, create=true)

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:add(path="exampleKeyStoreCredentialStore.jceks", relative-to=jboss.server.data.dir, credential-reference={clear-text=password}, create=true)
    {"outcome" => "success"}

4.1.4.2. 管理対象ドメインの KeyStoreCredential Store/credential-Store の作成

管理対象ドメインに KeyStoreCredentialStore を作成できますが、最初に Wild Fly Elytron ツールを使用して、KeyStoreCredentialStore を準備する必要があります。1 つの管理対象ドメインに複数のホストコントローラーがある場合は、以下のいずれかのオプションを選択します。

  • ホストコントローラーごとに KeyStoreCredentialStore を作成し、各 KeyStoreCredentialStore に資格情報を追加します。
  • あるホストコントローラーから他の全てのホストコントローラーに、生成された KeyStoreCredentialStore をコピーします。
  • KeyStoreCredentialStore ファイルをネットワークファイルシステム (NFS) に保存し、作成したすべての KeyStoreCredentialStore リソースにそのファイルを使用します。

また、Wild Fly Elytron ツールを使用せずに、ホストコントローラー上で資格情報を指定した KeyStoreCredentialStore ファイルを作成することもできます。

注記

同じプロファイルのすべてのサーバーには、KeyStore CredentialStore ファイルが含まれているので、全サーバーに KeyStoreCredentialStore リソースを定義する必要はありません。KeyStoreCredentialStore ファイルは、サーバーの data ディレクトリーの relative-to=jboss.server.data.dir にあります。

重要

credential-storesecret-key-credential-store は同じ Elytron 機能 (org.wildfly.security.credential-store) を実装しているため、同じ名前を指定できません。

以下の手順では、NFS を使用して KeyStoreCredentialStore ファイルをすべてのホストコントローラーに提供する方法を説明します。

手順

  1. Wild Fly Elytron ツールを使用して、KeyStoreCredentialStore ストレージファイルを作成します。この詳細は、Wild Fly Elytron ツールを使用したクレデンシャルストア操作 を参照してください。
  2. ストレージファイルを配布します。たとえば、scp コマンドを使用して各ホストコントローラーに割り当てたり、NFS に保存してすべての KeyStoreCredentialStore リソースに使用したりします。

    注記

    一貫性を保つために、複数のリソースやホストコントローラーが使用し、NFS に保存した KeyStoreCredentialStore ファイルは、読み取り専用モードで使用する必要があります。また、KeyStoreCredentialStore ファイルの絶対パスを指定することを確認してください。

    構文

    /profile=<profile_name>/subsystem=elytron/credential-store=<name_of_credential_store>:add(path=<absolute_path_to_store_keystore>,credential-reference={clear-text="<store_password>"},create=false,modifiable=false)

    /profile=full-ha/subsystem=elytron/credential-store=exampleCredentialStoreDomain:add(path=/usr/local/etc/example-cred-store.cs,credential-reference={clear-text="password"},create=false,modifiable=false)

  3. オプション:プロファイルに credential-store リソースを定義する必要がある場合は、ストレージファイルを使用してリソースを作成します。

    構文

    /profile=<profile_name>/subsystem=elytron/credential-store=<name_of_credential_store>:add(path=<path_to_store_file>,credential-reference={clear-text="<store_password>"})

    /profile=full-ha/subsystem=elytron/credential-store=exampleCredentialStoreHA:add(path=/usr/local/etc/example-cred-store-ha.cs, credential-reference={clear-text="password"})

  4. オプション: ホストコントローラーの KeyStoreCredentialStore リソースを作成します。

    構文

    /host=<host_controller_name>/subsystem=elytron/credential-store=<name_of_credential_store>:add(path=<path_to_store_file>,credential-reference={clear-text="<store_password>"})

    /host=master/subsystem=elytron/credential-store=exampleCredentialStoreHost:add(path=/usr/local/etc/example-cred-store-host.cs, credential-reference={clear-text="password"})

4.1.4.3. スタンドアロンサーバー用の Properties Credential Store/secret-key-credential-Store の作成

管理 CLI を使用して Properties Credential Store を作成します。Properties Credential Store を作成すると、JBoss EAP はデフォルトで秘密鍵を生成します。生成された鍵の名前は key で、そのサイズは 256 ビットです。

前提条件

  • 最低でも、JBoss EAP が実行されているユーザーアカウントの PropertiesCredentialStore を含むディレクトリーへの読み取り/書き込みのアクセスが割り当てられている。

手順

  • 次のコマンドを使用して、管理 CLI を使用して PropertiesCredentialStore を作成します。

    構文

    /subsystem=elytron/secret-key-credential-store=<name_of_credential_store>:add(path="<path_to_the_credential_store>", relative-to=<path_to_store_file>)

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:add(path=examplePropertiesCredentialStore.cs, relative-to=jboss.server.config.dir)
    {"outcome" => "success"}

4.1.4.4. KeyStoreCredentialStore/credential-store への PasswordCredential の追加

KeyStoreCredentialStore に PasswordCredential としてパスワードを必要とするリソースにはプレーンテキストのパスワードを追加して、そのパスワードを設定ファイルで非表示にします。この保存したクレデンシャルを参照して、パスワードを公開することなく、これらのリソースにアクセスできます。

前提条件

手順

  • 新しい PasswordCredential を KeyStoreCredentialStore に追加します。

    構文

    /subsystem=elytron/credential-store=<name_of_credential_store>:add-alias(alias=<alias>, secret-value=<secret-value>)

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:add-alias(alias=passwordCredentialAlias, secret-value=StrongPassword)
    {"outcome" => "success"}

検証

  • 次のコマンドを実行して、PasswordCredential が KeyStoreCredentialStore に追加されたことを確認します。

    構文

    /subsystem=elytron/credential-store=<name_of_credential_store>:read-aliases()

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:read-aliases()
    {
        "outcome" => "success",
        "result" => ["passwordcredentialalias"]
    }

4.1.4.5. KeyStoreCredentialStore/credential-Store での Secret Key Credential の生成

KeyStoreCredentialStore で Secret Key Credential を生成します。デフォルトでは、Elytron は 256 ビットの鍵を作成します。別のサイズにする場合は、key-size 属性に 128 ビットまたは 192 ビットの鍵を指定します。

前提条件

手順

  1. 以下の管理 CLI コマンドで、KeyStoreCredentialStore に SecretKeyCredential を生成します。

    構文

    /subsystem=elytron/credential-store=<name_of_credential_store>:generate-secret-key(alias=<alias>, key-size=<128_or_192>)

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:generate-secret-key(alias=secretKeyCredentialAlias)

検証

  • 以下のコマンドを実行して、Elytron が SecretKeyCredential を KeyStoreCredentialStore に保存されたことを確認します。

    構文

    /subsystem=elytron/credential-store=<credential_store>:read-aliases()

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:read-aliases()
    {
        "outcome" => "success",
        "result" => [
            "secretkeycredentialalias"
        ]
    }

4.1.4.6. PropertiesCredentialStore/secret-key-credential-store での SecretKeyCredential の生成

PropertiesCredentialStore で SecretKeyCredential を生成します。デフォルトでは、Elytron は 256 ビットの鍵を作成します。別のサイズにする場合は、key-size 属性に 128 ビットまたは 192 ビットの鍵を指定します。

SecretKeyCredential を生成すると、Elytron は新しいランダムな秘密鍵を生成して SecretKeyCredential として保存します。PropertiesCredentialStore のエクスポート操作を使用して、クレデンシャルの内容を見ることができます。

重要

JBoss EAP は失われた Elytron クレデンシャルを復号化または取得できないため、PropertiesCredentialStore、SecretKeyCredential、またはその両方のバックアップを必ず作成してください。

PropertiesCredentialStore の export 操作を使用して、SecretKeyCredential の値を取得できます。この値をバックアップとして保存できます。詳細は、PropertiesCredential Store/secret-key-credential-store からの SecretKeyCredential のエクスポート を参照してください。

前提条件

手順

  • 以下の管理 CLI コマンドで PropertiesCredentialStore に SecretKeyCredential を生成します。

    構文

    /subsystem=elytron/secret-key-credential-store=<name_of_the_properties_credential_store>:generate-secret-key(alias=<alias>, key-size=<128_or_192>)

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:generate-secret-key(alias=secretKeyCredentialAlias)
    {"outcome" => "success"}

検証

  • 以下のコマンドを実行して、Elytron が SecretKeyCredential を作成したことを確認します。

    構文

    /subsystem=elytron/secret-key-credential-store=<name_of_the_properties_credential_store>:read-aliases()

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:read-aliases()
    {
        "outcome" => "success",
        "result" => [
            "secretkeycredentialalias",
            "key"
        ]
    }

4.1.4.7. PropertiesCredentialStore/secret-key-credential-store への SecretKeyCredential のインポート

PropertiesCredentialStore の外部で作成された SecretKeyCredential を Elytron の PropertiesCredentialStore にインポートできます。別のクレデンシャルストア (例: KeyStoreCredentialStore) から SecretKeyCredential をエクスポートしたとすると、それを PropertiesCredential Store にインポートできます。

前提条件

手順

  1. 以下のコマンドを使用すると、管理 CLI でコマンドのキャッシュを無効にできます。

    重要

    キャッシングを無効にしない場合は、管理 CLI の履歴ファイルにアクセスできるユーザーは誰でも、秘密鍵を確認できます。

    history --disable
  2. 次の管理 CLI コマンドを使用して、秘密鍵をインポートします。

    構文

    /subsystem=elytron/secret-key-credential-store=<name_of_credential_store>:import-secret-key(alias=<alias>, key="<secret_key>")

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:import-secret-key(alias=imported, key="RUxZAUs+Y1CzEPw0g2AHHOZ+oTKhT9osSabWQtoxR+O+42o11g==")

  3. 以下の管理 CLI コマンドを使用して、コマンドのキャッシングを再度有効にしてください。

    history --enable

4.1.4.8. KeyStoreCredentialStore/credential-store にあるクレデンシャルの一覧表示

KeyStoreCredentialStore に保存されているすべての認証情報を表示するには、管理 CLI を使用してリストアップできます。

手順

  • 以下の管理用 CLI コマンドを使用して、KeyStoreCredentialStore に格納されている認証情報を一覧表示します。

    構文

    /subsystem=elytron/credential-store=<name_of_credential_store>:read-aliases()

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:read-aliases()
    {
        "outcome" => "success",
        "result" => [
            "passwordcredentialalias",
            "secretkeycredentialalias"
        ]
    }

4.1.4.9. PropertiesCredential Store/secret-key-credential-store にあるクレデンシャルの一覧表示

PropertiesCredentialStore に格納されているすべてのクレデンシャルを表示するには、管理 CLI を使用してリストアップできます。

手順

  • 以下の管理 CLI コマンドを使用して、PropertiesCredentialStore に格納されている認証情報を一覧表示します。

    構文

    /subsystem=elytron/secret-key-credential-store=<name_of_credential_store>:read-aliases()

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:read-aliases()
    {
        "outcome" => "success",
        "result" => [
            "secretkeycredentialalias",
            "key"
        ]
    }

4.1.4.10. KeyStoreCredentialStore/credential-store からの SecretKeyCredential のエクスポート

KeyStoreCredentialStore から既存の SecretKeyCredential をエクスポートして、SecretKeyCredential を使用したり、SecretKeyCredential のバックアップを作成したりできます。

前提条件

手順

  • 以下の管理 CLI コマンドで、KeyStoreCredentialStore から SecretKeyCredential をエクスポートします。

    構文

    /subsystem=elytron/credential-store=<name_of_credential_store>:export-secret-key(alias=<alias>)

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:export-secret-key(alias=secretKeyCredentialAlias)
    {
        "outcome" => "success",
        "result" => {"key" => "RUxZAUui+8JkoDCE6mFyA3cCIbSAZaXq5wgYejj1scYgdDqWiw=="}
    }

4.1.4.11. PropertiesCredentialStore/secret-key-credential-store からの SecretKeyCredential のエクスポート

PropertiesCredentialStore から既存の SecretKeyCredential をエクスポートして、SecretKeyCredential を使用したり、SecretKeyCredential のバックアップを作成したりできます。

前提条件

手順

  • 以下の管理 CLI コマンドを使用して、PropertiesCredentialStore から SecretKeyCredential をエクスポートします。

    構文

    /subsystem=elytron/secret-key-credential-store=<name_of_credential_store>:export-secret-key(alias=<alias>)

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:export-secret-key(alias=secretkeycredentialalias)
    {
        "outcome" => "success",
        "result" => {"key" => "RUxZAUtxXcYvz0aukZu+odOynIr0ByLhC72iwzlJsi+ZPmONgA=="}
    }

4.1.4.12. KeyStoreCredentialStore/credential-store からのクレデンシャルの削除

KeyStoreCredentialStore にすべてのクレデンシャルタイプを保存できますが、デフォルトでは、クレデンシャルを削除すると、Elytron は PasswordCredential であると想定します。別のクレデンシャルタイプを削除する場合は、entry-type 属性で指定します。

手順

  • 次の管理 CLI コマンドを使用して、KeyStoreCredentialStore からクレデンシャルを削除します。

    構文

    /subsystem=elytron/credential-store=<name_of_credential_store>:remove-alias(alias=<alias>, entry-type=<credential_type>)

    PasswordCredential の削除例

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:remove-alias(alias=passwordCredentialAlias)
    {
        "outcome" => "success",
        "response-headers" => {"warnings" => [{
            "warning" => "Update dependent resources as alias 'passwordCredentialAlias' does not exist anymore",
            "level" => "WARNING",
            "operation" => {
                "address" => [
                    ("subsystem" => "elytron"),
                    ("credential-store" => "exampleKeyStoreCredentialStore")
                ],
                "operation" => "remove-alias"
            }
        }]}
    }

    SecretKeyCredential の削除例

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:remove-alias(alias=secretKeyCredentialAlias, entry-type=SecretKeyCredential)
    {
        "outcome" => "success",
        "response-headers" => {"warnings" => [{
            "warning" => "Update dependent resources as alias 'secretKeyCredentialAl
    ias' does not exist anymore",
            "level" => "WARNING",
            "operation" => {
                "address" => [
                    ("subsystem" => "elytron"),
                    ("credential-store" => "exampleKeyStoreCredentialStore")
                ],
                "operation" => "remove-alias"
            }
        }]}
    }

検証

  • 次のコマンドを実行して、Elytron がクレデンシャルを削除したことを確認します。

    構文

    /subsystem=elytron/credential-store=<name_of_credential_store>:read-aliases()

    /subsystem=elytron/credential-store=exampleKeyStoreCredentialStore:read-aliases()
    {
        "outcome" => "success",
        "result" => []
    }

    削除したクレデンシャルはリストにありません。

4.1.4.13. PropertiesCredentialStore/secret-key-credential-store からのクレデンシャルの削除

PropertiesCredentialStore には、SecretKeyCredential タイプのみを格納できます。つまり、PropertiesCredentialStore からクレデンシャルを削除する時に、entry-type を指定する必要はありません。

手順

  • 以下のコマンドで PropertiesCredentialStore から SecretKeyCredential を削除します。

    構文

    /subsystem=elytron/secret-key-credential-store=<name_of_credential_store>:remove-alias(alias=<alias>)

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:remove-alias(alias=secretKeyCredentialAlias)
    {
        "outcome" => "success",
        "response-headers" => {"warnings" => [{
            "warning" => "Update dependent resources as alias 'secretKeyCredentialAlias' does not exist anymore",
            "level" => "WARNING",
            "operation" => {
                "address" => [
                    ("subsystem" => "elytron"),
                    ("secret-key-credential-store" => "examplePropertiesCredentialSt
    ore")
                ],
                "operation" => "remove-alias"
            }
        }]}
    }

検証

  • 次のコマンドを実行して、Elytron がクレデンシャルを削除したことを確認します。

    構文

    /subsystem=elytron/secret-key-credential-store=<name_of_credential_store>:read-aliases()

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:read-aliases()
    {
        "outcome" => "success",
        "result" => []
    }

    削除したクレデンシャルはリストにありません。

4.1.5. Wild Fly Elytron ツールを使用したクレデンシャルストア操作

4.1.5.1. Wild Fly Elytron ツールによる KeyStoreCredentialStore/credential-Store の作成

Elytron では、すべてのクレデンシャルタイプを保存できる KeyStoreCredentialStore をオフラインで作成できます。

手順

  • Wild Fly Elytron ツールを使って、以下のコマンドで KeyStoreCredentialStore を作成します。

    構文

    $ EAP_HOME/bin/elytron-tool.sh credential-store --create --location "<path_to_store_file>" --password <store_password>

    $ EAP_HOME/bin/elytron-tool.sh credential-store --create --location "../cred_stores/example-credential-store.jceks" --password storePassword
    Credential Store has been successfully created

    ストアのパスワードをコマンドに含めない場合は、この引数を省略して、プロンプトでパスワードを手動で入力してください。また、Wild Fly Elytron ツールで生成したマスキングされたパスワードを使用することもできます。マスクされたパスワードの生成については、Wild Fly Elytron ツールを使ったマスクされた暗号化文字列の生成 を参照してください。

4.1.5.2. Bouncy Castle プロバイダーを使用した KeyStoreCredential Store/credential-Store の作成

Bouncy Castle プロバイダーを使用して、KeyStoreCredentialStore を作成します。

前提条件

注記

credential-storesecret-key-credential-store は同じ Elytron 機能 (org.wildfly.security.credential-store) を実装しているため、同じ名前を指定できません。

手順

  1. BCFKS (Bouncy Castle FIPS Keystore) のキーストアを定義します。FIPS とは Federal Information Processing Standards の略です。このキーストアがすでにある場合は、次のステップに進んでください。

    $ keytool -genkeypair -alias <key_pair_alias> -keyalg <key_algorithm> -keysize <key_size> -storepass <key_pair_and_keystore_password> -keystore <path_to_keystore> -storetype BCFKS -keypass <key_pair_and_keystore_password>
    重要

    キーストアの keypass 属性と storepass 属性が同一であることを確認してください。そうでない場合は、elytron サブシステムの BCFKS キーストアでは定義できません。

  2. KeyStoreCredentialStore の秘密鍵を生成します。

    $ keytool -genseckey -alias <key_alias> -keyalg <key_algorithm> -keysize <key_size> -keystore <path_to_keystore> -storetype BCFKS -storepass <key_and_keystore_password> -keypass <key_and_keystore_password>
  3. KeyStoreCredentialStore を Wild Fly Elytron ツールを使って以下のコマンドで定義します。

    $ EAP_HOME/bin/elytron-tool.sh credential-store -c -a <alias> -x <alias_password> -p <key_and_keystore_password> -l <path_to_keystore> -u "keyStoreType=BCFKS;external=true;keyAlias=<key_alias>;externalPath=<path_to_credential_store>"

4.1.5.3. Wild Fly Elytron ツールによる PropertiesCredentialStore/secret-key-credential-Store の作成

Elytron では、PropertiesCredentialStore をオフラインで作成し、SecretKeyCredential インスタンスを保存できます。

手順

  • 以下のコマンドで Wild Fly Elytron ツールを使用して PropertiesCredentialStore を作成します。

    構文

    $ EAP_HOME/bin/elytron-tool.sh credential-store --create --location "<path_to_store_file>" --type PropertiesCredentialStore

    $ bin/elytron-tool.sh credential-store --create --location=standalone/configuration/properties-credential-store.cs --type PropertiesCredentialStore
    Credential Store has been successfully created

4.1.5.4. Wild Fly Elytron ツール KeyStoreCredentialStore/credential-store の操作

Wild Fly Elytron ツールを使って、以下のようなさまざまな KeyStoreCredentialStore タスクを行うことができます。

PasswordCredential の追加

PasswordCredential を KeyStoreCredentialStore に追加するには、以下の Wild Fly Elytron ツールのコマンドを使用します。

構文

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "<path_to_store_file>" --password <store_password> --add <alias> --secret <sensitive_string>

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "../cred_stores/example-credential-store.jceks" --password storePassword --add examplePasswordCredential --secret speci@l_db_pa$$_01
Alias "examplePasswordCredential" has been successfully stored

コマンドにシークレットを指定しない場合は、この引数を省略して、プロンプトが表示されたら手動でシークレットを入力します。

SecretKeyCredential の生成

KeyStoreCredential Store に SecretKeyCredential を追加するには、以下の Wild Fly Elytron ツールのコマンドを使用します。

構文

$ EAP_HOME/bin/elytron-tool.sh credential-store --generate-secret-key=example --location=<path_to_the_credential_store> --password <store_password>

$ EAP_HOME/bin/elytron-tool.sh credential-store --generate-secret-key=example --location "../cred_stores/example-credential-store.jceks" --password storePassword
Alias "example" has been successfully stored

コマンドにシークレットを指定しない場合は、この引数を省略して、プロンプトが表示されたら手動でシークレットを入力します。

デフォルトでは、JBoss EAP で SecretKeyCredential を作成すると、256 ビットの秘密鍵が作成されます。サイズを変更する場合は、 --size=128 または --size=192 を指定すると、それぞれ 128 ビット、192 ビットの鍵を作成できます。

SecretKeyCredential のインポート

Secret Key Credential のインポートは、以下の Wild FLy Elytron ツールのコマンドで行うことができます。

構文

$ EAP_HOME/bin/elytron-tool.sh credential-store --import-secret-key=imported --location=<path_to_credential_store> --password=<store_password>

$ EAP_HOME/bin/elytron-tool.sh credential-store --import-secret-key=imported --location=../cred_stores/example-credential-store.jceks --password=storePassword

インポートする秘密鍵を入力します。

すべてのクレデンシャルの一覧表示

以下の Wild Fly Elytron ツールのコマンドを使用して、KeyStoreCredentialStore 内の認証情報を一覧表示できます。

構文

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "<path_to_store_file>" --password <store_password> --aliases

以下に例を示します。

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "../cred_stores/example-credential-store.jceks" --password storePassword --aliases
Credential store contains following aliases: examplepasswordcredential example

エイリアスが存在するかどうかの確認

クレデンシャルストアにエイリアスが存在するかどうかを確認するには、次のコマンドを使用します。

構文

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "<path_to_store_file>" --password <store_password> --exists <alias>

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "../cred_stores/example-credential-store.jceks" --password storePassword --exists examplepasswordcredential
Alias "examplepasswordcredential" exists

SecretKeyCredential のエクスポート

以下のコマンドで、KeyStoreCredentialStore から SecretKeyCredential をエクスポートできます。

構文

$ EAP_HOME/bin/elytron-tool.sh credential-store --export-secret-key=<alias> --location=<path_to_credential_store> --password=storePassword

$ EAP_HOME/bin/elytron-tool.sh credential-store --export-secret-key=example --location=../cred_stores/example-credential-store.jceks --password=storePassword
Exported SecretKey for alias example=RUxZAUtBiAnoLP1CA+i6DtcbkZHfybBJxPeS9mlVOmEYwjjmEA==

クレデンシャルの削除

以下のコマンドを使用して、クレデンシャルストアから認証情報を削除できます。

構文

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "<path_to_store_file>" --password <store_password> --remove <alias>

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "../cred_stores/example-credential-store.jceks" --password storePassword --remove examplepasswordcredential
Alias "examplepasswordcredential" has been successfully removed

4.1.5.5. Wild Fly Elytron ツールの PropertiesCredentialStore/secret-key-credential-store の操作

以下のように、Wild Fly Elytron ツールを使って、SecretKeyCredential に対する PropertiesCredentialStore 操作を実行します。

SecretKeyCredential の生成

以下の Wild Fly Elytron ツールのコマンドで PropertiesCredentialStore に SecteKeyCredential を生成できます。

構文

$ EAP_HOME/bin/elytron-tool.sh credential-store --generate-secret-key=example --location "<path_to_the_credential_store>" --type PropertiesCredentialStore

$ EAP_HOME/bin/elytron-tool.sh credential-store --generate-secret-key=example --location "standalone/configuration/properties-credential-store.cs" --type PropertiesCredentialStore
Alias "example" has been successfully stored

SecretKeyCredential のインポート

Secret Key Credential のインポートは、以下の Wild FLy Elytron ツールのコマンドで行うことができます。

構文

$ EAP_HOME/bin/elytron-tool.sh credential-store --import-secret-key=imported --location=<path_to_credential_store> --type PropertiesCredentialStore

$ EAP_HOME/bin/elytron-tool.sh credential-store --import-secret-key=imported --location "standalone/configuration/properties-credential-store.cs" --type PropertiesCredentialStore

すべてのクレデンシャルの一覧表示

以下の Wild Fly Elytron ツールのコマンドを使用して、PropertiesCredentialStore 内の資格情報を一覧表示できます。

構文

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "<path_to_store_file>"  --aliases --type PropertiesCredentialStore

$ EAP_HOME/bin/elytron-tool.sh credential-store  --location "standalone/configuration/properties-credential-store.cs" --aliases --type PropertiesCredentialStore
Credential store contains following aliases: example

SecretKeyCredential のエクスポート

以下のコマンドで PropertiesCredentialStore から SecretKeyCredential をエクスポートできます。

構文

$ EAP_HOME/bin/elytron-tool.sh credential-store --export-secret-key=<alias> --location "<path_to_credential_store>"  --type PropertiesCredentialStore

$ EAP_HOME/bin/elytron-tool.sh credential-store --export-secret-key=example --location "standalone/configuration/properties-credential-store.cs" --type PropertiesCredentialStore
Exported SecretKey for alias example=RUxZAUt1EZM7PsYRgMGypkGirSel+5Eix4aSgwop6jfxGYUQaQ==

クレデンシャルの削除

以下のコマンドを使用して、クレデンシャルストアから認証情報を削除できます。

構文

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "<path_to_store_file>" --remove <alias> --type PropertiesCredentialStore

$ EAP_HOME/bin/elytron-tool.sh credential-store --location "standalone/configuration/properties-credential-store.cs"  --remove example --type PropertiesCredentialStore
Alias "example" has been successfully removed

4.1.5.6. WildFly Elytron Tool で作成されたクレデンシャルストアの JBoss EAP サーバーへの追加

Wild Fly Elytron ツールでクレデンシャルストアを作成したら、実行中の JBoss EAP サーバーに追加できます。

前提条件

手順

  • 以下の管理 CLI コマンドを使用して、実行中の JBoss EAP サーバーにクレデンシャルストアを追加します。

    /subsystem=elytron/credential-store=<store_name>:add(location="<path_to_store_file>",credential-reference={clear-text=<store_password>})

    以下に例を示します。

    /subsystem=elytron/credential-store=my_store:add(location="../cred_stores/example-credential-store.jceks",credential-reference={clear-text=storePassword})

クレデンシャルストアを JBoss EAP 設定に追加することで、credential-reference 属性 を使用してクレデンシャルストアに保存されているパスワードまたは機密文字列を参照できます。

詳細は、EAP_HOME/bin/elytron-tool.sh credential-store --help コマンドを使用して、利用可能なオプションの詳細な一覧を表示してください。

4.1.5.7. Wild Fly Elytron ツールによるキーペア管理の操作

以下の引数を使用して、クレデンシャルストアのエイリアスに保存するキーペアを新規生成するなど、elytron-tool.sh を実行してクレデンシャルストアを操作できます。

キーペアの生成

generate-key-pair コマンドでキーペアを作成します。その後、キーペアをクレデンシャルストアのエイリアスのに保存できます。以下の例では、割り当てられたサイズが3072ビットのRSAキーペアを作成し、クレデンシャルストアに指定された場所に保存しています。キーペアに割り当てられたエイリアスは example です。

$ EAP_HOME/bin/elytron-tool.sh credential-store --location=<path_to_store_file> --generate-key-pair example --algorithm RSA --size 3072
キーペアのインポート

既存の SSH キーペアを、指定したエイリアスでクレデンシャルストアにインポートするには、import-key-pair コマンドを使用します。以下の例では、Open SSH 形式の秘密鍵を含む/home/user/.ssh/id_rsa ファイルからexampleというエイリアスのキーペアをインポートしています。

$ EAP_HOME/bin/elytron-tool.sh credential-store --import-key-pair example --private-key-location /home/user/.ssh/id_rsa --location=<path_to_store_file>
キーペアのエクスポート

キーペアの公開鍵を表示するには、export-key-pair-public-key コマンドを使用します。公開鍵には、OpenSSH 形式のエイリアスが指定されています。以下の例では、エイリアスexampleの公開鍵を表示しています。

$ EAP_HOME/bin/elytron-tool.sh credential-store --location=<path_to_store_file> --export-key-pair-public-key example

Credential store password:
Confirm credential store password:
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMfncZuHmR7uglb0M96ieArRFtp42xPn9+ugukbY8dyjOXoi
cZrYRyy9+X68fylEWBMzyg+nhjWkxJlJ2M2LAGY=
注記

export-key-pair-public-key コマンドを実行すると、クレデンシャルストアのパスフレーズの入力が求められます。パスフレーズが存在しない場合は、プロンプトを空白にします。

4.1.5.8. Elytron の設定ファイルに保存されたキーペアの使用例

キーペアは、個別のキーでありながら一致する、パブリックキーとプライベートキーの 2 つの暗号キーで設定されます。キーペアをクレデンシャルストアに保存してから、elytron の設定ファイルでキーペアを参照する必要があります。これにより、スタンドアロンサーバーの設定データ管理用のアクセス権を Git に割り当てることができます。

以下の例では、elytron の設定ファイルの &lt;credential-stores&gt; 要素でクレデンシャルストアとそのプロパティーを参照しています。&lt;credential&gt; 要素は、クレデンシャルストアとキーペアを格納するエイリアスを参照します。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <authentication-client xmlns="urn:elytron:client:1.6">

     <credential-stores>
        <credential-store name="${credential_store_name}">
           <protection-parameter-credentials>
              <clear-password password="${credential_store_password}"/>
           </protection-parameter-credentials>
           <attributes>
              <attribute name="path" value="${path_to_credential_store}"/>
           </attributes>
        </credential-store>
     </credential-stores>

     <authentication-rules>
        <rule use-configuration="${configuration_file_name}"/>
     </authentication-rules>

     <authentication-configurations>
        <configuration name="${configuration_file_name}">
           <credentials>
              <credential-store-reference store="${credential_store_name}" alias="${alias_of_key_pair}"/>
           </credentials>
        </configuration>
     </authentication-configurations>

  </authentication-client>
</configuration>

elytron 設定ファイルの設定後に、そのキーペアを SSH 認証に使用できます。

4.1.5.9. WildFly Elytron Tool を使用した、マスクされた文字列の生成

WildFly Elytron ツールで、クレデンシャルストアのプレーンテキストパスワードの代わりに使用する PicketBox と互換性のある MASK- で暗号化した文字列を生成できます。

手順

  • マスクされた文字列を生成するには、以下のコマンドを使用して salt および iteration count の値を指定します。

    $ EAP_HOME/bin/elytron-tool.sh mask --salt <salt> --iteration <iteration_count> --secret <password>

    以下に例を示します。

    $ EAP_HOME/bin/elytron-tool.sh mask --salt 12345678 --iteration 123 --secret supersecretstorepassword
    
    MASK-8VzWsSNwBaR676g8ujiIDdFKwSjOBHCHgnKf17nun3v;12345678;123

    コマンドでシークレットを指定しない場合は、その引数を省略し、標準入力を使用して手動でシークレットを入力するように求められます。

詳細は、EAP_HOME/bin/elytron-tool.sh mask --help コマンドを使用して、利用可能なオプションの詳細な一覧を表示してください。

4.1.6. Elytron の暗号化式

機密な文字列を秘匿するには、サーバー設定ファイルで機密な字列を指定する代わりに、暗号化表現を使用できます。

暗号化式とは、文字列を SecretKeyCredential で暗号化し、その文字列をエンコーディングの接頭辞とリゾルバー名と組み合わせたものです。エンコーディング接頭辞は、Elytron に式が暗号化されていることを伝えます。リゾルバーは、暗号化式をクレデンシャルストア内で対応する SecretKeyCredential にマッピングします。

Elytron の expression=encryption リソースは、暗号化式を使用して、実行時にその中の暗号化された文字列を復号します。設定ファイルの中で、機密な文字列そのものではなく、暗号化式を使用して文字列の機密性を守ることができます。暗号化式は、以下のような形式になります。

特定のリゾルバーを使用する場合の構文

${ENC::RESOLVER_NAME:ENCRYPTED_STRING}

ENC は、暗号化式を表す接頭語です。

RESOLVER_NAME は、Elytron が暗号化された文字列の復号時に使用するリゾルバーです。

${ENC::initialresolver:RUxZAUMQE+L5zx9LmCRLyh5fjdfl1WM7lhfthKjeoEU+x+RMi6s=}

デフォルトのリゾルバーで暗号化式を作成すると、以下のようになります。

デフォルトのリゾルバーを使用する場合の構文

${ENC::ENCRYPTED_STRING}

${ENC::RUxZAUMQE+L5zx9LmCRLyh5fjdfl1WM7lhfthKjeoEU+x+RMi6s=}

この場合、Elytron は expression=encryption リソースで定義したデフォルトのリゾルバーを使用して式を復号化します。暗号化式は、対応の全リソース属性で使用できます。ある属性が暗号化式をサポートしているかどうかを調べるには、read-resource-description 操作などを使用します。

例: mail/mail-session の read-resource-description

/subsystem=mail/mail-session=*/:read-resource-description(recursive=true,access-control=none)
{
  "outcome"=>"success",
  "result"=>[{
  ...
    "from"=>{
      ...
      "expression-allowed"=>true,
      ...
   }]
}

この例では、from 属性が暗号化式をサポートしています。つまり、暗号化して、暗号化式を使用し、from フィールドのメールアドレスを非表示にできます。

4.1.7. Elytron での暗号化式の作成

機密な文字列と SecretKeyCredential から、暗号化式を作成します。この暗号化式を、管理モデルであるサーバー設定ファイルの機密文字列の代わりに使用すして、機密文字列を秘匿できます。

前提条件

手順

  1. 次の管理 CLI コマンドを使用して、クレデンシャルストア内の既存の SecretKeyCredential のエイリアスを参照するリゾルバーを作成します。

    構文

    /subsystem=elytron/expression=encryption:add(resolvers=[{name=<name_of_the_resolver>, credential-store=<name_of_credential_store>, secret-key=<secret_key_alias>}])

    /subsystem=elytron/expression=encryption:add(resolvers=[{name=exampleResolver, credential-store=examplePropertiesCredentialStore, secret-key=key}])

    リソースの重複に関するエラーメッセージが表示された場合は、以下のように、add ではなく list-add 操作を行ってください。

    構文

    /subsystem=elytron/expression=encryption:list-add(name=resolvers, value={name=<name_of_the_resolver>, credential-store=<name_of_credential_store>, secret-key=<secret_key_alias>})

    /subsystem=elytron/expression=encryption:list-add(name=resolvers,value={name=exampleResolver, credential-store=examplePropertiesCredentialStore, secret-key=key})
    {
        "outcome" => "success",
        "response-headers" => {
            "operation-requires-reload" => true,
            "process-state" => "reload-required"
        }
    }

  2. 以下の管理 CLI コマンドでサーバーをリロードします。

    reload
  3. 管理 CLI でのコマンドのキャッシングを無効にします。

    重要

    キャッシングを無効にしない場合は、管理 CLI の履歴ファイルにアクセスできるユーザーは誰でも、秘密鍵を確認できます。

    history --disable
  4. 以下の管理 CLI コマンドを使用して、暗号化式を作成します。

    構文

    /subsystem=elytron/expression=encryption:create-expression(resolver=<existing_resolver>, clear-text=<sensitive_string_to_protect>)

    /subsystem=elytron/expression=encryption:create-expression(resolver=exampleResolver, clear-text=TestPassword)
    {
        "outcome" => "success",
        "result" => {"expression" => "${ENC::exampleResolver:RUxZAUMQgtpG7oFlHR2j1Gkn3GKIHff+HR8GcMX1QXHvx2uGurI=}"}
    }

    ${ENC::example Resolver:RUx ZAUMQgtp G7o Fl HR2j1Gkn3GKIHff+HR8Gc MX1QXHvx2u Gur I=} は、管理モデルで Test Password の代わりに使用する暗号化式です。

    同じプレーンテキストをさまざまな場所で使用する場合は、対処の場所でプレーンテキストの代わりに、毎回このコマンドを繰り返してから暗号化式を使用します。同じプレーンテキストに対して同じコマンドを繰り返すと、同じキーでも異なる結果が得られます。これは、Elytron が呼び出しごとに固有の初期化ベクトルを使用しているためです。

    異なる暗号化式を使用して、文字列の暗号化式 1 つが侵害された場合に、他の暗号化式にも同じ文字列が含まれていることをユーザーが発見できないようにします。

  5. 以下の管理 CLI コマンドを使用して、コマンドキャッシングを再度有効にします。

    history --enable

4.1.8. JBoss EAP 設定での Password Credential の使用

クレデンシャルストアに保存されているパスワードまたは機密文字列を参照するには、JBoss EAP 設定で credential-reference 属性を使用します。credential-reference は、JBoss EAP 設定の全体でパスワードやその他の機密文字列を提供する代わりに使用できます。

前提条件

手順

  • credential-reference 属性で、既存の KeyStoreCredentialStore と PasswordCredential のエイリアスを参照します。

    構文

    credential-reference={store=<store_name>, alias=<alias>}

    data-source add --name=example_data_source --jndi-name=java:/example_data_source --driver-name=h2 --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE --user-name=db_user --credential-reference={store=exampleKeyStoreCredentialStore, alias=passwordCredentialAlias}
    16:17:23,024 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:/example_data_source]

    この例では、KeyStoreCredentialStore の exampleKeyStoreCredentialStore にある passwordCredentialAlias エイリアスが指定された既存の PasswordCredential を、データベースのプレーンテキストパスワードの代わりに使用し、データベースのパスワードを保護しています。

4.1.9. 暗号化式を使用した KeyStoreCredentialStore/credential-store の保護

Key Store Credential Store を保護するために、暗号化式を使用できます。

前提条件

手順

  • 暗号化式を clear-text として使用する KeyStoreCredentialStore を作成します。

    構文

    /subsystem=elytron/credential-store=<name_of_credential_store>:add(path=<path_to_the_credential_store>, create=true, modifiable=true, credential-reference={clear-text=<encrypted_expression>})

    /subsystem=elytron/credential-store=secureKeyStoreCredentialStore:add(path="secureKeyStoreCredentialStore.jceks", relative-to=jboss.server.data.dir, create=true, modifiable=true, credential-reference={clear-text=${ENC::exampleResolver:RUxZAUMQgtpG7oFlHR2j1Gkn3GKIHff+HR8GcMX1QXHvx2uGurI=}})
    {"outcome" => "success"}

4.1.10. クレデンシャルストアのクレデンシャルの自動更新

クレデンシャルストアがある場合には、クレデンシャル参照から取得する前に、クレデンシャルを追加したり、既存のクレデンシャルを更新したりする必要はありません。Elytron はこのプロセスを自動化します。クレデンシャル参照の設定時には、store 属性と clear-text 属性の両方を指定します。Elytron は、store 属性で指定されたクレデンシャルストアにクレデンシャルを自動的に追加または更新します。オプションで、エイリアス 属性を指定すできます。

Elytron はクレデンシャルストアを以下のように更新する。

  • エイリアスを指定した場合:

    • エイリアスのエントリーが存在する場合に、既存のクレデンシャルは指定のクリアテキストのパスワードに置き換えられます。
    • エイリアスのエントリーが存在しない場合は、指定のエイリアスとクリアテキストのパスワードを含む新しいエントリーがクレデンシャルストアに追加されます。
  • エイリアスが指定されない場合、Elytron はエイリアスを生成して生成されたエイリアスと指定されたクリアテキストパスワードが指定されたエントリーを新たに、クレデンシャルストアに追加します。

クレデンシャルストアが更新されると、clear-text 属性は管理モデルから削除されます。

次の例は、storeclear-textalias の各属性を指定したクレデンシャル参照を作成する方法を示しています。

/subsystem=elytron/key-store=exampleKS:add(relative-to=jboss.server.config.dir, path=example.keystore, type=JCEKS, credential-reference={store=exampleKeyStoreCredentialStore, alias=myNewAlias, clear-text=myNewPassword})
{
    "outcome" => "success",
    "result" => {"credential-store-update" => {
        "status" => "new-entry-added",
        "new-alias" => "myNewAlias"
    }}
}

以前に定義されたクレデンシャルストアに追加された myNewAlias エントリーのクレデンシャルを更新するには、次のコマンドを使用します。

/subsystem=elytron/key-store=exampleKS:write-attribute(name=credential-reference.clear-text,value=myUpdatedPassword)
{
    "outcome" => "success",
    "result" => {"credential-store-update" => {"status" => "existing-entry-updated"}},
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
注記

credential-reference パラメーターを含む操作に失敗した場合、クレデンシャルストアの自動更新は行われません。

credential-reference 属性で指定されていたクレデンシャルストアは変更されません。

4.1.11. FIPS 140-2 準拠のクレデンシャルストアの定義

Federal Information Processing Standards (FIPS)140-2 に準拠したクレデンシャルストアは、Network Security Services (NSS) のデータベースを使用するか、Bouncy Castle のプロバイダーで定義できます。

4.1.11.1. NSS データベースを使用した FIPS 140-2 対応クレデンシャルストアの定義

FIPS (Federal Information Processing Standards) に準拠したキーストアを入手するには、Sun PKCS#11(PKCS は Public Key Cryptography Standards の略) プロバイダーを使用して、NSS(Network Security Services) データベースにアクセスします。データベースの定義方法については、NSS データベースの設定 を参照してください。

手順

  1. クレデンシャルストアで使用する秘密鍵を作成します。

    注記

    keytool コマンドを動作させるには、nss_pkcsll_fips.cfg ファイルで、nss Db Mode 属性を read Write として割り当てる必要があります。

    $ keytool -keystore NONE -storetype PKCS11 -storepass <keystore_password> -genseckey -alias <key_alias> -keyalg <key_algorithm> -keysize <key_size>
  2. 外部クレデンシャルストアを作成します。外部クレデンシャルストアは PKCS#11 キーストアに秘密鍵を保持し、前の手順で定義したエイリアスを使用してこのキーストアにアクセスします。このキーストアは、Java Cryptography Extension Keystore (JCEKS) キーストアでの認証情報の復号化使用されます。credential-store 属性に加え、credential-store KeyStoreCredentialStore を設定して、外部クレデンシャルストアの設定に使用されます。

    /subsystem=elytron/credential-store=<store_name>:add(modifiable=true, implementation-properties={"keyStoreType"=>"PKCS11", "external"=>"true", "keyAlias"=>"<key_alias>", externalPath="<path_to_JCEKS_file>"}, credential-reference={clear-text="<keystore_password>"}, create=true)
  3. 作成後、クレデンシャルストアを使用して通常通りにエイリアスを保存することができます。

    /subsystem=elytron/credential-store=<store_name>:add-alias(alias="<alias>", secret-value="<sensitive_string>")
  4. クレデンシャルストアから読み取り、エイリアスが正常に追加されたことを確認します。

    /subsystem=elytron/credential-store=<store_name>:read-aliases()

4.1.11.2. Bouncy Castle プロバイダーを使用した FIPS 140-2 準拠のクレデンシャルストアの定義

Bouncy Castle のプロバイダーを使用して、FIPS(Federal Information Processing Standards)140-2 に準拠したクレデンシャルストアを定義します。

前提条件

  • お使いの環境が BouncyCastle プロバイダーを使用するように設定されていることを確認する。

    詳しくは、Bouncy Castle プロバイダーを使用するための環境設定をご覧ください。

手順

  1. クレデンシャルストアで使用する秘密鍵を作成します。

    $ keytool -genseckey -alias<key_alias> -keyalg <key_algorithm> -keysize <key_size> -keystore <path_to_keystore> -storetype BCFKS -storepass <key_and_keystore_password> -keypass <key_and_keystore_password>
    重要

    FIPS クレデンシャルストアを elytron サブシステムで定義するには、キーストアの keypass および storepass が同じである必要があります。

  2. 外部クレデンシャルストアを作成します。外部クレデンシャルストアは BCFKS キーストアの秘密鍵を保持し、前の手順で定義したエイリアスを使用してこのキーストアにアクセスします。その後、このキーストアは JCEKS キーストアの認証情報を復号化するために使用されます。credential-store KeyStoreCredentialStore 実装プロパティー は、外部クレデンシャルストアを設定するために使用されます。

    /subsystem=elytron/credential-store=<BCFKS_credential_store>:add(relative-to=jboss.server.config.dir,credential-reference={clear-text=<key_and_keystore_password>},implementation-properties={keyAlias=<key_alias>,external=true,externalPath=<path_to_credential_store>,keyStoreType=BCFKS},create=true,location=<path_to_keystore>,modifiable=true)
  3. 作成後、クレデンシャルストアを使用して通常通りにエイリアスを保存することができます。

    /subsystem=elytron/credential-store=<BCFKS_credential_store>:add-alias(alias="<alias>", secret-value="<sensitive_string>")
  4. クレデンシャルストアから読み取り、エイリアスが正常に追加されたことを確認します。

    /subsystem=elytron/credential-store=<BCFKS_credential_store>:read-aliases()

4.1.12. クレデンシャルストアのカスタム実装の使用

クレデンシャルストアのカスタム実装の使用

手順

  1. Service Provider Interface (SPI) CredentialStoreSpi 抽象クラスを拡張するクラスを作成します。
  2. Java Security Provider を実装するクラスを作成します。このプロバイダーはカスタムクレデンシャルストアクラスをサービスとして追加する必要があります。
  3. クレデンシャルストアおよびプロバイダークラスが含まれるモジュールを作成し、org.wildfly.security.elytron における依存関係とともに JBoss EAP に追加します。以下に例を示します。

    module add --name=org.jboss.customcredstore --resources=/path/to/customcredstoreprovider.jar --dependencies=org.wildfly.security.elytron --slot=main
  4. プロバイダーのプロバイダーローダーを作成します。以下に例を示します。

    /subsystem=elytron/provider-loader=myCustomLoader:add(class-names=[org.wildfly.security.mycustomcredstore.CustomElytronProvider],module=org.jboss.customcredstore)
  5. カスタム実装を使用してクレデンシャルストアを作成します。

    注記

    適切な providers および type の値を指定するようにしてください。type の値は、カスタムクレデンシャルストアクラスをサービスとして追加するプロバイダークラスで使用されるものです。

    以下に例を示します。

    /subsystem=elytron/credential-store=my_store:add(providers=myCustomLoader,type=CustomKeyStorePasswordStore,location="cred_stores/my_store.jceks",relative-to=jboss.server.data.dir,credential-reference={clear-text=supersecretstorepassword},create=true)

    また、複数のプロバイダーを作成した場合は、other-providers で別のプロバイダーローダーを使用して追加のプロバイダーを指定することもできます。これにより、新しいタイプの認証情報の追加実装が可能になります。指定した他のプロバイダーは、カスタムクレデンシャルストアの initialize メソッドで Provider[] 引数として自動的にアクセスできます。以下に例を示します。

    /subsystem=elytron/credential-store=my_store:add(providers=myCustomLoader,other-providers=myCustomLoader2,type=CustomKeyStorePasswordStore,location="cred_stores/my_store.jceks",relative-to=jboss.server.data.dir,credential-reference={clear-text=supersecretstorepassword},create=true)

4.1.13. 外部ソースからクレデンシャルストアのパスワードの取得

クレデンシャルストアのパスワードをクリアテキスト形式で指定する代わりに、擬似クレデンシャルストアを使用してパスワードを指定することもできます。

パスワードの設定方法には以下のオプションがあります。

EXT

java.lang.Runtime#exec(java.lang.String) を使用した外部コマンド。コマンドのパラメーターには、スペースで区切った文字列のリストを指定できます。外部コマンドは、オペレーティングシステムからの実行可能ファイル (シェルスクリプトや実行可能バイナリーファイルなど) を参照します。Elytron は、実行したコマンドの標準出力からパスワードを読み取ります。

credential-reference={clear-text="{EXT}/usr/bin/getThePasswordScript.sh par1 par2", type="COMMAND"}

CMD

java.lang.ProcessBuilder を使用した外部コマンドコマンドのパラメーターには、コンマで区切った文字列のリストを指定できます。外部コマンドは、オペレーティングシステムからの実行可能ファイル (シェルスクリプトや実行可能バイナリーファイルなど) を参照します。Elytron は、実行したコマンドの標準出力からパスワードを読み取ります。

credential-reference={clear-text="{CMD}/usr/bin/getThePasswordScript.sh par1,par2", type="COMMAND"}

MASK

PBE または Password Based Encryption を使用してマスクされたパスワード。SALT および ITERATION の値が含まれる以下の形式である必要があります。

credential-reference={clear-text="MASK-MASKED_VALUE;SALT;ITERATION"}

credential-reference={clear-text="MASK-NqMznhSbL3lwRpDmyuqLBW==;12345678;123"}

重要

EXTCMD、および MASK は、外部パスワードを提供するレガシーセキュリティー vault スタイルと後方互換性を提供します。MASK には、SALTITERATION の値が含まれる上記の形式を使用する必要があります。

また、別のクレデンシャルストアにあるパスワードを、新しいクレデンシャルストアのパスワードとして使用することもできます。

別のクレデンシャルストアのパスワードで作成されたクレデンシャルストアの例

/subsystem=elytron/credential-store=exampleCS:add(location="cred_stores/exampleCS.jceks", relative-to=jboss.server.data.dir, create=true, credential-reference={store=cred-store, alias=pwd})

4.1.14. セキュリティーで保護されたリソースを解除するための初期キーの JBoss EAP への指定

セキュリティー上の理由から、一部の JBoss EAP コンポーネントは、KeyStoreCredentialStore の PasswordCredential によって保護されます。この KeyStoreCredentialStore は、JBoss EAP の外部に保存されている秘密鍵によって保護されています。これをマスター キーと呼びます。JBoss EAP は起動時にこのマスター キーを使用して KeyStoreCredentialStore のロックを解除し、KeyStoreCredentialStore に保存されている PasswordCredential を取得します。

Elytron の PropertiesCredentialStore を使ってマスターキーを指定できます。また、マスターキーやパスワードを外部から入手することもできます。外部ソースからパスワードを取得する方法は、外部ソースからクレデンシャルストアのパスワードの取得 を参照してください。

4.1.14.1. スタンドアロンサーバー用の Properties Credential Store/secret-key-credential-Store の作成

管理 CLI を使用して Properties Credential Store を作成します。Properties Credential Store を作成すると、JBoss EAP はデフォルトで秘密鍵を生成します。生成された鍵の名前は key で、そのサイズは 256 ビットです。

前提条件

  • 最低でも、JBoss EAP が実行されているユーザーアカウントの PropertiesCredentialStore を含むディレクトリーへの読み取り/書き込みのアクセスが割り当てられている。

手順

  • 次のコマンドを使用して、管理 CLI を使用して PropertiesCredentialStore を作成します。

    構文

    /subsystem=elytron/secret-key-credential-store=<name_of_credential_store>:add(path="<path_to_the_credential_store>", relative-to=<path_to_store_file>)

    /subsystem=elytron/secret-key-credential-store=examplePropertiesCredentialStore:add(path=examplePropertiesCredentialStore.cs, relative-to=jboss.server.config.dir)
    {"outcome" => "success"}

4.1.14.2. Elytron での暗号化式の作成

機密な文字列と SecretKeyCredential から、暗号化式を作成します。この暗号化式を、管理モデルであるサーバー設定ファイルの機密文字列の代わりに使用すして、機密文字列を秘匿できます。

前提条件

手順

  1. 次の管理 CLI コマンドを使用して、クレデンシャルストア内の既存の SecretKeyCredential のエイリアスを参照するリゾルバーを作成します。

    構文

    /subsystem=elytron/expression=encryption:add(resolvers=[{name=<name_of_the_resolver>, credential-store=<name_of_credential_store>, secret-key=<secret_key_alias>}])

    /subsystem=elytron/expression=encryption:add(resolvers=[{name=exampleResolver, credential-store=examplePropertiesCredentialStore, secret-key=key}])

    リソースの重複に関するエラーメッセージが表示された場合は、以下のように、add ではなく list-add 操作を行ってください。

    構文

    /subsystem=elytron/expression=encryption:list-add(name=resolvers, value={name=<name_of_the_resolver>, credential-store=<name_of_credential_store>, secret-key=<secret_key_alias>})

    /subsystem=elytron/expression=encryption:list-add(name=resolvers,value={name=exampleResolver, credential-store=examplePropertiesCredentialStore, secret-key=key})
    {
        "outcome" => "success",
        "response-headers" => {
            "operation-requires-reload" => true,
            "process-state" => "reload-required"
        }
    }

  2. 以下の管理 CLI コマンドでサーバーをリロードします。

    reload
  3. 管理 CLI でのコマンドのキャッシングを無効にします。

    重要

    キャッシングを無効にしない場合は、管理 CLI の履歴ファイルにアクセスできるユーザーは誰でも、秘密鍵を確認できます。

    history --disable
  4. 以下の管理 CLI コマンドを使用して、暗号化式を作成します。

    構文

    /subsystem=elytron/expression=encryption:create-expression(resolver=<existing_resolver>, clear-text=<sensitive_string_to_protect>)

    /subsystem=elytron/expression=encryption:create-expression(resolver=exampleResolver, clear-text=TestPassword)
    {
        "outcome" => "success",
        "result" => {"expression" => "${ENC::exampleResolver:RUxZAUMQgtpG7oFlHR2j1Gkn3GKIHff+HR8GcMX1QXHvx2uGurI=}"}
    }

    ${ENC::example Resolver:RUx ZAUMQgtp G7o Fl HR2j1Gkn3GKIHff+HR8Gc MX1QXHvx2u Gur I=} は、管理モデルで Test Password の代わりに使用する暗号化式です。

    同じプレーンテキストをさまざまな場所で使用する場合は、対処の場所でプレーンテキストの代わりに、毎回このコマンドを繰り返してから暗号化式を使用します。同じプレーンテキストに対して同じコマンドを繰り返すと、同じキーでも異なる結果が得られます。これは、Elytron が呼び出しごとに固有の初期化ベクトルを使用しているためです。

    異なる暗号化式を使用して、文字列の暗号化式 1 つが侵害された場合に、他の暗号化式にも同じ文字列が含まれていることをユーザーが発見できないようにします。

  5. 以下の管理 CLI コマンドを使用して、コマンドキャッシングを再度有効にします。

    history --enable

4.1.14.3. 暗号化式を使用した KeyStoreCredentialStore/credential-store の保護

Key Store Credential Store を保護するために、暗号化式を使用できます。

前提条件

手順

  • 暗号化式を clear-text として使用する KeyStoreCredentialStore を作成します。

    構文

    /subsystem=elytron/credential-store=<name_of_credential_store>:add(path=<path_to_the_credential_store>, create=true, modifiable=true, credential-reference={clear-text=<encrypted_expression>})

    /subsystem=elytron/credential-store=secureKeyStoreCredentialStore:add(path="secureKeyStoreCredentialStore.jceks", relative-to=jboss.server.data.dir, create=true, modifiable=true, credential-reference={clear-text=${ENC::exampleResolver:RUxZAUMQgtpG7oFlHR2j1Gkn3GKIHff+HR8GcMX1QXHvx2uGurI=}})
    {"outcome" => "success"}

KeyStoreCredentialStore を暗号化式で保護した後、KeyStoreCredentialStore で SecretKeyCredential を生成し、その秘密鍵を使って別の暗号化式を作成できます。そして、この新しい暗号化式は、管理モデル (サーバー設定ファイル) の機密な文字列の代わりに使用できます。クレデンシャルストアのチェーン全体を作成してセキュリティーを確保できます。このようなチェーンは、文字列が以下のように保護されているため、機密な文字列を推測することが難しくなります。

  • 最初の暗号化式は、KeyStoreCredentialStore のセキュリティーを保護します。
  • また、別の暗号化式では、機密文字列のセキュリティーを確保します。
  • 機密な文字列の解読には、暗号化式を両方、解読する必要があります。

暗号化式のチェーンが長くなればなるほど、機密な文字列の復号化は困難になります。

4.1.15. パスワード vault からクレデンシャルストアへの変換

WildFly Elytron ツールを使用することで、パスワード vault をクレデンシャルストアに変換できます。パスワード vault をクレデンシャルストアに変換するには、vault の初期化時に vault の値を 使用する必要があります。

注記

パスワード vault を変換する際に、新しいクレデンシャルストアのエイリアスは、同等のパスワード vault ブロックおよび属性名 (VAULT_BLOCK::ATTRIBUTE_NAME) に基づいて、以下の形式で名前が付けられます。

4.1.15.1. WildFly Elytron Tool を使用した、単一パスワード vault のクレデンシャルストアへの変換

WildFly Elytron Tool を使用して 1 つのパスワード vault をクレデンシャルストアに変換します。

手順

  • 以下のコマンドで、単一のパスワード vault をクレデンシャルストアに変換します。

    $ EAP_HOME/bin/elytron-tool.sh vault --keystore "<path_to_vault_file>" --keystore-password <vault_password> --enc-dir "<path_to_vault_directory>" --salt <salt> --iteration <iteration_count> --alias <vault_alias>

    たとえば、--location 引数を使用して、新しいクレデンシャルストアのファイル名と場所を指定することもできます。

    $ EAP_HOME/bin/elytron-tool.sh vault --keystore ../vaults/vault.keystore --keystore-password vault22 --enc-dir ../vaults/ --salt 1234abcd --iteration 120 --alias my_vault --location ../cred_stores/my_vault_converted.cred_store
注記

--summary 引数を使用して、変換に使用する管理 CLI コマンドの概要を出力することもできます。プレーンテキストのパスワードが使用される場合でも、これはサマリー出力でマスクされることに注意してください。このコマンドで指定しない限り、デフォルトの saltiteration の値が使用されます。

4.1.15.2. WildFly Elytron Tool を使用した、パスワード vault のクレデンシャルストアへの一括変換

複数のパスワード vault をクレデンシャルストアに一括で変換します。

手順

  1. 以下の形式で、変換する vault の詳細を記述ファイルに配置します。

    keystore:<path_to_vault_file>
    keystore-password:<vault_password>
    enc-dir:<path_to_vault_directory>
    salt:<salt> 1
    iteration:<iteration_count>
    location:<path_to_converted_cred_store> 2
    alias:<vault_alias>
    properties:<parameter1>=<value1>;<parameter2>=<value2>; 3
    1
    vault にプレーンテキストのパスワードを指定する場合は salt および iteration は省略できます。
    2
    変換したクレデンシャルストアの場所とファイル名を指定します。
    3
    オプション: オプションパラメーターのリストをセミコロン区切り (;) で指定します。利用可能なパラメーターの一覧は、EAP_HOME/bin/elytron-tool.sh vault --help を参照してください。

    以下に例を示します。

    keystore:/vaults/vault1/vault1.keystore
    keystore-password:vault11
    enc-dir:/vaults/vault1/
    salt:1234abcd
    iteration:120
    location:/cred_stores/vault1_converted.cred_store
    alias:my_vault
    
    keystore:/vaults/vault2/vault2.keystore
    keystore-password:vault22
    enc-dir:/vaults/vault2/
    salt:abcd1234
    iteration:130
    location:/cred_stores/vault2_converted.cred_store
    alias:my_vault2
  2. 直前の手順の説明ファイルを使用して、一括変換コマンドを実行します。

    $ EAP_HOME/bin/elytron-tool.sh vault --bulk-convert vaultdescriptions.txt

詳細は、EAP_HOME/bin/elytron-tool.sh vault --help コマンドを使用して、利用可能なオプションの詳細な一覧を表示してください。

4.1.16. Elytron クライアントでのクレデンシャルストアの使用例

Jakarta Enterprise Beans などの JBoss EAP に接続するクライアントは、Elytron クライアントを使用して認証できます。実行中の JBoss EAP サーバーにアクセスできないユーザーは、WildFly Elytron ツールを使用してクレデンシャルストアを作成および変更できます。そのため、クライアントは Elytron クライアントを使用してクレデンシャルストア内の機密情報にアクセスできます。

以下の例は、Elytron クライアント設定ファイルでクレデンシャルストアを使用する方法を示しています。

クレデンシャルストアを含む custom-config.xml の例

<configuration>
  <authentication-client xmlns="urn:elytron:client:1.2">
    ...
    <credential-stores>
      <credential-store name="my_store"> 1
        <protection-parameter-credentials>
          <credential-store-reference clear-text="pass123"/> 2
        </protection-parameter-credentials>
        <attributes>
          <attribute name="location" value="/path/to/my_store.jceks"/> 3
        </attributes>
      </credential-store>
    </credential-stores>
    ...
    <authentication-configurations>
      <configuration name="my_user">
        <set-host name="localhost"/>
        <set-user-name name="my_user"/>
        <set-mechanism-realm name="ManagementRealm"/>
        <use-provider-sasl-factory/>
        <credentials>
          <credential-store-reference store="my_store" alias="my_user"/> 4
        </credentials>
      </configuration>
    </authentication-configurations>
    ...
  </authentication-client>
</configuration>

1
Elytron クライアント設定ファイル内で使用するクレデンシャルストアの名前。
2
クレデンシャルストアのパスワード。
3
クレデンシャルストアファイルへのパス。
4
クレデンシャルストアに保存される機密文字列のクレデンシャル参照。

4.2. パスワード vault

JBoss EAP および関連するアプリケーションの設定には、ユーザー名とパスワードなどの機密情報が必要になります。パスワードをプレーンテキストで設定ファイルに保存する代わりに、パスワード vault 機能を使用してパスワード情報をマスクし、暗号化したキーストアに保存できます。パスワードを保存したら、JBoss EAP にデプロイされた管理 CLI コマンドまたはアプリケーションに参照を含めることができます。

パスワード vault は Java キーストアをストレージメカニズムとして使用します。パスワード vault はストレージとキーストレージの 2 つで設定されます。Java キーストアは、Vault ストレージで機密文字列を暗号化または復号化するために使用されるキーを保存するために使用されます。

重要

この手順では、Java Runtime Environment (JRE) が提供する keytool ユーティリティーが使用されます。ファイルパスを見つけます。Red Hat Enterprise Linux では、/usr/bin/keytool です。

JCEKS キーストアの実装は Java ベンダーごとに異なります。そのため、キーストアは、使用している JDK と同じベンダーの keytool ユーティリティーを使用して生成する必要があります。別のベンダーの JDK で実行している JBoss EAP 7 インスタンスで、あるベンダーの JDK からキーツールによって生成されたキーストアを使用すると、java.io.IOException: com.sun.crypto.provider.SealedObjectForKeyProtector の例外が発生します。

4.2.1. パスワード vault の設定

以下の手順に従って、パスワード Vault をセットアップし、使用します。

  1. キーストアおよびその他の暗号化された情報を保存するディレクトリーを作成します。

    この手順では、ディレクトリーは EAP_HOME/vault/ と想定します。このディレクトリーには機密情報が含まれるため、アクセスは、一部のユーザーに制限する必要があります。JBoss EAP を実行しているユーザーアカウントには少なくとも読み書き込みアクセスが必要です。

  2. Keytool ユーティリティーで使用するパラメーターを決定します。

    以下のパラメーターの値を決めます。

    alias
    エイリアスは、vault やキーストアに保存されている他のデータの一意識別子です。エイリアスは大文字と小文字を区別しません。
    storetype
    ストアタイプはキーストアのタイプを指定します。値は、jceks が推奨されます。
    keyalg
    暗号化に使用するアルゴリズム。JRE およびオペレーティングシステムのドキュメントを参照して、利用可能な他の選択肢を確認します。
    keysize
    暗号化キーのサイズは、ブルートフォースでの暗号解除の難易度に影響します。適切な値の詳細は、キーツールユーティリティーとともに配布されるドキュメントを参照してください。
    storepass
    storepass の値は、キーストアに対する認証に使用されるパスワードであるため、鍵を読み取ることができます。パスワードは 6 文字以上である必要があります。パスワードは、キーストアへのアクセス時に入力する必要があります。このパラメーターを省略すると、コマンド実行後に keytool ユーティリティーにより入力が求められます。
    keypass
    Keypass の値は、特定のキーにアクセスするために使用されるパスワードで、storepass パラメーターの値と一致する必要があります。
    validity
    validity の値は、鍵が有効になる期間 (日数) です。
    keystore

    キーストアの値は、キーストアの値が保存されるファイルパスおよびファイル名です。キーストアファイルは、データが最初に追加されると作成されます。正しいファイルパスセパレーターが使用されるようにします。Red Hat Enterprise Linux および同様のオペレーティングシステムの場合は / (スラッシュ)、Windows Server の場合は \ (バックスラッシュ) です。

    Keytool ユーティリティーには、その他の多くのオプションがあります。詳細は、JRE またはオペレーティングシステムのドキュメントを参照してください。

  3. keytool コマンドを実行し、keypassstorepass に同じ値が含まれていることを確認します。

    $ keytool -genseckey -alias vault -storetype jceks -keyalg AES -keysize 128 -storepass vault22 -keypass vault22 -keystore EAP_HOME/vault/vault.keystore

    これにより、EAP_HOME/vault/vault.keystore ファイルに作成されたキーストアが作成されます。JBoss EAP では、パスワードなどの暗号化された文字列を保存するために使用されるエイリアス vault とともに単一のキーを保存します。

4.2.2. パスワード vault の初期化

パスワード vault は、各パラメーターの値の入力を求めるプロンプトが表示される場合にインタラクティブに初期化できます。またはコマンドラインにすべてのパラメーター値が提供される場合に非対話的に初期化されます。各メソッドで同じ結果が表示されるため、どちらかを使用できます。

以下のパラメーターが必要です。

keystore URL (KEYSTORE_URL)
キーストアファイルのファイルシステムパスまたは URI。この例では、EAP_HOME/vault/vault.keystore を使用します。
キーストアパスワード (KEYSTORE_PASSWORD)
キーストアのアクセスに使用されるパスワード。
Salt (SALT)
Salt 値は、キーストアの内容を暗号化するために、iteration count (反復カウント) とともに使用される 8 文字のランダムな文字列です。
keystore Alias (KEYSTORE_ALIAS)
キーストア認識されているエイリアス。
Iteration Count (ITERATION_COUNT)
暗号化アルゴリズムの実行回数。
Directory to store encrypted files (ENC_FILE_DIR)
暗号化したファイルを保存するパス。これは通常、パスワード vault を含むディレクトリーです。キーストアと同じ場所に暗号化された情報をすべて格納することは便利ですが、必須ではありません。このディレクトリーには、制限のあるユーザーのみがアクセスできるようにする必要があります。JBoss EAP 7 を実行しているユーザーアカウントには少なくとも読み書き込みアクセスが必要です。キーストアは、パスワード vault の設定 時に作成したディレクトリーに置く必要があります。ディレクトリー名の後にはバックスラッシュまたはスラッシュが必要であることに注意してください。正しいファイルパスセパレーターが使用されるようにします。Red Hat Enterprise Linux および同様のオペレーティングシステムの場合は / (スラッシュ)、Windows Server の場合は \ (バックスラッシュ) です。
Vault Block (VAULT_BLOCK)
パスワード vault でこのブロックに与えられる名前。
Attribute (ATTRIBUTE)
保存される属性に与えられる名前。
Security Attribute (SEC-ATTR)
パスワード vault に保存されているパスワード。

パスワード vault コマンドを非対話的に実行するには、EAP_HOME/bin/ にある vault スクリプトを、関連情報のパラメーターを使って呼び出します。

$ vault.sh --keystore KEYSTORE_URL --keystore-password KEYSTORE_PASSWORD --alias KEYSTORE_ALIAS --vault-block VAULT_BLOCK --attribute ATTRIBUTE --sec-attr SEC-ATTR --enc-dir ENC_FILE_DIR --iteration ITERATION_COUNT --salt SALT

例: パスワード vault の初期化

$ vault.sh --keystore EAP_HOME/vault/vault.keystore --keystore-password vault22 --alias vault --vault-block vb --attribute password --sec-attr 0penS3sam3 --enc-dir EAP_HOME/vault/ --iteration 120 --salt 1234abcd

例: 出力

=========================================================================

  JBoss Vault

  JBOSS_HOME: EAP_HOME

  JAVA: java

=========================================================================

Nov 09, 2015 9:02:47 PM org.picketbox.plugins.vault.PicketBoxSecurityVault init
INFO: PBOX00361: Default Security Vault Implementation Initialized and Ready
WFLYSEC0047: Secured attribute value has been stored in Vault.
Please make note of the following:
********************************************
Vault Block:vb
Attribute Name:password
Configuration should be done as follows:
VAULT::vb::password::1
********************************************
WFLYSEC0048: Vault Configuration in WildFly configuration file:
********************************************

</extensions>
<vault>
  <vault-option name="KEYSTORE_URL" value="EAP_HOME/vault/vault.keystore"/>
  <vault-option name="KEYSTORE_PASSWORD" value="MASK-5dOaAVafCSd"/>
  <vault-option name="KEYSTORE_ALIAS" value="vault"/>
  <vault-option name="SALT" value="1234abcd"/>
  <vault-opt